Merge remote-tracking branch 'origin/main' into claude/architecture-improvements-hqfc0i

Two changelogs and their manifests conflicted again: main minor-bumped
claude-config to 0.42.0 and claude-ops to 0.48.0, past the patch numbers this
branch had taken in the previous merge. Main's entries keep the numbers they
released under and this branch's entries move to 0.42.1 and 0.48.1, above them
in the newest-first order, with each manifest bumped to match.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011SQkHipoF2M8rTtnkbFKKP

Author: claude

docs/NATIVE-SURFACES.md

@@ -1090,9 +1090,21 @@ name is not the same underlying value across models):
   preference, not a task-by-task decision
   ([choosing a model and effort level](https://claude.com/blog/claude-model-and-effort-level-in-claude-code)).
 - **No lane pins `max` without eval evidence** — upstream warns it adds significant cost for
-  relatively small quality gains and can lead to overthinking. A pin above `high` (e.g. `xhigh`)
+  relatively small quality gains and can lead to overthinking. Deliberation helps only while
+  there is still evidence to find; past that point extra effort buys cost and latency and can
+  degrade the answer ([cut spend without losing quality](https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence#cut-spend-without-losing-quality),
+  verified 2026-09-09). A pin above `high` (e.g. `xhigh`)
   is a deliberate per-lane choice grounded in the target model's own recommended-levels guidance,
-  never a reflex.
+  never a reflex. The miscalibration cuts the other way too: a lane set too low stops before it
+  has enough evidence, makes fewer tool calls, and skips the checks it would run unprompted, so
+  the answer looks finished while resting on partial information (same page, same verification).
+- **Sweep model and effort together before raising either.** A stronger model at low effort can
+  beat a weaker or older model at high effort on both cost and quality, so a lane outgrowing its
+  level tests the newer model at lower effort before pinning the old one higher, on its own
+  evals. Cross-model economics and the flat-curve reading live in the fable-5 pack's
+  model-adaptation chapter for the newer model
+  (`plugins/playbooks/reference/model-adaptation/fable-5-1.md`, "Cross-model effort economics");
+  current prices resolve through the `claude-api` skill at decision time.
 - **Effort is the first lever in either direction; steering prose is the second.** Upstream states
   the order plainly — set the effort level matching the lane's workload, then "add prompt guidance
   only if Claude's triggering still doesn't match your needs at that level" — and gives the

docs/PLUGIN-PHILOSOPHY.md

@@ -6,6 +6,33 @@ major change; additive guidance is minor; clarification is a patch. The doc ship
 unnumbered, which this file reads as **1.0**; the entry below is the first recorded change and lands
 the changelog the README said would arrive with it.
 
+## 1.1.0 — 2026-09-11
+
+Additive: no required part of the description phrase moves and the canonical gate token is
+unchanged. One enforceability row is added, and the meaning of a store row with no baked line is
+split by surface.
+
+- **The Boundary section lands with the store row.** A non-`defer`, extraction-evidence row is
+  written together with its `## Boundary` section in the component body, in the same change. The
+  section is invocation-loaded, so it spends no listing budget and moves no routing; nothing the
+  description-phrase gate protects against applies to it. Routing and mutation gate go in the body;
+  the four-part records go in a reference file inside the same skill, linked from the section.
+- **"Pending-sweep" is now phrase-only.** A row without a description phrase remains legal pending
+  state. A row without its Boundary section is a problem the overlap self-check fails on (exit 1),
+  so no row can be added silently unbaked. The new enforceability row is Deterministic and
+  blocking: the tiers doc gives that tier no advisory grade, and the consumer gate's exit-3 pass
+  is reserved for conditions this repository cannot fix by editing its own files.
+- **The section must name the row's surface.** `baked.boundary_section` plus a bare `## Boundary`
+  heading is not parity: a component may carry a section written for a surface with no row, and a
+  component that overlaps several surfaces carries one section owing each of them a mention. The
+  heading naming the surface is the preferred shape; a generic heading passes when the section
+  text names the surface. Either way the name appears as a code span, so a native name that is
+  also an ordinary English word is not satisfied by prose that happens to use the word.
+- **Boundary-only baking may batch across plugins.** The one-plugin-per-unit sweep rule keeps its
+  reason (routing and budget) and therefore keeps its scope: description phrases.
+- Adopters table gains `/claude-config:audit-instructions`, `/evals:methodology`, and
+  `/playbooks:fable-5`, each carrying a Boundary section for the bundled `claude-api` skill.
+
 ## 1.0.1 — 2026-08-28
 
 Clarification patch: no required part of the description phrase moves, the canonical gate token is

docs/conventions/native-references/CHANGELOG.md

@@ -122,34 +122,53 @@ the source level.
 
 ## The Boundary section
 
-Where a description clause is too small for the real distinction, the component's **body** carries a
-fuller section, modeled on the `review` plugin's organic pattern
-(`/review:quality-gate` and `/review:fanout` each carry one):
+The Boundary section is the surface a verdict lands on. **A store row whose verdict is not `defer`
+and whose observation is extraction-evidence lands together with its `## Boundary` section in the
+component's body, in the same change.** A verdict that lives only in the store changes nothing the
+model reads: the registry is a maintainer surface and shipped plugins never carry it, so until the
+body says how the two surfaces relate, the overlap the row records is still silent at runtime.
+The section costs nothing the description phrase costs. Bodies load only on invocation, so a
+Boundary section spends no shared listing budget and changes no routing; the gate the phrase
+earns (below) has no reason to hold the section back.
+
+The section carries the conclusion: the surfaces by provenance class, the routing split, and the
+mutation gate. The four-part records behind it (the basis each upstream specific rests on, its
+as-of date, its recheck trigger, the extraction or docs evidence) live in a **reference file inside
+the same skill**, linked from the section with a same-plugin relative path, so the body stays short
+and the detail stays reachable. Modeled on the `review` plugin's organic pattern (`/review:quality-gate`
+and `/review:fanout` each carry one):
 
 ```markdown
-## Boundary — <the native surfaces this skill overlaps>
+## Boundary, the bundled `<name>` skill
 
 <One sentence naming the surfaces and why they are conflated.>
 
-- **<name> (<provenance class>)** — what it does, what it mutates, how it is invoked.
-- **<name> (<provenance class>)** — same.
+- **`<name>` (<provenance class>)** — what it does, what it mutates, how it is invoked.
+- **`<name>` (<provenance class>)** — same.
 
 **Routing:** <when to prefer each>.
 
 **Mutation gate:** <which invocations mutate, and the explicit opt-in they require>.
 ```
 
-Five properties the section keeps:
-
-1. **Surfaces named by provenance class**, exactly as in the description phrase.
-2. **A mutation gate per surface that mutates.** Naming an overlap without naming what it writes
+Six properties the section keeps:
+
+1. **Every overlapped surface named in the section, as a code span.** `## Boundary` on its own is
+   a heading any prose satisfies, and several components carry one for a surface this convention
+   has no verdict on. The heading naming the surface is the preferred shape and is what the
+   template above shows; a generic `## Boundary` heading is still accepted when the section text
+   names the surface, which is how one section covers a component that overlaps several. Either
+   way the name is a code span, so a surface whose name is also an ordinary English word (`run`,
+   `design`) is never satisfied by a sentence that happens to use the word.
+2. **Surfaces named by provenance class**, exactly as in the description phrase.
+3. **A mutation gate per surface that mutates.** Naming an overlap without naming what it writes
    invites an unrequested mutation.
-3. **One owning description, pointers elsewhere.** Where two components in the *same plugin* both
+4. **One owning description, pointers elsewhere.** Where two components in the *same plugin* both
    overlap the surface, one carries the description and the other points at it with a same-plugin
    relative link and adds only what is specific to itself. Cross-plugin pointers are forbidden.
-4. **Presence-gated language throughout** — the body inherits the description's gate; it never
+5. **Presence-gated language throughout** — the body inherits the description's gate; it never
    promotes a surface to available because the body is longer.
-5. **Upstream specifics carry their basis and date**, per
+6. **Upstream specifics carry their basis and date**, per
    [`upstream-drift`](../upstream-drift/README.md).
 
 ## Self-containment — shipped plugins never cite the registry
@@ -160,9 +179,13 @@ broken reference at install time, and the reader would be routed to a file that
 
 So: baked text repeats what it needs and cites nothing outside its own plugin. The registry is a
 maintainer surface — it records the verdict, the evidence, and the trigger that would change them;
-the component carries the conclusion. This is the same direction the parity check enforces
-mechanically: every baked line traces back to a store row, while a store row without a baked line
-is legal pending-sweep state.
+the component carries the conclusion. The parity check enforces the forward direction
+mechanically: every baked line traces back to a store row, and a claimed Boundary section must name
+that row's surface rather than merely carry the heading. In the other direction the two baked
+surfaces differ. A row without its Boundary section is a defect the self-check fails on, because
+the section costs nothing and can always land in the change that adds the row; a row without a
+description phrase is legal pending state, because the phrase is the budget-priced,
+routing-affecting half and earns its separate gate.
 
 ## Enforceability
 
@@ -171,6 +194,7 @@ Classified per `melodic-software/standards` `conventions/engineering/enforceabil
 | Judgment | Tier |
 |---|---|
 | A baked native reference traces to a store row | **Deterministic** — built, as the overlap self-check's store↔baked-line parity pass |
+| Every non-`defer` extraction-evidence row has its Boundary section (`baked.boundary_section` true, and a `## Boundary` section in the component naming that row's surface as a code span) | **Deterministic**: built, in the same self-check, as a blocking problem (exit 1). The tier carries no advisory grade: advisory belongs to detect-then-judge, where a tool narrows a set a human then rules on, and nothing here needs a ruling. A consumer gate passes a degraded run because degraded reports what this repository cannot fix by editing its own files; a missing section is fixable in the change that adds the row |
 | Every store row carries a recheck trigger and a class-tagged observation record | **Deterministic** — built, in the same self-check |
 | The phrase uses the presence gate rather than an availability assertion | **Detect-then-judge** — the `resolves in your session` token is greppable, but deciding whether a *different* sentence asserts availability is a judgment about meaning. Candidate check named, not built: flag a component description naming a bundled or built-in surface with no gate token. Build trigger: a second assertion-shaped native reference reaches `main` after this doc |
 | The routing split is the right one | **Reasoning-only** — it is the verdict, and verdicts are human-gated by design |
@@ -181,9 +205,20 @@ Classified per `melodic-software/standards` `conventions/engineering/enforceabil
 |---|---|
 | `/claude-ops:audit-install-state` | Description phrase + `## Boundary` section for the bundled `doctor` skill (verdict `complementary`) |
 | `/review:quality-gate`, `/review:fanout` | The organic Boundary pattern this doc generalizes; adopts the phrasing rules on next touch |
-
-Fleet-wide application is a reserved, separately gated sweep: one plugin per unit — apply, verify,
-PR, close — never a single fleet-wide edit.
+| `/claude-config:audit-instructions` | `## Boundary` section for the bundled `claude-api` skill's `prompt-audit` subcommand (verdict `complementary`, composite posture), four-part detail in the skill's own reference file; no description phrase |
+| `/evals:methodology` | `## Boundary` section for the bundled `claude-api` skill's `hillclimb` and `build-eval` subcommands (verdict `complementary`); detail in the skill's eval-design reference |
+| `/playbooks:fable-5` | `## Boundary` section for the bundled `claude-api` skill as the live-facts and cost-audit surface its chapters defer to (verdict `complementary`); detail in the pack's prompt-caching reference chapter |
+| `/review:code-review`, `/review:security-review` | `## Boundary` sections for the bundled `code-review` skill and the native `security-review` command (verdict `complementary`, CI lane versus session pass); four-part detail in each skill's `reference/` file; no description phrase |
+| `/code-tidying:tidy`, `/code-tidying:batch-simplify` | `## Boundary` sections for the bundled `simplify` skill (verdict `complementary`, diff-anchored versus lane- and sweep-anchored); detail in each skill's reference or context file; no description phrase |
+| `/testing:run-e2e` | `## Boundary` section for the bundled `run` skill (verdict `complementary`, a look versus evidenced verification); detail in the skill's context file; no description phrase |
+| `/claude-ops:audit-performance`, `/claude-ops:audit-skill-visibility` | `## Boundary` sections for the bundled `doctor` skill (and `/skill-doctor` for the second), verdict `complementary`; the second also carries the description phrase; detail in each skill's `reference/` file |
+| `/visualization:visualize`, `/prototype:explore-directions` | `## Boundary` sections for the bundled `design` skill (verdict `complementary`, user-run canvas versus throwaway page or mockup); detail in the catalog spoke and the skill's `reference/` file; no description phrase |
+
+Applying **description phrases** fleet-wide is a reserved, separately gated sweep: one plugin per
+unit — apply, verify, PR, close — never a single fleet-wide edit, because each phrase moves routing
+and spends shared budget. **Boundary sections** are not routing-affecting and spend no budget, so
+Boundary-only baking may land across several plugins in one change; the unit rule does not apply
+to it.
 
 ## Versioning