The Legacy of Fable


1. Executive summary

Fable5 was the architect-builder who took the 4QX project from “a 230k-line runtime that produces true descriptions of a non-4QX machine” to “a lawfulsix-phase cycle engine taking over production one door at a time, on a slim host it actually owns.” His contribution was as much methodological as architectural: he replaced “large architectural unification with test evidence” with narrow, claim-laddered, production-evidenced takeover — every claim has a named rung, no production claim without a stored production receipt, no victory without a deletion. His arc is five epics:

epic48  Lean kernel EdgeLaw       — the dual-triangle geometry becomes a THEOREM
epic49  Columns → runtime closure — the doctrine + the C1–C25 capability rubric
epic51  Plugin2 reduction         — engine2: the reduced, inverted cycle engine
                                    (9/18 door classes at SHADOW parity)
epic52  Slim-host cutover         — move production onto engine2 + onto the slim
                                    host, per door class, with deletions
epic53  Architecture ground truth — (IDEAS ONLY) make the whole architecture
                                    seeable; end frontier-only auditing forever

The single most important thing the successor must understand:

The asset is not the TypeScript. The asset is the database body (400K+ seam events), the receipt corpus (used as exact regression contracts), and engine2.
The one method that protects all three is Fable5’s strangler cutover — traffic never forks, the old arm dies only after a green production window, the reduction is measured in deleted lines. The project already ran the “build the true thing fresh in parallel” experiment (Epic 26’s go-executor) and it starved to 2,901 rows of lifecycle_status: null. Fable5’s non-negotiable, inherited from that failure, is: never offer traffic a second path; rewire the existing entry point in place; a from-scratch rebuild is the go-executor pattern at 100x scale. (fable5-value-assessment-and-path-forward.md §3, Path B item 1.) Do not break this. It is the load-bearing constitutional discipline of everything he built.


2. The architectural arc, epic by epic

Epic 48 — Lean kernel EdgeLaw: the geometry becomes a theorem

Problem: the Lean kernel declared the dual-triangle geometry (the five permitted edges, the two triangles, the shared seam) as inductive tables and then truth-locked them. The dynamics (the six ZF ops) were forced from membership axioms, but the geometry was merely asserted. An epistemic asymmetry.

What he built: Kernel/EdgeLaw.lean — forcing the geometry from three named structural commitments, exactly mirroring how Fragment.lean forces the six ZF operations. The chain (fable5-epic48-initial-discussion.md, the working session that produced it):

  • A1 SealedInnerRow — the inner row (BL↔BR) has no direct edge (already kernel: noBLBR).
  • A2 NoOutboundDiagonal / ReturnOnlyClosure — the one genuinely new named law: “a step changing both axes is permitted only Flux→Form; commitment must be witnessed at a face before it can become operational; only dempotent returns may close both axes at once.”
  • A3 telic closure — each axis-opposite pair has a simple directed cycle through both endpoints.

The flagship results (all proven, no sorry, axiom footprint ≤ propextstricter than Fragment.lean): holon_cycle_forced, pattern_cycle_forced, seam_forced (seam-sharing derived, not declared), and edge_set_forced (A1+A2+minimality ⇒ exactly the canonical edges). A bonus the prover found: no 4-cycle survives the two laws at all — every Hamiltonian cycle on the square needs either a private-row edge or an outbound diagonal.

The decisive doctrinal move (the one the successor must understand to read the whole runtime): the columns/diagonals unification, formalised here, says a holon is two named subjects — a structure and a continuity — each with a public outer face and a private extension within. Each subject has a telos that is a diagonal coupling its own face to the other subject’s depth (the chiasmus — “why it’s 4QX“). Outbound telic motion is mediated through the public row (the
seam gates authority); telic return is direct along the diagonal (evidence merges idempotently). H reads as per-column extension fidelity: H=0 ⟺ each inner face is a faithful extension of its outer face. This is the conceptual spine of everything downstream — the six-phase cycle, the capability grant table, and “value lands in Form” all fall out of it.

