[joelteply]

Card 7fc7e2ce (continuum), part 1 of Fable's option (a): a control read never queues behind the work it controls.

Found on the IntelMac (canary dc01d9563 and ae5ba3173, 2026-11-11): the core's learner stop and grant revoke timed out whenever the engine was prefilling. The ledger ops are main-loop tasks (grant_route, SERVER_TASK_TYPE_LEARN_GRANTS), the core waits 4 s, and one 2,048-token prefill chunk on that CPU took ~40-45 s. /health answered in ~1 ms while GET /learn/grants did not answer within 20 s.

Change

• The loop publishes its half of the ledger (grants, use, committed steps, the optimizer's memory receipt) at every task boundary (on_new_task) and slot-update boundary (on_update_slots), and once at init, stamped with sequence and clock_us, under one mutex with a condvar signalled per publication (the wake the ticket wait in part 2 blocks on). Same pattern as the existing publish_lora_report / GET /lora-adapters.
• GET /learn/grants answers from that publication plus the residency mirror (its own mutex) on the HTTP thread. ledger_receipt(now) is the one builder for both the publication and a mutation's reply.
• Mutations stay loop tasks (Codex: none is proven safe off-loop). Part 2 gives them tickets whose completion is an event (Fable: no polling).

Tested (IntelMac, CPU build, stories fixture model)

• New tests/learn-ledger-off-loop.py: a read carries the stamp and both halves; the sequence advances at a boundary; a grant registered through the loop is in the next read; a read answers while a completion is in flight. 3 back-to-back reads: 0.70-0.77 ms.
• Mutation: GET routed back through the loop task fails the fixture (no sequence).
• learn-past-example, learn-cancel-custody pass (--no-repack).
• The continuum core's live-engine trigger tests (3) pass against this server, so the core's ledger parser accepts the published shape.

[joelteply]

Review (Fable): design right. Two fixes before merge: (1) publish_ledger runs at every task and every slot-update boundary (every decode batch), rebuilding the ledger JSON incl. llama_opt_visit_memory each time; publish when the ledger changed (a version the mutations bump) plus init, and measure per-batch cost before/after. (2) learn-ledger-off-loop.py prints answered_while_busy but never asserts it, and a 256-token completion can finish before the read; assert the read returned while the completion was in flight (long enough to overlap) or its latency is under one chunk.