audit: verify soldeer autopublish is wired and current (hazard cat. 10 — dead wiring, cross-org secrets: inherit, [package] identity, registry lag)

[thedavidmeister]

Closes #31

What

Adds hazard-surface category 10 — Broken or stale package publish pipeline (soldeer autopublish) to skills/audit/SKILL.md, so the audit treats a soldeer-published repo whose merge→registry pipeline is broken, mis-wired, or lagging as a finding. It is the producer-side counterpart of Quality #11 (stale soldeer dependencies): #11 audits this repo's pins as a consumer, the new category audits what this repo publishes.

Four checks, causes before symptom:

1. Dead / stale publish wiring — a publish workflow uses: a rainix reusable removed at the pinned ref (the dead tag-triggered publish-soldeer.yaml), or a tag-triggered publish that hasn't fired across content-changing merges. MEDIUM, HIGH when the unpublished delta carries a security/correctness fix or deploy-record change consumers pin against.
2. Cross-org secrets: inherit — a reusable uses: whose owner org differs from the calling repo's, with secrets: inherit: GitHub disallows it, the run dies at startup_failure, and the publish silently never runs. Secrets must be passed explicitly. MEDIUM.
3. Missing [package] identity — no [package] name/version in foundry.toml; rainix-autopublish's content gate + auto-bump read them. MEDIUM.
4. Registry behind source / un-bumped next-version — the observable symptom, checked via https://api.soldeer.xyz/api/v1/revision?project_name=<name>, and the one check that also runs pre-merge: under pr:<n>, flag a diff changing published content (src/, excluding src/generated/) while [package].version still equals the published latest — the post-merge gate enforces that invariant a round trip late. Network honesty mirrors Quality ERC-165 checks: prefer OZ ERC165+super over raw IERC165, plus empty/vacuous impls, half-advertised families, and test coverage #11: unreachable registry ⇒ the check is noted skipped, never reported "current".

The Pass-6 scoped-run degradation bullet gains the matching touch-question "(10) change published-package content or its publish wiring", and the two "nine categories" counts become ten.

Evidence (verified live)

• Issue's originating incident: S01-Issuer/st0x.deploy — st0x-deploy stuck at 0.1.1 through two deploy releases; fixed by ci: soldeer autopublish via rainix-autopublish (unbreak publishing) S01-Issuer/st0x.deploy#239 (migrate to autopublish, merged 2026-07-08) and ci: pass soldeer autopublish secrets explicitly (fix cross-org startup_failure) S01-Issuer/st0x.deploy#240 (explicit cross-org secrets after startup_failure).
• Fresh case, today (2026-07-30): rainlanguage/rain.deploy#21 merged new public API at [package] version 0.1.4 with 0.1.4 already published (registry shows 0.1.4 published 2026-06-29). The post-merge Package Release run https://github.com/rainlanguage/rain.deploy/actions/runs/30564517433 failed at rainix soldeer-gate with foundry.toml [package].version (0.1.4) is not ahead of the published revision (0.1.4) (exact log line verified) — main went red until bump PR chore(release): bump to 0.1.5 so main's new API can publish rain.deploy#24 landed (merged 17:13:55Z) and 0.1.5 published at 17:14:56Z. The gate exists but fires post-merge; the new pre-merge check is what would have flagged audit: add events-belong-on-the-interface check (Code quality #12) #21 itself.

Versioning

0.23.0 → 0.24.0 in lockstep across SKILL.md frontmatter, .claude-plugin/plugin.json, and .claude-plugin/marketplace.json; version-hygiene replicated locally with nix-store jq (versions agree, bumped vs base).

QA

