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

[qq9340100]

Symptom

Every one of the five published remote templates fails its very first npm run build on the GA create-objectstack@17.0.0. Measured 2026-08-14 against the real npm registry (latest = 17.0.0, published 2026-08-14T07:59:14Z), Node 22.22.2 / npm 10.9.7.

npx -y create-objectstack@latest canary-app -t <template> --skip-skills --skip-install
cd canary-app && npm install && npm run build

template	scaffold	npm install	npm run build
todo	0	0	2
compliance	0	0	2
content	0	0	2
contracts	0	0	2
procurement	0	0	2
blank (control, bundled)	0	0	0

The blank control produces dist/objectstack.json (2.3 KB) normally, so the toolchain, the installed @objectstack/spec@17.0.0 and the build path are all healthy. The failure is isolated to remote template content.

Root cause

All five remote templates still author two enable flags that @objectstack/spec removed in the 16.x line (ADR-0049, #2377/#3207). Installed spec is 17.0.0, whose enable is a closed vocabulary, so the metadata is rejected at build. Verbatim, identical on all five:

✗ [
 {
 "code": "unrecognized_keys",
 "keys": [ "trash", "mru" ],
 "path": [ "enable" ],
 "message": "Unrecognized key(s) on `enable`: `trash`, `mru`. ..."
 }
]

The offending source ships in the scaffold, e.g. for todo at src/objects/todo_task.object.ts:102-103:

 trash: true,
 mru: true,

The error message names its own remedy: os migrate meta --from 16 rewrites existing sources automatically.

Where the fix lands

Not in this repo. The remote templates are fetched from a separate repository — packages/create-objectstack/src/index.ts:59-60:

const REMOTE_REPO = 'objectstack-ai/templates';
const REMOTE_BRANCH = 'main';

so the content fix belongs in objectstack-ai/templates@main. Filed here because this repo owns create-objectstack, the release process and the canary gate that should have caught it. Re-route or mirror as triage sees fit.

This is NOT the #7644 defect — that one is fixed

#7644 tracked a namespace-rewrite defect on 16.1.0 (object literals keeping the template's own prefix). That defect is verified fixed in 17.0.0 and is not what fails here. Measured structurally, independent of validation ordering: across all five templates, top-level object-name literals carrying no canary_app_ prefix = 0, and stale tpl_* tokens anywhere under src/ = none. Config reads namespace: 'canary_app' and literals read canary_app_task / canary_app_label etc. Zero occurrences of namespace prefix in any of the five build logs.

So the user-visible headline of #7644 ("non-blank remote templates fail first npm run build") still reproduces on GA 17.0.0, but for an entirely different and unrelated cause. Verification detail on #7644.

Severity

First-hour, follow-the-docs failure on the GA release: a new user picking any non-blank template gets a project whose first build exits 2. Same blocking class (④) that #7644 carried.

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; its own defect is fixed)
• P0:5 个已发布模板对真实新用户是坏的 —— 脚手架的对象名前缀改写对所有远程模板静默跳过,夜间金丝雀连红 20 次无人察觉 #4926 / fix(devx): init-service 门禁认全部服务访问器,不只 getService (#4835) #4902 (closed predecessors, different cause)
• ADR-0049, [11.0][A2] Remove dead author-facing metadata properties (ADR-0049 enforce-or-remove) #2377 / Remove dead object enable.trash / enable.mru capability flags (ADR-0049 enforce-or-remove) #3207 (the removals), Object-level workflows: [...] (and any unknown ObjectSchema key) is silently stripped at build — no error/warning (ADR-0032 'no silent failure', metadata layer) #1535 / [spec/cli] 对象 enable.files/trackHistory/activities/feeds 为 dead property:schema 接受、liveness 仅告警不拦 #2707 (why enable is closed)

---

Generated by Claude Code

[qq9340100]

⚠️ Correction — my premise was wrong, and the real defect is different (and lands HERE, not in the templates repo)

