chore: cut this repo's enabledPlugins to deltas against the new defaults

[kyle-sexton]

No related issue: follow-up to #5897 and #5934, so this repo's own enabledPlugins holds only deltas against the new catalog defaults.

Summary

.claude/settings.json is project scope. Each key in its enabledPlugins block pins that plugin's state, and in every local checkout it writes a project-scope install record. After #5897, a true for a plugin that is on by default changes nothing in the cloud. Locally it writes that record and forces the plugin on in this checkout whatever the user's own scope says. Dropping it leaves the plugin's local state to the user's own scope, the same as every other on-by-default plugin, none of which carries a key here. A true for a plugin that is off by default enables it in every session in this repo, and in cloud sessions too.

Fix

.claude/settings.json enabledPlugins:

• Kept unchanged: every false (animation, dometrain-mcp, gaming, pixel-art, playgrounds, retro-audio). No other marketplace has entries here.
• Dropped true for multi-agent, which is on by default, and for fleet and harness-memory, which are off by default and not needed to work in this repo.
• Kept or added true only for off-by-default plugins this repo's workflow uses:
  • ai-slop: the PR prep markdown audit (/ai-slop:audit). The repo keeps its config in .claude/ai-slop.json.
  • docs-naming: the remediation for CI's lower-kebab docs/ filename gate (ADR 0034).
  • evals: authoring and validating the evals/ suites that skills ship (/evals:design, which .claude/rules/eval-case-transcripts.md names).
  • harness-config: /harness-config:audit, whose kept findings live in .claude/audit-pass.md.
  • harness-ops: lane operation and telemetry that docs/conventions/loop-lane routes to (/harness-ops:lanes, /harness-ops:morning-brief).
  • instruction-placement: the PR prep rules audit, and the generated rules index in AGENTS.md.
  • plugin-quality: behavioral audits of the plugins this repo publishes.
  • skill-quality: the PR prep skills gate (/skill-quality:check).

docs/cloud-fleet-setup.md: three places still said the fleet list was the standards repository's fleet-plugins.json, which standards#663 deleted. They now say the list is derived from this repo's catalog (every entry whose defaultEnabled is absent or true), which matches setup.sh in standards. docs/cloud-sessions.md was already correct.

Verification

• scripts/check-plugin-catalog-enablement.sh: every key names a catalogued plugin, none orphaned, keys sorted. Its test reports PASS=13 FAIL=0.
• scripts/check-hook-wiring-liveness.sh: pass. jq empty .claude/settings.json: valid.
• markdownlint-cli2 docs/cloud-fleet-setup.md: 0 issues.
• No other doc in the tree still names fleet-plugins.json.

Related

• chore: install 44 non-core plugins disabled by default #5897 (catalog defaults), fix(ci): check enabledPlugins deltas against the catalog, not a deleted fleet list #5936 (the gate now checks deltas, not coverage), chore: sweep cross-plugin 'when installed' gates to 'when enabled' in default-enabled callers #5934 / fix: gate cross-plugin routing on enabled, not installed #5985 (the gate wording sweep).

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-03T04:23:55.401735Z	0ba2bb1	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[claude]

Claude finished @kyle-sexton's task in 1m 45s —— View job

---

Security review complete

• Gather context (PR diff, changed files)
• Check skip gate
• Review .claude/settings.json changes
• Review docs/cloud-fleet-setup.md changes
• Check for instruction-surface deletions against protected-class register
• Post final findings

Scope: .claude/settings.json (enabledPlugins block) and docs/cloud-fleet-setup.md, diffed against origin/main at 0ba2bb1.

Analysis:

