When `create.defaultTemplate: '@org'` is set, bare `vp create` now drops
into the org picker with a trailing "Vite+ built-in templates" escape-hatch
entry that routes to the existing `getInitialTemplateOptions` flow. This
preserves interactive discovery of `vite:monorepo` / `vite:application` /
`vite:library` / `vite:generator` without adding a new CLI flag; explicit
specifiers (e.g. `vp create vite:application`) remain the scripted bypass.

Addresses @cpojer's review feedback on #1398.

When `create.defaultTemplate: '@org'` is set, bare `vp create` now drops
into the org picker with a trailing "Vite+ built-in templates" escape-hatch
entry that routes to the existing `getInitialTemplateOptions` flow. This
preserves interactive discovery of `vite:monorepo` / `vite:application` /
`vite:library` / `vite:generator` without adding a new CLI flag; explicit
specifiers (e.g. `vp create vite:application`) remain the scripted bypass.

Addresses @cpojer's review feedback on #1398.

Let manifest entries use relative paths (`./templates/demo`) that resolve
against the enclosing @org/create package root, so orgs can ship one
package containing N templates instead of publishing N @org/template-*
packages — the pattern already used by create-vite, create-next-app, and
most enterprise scaffolding kits.

Vite+ fetches the tarball URL already returned by the registry manifest,
extracts it once per version into `$VP_HOME/tmp/create-org/<scope>/<name>/<version>/`,
and scaffolds by directory copy. Paths that escape the package root are
rejected at schema-validation time.

Addresses @fengmk2's review feedback on #1398 asking whether
`./templates/demo`-style bundled paths would be supported.

Two inline review findings from @fengmk2 on PR #1398:

- Bundled subdirectory section was leaking implementation details
  (tarball download mechanics, SHA-512 integrity verification, cache
  path under $VP_HOME, NPM_CONFIG_REGISTRY handling). Users just need
  to know that `./...` paths resolve against the @org/create package
  root and that the directory is copied verbatim. The rest belongs in
  the RFC.

