vijay_admin/sentryagent-idp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(governance): add CTO session completion protocol, TBC charter, and process governance OpenSpec change

Browse Source 
- 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
2026-04-07 08:41:12 +00:00
parent 7441c9f298
commit 4e3b989629
12 changed files with 539 additions and 912 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
openspec/changes/process-governance-handoff-gap/specs/cto-session-protocol/spec.md Normal file
View File

@@ -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)

36
openspec/changes/process-governance-handoff-gap/specs/engineering-workflow/spec.md Normal file
View File

@@ -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