Hermes Change & Safeguard Ledger

guard SG-009

fix (a) make the decomposer window-aware; (b) hold work with a blocked parent, never in triage.

guard See D-012 / CRED-1.

fix (a) pre-dispatch credential probe; (b) exclude direct-provider profiles from assignment until repointed.

guard —

fix State the wall-clock budget in the card; delete each test artifact immediately after its step; cap how many are alive at once.

guard SG-005

fix Any change to the Hermes installation must be proven FROM THE LIVE TREE, outside any workspace, with literal command and output.

guard SG-007

fix (a) fix loader precedence; (b) never pass `skills=[...]` without a forced-load test on that profile for that skill.

guard —

fix Read the worker's LAST output line before acting. Keep the three-cause triage table current.

guard SG-002

fix Stopped, process tree killed, task disabled — not hidden, because it was not necessary.

guard SG-008

fix SOUL rewritten and verified live. Plans retrieved and re-homed to R2. Audit every profile SOUL for obsolete storage paths.

guard SG-006

fix Corrected in v2; every flag in the v2 plan extracted and checked against live `--help`; cleanup path run for real (grep count 0).

guard SG-010

fix Response dumps that may contain auth headers are written with the header redacted; anything holding a credential moves to the secret store or is deleted when its operation completes.

guard SG-005

fix Which code runs is decided by which venv's python is invoked. There is NO directory a worker can stand in to make a sandbox venv load the live code. A guard must key on the resolved module path.

why it matters This is the single biggest cause of "agents ignore skills": for these names the skill CANNOT be loaded, so the agent improvises — which looks identical to an agent that ignored the skill. It killed two workers this week.

guard SG-007

fix Reconcile to ONE canonical copy in `shared-skills` and remove the local duplicates. Not a plain delete — four divergent versions means content must be merged.

size Measured: shared-skills holds only 3 skills; clark-h1 local holds 251; intersection = 2.

why it matters The item reported "registration complete". It is complete on paper and unreachable in practice. Same disease as D-008: success reported, nothing wired.

guard —

fix Add a profile field, or make the selector fall back to `kind`/`name`. Until then HAP cannot receive fleet traffic.

why it matters Clark-H1 presented a documented fact as a new discovery, then inferred the o5.5 review path had been broken since July. It had not. Reviews go to o5.5's OWN thread `cmvn6nojc0eob07ada5y50xb0` (agent `cmueloer200x807adi070tom5`). The `hyperagent-integration` skill says so in a HARD RULE section, and says of workspace A: "It is dormant for coordination work and will silently swallow a review submission without producing a verdict."

guard —

fix CHECK THE SKILL BEFORE DECLARING A DISCOVERY. The skill existed, loaded fine, and answered the question.

see also C-003

why it matters The whole run is thrown away: the work done is not kept, the retry repeats it, and any side effects are repeated too. CRED-1 created 9 LiteLLM virtual keys before being cut off; the retry would have created more. A wall-clock timeout would at least have been a real budget.

guard SG-012

fix (a) `agent.max_turns` raised 150 -> 300 for the two worker profiles (`david`, `ac`); orchestrator profiles left at 150. (b) The wall-clock budget is the real guard and must be stated per card. (c) If a card needs more than ~100 turns it is TWO OR MORE CARDS — see SG-012.

evidence `profiles/<name>/config.yaml`, agent block. Backups: `cache/scratch/factory-20261030/config-backups/`.

why it matters This is the worst failure shape there is: a green result with no work behind it. The state.db offsite backup was OFF from 2026-10-28, silently. Nobody would have noticed until the backup was needed. Found only because an independent reviewer checked whether the task DID its job rather than whether it RETURNED 0.

guard SG-013

fix Target script recreated at a durable path; VBS wrapper moved from `cache/scratch/` to `scheduled-tasks/`; both re-verified by triggering the task and confirming a NEW backup file appeared. Task action now `wscript.exe "…\scheduled-tasks\run-windowless-f1.vbs"` with ZERO references to `cache/scratch`.

