Wave-2 phase-0 records: X17 interim installs, install plan, client-configuration map and templates, skills, K4 guard and handbook - #659

… rows

Install plan (evidence/artifacts/new-wsl-install-plan-20261002/):
- memory-owner (ai-memory 2.5.2, 127.0.0.1:29374, local embedder), code-search (semble 0.6.1 with
  the model pinned to a local snapshot) and context-supply (context-mode 1.0.169: Claude plugin
  with the stats.json-only compare gate, Codex plugin at --ref 6f0cc684, verified npm tarball)
  install as interim rows; statusline (claude-hud 0.10.0) is added. All UNRUN.
- research-harnesses: DeerFlow as the embedded DeerFlowClient (uv sync --locked; no Compose,
  service or port), GPT Researcher through tools/research/gpt_researcher.sh (research changes
  2-5, 9, 18; synthesis X18), with a keyless committed configuration and a fail-closed preflight.
- tobi-qmd: needs.gpu true, config paths, an after-provisioning check (qmd change 16).
- gpt-gateway: EMBED_WS_PROXY_PORT=21131 and plain NAME=value lines (gateway change 12); X1-X3
  notes on the observability rows and the gateway row.
- The three skills rows delegate to tools/adoption/install_skills.py (skills change 7).

Skills (skills changes 1, 3, 6): grill-me, improve-codebase-architecture and semgrep retired
(dated addendum, template off, runtime-worker reuse entries and coverage removed); agent-browser
held; skill-creator a Claude-Code-only copy. install_skills.py and skills_status.py learn the
held state and the agents/copy fields, with tests. The Codex template disables the bundled
skill-installer by path.

check_plan.py passes (70 rows). The client configuration, the handbook and the evidence
registration follow; their checks still fail at this commit.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

… lines and builder fixes

Phase 0.3 of the wave-2 synthesis (sha256 3b512613...), with the rulings it cites:
- Map: semble (Claude and Codex entries, per-client SEMBLE_CACHE_LOCATION, SEMBLE_MODEL_NAME on the pinned snapshot,
  approval mode and two exact-name allow rules in the authorization class; code-search changes 2-5), the statusline
  row (claude-hud v0.10.0 marketplace and the setup.mjs command at 75683c6d as overrides, statusLine keep_existing;
  Codex [tui] status_line; usage changes 3-5, 8, 9), the six context-mode [hooks.state] entries (context change 9),
  Codex inherit = "none" with its set table (custody change 7), ai-memory at the host file's AI_MEMORY_URL (X5).
  The cache-heal hook stays unwired (the plugin writes it; X11). rtk, headroom and SocratiCode stay slot entries.
- Builder: AI_MEMORY_BIN from the plan's memory-owner link (render_config.py would derive the 2.4.1 pin path); host
  values filled in an MCP override; the verify step skips http servers; agent gaps count a wired plugin's tools and
  skills (context change 14); an allow rule already present counts as the same; labels name the Codex profile and
  allow rules; the default authorization line names approval modes and allow rules. codex_home.py gains
  --keep-hook-trust so a new Codex home and a merge end the same.
- Instruction lines in both sources (context-mode lane, semble, GPT Researcher, messaging; Codex lines after their own
  marker), blocks regenerated; the Claude template's word baseline re-recorded with the reason.
- Tests and records follow: client-config tests (145), the decision record's addendum and regenerated tables, and the
  shared suites the templates and the earlier skills commit touched (install profile, worker lane, scaffold, landscape
  sweep, recipe, docs consistency).

validate.py still fails on manifests/evidence.json registration, and the handbook check on the wave-2 consensus row;
both follow on this branch.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…ains host alerts

Phase 0.5 of the wave-2 synthesis:
- K4 (custody change 11): 21128, the new WSL distribution's single-port gateway, takes 20128's permit rows; 21129, its
  live-dashboard WebSocket, takes none, so every covered /api/ request to it refuses. The ports join K4_GW_HEAD,
  K4_GW_FIND and the gateway anchors (2112 beside 2012), so interpreter code that names only a 2112x port is read too.
  Tests: the frozen matrix rows and the refused-port set, and destination cases (/api/providers/client on curl, wget,
  xh, node and Python; /v1 allowed). adoption/hooks/claude/SHA256SUMS carries the new hash. This host's installed
  guard differs until install_claude_profile.py --only guard runs, so test_host_profile_copy_is_verbatim fails here.
