CodeGraph digital employees are accountable delivery roles, not autonomous personas with unlimited access. Each role works within a task, records its own evidence, and hands the result to the next accountable lane. Codex or another compatible agent acts as the operator of those role workflows.
Mental model
A normal delivery has four layers:
- a product requirement in OpenSpec and its linked story or service task;
- a task capsule defining scope, acceptance criteria, owner, and handoffs;
- role evidence for implementation, review, security, QA, docs, traceability, runtime, and cost;
- an authoritative closure decision after all required evidence is present.
The repository root AGENTS.md is the internal routing contract. Repeatable role
procedures live under .agents/skills/sdlc-*/SKILL.md. Current repository state and runtime
behavior take precedence over generated projections or old articles.
Accountable roles
| Role | Accountable outcome |
|---|---|
| Кира / Product Owner | Problem, user outcome, discovery readiness, scope decision. |
| Сергей / Industrial BA | Requirements, constraints, technical assignment, acceptance traceability. |
| Анна / Product Delivery | Plan, task capsule, handoff orchestration, release-readiness report. |
| Дмитрий / Implementation | Bounded code or configuration change and focused test evidence. |
| Рита / Structural Review | Architecture fit, changed symbols, blast radius, regression risk. |
| Вера / AppSec | Security, privacy, secrets, DLP, and publication boundary. |
| Лена / QA | Acceptance checks, regressions, and live or headless validation. |
| Борис / Documentation Memory | Documentation, catalog, bootstrap routing, and memory readiness. |
| Иван / Traceability | Links between requirements, stories, tasks, tests, evidence, and projections. |
| Олег / Support | Grounded answers, known issues, troubleshooting, and operator caveats. |
| Марина / AI Workforce Governance | Role skills, prompts, subagents, approvals, rollout, and drift. |
| Глеб / DevOps and SRE | Runtime, CI, deployment, release engineering, rollback, and publication. |
| Ева / Financial Control | Token, time, cost reconciliation, and financial closure evidence. |
Each role is an evidence authority in its own lane. The accountable owner records each lane’s verdict, and an orchestration summary links to the underlying evidence.
Delivery flow
Product work starts from openspec/changes/<change-id>/; accepted contracts move to
openspec/specs/. Historical PRD files remain migration evidence; write new and changed contracts
under the OpenSpec paths.
The usual flow is:
- Кира and Сергей make the intended outcome and acceptance boundary explicit.
- Анна creates or continues the task capsule and assigns the required lanes.
- Дмитрий implements the smallest tests-first increment.
- Рита, Вера, and Лена review the exact revision and its observed behavior.
- Борис and Иван synchronize documentation and traceability.
- Олег and Глеб cover support and runtime readiness when those surfaces are in scope.
- Ева reconciles final resource use; Анна reports readiness without replacing lane verdicts.
Lightweight service work may use its task as the governance root. Product delivery still needs the linked OpenSpec, story, case, and acceptance scope.
Status and evidence
Passing unit tests confirms the tested behavior. Documentation, security, runtime publication, financial reconciliation, and full SDLC closure each require their own evidence.
An authoritative completion packet must be revision-bound and show final_status_allowed=true,
with no missing lanes or blockers. Generated Markdown, dashboards, and repository projections are
advisory when they are stale, pending, or not protected by compare-and-swap revision checks.
Human approval authorizes the exact transition and scope stated by its signed carrier. Requirements, evidence, lane verdicts, delivery status, and finance remain bound to that scope.
Interfaces and scope
Use the interface that matches the task:
- MCP for agent automation and typed governed actions;
- CLI for local analysis and bounded operator workflows;
- REST or the dashboard for authenticated application operations;
- ACP for compatible IDE and agent-client sessions.
Tool presence depends on the active runtime profile and invocation policy. Discover tools through
the running client, pass native structured arguments, and keep project_key, namespace, task, and
story scope explicit. A working call confirms runtime availability.
Verify one delivery
Before reporting completion, reopen the authoritative status for the same task and revision. Check that every active acceptance criterion has an explicit result, required lane verdicts refer to the current revision, and the final-status decision has no unresolved blocker. Keep these checks separate from accepted handoffs: a handoff confirms ownership transfer, not successful execution.
If the runner is pending or the projection is stale, report the completed work and the missing governance evidence separately. This makes a useful local result visible without presenting it as formal closure.
Limits and next steps
Digital employees do not grant shell, repository, deployment, or publication authority by name alone. Operators remain responsible for credentials, environment access, and the mutation boundary accepted by the user.
Start with the quick start, use the MCP operator guide for runtime discovery, and consult the scenario guide to choose a supported workflow.