# Standard Node Starter Acceptance

The standard Node starter is a generated consumer project, not a copy of the
checked-in Operator integration application. The `STANDARD_NODE_STARTER` export
and its `standard-node-starter.json` source are the canonical shape.
`scripts/package-starters.mjs` generates that shape, and
`scripts/check-operator-application.mjs` packages and inspects the actual
output so generator changes cannot bypass the acceptance gate.

A fresh starter has exactly five authored files:

```text
.env.example
.gitignore
package.json
voyant.config.ts
src/scripts/seed.ts
```

The generator also creates empty, optional project-convention directories for
admin and public APIs, admin UI, modules, extensions, workflows, jobs,
subscribers, and links. It also creates `src/scripts` for the seed entry, which
is the only initial project source file.

The gate requires:

- `voyant.config.ts` contains only the Node deployment target and database
  provider choice; it contains no standard modules, extensions, or plugins.
- `package.json` delegates development, build, startup, migrations, and script
  execution to `voyant develop`, `voyant build`, `voyant start`, `voyant migrate`,
  and `voyant exec`. It does not expose graph, Vite, artifact-copy, or direct
  Node bootstrap implementation details.
- The project names only the CLI, framework, standard product distribution, and
  runtime as Voyant dependencies.
- `voyant.node-starter.v3` provides exact, key-complete runtime and development
  dependency coordinate maps. Self-host generators consume those coordinates
  directly and must never fall back to mutable registry tags such as `latest`.
- Packaged starters inherit the supported CLI semver range from the checked-in
  starter; the starter archive version never doubles as the CLI version.
- `.gitignore` protects `.voyant/`, `dist/`, `node_modules/`, and local env files
  while keeping `.env.example` tracked.
- no package-owned OpenAPI documents, migrations, links, subscribers, jobs,
  workflows, admin entries, or API routes are copied into the project.
- optional project migrations remain beside their owning local module and are
  generated by that module's ORM tooling; the starter has no aggregate schema or
  root migration history.
- no first-party package identifier appears in authored project source.
- the five-file authored-tree ratchet is exact. New initial files require an
  intentional architecture decision and checker update.
- a project may add a standard root `vite.config.ts` only when it needs custom
  Vite plugins or options. Both `voyant develop` and `voyant build` must merge
  that file without requiring custom scripts or a fork of generated metadata.
  The lifecycle-owned `build.outDir` remains `dist` so server, client, and graph
  artifact paths cannot diverge.

The product BOM still expands into an explicit `.voyant/` graph during build.
The checked-in `apps/operator` tree is a monorepo integration application,
not a second starter authority. It follows the same ownership rule for build
metadata: the repository verification lane deterministically writes its ambient
bindings, bounded client/server TypeScript programs, and Vite/Vitest entries
beneath `.voyant/`.
Its production manifest is also deterministic: authored lifecycle commands,
third-party dependencies, and application-host dependencies live in
`package.intent.json`; `generate-operator-application-manifest.mjs` adds the
first-party closure selected by `@voyant-travel/operator-standard` and emits
`package.json`. Both standalone verification and the standard-product generator
check the same generator output, so no second hand-maintained closure exists.
The declaration path maps are rebased from the shared TypeScript config and are
not consumer-authored files. A starter-local `turbo.json` is unnecessary because
the workspace root already owns task orchestration.

`check-operator-application.mjs` rejects restored root copies of those files
and requires `.voyant/` to remain ignored. `measure-operator-application.mjs`
reports checked-in metadata count and bytes and verifies the generated product
BOM, resolved graph, deployment artifacts, and migration plan alongside bundle
and boot measurements. After a production build, it reads the durable metadata
copy from `dist/.voyant/` if the workspace staging directory has already been
cleaned.

The source-level gate does not replace runtime acceptance or performance
evidence. Release confidence additionally requires the packaged starter to
install, emit its graph, boot the Node host, exercise local convention files,
and record boot time, server bundle size, and admin chunking in CI.