• Discriminating tests: n/a — prose-only diff (SKILL.md rule text + version JSON bumps); the repo's only CI is version-hygiene, replicated locally with nix-store jq 1.8.2: plugin.json == marketplace.json == frontmatter (0.24.0) and bumped vs origin/main base (0.23.0), which fails on base by construction (base carries no bump).
• Mutations applied: n/a — no executable code changed; the version-hygiene checks were exercised in both directions locally (versions agreeing passes; a skills/ diff without a bump is the failure the CI reproduces).
• Oracle: live GitHub/registry state, independent of this diff — run 30564517433's exact failure line pulled via gh run view --log-failed, api.soldeer.xyz/api/v1/revision?project_name=rain-deploy (0.1.4 @ 2026-06-29, 0.1.5 @ 2026-07-30T17:14:56Z), rainlanguage/rain.deploy#24 merged 17:13:55Z, rainix workflow listing (publish-soldeer.yaml 404, rainix-autopublish.yaml present, gate semantics read from its source), and st0x.deploy PRs #239/#240 titles+merge dates.
• Category check: issue asks (1) dead/stale publish wiring, (2) cross-org secrets: inherit, (3) missing [package] identity, (4) registry behind source — all four are sub-checks of the new category; the requested Pass-6 placement (generated-artifacts/cross-repo-drift hazard) and the Pass-0-adjacent workflow-config causes are covered by the category text + the scoped-run touch-question, and the stale-soldeer network-honesty clause is mirrored verbatim in spirit ("skipped", never a false "current"). Additionally covers the pre-merge un-bumped-next-version shape the fresh rain.deploy incident demonstrates.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 40 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b864af40-7aa8-47c2-b8bc-9feafb1ae350

📥 Commits

Reviewing files that changed from the base of the PR and between aa3d473 and 805df03.

📒 Files selected for processing (3)

• .claude-plugin/marketplace.json
• .claude-plugin/plugin.json
• skills/audit/SKILL.md

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thedavidmeister]

QA evidence for this prose-only skill change (head 1be4a830081930700060718462c28b43c25cd752):

Every factual claim in the new category was verified against live state before writing it:

Claim in the rule text	Verification
publish-soldeer.yaml removed from rainix	gh api repos/rainlanguage/rainix/contents/.github/workflows/publish-soldeer.yaml → 404; workflow listing shows rainix-autopublish.yaml present
soldeer-gate semantics (normalized source-only hash, src/generated/ excluded, version line blanked, next-version invariant)	Read from rainix-autopublish.yaml source at HEAD (gate comments + rainix-static soldeer-gate invocation)
rainlanguage/rain.deploy#21 merged new API at [package] version 0.1.4 with 0.1.4 already published	Registry: api.soldeer.xyz/api/v1/revision?project_name=rain-deploy → 0.1.4 published 2026-06-29T12:21:08Z
Post-merge Package Release run failed at the gate	Run 30564517433: conclusion failure, push to main, merge of #21; exact log line: foundry.toml [package].version (0.1.4) is not ahead of the published revision (0.1.4); the next-version lifecycle needs it to be the next UNPUBLISHED version — bump [package].version above 0.1.4.
Round trip to green	Bump PR rainlanguage/rain.deploy#24 merged 2026-07-30T17:13:55Z; registry shows 0.1.5 published 2026-07-30T17:14:56Z
st0x.deploy originating incident	S01-Issuer/st0x.deploy#239 ("unbreak publishing", merged 2026-07-08) and #240 ("fix cross-org startup_failure", merged 2026-07-08)

Version lockstep (the repo's only CI, replicated locally with nix-store jq 1.8.2): SKILL.md frontmatter == plugin.json == marketplace.json == 0.24.0, one minor above origin/main's 0.23.0; skills/ diff present so the bump-required branch of version-hygiene is exercised.

Internal-consistency sweep of the doc after the edit: the Pass-6 category count is referenced in three places (the scoped-run touch-question enumeration, "The nine stay non-exhaustive", "none of the nine names it") — all three updated to ten; no other "nine"-category references remain (grep -n "nine" leaves only the unrelated "nine separate skills" history note). Dimension-0 self-review caught and fixed one undefined cross-reference ("(a)–(c)" pointing at unlettered bullets) and three under-qualified PR references before push.

🤖 Generated with Claude Code

[thedavidmeister]

Reviewed 805df03: ready — Hazard cat. 10 with causes-then-symptom structure, the pre-merge un-bumped-version check today's rain.deploy incident proved out, content-hash over version echo, skipped-never-false registry honesty, composed onto main's cat 9 at 0.29.0, zero unresolved threads.