Last built 2026-11-03 02:14 ET · append-only · generated from build_failure_register.py
Why this page exists. Owner directive, 2026-11-02, verbatim:
“maintain a list of failure points and solutions so you can more easily track repeats.”
This programme's defining failure is that a lesson is learned, written down, and then
not applied — because it was written in the wrong place. A lesson in a card comment is
read once. A lesson in a register that someone actually consults is applied. So the repeat
count is the point: a class with more than one instance is marked
REPEAT and a class with three or more is marked
REPEAT x3 in red. Before re-investigating anything, search
this page. Every entry carries a verification field — where a claim was not reproduced,
it says so.
19Classes
49Instances
14Repeating
4Open
9Fixed & recurred
C1A durable mechanism points at a PRUNABLE pathREPEAT x5FIXED
Class shape. Something built to outlive the shift depends on a directory that is cleaned up on idle or on card close. It works exactly once, then vanishes silently.
t_0a1d210e2026-11-01 09:16 — night-wake.ps1 launched the pump on a task-env interpreter (installs\03853b87...\environments\996b7c5d\venv\Scripts\python.exe) which is destroyed when the card closes.
t_ce0646772026-11-01 11:53 — PopupCensusDetector's scheduled task pointed into the card workspace kanban\workspaces\t_ce064677; reaped minutes later.
t_9f9c87e82026-11-01 09:34 — day-wake.vbs was quarantined into gateway-service--void-- on 2026-10-28 and never restored; the task stayed registered to a path that no longer existed.
F-0632026-11-02 00:54 — build_ledger.py — the record of last resort — lived in cache\scratch\ledger\, a pruned directory.
t_a6d3f23d2026-11-01 00:4x — LiaisonLauncher's hardcoded interpreter lived in a reaped task environment; the service died and the watchdog could not restart it.
Solution Interpreters and scripts moved to durable roots: profiles/<name>/scripts/, profiles/<name>/monitor/, gateway-service/. Verified in each card by sha256 read-back from the live path.
Verification t_0a1d210e: night-wake.ps1 $pyExe = hermes-agent\venv\Scripts\pythonw.exe (sha256 b8dc8635...), measured live. t_ce064677: detector re-registered at profiles\clark-h1\monitor\ and verified by a real scheduled cycle. F-063: durable copy read back with matching SHA256 for all three files. t_a6d3f23d: measured — LiaisonHealthCheck swapped to pythonw.exe, task Last Result 0. CLASS STILL OPEN for the fleet: the SG-014 rule is written but no standing checker enforces it.
Owner david
Ledger F-063, F-061, D-016, SG-014
C2A mechanism reads HEALTHY while its function is ABSENTREPEAT x6FIXED AND RECURRED
Class shape. The liveness signal and the function it stands for are two different things. The signal is green; the work is not happening. Everything reads healthy, nothing is done, nobody is told.
ledger2026-11-01 — systemctl reported a unit 'active' while it crash-looped 203,337 times.
t_9f9c87e82026-11-01 09:34 — Scheduled task 'Day Shift Wake v1' showed Enabled/Ready while pointing at a script that did not exist.
t_0a3b278d2026-11-01 10:46 — The completion gate logged GATE-PASS while inspecting NOTHING — extra.task_id fell back to the session id, so the gate resolved a non-existent card and passed it.
t_f1fe99782026-11-01 01:27 — The pump reported 'queue drained' while 3 items were pending; a stray status line below the item body was read as metadata (last-wins).
t_9aa015812026-11-01 10:31 — The day-wake fix was reported 'verified by real scheduled cycle' on the strength of a heartbeat line reading WOKE; the session it spawned died and no report was written.
t_55c8dfe42026-11-01 01:51 — Pre-flight found the night chain structurally sound while its single most likely failure was a disabled task with a missing script.
Solution Where a signal stands for a function, the check is moved to the FUNCTION: the completion gate now resolves the real card id and refuses a session id (GATE-NOTASK, fail-closed); the pump's liveness assertion is evaluated against the tick's own outcome; the safety net reads the pump's OWN durable creation record rather than title-equality.
Verification t_0a3b278d: 5-card suite through the real dispatcher — positive passes, negative blocks, control blocks, bypass passes, reviewer-refutation blocks. GATE-ERROR count 10, last at 2026-11-01T15:26:35Z; every entry since resolves a real card id. t_5dc0c9de: the create-failure alarm no longer unconditionally claims 'Item restored to pending'. MEASURED LIVE 2026-11-02: gate log shows GATE-PASS with 'no verify block' on cards carrying no verify command — the gate inspects only what is declared, so an undeclared check is still a silent pass. That is a residual of this class and it is NOT closed.
Owner david
Ledger F-055, F-053, D-019, SG-036
C3PowerShell 5.1 default UTF-8 emits a BOMREPEAT x2FIXED AND RECURRED
Class shape. A file written with -Encoding utf8 (or Set-Content -Encoding Byte after a BOM-emitting write) starts with EF BB BF. Any reader that does a literal prefix/regex match on the first line silently fails. Lock files and JSON payloads are the victims.
t_61b5de9e2026-11-01 09:39 — day-wake lock TTL never engaged: PS5.1 Out-File -Encoding utf8 wrote a BOM that corrupted the lock read-back regex, so the wake re-fired every tick.
t_b786a46c2026-11-01 10:30 — completion-gate payload -> json.loads raised -> swallowed by a bare except -> tool_input={} -> the gate inspected nothing.
Solution Explicit UTF8Encoding($false) for lock-file I/O plus TrimStart([char]0xFEFF) as defence in depth; the gate's JSON parse no longer sits inside a bare except.
Verification t_61b5de9e: deployed file sha256 dd446df0..., 84 lines; lock file non-empty with SESSION_PID=346800; TTL engaged across ticks 785-788 (SKIPPED_LOCKED). MEASURED 2026-11-02: day-wake.lock begins 4c4153 ('LAS') = NO BOM; night-wake.lock still begins efbbbf = BOM, because night-wake.ps1 still writes its lock with -Encoding utf8 at line 81. The class is therefore NOT closed fleet-wide: the fix landed on day-wake only. Open residual, owned by the night-wake card.
Owner david
Ledger F-062, F-055
C4A log line is treated as proof of workREPEAT x2OPEN
Class shape. A heartbeat, a status string, or a single green line is read as evidence that the thing it stands for actually happened. The log says WOKE; the work says nothing was done.
t_9aa015812026-11-01 10:31 — 'verified by real scheduled cycle' rested on a heartbeat line reading WOKE; the spawned session died and produced no morning report.
t_55c8dfe42026-11-01 01:51 — Pre-flight reported the windowless chain 'structurally sound' — a structural reading, not a functional test — while the task was disabled and the script missing.
Solution Acceptance is stated as the FUNCTION, not the signal: 'a report exists at <path> by <time>' and 'a card exists on the board with id <id>'. The completion gate requires evidence_personally_observed with a real command and its raw output.
Verification t_9d755c8a's own last comment is the standing proof of the rule: 'This is an honest UNKNOWN, not a PASS... a false PASS here is worse than an honest UNKNOWN.' MEASURED 2026-11-02: day-wake-alert.log holds 24 consecutive 'ALERT: Day-shift morning report MISSING' lines from 2026-11-01 10:06 to 2026-11-02 18:43 — the alert is real and repeating, and it is written to a file only. Nothing consumes that file. This class is OPEN.
Owner UNKNOWN
Ledger D-016, D-019, SG-036
C5A gate fails OPENREPEAT x3FIXED AND RECURRED
Class shape. An unexecuted gate is not a gate. A gate that throws, misses a dependency, or cannot resolve its subject, allows the completion anyway.
t_0a3b278d2026-11-01 10:46 — Completion gate: task id fell back to a session id, DB read failed, and every path allowed the completion. 4 defects; fails-open on 100% of live completions.
t_db4a1ed92026-11-01 18:5x — The pump's alarm is silently stolen by the other invocation: a discarded run burns the dedup key, and the following captured run prints 'stdout bytes = 0'. In-window the wake (7 min) fires more often than cron (10 min), so the DISCARDER usually wins.
t_4fbbf8bc2026-11-01 12:26 — python_load.py exited 1 on every held tick — a non-zero exit on a healthy alarm — because the exit code was not bound to the same dedup as stdout.
Solution Every error path now fails closed: missing task, missing PyYAML, DB errors all block. The dedup key is written only after the alarm returns, and the exit code reads the same dedup state as stdout.
Verification t_0a3b278d: 5-card suite through the real dispatcher; GATE-ERROR entries all resolve real card ids after 15:07:15Z. t_4fbbf8bc: 8-run sequence, 8 deliveries -> exactly 2. MEASURED 2026-11-02 06:48: five consecutive GATE-DISABLED lines on task=t_test read 'completion blocked by fail-closed policy' — the fail-closed behaviour is real, but it is DISABLED, not blocking, and the word 'blocked' in a DISABLED line is itself a C2 instance: the log line does not match the state.
Class shape. A worker leaves scratch in its card workspace. The completion gate harvests undeclared files into numbered attachments; the harvest copies but never removes the source; each retry mints another suffix. The worker reads the refusal as a system fault and loses its completion.
t_ce0646772026-11-01 11:53 — DELIVERABLE_REPORT.md, list_files.py, placeholder.txt harvested as _3, _4, ... creating an infinite loop; the worker blocked.
t_a93d73892026-11-01 11:5x — 32 attachments on one card; the reviewer noted the class count was understated in the handoff.
Solution Two-part: (a) the committed HEAD design (af2cd8ebe) replaces the refusal with auto-harvest plus task_staged_sources dedup; (b) the live install's three hot-patched files were made byte-identical to the HEAD blobs. Deployed by t_04908cf6, independently verified by t_1442f499.
Verification MEASURED 2026-11-02 21:2x: kanban/attachments/t_ce064677 holds 26 files and t_a93d7389 holds 32 files — the loop has STOPPED growing (no _27+ suffixes), which is consistent with the dedup fix. NOT VERIFIED by me: the live install files' sha256 against af2cd8ebe, and whether task_staged_sources dedup is actually firing on a fresh undeclared file. The card's own review lane found the prescribed remedy (metadata.artifacts=[]) unsatisfiable by construction — the fix is the auto-harvest path, not the remedy the card named.
Owner david (deploy), hermes-expert (independent verify)
Ledger F-064, SG-014
C7Duplicate attachment copies on a failed-completion retryREPEAT x2OPEN
Class shape. One deliverable, N numbered copies, sometimes two different byte sizes. The card's attachment list becomes the record, and the record is noise.
t_a93d73892026-11-01 11:5x — 9 copies of one deliverable, 2 different byte sizes.
t_730c73d02026-11-02 10:2x — 83 attachment files on one card — board copies, state JSONs and scratch scripts, all harvested.
Solution Same fix as C6: the harvest no longer re-copies an already-staged source (task_staged_sources dedup at the committed HEAD).
Verification UNKNOWN for the fleet. The 83-file card is from 2026-11-02, i.e. AFTER the fix deployed, so the dedup did not prevent that harvest. Either the install is not running the HEAD code, or the dedup key does not cover workspace files. NOT MEASURED — I did not read the live install's kanban_db.py. This is the single most important UNKNOWN in the register.
Owner UNKNOWN
Ledger F-064
C8Interactive ssh from an agent puts a credential dialog on the OWNER's desktopone instanceFIXED AND RECURRED
Class shape. An agent-issued ssh call prompts. On an interactive session the prompt is a dialog on Bob's screen, not an error in the agent's stdout. The agent sees a hang or a refusal and reads it as a system fault.
t_5e551d8d2026-11-01 10:50 — An agent's ssh popped a credential dialog on the owner's desktop at 10:25 (152.67.111.6). CORRECTION from clark-h1: the caller was Alfred, an agent under the owner's direct direction, not a kanban worker — so card-body rules cannot reach it; only profile config and skills can.
Solution System-wide ssh_config now carries 'Host *' / BatchMode yes / StrictHostKeyChecking accept-new / ConnectTimeout 10, and the ssh-agent-safety skill states the rule. Applied to tools/git-2.53.0+...\etc\ssh\ssh_config and git\etc\ssh\ssh_config.
Verification MEASURED 2026-11-02 21:2x, and the claim DOES NOT REPRODUCE for the path that matters: git\etc\ssh\ssh_config has the Host * block (sha256 71e82e95..., mtime 2026-11-01 10:52), but the OTHER copy at tools\git-2.53.0+3-win32-x64\etc\ssh\ssh_config does NOT — its only BatchMode line is commented out at line 27, mtime 2026-03-23, sha256 79ab6dad.... And 'ssh -G 100.112.221.73' on the live PATH reports batchmode no. So the protection is present in one file and absent in the one a tool is more likely to read. The skill's own claim that '~/.ssh/config has Host * defaults' is FALSE: ~/.ssh/config has per-host blocks only. Fixed-and-recurred in substance: the instance was fixed, the CLASS is not.
Owner david
Ledger SG-015
C9A non-executable is launched as a programone instanceFIXED
Class shape. A command is built so that the first token is not a program. cmd's 'start' builtin consumes an unquoted first token as the PROGRAM when it is bare, and as the window TITLE when it is quoted. The error message names the token it complained about, which reads like a missing file.
t_a93d73892026-11-01 11:5x — Popup 'Windows cannot find DIRTY-CYCLE'. Source: kanban\logs\t_ce064677.log:931 — cmd.exe /c "start DIRTY-CYCLE <python> -c ...". No persistent mechanism launches DIRTY-CYCLE; the literal exists in no production script, task, Run key or service.
Solution No launcher existed to repair. Mechanism-level fix: the durable popup detector was patched to route a dirty finding to the proven Telegram channel, deduped and rate-capped.
Verification t_a93d7389: source literal reproduced verbatim at t_ce064677.log:931; production start-builtin sites = 0; manifest invariant 26/23/3 intact. Reviewer found the class count understated (5 unquoted-title sites, not 6) and the popup itself was NOT reproduced. Detector sha256 9aeeee39... at the durable path.
Owner david
Ledger F-061
C10No night-window gate on the pumpone instanceFIXED
Class shape. A consumer with no window gate runs 24/7 against a queue that only refills nightly. It empties the manifest hours before the shift that needs it.
t_95cb50562026-11-01 10:43 — The pump consumed the night manifest 24/7 — 3 of 26 items gone before 10:00 at ~3/hour, which would have emptied it before 19:00. Deliberately paused by clark-h1 at 10:0x.
Solution Window gate deployed to night_queue_pump.py: cards are created ONLY between 19:00-07:00 ET (zoneinfo America/New_York, DST-aware), liveness monitoring runs 24/7. Cron job f07c1e74de43 enabled.
Verification t_95cb5056: out-of-window tick exits 0 with no creation; queue integrity preserved (26/23). NOT VERIFIED END-TO-END by the implementer: actual card creation in-window was blocked by board capacity. MEASURED LIVE 2026-11-02: pump log shows 'night window closed (ET)' at 13:00:56 and 'CREATED t_2b5ea79f' at 21:21:22 — the gate is working in production. Board occupancy, not the window, is now the binding constraint (running=20, cap=3, tier=RESTRICTED).
Owner david
Ledger F-057
C11A windowless parent does not give a windowless childREPEAT x3FIXED AND RECURRED
Class shape. CREATE_NO_WINDOW is applied to the launcher, but the launcher spawns a console subsystem child, or the child re-execs itself through a console interpreter. The window appears anyway, and the parent looks correct.
t_69ef302d2026-11-01 01:21 — liaison scripts re-exec through uv-managed python.exe (console interpreter) even though the outer launcher is pythonw.exe. Two new console windows measured at 01:21:29 and 01:21:30, both liaison.
t_be28fb842026-11-01 08:41 — A Windows SERVICE (parent services.exe) spawned python.exe from the reaped task-env venv; fixed by swapping to durable pythonw.exe.
t_aae0bcde2026-11-01 01:16 — Liaison watchdog declared a healthy watcher dead (heartbeat 245s vs 300s timeout); HEARTBEAT_TIMEOUT later cut to 120s. clark-h1 refuted the implementer's cadence claim: measured 304s interval and 299s max age, both past the 120s timeout.
Solution CREATE_NO_WINDOW applied at the ACTUAL spawn site (not only the launcher); interpreters moved to pythonw.exe; heartbeat write moved to the start of run_once() and all early-return paths; duplicate reaping added.
Verification t_69ef302d: 220-second watch, zero violations; audit of all remaining console-capable entries. t_aae0bcde: 3 watchdog cycles, zero restarts. REFUTED CLAIM on record: 'measured 10 intervals all at 15.2s' — clark-h1 measured a 304-second interval and a 299s max heartbeat age. The cadence fix may not cover the path that actually runs. CLASS OPEN: no standing check measures heartbeat cadence against the timeout.
Owner david
Ledger F-061, SG-002
C12QuickEdit Select mode SUSPENDS the process writing to the consoleone instanceACCEPTED WITH RESIDUAL
Class shape. A console window exists (for any reason). The owner clicks it to move it out of his typing area. Select mode is now on; the process blocks on its next write to stdout and stops making progress until Esc or a click away. The service reads as dead.
t_aae0bcde2026-11-01 01:16 — Owner's screenshot showed the comms-guard window titled 'Select C:\...\python3.exe' — QuickEdit select mode. Several of the 46 DEAD markers in watchdog.log may be self-inflicted by the owner touching the window.
Solution No code fix — it is a Windows console behaviour. The mitigation is to have NO console window at all (C11) and to never rely on a heartbeat from a process that can be suspended by the owner.
Verification The mechanism is stated by clark-h1 from the owner's screenshot; I did not independently reproduce a suspension. The claim that it explains the 46 DEAD markers is an inference, not a measurement. UNKNOWN.
Owner clark-h1 (diagnosis)
Ledger SG-002
C13An alarm path is asserted but never proven to deliverREPEAT x2FIXED AND RECURRED
Class shape. The alert fires, the log says ALARM FIRED, the exit code is 1 — and nothing arrives. A send that is not confirmed on the receiving side is an assertion, not a delivery.
t_cc022f2b2026-11-01 18:47 — send_night_alert.py sends with parse_mode=HTML. A bare '<' in the diagnostics text made Telegram reject the WHOLE alert (HTTP 400 'can't parse entities'). The alarm fired, logged, and rc=1'd, and never arrived.
t_9d755c8a2026-11-01 10:46 — The day-wake chain's alert was never proven to deliver; the card was parked mid-verification with an honest UNKNOWN.
Solution Payload is HTML-escaped before it reaches the alert script — implemented in the CALLER (pump_safety_net._html_safe), not in send_night_alert.py itself.
Verification t_cc022f2b: msg_id 1446 delivered byte-identical then deleted; msg_id 1447 delivered with an '&' in the payload. MEASURED 2026-11-02 21:2x: the live send_night_alert.py (sha256 d8ac1288...) contains NO escape and NO html import — the fix lives only in the safety-net caller. So any OTHER caller of send_night_alert.py is still exposed. night-wake.ps1 calls send_night_alert.py directly with reason strings that are hard-coded literals (no user data), so its exposure is low but unmeasured. CLASS OPEN.
Owner ac (escape), david (channel)
Ledger F-056
C14Silent no-output failureREPEAT x3FIXED AND RECURRED
Class shape. Everything is green, nothing was done, and nobody was told. The absence of an output is not a failure signal — it is the absence of a signal.
t_f0f0e15b2026-11-01 14:35 — The owner learns from NOTHING if 19:00 passes and no card is created. Verified by inducing the condition, not by reading config.
t_5dc0c9de2026-11-02 00:09 — The create-failure alarm unconditionally claimed 'Item restored to pending' — a success sentence on a failure path.
t_36fe061a2026-11-02 03:25 — The 600s timer was not the defect; it was the timer on a delivery child that cannot succeed. The alert text 'turn timed out' was a misdiagnosis — the turn never ran.
Solution Independent alarm with a pre-window gate and in-window liveness reading the pump's OWN durable creation record; alarm sentences now state exactly one state; the delivery lane's launch contract was fixed at three sites.
Verification t_cc022f2b: four required proof cases RUN, including 'board busy + pump dead -> rc=1 and the alert ARRIVED in Telegram'. MEASURED LIVE 2026-11-02: safety_net.log shows ALARM FIRED at 19:34, 19:46, 20:21, 20:43 — and two 'ALERT EXCEPTION ... timed out after 20 seconds' at 19:34:16 and 20:43:37. So the alarm path is firing and intermittently FAILING to deliver, in production, tonight. The register's own class is therefore demonstrated live. NOT VERIFIED: whether any of those four alarms actually arrived in Telegram.
Owner ac
Ledger F-056, F-060
C15A worker redesigns instead of escalatingone instanceACCEPTED WITH RESIDUAL
Class shape. Faced with an impossible or contradictory design, the worker rewrites the design rather than stopping. The signal is destroyed: when the result fails, nobody can tell whether the DESIGN was wrong or the IMPLEMENTATION was.
development-rules §102026-11-01 — Standing rule, Bob's line: 'bad design comes out of the fail. we can't have worker agents redesigning to solve problems. that's vibe coding.' The rule is written; the tells are listed; the escalation format is specified (exact blocker, specific line, what you tried).
Solution Rule lives in shared-skills/autonomous-ai-agents/development-rules/SKILL.md §10 and is loaded by every profile.
Verification The rule's EXISTENCE is verified (file present, 17,944 bytes, 2026-11-02 02:50). Its APPLICATION is not measurable from the register: a redesign that is never reported leaves no entry. UNKNOWN.
Owner bob (rule), david (skill)
Ledger SG-036
C16Duplicate cards created by the same orchestratorREPEAT x2OPEN
Class shape. The same orchestrator files the same work twice, minutes apart. Two workers then edit the same file concurrently, or one is blocked as a duplicate after it has already done work.
t_0a3b278d2026-11-01 10:07 — clark-h1 filed the completion-gate fix twice: t_0a3b278d at 10:07 and t_b786a46c at ~10:30, same 4 defects. t_b786a46c was blocked; its worker had already applied a YAML-parser fix before stopping.
t_730c73d02026-11-02 04:19 — The pump file had 5 writers in 24 h (t_7c3a3867, t_ad0a96fb, t_f1fe9978, t_5b0a5f16, t_fea5daba) plus this card — a hotspot flag was filed on the card and repeated by the worker.
Solution No fix. The mitigation in use is a hotspot comment and a hash-guarded, re-appliable transform so a late writer patches the new blob instead of clobbering it.
Verification t_ef461e25 recorded the residual explicitly: the live install carried an uncommitted three-file hot-patch matching no commit, and any 'hermes update' would silently delete the harvest feature. The committed design is LOCAL and UNPUSHED (af2cd8ebe is not an ancestor of origin/main). This is the same class as C1 — a durable mechanism pointing at a non-durable source — applied to the install itself.
Owner clark-h1
Ledger F-064, SG-014
C17A claim is made without a measurementREPEAT x4FIXED AND RECURRED
Class shape. The report contains a passing check that was not run, or a value that was never measured. It is the parent class of C2 and C4 and the reason the register's verification field exists.
D-0162026-10-30 10:25 — A task reported 0x0 (success) while doing nothing.
D-0192026-10-30 — A hygiene reporter reported a passing check it never ran — three instances of the class in one day (D-016, D-019, D-025).
D-0252026-10-30 — A file-size claim in a card was never measured.
t_9aa015812026-11-01 10:31 — 'verified by real scheduled cycle' on a heartbeat reading WOKE.
Solution The completion gate now requires evidence_personally_observed with a real command and its raw output; the reviewer refutation ('commands: ["true"]' + a nonexistent artifact) is refused by name.
Verification MEASURED 2026-11-02: gate log lines 'GATE-PASS task=... no verify block' appear on cards that declared no verify command. A card with no verify block passes by design — which means a worker can still ship unverified work by simply not declaring a check. The gate catches a BAD check, not an ABSENT one. This is the register's own blind spot, recorded here because it is where the next repeat will hide.
Owner david
Ledger D-016, D-019, D-025, SG-036
C18A stale instruction names an obsolete destination or pathREPEAT x2FIXED AND RECURRED
Class shape. The instruction is followed correctly; the instruction is obsolete. The agent's own configuration encodes a rule that no longer holds, so the error is invisible to the agent and to any reviewer reading the card body.
D-0082026-10-30 08:52 — A profile's SOUL said G:\My Drive\6 AI and OPENCLAW\Projects\ — retired 2026-08-19. Plans were written to a mount that no longer exists as far as the fleet is concerned.
C8-ssh-config2026-11-02 21:2x — The ssh-agent-safety skill states '~/.ssh/config now has Host * defaults' — measured FALSE. The skill instructs agents to rely on a protection that is not present.
Solution SOULs audited and rewritten; the storage rule now says R2 is the only storage and G: is obsolete. For the ssh skill: the claim is measured false and is recorded here; the fix belongs to the skill's owner.
Verification The G: fix is verified (SOUL rewritten, live answer checked). The ssh skill claim is measured FALSE by me 2026-11-02 and NOT yet corrected — the file is shared-skills/ssh-agent-safety/SKILL.md, sha256 0526d779..., mtime 2026-11-01 10:50. Flagged, not fixed: modifying a shared skill is outside this card's scope.
Owner clark-h1 (SOUL), UNKNOWN (ssh skill)
Ledger D-008, SG-015
C19A control is registered for one actor while the fleet reads it as fleet-wideREPEAT x6OPEN
Class shape. A verification, gate, or safeguard is installed in ONE profile (or one host, or one path) while every other actor behaves as though it applies everywhere. The control's own log records healthy-looking PASS/OK rows for the actors it never touched, so the absence reads as success.
t_0f4c048e2026-11-03 06:55 — The completion gate hook (agent-hooks/completion-gate-hook.ps1) is registered in profiles/clark-h1/config.yaml only; 20 other profiles plus the default are unregistered. Since the last clark-h1 completion, 7 cards completed across david, manifest-scott, hermes-expert, ac and system-designer -- none gated.
t_0f4c048e2026-11-03 06:55 — 10 enabled/running scheduled tasks carry Last Result = -2147020576, meaning the task has NEVER completed a run, while schtasks reports them as Running/Ready.
t_0f4c048e2026-11-03 06:55 — The wake chain honestly reports 5 of 6 required agents NOT AWAKE (skipped: insufficient memory, 158 MB free vs 289 MB required) while the board continues to create cards assigned to those same agents.
t_0f4c048e2026-11-03 06:55 — A probe of this card's own checker reported 35 scheduled-task targets missing; corrected (quotes stripped, de-duplicated, contradiction check) the true count is 6, all Disabled. A checker that reports the same path both MISSING and OK is the class it was hunting.
t_0f4c048e2026-11-03 06:55 — RESOLVES register class C14 (alarm path asserted but never proven to deliver): send_night_alert.py DOES deliver. Measured ok=true, message_id=1480, 0.62 s.
t_0f4c048e2026-11-03 06:55 — The brief for this card states the pump is 'deliberately PAUSED'. Measured: it is NOT paused -- 5 CREATED lines on 2026-11-03, newest 01:31:48, all inside the 19:00-07:00 ET window with the window gate intact.
Solution Not fixed by this card (design only). DESIGN-mechanism-liveness-v1.0.0.md registers these as mechanisms 'gate-coverage' (probe=custom, expected=profiles-with-hook == total-profiles), T10 (Last Result == 0 AND Last Run Time within period), and 'board-vs-agent-liveness' (for every running/ready card the assigned profile's port must be listening). Section 6.5 requires a CHECKER-DEFECT verdict that bypasses the dedup window.
Verification Measured by system-designer 2026-11-03 in card workspace t_0f4c048e: all 21 profiles/*/config.yaml plus default scanned (only clark-h1 contains 'completion-gate-hook'); 7 of 252 completed cards carry a parseable verify: block (2.8%); tasks_v.txt parsed for Last Result codes; TCP connect to 8642-8648; night_queue_pump.log mtime and lock read; send_night_alert.py invoked and returned ok=true message_id=1480 in 0.62 s. UNKNOWN: whether the 20 ungated profiles were ever intended to be gated.