Decide the canonical npm target/release authority and source-to-registry cutover

[metaphorics]

Question

Five target tuples × two product surfaces (bamti API facade and bamti-cli CLI facade) are currently authored as independent literals in at least six overlapping places, with generator equality checks but no single source of truth:

1. npm/bamti/package.json optionalDependencies: five @bamti/bamti-* leaves (npm/bamti/package.json:84-89)
2. npm/bamti-cli/package.json optionalDependencies: five @bamti/cli-* leaves (npm/bamti-cli/package.json:29-35)
3. ten leaf manifests under npm/artifacts/* and the tarball staging area
4. generator scripts npm/scripts/{package-platform.mjs, package-native-platform.mjs, native-build-plan.mjs, stage-cli-artifacts.mjs, preflight.mjs, target-binary-identity.mjs, native-string-oracle.mjs}
5. workflow matrices .github/workflows/{native-release-build.yml, cli-release-build.yml, release.yml, native-string-oracle.yml}
6. loader target tables npm/bamti-cli/index.js:21-31 (CLI_TARGETS) and npm/bamti/native-loader.js:19-67 (NATIVE_TARGETS), plus native-release-table.json / cli-release-table.json produced at package time

The decision to make is: which one artifact is the authoring source for the target matrix, release fields (packageVersion, sourceCommit, buildSetId, releaseId, nativeAbi, cliProtocol), digest checks, and release-table schema version 1, and what is the exact source-manifest-to-registry cutover. Source manifests declare version 0.2.0; npm registry latest is documented as 0.1.0; these are distinct contracts until release evidence closes them (.outline/research/workspace-boundaries.md boundary inventory item 11).

Consumer evidence required

• Registry capture at decision time for bamti, bamti-cli, and all ten @bamti/* platform leaves: name, latest, published versions, dist-tags. Do not infer registry state from source manifests.
• Five-target build evidence for the pending 0.2.0 packages; README.md:35-55 documents this as currently blocked, so the decision must state what evidence unblocks it.
• Direct table consumers and their invariants: npm/bamti-cli/index.js artifact resolution, npm/bamti/native-loader.js optional-dependency fallback and hash validation (:7-67), npm/scripts/preflight.mjs table/manifest/digest checks, and the N-API run/releaseMetadata contract (crates/bamts-napi/src/lib.rs:52-53,274-318 per research snapshot; schema version 1, buildSetId/releaseId).
• Runner/toolchain/workflow revision pins embedded in CLI_TARGETS (runner: ubuntu-24.04, ubuntu-24.04-arm, macos-15-intel, macos-15, windows-2025) must be cross-checked against Ground every repository release pin #183's grounded release set.
• Any out-of-repo release automation consuming platform package names or release-table schema 1 must be positively accounted, or its unreachability and the resulting risk must be recorded (.outline/research/workspace-boundaries.md unresolved question 13).

Unresolved boundary channels

• Identity tuple agreement (.outline/research/workspace-boundaries.md invariant 8): version, source commit, build-set ID, ABI/protocol numbers, target tuple, digest, and canonical release ID must agree across Rust env, JS table, package manifest, workflow matrix, binary bytes, and addon metadata. Equality checks exist today; a single authoring source does not.
• Whether release.yml and native-string-oracle.yml participate in the same authority or are separate release-proof channels.
• dist-tag policy for publishing 0.2.0 while 0.1.0 is latest, and the rollback story from the registry side.

No-go conditions

• No republish, version flip, or source-to-registry cutover while the authority is duplicated or any facade/leaf lacks five-target build evidence and fail-closed digest/metadata checks.
• Generator equality checks or static search alone are not proof of single authorship.
• This ticket does not decide the target matrix content (capability matrix) or the admission/revocation policy; it decides authority and cutover mechanics only.

Observable acceptance

• Written decision naming exactly one authoring source (file + producing command) for target tuples, release fields, and release-table schema version; every other occurrence classified as generated output or deleted.
• Occurrence inventory (two facades, ten leaves, scripts, workflow matrices, loaders, N-API metadata) with each row labeled authority / derived / deleted.
• Registry capture artifact for the twelve npm names, dated and attached.
• Fail-closed preflight demonstrated: npm run preflight (or preflight:registry) fails when table, manifest, digest, or registry metadata disagree, with one named failure mode per check.
• Cutover plan that distinguishes 0.1.0 (published) from 0.2.0 (source) and lists the five-target evidence that must exist before npm publish.

Blocked by

• #159: Map crate dependencies and boundary consumers — research artifact that produced this boundary family and the consumer inventory.
• #168: Decide the published product facade — determines which npm packages and interfaces remain permanent, which is required before the distribution authority can be shaped.
• #178: Define release admission lifecycle — consumes the authority for target builds, package provenance, admission decisions, and the release ceremony.
• #183: Ground every repository release pin — supplies the runner/toolchain/workflow revisions the identity tuple must record.

[metaphorics]

Dependencies

This issue is blocked by:

• Map crate dependencies and boundary consumers #159 — Map crate dependencies and boundary consumers (research artifact that produced this boundary family and the consumer inventory)
• Decide the published product facade #168 — Decide the published product facade (determines which npm packages and interfaces remain permanent before distribution authority can be shaped)
• Define release admission lifecycle #178 — Define release admission lifecycle (consumes the authority for target builds, package provenance, admission, and the release ceremony)
• Ground every repository release pin #183 — Ground every repository release pin (supplies the runner/toolchain/workflow revisions the identity tuple must record)

Parent: #156. Feeds: #185.