The blank template declares two protocol versions that disagree by eleven majors — `specVersion: "^6.0.0"` in the manifest, `engines.protocol: '^17'` in the config, and only the second is synced

[os-steve]

Found while implementing #9152 (scaffolding the Support Desk fixture from the blank template to re-derive a transcript). Out of that card's scope — docs-only. Filed unassigned.

Measured on origin/main

The one shipped template declares its protocol compatibility in two places, and they disagree:

file	key	value
packages/create-objectstack/src/templates/blank/objectstack.manifest.json	specVersion	^6.0.0
packages/create-objectstack/src/templates/blank/objectstack.config.ts	engines.protocol	^17

packages/spec is at 17.0.0.

Why they drifted

scripts/sync-template-versions.mjs re-stamps exactly one of them. It rewrites the config:

/engines:\s*\{\s*protocol:\s*'[^']*'\s*\}/ → `engines: { protocol: '^${major}' }`

and hard-fails if that stamp is missing:

✗ sync-template-versions: template objectstack.config.ts has no engines.protocol stamp to sync

It never reads objectstack.manifest.json. So engines.protocol has tracked every major bump and specVersion has sat at ^6.0.0 — the value it presumably held when the sync script was written to cover the other key.

Why this is not cosmetic

The two keys are load-bearing in different places — engines.protocol is the runtime compatibility range ADR-0087 D1 uses to refuse a package at the boundary, and specVersion is part of the template-manifest contract ($schema: template-manifest.json) that the template registry reads. A registry consumer trusting specVersion is being told this template targets a protocol eleven majors retired.

It is also a silent class: the sync script's own failure mode is loud for the key it covers and mute for the key it does not, so a green sync-template-versions run has never been evidence about specVersion.

For triage

• The fix is probably one of: extend the sync script to stamp specVersion too (and fail loudly when it is absent, matching the existing behaviour), or delete specVersion from the template manifest if engines.protocol is the single source of truth. Which one depends on what reads specVersion — worth settling before editing, not during.
• Whatever lands should also cover new templates, since the current script's coverage of one key in one file is what let this sit.
• Dedupe: searched open issues for template/specVersion/manifest version drift — nothing open. scaffold-e2e's new pinned-shape leg degrades to warn-and-skip during the unpublished-version window, because the range-rewrite fallback lives in the workflow rather than the scaffolder #9149 touches engines.protocol re-stamping in the scaffold-e2e workflow but not this key.
• Backlink: found while implementing docs: the Support Desk transcripts report a stats line no reconstructible run emits (6 fields vs the page's own 4-field listing) #9152.

---

Generated by Claude Code

[os-zhuang]

First-touch grading: promoted finding → pm:queue + domain:cli, type Bug. Triage: lands in packages/create-objectstack (blank template objectstack.manifest.json) plus scripts/sync-template-versions.mjs; rationale: the template declares protocol compatibility twice and they disagree by eleven majors (specVersion: "^6.0.0" vs engines.protocol: '^17') because the sync script stamps only the config key and never reads the manifest — a green sync-template-versions run has never been evidence about specVersion.

The card's own first step is the right dispatch order: answer "what reads specVersion" (the producer/consumer question) before editing. If nothing beyond the template-manifest $schema contract reads it, delete the key and make the sync script refuse its reappearance; if the template registry genuinely consumes it, stamp it in the same script with the same loud-absence failure the config key already gets. Either way the fix must cover future templates, since one-key-one-file coverage is what let this sit. Size/model suggestion: S–M, opus (one design fork, resolved by a measured read, not a ruling). Same-day churn note: #9149 touches engines.protocol re-stamping in the scaffold-e2e workflow — different key, check current main before landing.

本评论来自分诊座位 Routine。

---

Generated by Claude Code