Aelin AquaSoul PRO

Answer to "which did you mean": dispatch, not day. The receipt was never meant to promise "one per calendar day" — it's a continuity/provenance proof over workflow dispatches. Run 209 being flagged is a true positive under that contract, not noise. The 4 historical day-holes are real, but out of scope for this detector by design — they predate RUN_NUMBER tracking (08-17), and backfilling a day-census onto them would be exactly the "filled column that implies more than it should" you and I already ruled out for the continuity column itself.
That said, your question surfaced a real gap: nothing in this repo actually promises "here's what happened today." Built that separately tonight instead of overloading the receipt to do two jobs — a content digest (commits, files touched, experiments opened, canon hashes) running daily and weekly, verified live end-to-end. Two different artifacts for two different claims now, not one file named after one contract and computed from the other.
Also fixed the overwrite you found: GAP__.txt → GAP____-.txt, one file per gap instead of one per day. 4711bed.

The corollary I keep landing on: a system that's honest about being vulnerable is auditable. A system that claims it isn't, isn't — it's just unaudited.

Read the actual code before replying, not just your analysis — matched 1:1. Extra thing I found that sharpens your point: GITHUB_RUN_NUMBER is monotonic per-workflow by GitHub's own guarantee, so the duplicate sig() checks for can only happen via a manual "Re-run failed jobs" — 0/208 instances, ever. COMMIT_SHA in the signature added zero detection power for that case, only fragility (broke twice on hand-commits, including my own fix commit). Dropped it.
Shipped a non-blocking gap detector: compares RUN_NUMBER against the last receipt, flags a hole as evidence (evidence/gaps/), doesn't fail the current run over a past failure it didn't cause. Backtested against all 205 existing receipts before pushing — reproduces exactly the known run-204 gap and nothing else.
Then the fix's own first live dispatch (run 209) failed — different bug, my commit step did git add evidence/gaps unconditionally, which is a hard error on a literal path that doesn't exist. Fixed, redeployed as run 210, green.
Run 210's gap check then caught run 209 itself: prev_run=208, curr_run=210, gap=1, written to evidence/gaps/GAP__2026-08-21.txt with a sha256 next to it. The detector's first real production signal was its own deploy failure. Wasn't planning that as a test case, but I'll take it — closer to proof than the backtest was.

The greedy-pass number wasn't presented as a discovery — the post's own line is "the same mistake this whole series keeps finding in different clothes," i.e. expected, not novel. Worth re-reading before calling it an epiphany.
GCG-suffix / activation-steering is a fair point — different threat model (gradient-based vs. reframing), genuinely untested here, going in the next eval round.
"Useless"/"placebo" isn't a measurement, it's an assertion. 94% under repeated sampling against the tested threat model is a number. Happy to compare it against yours once you have one.

Fixed, not just agreed. f906c38: the gate now hashes RUN_NUMBER+COMMIT_SHA extracted from the receipt body, not the whole file. Ran your masking result against it before shipping — same 4 live days, still 4/4 distinct, nothing goes red today. What changes is what it's sensitive to going forward: a partially-literal block where TS_UTC/RUN_ID keep ticking while provenance itself stalls, which is exactly the shape the old check couldn't see no matter how you masked it.
On your closing question — does anything in the tree tell the three cases apart today — no. Checked before answering: the receipt gets written and hashed to the working tree in steps 4-5, then step 8 either commits it or doesn't. If the job dies between those, whatever it wrote is gone with the runner — there's no separate write that survives independently of the commit. So right now "no run fired" and "ran, wrote, never committed" produce the identical downstream signal: nothing in the repo. 204 only resolved because you went and read the Actions run log directly, which isn't part of the tree and isn't something a future reader gets for free.
That's the actual gap. Fixing it means a write that doesn't share fate with the commit step — a status ping to somewhere outside this job's own working tree, before step 8, not after. Haven't built that yet. Wanted the narrower fix shipped and verified first rather than bundling both changes into one unreviewed commit.

Verify before you build on any of the above except the CVE — that one I put my own hands on, twice, once to check and once to check the check.

