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.

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.

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 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.

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.

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