Triad migration evidence of 2026-10-08 and 2026-10-09: test roots and CI patches, installer entry point, restore and rollback, #192's corrections, T018, Gate B status

specs/004-migrate-to-triad/adopter-rehearsal-2026-10-07.md

@@ -182,6 +182,12 @@ blob, `8043147a`. The source clone was unchanged except for the one new ref
   [quickstart.md](quickstart.md) and [preparation.md](preparation.md) still
   describe the October 4 version; the plan's owner decides when to refresh
   them.
+- *Dated 2026-10-09 (#193 item 8):* since #192, the mapping link above opens
+  run C's plan ([adopter-rehearsal-2026-10-08.md](adopter-rehearsal-2026-10-08.md)),
+  and run B's stays in history at `63810dd`. #188 landed as `837928a`. The
+  bench restart of 2026-10-08 cleared both runs' disposable repositories, so
+  their logs survive only in this file's receipt. Run C's legs still carry
+  `558a12b` and `48d98cd`, as the parents of their heads.
 - Each run used a fresh, empty `--local-remote-dir` and `--work-dir`. Without
   the first, `execute` calls `gh repo create`. The plan's
   `execution_authorized: false` is informational and the tool does not read it.

specs/004-migrate-to-triad/adopter-rehearsal-2026-10-08.md

@@ -21,17 +21,72 @@ kept host-local outside every repository so it survives a bench restart.
 Clone paths, local remote URLs, exact command lines and complete logs stay in
 the private receipt.
 
+**Dated 2026-10-09, after #192 landed (#193 items 8 and 13):**
+
+- **Where the records are.** #192 brought this file and run C's plan to
+  main. The 2026-10-07 record has been on main since #189 (`63810dd`), not
+  on a branch as the paragraph above says.
+- **What run C superseded.** No record: runs A and B stand as recorded. Its
+  plan did replace run B's as the
+  [mapping](../../openspec/changes/migrate-to-triad/adoption-plan.yaml), on
+  main in #192's squash `1abee1d`. (On #192's branch it was merge `1a26463`,
+  which main does not contain.) On main that link opens run C's plan from
+  both records.
+  So "On this branch" in the mapping section below holds for main, and the
+  2026-10-07 record's "On this branch, the mapping is the regenerated run B
+  plan" held only on its own branch. Run B's plan stays in history at
+  `63810dd` (blob `f1067e3`). Neither plan is the cutover plan.
+- **Runs A and B are gone from the bench.** The bench restart of
+  2026-10-08, at about 09:45Z, cleared `/tmp` (#186 comment 6068861167).
+  Both runs were built in a session scratch directory there, as the
+  2026-10-07 receipt's README records, so their disposable repositories are
+  gone and their logs survive only in that receipt. Two of their commits
+  live on in run C's legs: `558a12b`, the spec head of runs A and B, is the
+  parent of run C's spec head, and `48d98cd`, run A's code head, is the
+  parent of run C's code head. The splits `9e5f934` and `2726d3a`, run B's
+  code head `6d52162` and the local remotes are gone. That is why run C is
+  kept host-local.
+- **An observation left out.** The run C comment on #186 (6068938765)
+  noted that `openspec validate migrate-to-triad --strict` with `openspec`
+  1.2.0 fails on pristine `837928a` too (`ADDED "Installation retains the
+  public interface and one revision" must contain SHALL or MUST`), so run C
+  does not cause it. Lane 2's bench had `openspec` 1.13.1 (read on
+  2026-10-09, #186 comment 6088829392 item 8, and again on 2026-10-10,
+  6103482530). On 2026-10-09 the same command exited 0 on `837928a` and on
+  `71b05cb`, #192's head, whose tree its squash `1abee1d` carries unchanged.
+  *Corrected 2026-10-11 (lane 3's 5481348731 on #196, item 9): this note first
+  said "The bench's `openspec` is now 1.13.1", as if one version held on every
+  host. The version depends on the container. On lane 3's host on 2026-10-11 at
+  00:1xZ, `which -a openspec` lists a user-level npm install first, at 1.2.0,
+  and the system install second, at 1.6.0. The validate command above exits 1
+  under 1.2.0 (the SHALL or MUST error) and 0 under 1.6.0. So the result follows
+  which `openspec` comes first on the reader's `PATH`. Lane 1's walk records
+  the same split
+  ([gate-b-status-2026-10-09.md](gate-b-status-2026-10-09.md), section 4 (a)).*
+
 ## Setup
 
-- **filter-repo:** `git-filter-repo` 2.47.0 from a private venv. The rebuilt
-  bench has no `ensurepip`, and `python3 -m venv` refused with
+- **filter-repo:** `git-filter-repo` 2.47.0 from a private venv.
+  `python3 -m venv` refused with
   `The virtual environment was not created successfully because ensurepip is
   not available.` So the venv was created with `--without-pip`. The wheel
   came from `pip download` with SHA256
   `2cd04929b9024e83e65db571cbe36aec65ead0cb5f9ec5abe42158654af5ad83`, matching
   the recorded value. That exact file was installed into the venv with
   `--no-index`. The venv's `git-filter-repo` came first on `PATH`, and
   `git filter-repo --version` printed `a40bce548d2c`.
+  - *Corrected 2026-10-09 (#193 item 12):* this bullet first gave the cause
+    as "the rebuilt bench has no `ensurepip`", and the bench contradicts it.
+    Its dpkg log has `python3-venv` and `python3.12-venv` installed on
+    2026-09-23 at 00:18:06Z, before the 2026-10-08 boot.
+    `/usr/bin/python3 -m ensurepip --version` prints `pip 24.0`, and
+    `/usr/bin/python3 -m venv` succeeds (lane 2, #186 comments 6072333212
+    and 6072724043; measured again on 2026-10-09). The refusal itself is
+    real: the receipt's setup log records it. Its cause is not established.
+    The `python3` the writer ran was the first on its `PATH`: the venv's
+    `pyvenv.cfg`, in run C's host-local arrangement, records a user-local
+    `python3` based on `/usr/bin/python3.12`. That entry is no longer on
+    the bench, so the refusal cannot be retried as it ran.
 - **Tool and source:** a fresh clone of openRepoShape at `7f84ca4`, unedited
   and clean afterwards, ignored files included. A fresh `--single-branch`
   clone of main, with one worktree and no linked worktrees. Its nested
@@ -65,6 +120,20 @@ published copy. It differs from the executed plan only by its header,
 `local_path: .`, and the two closing status fields
 (`execution_authorized: false`).
 
+*Added 2026-10-09 (#193 item 10):* `check` validates against the source
+clone's local `main`, not its `HEAD`. In openRepoShape `7f84ca4`'s
+`adopt-project.py`, `_default_branch` (:288) takes the branch name from
+`origin/HEAD`, and `git rev-parse` of that name (:256-257) is the commit
+compared with the plan's source commit (:1026-1032). This plan therefore
+passes `check` only in a clone whose local `main` is `837928a`. Against any
+newer `main` it exits 1 with `FINDING plan-stale: the plan was written
+against 837928a1029a but main is now at …`, whatever `HEAD` is checked out.
+That includes main once this plan is on it: a plan cannot name the commit
+that carries it. Measured on 2026-10-09 with this plan and a fresh clone,
+local `main` at `63810dd` gave that finding and exit 1, also with `HEAD`
+detached at `837928a`. Local `main` moved to `837928a` gave `plan ok` and
+exit 0, also with `HEAD` detached at `63810dd`.
+
 ## Run C — main `837928a`
 
 `execute --local-remote-dir … --work-dir … --yes` exited **0** and printed