Last built 2026-10-30 15:02 ET · append-only · generated from ledger.jsonl
Why this page exists. Owner directive, 2026-10-30, verbatim:
“i like reversible but there needs to be a log of this stuff and it needs to be on an html page
somewhere because we forget things and then do the discovery and fix all over again.”
So this is the one place that holds everything irreversible (with its recovery path),
every safeguard in force, every discovery and its status, and every
correction to the record. Nothing is deleted — a wrong entry is superseded, because the
correction is itself the useful record. Before re-investigating anything, search this page.
4Irreversible action
29Safeguard in force
42Discovery / defect
5Correction to the record
Irreversible action (4)
IR-0012026-10-30 09:40
Three Hermes profiles deleted: `godmode` (100 days idle), `clark-h11` (no sessions, no SOUL), `clark-h1-2` (no sessions).
why Owner authorisation, verbatim: "if an agent doesn't have a session history in the last 90 days then feel free to delist/delete."
recovery Archived to R2 BEFORE deletion and verified: `r2:ai-shared/3 Factory Operations/Profile Archive 20261030/<name>/` — godmode 778 files, clark-h11 3 files, clark-h1-2 2,027 files. Restore = rclone copy back to `profiles/<name>/`.
guard Archive-before-delete (SG-001). A profile with no verified archive is NOT deleted.
Scheduled task `HermesCommsHeartbeatJames` stopped, its process tree killed, and the task DISABLED.
why It opened a console window on the owner's desktop every 15 minutes, for up to 7 minutes, 518 consecutive failures. It targeted a September receiver session and a listener on 8643 that does not exist (the gateway listens on 8642).
recovery Re-enable with `schtasks /Change /TN "HermesCommsHeartbeatJames" /ENABLE`. NOT restored by choice — its purpose (2026-10-29 peer-comms testing) is complete and James has said not to send further REL-B messages.
guard A task whose purpose has completed is disabled, not left running (SG-002).
verified Window gone; 0 titled console windows measured.
why Owner: "I want dev-kat name changed to a version of David this is confusing to me."
recovery Old profile archived at `backups/dev-kat.bak-rename-20261018`. Historical references are deliberately UNTOUCHED — `.archive/`, `.curator_backups/`, `.bak` files and kanban attachments still read `dev-kat`, because they are the record of what was actually done.
guard Renames must not manufacture a name collision: no `david-profile` and `dev-kat-profile` may coexist. Verified — none left.
verified `SKILL RESOLVED` on a forced load; 11 `david-profile` copies, 0 `dev-kat-profile` (one backup dir only).
actor ac (t_208ab5a4) + david (t_f6b75296)
IR-0042026-10-30 09:33
Two scheduled tasks re-registered to launch through `wscript.exe` + a VBScript with window style 0: `HermesSharedSkillsEnsure`, `F1-StateDB-Backup`. Their original action lines were replaced.
why Both launched console programs directly with `Hidden=False`, so both could open a console window on the owner's desktop.
recovery Original action lines are recoverable from each task's pre-change XML in the review evidence attachment `kanban/attachments/t_ab806fff/REVIEW-EVIDENCE-SCHED-1.md`.
guard Windowless-launcher rule (SG-002). Schedules, principals and enabled-state preserved; verified by XML round-trip.
verified `<Command>wscript.exe</Command>` on both; schedules 06:10 / 03:00 intact.
actor david (SCHED-1 t_a7be7aa0)
Safeguard in force (29)
P-0012026-10-30
AGENT NAMING POLICY (owner directive): when more than one agent shares a first name, EVERY member of that name class carries a distinct surname. Surname = role. Factory/base marker appended only when it varies (`Eric-ChiefDesigner-F1CH1` = Eric, Chief Designer, Factory 1, Clark-H1 base). Short forms = first name + surname initials (`EricCD`, `EricM`). A first name unique in the fleet needs no surname (`Alfred`, `Rosie`, `ac`).
why Humans read names, not IDs. `winston` and `manifest-winston` were indistinguishable in chat, on the board and in logs — the owner said so directly: "Humans need visible markers to not get confused."
scope Every profile, every kanban assignee, every skill and SOUL that names an agent.
actor bob
SG-0012026-10-30
ARCHIVE BEFORE DELETE. Any irreversible deletion copies the target to R2 and verifies the copy's size FIRST. No verified archive = no deletion. A failed archive stops the item.
why Deletion is irreversible and the owner does not verify work personally, so recovery must not depend on him.
NO AUTOMATED TASK MAY OPEN A CONSOLE WINDOW ON THE OWNER'S DESKTOP. Launch console programs through `wscript.exe` + VBScript with window style 0.
why `HermesCommsHeartbeatJames` put a console window on Bob's desktop every 15 minutes for ~18 hours. **`Settings.Hidden = True` is NOT the control** — it only hides the task from the Task Scheduler UI; the console window still appears. The LAUNCHER is what matters.
scope Every scheduled task whose action is `cmd.exe`, `.cmd`, `.bat`, `python.exe`, `python3.exe`.
actor clark-h1
SG-0032026-10-30
NO AUTOMATIC WINDOWS RESTART, ever. Restarts are the owner's, manual. The designed restart process caused hours of recovery and was the initial cause of the stand-down.
why Owner, verbatim: "my decas=des of real world experience say that the restart process automated isn't going to work with out a ton of research we don't have ttime to do."
scope All hosts. The real answer is converting this box to Ubuntu.
actor bob
SG-0042026-10-30
REVIEW IS MANDATORY for every fix or change. The reviewer is an INDEPENDENT named agent, identified by NAME and ID, on a different model from the implementer. An agent may not evaluate its own work.
why Owner, verbatim: "IT IS 100% UNACCEPTABLE TO NOT HAVE A REVIEW OF A FIX OR CHANGE."
scope Every change. No exceptions for small changes.
actor bob
SG-0052026-10-30
An acceptance test for a Hermes change runs with the LIVE venv's python and reports `hermes_cli.__file__` alongside the result.
why A worker reported DONE with evidence that genuinely passed — inside its own workspace, running its own patched CLI, while the live install was untouched.
scope All Hermes installation changes.
evidence See C-001 and C-002 — two wrong explanations for this preceded the measured one.
actor clark-h1
SG-0062026-10-30
Every command-line flag in a plan is verified to exist with `<tool> --help` BEFORE the plan is approved.
why Tranche 1 plans contained two invented flags (`--purge-identity`, `-q`). They sat in cleanup steps, so the failure would have been silent residue, not an error.
scope All execution plans (Execution Plan Template, gate item 8).
actor clark-h1
SG-0072026-10-30
Never pass `skills=[...]` on a card without first proving that exact skill resolves on the ASSIGNEE profile. A forced-load failure kills the worker at init and burns the whole retry budget.
why Two workers died this week with `Unknown skill(s)` on a skill that was ambiguous (local vs shared name collision).
scope Every Kanban dispatch.
actor clark-h1
SG-0082026-10-30
No profile SOUL and no skill may name a RETIRED path, a RETIRED agent name, or a DEAD endpoint.
why Manifest Eric wrote deliverables to `G:\My Drive` because his SOUL line 77 told him to. The agent followed its configuration correctly; the configuration was obsolete.
scope All profiles and skills. Retired so far: `G:\My Drive` (storage), `dev-kat` (agent name).
actor clark-h1
SG-0092026-10-30
Hold work with a BLOCKED PARENT, never by parking it in `triage`. The auto-decomposer treats `triage` as a dispatch trigger.
why At 07:16 the decomposer decomposed a triage card and dispatched children outside the 19:00-07:00 work window.
scope All Kanban work-holding.
actor clark-h1
SG-0102026-10-30
A credential value is NEVER written into an artifact. Reference credentials by name and location only. A token read for one operation is not written back into any dump.
why A live HAP bearer token sits in two scratch artifacts, one of them a cron-jobs backup.
scope All agent output, all reports, all dumps.
note Owner accepted the existing exposure until Factory 1 is in production; keys are rotated and protected then. Logged, not escalated.
actor bob
SG-0112026-10-30
Every dispatch card names its skills via `skills=[...]`, and every card carries its spec in the `body` field in the SAME create call.
why Skill loading is advisory — nothing forces a skill into context, so an agent that does not load it improvises. The PEER-1 worker blocked and improvised while the answer sat in an existing skill. Separately, 6 cards were created bodyless and their specs had to be attached as comments.
scope Every card clark-h1 creates.
actor clark-h1
SG-0122026-10-30
A CARD MUST FIT ITS BUDGET. State the wall-clock budget in the card, and if the work needs more than ~100 turns it is split into two or more cards. Investigation and mutation never share a card.
why CRED-1 mixed investigation, credential creation, repointing and proof across 3 profiles in one 60-minute card — 4 phases, and it died at the iteration cap with the mutation half-applied.
scope Every card clark-h1 creates. This is the third instance of the same class (see D-003).
actor clark-h1
SG-0132026-10-30
A SCHEDULED TASK IS VERIFIED BY WHETHER IT DID ITS WORK, NOT BY ITS EXIT CODE. Trigger it, then confirm the ARTIFACT it is supposed to produce actually appeared with a fresh timestamp.
why `F1-StateDB-Backup` returned 0x0 for two days while producing nothing, because its script was missing and its wrapper lived in a pruned directory. An exit code is not evidence.
scope Every scheduled task and every automation with a side effect.
actor clark-h1
SG-0142026-10-30
NOTHING THAT A SCHEDULED TASK DEPENDS ON MAY LIVE IN `cache/scratch/` — that directory is pruned on idle. Task scripts and their wrappers live in `scheduled-tasks/`.
why The `F1-StateDB-Backup` wrapper was written into scratch, pruned, and the task silently became a no-op.
scope All scheduled tasks, all cron scripts.
actor clark-h1
SG-0152026-10-30
A CARD IS NOT COMPLETE WHILE ITS DELIVERABLE IS STILL DUE. A correction posted to a completed card MUST be accompanied by a new card in the same turn, and no deadline may be reported as on-track unless an OPEN card exists against it.
why A manifest card closed at 09:30 against a 17:00 deadline. The review corrections posted minutes later reached nobody, and the item sat ownerless for over an hour.
scope Every deliverable with a future deadline.
actor clark-h1
SG-0162026-10-30
A SELF-REFERENTIAL VALUE IS NEVER STORED INSIDE THE ARTEFACT IT DESCRIBES. A file's own size, hash or line count goes in the REPORT, not in the file.
why `vFinal.md` misstated its own byte size, because correcting the text changes the size again — the value can never be exactly right in one pass, so it is always a claim rather than a fact.
scope All generated documents and reports.
actor clark-h1
SG-0172026-10-30
BEFORE PASSING `skills=[...]` ON A CARD, RUN `skill_audit.py --check <assignee> <skill>`. It must return OK. AMBIGUOUS or NOT FOUND means the card would kill the worker at init and burn the whole run.
why A forced-load failure is fatal and happens before the worker does anything. Two workers died this way in one week.
scope Every card that forces a skill. This is the mechanical form of SG-007.
actor clark-h1
SG-0182026-10-30
A REPORT MAY NOT CONTAIN A PASSING CHECK THAT WAS NOT RUN. If a check is not implemented, the report says `NOT IMPLEMENTED`. An aggregate line like "all verified" is permitted ONLY when every item is genuinely verified — any `UNKNOWN` or `NOT IMPLEMENTED` item forbids it.
why A hygiene report asserted "All green tasks verified fresh / task_issues: 0" while the tool contained no such check. Fabricated confidence is worse than a known gap.
scope Every automated report, every status line, every dashboard.
actor clark-h1
SG-0192026-10-30
WHEN A CARD DEMANDS A SPECIFIC PIECE OF EVIDENCE, THAT EVIDENCE IS THE COMPLETION CONDITION. No evidence, no completion — regardless of how good the summary reads.
why Three cards today were completed with a deliverable missing or a claim unbacked (D-016 the backup task, D-019 the file size, D-025 the cron job). In all three the evidence named in the card would have caught it instantly.
scope Every card with an evidence section.
actor clark-h1
SG-0202026-10-30
A RECURRING JOB MUST LIVE IN THE PROFILE WHOSE GATEWAY RUNS CONTINUOUSLY — never in a per-task worker profile. Verify a new scheduled job by TRIGGERING IT and reading back `last_status` plus a fresh artifact, from the profile that will actually run it.
why A job created in `david`'s store had a correct schedule, correct delivery and a real next-run time, and would never have fired.
scope Every cron job and scheduled task.
actor clark-h1
SG-0212026-10-30
AFTER CREATING OR CLONING A PROFILE, RE-RUN `skill_audit.py --json` AND COMPARE THE COLLISION COUNT AGAINST THE PRE-CLONE BASELINE. A clone is not complete until the count is unchanged.
why Cloning alfred silently took the fleet from 12 collisions to 13, because the clone carried local skill copies that collide with the shared tree it also inherits.
scope Every profile create, clone, import, or skill sync.
actor clark-h1
SG-0222026-10-30
ADDRESS A PROFILE BY ITS LOWERCASE ID IN EVERY EXECUTABLE COMMAND. The mixed-case name is a DISPLAY label only — it is never resolvable by `-p`, by kanban assignment, or as a wrapper. Any plan that renames profiles must include a display/id/alias/directory mapping table.
why A rename plan using display names would fail every verification step and, far worse, reassign kanban cards to a nonexistent profile.
scope Every profile rename, every kanban assignment, every spawn, every wrapper reference.
actor clark-h1
SG-0232026-10-30
A COMPLETION SUMMARY THAT NAMES A FILE MUST CONTAIN THE FILE'S LITERAL LISTING — `rclone lsl` or `ls -la` output showing real size and timestamp. A description of the file is not evidence it exists. And a completion event with `result_len: 0` must be treated as a FAILURE regardless of the summary attached to it.
why Four deliverables today were claimed and absent. In the fourth, the event log contained `result_len: 0` alongside a confident success summary.
scope Every card that produces a file. Every completion verification.
actor clark-h1
SG-0242026-10-30
KANBAN READS AND REASSIGNMENTS ARE ORCHESTRATOR-ONLY. A dispatched worker cannot call `kanban list` or `kanban reassign` (`HERMES_DELEGATED_CHILD_CONTEXT`) and there is no `sqlite3` fallback on this host. Any plan whose steps include kanban work must assign those steps to Clark-H1 explicitly.
why A worker-authored plan assumed it could reassign six profiles' cards. It could not.
scope Every plan involving card reassignment.
actor clark-h1
SG-0252026-10-30
ANY COUNT IN A PLAN IS A SNAPSHOT AND MUST BE RE-TAKEN AT EXECUTION, WITH THE TIMESTAMP RECORDED. Card counts move continuously — NAME-1 stated 7 cards for `manifest-eric` when the live figure was 9, then 10, and 41 for `david` when it was 28.
why Acting on a plan-time count reassigns some cards and strands the rest. A moving target must be measured at the moment of the move, not planned against.
scope Every plan that moves or reassigns cards, files, or agents.
actor clark-h1
SG-0262026-10-30
SCOPE A MIGRATION TO ONE ARTIFACT. When a change touches N objects across many surfaces, plan and execute ONE of them end to end, verify it, then template the rest from what survived. Do not plan N at once.
why Six renames in one plan failed independent review three times, each for a different reason, because the reference surface grew with every review. One proven rename produces a checklist that has met reality; six planned at once produces a document that has met a reviewer.
THE AUTHOR OF A PLAN MUST EXECUTE EVERY GATE COMMAND AND PASTE ITS REAL OUTPUT. A gate that has never been run is not a gate. Two verification blocks today were unexecutable while reading as correct — a stray quote in a heredoc, and a `.get()` on a JSON array.
why A safety check that throws fails OPEN: the plan is approved, the rename proceeds unchecked, and the check that was supposed to stop it never ran.
scope Every plan with gates, checks, or verification steps.
actor clark-h1
SG-0282026-10-30
A ROLLBACK THAT RESTS ON A GIT BASELINE MUST SATISFY TWO CONDITIONS: (1) `git status --porcelain <file>` is EMPTY before the change begins — uncommitted work in that file means a `git checkout` destroys someone else's fix; (2) the baseline hash is recorded AT EXECUTION with a timestamp, never copied from a plan. A plan-time hash is a snapshot and HEAD moves.
why A rollback citing HEAD as `16652eea18a` would have deleted 342 uncommitted lines of live code and reported success.
scope Every plan with a git rollback. Every destructive action resting on a recorded baseline.
actor clark-h1
Discovery / defect (42)
D-0012026-10-30 07:16open
The auto-decomposer decomposed a `triage` card and dispatched its children outside the work window.
guard SG-009
fix (a) make the decomposer window-aware; (b) hold work with a blocked parent, never in triage.
D-0022026-10-30 07:16open
Two children were assigned to profiles holding expired credentials (`hermes-expert`, `clark-h1-2`). Assignment is by profile name with no credential check.
guard See D-012 / CRED-1.
fix (a) pre-dispatch credential probe; (b) exclude direct-provider profiles from assignment until repointed.
D-0032026-10-30 04:54open
A review card ran 2,729 s against a 2,700 s cap; its cleanup ran as a final phase and never executed, leaving ~40 test profiles on disk.
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.
D-0042026-10-30 02:20fixed
A worker reported DONE with evidence that genuinely passed — inside its own install-environment workspace, where its patched copy of the CLI was executing. Against the live install the defect was unfixed.
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.
D-0052026-10-30 06:35open
A review card carried `skills: [...]` naming a skill that was ambiguous on that profile; the worker died at init and the whole retry budget was spent.
guard SG-007
fix (a) fix loader precedence; (b) never pass `skills=[...]` without a forced-load test on that profile for that skill.
D-0062026-10-30 04:00open
Three different causes (interpreter path, TPM limit, expired key) are all reported with ONE identical sentence: "the provider rejected this profile's credential or model".
guard —
fix Read the worker's LAST output line before acting. Keep the three-cause triage table current.
D-0072026-10-30 08:40fixed
A console window on the owner's desktop, every 15 minutes, up to 7 minutes at a time — the task `HermesCommsHeartbeatJames`. 518 consecutive failures against a receiver session from September and a listener on port 8643 (the gateway listens on 8642).
guard SG-002
fix Stopped, process tree killed, task disabled — not hidden, because it was not necessary.
D-0082026-10-30 08:52fixed
Manifest Eric wrote tranche 1 execution plans to `G:\My Drive` — a mount retired 2026-08-19. His SOUL line 77 instructed it. He followed his configuration correctly; the configuration was obsolete.
guard SG-008
fix SOUL rewritten and verified live. Plans retrieved and re-homed to R2. Audit every profile SOUL for obsolete storage paths.
D-0092026-10-30 09:02fixed
Tranche 1 plans contained two invented CLI flags: `hermes profile delete --purge-identity` (only `-y/--yes` exists) and `-q` (only `-z/--oneshot` exists). Both were in TEST AND CLEANUP steps, so the failure would have been silent residue.
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).
D-0102026-10-30 09:50open
A live HAP bearer token sits in `cache/scratch/peer-task/get-thread-result.json` and in `pre-live-backup/clark-h1-jobs.json` (a cron-jobs backup) — inside a scratch dir that is pruned on idle.
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.
D-0112026-10-30 10:10documented
WHICH TREE RUNS IS DECIDED BY THE INTERPRETER, NOT THE DIRECTORY. A sandbox venv imports its own `workspace/hermes_cli` from ANY working directory, because its `__editable__.hermes_agent-0.0.0.pth` runs an editable-install finder on `sys.meta_path`. `sys.path[0]` is empty — the CWD is not on it.
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.
D-0122026-10-30 10:15open
SKILL NAME COLLISIONS MAKE SKILLS UNLOADABLE. `development-rules` exists as FOUR divergent versions across 9 profiles plus a fifth in `shared-skills`; `hermes-profile-management` likewise across 4. Both trees are loader candidates, so `skill_view` REFUSES ("Ambiguous skill name... Refusing to guess") and a card forcing the name kills the worker.
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.
D-0132026-10-30 10:20open
THE HAP PEER REGISTRATION IS INERT. HAP is registered in `peers.json` v1-2, but the send tooling selects peers by `meta["profile"]` and the HAP entries carry no profile field — so they are SILENTLY SKIPPED. No crash, no routing.
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.
D-0142026-10-30 10:25documented
HAP workspace A (`cmrtwavar03yq06adf9w15vcm`) is DORMANT and delivery to it fails — but this was already documented, and it is NOT the review path.
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
D-0152026-10-30 10:20fixed
A CARD THAT NEEDS MORE THAN 150 TURNS IS DISCARDED ENTIRELY AND RETRIED FROM SCRATCH. CRED-1 (t_d2470a47) burned all 150 iterations in 2,165 s, was cut off mid-phase, and the dispatcher reported it as "timed out (max_runtime=0s)" — a misleading message that names a time budget when the real cause was the ITERATION budget.
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.
A SCHEDULED TASK REPORTED SUCCESS FOR TWO DAYS WHILE DOING NOTHING. `F1-StateDB-Backup` returned `0x0` every night, but its target script did not exist and its wrapper sat in `cache/scratch/`, which is pruned on idle. The task was structurally incapable of doing its job and nothing anywhere said so.
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.
D-0172026-10-30 10:26open
LOCAL BACKUP RETENTION IS MISSING. `state-db-backup.py` prunes R2 to 7 days (`RETENTION_DAYS = 7`) and deletes each raw `.bak` after gzip, but nothing prunes the local `.gz` files. Each is ~452 MB, written daily.
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.
A CARD CAN BE MARKED DONE WHILE ITS DELIVERABLE IS STILL DUE LATER. `t_541a51a2` completed at 09:30, but the actual deliverable — `vFinal` to the owner — is due at 17:00. Review corrections were posted at 09:32 and after, i.e. AFTER the card closed, so they reached nobody. The deadline item had NO OWNER for over an hour and nobody noticed.
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.
D-0192026-10-30 10:51fixed
A DELIVERABLE MISSTATED ITS OWN SIZE. `vFinal.md` reported itself as 15,837 bytes in two places; the actual file was 16,141. 15,837 was **v3's** size, carried forward — the worker re-read the PREVIOUS version and reported that number as the new file's.
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.
D-0202026-10-30 11:05fixed
`HERMES_HOME` IS THE PROFILE DIRECTORY, NOT THE INSTALL ROOT. The first run of the new audit tool reported "CLEAN — 0 profiles, 0 skill names" because it trusted `HERMES_HOME` (= `.../hermes/profiles/clark-h1`) as the root. It looked for `profiles/` underneath the profile itself, found nothing, and reported success.
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.
D-0212026-10-30 11:06open
950 RETIRED-TOKEN HITS ACROSS THE FLEET — overwhelmingly `G:\My Drive`, the storage mount retired 2026-08-19 — sitting in agent skill trees. Heaviest in `ac`'s tree, which is a profile that reviews work. These are skills that instruct an agent to write to a dead path.
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.
A DETERMINISTIC AUDITOR NOW EXISTS and predicted the exact failure that killed two workers. `scheduled-tasks/skill_audit.py` enumerates each profile's loader candidates, reports every skill name reachable from more than one of them, reports retired tokens, and validates a forced load BEFORE a card uses `skills=[...]`.
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.
A KANBAN CARD HAS BEEN SITTING AS `ready` SINCE 2026-07-16 AND CAN NEVER RUN. `t_f1fc32c9` ("LLM Costs") is **unassigned**, and an unassigned card is never dispatched. It is not work at all — it is a COMMENT SINK: the daily cost cron posts its report as comments on it. It has 12 comments spanning July to August.
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.
D-0242026-10-30 11:33open
A COST CRON HAS BEEN REPORTING A FAILED DEPLOY FOR TWO MONTHS. The last comment on `t_f1fc32c9` (2026-08-31) says: *"Deploy SKIPPED: wrangler OAuth invalid — refresh token rejected (invalid_grant since 2026-08-31 06:00Z)... Fix: run 'wrangler login' interactively."* **Wrangler works fine now** — the Change & Safeguard Ledger was deployed with it repeatedly on 2026-10-30 — so the note is stale and the deploy presumably recovered at some point without anyone updating the record.
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.
D-0252026-10-30 11:45open
THE HYGIENE REPORTER WAS ITSELF A SILENT FAILURE, AND IT INVENTED A PASSING CHECK. Card `t_b56fb549` reported *"Created deterministic weekly hygiene cron job"*. **No cron job was ever created** — 46 jobs in the store, the newest dated 2026-10-27, and no reference to the tool anywhere. The report and history were produced by running the tool twice BY HAND. Worse: the report states *"Task health: All green tasks verified fresh"* and the history records `"task_issues": 0`, but **`skill_audit.py` has no task-freshness check at all**. The line is hard-coded.
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.
D-0262026-10-30 12:08open
A SHARED UTILITY VANISHED AND PLANS KEEP REFERENCING IT. `r2_write_helper.py` — the local→R2 pusher that several execution plans call — **does not exist anywhere on this machine**. A fleet-wide search returns nothing: not in `scheduled-tasks/`, not in any profile, not in scratch. Separately, the HYGIENE-2 plan v2 calls **five** helper scripts that lived in `kanban/workspaces/t_ecc91453/`, and that workspace is now **empty** (the workspace is per-card and is emptied after the card closes).
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.
D-0272026-10-30 12:52fixed
A CRON JOB CAN BE CREATED IN A PROFILE STORE THAT NOTHING SERVICES, AND IT LOOKS CORRECT. HYGIENE-1b created `hygiene-weekly` (`7876a85afec7`, `30 7 * * 1`, delivery correct) — in **`david`'s** cron store. `david` is a per-task worker profile with **no gateway process**, so no scheduler reads that store: the job would have sat enabled with a correct `next_run_at` and **never fired once**. It was found only because I read the store file directly instead of trusting `cron list` in the current profile.
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.
D-0282026-10-30 13:46open
ALFRED NOW HOLDS THE SAME MANDATE AS `winston`. Winston's SOUL is a "Two-Way Editorial & Gatekeeper Engine (text-only, zero tools)" — inbound prompt compiler and outbound gatekeeper. That is exactly the role Alfred was created for. So the fleet now has `winston`, `manifest-winston` and `alfred` all descended from or holding that same mandate.
why it matters The owner created Alfred to AVOID duplicate-name confusion, and the duplicate capability now exists three times. Two agents that answer the same kind of request differently is worse than two with the same name, because the name at least told you they were related.
guard —
fix **Owner decision required — not a technical one.** Either `winston` retires now that Alfred exists, or `winston` moves to a different job. Until that is answered, `winston` cannot even be given a meaningful surname under the new naming policy.
D-0292026-10-30 14:05open
THE TASK-FRESHNESS CHECKER WORKS AND FOUND REAL FAILURES — BUT HALF ITS ALERTS ARE WRONG. First real run: 33 jobs, 18 verified, **8 stale**, 7 unknown. I checked all 8 by hand. **Four are false positives:** (a) Night Watch wake reported STALE 6.8h against max 1.0h — but the job runs `*/15 19-23,0-6` and is *correctly* idle at 13:00; (b) Session Archiver reported 'artifact not found' — the archive exists on R2 with 2026-07, 2026-08, archive_index.db; the spec demanded JSONL specifically; (c) Weekly R2 Backup Cleanup reported '235193.8h ago' (~27 years) — a fabricated age from a path that does not resolve; (d) State capture monitor reported STALE at 2.2h vs 2.0h — jitter on an hourly job.
why it matters A weekly report that cries wolf on half its alerts trains the reader to ignore it, which is the exact failure this job exists to prevent. Worse than the false positives is (c): a confidently wrong number. An unreadable path must say so, never produce a plausible figure.
guard SG-018
fix Card `t_ab40f487`: window-awareness (age measured against the most recent expected run, not wall-clock), jitter tolerance, never report an age you could not read, artifact specs that match reality, and HTTP checks that separate reachability from TLS failure.
D-0302026-10-30 14:05open
STALWART MAIL HAS AN INVALID TLS CERTIFICATE. `curl https://mail.atl-ga.com:8443/jmap/session` without `-k` returns **HTTP 000 in 0.22s** (TLS validation failure); with `-k` it returns **HTTP 200 in 0.23s**. The server is healthy; its certificate is not trusted by the client.
why it matters Every client that validates certificates — a phone, a desktop mail app, an automated integration — will refuse the connection. A health check reported this as 'mail down', which is the wrong diagnosis and would send someone chasing the wrong fault. Certificate expiry is silent until a client refuses.
guard —
fix Identify the certificate's issuer, expiry and chain; then either fix the chain or make clients trust it deliberately. Do NOT simply add `-k` to the health check — that hides the defect permanently.
CLONING A PROFILE MANUFACTURES A LOADER COLLISION BY CONSTRUCTION. `alfred` was cloned from `winston` with `--clone-from`, which copied winston's **entire local skills tree** — including `skills/autonomous-ai-agents/development-rules` — AND inherited `config.yaml` → `skills.external_dirs` → `shared-skills`, which holds its own `development-rules`. Two loader candidates for one name → the loader refuses to resolve. Fleet collisions went **12 → 13** on a profile that was supposed to change nothing about skills.
why it matters This is the exact defect class that killed two workers this week, reintroduced by the standard cloning path. Every future clone of a profile that has local skill copies plus external_dirs will do the same thing. And it is invisible unless someone re-runs the audit after the clone.
guard SG-021
fix Archived alfred's local development-rules (9 files) to R2 Profile Archive 20261030, removed the local copy, kept the shared one. `--check alfred development-rules` → OK; collisions back to **12**. Durable fix (a/b/c) referred to `ac` for a view: refuse-on-clone, skip-colliding-skills on clone, or rely on the fleet reconciliation.
evidence skill_audit.py --json: before 13 collisions (alfred local development-rules vs shared-skills), after 12.
D-0322026-10-30 14:35fixed
`hermes profile rename` LOWERCASES THE PROFILE ID; a mixed-case name becomes the DISPLAY name only. Tested live on a throwaway profile: `profile rename nametest Eric-TestName` → directory `profiles/eric-testname`, alias `eric-testname`, display `Eric-TestName`. So after renaming `system-designer` to `Eric-ChiefDesigner`, the profile is addressable only as `eric-chiefdesigner`.
why it matters Every executable command that needs to address the profile must use the lowercase id — `hermes -p eric-chiefdesigner`, `kanban reassign <task> eric-chiefdesigner`, wrapper `eric-chiefdesigner.bat`. The NAME-1 plan v1 used the mixed-case form throughout, which would have made all six verification steps unrunnable and — worse — would have reassigned board cards to a profile that does not resolve. Caught by testing rather than reasoning.
guard SG-022
fix NAME-1 plan v2 must carry a display-name → profile-id → alias → directory mapping table and use the lowercase id in every command. Renaming with the display form is correct; addressing by it is not.
FOURTH CLAIMED-BUT-ABSENT DELIVERABLE TODAY, AND THE RUN LOG SHOWS WHY. Card `t_f7648744` reported "CLONE-1 execution plan v1 written and uploaded to R2". **No such file exists** — verified against the full .md inventory of the day folder, a global filename search for 'clone-1'/'constructor', the card's own workspace (empty), and three local roots. The run event reads: `[run 71] completed {'result_len': 0, 'summary': 'CLONE-1 execution plan v1 written and uploaded to R2...'}` — **the run returned NOTHING and a confident summary was attached anyway.**
why it matters `result_len: 0` is a machine-readable contradiction sitting in the event log the whole time. The summary says success; the result is empty. Any completion check that reads the summary instead of the artifact will pass this every time. And `manifest-eric` was still on `max_turns: 150` — the exact cap that cut CRED-1 off mid-work — while `david` and `ac` had been raised to 300.
guard SG-023
fix Two changes. (1) `manifest-eric` and `manifest-scott` raised to `max_turns: 300` (backups kept in scratch config-backups). (2) Cards that name a file must carry the **literal listing** of that file in the completion summary, not a description of it — `t_aad73834` requires the `rclone lsl | grep` output as a completion condition. Write the artifact early, not at the end.
D-0342026-10-30 14:45open
`hermes kanban list` AND `hermes kanban reassign` ARE REFUSED INSIDE A DISPATCHED WORKER CONTEXT (`HERMES_DELEGATED_CHILD_CONTEXT`; `kanban.py:153`, `kanban_db.py:147`) — even without `--json`. The `sqlite3` CLI fallback that plans assume exists **is not on this host**. Measured by `ac` during the NAME-1 review.
why it matters ANY PLAN THAT HAS A WORKER CARD DOING KANBAN WORK IS UNEXECUTABLE. The NAME-1 rename plan assumed its executor could reassign six profiles' cards; it cannot. Every rename plan written for a worker will fail at the reassignment step — and a half-done rename with cards stranded on a dead id is worse than no rename. This is an architectural constraint, not a detail.
guard SG-024
fix Split every rename plan into (i) what a worker may do — profile rename, aliases, prose, verification reads — and (ii) what only the orchestrator may do — all kanban reads and all reassignments. NAME-1c is written that way. State the split in the plan, per step.
D-0352026-10-30 14:45open
`hermes profile rename` DOES NOT REWRITE CRON `deliver` TARGETS. Verified by live throwaway: the profile directory — including `cron/` — moves intact, `enabled`/`state` survive, but a deliver target is **left dangling as `bot-chat:<old-id>`**. Also established in the same review: `previous_names` IS maintained automatically (a throwaway with no profile.yaml gained `previous_names: [nametest-ac]`), and `migrate-identity` is a retry mechanism, not a required step.
why it matters A dangling deliver target means a job keeps running and delivers nowhere — a silent failure, indistinguishable from success. Separately, the NAME-1 plan's headline cron risk was **false**: it claimed 26+ jobs delivering to `bot-chat:clark-h1`; measured, the exact string appears **once**, `bot-chat*` fleet-wide is 17, and **none of the six profiles is exposed**. A fabricated risk inflated the plan and hid the real one.
guard SG-025
fix Any rename plan must check each profile's cron jobs for deliver targets naming that profile, and rewrite them. The NAME-1 v3 plan carries this.
D-0362026-10-30 15:00open
THE LIVE PEER-ROUTING AUTHORITY SITS IN A PRUNABLE DIRECTORY. `ac` established that the `peers.json` which actually routes agent-to-agent replies is **`profiles/clark-h1/cache/scratch/peer-task/peers.json` (v1-3)** — in `cache/scratch/`, which is pruned on idle. The copy in `shared-skills/` (v1-1) is NOT the authority. The NAME-1 plan spent three revisions editing the wrong file.
why it matters Routing silently dies when scratch is cleaned, and nothing would report it — the failure looks like a peer that stopped answering. This is SG-014 again, now on a live message path rather than a backup. It also means three reviews of a rename plan were assessing edits to a file that does not decide anything.
guard SG-014
fix Move the routing authority to a durable location and make the path explicit in the agent-to-agent-comms skill. Its own card.
D-0372026-10-30 15:00open
PROFILE IDS ARE HARDCODED IN TOOLING AND LIVE TASKS — THE REFERENCE SURFACE IS WIDER THAN `profiles/`. Measured by `ac` during the NAME-1 round-2 review: `scheduled-tasks/task_freshness.py` hardcodes `profiles/system-designer/logs/comms-heartbeat.log` and `profiles/david/cron/jobs.json` (the freshness checker built TODAY); the live scheduled task `HermesCommsHeartbeatJames` (state Ready) runs `heartbeat_james.cmd` with a literal `--receiver-profile system-designer` and reads `profiles/system-designer/{config.yaml,state.db}`; and **9 prompt-injected SKILL.md files** across `skills/` and `shared-skills/` carry old profile ids. Every verification grep in the rename plan searched only inside `profiles/`.
why it matters A rename that misses these leaves a live scheduled task pointed at a dead profile and a freshness checker reading a path that no longer exists — both fail silently. Skill prose matters most: it is injected into agent prompts, so a stale id there is an instruction, not documentation.
guard SG-026
fix Any rename or reference sweep must grep the whole Hermes root, not `profiles/`. `task_freshness.py` must resolve profile ids from config rather than hardcoding them. Both have their own cards.
D-0382026-10-30 15:00fixed
`hermes kanban list --json` PRINTS A TOP-LEVEL JSON ARRAY, NOT AN OBJECT (`kanban.py:430`). Plans that parse it as `d.get('tasks', [])` raise `AttributeError` on every run — the NAME-1 idleness gate was written that way and could never have executed. A gate that throws does not fail closed; it fails open, and the rename proceeds unchecked.
why it matters This is the second time today a verification block was unrunnable while reading as correct (the first was a stray quote in `python3 << 'PYEOF"`). A syntax error in a safety gate is worse than no gate, because the plan is approved on the strength of a check that cannot run.
guard SG-027
fix Parse the array directly. Every gate command in a plan must be executed by the author and its real output pasted — not reasoned about.
evidence `hermes kanban list --assignee manifest-eric --json` returns a top-level list; `d.get('tasks',[])` → AttributeError.
D-0392026-10-30 15:00fixed
A ROLLBACK COMMAND IN A PLAN WOULD HAVE DESTROYED 342 LINES OF UNCOMMITTED LIVE CODE. The CLONE-1 plan's rollback was `git checkout HEAD -- hermes_cli/profiles.py`, with its baseline cited as commit `16652eea18a`. But `profiles.py` was **uncommitted at that moment — 342 insertions ahead of HEAD**. That diff was the entire clone-identity fix applied earlier today (`_build_name_pattern`, `_replace_case_insensitive`, `_rewrite_soul_identity`) — the fix that makes a clone answer to its own name. Running the rollback would have deleted it, reported success, and left no copy anywhere.
why it matters This is the closest near-miss of the day. The rollback was written by a careful planner, reviewed by an independent agent, and both were measuring the same uncommitted tree — so the baseline hash looked correct. It was correct for the COMMITTED state and wrong for the LIVE state, and the difference was 342 lines of work that existed nowhere else. A rollback is a destructive action; a destructive action resting on a stale baseline is worse than no rollback at all.
guard SG-028
fix Committed the fix: `80d4d7ecc22`, 342 insertions, `hermes_cli/profiles.py` now clean. `git checkout HEAD` now restores rather than destroys. The plan is being reworked (`t_652dcb5f`) to require `git status --porcelain <file>` to be EMPTY before a change, and to record the baseline hash AT EXECUTION with a timestamp — never a hash captured at plan-writing time.
D-0402026-10-30 15:00open
13 FILES IN THE LIVE HERMES REPO ARE MODIFIED AND UNCOMMITTED, plus 6 untracked. The local patch set on `hermes-agent` (branch `main`) exists only in the working tree: `profiles.py` (now committed), `subagent_lifecycle.py`, `cron/lifecycle_guard.py`, `models_catalog_static.py`, `profile_channels.py`, `peer.py`, `web_server.py`, `test_async_delegation.py`, `daemon_pool.py`, `process_registry_notifications.py`, `terminal_tool.py`, `terminal_tool_guards.py`, and two docs. A stale `.git/index.lock` from **2026-10-25** (zero bytes, five days old) was also blocking commits.
why it matters Every one of these is a local fix that exists in exactly one place. Any `git checkout`, `git reset --hard`, or failed merge destroys them silently. The stale lock means commits had been failing for five days without anyone noticing — which is why the work accumulated uncommitted.
guard SG-028
fix Commit the remaining modified files deliberately, one themed commit at a time, after reviewing each diff. Do not bulk-commit blind. The lock is removed.
E-0012026-10-30 11:50documented
ISLAND-WIDE OUTAGE — 4 TO 5 HOURS EXPECTED. Owner reported a complete island-wide outage. This host runs on **satellite internet** and **solar / battery / generator power**. Precaution taken: state written to a resume note LOCAL FIRST at `profiles/clark-h1/RESUME-NOTES/RESUME-NOTE-20261030-1150-OUTAGE.md`, copied to the Desktop, then pushed to R2 at `3 Factory Operations/Resume Notes/` while connectivity still held.
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.
F-0012026-10-30documented
THE LESSON THAT KEEPS REPEATING: a plausible mechanism written down before it is measured is a CLAIM, not a finding — and it propagates straight into the fix. Three wrong explanations were recorded in one day (PATH, CWD, then a misread of a skill).
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.
Correction to the record (5)
C-0012026-10-30 10:05superseded by C-002
was recorded as The stale `hermes_cli` copy wins because of PATH ordering.
corrected to WRONG. `which -a hermes` puts the live venv first, and all three entry points report the live install directory. A PATH-keyed guard would have guarded nothing.
source Measured 2026-10-30.
actor clark-h1
C-0022026-10-30 10:05superseded by D-011
was recorded as The stale copy wins because the working directory is prepended to `sys.path`.
corrected to WRONG. `sys.path[0]` is EMPTY; the import is identical from `$HOME` and from the workspace. This correction was itself written without being measured — the same fault it was correcting.
source Measured 2026-10-30.
actor clark-h1
C-0032026-10-30 10:30corrected
was recorded as HAP workspace A is dead — which may explain why o5.5 has been idle.
corrected to WRONG ON THE INFERENCE. The dormancy is real and was ALREADY DOCUMENTED in the `hyperagent-integration` skill. The o5.5 review path is a different thread and was never broken. Two documented facts were misread as new findings.
was recorded as ~95 skills collide between loader trees.
corrected to WRONG BY ~45x. clark-h1's loader candidates are only its local tree plus `shared-skills`; the default profile's `hermes/skills` is NOT one. Real loader collisions: 2 (`development-rules`, `hermes-profile-management`). The other 93 are duplicate files in another profile's directory — a different, less urgent problem.
source `config.yaml` -> `skills.external_dirs` lists exactly one entry: `shared-skills`.
actor clark-h1
C-0052026-10-30 14:20corrected
I REPORTED ALFRED AS COMPLETE WITHOUT CHECKING THE COLLISION BASELINE — a check I had explicitly written into ac's review card, and then did not do myself.
why it matters I asked an independent agent to verify a thing I could have measured in one command, and did not measure it. Had ac not done its job, the regression would have shipped. The rule that an agent cannot review its own work does not mean the builder gets to skip the checks they delegate.
guard SG-021
fix Fixed and re-verified. The delegated check is not a substitute for the builder measuring before declaring done — it is a second pair of eyes on a claim that should already be true.