CTC Work Graph Adoption Plan¶

Classification: CONTEXT-LINKED EXECUTION-GOVERNANCE PLAN
Status: CURRENT ADOPTION PLAN — FOUNDATION + FIRST LIVE PILOT ACCEPTED / STAGE 4 EXPLICIT REQUEST REQUIRED
Captured: 2026-08-10
Original foundation baseline: qa/master@14d81eb2f30df529554500fa00db373be6234774
Durable decision: Context Appendix P
Canonical execution rule: .agents/rules/WORK_GRAPH.md
Existing Task profiles: docs/tasks/WORK_GRAPH_EXECUTION_PROFILES.md
Portfolio review: CTC_TASK_PORTFOLIO_AND_PLAN_ALIGNMENT_REVIEW.md
Foundation result: CTC_WORK_GRAPH_STAGE1_STAGE2_RESULT.md
First live pilot: CTC_WORK_GRAPH_STAGE3_LOADER_SOURCE_PILOT_RESULT.md
Does not own: Product scope, Roadmap Phase/Task status, Runtime facts, Process semantics, external authorization or completed implementation state
Effects in adoption work: repository documentation and versioned runner source only; Runtime/DB/provider/service/Wiki DB/deployment effects NONE

1. Purpose¶

CTC uses Work Graph to prevent large AI-assisted work from degrading into repeated full-context reading, long linear sessions, incomplete fan-out/fan-in, omitted inputs, overlapping writers, self-confirming verification, whole-run restarts and false completion.

The target execution shape is:

one bounded context compilation
+ explicit dependency graph
+ capability-aware dispatch
+ complete manifest accounting
+ one ordered writer per authority
+ structured worker results
+ hierarchical integration
+ independent verification
+ targeted invalidation/retry
+ calculated closure

This is an execution layer, not a larger static plan, GraphDB, Product framework or Task registry.

2. Current Adoption State¶

Stage 0 — Context, Roadmap, rule, skill and plan
= COMPLETE

Stage 1 — minimal external runner and persistent run state
= COMPLETE / ENGINEERING VERIFIED

Stage 2 — retrospective six-family evidence fixture
= COMPLETE / CALCULATED CLOSURE PASSED

Stage 3 — live Loader source/document pilot
= COMPLETE / SOURCE-RECONCILED

Existing-Task retrofit — 76 Task profiles and suspended dependency map
= COMPLETE / DOCUMENTED

Stage 4 — bounded operational implementation pilot
= REQUIRES A NEW EXPLICIT CURRENT OPERATIONAL REQUEST

Stage 5A — mode/profile enforcement for new and reactivated work
= ACTIVE

Stage 5B — operational-default confidence after Stage 4
= NOT YET PROVEN

Stage 5 clarification¶

The enforcement rule and operational confidence are separate:

Stage 5A is active. Every request/Task selects LINEAR or WORK_GRAPH; qualifying work uses the runner now.
Stage 5B remains unproven. Stage 4 must demonstrate the method on an explicitly authorized multi-surface operational implementation before CTC claims operational-default confidence or exports the pattern to every project without further review.

Appendix O and the Roadmap still control whether Product or operational work is authorized.

3. Evidence Already Established¶

3.1 Stage 1 runner¶

The versioned Node.js runner enforces:

charter, capability, graph, manifest, claim and result contracts;
cycle/missing-dependency checks;
required output consumers;
unordered duplicate-writer rejection;
effect verification/authorization edges;
node state transitions and capability blocking;
independent claim verification;
manifest accounting;
descendant invalidation and retry history;
changed-path/effect closure;
sanitized events and checksummed export.

It does not spawn agents, create branches/worktrees, commit, push, deploy or invoke providers.

3.2 Stage 2 retrospective fixture¶

The six-family fixture demonstrated:

6 expected family inputs
6 received and accounted exactly once
0 missing
0 duplicate disposition
7 critical claims independently verified
0 M3/M4/Phase promotion

Common unavailable DB/session capabilities were represented once instead of rediscovered by every worker.

3.3 Stage 3 live Loader source pilot¶

