sentryagent-idp/openspec/changes/process-governance-handoff-gap/specs/engineering-workflow/spec.md at 6fada694bb28c0239a67017fd41bc15f7f775fd3

Files

SentryAgent.ai Developer 4e3b989629 feat(governance): add CTO session completion protocol, TBC charter, and process governance OpenSpec change

- CLAUDE.md + README.md: new CTO Session Completion Protocol (authorized/done vocabulary, end-of-session summary requirement)
- docs/engineering/08-workflow.md: Section 8 — CTO Session Completion Protocol
- scripts/start-cto.sh: startup protocol updated to read PRD.md first
- openspec/changes/process-governance-handoff-gap/: full OpenSpec change record (proposal, design, specs, tasks)
- TBC/charter.md: Technical & Business Consultant charter
- TBC/minutes/TBC-MIN-001-2026-04-07.md: inaugural TBC meeting minutes

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-04-07 08:41:12 +00:00

2.8 KiB

Raw Blame History

MODIFIED 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

Scenario: CTO session completion protocol documented in workflow guide

WHEN a new engineer or CTO reads 08-workflow.md
THEN they SHALL understand that every CEO-authorized action requires a completion confirmation message posted to #vpe-cto-approvals before the session ends, and that "authorized" and "completed" are distinct states that MUST NOT be used interchangeably

2.8 KiB Raw Blame History