Roadmap and Agentic Workflow

Roadmap and Agentic Workflow

The roadmap is a live dependency graph, not a flat backlog. Every managed issue has one milestone, one status/priority/kind/risk, at least one area, one concurrency declaration, test/evidence criteria, documentation impact, and GitHub-native blocker relationships. Native dependencies are authoritative; each issue body mirrors them for humans.

Four phases

Phase	Outcome	Live milestone	Current state
1	Complete executable self-hosted behavior over the minimal kernel	Phase 1	Complete: the generalized evaluator and self-hosted all/any/none/chain/gate are covered by the reviewed executable conformance manifest through #20
2	Make coding-agent evidence reproducible and executable in-session	Phase 2	Complete: verifier runner #23, evidence mapping #24, controller #25, registered repeats #26, in-session adapters #27, and the immutable evidence audit #28 are reviewed and merged
3	Compose and enforce monotonic organization/user policy	Phase 3	Complete: restrictive composition, enforcement, conformance, and scoped expiring waiver application are reviewed and merged through #40
4	Add safe custom syntax and presentation layouts	Phase 4	Complete: #41 through #49 are reviewed, merged, and covered by the executable completion audit

Practical v0 implementation roadmap

The open v0 — End-to-end constrained execution milestone is the practical definition-of-done roadmap. Its 36 fine-grained issues form one acyclic GitHub-native dependency graph:

1. Freeze the end-to-end contract and reference program in #99. Complete: reviewed and squash-merged by PR #135.
2. Complete parsing, type/refinement checking, expression evaluation, ownership/effects, policy and waiver lowering, syntax/profile lowering, extensions, recursion, and semantic-IR audit in #100–#112. In progress: definition parsing #100 was independently reviewed and squash-merged by PR #136, goal/composition parsing #101 by PR #137, governance/profile/extension parsing #102 by PR #138, the complete value/type/refinement checker #103 by PR #139, the total pure v0 wire expression/pattern calculus #104 by PR #140, function/predicate elaboration #105 by PR #141, ownership/resource analysis #106 by PR #142, effect/authority analysis #107 by PR #143, policy/waiver lowering #108 by PR #146, and derived/native extension lowering #110 by PR #145.
3. Build deterministic shared graph identity, obligation/capability/state graphs, proof checking, and cross-graph audit in #113–#118. In progress: the shared typed graph identity/validation boundary #113 was independently reviewed and squash-merged by PR #144, complete structural obligation graph construction #114 by PR #147, and capability decision/provenance construction #115 by PR #149. State construction, generic proof checking, and cross-graph audit remain in the dependent issues.
4. Build planning, scheduling constraints, budget allocation, and deterministic execution graphs in #119–#122.
5. Deliver the capability-bounded executor, atomic state runtime, exact result states, deterministic per-obligation evidence, policy enforcement, and constrained coding-agent runtime in #123–#128.
6. Publish the safe-Rust SDK and complete CLI, make every normative scenario executable, prove the reference program, audit the adversarial boundary, and certify completion in #129–#134.

After capability graph construction #115 merged through PR #149, profile lowering #109, recursion/retention lowering #111, generic proof checking #117, and the post-merge graph-builder feature claim reconciliation #148 have no open native blockers and are eligible only while their declared concurrency tokens are available. State-graph construction #116 still waits on recursion/retention lowering; cross-graph audit #118 waits on all graph builders and proof checking. Planner scheduling #120, executor enforcement #123, and runtime policy enforcement #127 each retain other open blockers despite #115 closing. Readiness is eligibility, not a lock; exact remote claim refs and declared concurrency tokens remain authoritative. Closing a predecessor does not bypass exact-head review, the post-merge audit, or concurrency-token checks.

Completed delivery and evidence-generalization roadmaps

Priority is considered only among issues with no open native blockers and an available concurrency token.

• The original four delivery phases are complete through the Phase 2 evidence audit #28; every issue in milestones 1–4 is closed and marked done.
• The separate Future research — Evidence generalization milestone is also complete without expanding those delivery claims. Reviewed decision #91 froze the repository populations, exact artifacts, one model, arms, 36-session schedule, analysis, exclusions, stopping, billing preflight, and zero-incremental-spend resource budget before any new model turn.
• Positive in-session use #92 completed all 12 sessions with 0/12 registered use and 0/12 acceptance. The paired BHCP-versus-prose/calibration study #93 completed all 24 sessions with 0/12 acceptance in each arm, paired risk difference 0, exact McNemar p=1, and 12/12 conservative claim calibration in each arm. With no discordant outcomes, this is a failure of both representations to induce a repair in the frozen setup—not evidence of equivalence or a general representation effect.
• The Maintenance — Fast required CI milestone is complete through #97. Test-only SHA3/Keccak optimization, a complete-plan validator, six concurrent target partitions, and a fail-closed stable aggregate reduced exact-head protected feedback from 38:01 to about 5:06 while preserving the canonical local all-target gate.

The delivery-safety foundation, independently checkable self-hosted goal algebra, six frozen coding-agent pilots, valid five-session repeat, capability-bounded verifier runner with deterministic evidence mapping, fail-closed experiment controller, executable scoped-waiver contract, audited safe-profile contract, bounded 36-session evidence-generalization record, and fast protected feedback path are merged. The first six managed milestones are complete. Milestone 7 is the open implementation program; stronger external-validity studies remain separate future work.

Status and dependency rules

• status:ready: open and every native blocker is closed.
• status:claimed: authoritative issue/resource refs were atomically acquired.
• status:blocked: at least one native blocker is open.
• status:review: implementation is delivered and locks remain held through review.
• status:done: merged, verified, and closed.
• status:stale: a claim needs evidence-based recovery; it is not permission to steal a lock.

Blocked issues must not be started early. Closing a blocker promotes a dependent issue to ready only after its remaining blockers and resource capacity are rechecked.

Atomic claims

Labels, assignment, and comments are metadata, not locks. Cross-machine exclusion uses unique remote Git refs:

• refs/heads/codex-locks/issues/<number> — one worker per issue.
• refs/heads/codex-locks/mutex/<resource> — exclusive shared resource.
• refs/heads/codex-locks/semaphore/<resource>/<slot> — bounded capacity, slots 1..N only.

The coordinator creates all required resource refs and the issue ref atomically, then changes the label, assigns the worker, and comments with agent/task, timestamp, branch, worktree, scope, ref paths, exact SHAs, and unique nonces. A worker keeps those refs through review.

Release is a compare-and-delete fenced by the acquired SHA. If the lease fails, ownership was lost: do not delete the newer ref. Stale recovery requires inspecting the claim comment, task, branch, worktree, PR, and recent activity, then documenting the decision.

Delivery loop

1. Select the highest-priority ready issue whose concurrency token is available.
2. Atomically claim it and make the metadata match the lock.
3. Work red-first where practical; keep Rust models, CDDL, SEMANTICS, README, conformance fixtures, and wiki claims aligned.
4. Run formatting, Clippy with warnings denied, all tests, release build, and issue-specific evidence.
5. Open a linked PR; move the issue to status:review but retain all locks.
6. Independently review the exact head SHA. Queue or merge only that green, unchanged head with --squash --match-head-commit <reviewed-head-sha>; GitHub rejects author approval and failed required checks keep auto-merge blocked.
7. Close the issue, mark status:done, promote newly unblocked dependents, and release only the exact held refs with fenced deletion.

The reusable project loop is now repository-configured through AGENTS.md and .codex/project-profile.md. Those files are the executable operating contract; this page summarizes them, and live native issue dependencies remain authoritative.