Merlin
0fb8b2096c
Q39's repair 5 is a net, not a fence: live bytes and mtime are read around every
subprocess and around the subject's in-process import, a change restores the
bytes and refuses the run, so the write has already happened when the watch
fires. Q39's own record names the residual and the Q39 closure asks for "the
stronger form (the legs against a rewritten copy)". This is that form, and it is
the Helm lane's next unit rather than a new invention.
Three rules in the one choke point the gate already has -- the leg wrapper
installed on subprocess.run, so every future leg inherits them:
1. a subject leg carrying --dry-run runs AS THE ORIGINAL, watched: it writes
nothing by the collector's own rule (helm-collect.py:698), and running the
original is what lets the resolution leg read the subject's own destination
out of its banner;
2. every other subject leg, and the in-process import, runs the REWRITTEN COPY
-- every SNAPSHOT_PATH = assignment pointing at a per-invocation sandbox
built after admission and removed at the end of the run -- so module-level
code can write at most into the sandbox;
3. a subject leg is REFUSED (exit 2, the leg never runs) if its argv names the
live snapshot or passes --pin.
Rule 3 is load-bearing, not decoration: the collector refuses only when --out
resolves to its OWN SNAPSHOT_PATH (helm-collect.py:702), so a copy whose
destination is the sandbox would write the live path if a leg named it. The
gate's own "explicit live --out is refused" leg therefore now names the copy's
own destination -- the Q30 discipline applied to the collector. The rule under
test is unchanged; it is measured on a path that is not live, and the semantic
change is stated in the gate and the record rather than left implicit.
Measured, 20 gate invocations, live delta 0 on every one (snapshot 14,039 B /
aa842b0f... / mtime_ns 1791479579475780303; held pin 120 B / 5b6d7071... /
mtime_ns 1791478687099553071):
- green pair, 5 consecutive runs: rc 0, 166 passed / 0 failed, ALL GATES PASS,
12,248 B stdout; 4 subject legs redirected, 3 --dry-run legs run as the
original, 0 refusals; the sandbox holds 3 paths (the copy and its bytecode
cache, no data/snapshot.json); 18 legs watched, delta 0 on each;
- the five Q39 negatives refuse under BOTH gates (rc 2, stdout 0 B, no report
block, live delta 0) -- but they are refused at Q39's admission, before the
Q43 sandbox exists, so they are a regression control and nothing in the
five-fixture suite exercises the redirect. Stated, not hidden;
- the discriminator, on a scratch protected path: argvlive (the gate's own
pre-Q43 leg shape, rule 3 armed) -> rc 2, the refusal naming the leg's argv,
the copy's destination and the rule at :702, and the protected file's sha,
mtime AND ctime unchanged -- the leg never ran. argvlive-norule3 (rule 3
disarmed) -> rc 2 via Q39's watch, protected ctime MOVED while sha and mtime
were restored -- the leg ran, the copy wrote a real snapshot over the
protected file, and only the restore put it back. ctime_ns is the
discriminator: the stamp a restore cannot undo;
- the --pin residual: pin_stackchain() writes HELD_DIR, composed from HELM_HOME
and untouched by the rewrite, so a --pin leg is refused (rc 2, naming --pin
and /root/.helm/data/held); a copy with HELD_DIR also redirected to scratch,
run --pin --deploy, writes the scratch held file, so the path is real; bare
--pin is refused by the destination gate before `if args.pin`, so it is one
flag combination away, not on the default path;
- the rewrite is behaviour-preserving: original vs copy, both --dry-run, both
20,570 B, scrubbed over the gate's full clock set -> diff_keys [].
Three defects of mine, logged first in the record: the redirect keyed on argv[0],
which is the interpreter (the subject is an argv element, and the first run
measured 0 redirects while its legs ran the original -- the Q40 shape); the
behaviour-preservation scrub omitted generated_at and duration_seconds; and the
first --pin measurement ran bare, so the held path was never reached.
Limits stated in the record: prevention is total for the SNAPSHOT_PATH class, not
for every class; the legs still execute the subject's code, and damage to
anything other than the snapshot is out of this gate's scope; the five-fixture
suite no longer reaches Q43's machinery, so the two variants and the pin residual
are the coverage.
Nothing deployed: no cp into /root/.helm/bin/, the deployed bin is unmoved
(ee0b36a8... / 7ed1bca8... / 5c67473d...), decisions/ and inbox/ untouched, no
another-party file edited, no secret printed. Adoption stays Alexander's, and Q40
measured that the deployed gate has no subject-selection path at all, so the cp
is the only thing that puts any of Q31-Q43's protection into production.
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).