• .claude/settings.json: verified against .claude-plugin/marketplace.json's defaultEnabled values. fleet and harness-memory both have defaultEnabled: false, so dropping their explicit true disables them (capability decrease, matches the stated intent of not needing them here). multi-agent has defaultEnabled: null (treated as on-by-default), so dropping its explicit true is a no-op pin removal, not a disablement. The five newly-added true entries (ai-slop, evals, instruction-placement, plugin-quality, skill-quality) all have defaultEnabled: false in the catalog and are first-party plugins in this same repo's marketplace — this is a scoped, intentional capability grant for this repo's own workflow, not a third-party or supply-chain addition. No injection, authz, or secret-handling surface in a settings toggle like this.
• docs/cloud-fleet-setup.md: prose-only correction reflecting that the fleet list is now derived from this repo's own catalog rather than the standards repo's (deleted) fleet-plugins.json. This updates documentation to match an already-changed upstream mechanism; it doesn't remove or weaken any enforcement.
• Instruction-surface lens: checked the diff against the instruction exception register's Gate 0 classes (irreversible-action, secret-handling, data-integrity, external-publication, legal-compliance, agent-authority). Nothing in this diff deletes, narrows, or softens a standing instruction — it's a JSON config toggle and a matching doc update, not a rule removal. No match.

Findings: none. This PR has no security-relevant logic, trust-boundary, or injection surface — it's a plugin-enablement config change plus a documentation correction, and the enablement delta checks out against the catalog's own defaultEnabled values.

[claude]

Claude finished @kyle-sexton's task in 10m 4s —— View job

---

Code review (/review:code-review)

• Gather context (PR body, diff via gh pr diff, catalog, gate script, related docs)
• Understand the request: CI code-review lane for PR chore: cut this repo's enabledPlugins to deltas against the new defaults #5987
• Review .claude/settings.json and docs/cloud-fleet-setup.md for correctness
• Verify catalog/sort/orphan claims against scripts/check-plugin-catalog-enablement.sh's actual rules
• Adversarially verify the one candidate finding with an independent subagent pass
• Post findings

Scope: reviewed the two changed files (.claude/settings.json, docs/cloud-fleet-setup.md) against this repo's own conventions and docs, per the code-review lane's criteria. No security-lane findings scoped out here since none were found in this diff.

Finding (posted inline on .claude/settings.json line 42, confirmed): dropping "multi-agent@melodic-software": true is characterized as a no-op cleanup ("on by default anyway"), but it isn't. docs/cloud-sessions.md (unmodified by this PR) already documents that a project-scope key matching the catalog default is kept specifically because it "is there for that local effect," and this repo's own harness-ops verification record shows Claude Code only loads a plugin when some enabledPlugins scope explicitly sets it true — an absent key does not fall back to the catalog's defaultEnabled. Only the cloud fleet bootstrap honors that convention (writing an explicit true at user scope); a plain local session in this checkout has no equivalent, since .claude/cloud-bootstrap.sh no-ops outside CLAUDE_CODE_REMOTE. multi-agent is also actively used by this repo's own session-flow, review, testing, and planning plugins, so this is a real regression for local, non-cloud sessions here, not a harmless record removal. Unlike fleet/harness-memory, whose drop the PR correctly frames as a deliberate disablement, multi-agent should likely stay explicit true.

Checked and found consistent (no findings):

• Every new/kept enabledPlugins key names a catalogued plugin in .claude-plugin/marketplace.json (no orphans) and the keys are in byte order, matching scripts/check-plugin-catalog-enablement.sh's two structural checks (verified by reading the catalog and script directly, not by re-running the author's cited PASS=13 FAIL=0, which is author-claimed and unverified by me).
• The kept false entries (animation, dometrain-mcp, gaming, pixel-art, playgrounds, retro-audio) are not redundant in the same way — docs/cloud-sessions.md's "pins state for local sessions" rationale applies symmetrically to them, so leaving them explicit is correct, not an inconsistency with the multi-agent/fleet/harness-memory drops.
• docs/cloud-fleet-setup.md's three edits away from the deleted standards fleet-plugins.json toward "derived from this repository's catalog" match docs/cloud-sessions.md's existing (unmodified) description of the same mechanism — no drift introduced.
• Remaining fleet-plugins.json mentions in the tree (docs/cloud-fleet-setup.md:159,220, docs/cloud-sessions.md:185,383, .claude/cloud-bootstrap.sh:166) are all the generated runtime artifact path (/opt/melodic-fleet-plugins.json), not the deleted standards-repo file this PR is about — consistent with the PR's "no other doc" claim.

[claude]

Claude finished @kyle-sexton's task in 1m 12s —— View job

---

Security review (/review:security-review)

