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