Honesty boundary he held: the integration is conditional — “SealedInnerRow + ReturnOnlyClosure + SupportsBothTeloi + MinimalLawfulSupport ⇒ canonical edge relation” — and H-as-column-fidelity is bound Source-level only, explicitly
not promoted to a theorem (noted as future reviewed work). Kernel does not import Philosophy; the weld (EdgeLawTelosWeld.lean) imports the kernel from the Source side only.

How it set up 49: “the dual triangle stops being the kernel’s starting point and becomes its first theorem” gave the runtime a forced geometry to be faithful to — and the column/extension reading became the doctrine epic 49 wrote down.

Epic 49 — Columns → runtime closure: the doctrine and the rubric

Problem: the formalised column/extension unification had no runtime-facing doctrine, and there was no way to measure how far the build was from GOAL.

What he built / decided:

  • 4QX/Runtime/Generic Organisation.md rewritten (49.1) as present-tense pure concept: two column-subjects × two faces as static grammar; “the inner extends its outer within”; six phases as the coupled lifecycles of the two teloi (Instance Fit→Offer→Integrate, Class Accept→Run→Publish); the seam as Name-exchange market.
  • The C1–C25 capability matrix (4QX_DEV_KERNEL.md §15) — 25 named runtime capabilities as the GOAL-distance rubric, plus the seven prohibition classes as named violation classes. This becomes the build spec for engine2 and the authority rubric the architect still uses.
  • The body-schema reading of BL identity — BL is not just trie-naming; it is “a self-representation surface behaviour reads and Integrate rewrites.” Critical for the runtime capability matrix.
  • The four vertical ops (present / actualise / generalise / specialise) as the complete inter-level repertoire.

Closure discipline (the template for everything after): epic 49 closed under honest AMBER — F1 AMBER(detected), F2 AMBER(named), F4 AMBER(readable), with all remaining work routed with owner/route/criterion, never silently unresolved (fable5-epic49-closure-report.md §1, §6 anti-overclaim reassertion). “No status was promoted by prose.” This is the cadence — per-sprint Pro assessment, corrections bound as report addenda — that runs unbroken through 51 and 52.

Epic 51 — Plugin2 reduction: engine2, the reduced inverted engine

Problem (the “truth bomb”): the runtime held 4QX as vocabulary (continuation/native/phase.ts), annotation (seam/phase-tagging.ts, post-hoc), and unfired law (workflow/go-executor.ts, 2,901 dead instance rows) — while actual execution was a 9,838-line dispatch monolith (family-dispatch.ts). “The doctrine says the triangles run; the runtime’s truth is the triangles describe what the dispatcher did.” (fable5-epic51-design.md §0.)

The fusion (the insight that made epic 51 work): the “Reduce” step of the HolonicAgent independence plan (README §10.6 step 1: “make a 2.0 of the plugin with the minimum of code”) IS the inversion. Re-platforming and re-structuring become one move, validated continuously against the live system as a reference oracle. And it escapes the parallel-path curse because traffic must move this time — the OpenClaw host is being abandoned regardless, so there is a forcing function the go-executor never had.

The historical diagnosis he pinned (fable5-epic51-design.md §0.1, header-verified): the off-track moment was Epic 27B3.2, when seam/phase-tagging.ts made phases “the fourth orthogonal classification dimension” — from then any code path could count as six-phase by emitting recognisable events, and economics did the rest. MHC (43B2/F) was crowned as continuity core (correct doctrine) but in demoting WorkflowInstance as continuity root it also demoted the executor welded to it as engine — execution authority defaulted to family-dispatch. The binding porting guard: MHC’s perception machinery may reduce, but its ontology (one holon → one continuity → many cycles) is the half of the dual triangle that was right; a 2.0 with lawful cycles and no continuity identity would repeat the error mirrored.

