d42c653eea
- engineering-docs → archive/2026-03-29-engineering-docs (63/63 tasks complete) - phase-2-production-ready → archive/2026-03-29-phase-2-production-ready (89/89 tasks complete) - openspec/specs/ synced with all Phase 1 + Phase 2 + engineering-docs capabilities (22 specs total) 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