4e3b989629
- 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>
39 lines
3.3 KiB
Markdown
39 lines
3.3 KiB
Markdown
## 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)
|