What he built — engine2 (src/engine2/, src/engine2-substrate/, ~9,819 lines):

  • One cycle enginerunCycle() (engine2/cycle.ts:302) executes the six phases (GO_PHASE_ORDER, phase.ts:44) in order, once. Outcomes are total by construction: every cycle ends as completed | refused | halted, where a halt is a typed { phase, haltClass, reason }. There is no untyped failure.
  • Phase-scoped capabilities as the edge law in code — the grant table
    (capabilities.ts:60): fit:[read], offer/accept:[read,seam_emit], run:[read] (pure — no emit, no write), publish:[read,seam_emit, durable_write_p], integrate:[read,durable_write_r]. A door body holds only its current phase’s capabilities, leased via a Proxy that throws CapabilityEscapeError if stored and replayed later. This makes C13 value-landing, P5 raw_leak, P7 unaccepted_burn, P4 top-down, P1 identity-commands-burn hold by construction, not by scanner.
  • Door specsDoorCycleSpec (cycle.ts:178) carries doorClass, holonRef, continuityRef, initialState, a phases handler per GOPhase, and finalise. Each door class is a build*DoorSpec() function (outbox-replay, invoke-output-affordance, body-schema-runner offer/block, accept/defer decisions, complete-run, lifecycle-transition, accept-decision, candidate-disposition, inspect-outbox-posture, private-fit-frame, reasoning-mutation).
  • cycleRef / continuity weldmintCycleRef() (cycle.ts:241) mints cycle2:* refs (deliberately distinct from the old cycle: annotation hash); each cycle binds to its continuity via continuityRef (the ContinuityCycleRef weld 43J minted). One holon → one continuity → many cycles, enacted, not annotated.
  • H3 parent-gate / child-cycle nesting — the old invoke_declared_output_affordance re-entered the dispatcher (door-calls-door recursion). In 2.0 a parent cycle‘s Publish phase invokes a child through one capability,
    invokeChildAction() (door-invoke-output-affordance.ts:91) — recursion becomes a capability boundary, not dispatcher re-entry.
  • engine2-substrate (the harness layer, tests-only in epic 51): capability-factory.ts is THE single seam (D1) where engine2 meets surreal-client / seam-log / host-home / cadence-multiplex (two constructions: createLive* for production cutover, createShadow* reading the DB read-only, refs prefixed shadow:would_be_* so they can never launder into production); shadow-parity.ts (the five parity classes); cutover-window.ts (the per-class ladder differ); tagging-verifier.ts (“THE INVERSION of seam/phase-tagging.ts” — executed phase is ground truth, the classifier is checked against it).

Foundation lock D1–D5 (fable5-sprint51.0-foundation-lock.md):

  • D1 engine2 lives inside the plugin (src/engine2/); import-direction locked.
  • D2 extract only the tested cycle law from go-executor, never its trigger machinery — “the production oracle is FIRED DOOR BEHAVIOUR, never the unfired trigger path.”
  • D3 the shadow oracle protocol — “shadow output is barred from production-firing claims; claim levels stay distinct until cutover.”
  • D4 reframe around the one-FIRED-door finding (the meta-door’s arms).
  • D5 per-door retirement: old arm retires when the 2.0 path holds its declared parity class across a continuous production window for that class.

The meta-door finding (fable5-epic51-door-inventory.md): in production, strictly one door is fired — exercise_candidate_affordance (~985 lines), carrying all three canaries as internal arms (43I outbox-replay / 43K.5 lifecycle / 43K.6a accept). The inversion treats the meta-door’s arms as the door classes to port. This reframed the whole port order to oracle-first.

Closed claim (fable5-sprint51.6-closure.md §11 close certificate, Pro wording bound): “Plugin 2.0 executes 9 of 18 named door classes at shadow receipt-parity. For those classes, the six-phase cycle is the control flow and phase-scoped capability law holds by construction.” With the four N numbers locked and never conflated:

N_shadow_parity_validated        9 / 18 named door classes
N_catalogued_actionKinds_shadow  14 / 144
N_live_cutover                   0 / 18
production_traffic_share_on_2_0  0%

And the honest correction (C-51.6-B): epic 51 did not port every fired surface — shadow coverage was 402/678 = 59.3% of AAB-evidenced production exercises, with invoke_declared_output_affordance (n=241, 35.5% of all traffic) the top unported fired surface. Coverage ≠ traffic moved. The exact M=18 partition is locked executably by sprint-51.6-closure.test.ts.

Epic 52 — Slim-host cutover: making engine2 the live system

Problem: epic 51 proved the successor against the living system without touching it. Nothing was production-fired on 2.0; the monolith served 100%.

