infra: three submodules, watched releases, registry-mirrored skills - #358
Conversation
Eleven repos were vendored as submodules purely so agents could check a fact against them. None of their bytes reach the built site, so each one was a recurring bump PR with nothing to show for it, and several drifted years of releases behind unnoticed. They are now watched instead: .sources/upstream.json records the ref the docs are verified against, scripts/check-upstream-releases.mjs compares that against the newest matching tag, and a weekly workflow opens one issue per repo that moved, carrying the ref delta and a summary of what changed. Agents verify against the pinned ref via raw.githubusercontent.com rather than main, so a review stays reproducible and a page cannot document a flag from a release whose doc links have not been adapted yet.
examples, icskills, and dotskills had no notification when their pin fell behind: motoko and internetidentity are covered by their own sync workflows, and the release check only looked at the non-vendored repos. They are now in upstream.json as a vendored group whose pin is read from the gitlink, so git stays the single source of truth for it. icskills and dotskills are both currently behind.
…tion Skills came from two submodules through a double symlink chain (.claude/skills -> .agents/skills -> .sources/<submodule>/skills). They now come from skills.internetcomputer.org via a SessionStart hook, matching dfinity/examples: a differential sync keyed on each skill's published hash, offline-safe, and it only prunes skills it installed itself. That drops the icskills submodule, the symlink farm, and a watcher entry, and raises coverage from 16 skills to 29 — including static-site, custom-domains, encrypted-maps, service-discoverability, and mops-cli. It also corrects two stale names in the AGENTS.md table: asset-canister no longer exists (static-site covers it, including the legacy recipe and migration) and vetkd is now vetkeys. technical-documentation is not on the IC registry. It changed once since the pin and only to switch its license field to MIT, so its 11 text files are vendored next to the two brand skills that were already committed, and the dotskills submodule goes too. Three submodules remain: motoko, internetidentity, examples.
marc0olo
changed the title
MIT requires the copyright and permission notice to travel with a copy. The skill's frontmatter recorded its license and source but not the notice itself, so the upstream license text now sits alongside the files and NOTICE records the attribution.
The session-start hook is Claude Code only and automatic skill loading is harness-specific everywhere, so nothing loads skills automatically elsewhere. What is portable is where to get them: the IC skills from the registry index by URL, since they are gitignored and absent from a fresh clone, and the three repo-maintained skills from their committed path. Also records that the sync replaces a local skill whose name is later published to the registry, so publishing one means deleting the local copy in the same change.
…e version The cdk-rs pin was 0.20.1, which is the published crate version, not a git tag: the repo's newest bare-semver tag is 0.19.0, two minors behind. Compared against tags, the pin could never be overtaken, so the check reported 'current' forever for the repo that governs every Rust code block. A release pin that is not among the matched tags is now a loud failure rather than silence, and cdk-rs tracks crates.io, which is where its releases actually appear. Auditing the other ten pins found no further cases. motoko-core and response-verification now diff their changelogs, which names the APIs that changed instead of leaving 'check every signature' as the whole task.
… label Auditing every watched repo against its real publishing channel found a second case beyond cdk-rs: icp-js-sdk-docs carries no tags, so its commit was standing in for an @icp-sdk/core release. Tracking npm instead shows the docs are verified against 5.4.0 while 6.1.0 is out, a major bump across every JS code block. The pin was derived from public/core/versions.json at the previously pinned commit rather than guessed. Registry-tracked entries get a registry link instead of a GitHub compare view and no file diff, because a package version is not a ref git can resolve; both were producing broken links and a failed fetch. Every issue now also carries upstream-sync, so they are findable as a class rather than only per repo.
icp-js-sdk-docs is the delivery site for js.icp.build and carries the API docs for six libraries as zips. A commit on it means the docs site was rebuilt, not that an SDK released, so it was a proxy for the thing we actually document. The two packages the docs use are watched directly, and they need different signals: icp-js-core tags match its npm versions, so tags are authoritative and its CHANGELOG is the review payload, while icp-js-canisters publishes 3.6.0 with its newest semver tag at v1.0.0, so npm is the signal there. Both pins come from what the docs assert: v5.4.0 from the mirror's public/core/versions.json at the previously pinned commit, and 3.5.0 from the stated minimum in references/application-canisters.md.
…ches Addresses the Copilot review on #358. The commit track ordered short SHAs with the version comparator, so a real update whose SHA happened to sort lower was reported as current. Demonstrated: pinned ef03698 with head 9f1e819 returned 'current'. SHAs have no order, so the pin either prefixes the head or it does not, and links now use the full SHA while only the display is shortened. The link row was inferred from whether a registry URL was set, which mislabelled the commit track's GitHub compare view as 'Registry'; it is now named explicitly, and the verify-diff guard keys off that name rather than the URL. Also: upstream.json documented only two of the four tracks, VERSIONS claimed 7-char hashes while internetidentity uses 8, the label wording omitted both the shared upstream-sync label and the vendored form, and the workflow's jq filter uses an explicit index.
Twelve watched entries meant a weekly check on repos the docs barely draw on. Measured footprint in docs/ decided each one: icp-cli 51 pages, 461 hits, plus the link slug motoko-core 63 pages, 328 hits cdk-rs 47 pages, 336 hits, plus pinned versions in prose icp-js-core 15 pages, 47 hits icp-cli-recipes 11 pages, 26 hits, all pinned recipe versions in prose icp-js-canisters 4 pages, 8 hits, with a stated minimum version The other six move to a group: templates (linked, not restated), candid (a rarely-moving spec), response-verification (two pages that link to docs.rs), chain-fusion-signer (seven mentions), papi (one page), ic-pub-key (three pages). They keep their entry and their verify path so an agent knows where to look, but carry no pin and produce no issue: verify against the latest release on demand, since the surface is small enough that the next edit to those pages catches drift. First run drops from ten issues to five.
|
All five Copilot comments addressed. One was a real bug in the script; four were accurate documentation mismatches. 1. 2. 3. 4. 5. Label wording. Correct and then some: it omitted both the shared Unrelated to the review, the watch list also shrank from 12 repos to 6 after measuring what each upstream actually underwrites in |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 72 out of 73 changed files in this pull request and generated 2 comments.
Suppressed comments (2)
Previously missed (2) — in code that hasn't changed since the last review.
AGENTS.md:220
- This section says there are "five" vendored submodules, but the table immediately below lists three (
motoko,internetidentity,examples). This will mislead anyone following the instructions.
scripts/check-upstream-releases.mjs:148 summarizeChangeusesSets of lines, which can undercount changes when the same non-empty line appears multiple times (duplicates in changelogs/headings are common). Using per-line counts will make the added/removed totals and heading detection more accurate.
Addresses the second Copilot review on #358. The vendored check had both full SHAs in hand but put 7-char prefixes in the compare link and, more importantly, in the git checkout command it asks a maintainer to run. Short SHAs are now display-only. The commit track's comment also claimed links resolve against the full SHA, while the pin side of the compare URL is whatever upstream.json records. The comment now describes that: the head side is full, the pin side stays short for readability, and GitHub resolves a prefix on either side.
|
Both comments from the second review are accurate and fixed in Short SHAs in the vendored check. Correct, and the The comment that no longer matched the code. Also correct, and it was mine from fixing the previous review: I wrote "links resolve against the full SHA" while the pin side of the compare URL is whatever |
1. AGENTS.md said "five repos" over a table of three. 2. setup-node was unpinned while every other action in the repo is SHA-pinned. 3. The dispatch input was interpolated into a run: body; it now goes through env and is quoted. 4. icp-cli-recipes monitoring was a no-op for four of five recipes: refs compare by numeric run, so `rust-` against `static-site-` compares textually and only the alphabetically-last prefix could ever surface. Each recipe now has its own entry, pin, issue and label, which immediately surfaces asset-canister v2.2.1 to v2.3.0, rust v3.3.0 to v3.4.0, motoko v5.0.0 to v5.1.0 and prebuilt v2.0.0 to v2.1.0, all previously invisible. 5. scripts/setup.sh prunes .sources/ directories left behind by submodules the repo no longer vendors. A stale .sources/icp-cli/ is exactly the trap the verify-at-the-pinned-ref rule exists to close. 6. The pin guard covered only the release track. A crate or npm pin in the wrong shape compared as older for ever, so registry pins are now checked against the published version list, and crates.io reads max_stable_version so a prerelease is not reported as the latest release. 7. summarizeChange counted by set membership, so an added line that already appeared elsewhere read as unchanged. It now counts occurrences: cli.md v1.1.0 to v1.3.0 reports 14 added rather than 11. 8. Stale .sources/ paths in three pages, and migrating-from-dfx.md, which does not exist, named in AGENTS.md and CONTRIBUTING.md. 9. vincentkoc/dotskills is recorded as a reference entry so the vendored skill's origin is not lost.
The validator skips HTML comments but not MDX ones, and the fix for the stale .sources/ pointer used an em-dash, which the repo bans.
|
All ten items addressed in 1 to 3, the pre-merge fixes. 4, the recipes no-op. Correct and the most valuable catch here. Split into one entry per recipe, each with its own pin, issue, label and title. That immediately surfaces four releases the docs are behind, all previously invisible: One correction to the diagnosis, with evidence: 5, post-merge leftovers. 6, the guard covered only tags. Fixed both halves. Registry pins are now validated against the published version list, so 7, 8, stale pointers. Fixed in 9, the judgment call. Agreed, and it is the part I would want a second opinion on too. Two things now recorded rather than left implicit: 10, smoke test. Cannot run yet: |
The prune tested for 'not declared in .gitmodules', which today is the same set but would delete a scratch directory parked under .sources/ without warning. It now also requires the directory to be empty or hold a .git entry, which every submodule working tree does; anything else is reported and left in place.
|
Thanks for re-verifying against the commit rather than the reply, and for correcting the tag-list truncation openly. The The prune comment. I took it further than wording, because the hazard you named is real even if today's
Merge order. Added as a section to all three PR bodies, so whoever merges does not have to reconstruct it. One detail worth recording there: #354 and #358 both touch |
…aced (#370) Closes #360, #361, #362, #363, #364, #365, #366, #367, #368, #369. The first batch from the upstream watcher added in #358, plus one fix to the watcher itself that running the batch exposed. **23 files, 18 of them docs pages.** Two of the ten issues needed real content changes; the other eight were version strings or pin bumps. Every claim below was checked against the upstream at the new ref. Where a replacement is named, it is upstream's own wording, not an inference. ## What a reviewer should scrutinise 1. **The 20 Motoko call-site replacements** are the only changes that alter code a reader copies. Each one is named in upstream's `@deprecated` marker, quoted below. 2. **`icp canister status <name> -i`** replacing `icp canister id <name>`. This is a real command substitution, verified against the installed CLI, not a rename. 3. **The examples path filter** decides whether a whole class of issue fires. Its two-way verification is in the table below. Everything else is a version string or a pin. ## motoko-core v2.4.0 → v2.6.1: 20 deprecated call sites (#362) v2.6.0 deprecated every `Module.fromX` conversion that has a `toX` counterpart. Our examples used five of them, so left alone each one emits a compiler warning for anyone who copies the code. The replacements are read from `src/*.mo` at v2.6.1: | Deprecated | Upstream's `@deprecated` text | Sites | |---|---|---| | `Nat64.fromNat` | Use `Nat.toNat64` instead. | 7 | | `Nat8.fromNat` | Use `Nat.toNat8` instead. | 5 | | `Blob.fromArray` | Use `Array.toBlob` instead. | 5 | | `Float.fromInt` | Use `Int.toFloat` instead. | 2 | | `Text.fromChar` | Use `Char.toText` instead. | 1 | **Import policy: four added, zero removed.** A replacement can need a module the block did not import (`Nat`, `Char`), so those are added. Nothing is removed, deliberately: an unused import is harmless, a missing one does not compile, and pre-existing imports are not this change's business. A first attempt did prune them and got it wrong three ways, dropping `Text` where `hex.chars()` still needs it in scope for contextual dot, plus `Cycles` and `Principal`, which are unrelated. That pass was reverted. Two cases handled by hand: one `Nat64.fromNat` appears in prose rather than a fence (`ledgers.mdx`), and one fence is a fragment with no import block of its own, so it gets the call change without an import. ## icp-cli v1.1.0 → v1.3.0: nothing lost, two commands that never existed (#361) The decisive check is that **`docs/reference/cli.md` lost 0 lines** between the two refs (14 added, all for the new `icp canister link`). No documented command or flag disappeared, so the bump itself is safe. Verifying every `icp` invocation in `docs/` against that reference then surfaced two commands that do not exist. Both confirmed against the installed v1.3.0, not just the reference: | In the docs | Actual | Sites | |---|---|---| | `icp canister id <name>` | `icp canister status <name> -i` (`-i` is documented as "Only print the canister ids") | 4 | | `icp identity whoami` | `icp identity principal` | 1 | These predate the bump. They are exactly what the verification pass deferred in #354 was for. ## The remaining eight - **Four recipes** (#366, #367, #368, #369) each shipped **one identical additive change**, an optional `visibility` field on metadata entries, so the `icp.yaml` examples stay valid and only the 20 version strings move: `asset-canister` v2.2.1→v2.3.0 (10 places), `rust` v3.3.0→v3.4.0 (6), `motoko` v5.0.0→v5.1.0 (3), `prebuilt` v2.0.0→v2.1.0 (1). - **icp-js-core v5.4.0 → v6.1.0** (#364) is a major bump, and still pin-only for us. It changes `Agent.readState`, delegation permissions, effective subnet ID and URL path handling. Our examples import `agent`, `agent/canister-env`, `principal`, `identity` and `candid` only, never construct a `Delegation`, and never call `readState`. - **cdk-rs 0.20.2** (#363) only makes entry points lenient about an empty input vector. Pin-only. - **icp-js-canisters 3.6.0** (#365) adds NNS converter fields and snapshot visibility; the stated `>= 3.5.0` minimum still holds. Pin-only. - **examples** (#360) bumped to `42c474d`, with all six `snippet=` regions verified to resolve. ## Watcher fix: report an examples bump only when it touches a quoted file Running the batch showed #360 was noise, and the first attempt at fixing that was wrong in an instructive way. I dropped the check entirely, reasoning that the build already fails when a `snippet=` path or `#region` marker stops resolving. It does, but that only covers **breakage**. It cannot see an example being **corrected upstream while still resolving**, which leaves the docs quoting old code with a green build. That is the more valuable signal, and dropping the check would have lost it. So the check stays and gets precise. The entry carries `pathFilter: "snippets"`, and the check intersects the files changed between the pinned gitlink and the branch head with every file a `snippet=` quotes, opening an issue only when they overlap, naming the files. Verified both ways against real history: | Pin | Range | Result | |---|---|---| | `01edb5d8`, before a fix to the two `send_http_*` examples | 5 commits, 80 files | **reports**, naming `motoko/send_http_get/backend/main.mo` and `motoko/send_http_post/backend/main.mo` | | `b4fe175`, the pin this PR bumps from | 4 commits, 78 files, none quoted | **silent** | The second row is the point: #360 fired for a range touching nothing the docs quote, and would not fire now. Two implementation details worth a look. The snippet path is `<lang-dir>/<attribute>`, where the directory comes from the **fence language**, so `LANG_TO_DIR` is mirrored from `plugins/remark-snippet.mjs` rather than imported, because that plugin pulls in remark dependencies and the workflow installs none. The two must be kept in step, and an unmapped language throws rather than silently matching fewer files. Separately, when the comparison cannot be trusted, the API failing or truncating at its 300-file cap, the check reports instead of assuming nothing moved. The per-recipe split from #358 is unchanged. A batch release produces one issue per recipe, four here for a single upstream change. That is the cost of tracking them independently, and it is what made four stale version strings visible. ## Verification ``` npm run check:upstream # every entry current, exits 0 npm run build # passes npm run validate # 7 errors, unchanged from main ``` The 7 are all in `docs/references/internet-identity-spec.md`, which is generated. They clear when Internet Identity cuts its next dated release containing [dfinity/internet-identity#4284](dfinity/internet-identity#4284); our pin is already on the newest existing release tag, so there is nothing to sync until then. Tracked in #356. ## Known limits - The two CLI command fixes are verified against `icp 1.3.0` locally and against the published reference, but not executed end to end against a live project. - `snippet=` coverage depends on `LANG_TO_DIR` staying in step with the plugin. The two now match key for key, verified by parsing both maps rather than reading them, and an unmapped language fails loudly, which is the safe direction. It is still a duplicated constant: the plugin cannot be imported here because it pulls in remark dependencies the workflow does not install.
Closes #355.
.sources/held 16 submodules. Three are opened by the build; the rest were vendored so an agent could check a fact, or to supply skills through a symlink chain. Both have cheaper answers.Result: 3 submodules, 10 watched entries across 6 upstreams, 7 verified on demand, skills mirrored from the registry.
Kept, because the build opens them
motoko<motokoExamples>includesinternetidentitysync-ii-spec.mjs, which generates two reference pagesexamplesremark-snippet.mjs, which extractssnippet=codeThirteen go: eleven that existed only so an agent could check a fact, plus
icskillsanddotskills, which fed the skills symlink chain. The eleven appeared only in theAGENTS.mdsource table and.agents/submodule-bumping.md, and CI initializes justexamplesandmotoko, so nothing in the build referenced any of them.What is worth watching, and what is not
Watching everything meant a weekly check on repos the docs barely draw on. Measured footprint in
docs/decided each one:icp-climotoko-corecdk-rsicp-js-coreicp-cli-recipesicp-js-canistersThe other six became a
referencegroup:icp-cli-templates(linked, not restated),candid(a rarely moving spec),response-verification(two pages, both linking to docs.rs),chain-fusion-signer(7 mentions),papi(1 page),ic-pub-key(3 pages). They keep their entry and verify path so an agent knows where to look, but carry no pin and produce no issue: verify against the latest release on demand, since the surface is small enough that the next edit to those pages catches drift. Each entry records the footprint that decided it, so promotion back towatchedis a judgment someone can re-make.Every upstream is now checked exactly once
motoko,internetidentityexamplesupstream-releases.yml,vendoredmasterupstream-releases.yml,watched.claude/sync-ic-skills.shon session startexamplespreviously had no drift notification of any kind: it tracks a branch, and the only two workflows that could have noticed belong to the other two submodules. Issues carryupstream-syncplus a per-upstream label, and a run whose title already matches an open issue does nothing, so a repo that stays behind produces no weekly noise.Watching
.sources/upstream.jsonrecords per repo: the ref the docs are verified against, where its releases appear, which file's diff is the review payload, and what to re-check.scripts/check-upstream-releases.mjswrites an issue body per repo that moved (no token needed).npm run check:upstreamruns it locally.Agents verify against the pinned ref, so a review is reproducible and a page cannot document a flag from a release whose links have not been adapted:
raw.githubusercontent.comrather thangh api .../contents/...: the API returns base64 truncated at ~2.3 KB against 71 KB for the full file, and a truncated flag reference looks complete.Where releases appear differs per repo, and getting it wrong fails silently
trackreleaseicp-cli,motoko-core,icp-js-core, and one entry pericp-cli-recipesrecipecratecdk-rsnpmicp-js-canistersSeven defects found and fixed: three while building this, one from Copilot, three from review:
0.9.4beats0.20.1. Sorting is numeric-run aware.cdk-rswas pinned to0.20.1, which is not a tag but the published crate version, with the newest tag two minors behind. Against tags that pin could never be overtaken, so the repo governing every Rust code block would have reported "current" for ever. Areleasepin that is not among the matched tags is now a loud failure; every pin was audited.icp-js-sdk-docswas the wrong repo entirely. It is the js.icp.build delivery site, so a commit meant the docs site rebuilt. Replaced byicp-js-core(tags match npm) andicp-js-canisters(tags lag npm by two majors, so npm is the signal). Sibling repos, different correct answers.icp-cli-recipesmonitoring was a no-op for four of five recipes. Refs compare by numeric run, sorust-againststatic-site-compares textually and only the alphabetically-last prefix could ever be reported, while the entry read as watched. Each recipe now has its own entry, pin, issue and label, which immediately surfaces four releases the docs are behind.releasetrack. Acrateornpmpin in the wrong shape (v0.20.1for a crate that publishes0.20.1) compared as older for ever. Registry pins are now checked against the published version list, and crates.io readsmax_stable_versionso a prerelease is not reported as the latest release.summarizeChangecounted by set membership, so an added line that already appeared elsewhere in the file read as unchanged. It now counts occurrences:cli.mdv1.1.0 to v1.3.0 reports 14 added rather than 11.committrack ordered short SHAs with the version comparator, so an update whose SHA happened to sort lower read as "current". Demonstrated with pinef03698against head9f1e819. SHAs have no order, so it is now a prefix match, with the full SHA in links.commitis currently used by nothing: it exists for a repo with no releases at all, and after the reduction below no watched repo is in that state.First run: 9 of 11 have drifted
icp-cliv1.1.0→v1.3.0,motoko-corev2.4.0→v2.6.1,cdk-rs0.20.1→0.20.2,icp-js-corev5.4.0→v6.1.0,icp-js-canisters3.5.0→3.6.0, and four recipes:asset-canisterv2.2.1→v2.3.0,rustv3.3.0→v3.4.0,motokov5.0.0→v5.1.0,prebuiltv2.0.0→v2.1.0. Thestatic-siterecipe andexamplesare current.Three carry real content risk:
motoko-core(two minors ofmo:core),icp-js-core(a major bump,Agent.readStaterevamped),cdk-rs. Where a changelog exists it is the review payload, because "check every API signature" is unbounded while a changelog names the symbols to grep for.icp-cliis pinned at v1.1.0 deliberately: #354 moved the doc links to the 1.3 slug, but the commands were last verified against v1.1.0, so the first watch issue carries that pass rather than hiding it.Skills
.claude/sync-ic-skills.shonSessionStart, byte-identical to the scriptdfinity/examplesruns, replaces two submodules and a double symlink chain. Coverage rises 16 → 29 and corrects two table entries pointing at skills that no longer exist upstream:asset-canister→static-site(which covers the legacy recipe and the migration) andvetkd→vetkeys.No symlinks, in either direction: Claude finds a skill whether it is a directory or a link, no other harness auto-discovers any path, and for the synced 29 a symlink is actively wrong because the sync consumes anything at a name the registry publishes (verified in a sandbox). AGENTS.md states the non-Claude path instead: fetch the registry index by URL, explicitly not
.claude/skills/, which is gitignored and empty in a fresh clone.icp-brand-design,icp-brand-voice, andtechnical-documentationstay committed. The last is not on the registry and changed once since our pin, only to relicenseAGPL-3.0-only→ MIT. That license is why it was a submodule; MIT still requires the notice to travel, so its text sits in the skill directory and a new rootNOTICErecords the attribution.Instructions updated
AGENTS.md(source material, CLI verification, the1.3slug no longer derived from a submodule pin, skills, key directories),.agents/upstream-tracking.mdreplacingsubmodule-bumping.md, andCONTRIBUTING.md.Worth challenging
examplescosts 265 MB for one page today (6 snippets, 2 examples). Keeping it bets on<CodeExample>spreading.ic-cdk-timersandic-cdk-executorversion separately fromic-cdkand are not tracked individually; theaffectsnote tells a reviewer to check them.setup.shnow prunes stale.sources/directories. An existing clone keeps them after a submodule is removed, and a frozen.sources/icp-cli/looks authoritative while being exactly what the verify-at-the-pinned-ref rule exists to prevent. Only untracked directories are touched.referencegroup trades a prompt for less noise. If nobody edits those pages, drift sits there unreported. That is the deliberate bet: six weekly checks on repos with a 1-to-3 page footprint cost more attention than they return.Found along the way, not fixed here
ic-cdkis pinned to four different versions across the docs:0.19in 8 places, plus0.20,0.17, and0.17.1. The published crate is 0.20.2. That is a content bug rather than infrastructure, so it belongs with thecdk-rswatch issue rather than in this PR.Follow-up
#279 is unblocked: of the 11 repos its "keep as-is" bucket names, only
examplesis still a submodule, andaffectsnow carries the upstream-to-pages mapping.After merge: trigger the workflow once so the drifts land as issues, batch the pin-only bumps, then handle
icp-cliandmotoko-coreas their own PRs.Merge order
These three are independent in intent but share one file, so they have a preferred order: #354, then #357, then #358.
validate --allviolationsscripts/validate.js,data-persistence.mdx,chain-key-tokens.mdx; no overlap with the other two. Merging it here dropsvalidate --allonmainfrom 11 errors to 7..sources/reductiondocs/guides/canister-management/lifecycle.mdxwith #354 (different lines: a CLI link there, a stale.sources/pointer here). Last means at most one rebase, on a cleaner validate baseline.The remaining 7 errors after #357 are all in
docs/references/internet-identity-spec.md, which is generated bysync-ii-spec.mjs. They clear when dfinity/internet-identity#4284 merges and the next spec sync runs; that PR is independent of the order here.