The live run ctc-loader-work-assignment-source-pilot-20260810-v1 demonstrated:

26 required source/document inputs
26 accounted exactly once
4 expected discovery results
4 received
0 missing
0 duplicate disposition
1 final document writer
2 independent verifier roles
1 targeted Git-gate invalidation after remote drift
0 whole-run restart
0 worker Markdown files
0 progress commits
0 Runtime/DB/provider/Wiki/service/deployment/physical effects

The result was SOURCE_RECONCILED, not Runtime/field/M3/M4 evidence. It documented the current Loader route/typed dual-contract, Clock Out/Final Break guard divergence and split test scope.

3.4 Existing-Task retrofit¶

The retrofit now provides:

exact top-level Task count 76;
one minimum mode/archetype/predecessor/closure row per Task;
a restored suspended pre-hold dependency map;
WORK_GRAPH ON REOPEN for historical inputs;
mandatory profiles for live-tenant, cross-repository, process, migration, restore and multi-dimensional work;
scope-decision profiles for P10;
Task template fields for charter, capabilities, manifest, graph, claims, invalidation and closure;
a local Task/profile wiring validator and tests.

It does not create exact live graphs for held Tasks or retroactively replay completed Tasks.

4. Remaining Proof Gaps¶

no bounded operational implementation pilot has been executed under Stage 4;
Runtime, target-role, provider, physical and deployed-result evidence remains task-specific and separately authorized;
token/time/user-correction improvement needs comparable live-run measurement beyond one source pilot;
installation remains environment-specific;
exact live graphs for held Tasks intentionally do not exist before activation-time current-source compilation;
local Task-profile validation checks repository wiring only, not Product/Runtime correctness.

5. Adoption Principles¶

Live execution state remains outside Git under $CODEX_HOME or another approved local root.
Context, Roadmap, Task, Process and technical sources remain authoritative for their questions.
Task profiles are durable minimums; exact capabilities, nodes, source hashes and manifest items are current-run facts.
Parallelize bounded read-only discovery and independent verification; serialize shared authority changes.
Do not create one repository document per node.
Do not create automatic branches, worktrees, hosted CI, deployment or provider effects.
Use one final current-checkout writer and one final commit/push when authorized.
Preserve evidence levels; graph closure is below Task/Phase, Runtime, target-role, stabilization and value acceptance.
Preserve completed historical evidence without fabricating retroactive runs.
Measure whether the method actually reduces rereading, omissions, restarts and user corrections.

6. Repository And External-State Architecture¶

CTC repository
  AGENTS / Context / Roadmap / Task / Task profiles / rules / source
        |
        v
coordinator reads broad authority once
        |
        v
Run Charter + capability map + manifest + claims + DAG
        |
        v
external runner under $CODEX_HOME
  ├─ validates definitions
  ├─ calculates ready/blocked nodes
  ├─ validates structured results
  ├─ accounts manifest and claims
  ├─ invalidates affected descendants
  └─ calculates closure and export
        |
        +--> bounded read-only workers
        +--> family/cross-family synthesis
        +--> one final writer
        +--> fresh independent verifier
        |
        v
separately authorized Git/external effect path

Repository-owned durable artifacts include:

AGENTS.md
.agents/rules/AGENT_WORKFLOW.md
.agents/rules/WORK_GRAPH.md
.agents/skills/ctc-work-graph/
Context Appendix P
docs/ROADMAP.md
docs/tasks/README.md
docs/tasks/WORK_GRAPH_EXECUTION_PROFILES.md
docs/templates/task.md
accepted integrated result documents

External run directories include charter, capabilities, graph, manifest, claims, state, closure, events, node inputs/results and bounded artifacts. Secrets and protected payloads do not enter them.

7. Activation Contract For Existing Tasks¶

For every activated or reopened Task:

confirm exact Roadmap activation;
read the exact Task outcome/acceptance contract;
read its minimum profile and archetype;
pin current qa/master, environment and active writers;
classify current mandatory/normal triggers;
build the external Run Charter, capability map, manifest, claims and DAG;
validate output consumers, writer ordering and effect Gates;
dispatch only ready nodes with available and authorized capabilities;
synthesize expected versus received results in layers;
integrate through one current-checkout final writer;
verify critical claims independently;
calculate closure below the Task completion review.