• Load skill instructions
• Gather context (diff vs origin/main, confirm head SHA 3911985)
• Check skip gate
• Review .claude/settings.json changes
• Review docs/cloud-fleet-setup.md changes
• Check for instruction-surface deletions against protected-class register
• Post final findings

Scope: .claude/settings.json (enabledPlugins block) and docs/cloud-fleet-setup.md, diffed against origin/main at head 3911985.

Context: this head already carries a completed security review (posted against commit 0ba2bb1, findings: none). I diffed 0ba2bb1 → HEAD on the two reviewed files to find what changed since: docs/cloud-fleet-setup.md is byte-identical to the version already reviewed. .claude/settings.json gained one line, "speech@melodic-software": false, picked up from merging origin/main (the speech plugin is new to the catalog).

Analysis of the delta:

• .claude-plugin/marketplace.json lists speech with "defaultEnabled": false. The added key pins it to false, matching the catalog default — a disablement pin in the same pattern as the already-reviewed animation, gaming, pixel-art, playgrounds, retro-audio entries, not a new capability grant. No injection, authz, secret-handling, or trust-boundary surface in a false toggle.
• Everything else in the diff (the ai-slop/evals/instruction-placement/plugin-quality/skill-quality grants, the fleet/harness-memory/multi-agent drops, and the docs/cloud-fleet-setup.md prose correction) is unchanged from the version already reviewed with no findings.

Instruction-surface lens: enabledPlugins is a feature-enablement toggle, not one of the protected instruction surfaces (CLAUDE.md, AGENTS.md, a rules file, a skill/agent body, a hook's block list or allowlist) named in the instruction exception register. None of the dropped keys removes or weakens a standing rule; they change which plugins load, which is the PR's stated, reviewed intent.

Findings: none. No new security-relevant surface since the prior clean review on this PR.

[claude]

Claude finished @kyle-sexton's task in 1m 48s —— View job

---

Code review (/review:code-review)

• Gather context (PR body, diff via git diff origin/main...HEAD, prior review threads)
• Check skip gate
• Verify whether anything changed since the last code-review lane pass on this head
• Independently check the open multi-agent dispute against repo docs
• Post findings

Skip gate hit: nothing new to review. The only commits added since the prior code-review lane pass (at 0ba2bb1) are two merges of origin/main into this branch (0ba2bb1 → 3911985). Diffing 0ba2bb1..3911985 on the two changed files shows a single line, "speech@melodic-software": false, and it was already present on origin/main before this PR's own diff — the merge just carried it through; the PR's actual content (.claude/settings.json enabledPlugins, docs/cloud-fleet-setup.md) is byte-identical to what the lane already reviewed. Per the skip gate's 4th condition ("this head already has a successful review from this lane that still applies"), nothing further is posted for the diff itself.

On the open multi-agent thread: I independently checked the dispute between the earlier code-review finding (re-add "multi-agent@melodic-software": true) and the author's rebuttal, against docs/cloud-sessions.md (unmodified by this PR) and plugins/harness-ops/skills/plugins/context/sync-install-enable.md, rather than taking either side's claim at face value:

• docs/cloud-sessions.md L379–397 states the current block (post-plugins: project-scope pins accumulate per worktree (15 paths x ~60 plugins, 3 paths gone, 412 cached versions) #3688) intentionally writes no project-scope entry for an on-by-default plugin — that's the existing, already-shipped convention, not something this PR introduces. The current .claude/settings.json on this head already has no key for review, session-flow, testing, or planning either, all on-by-default and all plugins this very CI session is using successfully (this review itself runs through the review plugin's code-review skill).
• sync-install-enable.md L151–156 — the line the earlier finding cited for "an absent key doesn't load" — is scoped to ids with no enabledPlugins entry in any scope at all (missing a user-scope entry too). It doesn't support the claim that a project-scope entry is the only way to load an on-by-default plugin locally; the same doc's surrounding steps are themselves about writing the missing user-scope entry during marketplace sync, which is exactly the mechanism the author's rebuttal points to.

So the author's rebuttal holds up under independent check: dropping multi-agent's project-scope true matches the already-established pattern for every other on-by-default plugin in this repo, not a regression unique to multi-agent. No action needed there.

Findings: none (no new review surface on this head; the one open thread resolves in the author's favor on independent verification).