- Non-interactive inspection section explained the design rationale
  for keeping the output machine-parseable ("so scripts and AI agents
  can recover the list without a separate `--list` flag"). That's an
  RFC-level decision; users just need to see the shape of the output.

The early-exit "template name is required" guard fired before
`getConfiguredDefaultTemplate` ran, so `vp create --no-interactive`
in a repo with `create.defaultTemplate: '@your-org'` exited with a
generic "template name required" message instead of reading the
configured default. The documented precedence (CLI arg >
create.defaultTemplate > interactive picker) was silently broken for
all non-interactive / CI usage.

Fix: move the guard to after the full resolution chain
(CLI arg → create.defaultTemplate → @org manifest). Only error if
`selectedTemplateName` is still empty once every input source has had
a chance to fill it. If the configured default is an @org scope, the
manifest resolver's own `--no-interactive` branch prints the manifest
table — exactly what a user expects when the config was supposed to
pick the org.

New snap-test `create-org-config-default` locks in the fix: a fixture
with `create: { defaultTemplate: '@your-org' }` in vite.config.ts
runs bare `vp create --no-interactive` and verifies the @your-org
manifest table prints instead of the generic missing-argument error.

Reported by Cursor Bugbot on #1398.

When `create.defaultTemplate: '@org'` is set, bare `vp create` now drops
into the org picker with a trailing "Vite+ built-in templates" escape-hatch
entry that routes to the existing `getInitialTemplateOptions` flow. This
preserves interactive discovery of `vite:monorepo` / `vite:application` /
`vite:library` / `vite:generator` without adding a new CLI flag; explicit
specifiers (e.g. `vp create vite:application`) remain the scripted bypass.

Addresses @cpojer's review feedback on #1398.

Let manifest entries use relative paths (`./templates/demo`) that resolve
against the enclosing @org/create package root, so orgs can ship one
package containing N templates instead of publishing N @org/template-*
packages — the pattern already used by create-vite, create-next-app, and
most enterprise scaffolding kits.

Vite+ fetches the tarball URL already returned by the registry manifest,
extracts it once per version into `$VP_HOME/tmp/create-org/<scope>/<name>/<version>/`,
and scaffolds by directory copy. Paths that escape the package root are
rejected at schema-validation time.

Addresses @fengmk2's review feedback on #1398 asking whether
`./templates/demo`-style bundled paths would be supported.

Two inline review findings from @fengmk2 on PR #1398:

- Bundled subdirectory section was leaking implementation details
  (tarball download mechanics, SHA-512 integrity verification, cache
  path under $VP_HOME, NPM_CONFIG_REGISTRY handling). Users just need
  to know that `./...` paths resolve against the @org/create package
  root and that the directory is copied verbatim. The rest belongs in
  the RFC.

- Non-interactive inspection section explained the design rationale
  for keeping the output machine-parseable ("so scripts and AI agents
  can recover the list without a separate `--list` flag"). That's an
  RFC-level decision; users just need to see the shape of the output.

The early-exit "template name is required" guard fired before
`getConfiguredDefaultTemplate` ran, so `vp create --no-interactive`
in a repo with `create.defaultTemplate: '@your-org'` exited with a
generic "template name required" message instead of reading the
configured default. The documented precedence (CLI arg >
create.defaultTemplate > interactive picker) was silently broken for
all non-interactive / CI usage.

Fix: move the guard to after the full resolution chain
(CLI arg → create.defaultTemplate → @org manifest). Only error if
`selectedTemplateName` is still empty once every input source has had
a chance to fill it. If the configured default is an @org scope, the
manifest resolver's own `--no-interactive` branch prints the manifest
table — exactly what a user expects when the config was supposed to
pick the org.

New snap-test `create-org-config-default` locks in the fix: a fixture
with `create: { defaultTemplate: '@your-org' }` in vite.config.ts
runs bare `vp create --no-interactive` and verifies the @your-org
manifest table prints instead of the generic missing-argument error.

Reported by Cursor Bugbot on #1398.

When a user types `vp create @org` expecting the picker but
`@org/create` has no `vp.templates` manifest, emit a one-line
`info:` note before falling through to run `@org/create` as a normal
package:

  No `vp.templates` manifest in @org/create — running it as a normal package.

Without this, a later `ERR_PNPM_DLX_NO_BIN` (the typical failure when
`@org/create` is data-only, as with `@eggjs/create`) looks mysterious
— the user has no way to know the picker was attempted and skipped.

Triggered only for scope-only input (`vp create @org`). The
per-entry form (`vp create @org/name`) stays silent because it's
ambiguous — the user might have genuinely wanted `@org/create-name`
via the existing shorthand.

Also helps diagnose registry-mirror sync lag: if a user's mirror
hasn't synced a just-published manifest, they now see "no manifest"
instead of the downstream dlx failure.

Reported by @fengmk2 on #1398 after `vp create @eggjs` in a monorepo
showed the monorepo parent-dir prompt and then `pnpm dlx @eggjs/create`
without ever running the picker.

Manifest entries like `{ template: '@your-org/template-web' }` were
passing through `discoverTemplate` → `expandCreateShorthand` and being
rewritten into `@your-org/create-template-web` — because the shorthand
rule targets any `@scope/name` that doesn't already start with `create-`.
The manifest author's literal package name was silently transformed,
causing vp to fetch the wrong package.

Fix: thread a `skipShorthand` flag through `discoverTemplate` that short-
circuits the final `expandCreateShorthand` call. Set it when
`resolveOrgManifestForCreate` returns `kind: 'replaced'` (the path
responsible for manifest-resolved specifiers). The earlier branches in
`discoverTemplate` (`vite:`, GitHub URLs, local workspace packages)
still match first, so manifest entries using those specifier kinds
behave unchanged.

Unit test added to `discovery.spec.ts` pinning both halves of the
contract: `@your-org/template-web` stays literal with the flag set,
and still expands via shorthand without it (the existing behavior
for non-manifest inputs).

Reported by Cursor Bugbot on #1398.

When `create.defaultTemplate: '@org'` is set, bare `vp create` now drops
into the org picker with a trailing "Vite+ built-in templates" escape-hatch
entry that routes to the existing `getInitialTemplateOptions` flow. This
preserves interactive discovery of `vite:monorepo` / `vite:application` /
`vite:library` / `vite:generator` without adding a new CLI flag; explicit
specifiers (e.g. `vp create vite:application`) remain the scripted bypass.

Addresses @cpojer's review feedback on #1398.

Let manifest entries use relative paths (`./templates/demo`) that resolve
against the enclosing @org/create package root, so orgs can ship one
package containing N templates instead of publishing N @org/template-*
packages — the pattern already used by create-vite, create-next-app, and
most enterprise scaffolding kits.

Vite+ fetches the tarball URL already returned by the registry manifest,
extracts it once per version into `$VP_HOME/tmp/create-org/<scope>/<name>/<version>/`,
and scaffolds by directory copy. Paths that escape the package root are
rejected at schema-validation time.

Addresses @fengmk2's review feedback on #1398 asking whether
`./templates/demo`-style bundled paths would be supported.

Two inline review findings from @fengmk2 on PR #1398:

- Bundled subdirectory section was leaking implementation details
  (tarball download mechanics, SHA-512 integrity verification, cache
  path under $VP_HOME, NPM_CONFIG_REGISTRY handling). Users just need
  to know that `./...` paths resolve against the @org/create package
  root and that the directory is copied verbatim. The rest belongs in
  the RFC.

- Non-interactive inspection section explained the design rationale
  for keeping the output machine-parseable ("so scripts and AI agents
  can recover the list without a separate `--list` flag"). That's an
  RFC-level decision; users just need to see the shape of the output.

The early-exit "template name is required" guard fired before
`getConfiguredDefaultTemplate` ran, so `vp create --no-interactive`
in a repo with `create.defaultTemplate: '@your-org'` exited with a
generic "template name required" message instead of reading the
configured default. The documented precedence (CLI arg >
create.defaultTemplate > interactive picker) was silently broken for
all non-interactive / CI usage.

Fix: move the guard to after the full resolution chain
(CLI arg → create.defaultTemplate → @org manifest). Only error if
`selectedTemplateName` is still empty once every input source has had
a chance to fill it. If the configured default is an @org scope, the
manifest resolver's own `--no-interactive` branch prints the manifest
table — exactly what a user expects when the config was supposed to
pick the org.

New snap-test `create-org-config-default` locks in the fix: a fixture
with `create: { defaultTemplate: '@your-org' }` in vite.config.ts
runs bare `vp create --no-interactive` and verifies the @your-org
manifest table prints instead of the generic missing-argument error.

Reported by Cursor Bugbot on #1398.

When a user types `vp create @org` expecting the picker but
`@org/create` has no `vp.templates` manifest, emit a one-line
`info:` note before falling through to run `@org/create` as a normal
package:

  No `vp.templates` manifest in @org/create — running it as a normal package.

Without this, a later `ERR_PNPM_DLX_NO_BIN` (the typical failure when
`@org/create` is data-only, as with `@eggjs/create`) looks mysterious
— the user has no way to know the picker was attempted and skipped.

Triggered only for scope-only input (`vp create @org`). The
per-entry form (`vp create @org/name`) stays silent because it's
ambiguous — the user might have genuinely wanted `@org/create-name`
via the existing shorthand.

Also helps diagnose registry-mirror sync lag: if a user's mirror
hasn't synced a just-published manifest, they now see "no manifest"
instead of the downstream dlx failure.

Reported by @fengmk2 on #1398 after `vp create @eggjs` in a monorepo
showed the monorepo parent-dir prompt and then `pnpm dlx @eggjs/create`
without ever running the picker.

Manifest entries like `{ template: '@your-org/template-web' }` were
passing through `discoverTemplate` → `expandCreateShorthand` and being
rewritten into `@your-org/create-template-web` — because the shorthand
rule targets any `@scope/name` that doesn't already start with `create-`.
The manifest author's literal package name was silently transformed,
causing vp to fetch the wrong package.

Fix: thread a `skipShorthand` flag through `discoverTemplate` that short-
circuits the final `expandCreateShorthand` call. Set it when
`resolveOrgManifestForCreate` returns `kind: 'replaced'` (the path
responsible for manifest-resolved specifiers). The earlier branches in
`discoverTemplate` (`vite:`, GitHub URLs, local workspace packages)
still match first, so manifest entries using those specifier kinds
behave unchanged.

Unit test added to `discovery.spec.ts` pinning both halves of the
contract: `@your-org/template-web` stays literal with the flag set,
and still expands via shorthand without it (the existing behavior
for non-manifest inputs).

Reported by Cursor Bugbot on #1398.

When the `--directory` guard was widened from `!isBuiltinTemplate` to
`!isDirectScaffoldTemplate` (to accept bundled @org templates alongside
builtins), the error text was left behind and still said "only available
for builtin templates". Users hitting it today are told --directory
doesn't work with bundled templates, even though it does.

Now reads: "only available for builtin and bundled @org templates".

Reported by Cursor Bugbot on #1398.

BREAKING (unpublished feature): the org-create manifest now lives at
`createConfig.templates` in `@org/create`'s package.json, replacing the
Vite+-specific `vp.templates` location.

Rationale (fengmk2 + cpojer, PR #1398 review): the manifest metadata is
tool-neutral (names, descriptions, template specifiers) and belongs under
a neutral field name. Following the precedent of npm's `publishConfig`,
`createConfig` reads as "configuration used specifically when this
package is consumed as a create initializer", leaving room for other
scaffolding tools to adopt the same convention later. Vite+-specific
behavior, if/when it's needed, can sit at `createConfig.vp.*` without
further schema changes.

Schema shape unchanged (name / description / template / keywords /
monorepo). Validation error messages now reference
`createConfig.templates[...]` instead of `vp.templates[...]`.

Updated: org-manifest reader and schema validator, RegistryVersionMeta
type, org-resolve info note, bin.ts help text, define-config JSDoc,
RFC manifest schema + field reference + resolution flow sections,
docs guide + config pages, root README, all 7 snap-test mock manifests
(and the bundled-fixture tarball + integrity hash), and the unit-test
regex that asserts the error path name.

BREAKING (unpublished feature): the manifest-entry selector uses `:`
instead of `/`. `vp create @your-org:web` now picks the `web` entry from
`@your-org/create`'s `createConfig.templates` manifest. The old
`@your-org/web` form is no longer a manifest lookup — it reverts to the
pre-feature `expandCreateShorthand` path that turns it into
`@your-org/create-web`, exactly as it worked before this feature.

Rationale (cpojer + fengmk2, PR #1398 review): the `/` form collides
with real npm packages. If `@your-org/web` exists on npm as a genuine
package, `vp create @your-org/web` would silently prefer the manifest
entry over the real package — confusing, and fragile. The `:` separator
mirrors the existing `vite:monorepo` / `vite:library` builtin-template
syntax, which users already read as "namespace:entry". It also keeps
manifest entries lexically distinct from any real npm package path.

Miss behavior: `vp create @org:foo` where `foo` isn't in the manifest
(or the manifest is absent) is a HARD ERROR listing the available
entries. No silent fall-through — the `:` form is an explicit manifest
lookup, and the fallback shorthand is reserved for the `/` form.

Updated: `parseOrgScopedSpec` parses only `@scope` and `@scope:name`
(returns `null` for `@scope/anything`), `resolveOrgManifestForCreate`
errors on direct-selection miss, CLI help text, RFC command matrix +
examples + error-handling table + compatibility section, docs guide +
config page, snap-test fixture commands (`create-org-bundled`,
`create-org-monorepo-direct-in-monorepo`), `--no-interactive` hint line,
and unit tests for `parseOrgScopedSpec` (new test pinning the null
return for the `/` form).

Removed the `prompts.log.info('selected ... from ...')` line that used
to precede every manifest-driven template resolution. Rationale
(cpojer, PR #1398): the clack picker already prints the selected entry
above in its completed-prompt line, so the info note was a redundant
restatement of what the user just picked a moment before.

Impact on downstream failure context (the original reason the
breadcrumb was added, via the Cursor "chosen template fails to resolve
with context" finding): for the interactive path, the picker's own
completed-prompt line still shows the selection. For the
non-interactive `@org:name` path, the error surfaces from the
downstream runner — no vp-side framing. If that proves confusing in
practice, we can add the breadcrumb back only in failure paths.

Snap regenerated for `create-org-bundled` (the only fixture that
captured the line). 265 unit tests still pass.

When `create.defaultTemplate: '@org'` is set, bare `vp create` now drops
into the org picker with a trailing "Vite+ built-in templates" escape-hatch
entry that routes to the existing `getInitialTemplateOptions` flow. This
preserves interactive discovery of `vite:monorepo` / `vite:application` /
`vite:library` / `vite:generator` without adding a new CLI flag; explicit
specifiers (e.g. `vp create vite:application`) remain the scripted bypass.

Addresses @cpojer's review feedback on #1398.

Let manifest entries use relative paths (`./templates/demo`) that resolve
against the enclosing @org/create package root, so orgs can ship one
package containing N templates instead of publishing N @org/template-*
packages — the pattern already used by create-vite, create-next-app, and
most enterprise scaffolding kits.

Vite+ fetches the tarball URL already returned by the registry manifest,
extracts it once per version into `$VP_HOME/tmp/create-org/<scope>/<name>/<version>/`,
and scaffolds by directory copy. Paths that escape the package root are
rejected at schema-validation time.

Addresses @fengmk2's review feedback on #1398 asking whether
`./templates/demo`-style bundled paths would be supported.

Two inline review findings from @fengmk2 on PR #1398:

- Bundled subdirectory section was leaking implementation details
  (tarball download mechanics, SHA-512 integrity verification, cache
  path under $VP_HOME, NPM_CONFIG_REGISTRY handling). Users just need
  to know that `./...` paths resolve against the @org/create package
  root and that the directory is copied verbatim. The rest belongs in
  the RFC.

- Non-interactive inspection section explained the design rationale
  for keeping the output machine-parseable ("so scripts and AI agents
  can recover the list without a separate `--list` flag"). That's an
  RFC-level decision; users just need to see the shape of the output.

The early-exit "template name is required" guard fired before
`getConfiguredDefaultTemplate` ran, so `vp create --no-interactive`
in a repo with `create.defaultTemplate: '@your-org'` exited with a
generic "template name required" message instead of reading the
configured default. The documented precedence (CLI arg >
create.defaultTemplate > interactive picker) was silently broken for
all non-interactive / CI usage.

Fix: move the guard to after the full resolution chain
(CLI arg → create.defaultTemplate → @org manifest). Only error if
`selectedTemplateName` is still empty once every input source has had
a chance to fill it. If the configured default is an @org scope, the
manifest resolver's own `--no-interactive` branch prints the manifest
table — exactly what a user expects when the config was supposed to
pick the org.

New snap-test `create-org-config-default` locks in the fix: a fixture
with `create: { defaultTemplate: '@your-org' }` in vite.config.ts
runs bare `vp create --no-interactive` and verifies the @your-org
manifest table prints instead of the generic missing-argument error.

Reported by Cursor Bugbot on #1398.

When a user types `vp create @org` expecting the picker but
`@org/create` has no `vp.templates` manifest, emit a one-line
`info:` note before falling through to run `@org/create` as a normal
package:

  No `vp.templates` manifest in @org/create — running it as a normal package.

Without this, a later `ERR_PNPM_DLX_NO_BIN` (the typical failure when
`@org/create` is data-only, as with `@eggjs/create`) looks mysterious
— the user has no way to know the picker was attempted and skipped.

Triggered only for scope-only input (`vp create @org`). The
per-entry form (`vp create @org/name`) stays silent because it's
ambiguous — the user might have genuinely wanted `@org/create-name`
via the existing shorthand.

Also helps diagnose registry-mirror sync lag: if a user's mirror
hasn't synced a just-published manifest, they now see "no manifest"
instead of the downstream dlx failure.

Reported by @fengmk2 on #1398 after `vp create @eggjs` in a monorepo
showed the monorepo parent-dir prompt and then `pnpm dlx @eggjs/create`
without ever running the picker.

Manifest entries like `{ template: '@your-org/template-web' }` were
passing through `discoverTemplate` → `expandCreateShorthand` and being
rewritten into `@your-org/create-template-web` — because the shorthand
rule targets any `@scope/name` that doesn't already start with `create-`.
The manifest author's literal package name was silently transformed,
causing vp to fetch the wrong package.

Fix: thread a `skipShorthand` flag through `discoverTemplate` that short-
circuits the final `expandCreateShorthand` call. Set it when
`resolveOrgManifestForCreate` returns `kind: 'replaced'` (the path
responsible for manifest-resolved specifiers). The earlier branches in
`discoverTemplate` (`vite:`, GitHub URLs, local workspace packages)
still match first, so manifest entries using those specifier kinds
behave unchanged.

Unit test added to `discovery.spec.ts` pinning both halves of the
contract: `@your-org/template-web` stays literal with the flag set,
and still expands via shorthand without it (the existing behavior
for non-manifest inputs).

Reported by Cursor Bugbot on #1398.