- currency_due.py (lifecycle change 7): a fifth count, host_alerts, from the backup and restore-check status records
  (change 8's last_success/last_attempt shape; failed or partial, overdue past 48 h or 8 days, unreadable) and from the
  user manager's unit properties (an enabled stage-2 unit or dagu.service that is failed or inactive). A host without
  the record or the unit has no alert; a user manager that cannot be asked is coverage. Tests and a dated addendum to
  docs/decisions/2026-09-30-session-currency-notice.md.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

- scripts/build_new_wsl_handbook.py: consensus_slots() reads the layer-consensus record's wave2.add_rows (the statusline
  row) beside its first batch; the counts check mirrors the producer's interim count (amendment 3; present when the
  manifest records consensus_wave2); a waiting row that carries an interim install shows it in the Install column
  beside its decided default's reason, and the inventory sentence names how many do.
- docs/new-wsl-handbook.md and .json regenerated; evidence/artifacts/new-wsl-handbook-20261001/receipt.json carries the
  new generator and output digests (the profile and the inventory are unchanged).
- tests/test_new_wsl_handbook.py: 90 rows and six consensus rows, amendments from both batches, and the interim display.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

- docs/secret-storage.md: the gateway matrix the guard's docstring names follows K4_GW_ROWS (21128 takes 20128's rows;
  21129 none; wave-2 custody ruling, change 11).
- catalogs/landscape/skills-lifecycle.json: the installed lists follow adoption/skills/manifest.json after the wave-2
  skills ruling retired grill-me, improve-codebase-architecture and semgrep (changes 1 and 3): the design-intake task
  has no installed skill, codebase-design alone serves architecture, and the security task names the custom static
  rules as unowned; checked_at stays the sweep's date. tests/test_landscape_sweep_skills.py: no pinned skill keeps a
  listing other than on, so only the Codex flag kind is stated today.
- tests/test_windows_terminal_defaults.py: [tui] status_line joins the pinned keys after its upstream check
  (Tui.properties.status_line in codex-rs/core/config.schema.json at rust-v0.160.0; the six ids are StatusLineItem
  variants of codex-rs/tui/src/bottom_pane/status_line_setup.rs at that tag).
- blueprints/convergence-practice/wsl-new-distro-image-20261001/experiment.json carries the new hashes of the recipe and
  its test, both changed on this branch, as PR #608 did for the same two inputs.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…hell policy, remote plugin rules, apply gate

Review of the wave-2 records branch, 2026-10-03 (one repair round):

