Routes work through recovery, specification, implementation, verification, review, release, or handoff.
MYCODEXENV × SHIPQ · DEVELOPMENT HISTORY · 2026-08-16
From business blockage to governed enforcement.
DHF did not begin as a generic process template. It grew from ShipQ delivery pressure: first preserving where work should resume, then proving what actually completed, and finally controlling who may change an external system.
Checks whether a state change has a specification, authority, facts, and a recovery path.
Translates delivery controls into quality, risk, productivity, continuity, and traceability.
01 · CAP / BRIDGE
Three evolution concerns: CAP
CAP names the business concerns that repeatedly forced the harness to become more explicit.
Resume without guessing
Interrupted sessions need durable state, clear ownership, blockers, and one next safe task.
Prove the real result
Business correctness requires source-linked facts, current verification, and artifact readback.
Control real-world effects
Remote writes and protected changes need scoped authority that cannot be recovered from context alone.
BRIDGE · Maturity path
Six stages of evolution: BRIDGE
Each stage removes a recurring delivery failure and raises the evidence required for the next claim.
Recover position
- Value problem
- Interrupted sessions lose ownership, state, and a safe next action.
- Evidence required
- Durable state, clean ownership, and a recovery output that does not invent permission.
Make completion auditable
- Value problem
- Tests and artifacts look complete, but no unified receipt or next safe task can be reviewed.
- Evidence required
- Fresh command, exit code, key output, timestamp, and an append-only checkpoint.
Inspect domain truth
- Value problem
- AI-assisted inquiry intake can guess customer identity, routing, totals, or shipment detail.
- Evidence required
- Canonical schema, source-linked facts, fixtures, manual review, and an auditable correction trail.
Separate core from adapter
- Value problem
- Generic governance and ShipQ-specific quote, workbook, and fixture rules become tangled.
- Evidence required
- Separate DHF core, local runtime, and ShipQ adapter contracts with compatibility proof.
Grade control by risk
- Value problem
- Simple edits and protected mutations receive the same ceremony.
- Evidence required
- Light, standard, and governed profiles with scoped authorization and fail-closed denial tests.
Protect runtime change
- Value problem
- Documented rules can still be bypassed during promotion or external execution.
- Evidence required
- Protected runtime controls, atomic promotion, exact parity, and production readback.
02 · Business pressure
Why DHF follows ShipQ business boundaries
The harness is organized around delivery failure modes, not around repository directories.
Preserve source meaning
Extraction must retain the message evidence, distinguish candidate identity from confirmed customer state, and route ambiguity to review.
Keep pricing deterministic
AI may assist intake and explanation, but quote calculations and acceptance boundaries remain explicit and checkable.
Separate ability from permission
A ready connector or recovered session does not grant authority to send, publish, deploy, or overwrite.
03 · Control and value
SAFE controls the transition; TRUST tests the value
SAFE and TRUST run across the BRIDGE stages. They are not additional lifecycle phases.
Specification · Authorization · Facts · Error-recovery
Defines what completion means, who may advance, which facts are current, and how failure returns to a trusted state.
Trust · Risk · Unit productivity · Service continuity · Traceability
Asks whether the controls create observable delivery value rather than more process.
Control before claim
CAP is the concern, BRIDGE is the maturity path, SAFE governs change, and TRUST evaluates the result.
CAP → BRIDGE × SAFE → TRUST
04 · Observable value
Pain removed, control added, evidence required
Maturity is credible only when each stage names the problem it removes and the evidence supporting the claim.
| Stage | Pain removed | Control added | Observable evidence |
|---|---|---|---|
| Baseline | Lost session position | Session Bearing and durable state | Recovery resumes from a known state without inventing authority |
| Receipts | Completion is asserted without proof | Fresh receipts and append-only checkpoints | Command, exit code, key output, timestamp, and next safe task agree |
| Inspection | AI output can guess domain fields | Canonical schema, fixtures, and manual review | Decisions retain source facts and an auditable correction trail |
| Decoupling | Generic and ShipQ-specific rules are coupled | Core, runtime, and adapter contracts | Compatibility proof preserves domain ownership |
| Grading | Every action receives the same control | Light, standard, and governed profiles | Low-risk work stays light while high-risk actions fail closed |
| Enforcement | Documented rules can be bypassed | Protected runtime promotion | Atomic update, exact parity, rollback, and target readback |
05 · Current maturity
Current maturity and the next proof boundary
The strongest honest claim is not full automation. It is knowing where the system must stop and what evidence is needed to resume.
Recoverable, verifiable, auditable
Repository state, focused controls, receipts, and recovery paths can support bounded source-level claims.
Universal Level 2 execution
This history does not prove that every protected action is autonomously executed or enforced in production.
Observed customer outcomes
Adoption, saved effort, reduced error, and commercial value require separate attributable evidence.
Boundary: source implementation, runtime activation, public publication, production enforcement, and customer outcome remain separate evidence levels.
06 · Evidence
Evidence and claim boundary
This page explains how the framework evolved. It does not grant execution authority or upgrade historical evidence into a current operational claim.
What this page can support
- The six-stage synthesis and its relationship to CAP, SAFE, and TRUST.
- The business pressures that motivated recovery, routing, verification, governance, and enforcement controls.
- The distinction between a mechanism, its verification, and an observed business outcome.
What requires fresh verification
- Current repository and runtime parity.
- Current connector, deployment, publication, or production authority.
- Customer adoption, outcome attribution, and commercial validation.
Claim rule: a source artifact or green test supports only its own evidence level. Higher claims require their own current readback.