2.7 KiB
model: qwen3.5-9b prompt: model-tests/01-architectural-risk.md context: AGENTS.md date: 2026-06-04
the three highest-risk architectural choices are the is_admin flag without RBAC primitives, deferring DMs to v2 via external handles instead of in-app messaging, and relying on fs storage with no migration plan until after media ingestion is live.
first, locking down "admin-only surveys" with a single boolean flag on the user table creates a single point of failure for trust and access control. if you need to revoke admin rights or split duties later without rewriting the core auth flow, you are stuck. the risk here is operational lock-in where one person controls all feedback loops and the app has no mechanism to audit who actually created what. i estimate a 40–60% chance you will face a hard refactor when v2 needs granular permissions for events or fundraising moderation. mitigate this by designing user records with an empty policy map {} that maps roles (admin, mod, poster) to action sets upfront in the schema, even if only one role exists now.
second, handling DMs via external social handle strings means you lose the ability to resolve addresses within eutopic and force users to leave your app for conversation. this is a user retention risk because photo comments will naturally drift toward private chat, but you've built no bridge into that space. it also complicates v2 scope creep if you later decide to build DMs: you'd need to retrofit an internal message store or convince users to migrate their existing external threads. the probability of needing to rewrite the onboarding and profile flow is 30–50%. mitigate this by implementing a minimal internal /messages table with ephemeral in-app routing (pushed to v2) now, keeping it isolated from the main feed logic so you can toggle visibility without touching backend routes.
third, storing media on local fs before committing to an s3-compatible abstraction layer creates silent failure modes when disk space fills up or hardware degrades. with 5–50 users each uploading 10 photos at 5mb average, you'll hit a terabyte wall in ~100 days if growth accelerates. migrating mid-data is painful because of checksums and broken links. the risk surfaces only after you've ingested critical community content. i see a 60–70% chance this path forces an emergency rewrite during v2 prep when disk space becomes tight or backups fail. mitigate by mocking MediaStorage as an interface with fs impl now, but enforce a pre-check on first upload that writes metadata to a central catalog table and verifies free-space before accepting the file stream.
you're building something intentional here, but these three decisions will bite if you ship without planning for their evolution paths.
✻ Crunched for 1m 2s