From ambiguous requests
to verifiable delivery.
These pages explain how Delivery Harness Framework (DHF) turns agentic engineering work into fact recovery, domain and ADR alignment, lifecycle routing, verification evidence, and recoverable handoff. Prompt instructions do not make an agent reliable. DHF is the enforcement layer underneath them: a phase-scoped capability model, hooks that return a real block, and an evidence trail for every guarded decision.
DHF routes decisions before work starts
The public guide now reflects the current skill contract: recover state, classify execution lane, resolve architecture conflicts, choose the specialist route, and finish with fresh evidence.
Local, demo, or production
DHF separates local development, operator live demo work, and customer or production paths so external systems, secrets, deploys, and customer data stay approval-gated.
Architecture checkpoint
When durable sources disagree, DHF captures a decision-focused checkpoint, recuts vertical slices around outcomes, and validates agent-team write sets before dispatch.
Committee loops are explicit
Ordinary review, QA, security, and design routes stay specialized. Committee loops run only when the user asks for reviewers, a revision worker, and a target score.
Compaction governance and rollback prevention
The harness now treats context compaction and runtime deployment as governed control flow: host-observed signals, idempotent successor transitions, and a source transition guard that refuses to let an older source overwrite a newer runtime.
Second compaction is control flow
A host-observed compaction probe with incremental JSONL scanning, an append-only transition store for exactly-one successor tasks, a freshness-aware recovery boundary verdict, and a session bearing hook that injects phase and next safe task at session start.
Old sources cannot overwrite new runtimes
Runtime sync now checks a source transition matrix against a schema-v2 manifest: equal is a no-op, forward requires the pushed remote tip, and stale, diverged, or downgrade transitions fail closed. Deleted files are retained in backups, and the daily refresh is report-only with a quarantined-definition denylist.
Guards that actually block
The live PreToolUse guard emits the enforceable block shape proven by isolated probes, guard decisions carry risk tiers, acceptance criteria live in a tamper-evident ledger, and behavior evals verify recovery, handoff completeness, and successor idempotency.
An agent cannot widen its own blast radius
The guard governs a declared root and keeps the harness install directory protected. An agent may self-declare a work phase to unblock ordinary low and medium actions, but a self-declared phase never unlocks protected roots, and shell-profile, LaunchAgent, and crontab persistence writes stay blocked in every phase.
Source available is not runtime active
Runtime promotion moves a seven-target manifest and is authorized separately from writing the code. The 2026-08-10 comparison found 24/24 tracked managed runtime files byte-identical to repository source, and an isolated Codex CLI 0.147.0 host probe matched the expected guard matrix in 18/18 rounds. Production enforcement is still called unverified, because it is.
What actually makes a multi-step agent dependable
Every mechanism below exists because a demo-grade agent failed without it. This is the map for readers evaluating DHF as an enforcement, permission, and audit layer rather than as a writing style.
Permissions are phase-scoped, not prompt-scoped
Eight lifecycle phases each declare whether repository writes, network, remote access, and subagent dispatch are permitted, plus the minimum gate that phase must clear. Tool categories carry risk tiers, and an unresolved phase falls back to read-only rather than to trust.
High-impact actions wait for a person
Execution lanes separate local work from operator demos and customer or production paths. Runtime promotion, remote pushes, and commits are authorized as their own step, and multi-worker dispatch is intercepted until a write-set decision receipt exists.
Retries must not fan out
An append-only transition store with first-record-wins resolution guarantees exactly one successor task across compaction and restart. Acceptance criteria are content-hashed in a ledger, and a source transition matrix fails closed on stale, diverged, or downgrade syncs.
Recovered state carries a freshness verdict
Session state is an append-only checkpoint log, not a growing prompt. Recovery returns a boundary verdict that is fail-closed when freshness is unknown, and a session bearing hook injects the current phase and the next safe task at session start instead of asking the model to remember.
Every guarded decision leaves a record
Guard decisions, verification runs, and checkpoints are written as schema-validated JSONL evidence with pass, fail, and skip states preserved. Reports are generated from that evidence, so a completion claim can be checked against what the agent actually did.
Designed against the known agentic failure modes
The controls here line up with the OWASP agentic-AI concerns of excessive agency, excessive permission, and unbounded consumption: capability flags bound what a phase may do, protected roots and persistence patterns bound where it may reach, and integrity watch limits bound how much it may read at once.
Learn the framework
Recommended learning sequence: Beginner -> Lifecycle Flow -> Skill Routing Map -> Written Spec. The English path is now self-contained, with the written spec as the exact routing contract.
English Flow Map
A lightweight English lifecycle map showing how DHF moves from fact recovery and requirements through verification evidence and handoff.
Skill Routing Map
The public DHF skill and helper routing map, including domain docs, ADR checks, vertical slices, feedback loops, prototypes, durable briefs, and handoff gates.
For Product & Field Teams
The five guarantees of the harness explained in diagrams — delivery loop, verification receipts, lane gates, long-running work, and forward-only deployments — for readers who will never open the code.
Workflow Skills Matrix
A step-by-step inventory of every current DHF workflow step, the skills it uses, what each skill does, and the GitHub source link for each skill.
Written Routing Spec
The source-of-truth lifecycle guide for stage ownership, specialist skills, runtime helpers, agent briefs, evidence standards, and completion gates.
Share or switch language
Use these when the reader needs a presentation asset or the Chinese version of the same guide.
For maintainers
These are useful after the public concept is clear. They should not compete with the learning path.
Harness Runtime
The implementation contract for workflow state, helper scripts, evidence, checkpoints, permissions, hooks, and agent teams.
Classic Skill Map
Archive only. The older English visual remains available for comparison, but the status-style Skill Routing Map is the primary public path.