fix: drop the no-op apply action from the five check-only setups

.gitleaksignore

@@ -0,0 +1,10 @@
+# Gitleaks false-positive fingerprints (commit:file:rule:line).
+#
+# CLAUDE_TOKEN in resolve-convention-home.sh is the parser sense of "token"
+# (the pointer line lifted from a convention-home region), never a credential;
+# the generic-api-key rule keys on the identifier and reads the next line
+# (CLAUDE_SHIM=0) as the value. The current file carries a gitleaks:allow
+# annotation; these entries cover the pre-annotation commits, which the CI
+# scan reaches because it runs with --log-opts=--all over every fetched ref.
+f7aec1549dec60407a24a7d8ea720696b7b099af:plugins/claude-config/lib/resolve-convention-home.sh:generic-api-key:248
+708739fb2ba1b0196e93f9c07d3293bddfeed2f0:plugins/plugin-quality/lib/resolve-convention-home.sh:generic-api-key:249

plugins/claude-ops/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "claude-ops",
-  "version": "0.38.3",
+  "version": "0.38.4",
   "description": "Claude Code operations toolkit. Twelve skills: audit-skill-visibility (audit whether each installed skill is actually VISIBLE to the model, and diagnose why most of a fleet never gets used — a skill is invisible when its description is dropped by Claude Code's skill-listing context budget, which drops descriptions least-invoked-first so an unused skill loses the keywords that would let it be matched, from skills genuinely not wanted, from skills the run cannot observe at all; computes whether the listing overflows from documented settings, and withholds every cold verdict the data cannot support rather than reporting absence of data as absence of use), inventory (read-only enumeration of the complete invocable surface — every built-in CLI command with aliases and hidden/gated status, every bundled skill, and every component of every installed plugin across all marketplaces; reads the shipped binary because upstream publishes no built-in command list, and carries an integrity verdict so a drifted build reports counts as floors rather than silently short totals), audit-install-state (read-only audit of the machine-scope ~/.claude installation directory and ~/.claude.json — full inventory split into an authored surface and rolled-up bulk trees, product-managed retention vs genuinely unmanaged state, filename-scheme resolution before any process-liveness check, and deliberate/mid-experiment detection; reports, never deletes), audit-performance (read-only slowness-diagnostic capture run at the moment the machine or a session feels slow: CLI version, retention-sweep health including the silent unparsable-settings pause, a timed census walk of the install tree as a sweep-cost proxy, active-session and plugin-fleet counts, a process census, and the fan-out layer, which covers a load-labelled no-op spawn baseline, every hook that will fire bucketed per-tool-call versus per-turn with its invocation shape, the configured statusline, subagent concurrency and spawn-depth ceilings against documented defaults, whether running sessions predate the settings file they are judged by, and orphan attribution by parent liveness rather than age; read against a bundled known-performance-issues reference that also records the causes tested and cleared; separates the four documented suspects of accumulated state, version regression, component bloat, and per-spawn fan-out cost, and routes remediation out; reports, never mutates, and never executes a discovered hook or statusline command), audit-native-overlap (map native Claude Code surfaces — built-in CLI commands, bundled skills, plugin-backed built-ins, session-provided skills — against the current repo's plugin skills and agents, so a custom component never silently duplicates what Claude Code itself ships; bare invocation is a read-only overlap report carrying the extraction's integrity floors and a shared-listing-budget exposure section, verdicts are human-gated in a committed store rendered into a generated registry whose every row carries an observable recheck trigger, and only an explicit apply step bakes presence-gated native references into descriptions and Boundary sections), observability (read locally captured telemetry — OTEL store, collector, hook-event JSONL, ccusage — with trend reports and store pruning), known-issues (search known Claude product GitHub bugs, check service health, maintain a persistent tracked-issue registry), changelog (ingest Claude Code changelog entries and integrate them into the current repo), plugins (bring a machine's plugin fleet current on demand — marketplace refresh, effective-scope updates including in-repo project/local installs, new-plugin install per policy, scope-divergence detection and explicit convergence), morning-brief (read-only gh-based operator morning view — queue-label counts, merge-ready PRs, parked decisions with their RECOMMENDED lines, and loop-lane telemetry freshness), lanes (start/restart/stop/status loop lanes as named background Claude Code sessions seeded from canonical prompt files, with per-lane model/effort, a repo-pull + marketplace-refresh launch step, and a consume-restarts action — an OS-schedulable reader that relaunches stopped lanes whose telemetry carries a restart_request), and a re-runnable setup action that settles where the known-issues registry lives. Plus a family of eight advisory *-audit hooks (API errors, config changes, instruction loads, permission denials, pre-compaction, skill usage, tool failures, and unsurfaced hook failures — the last also warns the user via systemMessage, since a hook that fails to launch enforces nothing and Claude Code surfaces the failure to nobody) that emit the shared hook-telemetry envelope, and a reference sink that maps envelopes into the hook-events.jsonl the observability skill reads.",
   "author": {
     "name": "Melodic Software",

plugins/claude-ops/CHANGELOG.md

@@ -3,6 +3,12 @@
 All notable changes to the `claude-ops` plugin are documented here. Format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning.
 
+## [0.38.4]
+
+### Changed
+
+- `setup` is check-only: the no-op `apply` action is dropped per PLUGIN-PHILOSOPHY's Check-only carve-out, and its reconfiguration guidance is now printed by `check` (#3583, customization-consistency Phase 1b).
+
 ## [0.38.3]
 
 ### Changed

plugins/claude-ops/README.md

@@ -33,7 +33,7 @@ Claude Code's native OTEL cannot see.
 | `/claude-ops:plugins` | Brings a machine's plugin fleet current on demand: marketplace refresh, updates for the plugins that actually load (including in-repo project/local-scope installs), new-catalog-plugin install per policy, and scope-divergence detection. Actions: `sync` (default, CLI-mediated mutations only), `audit` (read-only dry run), `converge` (the one action that can touch a committed `.claude/settings.json`. Previews and confirms per plugin first). |
 | `/claude-ops:morning-brief` | Prints the read-only, `gh`-based operator morning view for the current repo in one pass: open counts per queue label (`priority: needs-triage`, `status: ready`, `status: needs-decision`, `needs-human`), the gh-native merge-ready PR list (non-draft + `mergeStateStatus=CLEAN`), parked `status: needs-decision` issues with their RECOMMENDED lines, and loop-lane telemetry freshness (per-lane `last-cycle` age + `flags:`). Never mutates anything; the authoritative PR merge gate stays `/source-control:babysit-prs`. |
 | `/claude-ops:lanes` | Starts, restarts, stops, and reports loop lanes as named background Claude Code sessions seeded from canonical prompt files. `start` (default) / `restart` pull the repo and refresh the plugin marketplace, then launch each configured lane (`claude --bg -n <lane>`) with its per-lane `model`/`effort`; `status` shows per-lane running state and live sessionId; `stop` ends a lane via `claude stop`; `consume-restarts` is the OS-schedulable restart-request consumer. It reads each configured lane's telemetry `restart_request` and relaunches the stopped lanes that asked, through the same launcher (#1653). Acts only on sessions whose name is a configured lane. Lanes come from a JSON config (`--config`, else `$CLAUDE_OPS_LANES_CONFIG`, else `<repo>/.work/lanes.json`); prompt storage is session-local `.work` today and composes with #480 for a durable home. |
-| `/claude-ops:setup` | `check` (default) reports the effective known-issues-registry and skill-usage-log destinations, their defaults, and path containment; `apply` routes personal option changes through Claude Code's plugin configuration prompt. |
+| `/claude-ops:setup` | Check-only: reports the effective known-issues-registry and skill-usage-log destinations, their defaults, and path containment, and prints the guidance for routing personal option changes through Claude Code's plugin configuration prompt. |
 
 ## The audit hooks
 

plugins/claude-ops/skills/setup/SKILL.md

@@ -1,25 +1,25 @@
 ---
-description: "Verify claude-ops's personal path configuration for this repository, where the known-issues registry and the skill-usage log resolve, and explain how to change them through Claude Code. Use when: 'set up claude-ops', 'configure claude-ops', 'claude-ops setup', 'where does the known-issues registry live', or 'where is skill usage logged'. Actions: check (read-only verification, default) | apply (route a reconfiguration once you've chosen a destination). Re-runnable and safe."
-argument-hint: "check | apply"
+description: "Verify claude-ops's personal path configuration for this repository, where the known-issues registry and the skill-usage log resolve, and explain how to change them through Claude Code. Use when: 'set up claude-ops', 'configure claude-ops', 'claude-ops setup', 'where does the known-issues registry live', or 'where is skill usage logged'. Check-only: verifies, reports, and prints reconfiguration guidance; there is nothing setup may write here. Re-runnable and safe."
+argument-hint: "check"
 user-invocable: true
 disable-model-invocation: true
 ---
 
 ## Purpose
 
-Thin check-centric setup per the uniform setup contract (`docs/PLUGIN-PHILOSOPHY.md`
-"Setup is explicit and repeatable" in the marketplace repository): `check` inspects and reports the
-effective personal path options, `apply` resolves what it found. `registry_dir` and `skill_usage_dir`
-are personal `userConfig` scalars owned by Claude Code's native configuration surface. Claude Code
-prompts for them when the plugin is enabled, stores non-sensitive options in user settings, and ignores
-`pluginConfigs` entries in project and local settings on current releases (≥ 2.1.207). This skill never
-writes them; `apply` verifies and routes.
+Check-only setup under the Check-only carve-out (`docs/PLUGIN-PHILOSOPHY.md` "Setup is explicit
+and repeatable" in the marketplace repository): this plugin's configuration surface contains no
+writable artifact, so `check` verifies, reports, and prints the reconfiguration guidance below,
+and no `apply` is offered because there is nothing it could conformingly write. `registry_dir` and
+`skill_usage_dir` are personal `userConfig` scalars owned by Claude Code's native configuration
+surface. Claude Code prompts for them when the plugin is enabled, stores non-sensitive options in
+user settings, and ignores `pluginConfigs` entries in project and local settings on current
+releases (≥ 2.1.207). This skill never writes them.
 
 Official contract (verified 2026-07-18):
 <https://code.claude.com/docs/en/plugins-reference#user-configuration>.
 
-Action routing: no argument or `check` runs the check; `apply` runs the check first, then the
-reconfiguration guidance below. Both are non-interactive, never prompt when the action is given.
+Action routing: no argument or `check` runs the check. Non-interactive, never prompts.
 
 ## `check` (read-only)
 
@@ -51,13 +51,14 @@ table, one remediation line per FAIL. Do not modify anything.
    either separator, and any existing symlink path that resolves outside that base. Do not normalize
    an invalid value into acceptance, and do not run any operation that would use an invalid destination.
 4. **Personal-vs-project**. INFO: both options are personal, user-scoped preferences, not tracked team
-   policy. Note the per-machine-vs-repository-resident tradeoff so the reader can choose in `apply`.
+   policy. Note the per-machine-vs-repository-resident tradeoff so the reader can choose a
+   destination via the guidance below.
 
-## `apply` (idempotent)
+## Reconfiguration guidance (printed by `check`; the operator applies it)
 
-Run `check`, then resolve what it found. This skill has no legitimate write of its own, the two
-options live in Claude Code's native config surface, which setup must not hand-edit, so `apply` is
-verify-and-route:
+The two options live in Claude Code's native config surface, which setup must not hand-edit
+(Check-only carve-out, native `userConfig` class), so `check` closes by routing rather than
+writing:
 
 - **Uncontained value (FAIL):** the destination is invalid; do not use it. Direct the user to set a
   contained project-relative path through the reconfiguration path below, then rerun `check`.
@@ -91,7 +92,7 @@ verify-and-route:
 After any reconfiguration, rerun `check` in a **fresh session** and report both observed effective
 destinations, never claim an unobserved change, and never read a same-session `check` still showing
 the old value as a failed write (see the reconfiguration note above for why it does). Re-running
-`apply` when both destinations are contained (or defaulted) changes nothing and reports
+`check` when both destinations are contained (or defaulted) changes nothing and reports
 "already configured".
 
 ## What this skill does NOT do

plugins/claude-ops/skills/setup/evals/evals.json

@@ -17,7 +17,7 @@
     {
       "id": 2,
       "name": "routes-reconfiguration-through-claude",
-      "prompt": "/claude-ops:setup apply\n\nKeep the known-issues registry in this repository.",
+      "prompt": "/claude-ops:setup\n\nKeep the known-issues registry in this repository.",
       "expected_output": "Recommends a portable project-relative path from repository evidence, directs the user to Claude Code's plugin configuration prompt, and verifies the rendered value on rerun before claiming success.",
       "files": [],
       "expectations": [

plugins/context-budget/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "context-budget",
-  "version": "0.6.10",
+  "version": "0.6.11",
   "description": "Measure a Claude Code session's fixed startup context payload per item, on the consumer's machine at a pinned, version-stamped binary — including per-tool attribution of the built-in tool pools that /context reports only as lump sums, derived live by A/B bare-name-deny differencing with enforced comparability rules (skill-listing signature, one mode, one binary), an SDK-primary exact meter degrading to a version-aware headless /context parser and then to an honest structured error (never a wrong number), and a per-project measure-toggle-remeasure ledger under the plugin data directory recording every lever's real before/after delta. Report-only: prints exact config, applies nothing.",
   "author": {
     "name": "Melodic Software",

plugins/context-budget/CHANGELOG.md

@@ -5,6 +5,12 @@ All notable changes to the `context-budget` plugin.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project
 adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.6.11]
+
+### Changed
+
+- `setup` is check-only: the no-op `apply` action is dropped per PLUGIN-PHILOSOPHY's Check-only carve-out, and its reconfiguration guidance is now printed by `check` (#3583, customization-consistency Phase 1b).
+
 ## [0.6.10]
 
 ### Changed