What he designed (fable5-epic52-design.md) — two orthogonal axes:

  • Axis H (host): which shell loads the plugin. OpenClaw gateway (2,334 files, of which the plugin uses four SDK modules through one adapter) → the ~830-line HolonicAgent slim host. The claim ladder he bound: host_built → host_dev_parity → host_live_parity → host_cutover_open → host_validated.
  • Axis D (doors): which engine executes each door class. family-dispatch arm → engine2 live construction. Eighteen named classes, one at a time.

The per-class cutover protocol (D52-2, the epic’s core law) — five steps, each with its own evidence: STEP 0 preconditions (gates as code: typed drift outcomes, H7 test-residual exclusion, the class’s mandatory-emission rows) → STEP 1 rewire (the caller calls the engine2 live factory; the witness inverts knowingly with a named row) → STEP 2 window (production receipts diffed against bound parity rows) → STEP 3 verdict (GREEN close or one-commit rollback) → STEP 4 delete (the old arm deleted in the same change set as the green close; the reduction ledger records the deleted lines). A class is production_validated only after step 4.

The per-class claim ladder (D52-3): shadow_parity_validated → cutover_pending → oduction_window_open → production_validated. N_live_cutover counts ONLY production_validated.

The guards (carried + new): G7 NO DUAL-SERVE (one engine per class at any moment; the window is temporal, not fractional — receipt-identity, not statistical similarity); G8 ROLLBACK IS ONE COMMIT; G9 WITNESS HONESTY (every inverted attestation amended in the same commit); G10 HOST-SWAP ISOLATION (“the host swap commit changes zero plugin code” — bound verbatim into every report). Plus the second standing law: “deletion commits re-baseline the full-suite failure count explicitly, never silently.”

How far he personally carried it (sprints 52.0–52.5, all fable5- authored; 52.6+ are the successor’s): foundation lock → port wave → first production cutover (the runner class, N_live_cutover 0→1, the first lawful use of production-fired on 2.0″ in project history) → slim-host build + dev parity → host swap (HolonicAgent serves 100% of production, 2026-06-12T16:05Z) → host_validated window → decision wave (block door created + hardened). He explicitly did not claim the host swap fixed the cadence wedge (FIND-52.2b-CADENCE-WEDGEburstInFlight never clears in the idle-gated autonomous window; it travels with the plugin, not the host).

Epic 53 — Architecture ground truth (IDEAS ONLY — his forward plan)

Problem: epics 51/52 invert the dispatch monolith, but the rest of the code was never asked the shape questions. Epic 53 makes the whole architecture seeable. Status: PROPOSED, awaiting plan assessment; opens after the 52 close. See §4.


3. What he built — the cumulative architecture as it stands

The live system today (verified 2026-06-14):

  • The host (Axis H): DONE — terminal rung. HolonicAgent serves 100% of production. It is not a fork of the plugin: it loads the unchanged plugin via jiti, uses shim modules for the four OpenClaw SDK surfaces, and crosses host/shim state through one globalThis bridge. host_validated reached 2026-06-13; OpenClaw independence: achieved” is lawful because the rollback shell 4qx-openclaw was retired (docker rm @ 026-06-13T13:14:51Z, the named C-52.4-A act).
    Restore is now a compose redeploy, not a one-step container start. The cadence-wedge watchdog (FIX-52-CADENCE-WEDGE, commit 1b372d3b) bounds the idle-section hang with a 120s budget; C-52.4-C confirmed 2026-06-14 the 00:00Z daily cohort fires naturally with zero catch-up restart — the catch-up ritual is retired (the wedge root cause stays open as the runtime team’s row, never claimed fixed).
  • The engine (engine2): live, taking over door by door. The six-phase runCycle, the door specs, the live capability factory, the H3 child-cycle nesting, the cycleRef weld — all as described in §2’s epic-51 entry. In production dispatch the modules are wired in per door class as each cuts over. The cutover ladder — where it stands now:
  N_live_cutover                   7 / 18 door classes production_validated
  N_shadow_parity_validated        9 / 18
  N_catalogued_actionKinds_shadow  17 / 144
  Host                             HolonicAgent 100% (host_validated, terminal)

