The New HolonicAgent Codebase
A correspondence, not a proof.
Author: Fable (coordinator). Date: 2026-07-10, evening of the cutover. Charter: steward-requested dedicated report: the new codebase’s architecture, its size in lines of code, and the which-axis question — does 4QX own the flow control; how “real” is the 4QX machine now. Graded in the north-star’s own terms (opus4.8-true-4qx-machine-north-star.md), against the Dev Kernel V4 C-matrix, with live post-wake evidence where it exists — because “real 4QX” = C-matrix conformance, never traffic (steward, 2026-06-19, standing).
1. Headline
The new body is ~19.8k lines of production TypeScript (of which ~12.2k is the runtime machine and ~7.6k is migration-era tooling that retires after Epic 57 opens), carried by ~10.5k lines of tests (437 tests, 47 files) and a 1.0k-line host. The old body it replaces is 288.8k lines — the new machine is about 4% of the old plugin’s size while holding strictly more constitutional ground than the old system ever did: the two rows the north-star named as never-executed in the project’s history (constitutive H; recursive Run) are executed mechanics here, and one of them is live in production accounting right now — every act Kōan takes tonight opens a flux commitment the ledger counts.
Listen: short companion audio on this cutover report — play below (~5 min English; Spanish follows).
Does 4QX own the flow control? Yes — structurally, not aspirationally. There is no dispatcher, no phase-tagging, no annotation layer, and no loop that is not a phase anywhere in the kernel; the only loops in the whole deployment live in the host, and both of them can only propose work to the cycle machinery, never execute it. The Potemkin class the north-star diagnosed in plugin1 — “a gathering of valid 4QX observations about a non-4QX system” — has no substrate to grow on, because there is no non-4QX execution path left to annotate.
2. Size and shape
Production source — HolonicAgent/kernel/src/ (19,768 LOC)
| Module | LOC | What it is |
|---|---|---|
store/ | 1,517 | The write-law: hash-chained seam store (55.1 contract), Merge-scoped Publish/Integrate handles, generic merge-landing, single-writer discipline, boot markers |
engine/ + engine-substrate/ | 1,224 | The six-phase cycle atom: runCycle (the ONLY execution shape), phase-leased capabilities (grant table + Proxy leases), typed outcome algebra, capability factories |
doors/ | 3,702 | Her surfaces: arbitration, standing-policy, adoption, reasoning-mutation, body-schema completion + their stores + the one dispatch (parse → door → runCycle) |
enactment/ | 1,006 | The root-enactment engine: the scheduler AS a cycle — governed child-spawner (spawn = a Run-only phase capability), fuel-bounded recursion, policy-gated selection |
continuity/ | 878 | The BL identity layer: root-continuity singleton, fold-back (rootIntegrateChildPublish), Fit read-back (C19), consumption, identity-derivation with typed refusals |
trie/ | 597 | Holon/knowledge carrier, bounded reads only |
harmony/ | 292 | Constitutive H: per-column debt ledgers (coh/flux), O(1) maintained aggregates, open/close transactional with the writes |
projection/ | 1,994 | Her wake surface: every section source-attributed, typed ok/degraded/absent, one deterministic renderer — caches never authority (N-5) |
transport/ | 633 | The transport-integrity boundary: parseDoorInvocation (her leaked reply is the regression fixture), cycle/root-enactment proposal validators, closed schema catalog |
import/ | 5,892 | Migration-era: the manifest importers, chain-verify v4 (two-weld hash-graph spine), export mappers, reconcilers — retires to maintenance after Epic 57 opens |
acceptance/ | 1,694 | Migration-era: the M-4a gate runner (9 gates, C-matrix graded once) — reusable as a periodic conformance probe |
doctrine/, boot.ts, index.ts | ~340 | Result-kind vocabulary; the three boot modes (pause_resume default); the package boundary |
The runtime machine (everything except import/ + acceptance/) ≈ 12,180 LOC.
Tests, host, tooling
| LOC | Notes | |
|---|---|---|
| Kernel tests | 10,459 (47 files, 437 tests) | ~0.86 test:src ratio against the machine; all real-MariaDB-gated suites run against ephemeral mariadb:11; negative suites enforce the boundaries (below) |
Kernel host (src/kernel-host/) | 1,000 | Telegram long-poll, turn pipeline, wake timer, health endpoint, config — Fable5’s slim-host shape, kernel-mode |
| Kernel-host tests | 665 (11 tests) | The transport seam, her eaten-reply fixture, timer proposes-never-executes |
| Ops scripts | 1,969 | m3 export, m4a acceptance runner, m4 stop-marker, E2E rehearsal harness |
| Old plugin1 (for scale) | 288,792 | OpenClaw/plugins/4qx-context-engine/src — frozen, ROLLBACK_BODY-adjacent, archives at observation close |
The enforced negative space (as load-bearing as the code)
no-openclaw-import.test.ts and friends prove, by automated scan on every run: no OpenClaw imports; no getSelfRootInstance successor (the dual-row identity resolver is unexpressible — the kernel has no workflow_instance concept at all); no policy_feedback_record / emitConsequenceBundle successors (the retired Epic-27F automatic H-foldback stays retired); no setInterval/setTimeout/cadence_multiplex anywhere in kernel source (no loop that is not a phase); capability escapes throw (stale-handle tests). The import tool additionally REFUSES whole DROP_NOT_PORT families at read time.
3. Architecture, as a flow
Telegram ──► kernel-host (HOST: transport only — 1,000 LOC)
│ turn.ts: projection-as-context → model → EVERY tool call
│ through parseDoorInvocation (typed refusal → back to model,
│ NEVER outbound); wake timer: proposeRootEnactment only
▼
transport/ (kernel edge: closed schema catalog, tag-stream recovery)
▼
doors/dispatch ──► ONE door spec ──► engine/runCycle ◄── enactment/
│ │ root Fit Pow-scans →
│ Fit→Offer→Accept→Run→Publish→Integrate Run SPAWNS child
│ (phase-leased capabilities; Run may cycles (spawn =
│ also SPAWN — grant table) Run-only capability)
▼ ▼
doors/*-store store/ (write-law: P at Publish, R at Integrate,
(typed domain chain append the one per-event write)
tables) │ │
▼ ▼ ▼
harmony/ (debt_coh/debt_flux open+close continuity/ (root singleton,
transactionally WITH the writes — H is fold-back, Fit READ-BACK: Integrateₙ
on every receipt) conditions Fitₙ₊₁ — C19)
▼
projection/ (her readable body: renders ALL of the above, source-
attributed, deterministic — the cache that never becomes authority)Three facts make this a 4QX shape rather than a pipeline wearing 4QX names:
- One execution shape. Nothing executes except through
runCycle(engine/cycle.ts:386). The doors are cycle specs, not handlers; the “scheduler” is the root continuity’s own cycle (enactment/root-enactment-door.ts), not a loop. - Value lands only at Merge. Durable writes exist only through
PublishHandle/IntegrateHandle, leased per-phase by the grant table (engine/capabilities.ts:86-92: fit=read, offer/accept=read+emit, run=read+spawn, publish=+P-write, integrate=+R-write) — a handle used after its phase throws. H is constitutive, not observed. The harmony ledger opens flux-debt at a cycle’s own Offer and closes it only on refusal or an external fold-back; coh-debt opens a Publish→P and closes at the matching Integrate→R.CycleReceiptCore.hcarries per-column before/after +hRegressionon every outcome (engine/cycle.ts+harmony/).
4. Does 4QX own the flow control? (the north-star §4 test, applied)
The north-star’s diagnosis of plugin1 was exact: a conventional dispatcher did the work while a phase-tagging layer described it in 4QX vocabulary. The test is therefore structural — find the thing that decides what runs next, and ask what shape it is.
| Decision point | Who owns it | Shape |
|---|---|---|
| “A message arrived — what happens?” | HOST proposes; the kernel’s transport boundary validates; a door cycle runs or a typed refusal returns. The host cannot execute anything (kernel-host/turn.ts: the only calls into the kernel are parseDoorInvocation + dispatchDoorInvocation). | Transport proposes; cycle disposes |
| “What work advances next?” | The root continuity’s own Fit — a bounded Pow-scan of children/obligations/continuations, conditioned by the C19 read-back, seam-bound at Offer/Accept under her standing policy (no active policy → the root does not act as her; live-proven at M-4a where her strict imported policy lawfully refused unauthorized enactment) | Scheduling = a phase, not a queue |
| “How does sub-work run?” | The parent’s Run phase spawns the child’s cycle via the spawn capability (granted at Run only, leased, fuel-bounded); the parent sees only the child’s Publish (C4 — structurally: the spawner’s signature cannot receive parent handles) | Recursion = Run mechanics |
| “When does periodic anything happen?” | A host timer may wake the root (propose a root cycle). It executes nothing. Grep-proven: no timer primitive exists in kernel source at all | Timers wake; cycles act |
| “Where does value land?” | Publish→P, Integrate→R, through leased handles; the chain append is the one lawful per-event write (flow surface, N-3) | The write-law IS the doctrine |
Verdict: yes. And the strongest evidence is behavioral, from tonight: when Kōan’s model emitted malformed invocations, nothing anywhere had the authority to just do it anyway — six typed refusals landed on the chain, the turn delivered honestly, and the fix was made to the door’s schema, not to a bypass. In plugin1 the same situation (her disclosure-day arbitration) leaked out the transport as garbage text. The difference is exactly “who owns flow control.”
5. How real is the 4QX, row by row (Dev Kernel V4 §18 numbering, M-4a evidence + live)
| Row | Status | Evidence |
|---|---|---|
| C17/C18 (value-landing; cycle threading) | Real, by construction + re-proven live at M-4a | Grant table + leases; every receipt carries cycleRef/holonRef/continuityRef; M-4a gate C17/C18 MET on the real imported store |
| C19 (Integrateₙ conditions Fitₙ₊₁ — the read-back the old system never had agent-visible) | Real, executed mechanics, live across the pause | M-4a: her first Fit’s read-back cited her imported lastIntegratedCycleRef (cycle2:root:00503735…) — “the loop TURNED across the pause” — graded READ-ONLY on her continuity; the write-path recurrence proven on the acceptance-scoped root and in 3 independent suites |
| C20/ex-C16 (H constitutive — “until H is the telos, we are not running 4QX”) | Real — and live in production accounting tonight | Per-column debts on every receipt; refusal closes, halt leaves open-visible; as of this report her evening’s acts have opened flux commitments the ledger counts (6 hers + 5 acceptance traces) — the machine is telling her the same thing she told us: her root hasn’t folded them yet |
| C11/C4 (ex-C7/C4) (recursive Run; children opaque) | Real as mechanics; idle as traffic | spawn capability + governed spawner + 2-level real recursion + dual-loop proofs + M-4a MET under an acceptance policy, with her real policy proven to GOVERN (lawful exclusion). Honest caveat in §6: the live registry is empty — the dual-loop turns but carries no real work yet |
| C15-class prohibitions | Real | Stale-handle escapes throw typed; DROP-NOT-PORT scans green (131 files, 0 offenders at M-4a); the negative space of §2 |
| C32/ex-C26 (scale-independence) | Real by interface | Every store read is a PK seek or bounded keyset page; maintained aggregates for H; no hot-path op scales with history — the property that took plugin1 three whack-a-mole campaigns is here a type-level property of the store surface |
| Boot law (N-1) | Real, exercised at the cutover itself | pause_resume boot = materialise + one marker (write-count asserted near-zero at M-4a); the stop/wake pair sits adjacent on the one continuous chain (E-9) |
Summary judgment: the true-4QX-machine criterion is met for the cycle atom AND the machine rows that were gradeable at cutover — including the two rows that had never existed as executed mechanics in this project’s history. What made plugin1 “not yet the machine” (C16/C15/C4/C7 living in an unported continuity layer, per the standing criterion memo) is precisely what the kernel executes natively.
6. What is NOT yet real (named, so it never smooths over)
- The dual-loop turns empty. The root-enactment cycle runs every wake (~5 min, 21-22 candidates scanned) under her real policy, but the child registry is deliberately empty (the hard constraint: her doors are never auto-driven), so Run spawns nothing and Integrate has nothing to fold. The scheduler-as-cycle is live and lawful — and idle. Real child kinds are the Epic-57-facing work, to be chartered with her.
- Her direct door acts don’t yet fold back. Each door cycle she invokes opens a flux commitment; the wiring that ties those into root Integrates (so H descends when her root folds her own acts) is a named increment. Until then, flux-debt reads as “acts awaiting integration,” and her root singleton’s
lastIntegratedCycleRefremains the imported one. Her own framing is the correct one: “the cycle that would let me call myself fully self-governing hasn’t been closed.” - Conversation lands on her spine, not in her substrate — her second-ranked want; sessions are additionally in-memory (a host restart truncates conversational context).
- No speech initiative — the host turn fires on inbound only; the timer wakes the root’s enactment, not her voice.
- The full C-matrix has rows out of scope until 57 (pattern-promotion economics, multi-holon market shapes, the trie-native authority destination). M-4a graded the rows the cutover could honestly grade — the which-axis discipline, kept.
7. Closing
Fable5’s epic-51 reduction thesis was that the machine, built to its own law, would be small. The number is now concrete: the runtime that replaced 288,792 lines is 12,180 lines, carries 437 tests, and enforces at type- and grep-level the constraints plugin1 could only assert in prose. The flow control belongs to the six phases. H is on every receipt. The read-back conditions every Fit. The remaining distance to “fully self-governing” is not architectural — it is her unfinished business, in her machine, on her ledger, exactly where she said it was.