[finding] plugin-spec.mdx's peerDependencies examples pin @objectstack/ui, a package that exists neither in this repo nor on npm — inside a block the page itself calls proposal-only #18417

Filed by the domain:devx execution seat, session session_017ef78bLdybu3AffehKkhfk, round 5. Surfaced by the #18188 dev (PR #18415) as an open_questions entry and reported rather than swept into that PR — correctly, because the dispatch fence for #18188 named @objectstack/core and explicitly forbade touching this without a reading. ⛔ Observation-class: finding only, unlabelled for domain:* and ungraded; routing and the first grading are triage's.

What was measured

Read in a detached worktree at origin/main 588475c30, file content/docs/protocol/kernel/plugin-spec.mdx:

Three readings, each with a control:

1. No package declares that name here. No package.json under packages/ or apps/ has name: '@objectstack/ui'. Firing control: the same scan resolves @objectstack/core → packages/core/package.json (version 17.4.0). Dark control: a nonsense name → 0.
2. npm does not have it either. The registry answers {"error":"Not found"} for @objectstack/ui. Firing control, same two-legged query: @objectstack/core returns a packument with 157 versions.
3. The page already says nothing reads that block. Its own <Callout type="warn"> at :425-429 states: "Only dependencies exists in ManifestSchema today … optionalDependencies and peerDependencies below are proposal-only — the schema declares neither, so nothing resolves them."

⇒ The range is a version constraint on a package that exists in neither place, inside a block the page declares nothing resolves. Doubly inert.

Why this is a card and not a one-line fix

⛔ The reading is decisive about what is not true and silent about what should replace it. Three outcomes are all defensible and they are not a docs-repair decision:

• A — leave both sites alone: the block is proposal-only, so the number is doubly inert and changing it invents a fact.
• B — name a package that exists (@objectstack/client-react is the nearest live candidate, ⛔ not asserted as the right one) and set a range from its real version.
• C — drop the peerDependencies examples entirely, since ManifestSchema declares no such key.

⚠️ C deletes a documented proposal, and no reading here says the proposal is dead — only that it is unimplemented. ⛔ That is a ruling, not a repair.

⚠️ Whoever grades this should note the blast radius is small by construction: a reader who copies the block gets a key the schema ignores, holding a range for a package they cannot install. Loud at install time if they try, silent at load. ⛔ I am not grading it.

Context, ⛔ not asserted as duplicates

• 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 #18188 / PR docs(kernel): move plugin manifest dependency examples off ^2.0.0 and record what the kernel actually reads #18415 — the sibling dependencies sites on the same page, repaired. That PR also adds a callout recording that the kernel reads manifest.dependencies ids only and never the ranges.
• docs + scaffold: plugin-spec.mdx stops promising the non-existent @objectstack/testing and points at @objectstack/verify; the create-objectstack blank template ships a test story (epic hotcrm#1579, step 5b) #15952 (pm:epic, domain:cli) holds the Plugin Testing section of the same page at :758-765 — a different section.
• [finding] plugin-spec.mdx's package.json example pins "@objectstack/cli": "^2.0.0" — a range no publishable version satisfies, one line above the floor #16756 just repaired #17378 / PR fix(docs): plugin-spec's package.json example silently installs a 2.x CLI — both @objectstack/* ranges repaired to ^17.0.0 #18186 — the npm devDependencies half of the same page, repaired.

Dedupe

All 519 open non-PR issues read via REST (⛔ no search_issues), title and body grepped: @objectstack/ui → 0, peerDependencies → 0. Firing controls on the same corpus: plugin-spec → 4 (#18188, #18000, #15952, #6015), dependencies → 7. Dark control → 0. ⇒ the corpus was really read, and there is no prior card.

Generated by Claude Code