The seven cut over (each: green window + old-arm deletion + re-baselined suite):

  1. runner OFFER (52.2 — the wake-scanner rewire; first cutover)
  2. block_body_schema_run (52.6)
  3. accept_body_schema_run (52.7)
  4. invoke_declared_output_affordance (52.8 — n=241, the traffic head; the H3 child-cycle door)
  5. complete_body_schema_run (52.9 — the last run-lifecycle door)
  6. generate_private_fit_frame (52.10 — the first non-lifecycle, audit-family, read-projection door)
  7. exercise_candidate_affordance (52.11 — the four-family meta-door, cut via an Option-B dispatch-among-four shim routing each sub-arm through its 51.x shadow-parity door; its S7 accept+propose_org_mutation arm is retained inline as a named partial deletion, RES-52.11-S7-PORT) Note the per-door Integrate grading the successor added (baton item 33): 52.6–52.10 are Integrate GREEN (natural inhabitant evidence); 52.11 is Integrate AMBER (driver-of-record — every actual since deploy is the synthetic driver; zero natural inhabitant exercise), bound to a 52.12 activation gate (C-52.11-INTEGRATE-A). This does not move N — the four ported families serve 100% of their traffic on 2.0.
  • The slim host + the measured reduction. The first measured reduction landed at the runner cutover: body-schema-runner.ts 527→63 lines, net −459 — “the reduction finally measured in deleted lines rather than promised in reports.”

4. His plans for moving forward (DONE / PLANNED / IDEA)

Remaining Axis-D cutovers (PLANNED — the bound port order)

From fable5-sprint51.6-closure.md §5 (evidence-first, EVD-51.6-AAB seeds it) and the residue table §3.2–3.11. After the seven already cut, the named residue with routes:

  • defer_body_schema_run — PARKED / old-path (C-52.6-D): fixture-scoped, zero production deferred events. Not a cutover until real deferred actuals can be lawfully generated, else a bounded defer-evidence sprint (Pro 52.9 governing recommendation).
  • governed_reasoning_mutation — the current in-flight door (52.12). See §6.
  • SPLIT-51.6-QUERY-BATCH (45 kinds) — batch port on the door-5 read-only pattern.
  • SPLIT-51.5b-INSPECT-HOST-HOME (H1 offender #2) — its own H1-NORM row.
  • RES-51.6-ORG-STRUCTURE (17), -AUDIT-MUTATION (30), -MODEL-POLICY (11), -REPO-SELF-EDIT (6), -REVISION-PROPOSAL (4), -DELEGATION (2), -BODY-SCHEMA (14 lifecycle/mutation kinds) — each routed with owner/criterion; org bridge coupled to RES-51.3-S7 (the unfired accept+propose_org_mutation arm — partly carried at 52.11); delegation = the H3 child-cycle shape; model_policy sequenced with the README §10.6 step-3 activation.

Named residues and gates carried forward (PLANNED/OPEN)

  • GATE-52-SCANNER-FIRINGedge_law_prohibition_check is structurally unreachable in production (no caller asks getDueScanners("boot")); 51.2 Publish stays AMBER until a lawful scoped invocation produces stored conformance evidence.
  • ROW-51-F5-WIRE — ExecutionProvenanceBundle refs from cycle receipts.
  • FIND-52.2b-CADENCE-WEDGE — root-open (runtime team), watchdog-bounded.
  • The 52.11 close residues (C-52.11-INTEGRATE-B): writer-scoping-predicate correction, COOL-not-production-fired, DRIFT-BRANCH-TEST-GAP, RES-52.11-S7-PORT, and the unilateral-deletion process flag.

His intended end-state (PLANNED/IDEA — epic 53 + value assessment)

The decisive forward document is fable5-value-assessment-and-path-forward.md, written when the steward asked whether to rebuild HolonicAgent from scratch. His answer (Path C — rebuild-by-absorption with an explicit keep-kernel and deletion budget, bindings PF-1…PF-6) is the clearest statement of where he was steering:

  1. Finish the Epic 52 strangler cutover — never abandon an open window; the monolith dies measured.
  2. HolonicAgent host: from scratch (already done as planned).
  3. Assembly 2.0: built fresh in the engine2 idiom, NOT in-place inverted (this amends the founding plan’s M-5 → ROUTE-53-ASSEMBLY-REBUILD, candidate Epic 55). The reason: the 4,922-line projector “spends the majority of its 4,000 lines building a prompt that line 4095 throws away” (the founding audit’s single most actionable fact).
    Building fresh against the kept Pow/Sep/Pair selection kernel + current surfaces, cut over per section, deleting the zombie with measured lines.
  4. A binding keep-kernel artefact (Epic 53 deliverable): the explicit list of modules the 3.0 plugin is made of; everything else is reference material with a deletion/quarantine date, kept honest by a regenerable fired-map.
  5. A permanent deletion budget — target end-state ~70–90k lines (from ~230k), traffic on it the whole way.

Epic 53 itself (IDEAS ONLY — fable5-epic53-plan.md + fable5-epic53-structural-audit.md): make the whole architecture seeable to end the situation where shape questions are only ever asked of the current epic’s frontier. Its root-cause analysis names why potemkins recur (RC-1 frontier-only auditing; RC-2 “vocabulary is free, structure is expensive, nothing type-checks the difference”; RC-3 the CHARTER fired-ness ladder is prose not a
machine; RC-6 the architecture doc is a stale fossil). Its deliverables: D-1 an end-to-end generator-grain architecture report; D-2 a regenerable system-architecture.md; D-3 a per-epic whole-architecture assessment gate regenerate the fired-map, diff against last epic, name every delta as intended or drift) — “the structural complement to the anti-Potemkin workflow: that checks claim-versus-world, this checks structure-versus-generator, globally, on cadence.”

