Retarget the built-in ai-config plugin ref to the Morrison-Lab marketplace - #359
Conversation
…arketplace ai-config renamed the marketplace declared in its own .claude-plugin/marketplace.json from 'd-morrison' to 'Morrison-Lab' (ai-config#802). A plugin ref resolves by that declared name, so the built-in 'ai-config@d-morrison' in claude-code-review.yml and claude.yml no longer matches anything and plugin installation aborts the run: Failed to install plugin 'ai-config@d-morrison' (exit code: 1) Every consumer of either workflow is affected. The clone URL was not the problem -- git and gh both follow GitHub's transfer redirect, so the old URL still clones and checking whether it resolves reports success. Only the name lookup fails. Both are retargeted here regardless. Fixes the two functional sites (run-claude-review-attempt's composite action and claude.yml's own inline plugin list) and keeps the input descriptions, examples/ stubs, and website/reference/ tables in sync per CLAUDE.md's composite-plus-wrapper-plus-example rule. Also qualifies the earlier documentation-URL retarget's changelog fragment, which deliberately left these identifiers alone as 'names rather than URLs' that 'still match the workflows that use them'. That was correct when written; ai-config#802 landed afterwards and invalidated it, and the fragment is still unreleased so it would have published a false claim.
|
🤖 Jules is reviewing this PR. Results will appear here shortly (typically 2–5 minutes). |
Note on the two failing checks
That is the same signature as every downstream consumer right now, and it clears once this merges and
Self-reviewSince
Verdict: ready for merge, with the caveat that the |
🤖 Jules ReviewSummaryThis PR correctly updates all references to the built-in Strengths
VERDICT: approve Session: |
|
👀 Picked up by workflow run #30435383964. Setup runs first; Claude itself responds after that. |
2026-07-29 08:29 UTC |
Final CI stateJules: approve. Every check passes except the two that structurally cannot:
The That makes the merge a human call. A failing required check is not something to merge past autonomously, so I am handing this over rather than forcing it. Two things worth doing on your side:
The consumer-side evidence is already in: |
* docs: record why a re-run cannot verify a major-tag slide Hit while verifying #359's release. After v2 was slid to c50e847, a re-run of the run that had failed still failed with the same 'ai-config@d-morrison' error, because GitHub replays the reusable-workflow SHA recorded in referenced_workflows at the original run's creation. The confusing part is that nested composite actions DO re-resolve at job-preparation time, so the same job log showed a c50e847-only echo line next to the old workflow's INPUT_PLUGINS -- which reads as the fix being live but ineffective, rather than not yet live. Documented next to the existing "can't self-verify before merge" section, since that one ends at the merge and this covers the step after it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012PKotEhi2qeEQ1kZwuFES8 * docs(review round 1): distinguish the two re-run modes Review correctly found that "the UI's re-run button" and "never a re-run" were overbroad. Verified against GitHub's own docs -- read from the docs source (data/reusables/actions/partial-reruns-with-reusable.md), since docs.github.com returns 403 to this environment: * Re-running all jobs in a workflow will use the reusable workflow from the specified reference. * Re-running failed jobs or a specific job in a workflow will use the reusable workflow from the same commit SHA of the first attempt. So only the failed-jobs/specific-job path is stale; "Re-run all jobs" re-resolves the tag. Narrowed the heading and the closing advice, quoted the docs inline so a later reviewer re-deriving this finds the citation in place rather than in thread history, and added the docs' own reference-is-not-a-SHA precondition. Also addressed the reviewer's second point: the composite carve-out means a failed-jobs re-run CAN surface a slide whose only change lives in a composite, so the section now says what such a re-run cannot verify is a change to the reusable workflow's own content. The observed case was an API rerun_failed_jobs, which the narrowed claim still covers exactly; the evidence did not change, only its scope. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012PKotEhi2qeEQ1kZwuFES8 * style: use dash bullets in the quoted docs block (MD004) lint-markdown's MD004/ul-style requires dash markers; the block quoted GitHub's docs verbatim, which use asterisks. Only the list marker changed; the quoted wording is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012PKotEhi2qeEQ1kZwuFES8 * docs(review round 2): name all three failed-jobs re-run spellings Review flagged that backticked `rerun_failed_jobs` reads as a precise API citation but matches no REST endpoint. The concern is right; the stated grounds are only partly so. `rerun_failed_jobs` IS a real identifier -- it is the GitHub MCP server's `actions_run_trigger` method value, and the literal call the anecdote describes -- but it is not the REST or CLI name, so backticking it alone invites a reader to hunt for an endpoint by that name. Rather than swap one surface's spelling for another, name all three and say that none is canonical: the REST path segment, `gh run rerun --failed`, and the MCP method. Dropped the "API" qualifier from the anecdote, which was what made the single spelling read as authoritative. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012PKotEhi2qeEQ1kZwuFES8 --------- Co-authored-by: Claude <noreply@anthropic.com>
The break
ai-configrenamed the marketplace declared in its own.claude-plugin/marketplace.jsonfromd-morrisontoMorrison-Lab(ai-config#802, merged 2026-07-29T06:51:55Z):{ "name": "Morrison-Lab", "owner": { "name": "Morrison-Lab" }, ... }A plugin ref resolves by that declared name, so the built-in
ai-config@d-morrisonin bothclaude-code-review.ymlandclaude.ymlnow matches nothing, and plugin installation aborts the run before it reviews or answers anything:Every consumer of either workflow is affected, and
review / require-reviewfails with it, so any repo with that as a required check is unmergeable. Observed downstream inLacaedemon/sparta(#1171): its last green review ran at 06:20:51Z, and the first run to reach plugin install after ai-config#802 failed.The clone URL was not the problem
This is what made it awkward to diagnose. Git and
ghboth follow GitHub's transfer redirect, sod-morrison/ai-config.gitstill clones fine, and the obvious check reports success:Only the name lookup fails. The URL is retargeted here too, but it was not what broke.
What changed
Two functional sites, both of which independently spell out the marketplace and plugin ref:
.github/actions/run-claude-review-attempt/action.yml.github/workflows/claude.ymlPlus the things CLAUDE.md's composite-plus-wrapper-plus-example rule requires stay in sync: the
use-ai-config/plugin-marketplaces/pluginsinput descriptions in both reusable workflows, theexamples/stubs, and thewebsite/reference/tables that quote the identifiers.Supersedes a deliberate earlier decision
changelog.d/retarget-doc-urls-after-org-move.fixed.mdexplicitly left these two identifiers alone:That was correct when written -- the marketplace still declared
d-morrisonat the time. ai-config#802 landed afterwards and invalidated the "still match" premise. Since that fragment is unreleased, it would otherwise publish a claim that is now false, so this PR qualifies it to past tense and points at the follow-up rather than silently leaving it.Deliberately untouched: historical
CHANGELOG.mdandchangelog.d/entries, andcheck-new-line-breaks.py's porting attribution -- all correct as records of what the repo was called when written.Verification
The reverse of this change is what is currently failing in the wild, so the fix is confirmed by the consumer side:
Lacaedemon/spartaworked around it by opting out (use-ai-config: false) and re-adding the marketplace under its current name throughplugin-marketplaces/plugins, which restored reviews immediately (sparta#1172). This PR makes that override unnecessary; sparta tracks removing it in sparta#1173.All five touched YAML files parse. No behaviour changes beyond the identifier.