discipline rename follow-ups: orphaned pluginConfigs overlays + three stale prose sites

[kyle-sexton]

Observation

Four follow-ups verified against the merged re-anchor → discipline rename (#1276). None blocks anything; the rename itself is clean and all 26 of its CI checks passed. Filed so they are not rediscovered.

Found incidentally while auditing the rename's blast radius for an unrelated program.

1. pluginConfigs overlays are orphaned by the rename — the migration note omits it

Highest value of the four, and it was raised by an automated reviewer on #1276 without a reply.

discipline declares four userConfig keys: batch_exclude, batch_promote, batch_demote, research_deep_verification. Per this repo's own docs (docs/MIGRATION-PLAYBOOK.md:174 and :200, docs/PLUGIN-PHILOSOPHY.md:179) stored options are keyed by the marketplace-qualified plugin ID. The rename changes that ID, so pluginConfigs["re-anchor@melodic-software"].options stops being read, and the renames map in marketplace.json migrates only the enabled/installed record — not the options.

The 0.9.0 migration note covers invocations and the sweep-all-disciplines → sweep-all leaf rename but says nothing about pluginConfigs. Anyone who set an overlay loses it silently.

Direction: add a line to the 0.9.0 note telling configured users to re-enter the four values via /plugin configure discipline.

Not affected on the authoring machine — ~/.claude/settings.json pluginConfigs holds only source-control@melodic-software, no re-anchor or discipline key. So this is a latent consumer-facing gap, not an observed breakage.

2-4. Prose the rename's token sweep missed

Each is a token rewritten correctly with stale prose left beside it on the same line.

• plugins/work-items/reference/pipeline-shape.md:52 — the token became discipline:* but the prose still reads "re-anchor slot" and "re-anchor set". Compare docs/conventions/loop-lane/README.md:181, updated in the same commit.
• plugins/work-items/skills/work-loop/SKILL.md:176 — "presence-gated re-anchor sweep". Compare plugins/source-control/skills/babysit-loop/SKILL.md:319, same seam, updated.
• plugins/session-flow/skills/reanchor/evals/evals.json:76 — eval case name is still negative-routing-rule-discipline-is-re-anchor-plugin, though that case's expected_output and expectations were both rewritten.

Deliberately excluded

Verified as correct, recorded so they are not re-reported:

• plugins/discipline/context/re-anchor-audit-correct.md keeps its filename. Deliberate: the file's own H1 is "The re-anchor / audit / correct-forward loop" — the name is the verb, not the plugin. All 19 in-repo references resolve.
• re-anchor remains in marketplace.json tags, plugin.json keywords, and the renames map. Correct — it is a discoverability alias and a migration record.
• CHANGELOG history keeps the old name. Append-only by contract.
• docs/topics/fresh-eyes-checkpoint-audit/PLAN.md:200 cites the pre-rename path plugins/re-anchor/context/re-anchor-audit-correct.md. Ambiguous: docs/topics/ is a contract-tier slice pruned before merge, so a dangling pointer there is arguably by design. Owner's call.

Acceptance

• The 0.9.0 migration note tells configured users how to restore their four userConfig values
• The three stale prose sites read discipline
• The retained-by-design items above are not "fixed" — the verb filename, the tags, and CHANGELOG history stay

Related

#1276 (the rename), #1271 (skill-metadata migration, which touches the same plugin's descriptions and should land after this).

---

This was generated by AI during a session on the fact-check capability.

[kyle-sexton]

[kyle-sexton]

This was generated by AI during work-loop execution.

Claimed and worked via /work-items:work. PR: #1365.

Items 2–4 (the three stale prose sites) are fixed as specified. Item 1 (orphaned pluginConfigs
overlays) turned out to have a false premise, verified against current upstream docs this session —
not implemented. Full evidence is in the PR description; summary:

Fetched Create and distribute a plugin marketplace
(current official docs, this session). It states, verbatim, that on rename Claude Code "rewrites the
old key to the new key in the user, project, and local settings scopes for both enabledPlugins and
pluginConfigs" — so the four userConfig values (batch_exclude, batch_promote, batch_demote,
research_deep_verification) migrate automatically; nothing is orphaned.

This also corrects this issue's framing that the pluginConfigs concern was "raised by an automated
reviewer on #1276 without a reply." It was replied to, on the CHANGELOG.md thread itself: the reviewer
comment was answered "INCORRECT — the premise is falsified by upstream," citing the same doc, and
fixed pre-merge in commit aa094fc9 (gh api repos/melodic-software/claude-code-plugins/pulls/1276/comments).
plugins/discipline/CHANGELOG.md's [0.9.0] entry already carries the correct wording as merged.

Adding the proposed "re-enter your values via /plugin configure discipline" line would ship guidance
that contradicts current upstream behavior, so item 1's acceptance box is left unchecked deliberately
rather than satisfied with incorrect content.