Files
social-media/docs/constraints.md
Jonathan Bourdon df3e602015
Some checks failed
Backend CI/CD / build_and_deploy (push) Has been cancelled
Frontend CI/CD / build_and_deploy (push) Has been cancelled
feat: pivot to social media workflow app
2026-04-24 12:58:35 -04:00

2.1 KiB

Constraints

These are cross-cutting rules for the current product and codebase. They are intended to reduce ambiguity for both humans and AI agents.

Product Constraints

  • The product is a workflow tool, not a public social network.
  • Internal review and client review should be modeled as related workflow stages, not isolated products.
  • Content approval must preserve traceability of comments, revisions, decisions, and status changes.
  • “Ready to publish” should only be reachable from an explicit workflow state transition, not inferred casually in UI code.

Domain Constraints

  • Workspace is the top-level scoping boundary.
  • An agency may manage multiple workspaces.
  • ContentItem belongs to a workspace scope.
  • Comments, approvals, assets, and notifications must remain traceable to the underlying workflow entity they relate to.

Backend Constraints

  • Keep module boundaries intact. Do not couple DbContexts across modules.
  • When adding schema changes, create migrations in the owning module only.
  • Follow the existing FastEndpoints handler pattern with explicit route and tag metadata.
  • Preserve development HTTP behavior locally; HTTPS redirection is not enabled in development.

Frontend Constraints

  • Frontend runtime config must flow through frontend/src/config.js.
  • Do not add feature-level import.meta.env reads.
  • Avoid introducing fallback env chains that create multiple configuration sources of truth.
  • Preserve token refresh concurrency protections in authStore and the API client.
  • Preserve route-level auth and role checks unless the product requirement explicitly changes.

Documentation Constraints

  • One topic should have one current source of truth.
  • Historical docs must be marked archived or legacy.
  • Specs should distinguish current behavior from proposed behavior.
  • Open questions should be listed explicitly rather than hidden in narrative text.

Naming Constraints

  • Prefer current product/domain language over Hutopy-era terminology.
  • Avoid reviving creator/tipping/membership concepts unless intentionally rebuilding them for the new product.