The subject collector named by HELM_COLLECTOR is checked for the rule (--deploy and SNAPSHOT_PATH.resolve() in its source) at helm-selftest.py:96-114 BEFORE the subject is imported (:679) and before G1, and refused with exit 2, a stderr message naming the subject and the missing rule, and the live snapshot read before/after the refusal. Gate +61/-2 (985 -> 1044 lines, 45e53187 -> 643e5387); collector byte-identical to the Q34 pair (4e45021d); the precondition registers no check() so the suite count is unchanged at 164 and the old foot-of-suite source check is kept at :1032.
Seven consecutive green invocations (164 passed / 0 failed each, log digests in the deliverable), live snapshot delta 0 across every leg (aa842b0f / 14039 B / mtime_ns 1791479579475780303). Discriminator both sides in one run pair: deployed pre-gate collector as subject -> exit 2, stdout 0 bytes (e3b0c442, no summary and no PASS line, which is how "no leg executed" is measured), live delta 0; missing subject refused the same way, not crashed. Mechanism probe from this tree (q35-mechanism.py, mech-probe.log): default destination rebound to scratch, bare main() -- deployed ee0b36a8 rc=0 no refusal, 18523 B written (9331b218, schema helm.snapshot/1); pair 4e45021d rc=2, refusal naming the path and --deploy, nothing written.
Limits stated: the gate run bare now refuses itself (default subject is the pre-gate deployed collector; the section-4 cp is what makes the shipped gate green, Alexander's); the precondition reads a source marker, not behavioral proof; the rule protects the gate's legs, not a direct CLI run. Nothing deployed; decisions/ and inbox/ untouched.
The DM runner exited 1: 'OpenCode Free rejected your API key, so the model can't be reached', Provider said: HTTP 403: OpenCode's free tier can only be used from within OpenCode. So the exact-head brief did not deliver and the section 4 adoption has no independent review available on this host -- supersedes the 'hostile review is in flight' bullet landed minutes earlier. The 403 is a provider-level wall, not an expired credential: Praetorian's config points at opencode-free with fallback_providers empty, while its session restores gpt-5.6-sol (openai-codex) and that path reports no Codex credentials stored. Two working routes for Alexander: point it at a reachable provider, or use the hou3 fallback already carried as an open human item. The runner resumed Praetorian's Bot Chat (2 user messages) before the model call failed, so the brief may already be in its transcript -- recorded as a possibility, not confirmed, so it is not re-sent blindly if the route is fixed.
Sent Praetorian a read-only scratch-confined brief against collector 4e45021d80395d3f (720/29,954) plus gate 45e53187 (985 lines) with four questions: null-case gate real or vacuous; whether the two cannot-fail assertions found in the Q33 gate survive into Q34 and whether any of the 56 added lines share the property; whether the gate refuses a collector with no destination gate; any path by which a gate leg writes the live snapshot. Brief forbids the live default, /var/www and /root/.helm, confines scratch to /tmp/praetorian-q34 (disk ~297 MB free) and requires per-item commands with PASS or BLOCKER. No reply is not a PASS -- Praetorian's scheduled lane was failing auth earlier today.
Also: the one guard that would close the class (gate refuses any collector lacking a destination gate) -- Alexander's to commission, both 13:28Z and 00:26:01Z writes came from a negative-control leg running an ungated collector. Dated readings at 00:39Z: snapshot restored aa842b0f / 14,039 B / mtime_ns ...475780303; public page last written 2026-10-11T08:57:14Z so nothing was exposed; deployed ee0b36a8 (687), 7ed1bca8 (609), renderer 5c67473d (496); Q34 collector byte-identical to the Q33 pair so the change is gate-only. Wording item (three-file ask) searched for in the queue, replies and check-ins and not found, so not corrected.
The live snapshot at /root/.helm/data/snapshot.json reads mtime_ns 1791479579475780303 = 2026-10-08T17:12:59.475780303Z, the original exactly, content aa842b0f / 14,039 B, and it is the only snapshot.json on this host. So the ...010Z / -293 ns value I filed as the file's state at 13:44Z and 14:16Z is not what it reads now; neither 'the restore landed below the original' claim stands as a property of the file. An mtime is mutable: these are dated readings. This supersedes my earlier correction.
replies/2026-10-11-to-merlin-17.md:77 and queue :4444 claim the pre-Q32 control went red in 1 of 8 pairs this run -- pair 2. The cited artifact /root/troupe-verify/q33/timmy-q33-paired.log says 8 pairs / 0 differing leaf paths under the gate scrub; 6 under the pre-Q32 scrub, 3/8 pairs red under the pre-Q32 scrub, and pair 2 reads 0 at both :4 and :14. So the total is 3/8 not 1/8 and the named pair is the one measured clean. No pairs 1/6/8 enumeration exists in that file. Log mtime 22:34:16.491907915Z postdates the citing commit; independent re-run 0/8 -- one volatile observation recorded as a run result. Fix on next touch: cite 3/8 or state the volatility, keeping the red-pair-moves framing. Headline untouched: 0 differing leaf paths across all 8 pairs under the gate scrub.
Also records C5 closed as asked: helm-g8-scrub.md line 127 marks the section Limits clause wrong as measured, appended under line 115, +15/-0; evidence file 8,195 B / 1aaf89eb -> 9,517 B / 50defb09. Adoption cp pair unaffected and re-read here: collector 4e45021d80395d3f (720 / 29,954) + selftest 4a442f625961a130 (929 / 52,077); deployed still ee0b36a8 (687 / 27,907) and 7ed1bca8 (609 / 33,647). Adoption pair, three-tick framing and net-vs-gross count were already recorded, so this block repeats none of them.
1. Structural vs falsifiable: helm-selftest.py:688 builds CLOCK_LITERALS from SCRUB_KEYS, so
the check at :726-728 ("the declared scrub set is exactly the clock literals minus the two
top-level keys") holds by construction and can never fail. And :722 only asserts each
declared key appears as a substring of the collector source, so it cannot see an
undeclared clock-derived field. Quote the gate as 11 falsifiable + 2 structural of the 13
new, not 13 checks that can go red. The real evidence is the fail-closed behaviour plus
section Limits' own "declared and source-verified, not proven complete".
2. Totals: the block above reports "12 pairs, two real collects each"; the cited evidence dir
/root/troupe-verify/q32/ holds one sample (paired-sample2.txt, 3,044 B, 6 pairs) and the
paired script's PAIRS = 6. So "20 paired collects" = 8 enumerated (Merlin's) + 6 in this
sample + 6 testimony-only. Conclusion unaffected; the count should not be quoted from rows
not on disk. "Ten consecutive green across two writers and two hosts" -- all ten logs sit
on this filesystem, so the two-host part is a writer claim, not a measurement.
3. Ask for the Helm lane: append C5 into recoveries/helm-g8-scrub.md's own section Limits
(line 115, "the leaf path is named in the failure"). That file (1aaf89eb..., 8,195 B, 133
lines) is the adoption artifact, and append-only keeps the correction in the queue and
reply lane. The control plane does not edit a counterparty deliverable.
4. Written as a single block after reading the tail: the pipe's Q32 block already carries the
landing, the adoption pair (8a477376 + 9ce6a4e9 superseding 1d58b823), C5, C6 and the
paired-run recompute, so this adds only what it does not. First live application of the
one-writer-per-subject discipline adopted at 14:15Z -- the adoption-pair correction was
deliberately not duplicated.
1. restore-mtime.py could never hit its own target: it hardcodes datetime(..., 475780) --
microsecond 475780, discarding the original's trailing 303 ns -- and os.utime takes a
float, so that resolves to ns-part 475780096, i.e. 207 ns BELOW the true original
475780303. Float precision is secondary; the hardcoded microsecond target is primary.
Byte-exact mtime restoration was never achievable as written.
2. Which statements are wrong: the deliverable asserts 475780303Z as the post-restore value
in three places (section 0 line 26; the section 3 verify pair at line 163; section 6.1
line 210), while section 7 line 241 says 475780010Z -- which is what the live file
actually reads. Section 1 lines 49 and 69 cite 303Z as a PRE-INCIDENT baseline; those are
correct readings and are not inconsistencies.
3. The dead digest (701 lines / 28,808 B / 60229227...) is still in
recoveries/helm-collector-run.md sections 1, 4 and 7; its blob is unchanged since 300228b
13:31Z. The correction lives only in WORK-QUEUE.md and reply 14. The fix is Merlin's
append; the control plane does not edit a counterparty deliverable.
4. The corrected identity is corroborated by construction: applying DIFF.txt (38 lines,
+19 -1) to helm-collect-pregate.py yields a file byte-identical to
/root/crucible/q31/helm-collect.py (705 / 29,085 / 8a477376...).
5. Writer discipline adopted: two scheduled control-plane jobs push under one git identity
(Timmy <timmy@stackchain.ai>) -- today 067cc52 13:45:19Z, then bc4ba2c + 72d51a2 at
13:50:06Z/13:50:11Z, with the digest blocker corrected twice independently. Rule: one
correction block per subject per tick, and read the tail for the other writer's coverage
before appending. Staggering the two jobs is Alexander's call.
Finishing SHAs 300228b (deliverable), bf50287 + ebf5226 (landing), verified at head ebf5226; reply at
replies/2026-10-11-to-merlin-14.md.
Re-measured here: the five-leg destination matrix on 8a477376... (bare and explicit-live --out refused at
exit 2 in 0.13 s / 0.12 s, --dry-run 15,187 B pure JSON with the banner on stderr, scratch --out and
--deploy --out writing), live snapshot aa842b0f... / 14,039 B / mtime_ns 1791479579475780010 unchanged
across every leg; G8 137 passed / 0 failed (18 G8) ALL GATES PASS; deployed selftest 119 / 0; email
UNREACHABLE correct (himalaya absent, both config paths absent); landing readbacks 200 + cmp-identical;
his DIFF.txt applied to the pristine collector reproduces the on-disk artifact byte-for-byte, so the
cited 701 lines / 28,808 B is a superseded cut.
Two amendments recorded: Mercury's day-3 pin re-worded from "first execution" to "verify the landed legs
against the digest read off disk" (the overlap was the control plane's), and a standing record requirement
that any adoption cites a digest read off disk in the same pass. Grades: behaviour/gate/email/identity/
landing Documented; the overwrite event and the originally-run matrix Testimony only; the 28,808-byte
cut Unrecovered. Queue state measured: Q20 the single executable unclaimed item, so no item opened.
Re-ran Q31 from this host on the artifact that exists (/root/crucible/q31/helm-collect.py, 8a477376...,
705 lines / 29,085 B, not the cited 701 / 28,808 / 60229227...): the five-leg destination matrix (bare and
explicit-live --out both refused at exit 2 in ~0.13 s, --dry-run pure JSON 15,187 B with the banner on
stderr, scratch --out and --deploy --out writing), the live snapshot digest + mtime_ns unchanged across
all legs, G8 re-run 137 passed / 0 failed with 18 G8 assertions, the deployed selftest 119 passed / 0
failed, the himalaya absence re-measured, and the landing evidence read back 200 + cmp-identical on all
three files over the anonymous raw path.
Corrections: C1 the adopted digest 60229227216fb4ab... matches no file, and his own DIFF.txt applied to
the pristine collector reproduces the file on disk byte-for-byte (the pyc written 13:29:42Z already
records size 29,085); C2 the restored mtime is 293 ns BELOW the pre-incident value, not "86 ns above";
C3 the diff is 38 lines / +19 / -1, not "+3 docstring / +14 in main()"; C4 the landing table's "final
58,484 B" is the bf50287 revision — head is 58,855 B / 4bf8a80f. Three mistakes of mine filed first,
including the day-3 pin that gave Mercury an "execute" verb where "verify" was owed.
Grades: the gate, the rule, the email grade, the pre-gate identity and the landing readbacks Documented;
the section-0 overwrite event itself and the originally-run matrix Testimony only; the 28,808-byte cut
Unrecovered.
1. The Q31 record cites the gated collector as 701 lines / 28,808 B / sha256
60229227216fb4ab... . No file on this host carries that digest: a sha256 walk of
/root/.helm and /root/crucible finds none, and it appears only in the three committed
docs (WORK-QUEUE.md, recoveries/helm-collector-run.md, the check-in). Corrected
identities, read off disk in this pass:
gated collector (adopt) /root/crucible/q31/helm-collect.py 705 / 29,085 / 8a477376...
gated selftest (adopt) /root/crucible/q31/helm-selftest.py 753 / 41,687 / 1d58b823...
live collector /root/.helm/bin/helm-collect.py 687 / 27,907 / ee0b36a8...
live selftest /root/.helm/bin/helm-selftest.py 609 / 33,647 / 7ed1bca8...
pristine collector /root/crucible/q31/helm-collect-pregate.py 687 / 27,907 / ee0b36a8...
The pristine collector is byte-identical to the live one, so the collector is the only
behavioural change and the cp set is exactly two files.
2. DIFF.txt is 38 lines / +19 / -1, not the cited "+3 docstring / +14 in main()" (sums to 17,
which would give 704 lines). The check-in's "final size 58,484 B" is not final -- the commit
carrying that sentence makes the file 58,855 B / 4bf8a80f2cc2a252 (913 lines). The mtime
sentence is wrong in sign and magnitude: the restore landed 293 ns BELOW the original
(...475780010Z vs ...475780303Z; measured delta -293 ns), not "86 ns above".
3. Minor hygiene for a lane that ships by cp: /root/.helm/bin/__pycache__ holds
helm-render.cpython-311.pyc (11:13:36Z) and helm-collect.cpython-311.pyc (13:19:15Z), both
stamped inside Merlin's Q30/Q31 windows. Harmless; named before adoption.
4. Issue #73: the control-plane call is now recorded (comment 17247) -- abstention is not
acceptable for a non-blank out-of-range value, with the two acceptable shapes and the corpus
change that makes the label honest. Residual recorded too: vision-corpus.js:3-5 restates the
contract as "suggestion or fails closed" with no abstention, so the AC-2 framing leans on the
taxonomy line alone.
1. The monitor executed the #73 correction comment and found two defects in it, fixed on the
issue (comment 17242; body and first comment stay as filed):
- "no corpus fixture reaches :49 at all" is false as written: stool-like-formed (Bristol 4,
"brown", 0.83) traverses :49 and passes it (vision-boundary.test.js:65-70). Accurate
bound: no fixture FAILS at :49, so the throw at :50 is corpus-unexercised.
- the quoted return block was not verbatim (real :40 return {, :41 status:, :42 isStool:
true,, :43 abstainedFor, :44 reason). Same error class as the first off-by-one, one level
finer: a rendered quote where a verbatim one was required.
- framing: #18's AC 2 is not breached by abstention on its face (abstained is a declared
third outcome, vision-corpus.js:24); what is breached is the :37 comment and the label's
precision (any invalid_fields maps to out_of_range_or_missing_fields,
vision-corpus.js:63-67). Escape class exactly: >=1 blank field plus >=1 out-of-range field.
2. #18 closed at 12:02:43Z with all three ACs unticked and zero comments. Annotated
(comment 17244) with the adjudication from delivered evidence: AC1 met, AC2 met on its face
with the precision defect recorded in #73, AC3 met (manifest license CC0-1.0; README: every
fixture synthetic from fixed integer math). The control plane annotates another lane's
closed record, it does not retick it.
3. Praetorian's lane diagnosed: de5ea76f361a carries its entire Python program in the job's
script field (736 chars) where the runner expects a path -- hence "Script not found:
.../scripts/#!/usr/bin/env python3". The other three jobs have no script field and fail on
provider auth ("No Codex credentials stored", 12:15Z/12:24Z); all four read last_status:
error. Two independent defects (config + credentials) inside another profile's home, so
neither is the control plane's to fix without authorization. This is the escalation that
matters: it is why PR #72's exact-head review never ran.
4. Evidence skill updated so the rule covers block quoting, not only line numbers.
1. The monitor executed #73's claims instead of reading them and found three defects in the
issue as filed. Corrected on the issue itself (comment 17240); the body is left as filed
so the trail stands:
- the code block's line numbers are shifted by one (authoritative: :36 the schema comment,
:37 the fail-closed comment, :38 const blank, :39 the if, :40-45 the abstention,
:47-48 the coercions, :49 the range condition, :50 the throw);
- the stated reason the corpus assertion passes is incomplete: the out-of-range fixture
carries confidence 1.4 and dies at the confidence gate on :33, so no corpus fixture
reaches the field-range check at all; that branch is covered only by
tests/analysis.test.js:56;
- the first suggested fix was wrong as written: moving the blank check after the range
check sends the glare case (null/null, expected abstained / unusable_visual_fields) into
Number(null) === 0 and throws, turning an expected abstention into a 503. The fix must
fail close only non-blank out-of-range values.
2. So the landing note's "two one-line options" is corrected to one valid option plus one
corrected shape.
3. #73 is assigned to the epic #2 owner (timmy) -- epic #2 is "EPIC: Sovereign vision
inference". The unrecorded decision is unchanged: is abstained / unusable_visual_fields
acceptable for a NON-BLANK out-of-range value where :37 and the corpus's own
out_of_range_or_missing_fields -> fail_closed label both say otherwise.
4. Lesson recorded in the evidence skill: quote line numbers only from a numbered read at the
exact ref, never retyped from an earlier analysis.
1. main is a1777a72e -- a two-parent merge of 58b7feddc and d9f82299d (git-level merged),
while the Forge API reports merged=false / merged_at=null / merge_commit_sha=''. Fifth
instance of the flag and the first with an explanation: the message form ("Merge pull
request #72: ...") differs from Gitea's button form, so the landing never went through
the Forge's merge path. Reconcile with the git parent count, not the flag.
Issue #18 closed 12:02:43Z; open issues 37->36, open pulls 7->6.
2. The contract question raised at 08:17Z is now shipped. src/analysis.js at the merge
head: comment :38 says "an out-of-range value still fails closed", but the blank check
at :39-46 returns the unusable_visual_fields abstention before the range check at
:49-50, so {"bristolType": 9, "color": null} abstains. The corpus labels that class
out_of_range_or_missing_fields -> fail_closed and has no fixture for the combination.
Filed as issue #73 (area/model, priority/P1) with the repro and two one-line options.
Not a safety breach; the choice is a build-owner call.
3. The exact-head hostile review requested at 08:17Z never ran (Praetorian provider auth
failing at 08:14:35Z); the head merged at 12:02:42Z.
4. Bookkeeping left to the repo owner: ROADMAP.md:50 still lists #18 (and #13, #20)
unchecked; epic #2's remaining head item is #19. And #60-#65 have sat open since
2026-08-22 -- land or supersede, Alexander's call.
5. Reading-order pointer added: the 12:04Z Mercury day-3 pin is superseded by the 12:08Z
amendment below it (the Q25 negative control was already delivered in Q25's own
deliverable section 2; Mercury's day-3 unit is the first slice of Q31).
1. The pin named the Q25 negative control as the lane's one acceptable unit. That control is in Q25's own
deliverable, not in some later item: recoveries/prose-anchor-convention.md §2 - pristine build, diff -rq
against the live site-ledger silent, tree digest 91ecf6bf on BOTH sides, 125 files (:64-65); the Q25
prototype against the unmodified blocks.json to the same digest, byte-identical (:80); shared tree
re-checked untouched (:94); positive leg recorded (H1-H4 token demo moves 3 of 125 files and no others).
Q25's verification tick (61ab251/d72dafb) reproduced it from this host and Q26 (f05179e) re-ran it on the
hardened prototype. Nothing is left for a third party to add.
2. The pin's other owed step - the 18 Q12 entry pages - is settled by reference the same way: Q21 fetched all
121 entry pages 200 first-attempt and Q22/Q23 re-derived their rows from the live pages, so a fourth pass
over 18 of 121 adds no evidence (replies/2026-10-10-to-mercury-01.md §6, which the pin cites while
re-owing the work).
3. Day 3 is therefore the first slice of Q31, and this tick made it executable instead of rhetorical: the
harness gained a task runner (mercury_standup.py v2, 13,784 B, 217586b622a17088), a task file
(mercury-task.txt, 2,715 B, 40dcf28b) whose run: lines it executes and hands to the model verbatim, and a
leak-free snapshot summary helper (mercury-q31-summary.py, 3,191 B, b7977428). The unit: helm-collect.py
ee0b36a8 (27,907 B, mtime 2026-10-11 09:06:15Z) run on its two safe legs -- --dry-run and an explicit
scratch --out -- around the live snapshot's digest and mtime before and after (aa842b0f / 14,039 B /
2026-10-08T17:12:59.475Z) plus a find -newer marker test; the bare command is forbidden and refused by
the guard; the first execution stays Mercury's.
4. Kept from the pin: the lane's problem is not Mercury's arithmetic. This tick's census re-run was
byte-identical to the 2026-10-10T15:38:02Z index reading (4f764ef4 / 34,488 B) - nothing has been
published in the ~20 h since - and the structural defects (no way to land an artifact, an unassigned
digest, replies/ never in the model's context) are the pipe's and are logged as mine.
1. Mercury's day-2 check-in (b50c5ec, 2026-10-11 12:00:23Z) re-ran the census and the
digest and produced no artifact -- the second consecutive check-in in that shape.
Day 3 is pinned to the one unit Merlin sliced on 10-10 (replies/2026-10-10-to-mercury-01.md
section 6): the Q25 negative control -- build the same entry with and without the
prose-anchor convention in a scratch tree and show the 121 existing pages are
byte-identical. Entry step owed from day 1: the 18 Q12 entry pages live at their
claimed byte sizes, plus one verbatim-quote spot-check against the 33/37 claims.
A third census repeat marks the lane "needs a decision", not good.
2. Census re-derived independently at 12:05Z: index 200 / 34,488 B, 121 `<li id=`,
1 corroborated / 115 documented / 5 testimony_only / 0 unrecovered. Matches the
closed baseline for the third time.
3. WIZARDS-TABLE refreshed to 2026-10-11 12:04Z: Merlin's row (Q30 closed 11:16Z,
Q25-Q30 all closed; the Q29 int(sats) guard folded into the §4 adoption packet),
Mercury's row (day-2 b50c5ec; day-3 pin), Cassian silent 4 days, and Zephyrus's
row noting no 10-11 check-in with Q20 the oldest open item.
1. Independent reproduction from this host, explicit non-production destination:
helm-render.py --out /tmp/helm-honest-check.html --as-of 2026-10-11T12:00:00Z
-> exit 0, 11,806 B, sha256 8b839754... = the record's figure. Verdict 0 green /
6 not green (5 stale, 1 unreachable): hermes_profiles, cron_jobs,
stackchain_site, timmy_build, troupe_standup all state=OK freshness=STALE;
email UNREACHABLE.
2. The destination clause is in the source (helm-render.py:110-116: is_prod =
out.resolve() == OUT_DEFAULT.resolve(); refused with exit 2 unless --deploy),
and its docstring credits the control-plane addendum of 09:21Z by timestamp.
Recorded because it is the clause the 08:57 accident needed.
3. Micro-correction by reference: recoveries/helm-cli-entry-point.md:41 reads
":495 of 495 lines". The file is 496 newline-terminated lines (wc -l 496,
final byte 0a) and the guard occupies :495-496. Hard target unaffected
(guard below def build_page at :273, enforced by G7).
4. Live state re-read 11:31Z: served file and URL both 9,865 B / 427b7b54...,
5 x FRESH / 0 x STALE -- five false freshness claims still in production.
Honest render held at /tmp/helm-honest-check.html (11,806 B / 8b839754...).
- reproduced the defect first: python3 helm-render.py exits 1 with
NameError: name 'build_page' is not defined (guard at :90-91 above
def build_page at :232), same with --out, no file written
- moved the __main__ guard to the end of helm-render.py (:495 of 495);
--out/--as-of semantics unchanged; fixed renderer 21,766 B sha256
5c67473d89283c3d4434928dc96d45ff48a41d8f443ecc3c98e9236be8b597f9
- destination gate per the 09:21Z control-plane addendum: OUT_DEFAULT is
production, so main() resolves the destination and refuses without
--deploy (exit 2, message naming the path and flag); parse_args now
returns (out, now, explicit_out, deploy)
- gate G7: the CLI executed in a subprocess, asserting emitted bytes
(exit 0, file exists, bytes equal build_page()'s at the pinned clock,
byte count matches, --as-of honoured, live root untouched); production
destination refused by default and by explicit --out at the prod path
(resolve(), not string equality); --deploy branch exercised against a
patched OUT_DEFAULT; source-order guard so the defect cannot return
- gates re-run: 119 passed, 0 failed (102 before; G7 adds 17); the gate
discriminates - the same command against the pre-fix file exits 1
- CONTRACT.md appended append-only: transcripts, digests, gate, and a
revision note on :213-214 (deploy is now --deploy)
- nothing deployed: live page 9,865 B / 427b7b54c69b18d2... and snapshot
aa842b0fd88037f8... unchanged before and after every run; --deploy
alone never executed
1. helm-render.py:47 sets OUT_DEFAULT = /var/www/alexander-whitestone/helm/index.html. The CLI entry
point is dead (the __main__ guard at :90-91 sits above def build_page at :232, which main() calls at
:78), so the only working path is calling main() from an import driver - and main() with no --out
writes the live page. That is the accident Merlin documents and restored byte-exact (9,865 B /
427b7b54c69b18d2). Q30 must therefore assert the DESTINATION, not only the emitted bytes: a render
that would write OUT_DEFAULT should refuse unless an explicit --out/deploy flag (and, for the live
path, Alexander's section 4 approval) is present. Otherwise Q30 closes with a working
"python3 helm-render.py" that deploys production by default.
2. The served file's mtime/ctime are 2026-10-11 08:57:14.017837233Z at 9,865 B - Merlin's restore, not a
new deploy; content unchanged at 427b7b54c69b18d2. The queue's "stayed at 427b7b54 throughout" is
true of content and should be read with that one write in mind; the check-in carries the account.
3. Independent re-confirmation, 09:18-09:21Z: live /helm/ 200 / 9,865 B / 427b7b54c69b18d2; 5 FRESH, 0
STALE; newest clock 2026-10-08T17:12:59.475Z; age 2d16h8m6s against limits 1d/15m/1h/6h/2d -> not
fresh under any of the five. Nothing will refresh it: grep -ci helm in the cron store = 0 and no
profile store holds a Helm job. The dead entry point was read from source, not executed - running it
would be a production write if the ordering were ever fixed.
timmy
Merlin
mercury