The founding audit (his most careful forward-looking document) found that the rest of the plugin has the same structure-versus-grammar failure as the dispatch monolith: the context-assembly pipeline is “a linear concatenation pipeline wearing holonic vocabulary, with the genuinely salience-driven machinery running disconnected alongside it” — the Pow/Sep/Pair retrieval kernel runs every turn and is discarded; walk-engine.ts is “a scorer named a walker”; the children holarchy nesting is “always []“; field/replay.ts is “the authoritative replay engine, zero production callers.” He classified everything (TYPE A post-hoc annotation / TYPE B starved parallel / TYPE C vocabulary monolith / SOUND) with file:line anchors — this is the audit Epic 53 sprint 53.1 would settle with live probes.

The steward reframe he bound (DONE, recorded fable5-value-assessment §6): “the dev was not wasted — the ~230k lines were the price of the specification, not a failed implementation of it.” The soundness map matches the knowledge map: SOUND code is exactly what theory specified precisely before building; potemkin code is exactly what theory had not yet specified. The runtime→Lean backflow already fired once (epic 48 pinned the two-teloi discovery). ROUTE-53-LEAN-BACKFLOW (steward-gated) carries the rest.


5. Open questions / what is at risk now that he’s gone

  1. The from-scratch temptation. The single biggest risk is a successor (or steward) deciding to rebuild fresh because “so much of it is potemkin.” Fable5’s value assessment is the definitive refutation: the second-path argument is structural, not empirical (Path B is the go-executor pattern at scale). Do not reopen this. His answer is Path C and it is bound.
  2. The reasoning-door GO-gate decision (in-flight, constitutional, undecided). 52.12 surfaced a finding Fable5 never saw: GO-gating the reasoning door is not a drop-in. The GO-gate refuses any action with targetCoord === 0 (root) unless self-knowledge; reasoning is self-root-scoped, so GO-gating it either passes (if cached projectCoord is null) or regresses totally (if it is 0). Worse, all 7 already-cut-over doors are bootstrap-exempt / audit-family — they all skip the parent gate. So the steward’s “move reasoning to the full GO-gated path” ruling is a cross-cutting constitutional change to self-root organisation generally, not a property of one door. The sub-agent investigation (baton item 38) recommends converting bootstrapExempt (skip the gate) into selfRootScoped (gate it as self-root organisation), which edits the constitutional root-protection guard — security-sensitive. This is paused pending a steward scope decision and is exactly the kind of one-way door Fable5 would have wanted the architect in the room for. Do not GO-gate reasoning alone and call it a door cutover; that makes it the first gated door, inconsistent with the other seven.
  3. The ARCHITECT-OFFLINE-DELETION rule (new, because he’s gone). The 52.11 step-4 deletion (236 lines, a live dispatch path) was a unilateral builder act under architect-offline conditions. Pro bound a standing rule: a deletion ≥50 lines OR affecting a live dispatch path lands only if architect-reviewed before merge, or marked “post-hoc architect review required before next functional cutover.” Every step-4 cutover deletion touches a live dispatch path — so this gate applies to every future cutover deletion by default. The successor must not let the 52.11 precedent become a precedent for skipping review.
  4. Ambiguous: when a residue’s only evidence path is the midnight cohort. The steward has ruled (recorded in architect memory) that work must never block waiting for the UTC-midnight cohort. Door-axis windows must be driven on-demand (the inhabitant-driven window reading, C-52.2b-WINDOW-CYCLE-RESTATE, explicitly allows real exercises as the cycle). defer_body_schema_run is the live case: zero natural deferred events, so its cutover needs either lawfully-generated real actuals or a bounded evidence sprint — never a synthetic event laundered as production.
  5. The M-5 amendment must not be lost. The founding plan said “invert assembly in-place”; the value assessment amended this to “build assembly 2.0 fresh in the engine2 idiom” (ROUTE-53-ASSEMBLY-REBUILD). A successor reading only the epic53 plan §3 M-5 without the value-assessment PF-2 amendment would do the wrong (more expensive, porting-dead-weight) thing.

