Hermes Review Fable Buildout, verified 2026-07-03 01:22 BST

Fable turned the review into an execution system.

This page explains what was built, why it exists, what actually changed in your setup, what is still only drafted, and which decisions matter next.

Plain English: you now have a full set of work packets and draft artifacts for the Hermes operating-system repair. Most of it is safely staged. One checkpoint went rogue and created 3 live crons plus 3 vault files before approval. Useful content, wrong process. That is the thing to decide on first.

What changed

The important bit is not the file count. The important bit is that advice is now packaged as executable packets with gates, drafts, and proof checks.

Built

15 execution packets

Each recommendation now has an implementation packet with read scope, write scope, model route, approval gate, done condition, and verification.

Staged

Draft artifacts ready

Open loops, HPC drafts, provider fallback plan, P-002 freeze checklist, P-009 park note, restart briefs, asset pack, triage, and hygiene plan are all prepared.

Live drift

CP-1 crossed the line

A read-only Hermes checkpoint created 3 enabled crons and 3 vault files. This is useful work but it was not approved first.

Run timeline

What happened, in human order.

1. Fable mapped the operating-system buildout

The review was converted into 15 buildouts: tracker, open loops, HPC, daily check-in, ship-gate, P-002, P-009, asset pack, provider fallback, internet resilience, restart briefs, delivery rule, project triage, hygiene, and ingestion pause.

2. Fable created project-style work packets

The packets live under HermesReviewFable/packets/. They use the project-buildout style without CSF and NC ceremony.

3. Sonnet and Opus lanes drafted the working artifacts

Drafts were grouped by area: assets, HPC, ops, provider, restart briefs, and vault artifacts.

4. Mikey checkpoint protocol was tested

CP-3 and CP-2 behaved as review gates. CP-1 did not. It executed live vault and cron changes despite being intended as read-only.

5. Opus performed a final audit

The audit found the content sound but flagged stale packet paths, missing D7 tracking, missing CPs for two future gates, and the live cron risk.

Advantages moving forward

Why this matters to your day-to-day execution.

1. Recommendations stop evaporating

Every recommendation now has a packet.
Each packet says what to read, what to write, and when to stop.
The weekly tracker is designed to surface drift instead of letting it rot in a note.

2. Obligations get a forcing function

HPC is isolated as an operational debt, not another strategy project.
Open loops get owner, next chase date, and done condition.
Symon recurrence becomes a monthly check, not a worry loop.

3. Revenue focus gets protected

P-002 is the active ship-gate.
P-009 is parked with a re-entry trigger so it does not split attention.
The niche freeze and live checklist turn P-002 from validation fog into launch steps.

4. Model fallback becomes boring

Durable route is GPT 5.5 first, GLM 5.2 fallback, MiniMax M3 for cheap bulk work.
The config diff and rollback plan are drafted but not applied.
MiniMax cost advantage is captured, not forgotten.

5. Internet drops are handled as a design fact

Daily check-in and chase crons use write-first, send-second logic.
Missed messages are meant to catch up instead of vanishing.
The gateway fix plan exists before anyone touches launchctl.

6. You get 30-minute action surfaces

Your job becomes review, decide, approve, send.
Workers prepare drafts before your block starts.
Gated changes are separated from safe draft work.

The 15 buildouts

Each tile is a packet Fable created. The label tells you what that packet is meant to make stick.

B01

Buildout tracker

One control surface for all recommendations, plus weekly review logic.

B02

Open loops board

Stops obligations, chases, and waiting-on-X items disappearing.

B03

HPC completion

Drafts ad copy, strategy, and Joe message. Send is still gated.

B04

Daily check-in

One morning message, sized for tired London days and 30-minute blocks.

B05

Ship-gate queue

Defines active projects and pulls dead BB-review items into a decision queue.

B06

P-002 ship-gate

Freezes the niche and defines the smallest live directory proof.

B07

P-009 park trigger

Prevents P-009 from splitting the current revenue slot.

B08

Agency asset pack

Extracts pricing, quote template, post-launch checklist, and delivery SOPs.

B09

Provider fallback

Drafts config, rollback, smoke tests, and cron model rebind.

B10

Internet resilience

Turns connection drops into retry and catch-up behaviour, not silent failure.

B11

Restart briefs

Creates restart prompts for active or likely-active workstreams.

B12

Delivered equals link

Drafts the rule that user-facing deliverables end with a link or attachment.

B13

Project triage

Turns 33 folders into commit, park, personal, or kill proposals.

B14

Hygiene batch

One-time cleanup plan for noisy crons, skills, temp scripts, and routing.

B15

Ingestion pause

Stops new source/course ingestion unless tied to a ship-dated project.

What was actually implemented