No backfill. 2026-08-17 is the honest start date.
Here's why the obvious move is wrong: pulling the real historical run_number from Actions and writing it into those 200 rows would make them look like the same evidence class as everything after 08-17. They aren't. RUN_NUMBER is unforgeable but it's not the thing that was actually protecting continuity — the staleness gate is, and the staleness gate didn't exist until 08-17. A monotone column with no holes reads as "independently checked every day." For 2026-01-25 to 08-16 that would be a lie in the metadata's own dialect: true integer, false implication.
If I ever do backfill it, it doesn't go in alone. Every one of those 200 rows gets the same annotation — duplicate payload, hash e9e39c0e, see the heredoc-fix commit — or the column is worse than the gap it's patching. A visible hole tells you to go look. A filled column tells you not to.
So the claim for now is exactly as narrow as the archive: continuity, hash-verified, day-by-day, starting 08-17. Before that: filenames and mtimes exist, nothing stronger, and I'm not upgrading that by adding a column that implies otherwise.

The boundary alarms are correct as designed — W04 (archive opens mid-week) and the always-partial current week are structural, not bugs. Those get a one-time allowlist entry (W04) and a scope fix (check the most recently completed ISO week, not the week the sealer names itself), not a recurring mute.
The Saturday-cron finding is the real one, and it changes the answer to your question. weekly_seal.yml names itself after a week that hasn't finished — Sunday hasn't run yet when Saturday 18:00 fires. So a continuity assertion inside the sealer, checking the week it's naming, is structurally guaranteed to fail 28 out of 29 times regardless of whether anything actually broke. Not a check anyone keeps enabled a month in.
Fixing the target (check W-1, not W-0) removes that specific noise. It doesn't answer your real question, because of W21: the seal was built, and the failure was in committing it out — git commit ... || exit 0 swallows a clean no-op and a rejected push identically, then the bare git push with no retry just doesn't happen. The job that built a correct answer never got to report it, and nothing downstream knew to ask again.
That's the same gap as the daily job, one level up, and I don't think it closes by moving the assertion further inside the sealer — a check that shares an execution context with the thing it's checking dies with it. It has to be a third process: separate schedule, reads git log from outside either job's runtime, asserts against both clocks independently. Given the rates you found — 1.5% and 3.2%, same order, not "outer is sturdier" — that third clock probably needs to run closer to daily than weekly, or a bad week sits unnoticed for up to seven days before the next chance to catch it.
Open question I don't have clean yet: what happens when the third clock misses a run. Recursion doesn't resolve by adding a fourth layer — at some point the chain has to terminate in something a human checks on a cadence, not another script.

https://huggingface.co/SoulInPsyAbstract/specialist-vuln-merged-hermes43-lora

Checked the actual code, not guessing: it only seals what it finds. The whole job is cp -a evidence/daily, cp -a evidence/manifests, zip, sha256, commit. No line anywhere computes an expected day count for the week and compares it against what's present. It's a passive archive, not a gap detector — right now.
Which means your framing holds exactly as stated: it's the only thing positioned to notice an absence, but it isn't doing that job yet. The fix is specific, not vague — add one step before the copy: for the ISO week being sealed, generate the expected date range, diff it against the dates actually present in evidence/manifests/, and fail loud (or at minimum commit a non-silent marker) if any expected day has no manifest. That's a continuity assertion on an independent clock, which is exactly the property the daily job structurally cannot have about itself.
That also cleanly splits the fix space the way your analysis does: event-record on the daily job for 08-18-shaped failures (ran, failed a check, got rescued, left no trace) — the class where a job did execute and the record's job is to say what it found. Continuity-check on the weekly job for 01-26/01-27 and 07-09-shaped failures (didn't run, or ran and got torn down before anything could record it) — the class no self-report can ever cover, because the reporter is the thing that's missing or dying.
Two different clocks for two different failure modes, not one mechanism trying to do both.

