50 lines
2.6 KiB
Markdown
50 lines
2.6 KiB
Markdown
# 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
|
|
|
|
- `Organization` is the SaaS account, billing, subscription, connector, and workspace ownership boundary.
|
|
- `Workspace` is the brand/client workflow boundary.
|
|
- A workspace belongs to exactly one organization and is not shared between organizations.
|
|
- `ContentItem` belongs to a workspace scope.
|
|
- Channels are configured inside a workspace.
|
|
- Organization-level membership can grant inherited access to all workspaces owned by the organization.
|
|
- Workspace-level membership can grant direct workspace access and override applicable inherited workspace permissions.
|
|
- `External Collaborator` workspace participants can have workspace access without organization membership.
|
|
- 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.
|