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>
This commit is contained in:
SentryAgent.ai Developer
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-04-07
|
||||
44
openspec/changes/process-governance-handoff-gap/design.md
Normal file
44
openspec/changes/process-governance-handoff-gap/design.md
Normal file
@@ -0,0 +1,44 @@
|
||||
## Context
|
||||
|
||||
The current multi-agent session protocol (CEO ↔ CTO via `#vpe-cto-approvals`) has a handoff gap: once the CEO authorizes an action, there is no enforcement that the CTO confirms completion before the session ends. The gap was exposed on 2026-04-07 when the CTO received commit authorization but the session ended before posting a confirmation — leaving 5 uncommitted files and the field trial status ambiguous.
|
||||
|
||||
The fix is purely process/documentation: CLAUDE.md and README.md are the authoritative session protocol documents. Both must be updated with explicit rules. No code changes are required.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- Require the CTO to post a completion confirmation to `#vpe-cto-approvals` after every CEO-authorized action
|
||||
- Require the CTO to post an end-of-session summary before closing
|
||||
- Establish clear vocabulary: "authorized" ≠ "completed" in all status tracking
|
||||
- Make these rules durable by codifying them in CLAUDE.md (session protocol) and README.md (CTO responsibilities)
|
||||
|
||||
**Non-Goals:**
|
||||
- Automated enforcement (no code hooks, no CI checks)
|
||||
- Changes to the V&V process or the `#vv-cto-resolution` channel protocol
|
||||
- Changes to any service, API, or database
|
||||
|
||||
## Decisions
|
||||
|
||||
**Decision 1: CLAUDE.md is the primary update target.**
|
||||
CLAUDE.md is loaded on every new Claude session via the project instructions. Any protocol rule placed there is enforced at session startup. README.md Section 4.3 is secondary — it documents CTO responsibilities but is not loaded automatically. Rationale: rules that need to be followed must live where they are read.
|
||||
|
||||
**Decision 2: Completion confirmation is a mandatory, structured message.**
|
||||
Rather than leaving format open-ended, the confirmation must include: action completed, outcome (success/failure), commit hash (if applicable), and resulting state. This makes it scannable and unambiguous. Alternative considered: free-form text — rejected because it creates ambiguity about whether the action actually completed.
|
||||
|
||||
**Decision 3: Session-end summary is required before closing.**
|
||||
The CTO must post a structured "end of session" summary any time a session ends with pending or in-progress work. Format: completed this session / pending (awaiting execution) / requires CEO action next session. Alternative considered: optional/best-effort — rejected because the exact failure mode was "session ended without summary."
|
||||
|
||||
**Decision 4: Authorized vs. Done as explicit vocabulary.**
|
||||
Status messages must use unambiguous language. "Authorized" means CEO gave permission. "Committed," "deployed," or "completed" means the action was executed and confirmed. These terms must not be used interchangeably.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- **Risk**: CTO session ends abruptly (crash, timeout) before posting session-end summary → **Mitigation**: CEO checks `#vpe-cto-approvals` at startup for the last CTO message; if it is an authorization request (not a completion), treat the action as pending.
|
||||
- **Risk**: Rules in CLAUDE.md may drift from README.md over time → **Mitigation**: Tasks explicitly update both files; future changes to session protocol must update both.
|
||||
- **Trade-off**: Adding required messages increases CTO session overhead slightly. Accepted — the cost of a missed commit or ambiguous state is higher.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Update CLAUDE.md — add CTO Session Completion Protocol section
|
||||
2. Update README.md Section 4.3 — add session-end checklist and completion confirmation to CTO responsibilities
|
||||
3. No rollback needed — documentation-only change
|
||||
24
openspec/changes/process-governance-handoff-gap/proposal.md
Normal file
24
openspec/changes/process-governance-handoff-gap/proposal.md
Normal file
@@ -0,0 +1,24 @@
|
||||
## Why
|
||||
|
||||
The current CEO ↔ CTO authorization protocol has no completion gate — once the CEO approves an action, there is no required confirmation that the action was actually executed. This was exposed in the last session when the CTO received authorization to commit V&V resolution changes but the session ended before confirming completion, leaving 5 files uncommitted and the field trial status ambiguous.
|
||||
|
||||
## What Changes
|
||||
|
||||
- **Mandatory completion confirmation**: After any CEO-authorized action, the CTO must post a follow-up message to `#vpe-cto-approvals` confirming the action is done — including outcome, commit hash (if applicable), and next state.
|
||||
- **Session-end summary**: Before closing, the CTO must post a structured end-of-session summary: what was completed, what is pending, and what requires CEO action in the next session.
|
||||
- **Authorized vs. Done state vocabulary**: CLAUDE.md and all status tracking must use explicit language distinguishing "authorized" (permission granted) from "committed/completed" (action verified done). These are not interchangeable.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `cto-session-protocol`: Formal CTO session protocol rules — completion confirmation requirement, session-end checklist, and authorized-vs-done state vocabulary — codified in CLAUDE.md and README.md.
|
||||
|
||||
### Modified Capabilities
|
||||
- `engineering-workflow`: Session protocol and CTO communication standards are a subset of the engineering workflow; the workflow spec requires a delta to reflect the new completion gate requirement.
|
||||
|
||||
## Impact
|
||||
|
||||
- `CLAUDE.md` — primary update target; CTO session protocol section added
|
||||
- `README.md` — Section 4.3 (Virtual CTO responsibilities) updated to reflect session-end checklist
|
||||
- No code changes, no API changes, no new dependencies
|
||||
- No breaking changes to existing functionality
|
||||
@@ -0,0 +1,38 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: CTO completion confirmation after authorized action
|
||||
After the CEO authorizes any action via `#vpe-cto-approvals`, the CTO SHALL post a follow-up confirmation message to `#vpe-cto-approvals` once the action is executed. The confirmation MUST include: (1) the action completed, (2) outcome (success or failure), (3) commit hash if the action involved a git commit, and (4) the resulting system state. An authorization message and a completion confirmation are two distinct, required messages — authorization alone does not constitute completion.
|
||||
|
||||
#### Scenario: CEO authorizes a git commit
|
||||
- **WHEN** the CEO posts approval for the CTO to commit outstanding changes
|
||||
- **THEN** the CTO SHALL execute the commit and post a confirmation message containing the commit hash, files committed, and current git state before the session ends
|
||||
|
||||
#### Scenario: Authorized action cannot be completed
|
||||
- **WHEN** the CTO encounters a blocker executing a CEO-authorized action
|
||||
- **THEN** the CTO SHALL post a message to `#vpe-cto-approvals` describing the blocker and requesting CEO guidance — the action remains in "authorized but pending" state until resolved
|
||||
|
||||
#### Scenario: Session ends after authorization but before execution
|
||||
- **WHEN** a CTO session ends before an authorized action is executed
|
||||
- **THEN** the CEO SHALL treat the action as pending (not complete) and re-authorize in the next session before the CTO proceeds
|
||||
|
||||
### Requirement: CTO end-of-session summary
|
||||
Before closing any session that contains completed, pending, or in-progress work, the CTO SHALL post a structured end-of-session summary to `#vpe-cto-approvals`. The summary MUST contain three sections: (1) Completed this session, (2) Pending — authorized but not yet executed, (3) Requires CEO action next session.
|
||||
|
||||
#### Scenario: Session ends with all work complete
|
||||
- **WHEN** the CTO closes a session with no pending authorized actions
|
||||
- **THEN** the CTO SHALL post an end-of-session summary confirming all authorized actions were completed, listing commit hashes where applicable
|
||||
|
||||
#### Scenario: Session ends with pending work
|
||||
- **WHEN** the CTO closes a session and one or more authorized actions were not yet executed
|
||||
- **THEN** the CTO SHALL post an end-of-session summary explicitly listing each pending action under "Pending — authorized but not yet executed" so the next session can pick up cleanly
|
||||
|
||||
### Requirement: Authorized vs. Done state vocabulary
|
||||
All CTO status messages, ledger entries, and session summaries SHALL use unambiguous language to distinguish between permission state and execution state. "Authorized" means the CEO has granted permission. "Committed," "deployed," or "completed" means the action has been executed and confirmed. These terms MUST NOT be used interchangeably in any status communication.
|
||||
|
||||
#### Scenario: CTO reports on a CEO-approved but unexecuted action
|
||||
- **WHEN** the CTO describes an action the CEO has approved but the CTO has not yet executed
|
||||
- **THEN** the message SHALL use the word "authorized" and SHALL NOT use "completed," "committed," or "done"
|
||||
|
||||
#### Scenario: CTO reports on a fully executed action
|
||||
- **WHEN** the CTO describes an action that has been executed and confirmed
|
||||
- **THEN** the message SHALL use "committed," "deployed," or "completed" with supporting evidence (e.g., commit hash, test results)
|
||||
@@ -0,0 +1,36 @@
|
||||
## 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
|
||||
15
openspec/changes/process-governance-handoff-gap/tasks.md
Normal file
15
openspec/changes/process-governance-handoff-gap/tasks.md
Normal file
@@ -0,0 +1,15 @@
|
||||
## 1. Update CLAUDE.md — CTO Session Completion Protocol
|
||||
|
||||
- [x] 1.1 Add a new "CTO SESSION COMPLETION PROTOCOL" section to CLAUDE.md under the CEO APPROVAL GATES section
|
||||
- [x] 1.2 Document the mandatory completion confirmation rule: after any CEO-authorized action, CTO must post a follow-up to `#vpe-cto-approvals` with action, outcome, commit hash (if applicable), and resulting state
|
||||
- [x] 1.3 Document the end-of-session summary rule: before closing, CTO must post a structured summary with three sections — Completed / Pending (authorized but not executed) / Requires CEO action next session
|
||||
- [x] 1.4 Document the authorized-vs-done vocabulary rule: "authorized" = permission granted, "committed/completed/deployed" = action executed and confirmed — never interchangeable
|
||||
|
||||
## 2. Update README.md — Virtual CTO Responsibilities
|
||||
|
||||
- [x] 2.1 In Section 4.3 (Virtual CTO), add completion confirmation and end-of-session summary to the CTO responsibilities list
|
||||
- [x] 2.2 Update the "Claude Session Startup (CTO Role)" block in Section 4.3 to include session-end checklist as a required step before closing
|
||||
|
||||
## 3. Update Engineering Workflow Doc
|
||||
|
||||
- [x] 3.1 In `docs/engineering/08-workflow.md`, add a section documenting the CTO session completion protocol — completion confirmation requirement, session-end checklist, and authorized-vs-done vocabulary — per the engineering-workflow spec delta
|
||||
Reference in New Issue
Block a user