CTC Task Portfolio And Original-Plan Alignment Review¶
- Classification:
CURRENT SOURCE/DOCUMENT RECONCILIATION + EXECUTION-GOVERNANCE REVIEW - Status:
DETAILED CURRENT INPUT / PHASE IMPACT NONE - Review date:
2026-08-10 - Analysis-start refs:
qa@0ee9cc91ccee3aee59e0b894e06720ce9d186d84master@d78a88d4395d61df9c9590379ee5bb26facf2d04- Latest concurrent baseline absorbed before final integration:
qa/master@43815e9c299b602df0ec59ca9a289b6e97ff6110 - Current status authority:
docs/ROADMAP.md - Current execution corrections:
Appendix O,Appendix P - Work Graph rule:
.agents/rules/WORK_GRAPH.md - Existing Task profiles:
docs/tasks/WORK_GRAPH_EXECUTION_PROFILES.md - First live pilot:
CTC_WORK_GRAPH_STAGE3_LOADER_SOURCE_PILOT_RESULT.md - Effects in this review: repository documentation and local validation tooling only; Runtime/DB/provider/Wiki DB/service/deployment/physical effects
NONE
1. Executive Finding¶
The CTC Product plan remains coherent, but the existing Task portfolio was not fully compilable under the new Work Graph method.
Product direction
= ALIGNED
Phase/objective decomposition
= MOSTLY ALIGNED
current Phase hold and safety boundary
= ALIGNED
Work Graph runner foundation
= ACCEPTED
first live source/document pilot
= ACCEPTED / SOURCE-RECONCILED
existing 76 Task compatibility with Work Graph before this review
= PARTIAL
existing 76 Task compatibility after this retrofit
= DURABLE PROFILE COMPLETE / EXACT LIVE GRAPHS ACTIVATION-TIME
bounded operational Work Graph pilot
= NOT YET AUTHORIZED OR PROVEN
The target itself is not the problem. CTC still points toward:
- one modular multi-tenant Product;
- Client 1 live safety and Client 2 join readiness;
- explicit process, application, data, access and effect authority;
- React + Next.js + Tailwind on MySQL first;
- process/capability migration with one writer, rollback and caller-zero;
- PostgreSQL only after React + Next.js + MySQL stabilization;
- process-derived Wiki/manual;
- deterministic automation before governed AI action.
The execution defect was the missing bridge among three existing assets:
- detailed Task prose created before Work Graph;
- a current Roadmap that placed P2–P12 on Phase-level hold and removed the old Task-level table;
- a runner that needs explicit charter, capabilities, manifest, DAG, claims, results and closure.
Without a Task-profile layer, future agents would still have to reconstruct the execution graph from memory and long documents, which is exactly the failure Work Graph was introduced to prevent.
2. Scope And Evidence¶
2.1 Inspected authority and implementation¶
The review inspected:
- AGENTS and current document-class authority;
- Context through Appendices O and P;
- Product, Design, Development and current Roadmap direction;
- Project Operations, Phase/Operational tracks, Agent Workflow and Work Graph rules;
- Work Graph skill, runner contracts, node/result validation, closure logic and accepted results;
- Task registry and Task template;
- the complete top-level Task inventory P1-001 through P12-004;
- representative detailed Tasks across every Phase;
- the pre-hold Roadmap sequence retained in Git history;
- the accepted Stage 3 Loader source pilot;
- current
qa/masteridentity and concurrent changes before integration.
2.2 Evidence limits¶
This review did not establish:
- Production deployment identity;
- DB schema/row state;
- current role/menu/API behavior;
- target-role browser acceptance;
- provider/file/device/physical result;
- current
T_WIKI_PAGEcontent; - M3/M4 readiness;
- Product Task or Phase completion.
Stage 3 established a Loader SOURCE_RECONCILED result only. The Task-profile retrofit is documentation governance only.
3. Reconstructed Original Plan¶
3.1 Foundation¶
P1-001~006
-> canonical documentation, repository responsibility,
benchmark input, minimum verification and Wiki foundation
-> P1 accepted
P1 never established current process meaning, Runtime operation, field acceptance or migration readiness by itself.
3.2 Live Product Gate¶
P2-001~006 historical inputs/candidate
-> P2-007 corrective live-tenant Gate
-> user review
-> P2-008 target-role cutover/stabilization
The corrected execution order is P2-007 -> P2-008: the live-tenant candidate Gate precedes target-role UAT and cutover because the earlier result had screen-level inconsistency and a broad role guard caused a Client 1 outage.
3.3 Process Authority¶
P6-001 inventory
-> P6-002 semantic standard
-> P6-007 current portfolio/source reconciliation
-> accepted process slices
-> P6-003 measurable baseline
-> P6-004 deterministic automation boundary
-> P6-005 pilots
-> P6-006 governed AI decision
This order prevents metrics, automation and AI from being built on ambiguous completion/retry/recovery semantics.
3.4 Module And Frontend Preparation¶
P5-001 ownership/caller inventory
-> P5-002~004 contracts/templates
-> P5-005 reference conversion
-> P5-006 waves/caller-zero
P7-001 frontend inventory
-> P7-002/003 shell and UI standards
-> P7-004 reference workflow
-> P7-005 waves
-> P7-006 P12 handoff
P5 and P7 may fan out on disjoint read-only discovery, but both consume current P6 process authority and P2 operational-role evidence.
3.5 Wiki Projection¶
accepted P6 process slice
-> P8-001 coverage/draft/publication readiness
-> templates and role/profile content
-> named publication/readback
-> navigation and old-content retirement
Mapping does not mean publication; publication does not mean target-role usability.
3.6 Runtime And Database Migration¶
accepted P5/P6/P7 packets
-> P12-001 architecture/coexistence contract
-> P12-002 read-only reference
-> P12-003 transactional + worker reference
-> P12-004 capability waves and PHP caller-zero
-> React + Next.js + MySQL stabilization
-> P11 PostgreSQL readiness/pilot/rehearsal/cutover
Starting P11 before P12 stabilization would combine framework, application, process and database migration risks and contradicts the approved plan.
3.7 Repeatability And Expansion¶
measured process/platform/frontend baselines
-> P9 package/onboarding/restore/repeatability
-> third-company no-fork stabilization
-> P10 user-selected post-stability expansion
P10 remains a selection portfolio, not pre-authorized implementation.
4. Alignment Assessment¶
The percentages below are diagnostic estimates, not formal Product completion metrics.
| Dimension | Assessment | Reason |
|---|---|---|
| Product/North Star | 90% ALIGNED |
Modular multi-tenant, process authority, React+Next.js/MySQL-first and later PostgreSQL remain consistent. |
| Phase decomposition | 85% ALIGNED |
P1–P12 responsibilities are coherent and major cross-Phase boundaries exist. |
| Original dependency order | 75% ALIGNED BEFORE / 95% DOCUMENTED AFTER |
Correct sequences existed in Task prose/history; the retrofit restores them as current suspended metadata and profiles. |
| Task status authority | 45% ALIGNED BEFORE / 90% ALIGNED AFTER |
The current hold was clear, but Task files referenced missing individual Roadmap rows. Roadmap/profile/Task authority is now explicitly separated. |
| Work Graph foundation | 90% ALIGNED |
Runner, retrospective fixture and live source pilot are accepted. Operational implementation remains unproven. |
| Existing Task Work Graph compatibility | 30% BEFORE / 90% PROFILE-READY AFTER |
All 76 Tasks now have minimum mode/archetype/predecessor/closure profiles; exact graphs remain activation-time by design. |
| Verification/evidence separation | 85% ALIGNED |
Source/Runtime/role/provider/field/stability states and graph closure boundaries are explicit. |
| Client 1 safety | 75% DOCUMENTED / NOT CURRENTLY FIELD-VERIFIED |
Strong rules and P2-007 contract exist, but current environment evidence was not authorized here. |
| Context/fan-in scalability | 50% BEFORE / 85% DESIGN-READY AFTER |
Stage 3 proved one live source fan-in; profiles/template/validator remove hidden reconstruction for future Tasks. |
Overall:
plan intent: sound
portfolio content: rich but uneven
source-pilot method: proven
existing Task compilation: repaired at durable-profile level
operational method: pending explicit Stage 4 pilot
Product implementation: still on user hold
5. Detailed Defects Found And Corrections¶
F1 — Task files referenced Roadmap rows that no longer existed¶
Most Task headers delegated status/Lane/parallel/dependencies to a Roadmap row. The current Roadmap had only Phase-level hold rows after the global hold replaced the old execution table.
Risk: reactivation from stale prose, numeric ordering or memory.
Correction: Roadmap now contains the suspended Task frontier; the central profile contains exact minimum mode/archetype/predecessor/closure detail. The Roadmap remains the only live activation owner.
F2 — Task registry expected count was wrong¶
The registry said 70. Actual top-level Task documents are:
P1 7 P2 8 P3 9 P4 6
P5 6 P6 7 P7 6 P8 6
P9 7 P10 5 P11 5 P12 4
TOTAL 76
Correction: count fixed to 76 and protected by a local validator.
F3 — Existing Tasks lacked LINEAR/WORK_GRAPH classification¶
Appendix P governed future work but the existing portfolio predated the requirement.
Correction: every Task now has one minimum profile:
- historical inputs:
WORK_GRAPH ON REOPEN; - high-risk structural/operational/migration work:
WORK_GRAPH — MANDATORY; - bounded but still multi-owner work:
WORK_GRAPHwith a strict LINEAR exception test; - P10:
SCOPE DECISION THEN WORK_GRAPH.
F4 — Task template did not compile into runner contracts¶
The prior template was detailed but omitted explicit:
- execution mode/profile;
- Run Charter fields;
- availability versus authorization;
- manifest ownership/disposition;
- node outputs and consumers;
- critical claims and verifier inputs;
- invalidation and targeted retry;
- graph closure versus Task completion.
Correction: a new Section 0 and extensions to stage, verification, effect, ledger and completion sections now cover those contracts.
F5 — Parallelism labels were too coarse¶
possible / conditional / not possible did not describe the exact read-only node groups, the shared authority, the synthesis input counts or the invalidation.
Correction: retain those values as Roadmap hints, but require exact DAG edges and writer ordering in live runs.
F6 — Formerly concurrent Phase work shared authority¶
P2-007, P6-007, P5-001, P7-001, P8-001, P6-003 and P3-005 were not one unrestricted parallel set.
Examples:
- P6-007 owns process meaning and migration readiness;
- P5-001 consumes process ownership;
- P7-001 consumes route/module/workflow facts;
- P8-001 consumes accepted process/role paths;
- P6-003 waits for an accepted P6-007 slice;
- P2-007 can invalidate downstream role/workflow assumptions;
- P3-005 crosses a separate owning repository.
Correction: profiles expose hard predecessors, and live Work Graph runs parallelize discovery while serializing authority decisions and final writers.
F7 — Umbrella Tasks could become report accumulation sinks¶
P2-007, P5-001, P6-007, P7-001 and P8-001 span many families.
Correction: use stable item manifests, family synthesis and cross-family synthesis. Worker results remain external structured artifacts; only integrated durable conclusions enter repository owners.
F8 — Historical COMPLETE could be misread as current evidence¶
Not all old Tasks were written under the current evidence vocabulary.
Correction: completed Tasks are historical inputs. A reopened or materially relied-on Task uses Archetype A current-source/consumer/acceptance revalidation.
F9 — Work Graph source pilot was accepted, but existing Task enforcement was incomplete¶
The Stage 3 Loader pilot already proved manifest/fan-in/writer/verifier/invalidation behavior on a real source task. The remaining gap was not another Stage 3 pilot; it was applying a durable execution shape to the full existing Task portfolio.
Correction: preserve Stage 3 accepted status and record the 76-Task retrofit as a separate documented adoption result.
F10 — Operational implementation confidence remains unproven¶
Source/document success does not prove UI/API/DB/role/provider/deployment execution under Work Graph.
Correction: Stage 4 remains explicitly gated by a new named operational request. No Task is implicitly selected by this review.
F11 — Profile drift needed machine detection¶
A central profile can silently miss a newly added Task or duplicate an ID.
Correction: add validate-task-profiles.mjs and focused tests. It checks the 76-file inventory, one profile row per Task, no extras/duplicates, registry count and authority wiring. It is local documentation validation only.
F12 — Concurrent source changes had to be preserved¶
While this review was being prepared, qa/master moved to 43815e9... with a CRUD/order-sync safety correction and Stage 3 accepted metadata.
Correction: reread remote refs and current authority before final integration; preserve the new CRUD guard and Stage 3 result rather than replacing them with the earlier baseline.
6. What Was Preserved¶
- Roadmap remains the sole live status/activation owner.
- Task files remain durable Product outcome/acceptance contracts.
- Process contracts remain process-meaning owners.
- External run state remains outside Git.
- One final writer uses the current checkout; no node progress branches/worktrees/commits.
- Repository, DB, provider, Wiki DB, service and deployment effects remain separate.
- No GitHub Actions or hosted CI dependency was introduced.
- Appendix O's Phase hold remains in force.
- Detailed existing Task documents were retained rather than mechanically rewritten.
- Operational changes remain inputs and cannot silently advance Phase/process status.
- Stage 3 Loader source evidence remains accepted at its exact
SOURCE_RECONCILEDlevel. - The latest CRUD/user-input safety correction remains in AGENTS and is not weakened by execution governance.
7. Implemented Documentation And Tooling¶
7.1 WORK_GRAPH_EXECUTION_PROFILES.md¶
Contains:
- all 76 Task IDs exactly once;
- minimum execution mode;
- graph archetype A–K;
- current/suspended disposition;
- hard predecessor/input;
- closure evidence expected if activated/reopened;
- cross-Phase dependency graph;
- activation compilation contract;
- graph closure versus Task completion.
7.2 Roadmap¶
Now preserves:
- current Phase hold;
- accepted Stages 0–3;
- completed 76-Task retrofit;
- active mode/profile enforcement;
- Stage 4 explicit-request boundary;
- suspended Task program map;
- critical path and parallel/serialized authority boundaries.
7.3 Task registry¶
Now:
- states 76 top-level Tasks;
- defines Roadmap -> Task -> profile -> external-run authority;
- explains
WORK_GRAPH ON REOPENand profile minimums; - separates Task subdirectory evidence from Task IDs;
- documents the local profile validator.
7.4 Task template¶
Adds:
- mode/profile and trigger evidence;
- charter/capability/manifest/graph/claims;
- invalidation/targeted retry;
- exact output consumers and writer boundaries;
- graph closure separated from completion review.
7.5 Agent startup and skill routing¶
AGENTS, Agent Workflow and Work Graph skill now require:
Roadmap -> exact Task -> execution profile -> fresh external run
7.6 Validator and tests¶
node .agents/skills/ctc-work-graph/bin/validate-task-profiles.mjs
node --test .agents/skills/ctc-work-graph/tests/task-profile-validator.test.mjs
The validator does not inspect Runtime or become a release/Product Gate.
8. Why All 76 Task Files Were Not Mechanically Rewritten¶
Copying static graph sections into every held Task would cause:
- duplicated profile authority across 76 files;
- stale pseudo-graphs before current capabilities/source hashes are known;
- large review noise while P2–P12 remain held;
- repeated synchronization cost whenever an archetype changes.
The correct split is:
central profile
= applies immediately to every existing Task
Task Section 0
= used for new, materially rewritten or explicitly reactivated Tasks
external run state
= exact current graph and execution evidence
Representative high-risk Tasks already contain strong outcome, authority, stage, acceptance and rollback contracts. Their next requirement is activation-time graph compilation, not speculative static duplication.
9. Corrected Program Execution Waves¶
Current Wave — Hold + execution-governance default¶
Complete:
- Work Graph foundation;
- retrospective fixture;
- Loader source pilot;
- 76-Task profile retrofit.
Active:
- mode/profile enforcement for every new/reactivated request;
- Cloud source/document reconciliation within Roadmap scope.
Not authorized:
- P2–P12 implementation;
- DB/role/provider/Wiki DB/service/deployment effects;
- Stage 4 operational pilot without a new named request.
First Product reactivation, only by user decision¶
Recommended first Product Gate remains:
P2-007
Reason:
- Client 1 is live;
- prior broad role guard caused an outage;
- Client 2 join readiness depends on exact role/API/workflow behavior;
- downstream UI/process/Wiki/platform assumptions need current target-role evidence.
P2-007 requires Archetype D and cannot be reduced to a source-only matrix.
Process authority and bounded inventories¶
P6-007 accepted process slices
+ bounded P5-001 discovery
+ bounded P7-001 discovery
+ P8-001 mapping per accepted slice
Read-only discovery may overlap. Registry/lifecycle/shared route/page owner and final integration writes remain serialized.
Acceptance and measurement¶
accepted P2-007 candidate -> P2-008
accepted P6-007 slice -> P6-003
Structural contracts and references¶
P4-002/003 as explicitly activated
P5-002~005
P7-002~004
P8 focused named content
P6-004/005 after accepted metrics/semantics
Select bounded capabilities, not all Phase implementations at once.
Runtime migration¶
P5/P6/P7 accepted packets
-> P12-001
-> P12-002
-> P12-003
-> bounded P12-004 waves
Repeatability, stabilization and PostgreSQL¶
P9 restore/package/no-fork evidence
+ React + Next.js + MySQL stabilization
-> P11
Product expansion¶
Stability/value evidence
-> P10-001 benchmark/selection
-> one selected package
10. Stage 4 Boundary¶
The next adoption stage is not another source pilot. Stage 3 is complete.
Stage 4 requires a new explicit named operational problem spanning at least three relevant surfaces while remaining bounded to one operator outcome.
Minimum graph:
current outcome/candidate anchor
-> environment/account/effect preflight
-> bounded parallel read-only discovery
-> authority/state synthesis
-> one implementation writer
-> independent role/API/data/recovery verification
-> separately authorized Git/deployment/effect Gate
-> observation and calculated closure
The Stage 4 Task must preserve Client 1, prove exact normal/denied/retry/recovery behavior and leave unavailable dimensions BLOCKED/NOT_RUN.
11. Verification Performed For This Package¶
- current
qaandmasterwere reread before integration; - concurrent CRUD/order-sync safety authority was preserved;
- accepted Stage 3 status/result was preserved after a detected stale-baseline conflict;
- changed paths were limited to documentation/rules/Work Graph local validation tooling;
- all 76 Task IDs received one profile row by phase inventory;
- Task registry count was corrected to 76;
- Roadmap/AGENTS/Task template/Agent Workflow/skill/profile links were wired;
- focused validator tests cover complete, missing and duplicate/unknown profile cases;
- no live graph state, node transcript, Runtime, DB, provider, Wiki DB, service or deployment change was introduced.
A full checkout-wide local validation command was not available through the GitHub connector environment. The committed validator supplies that exact local check for any checkout, while remote commit/file/ref readback verifies the stored integration.
12. Final Disposition¶
Was the original Product plan abandoned?
= NO
Was execution following its dependency graph reliably before Work Graph?
= NOT RELIABLY
Was the first live source/document Work Graph pilot complete?
= YES, Loader source pilot / SOURCE-RECONCILED
Was Work Graph fully applied to the existing Task portfolio before this review?
= NO
Does the retrofit reactivate Phase implementation?
= NO
Does every existing Task now have a durable graph-compilation profile?
= YES, 76/76
Are exact live graphs created for all held Tasks?
= NO, intentionally; they require current activation-time facts
Is operational implementation confidence proven?
= NO; Stage 4 requires a new explicit operational request
What is the current execution rule?
= classify every request; use the Task profile and runner for qualifying work; preserve the hold and separate effects
The corrected approach preserves the original Product direction while replacing hidden prose reconstruction with explicit profiles, manifests, fan-in, writer boundaries, independent verification, targeted invalidation and calculated closure.¶
Source:
docs/research/agent-execution/2026-08-10/CTC_TASK_PORTFOLIO_AND_PLAN_ALIGNMENT_REVIEW.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.