Skip to content

Specs

Functional specifications for BizOS. A spec describes what the product does and how we know it works: users, screens, rules, and acceptance criteria. It does not prescribe implementation; technical decisions go in Architecture and its ADRs.

Index

Spec Area Status
Admin portal Internal portal for the team that operates BizOS Draft
Admin portal - Layout Operations Draft
Admin portal - Operator access and audit Operations Draft
Admin portal - Tenant management Operations Draft
Admin portal - Provisioning monitor Operations Draft
Admin portal - Backup, restore, and reset Operations Draft
Admin portal - System health Operations Implemented
Admin portal - All users Operations Implemented
Admin portal - CRM Oversight Operations Implemented
IAM Identity and access management overview Draft
IAM - User types and actors IAM Implemented
Sign-in IAM Draft
Register IAM Draft
User management IAM Implemented
Change password IAM Implemented
IAM - Notification center IAM Implemented
IAM - Password reset IAM Implemented
IAM - My profile IAM Implemented
IAM - Audit writer IAM Implemented
IAM - Roles and permissions IAM Implemented
Customer portal Tenant Workspace Implemented
Customer portal - Customer CRM Tenant Workspace Implemented
Customer portal - Tenant sign-up Tenant Workspace Implemented
Customer portal - Product home Tenant Workspace Implemented
Tenancy - Platform core Tenancy Implemented
Tenancy - Lifecycle and workflows Tenancy Draft
Architecture overview Architecture Implemented
Architecture stack rules Architecture Implemented
Architecture Decision Records (ADRs) Architecture Implemented
System - SMTP settings System Administration Implemented
System - Activity log System Administration Draft

Conventions

  • One folder per product area, one file per capability. Start new files from the template.
  • The owner of a feature writes and maintains its spec and its data model (the module's schema) as part of building the feature; there is no separate central spec or data model.
  • Status: Draft (being written), In review (open for comments), Approved (ready to build), Implemented (every Must requirement built and tested), Superseded (replaced; link the replacement).
  • Each capability spec names its code with - Module: and - Feature: lines, matching libs/<api|web>/<module>/src/lib/features/<feature>/.
  • Requirement IDs are <PREFIX>-NN, unique within a spec and never reused. Reference them from code reviews, tests, and other specs; a test that checks a requirement starts its name with the ID.
  • Code and specs stay in sync in both directions (see .cursor/rules/specs-code-sync.mdc); the spec-sync agent skill audits drift. Agreed requirements not built yet are listed under ## Not yet implemented.
  • Priority uses MoSCoW: Must (required for the first release), Should (expected soon after), Could (nice to have), Won't (explicitly not now).
  • Acceptance criteria are written so a tester can check them without asking the author.
  • Keep open questions in the spec until they are answered, then fold the answer into the requirements.
  • Write in English. Use placeholders such as <root-domain> instead of real hosts, and never put credentials, internal URLs, or customer data in a spec.