Repository navigation
shared-rules: dispose-to-serve-new-state required in all seven repos — step 3 of 3 - #4662
Conversation
…— step 3 of 3
Maintainer directive, 2026-09-17: "the grain keeps serving old state until we send
dispose request" / "write this prominently in all repos" / "in pull request skill etc".
Step 1 was core#4641 — the block wrapped in core's AGENTS.md, the Architecture page
StaleStateUntilRecycle it points at, the five skills, and the register entry with
required-in naming only the hub, so no spoke marker was ever undeclared. Step 2 landed
the block verbatim in the six registered spokes. This widens required-in to all seven,
so from here a repo that drops or drifts the block is red in core's shared-rules check.
MeshWeaver.Crm carries the same text (Crm#127) and is deliberately NOT registered: it
is absent from the register's `repos`, so the gate never reads it, and registering it
needs the read-only fleet-reader App installed there AND Crm carrying the blocks
already registered — an unreadable repo is a RED in this gate by design.
Verified: check-shared-rules.py --self-test 18/18, and --local across all seven repos
with this widening green ("✓ 6 spoke(s) match the hub").
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🟡 Changes recommended
The manifest claims all step-2 spoke PRs landed, contradicting the PR’s stated status for three of them.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Widens enforcement of the dispose-to-serve-new-state shared rule from core to all seven registered repositories.
Changes:
- Adds six spoke repositories to
required-in. - Updates rollout metadata and documents Crm’s intentional exclusion.
File summaries
| File | Description |
|---|---|
.github/shared-rules.json |
Registers all seven repositories for shared-rule validation. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| "Landed: step 1 core#4641; step 2 Plugins#2050, Education#351, Reinsurance#220,", | ||
| "SocialMedia#205, Manufacturing#101, Memex#409; step 3 this entry's widening. Crm#127", | ||
| "carries the same text, unregistered — see the paragraph above.", |
There was a problem hiding this comment.
Valid catch, and the contradiction was real — but it resolves the other way round now: the manifest line is correct and the PR DESCRIPTION had gone stale.
When the description was written, Reinsurance#220, SocialMedia#205 and Manufacturing#101 were genuinely open and red. They were red on a publication-availability refusal that had nothing to do with their own diff (each is AGENTS.md and nothing else): compile-check failed at "Add external modules to the reference set" BEFORE any NodeType compiled, with no sealed publication for source (plugins) under framework identity sadada8c47… — the #3583 class. Core CD run 8872 sealed the publication; each spoke was then re-run as a whole run, and each ones own resolver line was read before its result was trusted (PINNED_SET 3.0.0-ci.8872, identity s02e28d5cd…, compile-check success). All six registered spokes plus Crm#127 are now merged, which I verified by reading the block out of each default branch rather than trusting the merges.
So the why block stands as written. I have rewritten the description to match: it now lists all six as merged, carries the per-spoke resolver table, and states why Crm is deliberately unregistered. Thanks — a stale rollout record in the one file that exists to explain the rollout is exactly the thing worth flagging.
…e census that ends it Bundled onto the step-3 register change rather than spending its own CI run. The maintainer supplied the measurement behind the "an UNFORCED trigger re-adopts the same prebuilt bundle" clause, and it also answers why that case cost two hours: NO INSTRUMENT REPORTS IT. On memex, 2026-09-17, Approvals/Desk was recompiled at 17:35 (v844 -> v846) by a pod of the OTHER generation while the deployment was split across two images; it came out with the same MVID, still stamped the foreign framework identity, and recorded buildProvenance: AdoptedVerified. Nobody ran the recycle verb, so RequestedReleaseForce was never stamped — a boot-time compile re-adopted a bundle, which is the unforced clause and not the forced one. (That also confirms the clause as shipped is right: the forced path does skip adoption, #2818.) Neither instrument a reader reaches for could say so. `/health`'s content-types records a degradation only when a content read DEGRADES, and bake-report reads the SHARED record, which said Ok. All that was left was a blank area and "No renderer is registered for area …". The page now says that, and points at the census built to answer the question the other two cannot — "is there a NodeType this replica cannot SERVE?", per type, with its denominator stated and with "no sweep has reported here" printed as its own sentence rather than as a clean one (#4647). Verified: Documentation.Test Release -warnaserror 0 Error(s); full suite 562 passed, 0 failed, 0 skipped (DocumentationLinkIntegrityTest included, which resolves the new link). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Second commit bundled in (deliberately, rather than spending a separate CI run on a paragraph): The maintainer supplied the measurement behind this page's "an UNFORCED trigger re-adopts the same prebuilt bundle" clause. On memex, 2026-09-17, What made it cost two hours is that no instrument reports it. Verified: Still a draft for the same reason as before — the last three spokes (Reinsurance#220, SocialMedia#205, Manufacturing#101) are blocked on the seal, not on anything in their own diff. 🤖 Generated with Claude Code |
…opped Resolving the conflict with main replaced main's "NECESSARY AND NOT SUFFICIENT" section with this branch's corrected one, and that section carried a measurement this branch's does not have: #4652, the first use of the re-run remedy, BLOCKED/FAILURE -> CLEAN/SUCCESS/isInMergeQueue within a minute, with re-arming auto-merge proven not to clear it. Restored beside the remedy it evidences, and a second instance (#4662, today) added. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Step 3 of 3 of the
dispose-to-serve-new-staterollout (maintainer, 2026-09-17: "the grain keeps serving old state until we send dispose request" / "write this prominently in all repos" / "in pull request skill etc").AGENTS.md, the Architecture page Stale State Until a Recycle it points at, the five skills (pullrequest,deployment,release,mesh-data,debug), and the register entry withrequired-innaming only the hub — so no spoke marker was ever undeclared.required-into all seven, so from here a repo that drops or drifts the block is red in core'sshared-rulescheck.Also carries a second commit:
StaleStateUntilRecyclenow names why the unforced re-adoption case is invisible (/health'scontent-typesrecords a degradation only when a read degrades;bake-reportreads the shared record, which saidOk) and points at #4647's per-type outcome census. Bundled deliberately rather than spending a separate CI run on a paragraph.On the earlier red, now cleared
Four spokes were blocked on a publication-availability refusal, not on anything in their own diff:
compile-checkfailed at "Add external modules to the reference set" before any NodeType compiled, withno sealed publication for source 'plugins' under framework identity sadada8c47…(the #3583 class). Core CD run 8872 sealed the publication; each spoke was then re-run as a whole run and each one's own resolver line was read before its result was trusted:PINNED_SETcompile-check3.0.0-ci.8872s02e28d5cd…3.0.0-ci.8872s02e28d5cd…3.0.0-ci.8872s02e28d5cd…3.0.0-ci.8872s02e28d5cd…Why Crm is not in the register
MeshWeaver.Crmis absent from the register'srepos, so this gate never reads it and nothing here requires it. Registering it needs the read-onlyfleet-readerApp installed there and Crm carrying the blocks already registered — an unreadable repo is a RED in this gate by design. It carries this block's text anyway, so a later registration is a one-line change rather than a rollout.Verification
check-shared-rules.py --self-test18/18, and--localacross all seven repos read from their live default branches after the spokes landed:✓ 6 spoke(s) match the hubfordispose-to-serve-new-stateand fornever-hand-roll-ui,✅ All 5 shared rule block(s) are identical everywhere they are carried, across 7 repos.Documentation.TestRelease-warnaserror0 Error(s); full suite 562 passed / 0 failed / 0 skipped.mainis merged in so this cannot revert #4418's widening ofnever-hand-roll-ui; the combined register reads 7 for both blocks.Pairs-with: none — the register and one doc paragraph; no public surface changes.
🤖 Generated with Claude Code