f1fbe0e29a
Archived 4 completed OpenSpec changes (2026-04-02): - phase-3-enterprise (100/100 tasks) — 6 Phase 3 capabilities synced - devops-documentation (48/48 tasks) — 3 new + 1 merged capability - bedroom-developer-docs (33/33 tasks) — 4 new capabilities synced - engineering-docs (superseded by 2026-03-29 archive) — no tasks Main spec library grows from 21 → 35 capabilities (+14 new): federation, multi-tenancy, oidc, soc2, w3c-dids, webhooks, database, operations, system-overview, api-reference, core-concepts, developer-guides, quick-start + deployment (merged additive requirements) Active changes: 0 — project board is clear for Phase 4 planning. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.4 KiB
2.4 KiB
ADDED Requirements
Requirement: Engineering workflow and contribution guide
The system SHALL include a document (docs/engineering/08-workflow.md) that prescribes the exact steps an engineer MUST follow to contribute any new feature or change, from idea to merged code.
Scenario: OpenSpec spec-first workflow explained
- WHEN a new engineer reads 08-workflow.md
- THEN they SHALL understand that NO implementation begins without an approved OpenAPI spec — and the exact sequence: CEO approves → Architect writes spec → CTO reviews → Developer implements → QA signs off → CEO approves merge
Scenario: OpenSpec CLI commands documented
- WHEN a new engineer wants to start a new change
- THEN the guide SHALL provide the exact commands:
openspec new change <name>,openspec status --change <name>,openspec instructions <artifact> --change <name>, and what each command does
Scenario: Branching strategy documented
- WHEN a new engineer creates a branch
- THEN the guide SHALL prescribe: feature branches from
develop, naming conventionfeature/<change-name>, PR targetsdevelop,develop→mainrequires CTO + CEO approval
Scenario: TypeScript and code standards enforced in workflow
- WHEN a new engineer writes code
- THEN the guide SHALL state the non-negotiable standards: strict mode, no
any, DRY, SOLID, JSDoc on all public methods — and that PRs violating these are blocked by the CTO regardless of functionality
Scenario: PR checklist documented
- WHEN a new engineer opens a PR
- THEN the guide SHALL provide a PR checklist: TypeScript compiles with zero errors, ESLint passes with zero warnings, unit tests pass, coverage gate met (>80%), integration tests pass, OpenAPI spec updated if endpoint changed, engineering docs updated if architecture changed
Scenario: Virtual engineering team roles explained for contributors
- WHEN a new engineer reads 08-workflow.md
- THEN they SHALL understand the role separation: they contribute as the Principal Developer role, the CTO reviews all PRs, the Architect owns spec changes, and QA owns the test sign-off — and how to interact with each role in practice
Scenario: Commit message conventions documented
- WHEN a new engineer writes a commit message
- THEN the guide SHALL prescribe the Conventional Commits format:
feat:,fix:,docs:,test:,chore:,refactor:prefixes — with examples for each