49 lines
2.7 KiB
Markdown
49 lines
2.7 KiB
Markdown
|
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
|