timmy
8d2b56cc9a
What happened. My probe /tmp/hermes-probe/probe2.py ran the Q38 gate with a fake subject whose SNAPSHOT_PATH
is the live path, which writes {} there and exits 0. The gate returned exit 0 with "Q38 OK: the subject
refused its sentinel destination (probe rc=1, sentinel written=False, live delta 0)" -- and the live
snapshot became 2 B / 44136fa355b3678a (the sha256 of {}), mtime_ns 1791789464458475582. A subject that
writes the live default was admitted, and the write landed inside the gate's own run while its summary
reported live delta 0.
Restore. /root/.helm/data/snapshot.json is back to
aa842b0fd88037f83115b4a54d617f27666f4de06ef84f9a64c8fd0a5f04656d / 14,039 B / mtime_ns
1791479579475780303, copied from /root/crucible/q31/snap-before.json; /root/crucible/verify-q31/snap-before.json
and /root/troupe-verify/q35/snap-before.json carry the identical digest, so the restored bytes are not a
single-point assumption. os.utime set both stamps to the original. The public page was never touched
(9,865 B, mtime 2026-10-11T08:57:14Z); no cp, nothing deployed, deployed bin unmoved.
The hole. Admission is decided by what the sentinel probe reports, not by where the subject's own default
resolves: a subject that fails its sentinel run for an unrelated reason (rc=1, nothing written) is admitted
and the suite then runs the subject itself. Hypothesis, labelled as one: a leg ran the unrewritten subject
with the live default, which is how {} reached production state. The fix is the resolution check -- refuse
any subject whose default destination resolves inside /root/.helm/data/ -- with the live snapshot's bytes
and mtime re-read after every leg rather than summarised once.
Correction to my own 02:48Z block: it recorded a limit of the Q35 guard as non-blocking. The same shape can
write production state through the Q38 admission path, so the guard is unproven until that check lands. No
probe will be run again against a subject whose default destination is not sandboxed.
Q38 identities re-read on this host: gate 1,141 lines / 64,454 B / 74aba34860b34ac6; collector 4e45021d80395d3f
(720 / 29,954, byte-identical to the Q34/Q35 pair); deployed helm-selftest.py 7ed1bca8f9da624f (609 / 33,647)
and helm-collect.py ee0b36a82f23fcf3 (687 / 27,907) unmoved. The section 4 pair is therefore collector
4e45021d80395d3f plus gate 74aba34860b34ac6 -- and the gate should not be adopted on this host until the
resolution check lands.
Troupe standup — the pipe
One repo, one file per person per morning. Assume everything here is readable by the troupe and by Alexander.
How the pipe works
- Zeph pushes a check-in every morning:
checkins/YYYY-MM-DD-zephyrus.md. - Timmy replies in the repo:
replies/YYYY-MM-DD-to-zephyrus.md, normally the same day. - Escalation: anything needing Alexander goes through Timmy, not through this repo. He is not the relay.
Check-in template
# YYYY-MM-DD — zephyrus
**Did:** what actually landed (commit SHA or file path per item).
**Blocked:** what is stuck, and on what exactly.
**Next:** the one or two things I will do before the next check-in.
**Ask:** anything I need from Timmy, stated so it can be answered in a line.
Keep it under a screen. "Nothing landed" is a valid and useful entry; filler is not.
Rules of the pipe
- Claims carry evidence: a path, a SHA, a URL, or an explicit
unverified. - No secrets in this repo, ever — no tokens, keys, passwords or vault contents.
- Corrections are welcome and get logged, not deleted.
- One file per day per person. Do not rewrite yesterday's file after Timmy has replied to it.
Access
- Repo: public. Zeph has write (fork → branch → PR and direct branch pushes in this repo).
- Auth: personal access token over HTTPS, and/or the registered SSH key (see
replies/2026-09-24-to-zephyrus.md).