- Blocking (custody change 7, synthesis X12): Codex shells under inherit = "none" now get XDG_RUNTIME_DIR
  (/run/user/<uid> of the user the builder runs as, [email protected](5)) and DOCKER_HOST
  (unix://${XDG_RUNTIME_DIR}/docker.sock, wired through the container-engine slot); a render test holds both.
- New-distribution keys leave the shared templates: inherit = "none" with its set table, both semble servers,
  semble's Claude allow rules and ai-memory's Codex approval mode move to adoption/new-wsl/templates/*.additions.*,
  which only tools/adoption/new_wsl_client_config.py reads (template_data merges them; a key both define is refused).
  codex.config.template.toml, claude-user.json, the Claude settings template and bootstrap.md step 4a are again what
  every other host renders, so decision 5 of 2026-09-26-codex-worker-lane.md stands unamended there.
- Messaging change 1: the Codex instruction block runs the research script and the courier as long commands
  (yield_time_ms 30000, then write_stdin polls with empty chars until the process exits; codex-rs rust-v0.160.0
  unified_exec/mod.rs L73-77, shell_spec.rs L117-154); blocks regenerated, top-rule hash and word count updated.
- Skills change 5: --apply reads the account's remote plugin cache and adds one [[skills.config]] name rule per
  plugin skill (<manifest name>:<frontmatter name>, as Codex qualifies it) and an off switch per plugin MCP server
  (map piece step/codex-remote-plugin-rules); arrays of tables are written as [[...]] items and the merge adds the
  render's rules a file lacks after its own, refusing an inline array.
- Code-search change 1: a real --apply refuses while consensus.json wave2.acknowledgements_owed names a family and
  the render wires an interim install; a dry run says so.
- Map entry for ai-memory's Codex hook trust and recipes/README.md:145 amended for the X10 route.
- Record tables and counts regenerated (385 pieces).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…ontext-mode auto-update check, wave-2 docs

Review of the wave-2 records branch, 2026-10-03 (one repair round):

- Code-search change 1 gate: install.sh's interim_acknowledged reads wave2.acknowledgements_owed from
  consensus.json with jq and refuses while it names a family; each interim row's install function calls it first,
  and check_plan.py fails a plan whose interim function does not. Recorded in the layer-consensus record, Wave 2.
- memory-owner (memory changes 12-13, synthesis X10/X11): ai-memory's own `install-hooks --agent codex --apply`
  writes its seven Codex hooks once (the X11 exception: the builder writes no ~/.codex/hooks.json); the post-install
  check reads the seven events back from hooks.json (ai-memory 7580b74d docs/install.md L118-121, L593-595;
  install_hooks.rs L2071-2093; render_shared.rs L907-915). The row note no longer forbids it; trust per X10.
- context-supply (context change 17): the notes say why the default-head route stays behind the compare gate, and
  the acceptance checks that marketplace auto-update is off (code.claude.com/docs/en/plugins/loading).
- The assembler resolves an owner decision's relayed_by in the hashed record it names and requires the entry to
  name the slot or the owner, dated as the authority; the browser hold is enforced by the record.
- Tests: check_plan.py mutations (interim not installed, owner not the interim's, gate missing) and the gate itself
  against scratch consensus files; six new assembler refusals.
- SOURCES.md, README.md and VALIDATION.md gain Wave 2 sections; counts are 70/42/3/25; the OmniRoute env line is
  exported with set -a; the DeerFlow Compose route is marked superseded.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

… shape for both acknowledgement gates

- with_remote_plugin_rules writes enabled = false on each remote plugin table it touches. Read at rust-v0.160.0: a
  local [plugins."<id>"] table defaults enabled to true (config/src/types.rs L1004-1006), a local entry the synced
  remote list lacks stays as configured (core-plugins/src/loader.rs merge_configured_plugins_with_remote_installed),
  and load_plugin loads an enabled entry whose bundle is cached, so a table with only the MCP server switch would turn
  on a cached plugin the account no longer installs. Docstring and the client-configuration record now say so.
- install.sh's interim_acknowledged refuses a list holding an empty name, as owed_acknowledgements does; the bash test
  covers the same inputs as the builder's ({} and [""] added).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

… and repository pairs its record lists

The Codex root lane's source read of b6828c7 (finding 1, P2): relayed_decision took a mention of the slot or the
repository's last part anywhere in the relayed decision's text for the owner's authority, so a browser interim for
crawl4ai, which owner_decisions[0] names only as a candidate the kept browser hold measures first, was admitted.

- wave2-records.json: each owner_decisions entry gains `authorizes`, the exact slot and repository pairs its decision
  installs or puts to use, under the decision's own verb (memory-owner akitaonrails/ai-memory and code-search
  MinishLab/semble by `install` in [0]; context-supply mksglu/context-mode by `use` in [1]); the method says the
  coordinator structures it and that a kept hold is in no list. Its sha256 moves to c091152f... in consensus.json's
  four references; definitive-manifest.json and the handbook are regenerated (hash fields only), and the handbook
  receipt's two output digests follow them (generator, profile and inventory unchanged).
- assemble_manifest.py relayed_decision: after the mention and before the date check, the entry must list the
  interim's slot and repository (norm) under an action in AUTHORIZING_ACTIONS ("install", "use").
- Tests: two refusal cases in test_the_assembler_refuses_an_interim_outside_the_rule (crawl4ai on playwright-cli; an
  authorized repository in another authorized slot) and test_an_owner_decision_authorizes_only_the_exact_pairs_its_
  record_lists (each recorded interim is a listed pair; the old input refused; scratch-record grants missing, of
  another action, slot or repository refused; the unchanged entry admitted). controls.py gains the crawl4ai case.
  Negative control: the b6828c7 assembler accepts both new inputs (run once against its blob).
- The layer-consensus decision record and the consensus folder's README state the rule.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…ule list, refused as inline, never a kept conflict

The Codex root lane's source read of b6828c7 (finding 2, P2): with a valid existing `[skills] config = []`,
is_table_array([]) is false, so plan_merge kept the render's skill-installer and remote-plugin disable rules out as an
ordinary conflict and the step ended `merged with conflicts kept` without them.

- plan_merge: an existing empty list counts as a rule list, so the render's rules are planned as appends after the
  file's own (none), not as a conflict. TOML writes an empty array only inline and TOML 1.0 forbids adding [[...]]
  items to a statically defined array, even an empty one, so merge_toml_text reaches its existing inline-array
  refusal and nothing is written; the message adds that removing the empty key is enough. is_table_array is
  unchanged, so the writer still writes an empty list as `key = []`.
- The remote-plugin line says the rules and off switches are planned and in place once the codex-config step has
  written and read them back, instead of "turned off" before any write.
- Test test_an_existing_rule_list_gains_the_rules_or_is_refused_and_an_empty_one_is_never_kept_as_a_conflict: the
  plan for the empty and the non-empty list (appends, no conflict, the merged list), the empty file refused with the
  file unchanged and no conflict reported, the same file without the key gaining both rules, and a non-empty array of
  tables extended after its own rule with every line kept. Negative control: against the b6828c7 blob the empty plan
  is a conflict with no appends and the apply exits 0 without the rules.
- The usage text and the client-configuration decision record say so.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…wn folder with no shared same-name entry

The Codex root lane's source read of b6828c7 (finding 3, P2): classify_skill returned ok for a global copy entry from
the pinned SKILL.md bytes and the lock entry alone, so --check-only, which the install plan's smoke check runs, passed
a Claude entry that is a link onto the shared folder, or a real copy beside a same-name entry in ~/.agents/skills,
where Codex loads skills; scripts/skills_status.py fails both layouts.

- copy_placement_problem: the Claude entry must not be a link, and the shared canonical folder must hold no entry of
  the name (os.path.lexists, as skills_status.py reads it). classify_skill returns 'misplaced' for either, before the
  lock and bytes are read.
- process_skill refuses 'misplaced' in every mode (--check-only, --dry-run and --force included), names the path and
  the condition, runs no add or remove and deletes nothing; the exit status is 1.
- Test test_a_copy_is_ok_only_as_claude_codes_own_folder_with_no_shared_entry: the same pinned bytes and lock entry in
  four layouts; a real Claude folder is ok (the positive control); a link, a shared same-name folder and a dangling
  shared link are misplaced in all four modes with the home unchanged and no add or remove. Negative control: against
  the b6828c7 blob all twelve misplaced subcases return ok with exit 0.
- The module docstring, the --check-only help, adoption/skills/lifecycle.md and the skills decision record's wave-2
  addendum say so.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…ollows the Codex home

Review thread "Resolve the bundled skill path from CODEX_HOME" (chatgpt-codex-connector on b6828c7): the rule
path = "${HOME}/.codex/skills/.system/skill-installer/SKILL.md" missed Codex's bundled copy wherever the Codex home is
not ~/.codex. codex_home.py (L250) writes the rendered config into $CODEX_HOME/config.toml when CODEX_HOME is set
(apply_codex_lane.py L457 resolves the same home), and bootstrap-linux.sh (L994-995) runs codex_home.py without
--codex-home, so on such a host the bundled skill-installer stayed on. new_wsl_client_config.py refuses CODEX_HOME for a real run (L1951-1955) and writes
<home>/.codex (L1981), so the new distribution's route was not affected.

- adoption/templates/codex.config.template.toml: path = "skills/.system/skill-installer/SKILL.md". Codex installs its
  bundled skills in <Codex home>/skills/.system (openai/codex rust-v0.160.0 codex-rs/skills/src/lib.rs L62-69) and
  resolves a relative path in the user config.toml against that file's folder (config/src/loader/mod.rs L557,
  L573-582, L1424-1445; utils/absolute-path/src/lib.rs L392-405). The same functions are at rust-v0.159.3 and
  rust-v0.155.1 (loader L584, L609, L1443 there). scripts/skills_status.py codex_rule_path already models this
  resolution. No new render placeholder: render_config.py, the host value files and the bootstrap are unchanged.
- tests/test_render_config.py test_the_bundled_skill_installer_rule_follows_the_codex_home: the rendered rule is
  relative and resolves under ~/.codex and under another Codex home. Planted negative: the earlier absolute form,
  resolved the same way, misses the other home (checked against this branch's previous template: False).
- tests/test_new_wsl_client_config.py: the three applied-config expectations take the relative rule.

Local probe (this host, codex-cli 0.159.3, the Linux pin; app-server skills/list with a scratch HOME and a scratch
CODEX_HOME that is not HOME/.codex, one rule in its config.toml; output not retained as a receipt):
  no rule                          -> skill-installer enabled true
  path = "skills/.system/..."      -> enabled false (and false with CODEX_HOME unset, config in HOME/.codex)
  path = "<HOME>/.codex/skills/..." -> enabled true (the reported defect)
The destination pins 0.160.0, whose files above are the same functions; that version was not run.

Caveat: when a whole user config.toml fails ConfigToml typing, the loader keeps it unresolved (loader L1430-1433)
and skill_config_rules_from_stack then skips that file's [[skills.config]] rules as invalid (skills_config.rs
L163-168); an absolute rule does not depend on that typing.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…terval 5, accept the configured command

Review thread "Run claude-hud setup before wiring its copied launcher" (chatgpt-codex-connector on b6828c7): the
statusline row stopped after the plugin install, but the status line the client configuration renders,
'<mise node>' '<config dir>/plugins/claude-hud/statusline.mjs' (adoption/new-wsl/client-config-map.json L205), names
the launcher that only upstream's helper copies there (jarrodwatts/claude-hud@75683c6d scripts/setup.mjs L69-80), and
the acceptance ran the cached scripts/statusline.mjs directly, so it passed while Claude Code's configured status line
had no file to run. The wave-2 usage ruling (wave2-records.json, layers.analytics-statusline, changes 3 and 4) already
says automation runs the helper without prompts; the row's notes left it to a step outside the plan.

- install.sh statusline() and install-plan.json commands: two commands after the plugin install. (1) In the one cached
  0.10.0 (refused with none, or with 0.10.0 in two marketplaces), under the first of bun and node on PATH
  (commands/setup.md L24; mise's Node here), `setup.mjs inspect --shell posix`, then `install --shell posix`
  (setup.md L35 and L58): install copies the launcher, backs up settings.json and writes statusLine (setup.mjs
  L69-101). (2) refreshInterval 5 when the statusLine has none (code.claude.com statusline.md L69): setup.mjs keeps
  earlier statusLine keys only when they were claude-hud's (L94), and the client configuration's apply keeps a
  statusLine the file has (keep_existing), so nothing else would add it. Written to the real file behind a link, its
  mode kept, through a temporary file in the same folder.
- accept.sh and install-plan.json acceptance: the configured statusLine.command, run through bash as Claude Code runs
  it (setup.md L10), with upstream's sample input (L72) must print two lines; statusLine.type command,
  refreshInterval 5, the command naming the copied launcher, that copy equal to 0.10.0's scripts/statusline.mjs and
  one cached version. The name check sits in the last [[ ]], so it does not rest on errexit.
- Row notes, README.md, SOURCES.md and VALIDATION.md (check_plan.py: 87 commands, 62 acceptance entries); the plan's
  and owners.json's revised_at_utc.
- tests/test_new_wsl_definitive_defaults.py StatuslineInstallAndAcceptance runs the row's own strings with a scratch
  HOME, links to the system tools and a stand-in runtime: the helper's calls and its three refusals; refreshInterval
  added only when absent, through a link, mode kept; the acceptance passes the wired state and fails each planted
  condition (the copied launcher missing, no or another refreshInterval, another version's copy, a second cached
  version, a command that runs the cached launcher). Negative control: on the missing-copy fixture the acceptance as it
  was (this branch before the change) exits 0; the new one exits 2.

Not run: upstream's helper and launcher, and anything on a distribution; the row stays UNRUN.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…the relative path

Follows e622dcb (the rule follows the Codex home): ListingBudgetTemplateTests read the template's one
[[skills.config]] rule as the earlier ${HOME}/.codex/... string, and the acceptance run of the seven unittest modules
failed it (1 of 502). It now expects path = "skills/.system/skill-installer/SKILL.md" and names the test that resolves
it under any Codex home.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…le protocol)

The branch's last commit, by docs/lanes.md's hot-file protocol, on origin/main ecea286: main's manifest, with the
54 files this branch changes that main's manifest lists re-registered through host_receipts.register_file, and the
branch's one new evidence file, evidence/artifacts/new-wsl-layer-consensus-20261002/wave2-records.json, registered (55
entries; no entry removed; receipts[] and convergence_records[] as main has them). It replaces 42c43b3 (the same
registration on 4ced292, before the two review repairs), so the manifest change sits in the last commit only. Against
42c43b3's set, two entries are new: adoption/skills/lifecycle.md (main's manifest lists it now) and
tests/test_render_config.py (changed by the review repair).

main's files[] at ecea286 is out of order at one entry (docs/decisions/2026-10-03-omniroute-sdk-worker-0160.md after
docs/decisions/2026-10-03-retire-pr320-loki-denominator-host-receipts.md; read from origin/main's file), and
scripts/validate.py refused this registration for it ("files[] must be sorted by path"); scripts/evidence_manifest.py
--write sorted it, moving that one entry and changing no entry's fields.

component_matrix.py and new_host_grand_list.py were rewritten and are unchanged. validate.py passed (9498 hashed files,
191 receipts).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…json (hot-file protocol)

Re-registered with host_receipts.register_file, in place, sorted order kept:
the install plan's accept.sh, install-plan.json, SOURCES.md and VALIDATION.md,
and tests/test_new_wsl_definitive_defaults.py. component_matrix.py --check and
new_host_grand_list.py --check pass, so neither report is rewritten.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…losed without one

Codex root review of 06f6259, finding 2 (macOS CI run 37141171758: exit
127, "env: timeout: No such file or directory"). gpt_researcher.sh ran a
bare `timeout` inside its env -i child, whose PATH is /usr/bin:/bin; macOS
has no timeout there, and a parent PATH change cannot reach that child.

- gpt_researcher.sh: the timer is resolved in the parent, before the run
  directory and the scrub, with `type -P` (a PATH search for an executable
  file only): GNU coreutils' timeout, else gtimeout, the name Homebrew's
  coreutils gives it on macOS; a relative result is anchored to $PWD. The
  scrubbed child runs it by absolute path with the same 1500 seconds; the
  child's environment and PATH are unchanged. With neither timer, the
  research run stops with exit 1 and a message naming both, after the
  preflight and before the CLI starts; --preflight-only needs no timer.
- tests/test_research_entry.py: the fixture finds the host timer the same
  way and puts first on the wrapper's PATH a `timeout` that records its
  arguments and runs that timer; the run test checks the CLI ran under it,
  by absolute path, with 1500. It skips, with the reason stated, only where
  no supported timer exists: the GitHub runner image of the macos-15 label
  lists no coreutils, timeout or gtimeout (actions/runner-images README.md
  L34 at a99056ad; images/macos/macos-15-arm64-Readme.md at f95c0c79 and
  images/macos/macos-15-Readme.md at 07cc2190). Negative control: with a
  PATH of only bash, env, dirname, date and install, the run exits 1, not
  127, names the missing timer, and the CLI never starts.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…(hot-file protocol)

Re-registered with scripts/host_receipts.register_file, on the branch's own
registry: the install plan's accept.sh, install-plan.json, SOURCES.md and
VALIDATION.md, and tests/test_new_wsl_definitive_defaults.py (sha256 and
bytes only; files[] stays sorted and unique, 9,542 paths).
tools/research/gpt_researcher.sh and tests/test_research_entry.py were not
in files[] and stay unregistered.

Co-Authored-By: Claude Opus 5.5 <[email protected]>