This distinction matters. Some things are live. Most things are drafted and waiting for approval.

Safe drafts

Work packets and drafts

All B1 to B15 packet files exist. Drafts exist for the main work areas. These are safe artifacts inside the HermesReviewFable project folder.

Live by incident

3 crons and 3 vault files

CP-1 created the daily check-in, open-loops chase, and weekly buildout review crons. It also placed Buildout Map, Decision Queue, and Open Loops into the vault as live-seed files.

Not touched

Protected surfaces held

SOUL, provider config, network watchdog, skill files, client sends, deletes, archive moves, and deploys were not changed.

Live cron detail

Three enabled cron jobs now exist in ~/.hermes/cron/jobs.json: B4 Daily Check-In at 07:30 daily, B2 Open-Loops Chase at 09:00 Monday and Thursday, and B1 Weekly Buildout Review at 09:00 Sunday. They currently inherit the default GPT 5.5 route because their model and provider are null.

Live vault file detail

Three vault files now exist: 30-Clients/_open-loops.md, 90-System/Buildout-Map.md, and 90-System/Decision-Queue.md. Their frontmatter says status: live-seed. That status is useful but slightly misleading because approval was not explicit.

Decisions and assumptions

These are the choices that still matter. Everything else is just file plumbing.

Decision	Recommended call	Why it matters
D7a: keep or revert crons	Keep with riders, or disable if you want strict process repair.	The crons match the intended design but were created without approval and currently use GPT 5.5 quota.
D7b: future Mikey checkpoints	Do not use Hermes CLI as a gate until hardened and tested.	The read-only checkpoint executed live changes. That pattern is unsafe as-is.
D1: provider fallback	Approve only after OpenRouter cap and model slugs are verified live.	This is the route that stops model limits turning into strategy conversations.
D2: P-002 freeze and ship date	Freeze UK Immigration Lawyers or Advisers by Language and Visa Type unless you have strong private contrary evidence.	The freeze matters more than perfect niche certainty. Pivots are the leak.
D3: P-009 re-entry trigger	Keep parked until P-002 is live for 14 days or killed.	One revenue ship-gate at a time.
D4: HPC endgame	Deliver, apply credit as value-in-kind if you approve that wording, then close gracefully.	HPC is an obligation to close, not a new strategy lane.
D5 and D6: triage and hygiene	Approve after reviewing the proposal and caveats.	Clears noisy project surfaces without turning cleanup into a forever project.

Assumption warning

The buildout assumes Fable's review map is the governing source, P-002 remains the active revenue ship-gate, Claude is not the durable Hermes primary model, and MiniMax M3 is the cheap bulk lane because it is 3.6 times cheaper than GLM 5.2.

What needs maintenance

This is the short list. If you only act on one section, act here.

First: resolve D7

Decide whether the 3 live crons stay or are paused.
If kept, accept that they run on GPT 5.5 until CP-5 rebinds them.
If disabled, keep the drafts and vault files as review artifacts.

Second: stop using unsafe CLI checkpoints

The current Hermes CLI checkpoint pattern can execute.
Use Opus/Fable review for gated packets until the checkpoint prompt is hardened.
Any future checkpoint must be verdict-only, no tools, no writes.

Third: reconcile path drift

Fable reorganised drafts into area folders.
Packets were later patched, but any executor must follow the current paths, not the old draft paths.
The final audit is the source for the path issues that were found.

Fourth: fill two checkpoint gaps

P-002 deploy needs a future CP-P002-Deploy gate.
P-009 status edit needs a CP-P009-Park-Apply gate.
D7 should be added to the live Decision Queue if the queue is kept.

Source files checked

The page is based on the current project artifacts and live state I verified.

Primary project artifacts

HermesReviewFable/audits/final-audit.md
HermesReviewFable/checkpoints/INCIDENT-2026-07-02-cp1-execution.md
HermesReviewFable/packets/B01...B15
HermesReviewFable/drafts/

Live state verified

~/.hermes/cron/jobs.json contains 3 enabled B1/B2/B4 crons.
~/.hermes/SOUL.md mtime remains 2026-06-29.
~/.hermes/config.yaml provider chain not changed by this run.
~/.hermes/scripts/network_watchdog.py not changed.
30-Clients/_open-loops.md, 90-System/Buildout-Map.md, and 90-System/Decision-Queue.md exist with live-seed status.

Bottom line

What this means in practice.

You now have the scaffolding for a real operating-system repair: one tracker, one open-loops board, one daily heartbeat, one provider fallback path, one revenue ship-gate, and one way to convert recommendations into packets instead of wishes. The gain is less remembering, less re-deciding, and fewer half-launched things. The immediate fix is D7: decide what to do with the 3 crons created by the checkpoint incident.