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>
33 lines
2.4 KiB
Markdown
33 lines
2.4 KiB
Markdown
## 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 convention `feature/<change-name>`, PR targets `develop`, `develop` → `main` requires 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
|