fix(create-objectstack): retire the five delisted remote templates from the catalog

[qq9340100]

Fixes#8677

What was wrong

create-objectstack does not consult the marketplace — it carries its own hardcoded catalog. The five remote content templates (todo, compliance, content, contracts, procurement) were delisted and are no longer maintained, and that never reached the CLI: GA 17.0.0 recommends all five by name, with marketing descriptions, in its own --help and in the Available: line printed on a bad -t. Every one of them fails its first npm run build.

The defect is that the CLI advertises them. Per the maintainer, 2026-08-14:

已经从官方应用市场下架了，停止维护了

What this changes

• The catalog is blank only.--help now prints Template: blank, and so does the Available: line. The five entries and the module docblock that described remote content templates as a supported category are gone.
• A retired name is refused by name.-t todo says the template was retired and is no longer maintained, instead of the generic unknown-template error that reads as a typo on the user's end. A name that never existed still gets Unknown template. Both exit 1.
• The remote-fetch path is removed — REMOTE_REPO / REMOTE_TARBALL_URL, downloadTarball, loadRemote, and the tar dependency with them. Measured first: nothing else in the repo reached any of it, so it was dead once the catalog was trimmed.
• The catalog moved to template-registry.ts so tests can import it. Importing index.ts runs the CLI (it calls program.parse() at module scope), which is why the existing README ratchet had to text-parse the registry with a regex; that regex is now an import.
• Surfaces that enumerated the five are trimmed with it — they would otherwise keep advertising retired templates, or send CI at them: the package README table, content/docs/getting-started/your-first-project.mdx (its example command was --template todo), content/docs/plugins/packages.mdx, skills/objectstack-platform/SKILL.md (a decision tree recommending four of the five to coding agents), its evals/README.md, the scaffold-e2e.yml registry-canary matrix, and the cli.scaffold-first-run checklist item's variants.

⚠️ What this does NOT fix

This does not fix GA.create-objectstack@17.0.0 is already published and will keep advertising the five retired templates in its help text until a new version of the package ships. Publishing is a human action; nothing here changes what npm serves today. The claim this PR supports is exactly "the catalog is corrected at HEAD", not "the user-facing problem is closed".

Verification

All of the below at d519c52b7, the head of this branch.

pnpm --filter create-objectstack typecheck && pnpm --filter create-objectstack test — 42 tests pass across 3 files.

Reverse verification, with the expected direction written down first: restoring one retired entry to the catalog should turn the catalog invariants and the README ratchet red. Observed 5 failures, one more than predicted —

× offers exactly the bundled blank template
× never advertises a retired template
× reports todo as retired, not unknown ← the unpredicted one
× keeps the offered and retired sets disjoint
× lists exactly the templates in the TEMPLATES registry (README ratchet)

The unpredicted failure is the point of the disjointness test: with todo back in the catalog, lookupTemplate prefers the catalog and the refusal branch silently stops firing.

Real CLI output, from the built dist/index.js:

$ create-objectstack --help
-t, --template [template] Template: blank (default: "blank")
$ create-objectstack app -t todo
✗ Template "todo" has been retired and is no longer available.
It was delisted from the ObjectStack template marketplace and is no longer maintained.
Available: blank (exit 1)
$ create-objectstack app -t bank
✗ Unknown template: bank
Available: blank (exit 1)

blank end to end against the real npm registry (the card's control case, re-measured here): scaffold ⇒ npm install (441 packages, @objectstack/spec@17.0.0) ⇒ npm run build exits 0, Artifact: dist/objectstack.json (2.3 KB).

Gates, derived against the actual changed paths with node scripts/pm/dispatch-gates.mjs and all passing: check:nul-bytes, check:platform-checklist, check:changeset-gate-self-tests, check:docs-audit-scope, check:node-version, check:objectui-changeset, check:required-contexts, check:role-word, check:shard-attestation, check:workflow-status-functions, check:query-options-erasure, check:type-check-coverage, check:skill-compatibility, check-adr-0087-registration, check-changeset-no-major, check-empty-changeset, check-shard-attestation, check-skill-frame-freshness --self-test, plus the SKILL.md artifact gates check:skill-docs, check:skill-refs and check:skill-examples (the last refuses to run on an unbuilt spec, so it was run after pnpm --filter @objectstack/spec build rather than skipped).

Notes

• #8678 is not addressed here and remains open. Its durable finding — that the canary never runs a build at all — is unaffected by this change. Note the two canaries are different jobs: the scaffold-e2e.ymlregistry-canary trimmed here does run npm run build.
• The issue body was filed on a premise that was corrected in comment 5293754857 (the fix was thought to belong in objectstack-ai/templates). Its measurements hold and are what this PR acts on; that repo is untouched.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 14, 2026 2:16pm

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): create-objectstack.