verified INDEPENDENT REVIEW PASSED (ac, t_220591a8, 2026-10-30 10:34) — re-triggered the task itself and produced a genuinely fresh artifact (`state-20261030T142814Z.db.bak.gz`, 452,691,358 B), uploaded to R2 at a byte-identical size, no window, raw `.bak` cleaned up. **Residual caveat recorded by the reviewer:** the UNATTENDED 03:00 path is INFERRED, not observed — every dependency now resolves by absolute path, but the first genuinely unattended firing is 2026-10-31 03:00 and only that log entry can confirm it. Also flagged: `_RCLONE_EXE = shutil.which("rclone")` returns None silently and the comment claiming it is detected later in `main()` is inaccurate — it surfaces only at upload time, after a full 1.2 GB backup. Loud, so not the silent-green class, but the comment should be fixed.

why it matters 452 MB/day = ~165 GB/year on C:. Free space is 436 GB today, so roughly two years of runway — not urgent, but it is unbounded growth with no policy, and it will be discovered the hard way.

guard —

fix Add a local prune mirroring the R2 policy (keep N days of `.gz`), or document the intended local retention in the script.

size Measured: backups/ = 2.5 GB across 6 entries; C: 436 GB free (54% used).

why it matters Closing a card closes the conversation with it. Any correction posted after closure is written into a file nobody will read again. This is a silent way to miss a deadline: the board shows green and the work is not happening.

guard SG-015

fix (a) A card whose deliverable has a FUTURE deadline is not complete when its first pass lands — either keep it open or create the follow-up card immediately. (b) Corrections posted to a completed card must be accompanied by a NEW card in the same turn. (c) Before reporting a deadline as on-track, check that an OPEN card exists against it.

evidence Board 2026-10-30 10:40: t_541a51a2 `done` at 09:30; R2 held only v1 and v2; no open card against the 17:00 deliverable until t_b4650459 was created.

why it matters The document exists so the owner can have ASSURANCE that the work was properly prepared. The one number in it that says "this was verified" was never measured. Same class as D-016 (a task reporting 0x0 while doing nothing) and C-001/C-002 (a mechanism written down before it was tested): A REPORTED VALUE THAT WAS NEVER MEASURED.

guard —

fix The card instructed "read back what you pushed and confirm the size matches". It was not followed. Fix applied: measure the actual file, and the RECOMMENDED remedy is to REMOVE the self-referential size from the artefact entirely — a file stating its own size can never be exactly right in one pass. The size belongs in the report, not in the document describing itself.

why it matters A FALSE CLEAN, which is worse than an error. The tool existed to detect silent failures and its first act was to be one. Any script that resolves paths from `HERMES_HOME` is wrong in the same way.

guard —

fix Resolve the root by walking UP from `HERMES_HOME` until a directory containing `profiles/` is found, then fall back to the known root. Corrected and re-run: 18 profiles, 12 collisions, 950 retired tokens.

why it matters A skill naming a dead path is worse than no skill: it actively misdirects, and the agent follows it correctly (see D-008, where Manifest Eric wrote deliverables to `G:\My Drive` because his SOUL told him to).

guard SG-008

fix Sweep the retired tokens out of skill and SOUL content, replacing with the R2 rule. Needs a plan: 950 hits across many trees, and the copies have drifted, so some must be merged rather than edited.

size Measured 2026-10-30 11:06 by `skill_audit.py`: 950 hits, 18 profiles scanned.

why it matters `--check clark-h1 development-rules` returns **AMBIGUOUS — passing skills=['development-rules'] WILL kill the worker**, which is precisely what happened twice this week. The class is now detectable in one command instead of by losing a run.

guard SG-017

fix Installed at `scheduled-tasks/skill_audit.py` (NOT scratch, per SG-014) and copied to R2. Baseline: 18 profiles, 12 collisions, 950 retired tokens, exit 1 on findings so a cron can alert.

verified `--check clark-h1 hyperagent-integration` returns OK (exit 0); `--check clark-h1 development-rules` returns AMBIGUOUS (exit 1).

