Conversation
The roadmap said what remained to do. It did not say where the soak actually stops, which environment starts it, or which measurements had been taken through a layer that changes the answer. This records all three, dated, so the next reader starts from evidence instead of from argument. What is now written down: - The soak STARTS on Ubuntu 22.04 and passes its exact-six integration gate. Its next barrier is named, with the file and line that cause it: the isolated config set copies one tracked file and never copies `config/themes/`, so the launcher cannot import a default theme pack that exists in the repository. - The environment recipe that was measured to work, and the fact that the checklist's own runtime recipe is stale on the laboratory image — it points at a path that is not readable and at a Python that is not the one installed. - A measurement trap that produced four wrong answers in one evening: a Windows-created worktree reached from WSL resolves no git repository, so every test that shells out to git fails for a reason unrelated to the code. Two published claims were corrected because of it. - Four rungs to a laboratory-ready week, each one a stopping point where the system is still coherent if work stops there. - Two owner facts of 2026-08-18: the laboratory computer is on an uninterruptible power supply, and he travels this week to test on real hardware. Green software gates do not replace that test, and the Keithley A8-0 gate on real firmware remains the heater-control gate that no soak can close. The checklist's stale runtime recipe is NOT corrected here. That file is already changed by the open long-soak pull request, and correcting it in two places would conflict for no benefit.
…the risk deepseek-v4-pro caught an over-claim on its first review under the new reviewer setting, and it was the class that must never pass: reporting a result the evidence does not support. The owner said the laboratory computer is on an uninterruptible power supply. I wrote that host death mid-profile is therefore a schedule risk and not a data risk. He did not say that, and it is not true. The supply removes mains power loss and nothing else. A kernel panic, an out-of-memory kill, a storage or filesystem failure, or a crash of the program itself still kills the host and still drops whatever measurements are not yet persisted. It also contradicted this same roadmap two paragraphs above, where A8c host-death is still listed as a physical blocker. A reader could have taken the supply as closing it and skipped the check. The text now says which single cause is removed, states that host-death persistence stays OPEN and that A8c remains a physical blocker, and names the case the supply really does close: the mains outage that interrupted work on the development machine, which has no such supply.
|
@codex review Head is |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Review verdict: CLEAN —
|
…measured-2026-08-18 # Conflicts: # docs/architecture-montana-important.svg # docs/current_candidate_metrics.md
|
@codex review Head is |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Master is RED on the target platform, and this branch is what fixes itMeasured on Ubuntu 22.04.5 LTS, Python 3.14.6, in clean worktrees cut from the
The failure master carriesThe child loads the system
The library the child needs is present in the environment and is not the one it Why this branch fixes itMaster computes the controlled That change was made for a different reason — a stock virtual environment What it means for the queueEvery open pull request inherits this red node, including ones that touch no It is therefore not an acceptance to be written per branch. It is one fix, here. |
Correction: the red node here is NOT the cause I named earlierAn earlier comment on this pull request said the red What actually fails inside the exact-six run on the hosted runner: That is a leader-election and delivery-authorisation test, not a library What still stands from the earlier commentThe libstdc++ measurement itself is unchanged and reproducible on the laboratory What is being done hereThe node passes on the laboratory host at master — measured just now, Nothing about this pull request's own content is implicated. It changes one |
…measured-2026-08-18 # Conflicts: # docs/architecture-montana-important.svg # docs/current_candidate_metrics.md
|
@codex review Head is |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
…measured-2026-08-18 # Conflicts: # docs/architecture-montana-important.svg # docs/current_candidate_metrics.md
|
@codex review Head is |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
# Conflicts: # docs/architecture-montana-important.svg # docs/current_candidate_metrics.md
|
@codex review Head is |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
The paragraph said the theme pack never arrives because the isolated config copy lists only channels.yaml. That is true of the copy and it is not the mechanism, and the difference decides where a reader looks next. The pack is tracked and git archive carries it into the sealed snapshot, so the tree has it. The child cannot see it because _source_environment points CRYODAQ_ROOT at the isolated root, and get_config_dir is that root plus config, which holds only the curated passive set. Measured both ways on Ubuntu 22.04.5 with the workspace rootprobe tool: an override at a tree without config reproduces the recorded traceback exactly, and CRYODAQ_ROOT at the application tree with CRYODAQ_STATE_ROOT at the isolated directory imports cleanly. The second arrangement is the split paths.py already documents, so the fix is a configuration decision rather than new code. The refusal is left alone. A test pins it and a tree with no config has no safety configuration either, so whether the program should stop over a colour file is the owner's decision.
|
@codex review Head is |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Two things say this is a hosted-runner timing flake rather than something this branch caused, and both are measurements rather than reasoning:
The failed job is being rerun rather than argued away. If it fails again the reading changes and the test needs its own work, because a required check that fails twice is not a flake, it is a defect with an unknown owner. Recording it here so that a green rerun is not later read as "it passed", which is a different claim from "it failed once and passed on rerun at a measured rate of zero in twelve locally". |
# Conflicts: # docs/architecture-montana-important.svg # docs/current_candidate_metrics.md
|
@codex review Head is |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 432b1cc46c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| `_source_environment` sets `CRYODAQ_ROOT` to the ISOLATED root, | ||
| `get_config_dir()` is `get_project_root() / "config"`, and that isolated | ||
| `config/` holds only the curated passive set (`_ISOLATED_TRACKED_CONFIG_FILES` | ||
| plus `_ISOLATED_STATIC_CONFIGS`), with no `themes/` among them. |
There was a problem hiding this comment.
Re-measure before naming the current soak barrier
At this commit, the stated cause has already been fixed: scripts/soak_mock_stack_runner.py declares _ISOLATED_TRACKED_CONFIG_DIRS = ("themes",) and _materialize_isolated_mock_config copies those packs into the isolated configuration. Keeping the old fa52b35804 diagnosis under “its next barrier” makes the forward roadmap describe completed work as the current blocker and can send the next investigation down the wrong path; re-run the soak at the reviewed head and record the barrier that remains.
AGENTS.md reference: AGENTS.md:L37-L39
Useful? React with 👍 / 👎.
| The qualification section of `docs/lab_verification_checklist.md` is right about | ||
| the important thing — the run must happen in a clone on a native Linux | ||
| filesystem, never under `/mnt/c` — and **its runtime recipe is stale**. It | ||
| symlinks `.venv` at `/root/cryodaq-soak-py313`. Measured 2026-08-18 on the | ||
| laboratory WSL image: that path is not readable, and the interpreter present is | ||
| `cryodaq-lab`, Python 3.14.6. |
There was a problem hiding this comment.
Repair the canonical qualification recipe in the same slice
On the measured laboratory WSL image, this says /root/cryodaq-soak-py313 is unreadable, but the authoritative turnkey procedure in docs/lab_verification_checklist.md:55-62 still creates .venv symlinks to exactly that path. An operator following the canonical checklist will therefore reach a dangling symlink and fail at .venv/bin/python even though this roadmap contains a different recipe; update and verify the checklist rather than leaving two incompatible procedures.
AGENTS.md reference: AGENTS.md:L37-L39
Useful? React with 👍 / 👎.
| Sufficiency at every rung is the same object: a sealed soak PASS at increasing | ||
| duration. That is why the soak is graded as an instrument rather than a feature. |
There was a problem hiding this comment.
Do not make the passive soak sufficient for these rungs
When these rungs are used as laboratory-readiness criteria, a sealed soak PASS cannot be their sufficient evidence: the canonical checklist defines this soak as one passive mock LS218 fixture with production alarms, interlocks, and physical alarms disabled, while the rungs require heater-control, real end-to-end instrument operation, and fault delivery to a human. Describe the soak as one required software gate and retain separate prescribed evidence for those requirements; otherwise even a 168-hour mock PASS appears to certify behavior it never exercises.
AGENTS.md reference: AGENTS.md:L23-L26
Useful? React with 👍 / 👎.
| **The owner travels to the laboratory this week to test on real hardware. Green | ||
| software gates do not replace that test, and he has said so.** Read the | ||
| irreducible hardware milestone above with that in mind: **Keithley A8-0 on real | ||
| 2604B firmware is the heater-control gate, and no soak substitutes for it.** |
There was a problem hiding this comment.
Remove the owner's travel schedule from the public roadmap
Because ROADMAP.md is the repository's public forward product plan, recording that the identifiable owner will travel to the laboratory “this week” publishes personal scheduling information and turns a durable plan into immediately stale campaign evidence. Retain only the product requirement that physical testing must occur, and keep the person's schedule in an appropriately private or campaign-local coordination channel.
AGENTS.md reference: AGENTS.md:L544-L549
Useful? React with 👍 / 👎.
| 2. **Trust the evidence** — the suite that certifies the system is itself | ||
| trustworthy: no test leaves a production module mocked for the tests after | ||
| it, no unavailable source root passes as a compile check, no vacuous | ||
| assertion. Plus a 12-hour PASS. | ||
| 3. **Unattended week** — faults reach a human, configuration parsing has an | ||
| owner, the predictor baseline is honest. Plus a 72-hour PASS. | ||
| 4. **The week** — a 168-hour PASS on a frozen SHA. |
There was a problem hiding this comment.
Mark the long-soak rungs unavailable until they can run
These stopping criteria cannot currently produce the evidence they require: scripts/soak_mock_stack.py exposes only short, 12h, and 72h, immediately returns exit code 3 for every profile other than short, and defines no 168-hour profile at all. Consequently the 12-hour and 72-hour PASSes are refused and the 168-hour PASS is not even selectable; describe these as open implementation/activation gates or add the corresponding runnable, sealable evidence contracts before presenting them as executable rungs.
AGENTS.md reference: AGENTS.md:L37-L39
Useful? React with 👍 / 👎.
| **So host-death persistence remains OPEN, and the A8c host-death gate above | ||
| remains a physical blocker.** Do not read the uninterruptible supply as closing |
There was a problem hiding this comment.
Separate persistence loss from the A8c OFF gate
When the laboratory team works through the declared physical blockers, this introduces “host-death persistence” as an open gate next to A8c, but docs/lab_verification_checklist.md:294-304 defines A8c only as killing the host and observing whether the Keithley output turns OFF without another command; it contains no database or data-durability criterion. As written, there is no prescribed evidence that can close the newly named persistence gate, and an A8c result can be mistaken for covering it; define a separate persistence procedure and artifacts, or explicitly classify the data loss as an accepted residual while keeping A8c solely about verified OFF.
AGENTS.md reference: AGENTS.md:L37-L42
Useful? React with 👍 / 👎.
| either. What it does close is the specific case that interrupted work on | ||
| 2026-08-18: a mains outage on the development machine, which has no such supply. |
There was a problem hiding this comment.
Do not close the development-machine outage with a lab UPS
In the stated scenario, the interrupted soak ran on the development machine and this sentence explicitly says that machine has no UPS, so a UPS attached to the separate laboratory computer cannot close that specific mains-outage case. It only changes the risk for future runs performed on the protected lab machine, and even there requires bounded-runtime evidence; reword this as a machine-scoped mitigation rather than claiming the observed failure case is closed.
AGENTS.md reference: AGENTS.md:L23-L26
Useful? React with 👍 / 👎.
…he soak from proving what it never ran Seven review findings on the readiness record, and four of them say the same thing in different places: the document states a position that has since moved. THE NAMED BARRIER WAS ALREADY BUILT. The theme-pack cause is fixed in the runner, so keeping it under "the next barrier" pointed the next investigation at finished work. Measured on Ubuntu 22.04 at the heads then under review, the run now recovers the engine fault -- ready in 6.749 s, with bridge data resumed -- and stops three steps further on: the periodic reporter flaps between ready and degraded_runtime about once a second, active never leaves null, so no slot is allocated, so no receipt can be sealed, so the assistant fault refuses. Its own health names the cause: periodic_live_source_stopped, and beneath that periodic_engine_unavailable. The old measurements are kept as dated history, because they are still true of the commits they name. THE CANONICAL RECIPE STAYED BROKEN. Recording a working recipe in the roadmap while the checklist -- the procedure an operator actually follows -- still symlinks the unreadable /root/cryodaq-soak-py313 leaves the operator at a dangling symlink and a failure at .venv/bin/python. The checklist is repaired in this same commit: the interpreter path is measured on the machine, one link to the interpreter is enough, and what was measured on the laboratory image is named. THREE OF THE FOUR RUNGS CANNOT BE RUN. scripts/soak_mock_stack.py registers exactly short, 12h and 72h; every profile other than short exits 3, the runner refuses it a second time, and there is no 168-hour profile at all. The ladder now says so, and says what has to be built before those rungs can be attempted. AND THE SOAK DOES NOT PROVE HEATER CONTROL. It drives mock sources and commands no heater, so a PASS of any duration certifies continuity and nothing about the physical gate. Sufficiency is no longer one object at every rung. The remaining three: the owner's travel schedule is out of the public plan, the 2026-08-18 outage is scoped to the development machine it actually struck, and A8c is stated as an OFF gate that does not cover persistence.
|
@codex review Head is
Gates run on this tree: the derived documentation pair regenerated to a fixed point and committed, and |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c10040c372
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| heater control or about the instrument running end to end. Rung 1 asks for both | ||
| of those, and they come from the physical Keithley A8-0 gate, not from a soak of | ||
| any duration. What the soak alone certifies is continuity: that the program |
There was a problem hiding this comment.
Keep heater-control evidence outside the OFF-grammar gate
At this head, the corrected text assigns both heater control and end-to-end instrument operation to A8-0, but docs/lab_verification_checklist.md:258-281 requires A8-0 to run while the source is already confirmed OFF and without applying power; it verifies only the nonce-bound OFF reply grammar. Rung 1 could therefore be declared complete without ever exercising heater control. Keep A8-0 open for its stated purpose and name a separate prescribed powered/end-to-end hardware procedure for these two claims.
AGENTS.md reference: AGENTS.md:L23-L26
Useful? React with 👍 / 👎.
| **Fixing this document is not enough: the checklist is the CANONICAL procedure, | ||
| and an operator follows that.** While the two disagree, the operator meets a | ||
| dangling symlink and fails at `.venv/bin/python` no matter what this roadmap | ||
| says. Repairing `docs/lab_verification_checklist.md` belongs in the same slice | ||
| as this section; until it lands, treat the recipe below as the one that was | ||
| measured and the checklist as known-stale. |
There was a problem hiding this comment.
Remove the obsolete warning about the canonical recipe
In the reviewed tree, docs/lab_verification_checklist.md:59-71 has already replaced the old /root/cryodaq-soak-py313 links, but this section still tells operators that the checklist has a dangling symlink, is known-stale, and should be disregarded in favor of the roadmap's different venv recipe. That leaves the repaired canonical procedure contradicted by the public plan; update this section to describe the checklist that actually landed.
AGENTS.md reference: AGENTS.md:L37-L39
Useful? React with 👍 / 👎.
| **Measured 2026-08-20 on Ubuntu 22.04, at the heads then under review, the run | ||
| gets much further and stops somewhere else entirely:** |
There was a problem hiding this comment.
Bind the barrier measurement to an immutable commit
When later changes move the soak behavior again, “at the heads then under review” does not identify which code produced the 6.749-second recovery and periodic-reporter failure, even though the section promotes that result as the current barrier. Record the exact commit or tree and command/evidence artifact, or label this result pending/historical, so reviewers can determine whether the measurement applies to the candidate they are qualifying.
AGENTS.md reference: AGENTS.md:L445-L450
Useful? React with 👍 / 👎.
Three review findings, and the first is the one that mattered. A8-0 CANNOT PROVE HEATER CONTROL. The checklist says so in its own words: the procedure runs with the source already confirmed OFF and with no power applied, and it checks exactly one property -- that the instrument answers a nonce-bound OFF command with the exact expected line and nothing else. I had assigned both heater control and end-to-end operation to it, so rung 1 could have been declared complete without a heater ever being driven. Heater control now cites the POWERED procedures, A8b and A8d; A8-0 stays open for its own purpose. AND END-TO-END OPERATION HAS NO PROCEDURE AT ALL. The A8 series covers the OFF command, the watchdog, host death and terminal measurement. None of them is an experiment run end to end on real hardware with acquisition, storage and export. Naming that gap is more useful than assigning it to a gate that does not test it. THE WARNING I WROTE WAS OBSOLETE BY THE TIME IT LANDED, because the same change repaired the checklist it warned about. It told operators to disregard the canonical procedure that had just been fixed. AND THE BARRIER MEASUREMENT NAMES NO TREE. It was taken on a throwaway merge of several open branches, so no tracked commit produced it and none can be cited -- which makes it directional rather than qualification of any candidate. It becomes bindable when those branches merge and the soak runs at one candidate head.
|
@codex review Head is
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2d4a360faf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| with that in mind: **Keithley A8-0 on real 2604B firmware is the heater-control | ||
| gate, and no soak substitutes for it.** When that testing happens is scheduling, |
There was a problem hiding this comment.
Stop naming A8-0 as the heater-control gate
Fresh evidence at head 2d4a360 is that this sentence still calls A8-0 the heater-control gate even though the corrected rung text below and docs/lab_verification_checklist.md:258-281 establish that A8-0 runs already confirmed OFF, applies no power, and verifies only reply grammar. Leaving this earlier summary intact gives operators a contradictory path for treating an unpowered grammar check as physical heater-control evidence; name the powered A8b/A8d procedures here as well.
AGENTS.md reference: AGENTS.md:L23-L26
Useful? React with 👍 / 👎.
| a behaviour decision, not a mechanism one — **and the owner has since decided | ||
| it** (2026-08-20: *"файл цветов не должен останавливать"*), so that test now | ||
| states the opposite and the loader falls back to a built-in copy. |
There was a problem hiding this comment.
Do not claim the built-in theme fallback has landed
At the reviewed head, resolve_theme() still raises RuntimeError when the default pack is missing (src/cryodaq/gui/_theme_loader.py:162-180), and tests/gui/test_theme_loader.py:182-186 still explicitly expects that exception. This statement therefore reports an open-branch or intended behavior as current behavior, which can mislead investigation of startup failures; describe it as pending until the implementation and opposite test are actually in this candidate.
AGENTS.md reference: AGENTS.md:L37-L39
Useful? React with 👍 / 👎.
| The qualification section of `docs/lab_verification_checklist.md` is right about | ||
| the important thing — the run must happen in a clone on a native Linux | ||
| filesystem, never under `/mnt/c` — and **its runtime recipe is stale**. It | ||
| symlinks `.venv` at `/root/cryodaq-soak-py313`. Measured 2026-08-18 on the | ||
| laboratory WSL image: that path is not readable, and the interpreter present is |
There was a problem hiding this comment.
Remove the stale-recipe warning that remains
Fresh evidence at head 2d4a360 is that the obsolete warning remains immediately after the new paragraph saying the canonical checklist was repaired: these lines still state in the present tense that the checklist uses /root/cryodaq-soak-py313, while docs/lab_verification_checklist.md:58-71 now resolves and links the measured cryodaq-lab interpreter instead. Operators are consequently given mutually exclusive descriptions of the canonical procedure; remove or clearly historicize this paragraph.
AGENTS.md reference: AGENTS.md:L37-L39
Useful? React with 👍 / 👎.
Three review findings, and all three are the same failure: a correction was made in one place and the sentence that said the opposite was left standing. A reader then has two mutually exclusive statements and no way to tell which is current. A8-0 WAS STILL CALLED THE HEATER-CONTROL GATE in the summary above the rungs, even though the rung text below and the checklist both establish that it runs with the source already confirmed OFF, applies no power, and verifies reply grammar only. That gave an operator a path to treat an unpowered grammar check as physical heater-control evidence. The powered procedures, A8b and A8d, are named here as well now. THE THEME FALLBACK WAS REPORTED AS LANDED. It is not. Verified in this candidate: `src/cryodaq/gui/_theme_loader.py` still raises `RuntimeError` on a missing or invalid default pack, and `test_missing_default_pack_raises` still requires that exception, so a missing colour file still stops startup today. The owner's decision that it should NOT is kept beside that, because both halves matter -- the decision is made and the behaviour has not changed yet, and reading only the first half sends an investigation of a startup failure down the wrong path. AND THE OBSOLETE RECIPE WARNING WAS STILL THERE, in the present tense, directly after the new paragraph saying the canonical checklist had been repaired. This slice was drafted by a worker lane and then verified here rather than taken on its word. Two things needed correcting: the lane wrote CRLF into an LF file, which would have shown as a whole-file diff, and it removed the owner's decision along with the stale claim instead of keeping it as pending.
|
@codex review Head is
Two process notes, since they affect how you should weigh this head. This slice was drafted by a worker lane and then verified here rather than taken on its word, and two things needed correcting afterwards: the lane wrote CRLF into an LF file, which would have shown as a whole-file diff; and it removed the owner's decision along with the stale claim, instead of keeping it as pending.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9aa05ea3c9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| interpreter. **The recipe below is the same one and is kept as the record of what | ||
| was measured**, not as a competing procedure. |
There was a problem hiding this comment.
Keep the roadmap recipe distinct from the checklist
When qualification is reproduced from this roadmap, the asserted equivalence is false: docs/lab_verification_checklist.md:66-71 resolves the installed conda interpreter and symlinks it directly into .venv/bin, whereas the recipe below creates a new venv with --system-site-packages. Those approaches produce different environment prefixes and isolation, so the public plan still presents two distinct qualification procedures while claiming canonical parity; make the commands equivalent or clearly label the roadmap recipe as separate historical evidence.
AGENTS.md reference: AGENTS.md:L37-L42
Useful? React with 👍 / 👎.
|
Closing by the approved laboratory-readiness disposition. This pull request is a dated readiness snapshot that was superseded by later measured laboratory runs. Merging the older position would publish stale status rather than improve the Ubuntu 22.04 week-long run. |
Records the measured laboratory-readiness position of 2026-08-18 in the roadmap,
under the live pre-lab milestone. Documentation only; no production code, no
test, no gate.
The roadmap said what remained to do. It did not say where the soak actually
stops, which environment starts it, or which measurements had been taken
through a layer that changes the answer. All three are now written down with
their dates, so the next reader starts from evidence rather than from argument.
What is recorded
The soak starts on Ubuntu 22.04. At
fa52b35804, in a worktree cut from anative Linux clone, it reaches the runner phase, writes seven evidence files,
and its exact-six integration gate PASSES. It then fails at one named barrier:
source stack did not reach the exact four-role startup cut.The barrier has a cause, with lines.
scripts/soak_mock_stack_runner.py:153copies only
_ISOLATED_TRACKED_CONFIG_FILES = ("channels.yaml",)into theisolated config set, so
config/themes/never arrives;src/cryodaq/gui/theme.pycalls
resolve_theme()at module import, and_theme_loader.py:26nameswarm_stoneas the default. The pack exists in the repository and not in thecopied tree, so the launcher cannot import.
The environment recipe that works, and the one that does not. The
qualification section of
docs/lab_verification_checklist.mdis right that therun must happen on a native Linux filesystem and never under
/mnt/c. Itsruntime recipe is stale: it symlinks
.venvat/root/cryodaq-soak-py313,which is not readable on the laboratory image, whose interpreter is Python
3.14.6. That correction is deliberately NOT made here — the checklist is
already changed by the open long-soak pull request, and editing it in two places
would conflict for no benefit.
A measurement trap. A Windows-created worktree reached from WSL resolves no
git repository, so every test that shells out to git fails for a reason
unrelated to the code, while tests that never touch git pass normally. It
produced four wrong answers in one evening and two published claims had to be
corrected.
Four rungs, each a stopping point where the system stays coherent if work
stops there, and the note that sufficiency at every rung is the same object: a
sealed soak PASS at increasing duration.
Two owner facts of 2026-08-18. The laboratory computer is on an
uninterruptible power supply, so host death mid-profile is a schedule risk for
that machine rather than a data risk. And he travels this week to test on real
hardware — green software gates do not replace that test, and Keithley A8-0
on real 2604B firmware remains the heater-control gate that no soak can close.
Verification
tests/docs— 67 passed at this head, on Windows.Every statement carries its date, and the section opens by telling the reader to
re-measure before acting on any of it.
Written with AI assistance (Claude), reviewed and pushed by the coordinator.