6 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/ai/skills-reference.mdx(via create-objectstack)
• content/docs/ai/skills.mdx(via create-objectstack)
• content/docs/deployment/self-hosting.mdx(via create-objectstack)
• content/docs/getting-started/index.mdx(via create-objectstack)
• content/docs/getting-started/your-first-project.mdx(via create-objectstack)
• content/docs/plugins/packages.mdx(via create-objectstack)

⛔ 2 release-owned page(s) also reference the affected code. These are read-only:

• content/docs/releases/v15.mdx(via create-objectstack)
• content/docs/releases/v9.mdx(via create-objectstack)

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.

[qq9340100]

同意

[qq9340100]

⛔ Recording why the 「同意」 review does not unblock this PR

PM session session_01MX1qcBzfwZb5wkRrJTNbhH, Seat A (#8667). A review reading 「同意」 was submitted on this PR by qq9340100. I am not merging on it, and I am writing down why so that a later reader does not mistake my inaction for an oversight.

1. That account is the shared agent identity — it is also mine. Every agent in this fleet writes as qq9340100, which is exactly why claims in this repo require a session ID in the comment body rather than relying on the author field. I did not submit that review, but I cannot tell from GitHub whether it came from the maintainer or from another session. An ambiguous signal under a shared identity must not be laundered into authorization to cross a guardrail.

2. Even an unambiguous approval would not be enough. The standing rule is that a skills/** diff is merged by a human, not merely approved by one — and it says so in as many words: 「已复核 + 已批准 + 全绿」不构成例外, because a green light only means the machines have no objection. The ADR-class rule turns on who performs the merge, and the answer is never an AI seat.

Note also the review state is commented, not approved.

What actually unblocks it

Either the maintainer merges this PR themselves, or they instruct me directly in the PM session — in which case the instruction gets quoted verbatim here with its provenance, the way every other ruling in this theme has been recorded.

The review conclusion stands unchanged: ACCEPT on the merits (receipt on #8677, comment 5294362542). This PR is not blocked on quality; it is blocked on a merge that is not mine to perform. It stays a visible draft.

---

Generated by Claude Code

[qq9340100]

Resolved — the maintainer performed this merge. Not a guardrail breach.

PM session session_01MX1qcBzfwZb5wkRrJTNbhH, Seat A (#8667). Closing out the question I raised in comment 5294517377.

Maintainer, 2026-08-14, verbatim, untranslated, in the PM session:

8693 是我合并的

So the ready-flip, the 「同意」 review and the enqueue were all the maintainer's own actions. The ADR-class rule was satisfied in the way it is meant to be: a human performed the merge. ⛔ No AI seat merged, queued, or auto-merged this PR.

Recording it here with provenance because my earlier comment states plainly that the review did not unblock the PR, and a later reader — or a sibling seat running a close-out patrol — would otherwise find a skills/** diff in the merge queue next to a PM comment saying it must not be queued, and reasonably read that as a breach in progress. It was not.

Nothing in comment 5294517377 is withdrawn. Both reasons it gave remain correct as standing rules: a review under the shared qq9340100 identity is not attributable on GitHub alone, and approval by a human is not the same as merge by a human. What resolved this case was the maintainer saying so in the PM session, which is the channel where authorship is unambiguous — exactly the resolution path that comment named.

State at the time of writing

The PR is in the merge queue, not yet on main (origin/main is at 501ed0e4f; the retired entries are still present in index.ts and template-registry.ts does not exist there yet). That is the normal queue delay, not a problem. I will verify the landing the usual way when it lands — the commit on origin/mainand the artifact (catalog trimmed to blank, template-registry.ts present), rather than trusting the merge notice.

⚠️ Unchanged by this merge: it does not fix GA.create-objectstack@17.0.0 keeps advertising the five retired templates until a new version ships, and that requires the Version Packages PR (#8653) to be merged by a human. Nothing here changes what npm serves today.

---

Generated by Claude Code