create-objectstack 17.0.0 → 17.2.0

package/CHANGELOG.md

@@ -1,5 +1,521 @@
 # create-objectstack
 
+## 17.2.0
+
+### Minor Changes
+
+- 5a616d5: `create-objectstack` now closes with a "Created files" summary derived from a
+  walk of the finished project directory, so it names everything the run wrote —
+  including the files written after the template copy (#10323).
+  
+  The old summary was the template copy's own list, printed before
+  `<pm> install` and before `npx skills add`. Measured against published
+  `create-objectstack@17.1.0` (`create-objectstack demo-app`, then a full walk of
+  the result): 12 entries printed, 18,045 paths on disk, **18,033 of them
+  unreachable from the summary** — `AGENTS.md`, `.github/copilot-instructions.md`,
+  `pnpm-lock.yaml`, `skills-lock.json`, `node_modules/`, and two ~968 KB trees of
+  agent instructions at `.agents/skills/` and `agent/skills/`.
+  
+  That mattered because the same run ends with the `skills` CLI printing *"Review
+  skills before use; they run with full agent permissions."* Advice to review
+  files the run never named, at paths it never showed, is advice a newcomer
+  cannot act on — the wrong failure direction for a security-flavoured warning.
+  
+  The list could not have been correct where it stood: two of the three write
+  phases belong to other processes, and the `skills` installer's destination set
+  moves with **its** releases, not ours. Reading the directory afterwards makes
+  the summary self-correcting instead. Large directories collapse to one line
+  carrying their path, entry count and size, so the bulk stays reviewable without
+  18,000 lines of output, and the paths the skills installer created are marked
+  `⚠ skills` with the permissions warning tied to them.
+  
+  Same run, after the change: 20 entries printed, **0 written paths unreachable**.
+
+### Patch Changes
+
+- cec9d23: Fix `create-objectstack`'s startup banner hardcoding `◆ Create ObjectStack v6.x`
+  regardless of the package's real, released version — eleven majors stale, on
+  the first line of output a newcomer ever sees (#10325). The banner now calls
+  `readCliVersion()`, the same reader `.version()` already used, instead of a
+  literal string.
+  
+  Dropping the real version in without recomputing the box's padding would have
+  reintroduced the same defect one line later — the border is a fixed run of
+  `═` computed for the 4-character `v6.x`, and a longer real version (`v17.1.0`
+  is 7 characters) would push the right border out of alignment (the sibling
+  bug fixed in #10322, one function away in the same file). The box now derives
+  its width from the version string's plain length and widens the frame — never
+  truncates — for a version long enough to need more room; ordinary versions
+  still render at the historical box size.
+  
+  No behaviour change beyond the printed banner.
+- 3a3f209: Tell a newcomer that the `blank` starter ships no app, so an empty Console
+  reads as the intended starting point rather than a broken install (#10317).
+  
+  Measured on a real scaffold-and-boot (`create-objectstack my-app -t blank`,
+  published 17.1.0 packages, `objectstack dev --ui`): `GET /api/v1/meta/app`
+  returns the two platform apps (Setup, Account) and nothing of the project's
+  own, while `GET /api/v1/data/my_app_note` serves the scaffolded object the
+  whole time. The template ships `src/objects/` only — deliberately, as every
+  scaffolder template in this repo does — but nothing the newcomer could reach
+  said so, and `pnpm dev` advertises the Console URL on every boot.
+  
+  Documentation only: a new "The Console" section in the generated `README.md`
+  naming the Console path, the consequence, and `src/apps/*.app.ts` as the
+  remedy. No change to what the scaffolder writes into `src/`.
+- 7bf3fb7: Point every documentation link in these packages' published READMEs — and in
+  the project `create-objectstack` scaffolds — at the canonical docs origin
+  `https://objectstack.ai`, replacing the `docs.objectstack.ai` spelling.
+  
+  Both spellings reach the same pages (the alias redirects to the apex,
+  path-preserving), so no link was broken. The reason it needs a release rather
+  than an in-repo fix alone: a README ships inside the npm tarball, so the
+  version already on npm keeps showing the old host to every reader of the
+  package page until a new one is published.
+- 675ab57: **First-run polish:** a brand-new scaffold's very first `pnpm install` no longer reports two unmet peer dependencies (#10326).
+  
+  Reproduced on a clean scaffold from published `create-objectstack@17.1.0` — no lockfile, `node_modules` removed, nothing configured by the user — and again on the second scaffold path, `objectstack init`. Both printed the same two:
+  
+  ```
+  ✕ unmet peer better-call
+    Installed: 1.4.0
+    Wanted:
+      1.3.7:
+        @better-auth/scim@1.7.0-rc.1
+  
+  ✕ unmet peer better-sqlite3
+    Installed: 13.0.3
+    Wanted:
+      ^12.0.0:
+        better-auth@1.7.1
+  ```
+  
+  Nothing was broken — but it is the first screen a newcomer sees, and there is nothing they did to cause it or can do about it.
+  
+  **`better-sqlite3`: the pin is right and the upstream range is stale — so it is widened, not corrected.** better-auth 1.7.1 declares `better-sqlite3` as an **optional** peer at `^12.0.0`, and it governs exactly one configuration: a raw better-sqlite3 `Database` handed to better-auth's `database` option, which its Kysely dialect then drives. ObjectStack never takes that path — `AuthManager.createDatabaseConfig()` returns `createObjectQLAdapterFactory(dataEngine)`, and every `better-sqlite3` use under `plugin-auth` is knex's `client: 'better-sqlite3'` beneath ObjectQL. Measured anyway on the configuration the range *does* govern: better-auth 1.7.1 with `database: new Database(':memory:')`, running `getMigrations().runMigrations()`, `signUpEmail`, `signInEmail` and adapter `findOne`/`update`/`delete`, is green on **better-sqlite3 13.0.3** and byte-for-byte equivalent on **12.11.1**. The same probe with `Database.prototype.prepare` neutered fails, so that green is the driver's and not an unexercised path. Pinning our own `^13.0.3` declarations back to `^12` would downgrade a native module across the platform to satisfy a range measurement shows is simply behind.
+  
+  **`@better-auth/scim`: the rc pin stays, and one `better-call` copy is the correct tree.** `npm view @better-auth/scim dist-tags` reads `latest: '1.7.1'`, but stable 1.7.x ships the rc.2 whole-model rewrite, so adopting it is a separate migration rather than a version bump; the exact `1.7.0-rc.1` pin is deliberate. The rc peers an exact `better-call@1.3.7` while better-auth 1.7.1 depends on `1.4.0` — and a better-auth plugin has to share the **host's** better-call instance, so the single 1.4.0 copy every install already resolves is right, not a skew to repair. This declaration retires together with the rc pin.
+  
+  **What changed, and what deliberately did not.** Both remedies are pnpm `peerDependencyRules.allowedVersions` entries, scoped `<declaring package>><peer>` so each widens exactly one declaration. They ship *inside* the scaffold — the bundled `pnpm-workspace.yaml` template and the one `objectstack init` renders — because a block in this repo's own workspace file does not travel with published packages. `allowedVersions` changes what pnpm **reports**, never what it resolves: measured on both scaffold paths, the lockfile is byte-identical with and without it (0 lines of diff), and no dependency version, range or resolution moved anywhere. This repo's own resolutions are untouched.
+- e85182d: Converge the blank scaffold template's `README.md` docs links on the ruled
+  canonical origin, `https://objectstack.ai` (maintainer ruling, 2026-08-21:
+  「这个仓的文档站规范 URL 是 https://objectstack.ai」; enforced by
+  `CANONICAL_DOCS_ORIGIN` in `scripts/check-published-readme-links.mjs`). The
+  template previously linked the accepted-but-unratified `docs.objectstack.ai`
+  alias in three places, which disagreed with the root `README.md`'s already-
+  canonical spelling — so a single `npm create objectstack@latest` run handed
+  the user two different hostnames for the same docs site.
+- aea1e64: Fix the declared bin (`bin/create-objectstack.js`) being tracked non-executable
+  in git. It carries a `#!/usr/bin/env node` shebang and is pnpm's link target
+  for the `create-objectstack` command, but was committed `100644` instead of
+  `100755` — matching the sibling declared bin `packages/cli/bin/run.js`, which
+  was already tracked executable.
+  
+  Patch bump: this is a packaging-mode correction with no content, API or
+  behavior change (the blob hash is identical) — it only fixes how the file is
+  tracked in git and therefore how it is packed for npm.
+- 818e027: Fix `objectstack init`'s closing "Created files" summary omitting `pnpm-lock.yaml` / `package-lock.json` and `node_modules/` (#10557).
+  
+  The summary used to be printed from a list accumulated while the template
+  files were written — before `<pm> install` ran — so it could never name what
+  the package manager wrote. `init` now prints it after the install attempt
+  (succeeded or failed) from a walk of the finished project directory, reusing
+  `create-objectstack`'s `created-summary.ts` (now published as the
+  `create-objectstack/created-summary` subpath) instead of a second copy of the
+  same renderer.
+- afe1c4e: fix(cli): declare the four `@better-auth/utils` peer skews a freshly scaffolded project reports (#10931)
+  
+  Both scaffold paths emit a `peerDependencyRules.allowedVersions` block whose
+  stated purpose is that a brand-new project's first `pnpm install` does not open
+  with a peer-skew report. It declared two skews and left four showing:
+  
+  ```
+  ├─┬ @better-auth/core 1.7.1
+  │ └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0
+          ├─┬ @better-auth/scim 1.7.0-rc.1
+          │ └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0
+          ├─┬ @better-auth/oauth-provider 1.7.1
+          │ └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0
+          └─┬ @better-auth/sso 1.7.1
+            └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0
+  ```
+  
+  `@better-auth/core`, `/oauth-provider`, `/scim` and `/sso` each peer an **exact**
+  `@better-auth/utils@0.4.2`. The 0.5.0 they are handed comes from
+  `better-call@1.4.0` — better-auth's own HTTP layer — which *depends* on
+  `^0.5.0`; `@objectstack/plugin-auth` names the four as direct dependencies
+  without naming utils, so pnpm satisfies their peer from better-call's copy
+  instead of better-auth's own exact 0.4.2 dependency.
+  
+  **Measured compatible before widening, not assumed.** Those four import three
+  symbols in total: `base64`/`base64Url` (`@better-auth/utils/base64`),
+  `createHash` (`/hash`) and, in core only, `createRandomStringGenerator`
+  (`/random`). 0.5.0 declares all three with identical signatures; `/random` is
+  unchanged apart from formatting, `/base64` swaps `new Uint8Array(data)` for a
+  helper that *is* `new Uint8Array(data)` on non-strings, and `/hash` only widens
+  its input coercion for views not backed by a plain `ArrayBuffer`. Run against
+  the input shapes those call sites actually pass, the two versions agree on every
+  value; run end to end — better-auth with the `sso`, `oauth-provider` and `scim`
+  plugins — a tree where the four resolve 0.5.0 and one where they resolve 0.4.2
+  produce the same transcript: sign-up, sign-in, session, both OAuth metadata
+  documents, the RFC 7636 PKCE challenge, and the SCIM and SSO endpoint outcomes.
+  
+  A resolution change was measured too, and rejected: pinning utils back to 0.4.2
+  clears the four lines only by dragging `better-call@1.4.0` off its own declared
+  `^0.5.0` — manufacturing one real range violation to silence four benign ones.
+  
+  Four scoped entries, one per declaring package, matching the block's convention
+  that each rule widens exactly one declaration. `allowedVersions` suppresses the
+  report only: the lockfile a scaffold resolves is byte-identical with and without
+  the block. The version is spelled `0.5.0` exactly rather than `0.5`, so a future
+  `0.6.0` reports again instead of inheriting this finding.
+  
+  Both scaffold paths — `objectstack init` (rendered by the CLI) and
+  `npx create-objectstack` (a copied template file) — are changed together, and
+  `packages/cli/test/scaffold-workspace-consistency.test.ts` gains a limb that
+  compares the peer maps the two produce, so they cannot drift apart again.
+- 21756b3: fix(create-objectstack): converge scaffold docs on the canonical host and drop the last two dead monorepo references (#10990, #11022)
+  
+  A freshly scaffolded project shipped a handful of text lines a reader with
+  only their own project — no monorepo, no `docs/adr/`, no issue tracker —
+  could not follow:
+  
+  - `templates/AGENTS.md` linked `https://objectstack.com/docs`, a domain that
+    is not this project's docs site at all (not even a redirecting alias).
+  - `templates/blank/Dockerfile` and `templates/blank/docker-compose.yml` both
+    linked `https://docs.objectstack.ai/...`, an accepted-but-unratified alias.
+    All three now point at the ruled canonical origin, `https://objectstack.ai`
+    (maintainer ruling, 2026-08-21).
+  - `templates/blank/README.md` cited `ADR-0097` and named "the ObjectStack
+    framework repo" as the home of `skills/` — both rewritten self-contained,
+    keeping the fact each was carrying: the connector-materialization line now
+    links the public [Automation → Connectors](https://objectstack.ai/docs/automation/connectors)
+    page, and the skills line now names the followable
+    `npx skills add objectstack-ai/objectstack/skills` install the scaffolder's
+    own closing output already uses.
+  
+  `packages/create-objectstack/src/starter-comments-self-contained.test.ts`
+  (#10324) gains two pin obligations these two fixes call for: a host-convergence
+  assertion driven by the same `shippedFiles()` walker that already enumerates
+  everything a scaffold ships (no other repo gate's population reaches these
+  template files — `check:published-readme-links` reads publishable packages'
+  published markdown only), and a fifth `MONOREPO_ONLY` pattern that catches a
+  prose-shaped reference to this repo ("the ObjectStack framework repo") the
+  first four, syntax-shaped patterns could not. The self-retiring `EXCLUDED`
+  entry for `blank/README.md` is removed now that the file cites nothing
+  monorepo-only.
+- 568de19: Scaffolded projects declare an explicit empty `packages: []` in their
+  `pnpm-workspace.yaml` (#10933). Both scaffold paths render it —
+  `renderPnpmWorkspaceYaml` in `objectstack init`, and the bundled `blank`
+  template `npx create-objectstack` copies.
+  
+  The file was deliberately keyless so it would act purely as a settings file.
+  That intent is now written down rather than inferred from a missing key, and
+  writing it down is what fixes a first-command failure: pnpm 9.x and 10.0–10.4
+  parse `pnpm-workspace.yaml` **before** they read `engines`, so they refused a
+  brand-new project outright with
+  
+  ```
+   ERROR  packages field missing or empty
+  ```
+  
+  naming a file the user never wrote and giving no hint that the cause is their
+  pnpm version — and no `engines.pnpm` floor could reach them, because they never
+  got as far as the engines check. Measured, one clean install per pnpm version,
+  each with its own store:
+  
+  | pnpm | before | after |
+  |---|---|---|
+  | 9.15.9, 10.0.0, 10.4.0 | `ERROR packages field missing or empty` | `ERR_PNPM_UNSUPPORTED_ENGINE`, naming `>=10.15` |
+  | 10.5.0–10.14.0 | `ERR_PNPM_UNSUPPORTED_ENGINE` | unchanged |
+  | 10.15.0, 10.34.5, 11.22.0 | installs | installs, byte-identical `pnpm-lock.yaml` |
+  
+  So every unsupported pnpm now reports the same actionable cause, and supported
+  pnpm is unaffected: the empty key was measured equivalent to omission on
+  10.15.0, 10.34.5 and 11.22.0 — identical lockfile bytes, identical
+  `node_modules/.modules.yaml` once the run-local `prunedAt`/`storeDir` fields are
+  dropped, identical `pnpm ls -r --depth -1`, and an identical second-install
+  "Already up to date".
+  
+  The declaration is an **empty** list on purpose. `packages: ['.']` satisfies the
+  same parsers but declares the project root a workspace *member* — a monorepo
+  root — which a single-package scaffold is not, and which reads to the next
+  author (human or AI) as an invitation to add member packages to an app.
+  
+  `engines.pnpm` is unchanged at `>=10.15`.
+- 8d21f7a: Fix `create-objectstack`'s closing "Next steps" and install-failure remedy
+  hardcoding `npm` regardless of which package manager the run actually used
+  (#10322). `detectPackageManager()` already prefers `pnpm` and falls back to
+  `npm` only when `pnpm` is unreachable — confirmed still true at HEAD, and
+  confirmed empirically: a real run with `pnpm` on `PATH` installs with `pnpm`
+  (`pnpm-lock.yaml`, "Done in … using pnpm vX") and then told the newcomer to
+  run `npm run dev` / `npm run validate` next, a package manager the run never
+  touched. The detected package manager is now read once, up front, and reused
+  consistently for the install command, the install-failure remedy, and every
+  line of "Next steps" — so the printed guidance always names the tool the run
+  actually used, in both the `pnpm` and the `npm`-fallback case.
+  
+  Also names `validate` — the step the generated `AGENTS.md` calls
+  unskippable — in the "Getting started" section of the generated `blank`
+  template's README, not only in its later "Verify your changes" section, so a
+  newcomer reading top-to-bottom sees it at first touch.
+  
+  No install behaviour changes: the scaffolder still installs by default and
+  still supports `--skip-install`; this is a messaging-only fix.
+- 9d101d2: Declare a pnpm floor (`engines.pnpm: ">=10.15"`) in the `package.json` both
+  scaffolders write, so an unsupported pnpm reports its own version instead of an
+  error about a file the user never wrote.
+  
+  Both scaffold paths emit a settings-only `pnpm-workspace.yaml` with no
+  `packages:` key. Early pnpm 10 refuses that file outright — `pnpm install` exits
+  1 with `ERROR packages field missing or empty` before resolving a single
+  dependency, so a brand-new project could not be installed at all. Measured on
+  the rendered shape, one clean install per pnpm version, each with its own store:
+  
+  | pnpm | before | after |
+  | --- | --- | --- |
+  | 10.0.0 – 10.4.0 | `packages field missing or empty` | unchanged — see below |
+  | 10.5.0 – 10.14.0 | `packages field missing or empty` | `ERR_PNPM_UNSUPPORTED_ENGINE`, naming the expected range |
+  | >= 10.15.0 | installs | installs |
+  
+  The floor is a diagnosis, not a repair: pnpm 10.0.0–10.4.0 parse
+  `pnpm-workspace.yaml` *before* they read `engines`, so they still print the raw
+  workspace error. Closing that remaining sliver requires deciding what a
+  single-package scaffold should declare under `packages:`, which is tracked
+  separately and deliberately not decided here.
+  
+  `engines.pnpm` rather than a `packageManager` stamp: npm, yarn and bun ignore
+  `engines.pnpm` entirely, so the scaffold keeps working for all four package
+  managers `objectstack init` hands off to. A `packageManager: "pnpm@x.y.z"` stamp
+  would declare the project pnpm-only (corepack-driven yarn refuses to run in such
+  a project) and pin one exact version that goes stale on every pnpm release — and
+  it buys nothing on 10.0–10.4, which reach the workspace error before reading
+  that field either.
+  
+  No existing project is affected; this only changes what a newly scaffolded
+  `package.json` contains.
+- 6d441e4: Correct the pnpm boundary the blank template states for `allowBuilds`, and gate
+  the two scaffold paths against each other (#10498, #10499).
+  
+  `packages/create-objectstack/src/templates/blank/pnpm-workspace.yaml` is copied
+  verbatim into every scaffolded project, so its header comment is prose that
+  ships **inside the user's own repository**. It said `allowBuilds` needs
+  pnpm >= 10.31 and that `onlyBuiltDependencies` covers pnpm 10.0–10.30. Measured
+  on a probe depending on `esbuild@0.28.2`, with a workspace file carrying only
+  `allowBuilds`, one clean install per pnpm version and each with its own
+  `--store-dir` (isolation matters — pnpm's side-effects cache will otherwise hand
+  a later run a build an earlier run performed, and it reads as "the key worked"):
+  
+  | pnpm | `allowBuilds` alone |
+  |:--|:--|
+  | 10.15.0 – 10.25.0 | ignored — build not run |
+  | **10.26.0** | **honoured — build ran** |
+  | 10.28.0 – 10.33.0 | honoured — build ran |
+  
+  So the floor is 10.26.0 and the older-key band is 10.0–10.25. A user on pnpm
+  10.28 was being told by the file in front of them that their pnpm cannot read
+  the key it is in fact reading. Both load-bearing claims in that comment were
+  correct and are unchanged: both keys are needed, and pnpm 11 reads only
+  `allowBuilds`. No setting, no assertion and no install behaviour changes — the
+  rendered `onlyBuiltDependencies` / `allowBuilds` values are byte-identical.
+  
+  The reason it was wrong for so long is the second half of this change.
+  `objectstack init` renders the same file from `renderPnpmWorkspaceYaml()` in
+  `packages/cli`, it was corrected to the measured numbers separately, and each
+  package's ratchets are package-local — so neither could ever fail for the other
+  file's regression, and the two scaffold paths shipped contradictory prose about
+  the same rule with every gate green. `packages/cli/test/scaffold-workspace-consistency.test.ts`
+  now compares the two **rendered outputs**: the packages each key actually grants
+  a build to, and the pnpm versions each file actually names for each key. It was
+  confirmed failing against the live divergence before this correction landed.
+  
+  Bumped `patch` rather than left out: the corrected text is user-visible — it is
+  delivered into every new project — while nothing executable moves.
+- ecd06f6: Rewrite the scaffolded project's starter comments so a newcomer can actually
+  follow them (#10324). `objectstack.config.ts` and `src/objects/note.object.ts`
+  are the first two files opened after scaffolding, and between them they cited
+  four ADR identifiers, one bare issue number and the path of a release-time
+  script in this monorepo — none of which ship in, or are linked from, a
+  scaffolded project. `// per ADR-0097` read as a reference the reader was
+  failing to follow rather than as the context it was meant to be.
+  
+  The explanations are kept and made self-contained; only the dead ends are
+  gone. Each now states the fact the identifier stood for — the protocol range
+  is checked before anything loads and was stamped to match the installed
+  version rather than hand-tuned; `automation` must stay whenever `plugins:`
+  lists a connector or the executors have nowhere to register; a declarative
+  `mcp` stdio transport is denied by default; the org-wide default is required
+  so the baseline is an authored decision — and points at the public docs page
+  that covers it in full. The blank `Dockerfile` likewise stops pointing at a
+  file in this repo and points at the self-hosting guide it already links.
+  
+  A pin (`starter-comments-self-contained.test.ts`) keeps it that way from both
+  sides: no shipped template file may cite an ADR identifier, a bare issue
+  number or a repo script path, and the facts those references carried must
+  still be stated — so the comments cannot be "fixed" by deleting them. It also
+  resolves every canonical-origin docs URL in the shipped tree against
+  `content/docs`, because a link that 404s is the same defect one level out.
+
+## 17.1.0
+
+### Minor Changes
+
+- 1eb28a1: Retire the five remote content templates from the scaffolder's catalog.
+  
+  `todo`, `compliance`, `content`, `contracts` and `procurement` were delisted
+  from the official ObjectStack template marketplace and are no longer
+  maintained, but the CLI carried its own hardcoded catalog and never learned
+  that: `--help` recommended all five by name with marketing descriptions, and
+  the `Available:` line on a bad `-t` offered them too.
+  
+  - `blank` (bundled, offline) is now the whole catalog, so the help text
+    advertises only what is actually supported.
+  - Asking for one of the five by name — `-t todo` in an old script or tutorial —
+    is refused with a message that says the template was retired, instead of the
+    generic "Unknown template" error that reads as a typo.
+  - The GitHub tarball-fetch path that served the remote templates is removed
+    along with its `tar` dependency; nothing else reached it.
+  
+  Note this corrects the catalog at HEAD only. Already-published versions keep
+  advertising the retired templates until a new version of `create-objectstack`
+  is released.
+
+### Patch Changes
+
+- 4906c90: Fix scaffolded projects describing themselves as the blank template (#9263)
+  
+  `rewriteProjectIdentity` rewrote `id` / `namespace` / `name` in both
+  `objectstack.config.ts` and `objectstack.manifest.json` from the project name,
+  but left `description` untouched — every scaffolded project carried the blank
+  template's own line verbatim ("Minimal ObjectStack environment — a clean
+  slate for building."), confidently wrong rather than empty, and printed by
+  the first command the getting-started flow tells people to run (`os
+  validate`).
+  
+  The scaffolder now drops `description` from both files instead of rewriting
+  it. There is nothing but the project name to derive a replacement from, and a
+  name-derived sentence (e.g. "Support Desk — an ObjectStack environment.")
+  would be a bare restatement of the `name`/`displayName` row already shown —
+  worse than no sentence at all. `os validate` already omits the description
+  line entirely when the field is unset, so a freshly scaffolded project now
+  prints cleanly:
+  
+  ```
+    Support Desk v0.1.0
+  ```
+  
+  instead of
+  
+  ```
+    Support Desk v0.1.0
+    Minimal ObjectStack environment — a clean slate for building.
+  ```
+- f2f09e4: fix(create-objectstack): the scaffolded Dockerfile pins the runtime image to the CLI that builds the artifact, instead of `latest` under a comment saying to pin (#9017)
+  
+  `src/templates/blank/Dockerfile` shipped `FROM ghcr.io/objectstack-ai/objectstack:latest`
+  directly beneath a comment instructing the reader to "pin the tag to the
+  `@objectstack/cli` version in your package.json so the runtime matches the CLI that built
+  the artifact" — an instruction the scaffold itself did not follow. Every app made with
+  `npx create-objectstack` shipped that contradiction from day one, and `docker/README.md`'s
+  tag table already scopes `latest` to quick starts while documenting `X.Y.Z` as the
+  production pin.
+  
+  Measured on scaffolded output rather than the template's bytes, before the fix:
+  
+  ```
+  emitted package.json cli range : ^17.0.0
+  emitted Dockerfile FROM        : FROM ghcr.io/objectstack-ai/objectstack:latest
+  agreement (tag vs cli range)   : DISAGREE
+  ```
+  
+  **The tag is resolved after `install`, from the installed CLI — not from the generated
+  `package.json`.** That file carries a caret RANGE, and the two are not interchangeable:
+  npm resolves `^17.0.0` to the newest 17.x, so pinning the range's floor would ship a
+  runtime image *older* than the CLI that built the artifact — breaking the same promise in
+  a new way. The rolling `:17` tag does match the range's float window but is exactly what
+  the tag table tells production not to use. The resolved version is the only value that
+  makes the sentence true, and it is the rule the repo already applies for this purpose in
+  `.github/workflows/scaffold-e2e.yml` ("Pin the runtime's CLI to the SAME version the
+  generated project actually resolved to — NOT a hardcoded `latest`").
+  
+  **Both halves move together.** Pinning the line while leaving an imperative to pin by hand
+  would relocate the contradiction rather than remove it, so the comment above the `FROM`
+  line is replaced in the same rewrite. With `--skip-install` there is no resolved version:
+  the tag stays `latest` and the comment keeps telling the reader to pin — which is true on
+  that path, because there the user really must do it by hand.
+  
+  The regression proof asserts on **scaffolded output**, never on the template: it scaffolds
+  with the real copy/sync/pin path, plants an installed CLI whose version is deliberately
+  *not* the range's floor (the normal case, and the one that a package.json-derived tag
+  would get wrong), and checks the emitted `FROM` tag against the emitted `package.json`
+  range with a satisfies-check rather than equality.
+  
+  `.github/workflows/scaffold-e2e.yml` now reads the tag it builds its local runtime image
+  under **out of the generated Dockerfile** instead of hardcoding `:latest`. Those were two
+  hand-matched literals; had they skewed, Docker would have quietly pulled the last
+  published image instead of the one built from this checkout, and the job's own stated
+  hermeticity would have been false while it stayed green.
+- 0a5adba: fix(create-objectstack): the blank template's `specVersion` stops shipping eleven majors stale, and the version-time sync covers every declared surface on every template (#9264)
+  
+  The one bundled template declared the platform it targets in **two** places that
+  disagreed by eleven majors:
+  
+  | file | key | was |
+  |:--|:--|:--|
+  | `objectstack.manifest.json` | `specVersion` | `^6.0.0` |
+  | `objectstack.config.ts` | `engines.protocol` | `^17` |
+  
+  `scripts/sync-template-versions.mjs` re-stamped the config key and the template's
+  `@objectstack/*` dependency ranges, and **never opened the manifest at all**. So
+  `engines.protocol` tracked every major bump while `specVersion` sat at the value
+  it held when the script was written — and a green `sync-template-versions` run
+  was never evidence about it, because the script's failure mode was loud for the
+  keys it covered and mute for the key it did not.
+  
+  **This is not confined to the registry contract.** `create-objectstack` copies
+  the manifest into every scaffolded project, rewriting `name`, `displayName` and
+  `namespace` and dropping `description` — it has never touched `specVersion`. So
+  every project scaffolded since v7 was stamped with a `^6.0.0` spec range while
+  installing `@objectstack/spec@^17.0.0`.
+  
+  **The two keys are two facts, and the fix keeps them apart.** `engines.protocol`
+  is the ADR-0087 D1 runtime handshake range and carries the protocol major
+  (`^17`). `specVersion` is documented by `TemplateManifestSchema` as the
+  "Compatible `@objectstack/spec` semver range" and carries the package range
+  (`^17.0.0`) — the same value the script already writes into the template's own
+  `@objectstack/spec` dependency, so the manifest and the `package.json` now state
+  one fact once. They agree on the major only because the spec package's major and
+  the protocol major are kept in lockstep; they are stamped from two different
+  values.
+  
+  Deleting the key was not available: `specVersion` is **required** by
+  `TemplateManifestSchema`, and every shipped manifest is parsed against it by
+  `check:template-manifests`.
+  
+  **Two structural changes, because one-key-one-file coverage is what let this
+  sit:**
+  
+  - the sync script's file list is now **discovered**, not hard-coded — templates
+    are found by walking `src/templates/`, the same way `check-template-manifests`
+    finds the manifests it parses, so a second template is covered on the day it
+    lands;
+  - **every stamp is required**. A template whose file is missing, whose stamp is
+    absent, or whose `package.json` declares no `@objectstack/*` dependency is a
+    hard failure naming the path — never a skip. A skipped stamp is
+    indistinguishable from a synced one in the log, which is the invisibility this
+    fixes.
+  
+  The manifest is rewritten as **text** rather than parsed and re-serialized:
+  `objectstack.manifest.json` keeps `scaffold.variables` compact on one line, and
+  `JSON.stringify(…, null, 2)` would reformat unrelated structure on every release.
+  
+  CI coverage lands as four per-template ratchets in `template-consistency.test.ts`,
+  generalized off `blank` onto the same directory walk — including the invariant
+  that catches this exact class: the manifest's `specVersion` must equal the
+  `@objectstack/spec` range the template actually installs. Either file alone can
+  be self-consistently stale; only comparing them catches a stamp that covered one
+  and not the other.
+
 ## 17.0.0
 
 ### Major Changes

package/README.md

@@ -27,16 +27,14 @@ npx create-objectstack my-app --skip-install
 | Template | Source | Description |
 | --- | --- | --- |
 | `blank` *(default)* | bundled (offline) | Minimal starter — one object, REST API, ready to extend |
-| `todo` | remote | Universal task & project management starter |
-| `compliance` | remote | Compliance posture & evidence management (SOC2 / ISO27001) |
-| `content` | remote | Content marketing pipeline — editorial calendar & channel ROI |
-| `contracts` | remote | Post-signature CLM — approvals, obligations, renewals |
-| `procurement` | remote | Source-to-pay — vendors, POs, receipts, invoice matching |
 
-Remote templates are fetched from
-[`objectstack-ai/templates`](https://github.com/objectstack-ai/templates) at
-scaffold time and require network access; `blank` is bundled and always works
-offline.
+`blank` is bundled inside the npm package, so scaffolding never needs network
+access.
+
+The remote content templates (`todo`, `compliance`, `content`, `contracts`,
+`procurement`) have been **retired** — they were delisted from the ObjectStack
+template marketplace and are no longer maintained. Asking for one by name tells
+you so rather than failing as an unknown template.
 
 ## Options
 
@@ -89,7 +87,7 @@ npm run validate   # verify metadata: schema + predicates + bindings
 ```
 
 See the docs:
-[Your First Project](https://docs.objectstack.ai/docs/getting-started/your-first-project).
+[Your First Project](https://objectstack.ai/docs/getting-started/your-first-project).
 
 ## License
 

package/dist/chunk-ZIUW7UEA.js

@@ -0,0 +1,112 @@
+// src/created-summary.ts
+import fs from "fs";
+import path from "path";
+var COLLAPSE_AT = 10;
+var MEASURE_BUDGET = 2e3;
+function scan(abs, name, budget) {
+  let st;
+  try {
+    st = fs.lstatSync(abs);
+  } catch {
+    return { name, dir: false, entries: 0, bytes: 0, truncated: false, children: [] };
+  }
+  if (!st.isDirectory()) {
+    budget.left -= 1;
+    return { name, dir: false, entries: 1, bytes: st.size, truncated: false, children: [] };
+  }
+  const node = { name, dir: true, entries: 0, bytes: 0, truncated: false, children: [] };
+  let dirents;
+  try {
+    dirents = fs.readdirSync(abs, { withFileTypes: true });
+  } catch {
+    return node;
+  }
+  for (const entry of dirents) {
+    if (budget.left <= 0) {
+      node.truncated = true;
+      break;
+    }
+    const child = scan(path.join(abs, entry.name), entry.name, budget);
+    node.entries += child.entries;
+    node.bytes += child.bytes;
+    if (child.truncated) node.truncated = true;
+    node.children.push(child);
+  }
+  return node;
+}
+function byName(a, b) {
+  return a.name.localeCompare(b.name, "en");
+}
+function flatten(node, prefix, out) {
+  for (const child of [...node.children].sort(byName)) {
+    const rel = prefix + child.name;
+    if (!child.dir) {
+      out.push({ path: rel, kind: "file", entries: 1, bytes: child.bytes, truncated: false });
+      continue;
+    }
+    if (!child.truncated && child.entries <= COLLAPSE_AT) {
+      flatten(child, `${rel}/`, out);
+      continue;
+    }
+    let deepest = child;
+    let shown = rel;
+    while (deepest.children.length === 1 && deepest.children[0].dir) {
+      deepest = deepest.children[0];
+      shown = `${shown}/${deepest.name}`;
+    }
+    out.push({
+      path: `${shown}/`,
+      kind: "dir",
+      entries: deepest.entries,
+      bytes: deepest.bytes,
+      truncated: deepest.truncated
+    });
+  }
+}
+function summarizeTree(root) {
+  let dirents;
+  try {
+    dirents = fs.readdirSync(root, { withFileTypes: true });
+  } catch {
+    return [];
+  }
+  const top = { name: "", dir: true, entries: 0, bytes: 0, truncated: false, children: [] };
+  for (const entry of dirents) {
+    top.children.push(scan(path.join(root, entry.name), entry.name, { left: MEASURE_BUDGET }));
+  }
+  const out = [];
+  flatten(top, "", out);
+  return [
+    ...out.filter((e) => e.kind === "file"),
+    ...out.filter((e) => e.kind === "dir")
+  ];
+}
+function formatBytes(bytes) {
+  if (bytes < 1024) return `${bytes} B`;
+  const kb = bytes / 1024;
+  if (kb < 1024) return `${kb < 10 ? kb.toFixed(1) : Math.round(kb)} KB`;
+  const mb = kb / 1024;
+  return `${mb < 10 ? mb.toFixed(1) : Math.round(mb)} MB`;
+}
+function describeEntry(entry) {
+  if (entry.kind === "file") return "";
+  const noun = entry.entries === 1 ? "file" : "files";
+  if (entry.truncated) return `over ${entry.entries.toLocaleString("en-US")} ${noun}`;
+  return `${entry.entries.toLocaleString("en-US")} ${noun}, ${formatBytes(entry.bytes)}`;
+}
+function unreachablePaths(entries, written) {
+  const named = new Set(entries.filter((e) => e.kind === "file").map((e) => e.path));
+  const dirs = entries.filter((e) => e.kind === "dir").map((e) => e.path);
+  return written.filter(
+    (p) => !named.has(p) && !dirs.some((d) => `${p}/`.startsWith(d))
+  );
+}
+
+export {
+  COLLAPSE_AT,
+  MEASURE_BUDGET,
+  summarizeTree,
+  formatBytes,
+  describeEntry,
+  unreachablePaths
+};