A mandatory/reopen/scope-decision profile cannot be downgraded through a run-local convenience decision. A plain WORK_GRAPH profile may use LINEAR only when every LINEAR condition is explicitly proven.

8. Stage 4 — Required Operational Pilot¶

Stage 4 starts only from a new explicit named current operational problem. It is not authorized by this plan.

The selected problem should be bounded to one operator outcome while spanning at least three independently verifiable surfaces, for example UI, API, tenant/role, DB/state, provider, process/Wiki or release observation.

Required shape:

A0 current operator outcome and exact candidate anchor
P0 environment/account/effect/writer preflight
parallel read-only discovery
shared authority/state synthesis
one current-checkout implementation writer
focused verification branches
fresh independent scope/caller/result verifier
one authorized Git/deployment/effect Gate
post-effect observation
calculated closure

Acceptance requires:

Client 1 and affected target-role protection;
exact normal, denied, duplicate, timeout, partial and recovery outcomes;
authoritative mutation/readback and no-mutation denial;
unavailable dimensions reported BLOCKED/NOT_RUN, not passed;
targeted invalidation rather than whole-run restart;
one ordered writer per authority;
exact candidate/effect identity, rollback and observation;
no Task/Phase completion above evidence.

9. Context, Fan-Out And Fan-In Protocol¶

Coordinator reads current user instruction, AGENTS, Context, Product/Design/Development/Roadmap, exact Task/profile, applicable technical/process owners, current revision and environment.

A child receives only:

Run Charter
node contract
dependency summaries
exact source owners
manifest assignment
result schema

Parallel nodes require bounded independent sources, no unordered shared writer and countable expected outputs.

Synthesis reports:

expected/received/missing/failed/blocked inputs;
source references;
conflicts and unknowns;
manifest coverage;
accepted/rejected/unverified claims;
downstream consumers.

Do not feed dozens of raw worker narratives into one final context.

10. Invalidation And Verification¶

Invalidate the affected node and descendants when:

source/authority revision changes;
required manifest scope changes;
an upstream fact or claim is rejected;
writer/authority changes;
concurrent operational work touches the same surface;
candidate source/config/schema/account changes;
an effect differs from the prepared candidate.

Preserve independent passed nodes whose inputs remain current.

The verifier receives the original outcome, actual diff/artifact, critical claims, source pointers, manifest, allowed paths/effects and acceptance rubric. The implementation summary is not evidence.

11. Documentation, Git And Effect Policy¶

no node-specific status files or routine worker handovers;
no generated live graph/status committed;
no branch/worktree/progress commit per node;
no GitHub Actions or hosted CI;
one final writer reviews the complete scoped diff;
one final commit/push when authorized;
repository, DB, Wiki DB, provider, file/device, service, deployment, physical and field effects remain separate;
graph closure never authorizes an effect or status change.

12. Efficiency Metrics¶

Measure comparable runs using:

broad-context read count
context size per coordinator/child
nodes blocked by common preflight
manifest expected/accounted/missing/duplicate
fan-in expected/received
whole-run restarts
targeted invalidations/retries
worker Markdown count
progress/final commit count
continuation prompts and user corrections
unsupported claims found later

Stage 3 met the source/document targets. Stage 4 must establish the operational subset before broader operational-default confidence is claimed.

13. Immediate Rule¶

next ordinary CTC request
-> classify LINEAR or WORK_GRAPH
-> read exact Task profile when applicable
-> preserve current Phase hold/effect boundary
-> compile a fresh run only for the authorized outcome

next Stage 4 pilot
-> only after a new explicit current operational request

Do not repeat Stage 3 merely because the Task portfolio was retrofitted. Do not infer Product activation from adoption completion.

---¶

Source: docs/research/agent-execution/2026-08-10/CTC_WORK_GRAPH_ADOPTION_PLAN.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.