PR-H (#381) Amendment 2: adopt the #402 role bodies before execution (Opus verifier and builder, builder base binding) - #413

…ld-routing

The lean-workflow-child-routing activation in catalogs/foundation/decisions.json
still described isolated-builder as "Sonnet/max". All three copies of its
definition (.claude/agents, adoption/agents/claude,
examples/claude-native/agents) declare model: opus and effort: max since the
2026-09-27 harness-settings change (docs/decisions/2026-09-27-claude-harness-settings.md,
item 1), and the token-e2e runner binds it to opus (Amendment 2, #413). This
closes follow-up 5 of that record's independent verification.

A new test, CheckedInAgentLabelTests, compares every "`agent` (Model/effort)"
label in the foundation decisions with the agent's frontmatter, read with a
regex so it needs no PyYAML.

Evidence: the test failed at ec8a489 (('sonnet', 'max') != ('opus', 'max'))
and passes now; tests.test_foundation_catalog and scripts/validate_foundation.py
through test_checked_in_catalog_passes stay green.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…ld-routing

The lean-workflow-child-routing activation in catalogs/foundation/decisions.json
still described isolated-builder as "Sonnet/max". All three copies of its
definition (.claude/agents, adoption/agents/claude,
examples/claude-native/agents) declare model: opus and effort: max since the
2026-09-27 harness-settings change (docs/decisions/2026-09-27-claude-harness-settings.md,
item 1), and the token-e2e runner binds it to opus (Amendment 2, #413). This
closes follow-up 5 of that record's independent verification.

A new test, CheckedInAgentLabelTests, compares every "`agent` (Model/effort)"
label in the foundation decisions with the agent's frontmatter, read with a
regex so it needs no PyYAML.

Evidence: the test failed at ec8a489 (('sonnet', 'max') != ('opus', 'max'))
and passes now; tests.test_foundation_catalog and scripts/validate_foundation.py
through test_checked_in_catalog_passes stay green.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…addendum (fallback guards, template advisor, catalog label) (#470)

* Model currency record: every routed model current; holds, gates and the routes to an older model

Record the 2026-09-27 model-currency check the user asked for ("only the latest
SOTA models, even the latest ones released in the past weeks"): three Opus
research units (Claude, OpenAI/Codex with OmniRoute, open-weight workstation
models), one adversarial refuter each and one synthesis.

- Decision table per lane and role: current, latest available with release
  date, action. No row switches; four hold behind upstream gates:
  jina-reranker-v3.5 for qmd (stock llama.cpp rank-pooling, #26286 open),
  Nemotron-3-Embed-1B for ai-memory (2.5.0 with #859), Sonnet 5.5 and Haiku
  5.5 (announced, no model ID), and Opus 5.5 on OmniRoute (the gateway lists
  no claude-opus-5-5, so Opus-role stages stay on native Claude Code).
- The committed-settings fallback guards, the template advisor and the
  isolated-builder label are recorded with their evidence classes.
- llama.cpp: v0.5.0 is b11146 (commit 7fe450e1); the 2026-09-25 re-pin gate
  (paired acceptance against a fresh b11057 baseline) has not run, so the
  b11057 pin stays and the divergence and the qualification are recorded.

Sources (re-fetched 2026-09-27): platform.claude.com release notes, models
overview and model deprecations; anthropic.com/claude-opus-5-5;
code.claude.com settings-reference, model-config, advisor, env-vars and
settings; anthropics/claude-code CHANGELOG at 7779afb1 (tag v2.1.283);
developers.openai.com API changelog; registry.npmjs.org
@anthropic-ai/claude-code (latest 2.1.283); gh api for ggml-org/llama.cpp
tags b11057, b11146, v0.5.0 and releases/latest, akitaonrails/ai-memory
releases and #859, vllm-project/vllm and tobi/qmd releases; a read-only
GET /v1/models on the loopback gateway (582 IDs, 55 Claude, no opus-5-5).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Model-fallback guards in the committed project and portable Ultracode settings

.claude/settings.json and examples/claude-native/ultracode.settings.json now
carry the template's two guards in the template's form: "switchModelsOnFlag":
false and env CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK="1". The recipe's embedded
copy of the portable file matches it. Before this, a session that loaded only
this repository's files, or an adopter running claude --settings with the
portable file, could re-run a flagged Opus 5.5 or Fable request on Opus 4.8
(cybersecurity) or Opus 5 (biology). This closes the "ultracode recipe alone"
gap of docs/decisions/2026-09-25-model-fallback-guard.md.

Sources (fetched 2026-09-27):
- code.claude.com/docs/en/settings-reference#switchmodelsonflag: "Scope: Any
  file"; false pauses an interactive session and ends a -p request as an
  error. The env entry: "Scope: Any file"; project values apply after
  workspace trust or at -p startup; the documented project ignore list does
  not name either key.
- code.claude.com/docs/en/model-config#automatic-model-fallback: the targets.
- CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK is not found in env-vars, model-config,
  settings-reference or the CHANGELOG at anthropics/claude-code 7779afb1
  (tag v2.1.283). Source review of the installed 2.1.283 client: jD() is
  !a.CLAUDE_CODE_DISABLE_REFUSAL_FALLBACK&&!Ote(); the fallback handler runs
  only on jD() or a server-armed same-model silent retry (IAr returns the
  refusing model); orn() returns "subagent" before it reads
  switchModelsOnFlag; a's getters (Rhn) read process.env live; the project
  ignore set Qzn does not contain the variable. Not probed.

Evidence: CommittedSettingsFallbackGuardTests failed at ec8a489 for both
files (None != '1'); after the settings edit the recipe-copy test failed
until the recipe matched; both pass now. node test-envelope.mjs 254/254 and
node test-contract-mutations.mjs 74/74 before and after.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Claude profile template: advisorModel "fable" so a new host gets the assigned advisor

The user's rule pairs the Opus 5.5 main model with Fable 5.1 as the native
advisor for truly complex calls, and this host carries advisorModel "fable"
in its user settings, but the adoption template had no advisorModel key, so a
new host that applied it got no advisor.

Sources (fetched 2026-09-27):
- code.claude.com/docs/en/settings-reference#advisormodel: "Scope: Any file";
  "fable", "opus", "sonnet" or a full model ID; unset leaves the advisor off;
  /advisor saves the pick to ~/.claude/settings.json, the file the template
  renders into.
- code.claude.com/docs/en/advisor, "Choose an advisor model": an Opus 5.5 main
  model accepts "Fable, and Opus 5 or later" (the template's model is
  opus[1m]); Sonnet 5 accepts Fable; subagents inherit the advisor under the
  same pairing check (documented, not observed). Without Fable access or
  the usage-credits consent, requests go without the advisor and an
  interactive session shows a notification pointing to /model fable.
- code.claude.com/docs/en/env-vars, "Features that need feature-flag
  fetching": the template sets none of the variables that turn fetching,
  and so the advisor, off, nor CLAUDE_CODE_DISABLE_ADVISOR_TOOL.

apply_claude_settings.py merges scalars with the template winning, so a
re-apply resets a host that chose opus or no advisor; the record says how
such a host keeps its choice.

Evidence: test_the_advisor_is_fable_and_accepted_for_the_main_model failed
at ec8a489 (None != 'fable') and passes now.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Foundation catalog: isolated-builder is Opus/max in lean-workflow-child-routing

The lean-workflow-child-routing activation in catalogs/foundation/decisions.json
still described isolated-builder as "Sonnet/max". All three copies of its
definition (.claude/agents, adoption/agents/claude,
examples/claude-native/agents) declare model: opus and effort: max since the
2026-09-27 harness-settings change (docs/decisions/2026-09-27-claude-harness-settings.md,
item 1), and the token-e2e runner binds it to opus (Amendment 2, #413). This
closes follow-up 5 of that record's independent verification.

A new test, CheckedInAgentLabelTests, compares every "`agent` (Model/effort)"
label in the foundation decisions with the agent's frontmatter, read with a
regex so it needs no PyYAML.

Evidence: the test failed at ec8a489 (('sonnet', 'max') != ('opus', 'max'))
and passes now; tests.test_foundation_catalog and scripts/validate_foundation.py
through test_checked_in_catalog_passes stay green.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Model currency record: receipt review status, deniedModels alternative, bin/vllm follow-up closed

Review repair (one round):
- The three 2026-09-26 llama.cpp host receipts carry independent_session
  reviews: agree for install-2 and use, needs_changes for the superseded
  first install receipt. The serving-switch receipt has no reviews field,
  and its limitations[4] "only self reviews" sentence predates them. The
  b11057 pin stands: the paired acceptance against a fresh b11057 baseline
  is the remaining gate (eval_arm.py pins every li26 arm to b11146).
- Alternative 4: the Claude Code 2.1.283 deniedModels setting, not adopted
  because it is managed-only; the guards' Overturn now names it.
- The workstation refresh record's bin/vllm follow-up is closed on this
  host, from the coordinator's host observation (one dated line).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Model currency record: the bin/vllm evidence row names no receipt in the repository

The coordinator's host observation has no receipt in this repository
(no evidence file changed between ec8a489 and origin/main); the row no
longer implies that none exists anywhere.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Model currency record: GPT-6 review repairs (qmd formats and 0.6B expander, li26 scope, coordinator effort)

The cross-family review found five defects, each verified against source:
- qmd 2.8.3 formats Qwen3-Embedding as well as EmbeddingGemma (src/llm.ts L86-119) and takes other models through QMD_EMBED_MODEL (L281-282, L303-304); the embedding row no longer says a 2026 embedder needs a qmd change, and cites the Gemma releases page for the 2025-09-04 date.
- tobil/qmd-query-expansion-0.6B-gguf (2026-04-24, edddacb0) is newer than the 1.7B default (L285) and loadable through QMD_GENERATE_MODEL (L307-308); it is listed as an evaluation candidate, not a switch.
- The llama.cpp row limits its claim to li26's arms and proxy workload.
- The main-session row gives the coordinator's xhigh (template effortLevel and modelSettings) and max for agents and workflow children.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Model currency record: 2026-09-28 addendum (Sonnet 5.5 launch, alias measured, fallback map)

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

* Model currency record: repair round for the 2026-09-28 cross-family review (guard scope, Vals fallback counts, alias observation scope, lifecycle scope, advisor test)

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

* Model currency record: apply the re-check findings (workflow-stage observation dropped, project-file reach, Vals page dates)

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

* Hot files: evidence registration for the model-currency branch

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

---------

Co-authored-by: Scout <scout@local>
Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>

…ks --required; move merge-guard mechanics to the decision record

The round-one verifier showed the documented statusCheckRollup filter prints superseded runs, so 'none failed' could not be judged with it (merged #389, #411 and #413 each show an earlier sota-sources failure and a later success on the final head). gh pr checks --required lists only the required checks with the latest run of each; measured exit 0 (all passed), 1 (one failed, none pending) and 8 (pending). The implementation-level citations move to the decision record, the stale-approval comparison is called an analogy, and 'today' leaves the dated record.

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

…uire sota-sources (#430)

* docs/lanes.md: merge with the reviewed head pinned (--match-head-commit)

Strict up-to-date checks stay off and this User-owned repository cannot use
a merge queue (docs/decisions/2026-09-22-github-automation-closure.md), so
`gh pr merge <N> --squash --match-head-commit <SHA>` is the guard against
merging a head nobody reviewed (https://cli.github.com/manual/gh_pr_merge).
It was practised but not written down: grep for match-head-commit across
docs, recipes, adoption, examples and AGENTS.md returned nothing.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Decision record: close the sota-sources ruleset drift with dated GETs

The live ruleset 23739774 now requires the committed eight checks. Before-GET
21:00:04Z (seven, no sota-sources); PUT of .github/main-ruleset.json at main
e82e6be at 21:00:13Z; after-GET matches the committed file. Records the open
PRs affected at PUT time and the rollback.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* docs/lanes.md merge guard: pin the checked and reviewed head read just before merge (B1, B2)

B1: <SHA> is the full 40-character headRefOid read with gh pr view <N> --json headRefOid,statusCheckRollup immediately before the merge, on which the review completed and every required check ran with none running or failed. The hot-file protocol's rebase or merge of main comes before that read; if main changed a shared hot file after <SHA>, merge main again, wait for the checks on the new head and pin it; the review carries over only if the reviewed files are byte-identical (GitHub's stale-approval rule, available-rules-for-rulesets). Sources: gh 2.101.0 'gh pr merge --help'; cli/cli v2.101.0 pkg/cmd/pr/merge/http.go L77-80 (expectedHeadOid); GraphQL MergePullRequestInput.expectedHeadOid read by schema introspection and in github/docs src/graphql/data/fpt/schema-pulls.json.

B2: the flag guards the head, not the base: with strict up-to-date checks off and no merge queue, two PRs green against an older main can still break it together (GitHub docs, loose required status checks).

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

* Drift closed entry: measured live-ruleset comparison, historical labels, executable rollback (B3, B4, B5)

B4: the before-GET, PUT, after-GET and PR-status claims are labelled historical, recorded by the PR author, output not retained. Measured today (2026-09-29T03:18:04Z, read-only): the recorded diff of the live ruleset 23739774 against origin/main (b0fb65b, GitHub's main tip then) exited 0 after stripping eight response-metadata keys and sorting rules by type; the rules order is the only other difference; the 57fb6d8 negative control exits 1 on the sota-sources context only; updated_at is still the recorded PUT second. packet.md L90-92 cited as historical corroboration.

B3: rollback is git show 57fb6d8:.github/main-ruleset.json | gh api --method PUT .../rulesets/23739774 --input - (not run); verified 57fb6d8's file equals 7bbb021's minus sota-sources (jq -S, cmp exit 0) and main still carries 7bbb021's file.

B5: a rebase is not the only way to get a sota-sources run (validate.yml L6-9 reopened/edited; docs/lanes.md merge path), GitHub starts no pull_request run while a PR conflicts, and reporting is not passing (the job reads only the description, L517-521); #205/#216 measured CONFLICTING with no sota-sources run.

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

* Hot-file step: re-register docs/lanes.md and the automation-closure record in manifests/evidence.json

Registered with host_receipts.register_file; component_matrix.py --write and new_host_grand_list.py --write left the four generated reports unchanged; scripts/validate.py passed.

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

* docs/lanes.md: read the pinned head's required checks with gh pr checks --required; move merge-guard mechanics to the decision record

The round-one verifier showed the documented statusCheckRollup filter prints superseded runs, so 'none failed' could not be judged with it (merged #389, #411 and #413 each show an earlier sota-sources failure and a later success on the final head). gh pr checks --required lists only the required checks with the latest run of each; measured exit 0 (all passed), 1 (one failed, none pending) and 8 (pending). The implementation-level citations move to the decision record, the stale-approval comparison is called an analogy, and 'today' leaves the dated record.

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

---------

Co-authored-by: Scout <scout@local>
Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>