6. Continuity note for the successor

Read first, in this order:

  1. HolonicAgent/Discussion/epic52-slim-host-cutover/opus4.8-epic52-baton.md — the live ledger (where the cutover ladder stands; §3 head for the bound Axis-D state, §8 for the item-by-item history; the 52.12 GO-gate finding is items 36–38).
  2. HolonicAgent/Discussion/epic52-slim-host-cutover/fable5-epic52-design.md — the protocol (D52-1/2/3, the five steps, the guards G7–G10).
  3. OpenClaw/Discussion/epic51-plugin2-reduction/fable5-sprint51.6-closure.md — the M=18 table, the residue routes, the N vocabulary.
  4. HolonicAgent/Discussion/epic53-architecture-ground-truth/fable5-value-assessment-and-path-forward.md — the definitive forward direction (Path C, PF-1…PF-6).
  5. HolonicAgent/Discussion/epic53-architecture-ground-truth/fable5-epic53-plan.md + fable5-epic53-structural-audit.md — the next epic’s ideas + the whole-tree audit.
  6. The canonical doctrine: 4QX/Runtime/Generic Organisation.md and the kernel EdgeLaw — the geometry the whole runtime is faithful to.

The standing principle (do not violate): His design is definitive — study before changing. The strangler discipline (never fork traffic; one engine per class; old arm dies only after a green window; reduction measured in deleted lines; every claim runged; every runtime claim cites a production receipt; TESTED/WIRED is never GREEN) is not style — it is the constitutional response to a documented past failure (the go-executor starvation).

In-flight work: Epic 52 is mid-Axis-D, 7/18 cut over, currently at the governed_reasoning_mutation cutover (52.12) — which is blocked on a constitutional GO-gate scope decision (§5 item 2). The host is done; the remaining work is doors.

Recommended next steps (grounded in his plan):

  • Resolve the 52.12 GO-gate scope question with the steward before any reasoning-door code lands; do not GO-gate one door in isolation. Prefer the contained-pilot or door-cutover-only options the investigation surfaced over a silent constitutional change.
  • Continue the bound port order (after reasoning: query batch on the door-5 pattern; inspect_host_home; then the mutation residue classes by AAB volume), one door at a time, each with a green window and a deletion.
  • Treat defer_body_schema_run honestly: no synthetic cutover; drive real actuals or run a bounded evidence sprint.
  • Apply the ARCHITECT-OFFLINE-DELETION rule to every step-4 deletion.
  • When the 52 cutover converges, open Epic 53 as he planned it (knowability; the fired-map gate; the keep-kernel artefact) and carry the M-5 amendment (assembly 2.0 fresh, not in-place).

His one-line summary of the whole programme, which the successor should keep in view:
“The monolith does not get refactored — it gets survived, door by door, with receipts.”

Leave a Reply

Your email address will not be published. Required fields are marked *