registry-canary structurally cannot catch remote-template breakage — it scaffolds only `blank` and never runs `npm run build`; it was green over the #7644 defect

[qq9340100]

The gap

The registry-canary job (.github/workflows/publish-smoke.yml, SMOKE_MODE=registry) is the gate two separate cards lean on to prove that a published create-objectstack scaffolds a working project. It cannot see the failure class it is being trusted for, for two independent reasons.

1. It only ever scaffolds the bundled blank template

scripts/publish-smoke.sh:210:

(cd "$SMOKE_ROOT" && npx -y create-objectstack@latest "$APP_NAME" --skip-install --skip-skills)

No -t is passed, and create-objectstack's template option defaults to 'blank' (packages/create-objectstack/src/index.ts:386-390). blank is a bundled template (source: { kind: 'bundled' }); the five templates that break are remote (kind: 'remote', fetched from objectstack-ai/templates). The remote path — manifest handling, identity rewrite, template content vs current spec — is never exercised.

This is not incidental: #7644's own body records that blank was the one template clean end to end while four others failed.

2. It never runs npm run build

After install the script goes straight to objectstack dev --fresh (publish-smoke.sh:228-232). npm run build — the exact command that exits 2 in #7644 and #8677 — is never invoked in either smoke mode.

Measured proof the gate is blind, not merely narrow

The most recent scheduled registry-canary run before the v17 cut:

run #1932 event=schedule conclusion=success 2026-08-10T05:11:25Z
https://github.com/objectstack-ai/objectstack/actions/runs/31357804459

At that moment npm latest was 16.1.0 — the version #7644 documents as failing first npm run build on todo, compliance, content and contracts. The canary concluded success over a release that was broken on four of six templates. A green reading from this job is therefore not evidence about remote templates in either direction.

The workflow header says the job "Opens/refreshes an issue on failure", which makes the silence actively misleading: no failure issue exists, and there is nothing wrong with the job — it passed honestly on the one template it tests.

Why this matters beyond one card

create-objectstack is the first command a new user runs. Both breakages found so far (#7644's namespace rewrite on 16.1.0, #8677's enable.trash/enable.mru on 17.0.0) are first-hour, follow-the-docs failures on a GA release, and this gate — the only automated one pointed at the published package — was green through both. packages/create-objectstack/src/rewrite-identity.ts's own header records the earlier #4902 incident in which all five published remote templates were broken at once, which is precisely the shape this canary is meant to make impossible to miss.

Suggested direction (not a decision — flagging the trade-off)

The obvious fix is to loop the canary over every entry in the template registry and run npm run build on each. Two real costs to weigh: runtime (five extra installs per run) and a dependency on objectstack-ai/templates staying green, which makes this repo's weekly job red for another repo's content. A cheaper middle option is one remote template plus npm run build, which would have caught both incidents. Whoever picks this up should also decide whether the project name must differ from the template's own namespace — smoke-app does differ today, which is the property #7644's defect needed to reproduce, and it is currently accidental rather than asserted.

Related

• [finding] create-objectstack: non-blank remote templates fail first npm run build on published 16.1.0 — fix is at HEAD, needs 17.0.0 release + canary verification #7644 (verification card this was found from)
• All five published remote templates fail first npm run build on GA create-objectstack@17.0.0 — templates still author enable.trash / enable.mru, removed in the 16.x line #8677 (the live GA breakage this gate did not catch)
• fix(devx): init-service 门禁认全部服务访问器,不只 getService (#4835) #4902 / P0:5 个已发布模板对真实新用户是坏的 —— 脚手架的对象名前缀改写对所有远程模板静默跳过,夜间金丝雀连红 20 次无人察觉 #4926 (the prior incident the fix's header records)
• Fresh projects: every auth endpoint returns 500 "Cannot set properties of undefined (setting 'modelName')" — fixed in 15.1.1 #3091 / fix(plugin-auth): pin better-auth family to 1.7.0-rc.1 — fresh 15.1.0 projects 500 on every auth endpoint #3085 (the failure class the workflow was built for)

---

Generated by Claude Code

[qq9340100]

Re-framing after a maintainer correction on the sibling card

PM session session_01MX1qcBzfwZb5wkRrJTNbhH, Seat A (#8667).

Maintainer, 2026-08-14, verbatim, untranslated, on #8677:

8677 你从哪里找到的5个模版，已经从官方应用市场下架了，停止维护了。

The five remote templates are delisted and unmaintained. That changes this card's emphasis, so recording it before anyone works from the original framing.

Half of this card is overtaken

The "blind to remote-template breakage" argument loses its force: once the retired entries come out of create-objectstack's hardcoded catalog (the corrected #8677), there are no remote templates left for a canary to be blind to. ⛔ Do not implement -t coverage across five templates that are going away.

The half that survives is the one that mattered

The canary never runs npm run build at all. That is independent of which templates exist:

• it scaffolds, and stops;
• so it cannot catch a broken blank either — the one template that is staying;
• and blank is the entire first-run experience for every new user once the catalog is trimmed.

The evidence for the blindness is unchanged and does not depend on the retired templates: run #1932 concluded success on 2026-08-10 while npm latest was a create-objectstack that failed first build on four templates. A green canary over a scaffold-only check is a green that means very little.

Restated ask

Make the registry canary run the thing a user runs: npx create-objectstack@latest <name> → npm install → npm run build, asserting exit 0. Scope it to blank — that is the supported surface after #8677.

⚠️ Worth stating for whoever takes it: this is the fourth occurrence of the "published scaffold is broken and nobody noticed" class (#4902 → #4926 → #7644 → this round). Every previous fix repaired the content; none repaired the detector. That is why this card is the durable one of the pair.

Still nominated rather than labelled — it needs target:v17 from the maintainer before it enters the queue.

---

Generated by Claude Code

[hotlong]

Triage: gate/CI scripting ⇒ domain:devx. Type Task, queued.

Rationale: the fix strengthens a canary gate (scaffold breadth + an actual npm run build), which is the devx lane's scripts/-and-gates surface rather than the CLI package the canary exercises.

Not escalated: strengthening a gate that was green over a real defect (#7644) restores the gate's declared purpose. No accept-set change, no human floor — gate weakening is the direction that needs a maintainer; this is the opposite.

The load-bearing claim is that the canary "was green over the #7644 defect". That is what makes this worth doing rather than tidy: verify it first, and make the new coverage fail against the #7644 state before it passes against main. A canary extension that has never been shown to go red is the same defect one layer up.

Size/model suggestion: S–M, opus.

---

Generated by Claude Code