plugin-spec.mdx's PLUGIN MANIFEST examples still pin @objectstack/core at ^2.0.0 (kernel-resolved surface, not the npm one #17378 repaired) — with the kernel-resolution leg unmeasured

[claude]

Surfaced by #17378's dev as an out_of_scope_findings entry and reported rather than swept into that PR — correctly, because it is a different surface. ⛔ Unlabelled for domain:* and ungraded; routing and grading are triage's. ⛔ The filer did not dedupe; dedupe words at the bottom.

Two surfaces on one page, and only one of them was repaired

content/docs/protocol/kernel/plugin-spec.mdx carries version ranges in two different roles:

surface	resolved by	status
the npm package.json example (devDependencies)	npm	✅ repaired by #17378 / PR #18186 (^2.0.0 → ^17.0.0 on @objectstack/cli and @objectstack/core)
the plugin manifest examples — ManifestSchema.dependencies, a Record<packageId, versionRange>	the kernel, ⛔ not npm	⚠️ untouched

The manifest examples still pin '@objectstack/core': '^2.0.0' (two sites), and a third site teaches '2.0.0' as a deliberate exact pin in a pin-vs-caret lesson.

@objectstack/core publishes 2.0.0–2.0.7 and its current version is 17.4.0 — the same fifteen-major gap #17378 measured.

⛔ The load-bearing leg is UNMEASURED, and is named so nobody inherits a guess

Does the kernel actually resolve @objectstack/core as a manifest dependency at plugin load?

• If it does → copying the example fails at load, and this is class (a).
• If it does not → it is an inert wrong number, and it belongs in a PR's acceptance notes rather than in a card.

⛔ Neither #17378's dev nor the domain:devx seat measured this. ⛔ Do not grade this card as (a) on the strength of the sibling card — the sibling's surface is npm, which is a different resolver with a different failure mode.

⚠️ The third site is a CONTENT decision, not a mechanical repair

The '2.0.0' exact pin is the worked example of a lesson about pinning versus caret ranges. Changing the number without reading the lesson around it can leave the prose arguing for one thing and demonstrating another. ⛔ Whoever takes this reads that section before touching the number.

Suggested shape (⛔ a proposal, not a prescription)

1. Establish the kernel-resolution leg first — it decides whether this is a bug or a tidy-up, and therefore what the acceptance bar is.
2. Then repair the two caret sites to whatever the kernel actually accepts for a 17.x line.
3. Treat the pin-vs-caret lesson's number separately, with its prose.

Acceptance

1. The kernel-resolution question is answered with a reading (a call site, or a test that loads a manifest with a dependencies entry), ⛔ not reasoned from the npm side.
2. Any number changed is consistent with what that reading says the kernel accepts, with a firing control that the probe discriminates.
3. The pin-vs-caret section still argues and demonstrates the same thing after the edit.

⚠️ Related context, ⛔ not asserted as duplicates: #17378 (the npm surface, repaired) and #16756 (the typescript key on the adjacent line). ⚠️ The #15952 epic (pm:epic) is recorded as holding this page — check whether this belongs inside that subtree before routing it to a lane.

Dedupe words

plugin-spec manifest dependencies · objectstack/core caret 2.0.0 · kernel resolver versionRange · ManifestSchema dependencies · pin vs caret lesson

---

Generated by Claude Code