Xeo Forge v1.20.0 — Local-First Agent Workbench

v1.20.0 — The Governed Loop

Summary

The agent loop's biggest upgrade since the hardening release. Three pillars,
each one an answer to "what makes frontier coding agents strong?" — and each
one shaped by Xeo Forge's constraint: high autonomy under explicit human
authority.

Pillar 1 — Progress replaced counters

The old stagnation guard asked "did you repeat yourself N times?". That
punishes a legitimate test-fix loop (same two tools, changing results) and
forgives a useless one (alternating two reads forever). The new progress model
asks "did the world change?":

• New files read or changed → progress
• Test outcome flipped (pass↔fail) → progress
• A genuinely different error class → progress (a new failure is information)
• Task state moved → progress

Zero-movement loops are nudged after a window and failed after grace — even
if every call fingerprint looks different. Information gain replaces fixed
read ceilings: 25 genuinely-new files stay un-nudged; re-reading known content
does not.

Pillar 2 — Authority as data

Permissions were scattered across if statements. Now they are ordered rules:

{ action: 'shell', resource: 'git push *', effect: 'ask' }

• Every decision cites its rule — evidence bundles can answer why
• Batch evaluation: a multi-file patch takes the strictest outcome
• Four autonomy levels as real state: read_only · assist · execute · autonomous
  • execute is the default: routine work proceeds, anything leaving the machine asks
  • Publishing (npm publish, docker push, git push) asks even at maximum autonomy
  • Secrets ask at every level; outside-the-workspace asks at every level
  • Universal denies (rm -rf /, mkfs, metadata IP, force-push) survive any override — tested with a grant-everything configuration
• Enforcement is real end-to-end: run args → effective rules → tool context → command executor, which names the denying rule in its error

Pillar 3 — Lifecycle hooks

Anything that must always happen must not depend on the model remembering it.

• audit_pretool: every shell command recorded before execution with its permission citation — blocked attempts are evidence too
• audit_posttool / tool_failure: outcomes appended at the single chokepoint both tool paths share
• guardrail_verify: after successful executions in build mode, claimed files are checked against the workspace — "claimed but vanished" false completions get caught mid-run
• completion_evidence: a deterministic touched-files bundle at finalize

Hook errors never break a run — they become evidence. Every firing lands in
the same seq-ordered stream as everything else: hooks inherit the audit trail.

Direction document

docs/loop-v2.md lays out the full v2 path with evidence tiers
([documented] / [observable] / [inference] / [bench]): explicit AgentState,
checkpoints, governed delegation with budgets and governance trees, best-of-N
with independent judges, dynamic verification contracts, and an execution DAG.
Nothing ships there until its prerequisite proves itself.

Verification

tsc --noEmit clean · lint clean · 805/805 tests (+48 across the three
pillars) · hook timeline labels confirmed in served bundles · permission
enforcement exercised through the executor.