PM session session_01MX1qcBzfwZb5wkRrJTNbhH, Seat A (#8667). Correcting a card I filed myself two hours ago.

Maintainer, 2026-08-14, verbatim, untranslated:

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

The five templates are delisted from the marketplace and no longer maintained. I did not know that, and the card was written as though they were live product.

What that invalidates, and what it does not

Invalidated: "the content fix belongs in objectstack-ai/templates@main." ⛔ Nobody should fix those templates. They are retired — running os migrate meta --from 16 over them would be maintaining something that was deliberately stopped.

Not invalidated: the measurements. All five still fail first npm run build on GA create-objectstack@17.0.0 with unrecognized_keys: [trash, mru], and blank still passes. Those readings stand; it is the conclusion drawn from them that was wrong.

The actual defect — and it is in THIS repo

The delisting never reached the CLI. create-objectstack does not consult the marketplace at all: it carries its own hardcoded catalog, verified on origin/main at packages/create-objectstack/src/index.ts:75-100:

const TEMPLATES: Record<string, TemplateInfo> = {
 blank: { source: { kind: 'bundled', dir: 'blank' } },
 todo: { source: { kind: 'remote', pkg: 'todo' } },
 compliance: { source: { kind: 'remote', pkg: 'compliance' } },
 content: { source: { kind: 'remote', pkg: 'content' } },
 contracts: { source: { kind: 'remote', pkg: 'contracts' } },
 procurement: { source: { kind: 'remote', pkg: 'procurement' } },
};

And that catalog is shown to users, not merely accepted:

• index.ts:388 — the usage text prints Template: blank, todo, compliance, content, contracts, procurement
• index.ts:407 — an invalid -t prints Available: <the same six>

⇒ GA create-objectstack@17.0.0 advertises five retired templates in its own --help, each with a marketing description, and every one of them fails on first build. A user does not need to visit the marketplace to be sent down this path — the CLI offers it to them directly.

Restated

• Before: "five published templates are broken; fix the content in another repo." Wrong — they are not published any more, and their content should not be fixed.
• After: "the CLI still ships and advertises five retired templates." The fix is to remove the retired entries from TEMPLATES (and the docblock at :9-17 that describes them as a supported category), leaving blank.

That is a small, mechanical change in packages/create-objectstack ⇒ domain:cli, this repo, and dispatchable by this seat. The third-repo boundary problem I escalated to the maintainer does not exist — it was an artefact of my wrong premise.

One question for whoever takes it, not to be answered by guessing

Whether the retired entries are deleted or kept with a "retired" refusal that names the deprecation is a real choice — deleting makes -t todo an unknown-template error, which is honest but tells a returning user nothing about why. That is a small product call and should be stated in the PR rather than decided by whichever is easier to type.

Knock-on to #8678

#8678 (the registry-canary scaffolds only blank and never runs npm run build) is partly overtaken: its "blind to remote-template breakage" framing loses force once no remote templates remain. Its core finding survives unchanged and is the durable one — the canary never runs a build at all, so it cannot catch a broken blank either. Re-framed there.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 2
Session: session_01MX1qcBzfwZb5wkRrJTNbhH
Branch: claude/issue-8677-retire-remote-template-catalog
Worktree: objectstack-issue-8677
Domain: domain:cli
File surface: packages/create-objectstack/src/index.ts (the TEMPLATES catalog, the module docblock at :9-17, and the two places the catalog is printed — :388, :407), plus tests (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus
Serial constraints cleared: nothing in flight touches packages/create-objectstack. Siblings: #8149 (plugin-email/messaging), #8155 (service-datasource), #8504 (packages/cli — a different package from packages/create-objectstack, verified).

Entering the queue on a maintainer ruling, 2026-08-14, verbatim, untranslated:

这个问题要解决 create-objectstack@17.0.0 仍然在自己的帮助文本里推荐五个已停止维护的模板

That is the approval the theme's workability rule requires; target:v17 applied on it. It follows the maintainer's prior statement that the five remote templates are delisted and unmaintained (「已经从官方应用市场下架了，停止维护了」).

⚠️ Read the correction comment (5293754857) before the card body — the body was written on a wrong premise (that the fix belonged in objectstack-ai/templates). The measurements in it stand; the conclusion does not. The fix lands here.

PM decision, so the dev does not have to guess

Two things, and I am deciding them rather than passing the fork down:

1. Remove the five remote entries from TEMPLATES. That is the deliverable — the help text must stop offering them.
2. Keep a named refusal for the five retired names, so -t todo answers "that template was retired" rather than the generic unknown-template error. A returning user with todo in a script or an old doc otherwise gets a message that tells them nothing about what happened. This is a handful of lines and I judge it worth the small permanent obligation; if the dev measures that the generic path already says something adequate, it may drop this with the reading shown.

⛔ Not in scope: repairing the templates' content, or anything in objectstack-ai/templates. They are retired.

⚠️ The honest limit on what this fix achieves

Landing this on main does not fix GA. create-objectstack@17.0.0 is already published and will keep advertising those templates until a new version ships — and publishing is a human action that no seat may take. So the correct claim at merge is "the catalog is corrected at HEAD", never "GA is fixed". Whoever writes the PR body should say so plainly rather than letting the changeset imply the user-facing problem is closed.

---

Generated by Claude Code