Last built 2026-10-30 10:51 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
16Safeguard in force
20Discovery / defect
4Correction 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 (16)
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
Discovery / defect (20)
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.
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 (4)
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`.