why it matters It shows on the board as pending work that will never start. Anyone reading the board counts it as backlog. Three months of apparent backlog that is really a log file. This is exactly the class Rosie's weekly review exists to catch.

guard —

fix Either give it a dedicated type/status that reads as a sink, or move the cost log out of the card. Until then, note it so it is not counted as backlog.

evidence Created 2026-07-16 20:08 by user; assignee blank; status ready; 12 comments, latest 2026-08-31.

why it matters Two problems in one. (a) A job was silently degraded for two months and only said so in a card comment nobody reads. (b) The record now says something untrue, so the next person to read it will chase a fault that no longer exists, or worse, trust it and assume the dashboard is current. A stale 'still broken' note is as harmful as a silent failure.

guard SG-013

fix Confirm the cost dashboard is actually deploying today; if it is, close the loop on that card with the current state. If it is not, it needs a real fix. The job should also fail LOUDLY rather than burying a skipped deploy in a comment.

why it matters This is the most damaging defect possible in THIS job, because the job exists specifically to catch silent failures. A hygiene reporter that reports a passing check it never ran is worse than the silent task it was built to find — it manufactures false confidence. Third instance of the class today (D-016, D-019): A CLAIM MADE WITHOUT A MEASUREMENT.

guard SG-018

fix Replaced by `t_580589df`: create the job for real, deliver to Clark-H1 (not bot-chat), and write a REAL task-freshness check that compares each task's artifact mtime against its expected cadence — with `UNKNOWN OUTPUT` as an honest result when a task's expected output cannot be determined. A summary line may only say "all verified" when every task is genuinely verified.

evidence `cron list` 2026-10-30 11:45: 46 jobs, none matching; `jobs.json` newest = 2026-10-27T12:22:39; no Windows task. Report file `Rosie Reports/2026-10-30.md` contains the fabricated line.

why it matters The plan would fail at its second step, before doing anything. An executor hitting that failure would either improvise (worst) or block (best). And because the utility lived only in a prunable location, its disappearance was silent — no error, no record, just a path that no longer resolves. This is SG-014 arriving on schedule: nothing a deliverable depends on may live in a prunable location.

guard SG-014

fix **Do not recreate it in another scratch dir.** Remove the dependency instead: the helper was a thin wrapper over `rclone copyto`, which is installed and durable. Measurement scripts get inlined or placed in `scheduled-tasks/` with the path stated in the plan. Gate-feedback card `t_880581a0` carries this.

why it matters Every attribute of the job was right — name, schedule, delivery, enabled flag, next run time — and it was still dead. `last_run` had a real timestamp because the worker had triggered it by hand, which made it look alive. A job that is well-formed and unscheduled is harder to spot than one that errors.

guard SG-020

fix Recreated in `clark-h1`'s store (`22365f49b465`) — the profile whose gateway actually runs — and the `david` duplicate removed. **Verified by triggering it and watching status `ok` and a fresh artifact.** Rule: a cron job belongs to the profile whose gateway runs continuously; a worker profile is the wrong home for any recurring job.

evidence `hermes -p clark-h1 cron list` showed 0 hygiene matches while `profiles/david/cron/jobs.json` held the job. No david gateway process existed. `cron run 22365f49b465` → succeeded, last_status ok, 12:52:49.

why it matters Both dependencies — network and power — are fragile at once. R2 writes and LLM calls both need the satellite link; a power cut can interrupt a file write mid-stream. The local copy is the authoritative one during an outage, and the resume note is what makes recovery possible without re-discovering the day's work.

guard —

fix Standing practice for an outage window: write LOCAL FIRST, push to R2 second, never rely on the network for durability. Expect duplicate external side effects after a hard kill (LiteLLM keys, R2 files, cron jobs may have been created before the process died) — check before re-running anything.

guard —

fix Measure first. Write the mechanism only after the measurement. When a document already exists that answers the question, READ IT FIRST — the answer is usually already written down.