1.7 KiB
model: glm-4.7 prompt: model-tests/01-architectural-risk.md date: 2026-06-04
three highest-risk decisions:
storage migration (filesystem → s3-compatible). open priority 0 question flagged in OPEN-QUESTIONS.md. moving existing user media after launch means rewriting database references, handling broken links, and likely requiring a period where both systems coexist. risk: data loss or broken media references during migration. mitigation: write to both filesystem and s3-compatible storage from day one (dual-write), making migration a matter of retiring the filesystem backend rather than moving data.
sqlite → postgres migration path. called "postgres-ready" but no documented strategy exists. sqlite and postgres have different constraint semantics, transaction behaviors, and query capabilities. a photo-first app will hit sqlite limits faster than a text-only one. risk: architectural assumptions that don't port, breaking migrations or queries at scale. mitigation: use a repository pattern to abstract database specifics, add a migration test suite with realistic media volume early, and document which postgres features you're avoiding to stay sqlite-compatible.
fedify integration without v1 activation. fedify is in the stack but federation is off, planned for v2/v3. building the core data model without understanding fedify's requirements could force major refactoring later. risk: discovering incompatibilities between your current schema and fedify's activitypub model constraints after users have data. mitigation: prototype a minimal fedify integration now to understand its schema and protocol requirements, then design your core data model with those constraints in mind even if federation remains inactive.