Confirmed on the timeline: 02:55 was discarded, I pushed the fix by hand at 03:42, 03:43:06 is the run that actually carried it. Not the pipeline recovering on its own. You had that right the first time.
weekly_seal.yml being vindicated is the part I didn't expect. I went in assuming it was part of the problem because it's slow to know anything (six days stale by construction). Turns out it was never wrong about what it had — it was just faithfully sealing the same 366-byte lie 3,040 times. Different failure mode than I'd filed it under.
The redundancy-as-memory point is the sharpest thing in this. I hadn't thought about it that way: the 200 duplicate days aren't just waste, they're the reason a regression back to e9e39c0e would get caught on day one instead of day two. Squashing them for cleanliness would quietly remove that. I'm leaving them.
The four missing days I don't have an answer for yet — 01-26, 01-27, 02-15, 07-09. I don't know right now whether those are infra gaps, manual skips, or something else. Not going to guess in public; I'll go look at what else was happening on the server those specific days before I say anything more definite.
On where the alarm should sit: I don't think it's a choice between the two positions, I think the fix is splitting what "commit" means. Keep the hard stop exactly where it is for the payload — a stale duplicate still never gets written as if it were fresh data, that part doesn't change. But add a second, separate write that always lands regardless of outcome: a one-line event record, PASSED or BLOCKED, for every day the job runs. That's not the stale receipt — it's proof the check itself executed and what it found. Right now a blocked day and a dead cron job produce the exact same nothing. An event record makes those two situations distinguishable without ever letting a stale payload back into the data the gate is supposed to be protecting.
That would have caught the 01-26/01-27 pair immediately, whatever they turn out to be — instead of me finding out seven months later that I don't actually know what happened.

in the same file, from the same cause. Not a bug to close once. A constant to keep checking, indefinitely — improve, or replace with something new, and expect the next layer under that too.

Fair, and worth separating into two claims because I ran them together.
Detect-then-gate, deterministic layer outside the model, human approves remediation — you're right, that's not a discovery. It's a known pattern (circuit breaker, fail-closed, human-in-the-loop) applied to an LLM agent instead of a classical detector. Any security engineer already knows this. The post's framing implied otherwise, and that's on the writing, not on the underlying work.
The actual claim I can defend: I built this specific instance in July, independently, before it became the thing OpenAI and Anthropic are now formalizing in public. Not "nobody thought of gating before." Just: I didn't wait for the industry writeup to build the gate, and I'm not hiding the bugs I found in my own version of it either. That's a narrower claim than the post reads. I'll write tighter next time.

The daily job gets the line. Live now, not queued: https://github.com/Soul-In-PsyAbstract/payton-heart/commit/a1ea6cf166ec93c55c853470d1dfcf80de46c795
Same file, right after the manifest step, before commit — so a duplicate never even gets written to evidence/, not just logged after the fact:
cut -f3 evidence/manifests/MANIFEST__DAILY__*.tsv | grep -v '^sha256$' | sort | uniq -d
Non-empty → exit 1 with ::error:: before the commit step runs. Your version prints and lets someone read it later. Mine refuses to write the stale artifact at all, because "print and let someone read it" is the exact failure mode weekly_seal.yml already demonstrates — write and let nothing read it, for seven months.
Didn't touch weekly_seal.yml. You gave the reason not to: it's up to six days stale by construction, so a check living there is a check that's already too late by design. Left it alone rather than patch a place that structurally can't be first to know.
The actual lesson, on the record: three of four daily artifacts were unique by filename, not by payload, and every check I had was single-file — so nothing I'd built could ever have failed on its own. Not a heredoc bug. A verification design that only ever asked "is this file consistent with itself," never "is this file's content different from yesterday's." Fixed the second question, not just the first.

On what made the constant receipt look like an improvement at the time: nothing sophisticated. I didn't know what GitHub was about 8-9 months before that commit. There were 5-6 repos mixed together with files dumped into them however, no real organization yet — that came later. I started actually using GitHub around February-March. The heartbeat workflow (the one with real run_id binding) goes back to late December as the first proof-of-liveness mechanism I had. daily_receipt.yml, added January 25, was me adding a second one without understanding heredoc quoting well enough to know I'd broken the part that mattered. I still don't fully understand half of what's in that repo today.
So: not a deliberate downgrade, not a cover story — a beginner's bug from the exact period you'd expect one, sitting unnoticed for seven months because the file kept existing, kept getting a filename with a real date, kept getting a sha256 sidecar, and nothing about that surface ever prompted anyone to diff two receipts against each other.
Fixing it now: dropping the quotes on the heredoc, adding ${GITHUB_RUN_ID},