The Autonomous Dev Framework has outgrown its own pitch. What began as a multi-agent "self-coding" demo has hardened into the Autonomous Development Protocol (ADP v1.2) — a governed operating system for AI developers, built on a versioned knowledge graph, a strict task lifecycle, and validation gates that make self-assessed confidence irrelevant.

The first generation of ADF Coder treated autonomy as an orchestration problem: give an Architect, a Coder, a Sandbox and a Critic one objective, and let them iterate. It worked — until it didn't. Agents graded their own homework, drifted outside scope, and declared victory at eighty percent. The lesson of the last year is that autonomy is not an orchestration problem. It is a governance problem, and governance has to be enforced by deterministic tooling, not by asking the model to behave.

Governed Autonomy, Not Free-Form Agents

ADP's founding contract is called governed autonomy: the agent may plan, edit and retry freely — inside guardrails that it cannot modify. Every code change passes through 7 rules, in order, each enforced by a script that must print its pass checkpoint before the next rule may run. Crucially, the agent is forbidden from echoing its own checkpoints. The "✓ Changes applied and validated" lines come from the tooling, never from the model, so the transcript doubles as a tamper-resistant audit log.

Failure is formatted just as rigidly: a failed gate prints ✗ what broke followed by→ ACTION: what happens next — then the protocol stops. The agent is never allowed to narrate its way past a red checkpoint, and it never continues to a later rule after an earlier one fails.

The Source Knowledge Graph

Underneath the protocol sits a Source Knowledge Graph — a directory namedsourcecode-base-graph/ holding versioned snapshots v1, v2, …vN of the project's institutional memory. Each version is a full snapshot containing six documents: INDEX.md (navigation hub and version table), ARCHITECTURE.md,AGENT_SYSTEM.md, ISSUES_TRACKER.md, CHANGELOG.md andCONTEXT_PROMPTS.md. Together they answer the questions that used to require re-reading the entire codebase: how the system is built, how the agent should behave, what is broken, and what changed last.

Two rules give the graph its integrity. First, immutability: a promoted version is never edited again — history lives in old versions, current truth lives only in the latest. Second, ledger over memory: issue numbers, target files and version counters are read from the graph, never recalled from the model's context window. An LLM's recollection is treated as a cache at best — and stale caches are invalidated by reading the ledger.

The Strict Task Lifecycle — PROTO-015

Every task that touches code follows the ratified Strict Task Lifecycle Contract(ADP/HEARTH PROTO-015). It has three movements, and it bookends the work with the knowledge graph on both sides:

1. Every task starts at the knowledge base. Load INDEX.md and the issue tracker, bind the work to a tracked issue, validate every target file exists, and snapshot each as a .backup — before a single character of code changes.
2. Governed execution. Changes are minimal, surgical, and consistent with the documented architecture. One issue per run. The validation gate must pass; any failure triggers an immediate rollback.
3. Every task ends at the knowledge base. Promote v{N} → v{N+1} (the old version becomes immutable), resolve the issue, write the CHANGELOG entry, sync the architecture docs, and run the final gate.

The developer-facing surface is two commands:

run_protocol.sh pre                    # Rules 1–3: load KG, bind issue, back up targets
#   ... apply the surgical edit (Rule 4) ...
run_protocol.sh post "summary" "impact" --arch updated
                                       # Rules 4–7: gate, promote v{N+1}, final audit

The contract closes with an invariant that sounds trivial and is anything but:one task = one issue = one version. Batching several fixes into a single "quick" run is a contract violation, because a version that resolves three issues at once can't be rolled back, audited, or attributed — it's the agent-side equivalent of a 3,000-line commit titled "misc fixes".

The Seven Rules, Enforced by Scripts

Each rule has a dedicated enforcement script and a checkpoint that must echo before the next rule may run:

Every Change Binds to a Tracked Issue

ADF refuses to act on vibes. Work items live in ISSUES_TRACKER.md in a machine-parsed format — a ### Issue #N header, a Priority: line from P0 (Critical) to P3 (Low), a Status: line, and a Files: list where every path must actually exist in the repo. Selection is deterministic: the protocol scans P0 → P3 and takes the highest-priority Open issue, using exact-number matching so Issue #1 can never accidentally resolve Issue #10 — and it refuses to touch anything that isn't Open.

