This page is the canonical public snapshot for MyCodexEnv and Delivery Harness Framework. It separates repository source, one machine's active runtime, published documentation, and the proposed independent DHF core. Source available is not runtime active.
English guide Lifecycle flow Skill routingThe audited local main contains the lifecycle router, hooks, guard, evidence schemas, recovery, checkpoint, ledger, transition store, compaction observation, session bearing, context meter, and tier-1/2 behavior evals.
A reversible seven-target promotion produced runtime_promoted; a broader tracked comparison found 24/24 managed files matching source. Codex CLI 0.147.0 triggered the promoted guard in 18/18 isolated host rounds. These are local parity and activity receipts, not production rollout.
GitHub Pages explains source architecture and verification boundaries. A reachable page is not proof that hooks are installed, tests are green, or a particular machine is running the same source.
Staged extraction has a reviewed direction and prerequisite design, but no independent repository, immutable release, tag, or runtime activation is asserted. MyCodexEnv remains the working source and consumer boundary.
| State | Current evidence boundary |
|---|---|
| Repository source | Implemented managed source is anchored to local main; this status refresh remains a working-tree change until separately committed. |
| Fresh verification | Only fresh command receipts in this task count; historical green results do not. |
| Installed runtime | runtime_promoted, seven approved targets byte-match, and the tracked managed comparison is 24/24. |
| Public publication | Not performed in this task. Updating page source is not deployment or public readback. |
| Production enforcement | Not proven. The 18/18 host probe is isolated local evidence. |
| Customer adoption | No verified customer-use evidence is asserted. |
| Commercial validation | No revenue, pricing, conversion, or outcome claim is asserted. |
SessionStart: naming → session_bearing.py. UserPromptSubmit: compaction_probe.py → model_router.py → dhf_preprompt.py. PreToolUse: harness_guard.py. PostToolUse: harness_observer.py.harness_recover.py, harness_checkpoint.py, harness_ledger.py, harness_transition.py, harness_eval.py, schemas, state logs, and fresh four-field verification receipts make work recoverable and auditable.codex/ is repository source. ~/.codex is machine runtime. Promotion is explicit, targeted, reversible, and followed by byte parity plus full verification. Public docs and future independent-core releases are separate publication lanes.| Capability | Source state | Runtime / remaining boundary |
|---|---|---|
| Lifecycle routing and recovery | Implemented with durable source order, dirty ownership, execution lanes, and explicit helper routing. | Recovery is evidence, not permission; runtime config remains machine-specific. |
| Guard and evidence | Guard categories, risk-tier annotations, observer events, split schemas, report and reflection helpers are implemented. | The legacy block shape is host-compatible; a documented command-form secret classifier gap remains. |
| Compaction governance | Shared counter, incremental probe, ordinal-only pressure, transition CAS, W3 checkpoint fields, boundary verdict, and tier-2 agreement eval are implemented. | compaction_probe.py and session_bearing.py exist in the published source; their live deployment is re-verified after every sync rather than assumed. |
| Acceptance and behavior | Requirements validation, tamper-evident ledger, tier-1/2 evals, focused tests, surfaces checks, and a full test runner exist. | A completion claim requires fresh final-suite and environment-verifier receipts from the same change; source or parity alone is insufficient. |
| Simplification profiles | A thin-core / progressive-governance contract exists as a separate implementation direction. | The committed router on this snapshot remains stage-based; do not describe light/standard/governed profiles as active runtime behavior until their source and runtime land together. |
| Independent core | Extraction evaluation and prerequisite design define copy/adapt/exclude, packet, pin, doctor, privacy, and rollback boundaries. | No independent release or upstream pin exists yet. |
Principle: a historical green result is never reused as proof of the current runtime. After any deployment or environment change, DHF re-runs its source tests, file-by-file parity checks, and environment verification before claiming completion.
Every completion claim is backed by a fresh, machine-checkable verification receipt rather than by memory or past status.