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

Completed delivery roadmap and future research queue

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 does not expand those delivery claims. Its ready decision #91 must freeze population, tasks, models, arms, sample and analysis rules, and resource authorization before any new model turn.
• Positive in-session use #92 and BHCP-versus-prose/calibration effects #93 are natively blocked by #91. Their blocked state is the explicit representation of unmeasured empirical work, not an incomplete Phase 2 runtime.

The complete 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, and audited safe-profile contract are merged. The four-phase delivery roadmap is complete; broader language/runtime construction and generalization research remain 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.