If the user's task isn't tracked yet, the protocol registers it first withpre --new "title" --priority P1 --files …, appending a numbered issue to the latest version's tracker (the live ledger) before Rules 1–3 continue. The registration path closes the classic autonomy loophole where an agent "just quickly" edits code nobody asked it to track.

A Validation Gate That Can't Be Charmed

Rule 5 resolves its check command in a strict order: a per-service ADP_CHECK_CMDenvironment variable, then a .adp_check file (one shell command per line, all must pass), then stack auto-detection — tsc --noEmit for TypeScript, compileallfor Python, go vet + tests for Go, dotnet build for .NET, cargo checkfor Rust. If nothing is detectable, the gate doesn't silently pass: it skips with a loud warning telling you to declare a check. A missing local TypeScript compiler next to atsconfig.json is a hard failure with a "run npm install" message — never an interactive npx prompt that an unattended agent would hang on forever.

Placeholder detection matters here too: a package.json still carrying the npm-init "Error: no test specified" script has that script skipped, not executed, so the gate can't be satisfied by boilerplate. The theme across all of these details is the same: every escape hatch that an agent could exploit — or get stuck in — has been deliberately closed.

The Architecture-Sync Gate

Documentation drift is the quiet killer of agent-run codebases, so PROTO-015 adds a second gate after the diff. A conservative heuristic inspects the change for structural edits — new or changed exports, classes, interfaces, routes, or untracked files. A structural diffstops the run until ARCHITECTURE.md / AGENT_SYSTEM.md are updated and post --arch updated is issued — and "updated" is verified against SHA-256 stamps of the docs taken at pre-time, so the copy that promotion performs can't fool the gate. If the diff only looks structural, the agent must file a written justification (--arch none --why "reason") that is recorded in the CHANGELOG next to the change it excuses. Docs can no longer silently rot while the code races ahead.

Failure Is a First-Class Path

When any gate fails, the protocol rolls the targets back from their .backup copies — and keeps the backups, so the documented retry path (re-edit, re-run post, at most once) actually works instead of stranding the agent with no state. Abandoning is equally explicit: a cleanup command removes the tracked backups and the state file. Backup operations are scoped to the tracked target list only, so a user's unrelated*.backup files are never collateral damage. And if the agent discovers a new bug mid-task, it doesn't fix it on the sly — it registers the finding as a new tracked issue so the next run inherits it. Scope creep is converted into bookkeeping.

Wired into the IDE: the HEARTH Bridge

The protocol ships with an integration layer for HEARTH workspaces, so the same lifecycle runs behind hearth task pre <svc> / hearth task post <svc> and the MCP tools hearth_task_pre / hearth_task_post from any editor. Each service declares governance in its ledger — a SVC_KG field pointing at its own knowledge graph and a SVC_CHECK command that becomes the validation gate — and a doctor script warns when a service is either non-governed or carrying a broken graph. The seven rules map cleanly onto HEARTH's 7R loop:

Hardened by Eating Its Own Cooking

Version 1.2 exists because the protocol subjected itself to a formal evaluation and closed every finding. High-severity fixes include removing the npx hang class entirely, detecting placeholder test scripts by parsing package.json instead of grepping strings, scoping every backup operation so foreign files survive the protocol untouched, and making backups fail loudly on a stale or failed copy rather than corrupting a run. The remediation even surfaced a new bug class: under set -o pipefail, acmd | grep -q pipeline reports failure when it matches, because grep -qexits early and SIGPIPEs its producer — a trap now eliminated across all fifteen scripts.

The whole system is covered by a self-test harness that runs the complete lifecycle in a throwaway sandbox repo — bootstrap, issue binding, a deliberately failed run, the happy path, registration, both architecture-gate refusals — and asserts on the checkpoints themselves. Ten assertion groups must pass before the release ships. A protocol about evidence-based completion ought to be held to exactly that standard.

The takeaway: trustworthy autonomous coding doesn't come from a smarter model — it comes from governance that never needs to trust the model's opinion of itself. Deterministic gates, immutable ledgers, evidence over confidence. That is ADF in its current form.