refactor: model product dependencies and simplify qualification

.codex/skills/add-oliphaunt-extension/SKILL.md

@@ -11,7 +11,7 @@ Make support claims fail closed. A runtime target existing does not prove an ext
 
 - contrib: source is PostgreSQL 18. The SQL member belongs to the
   `oliphaunt-extension-contrib-pg18` logical distribution at
-  `src/extensions/contrib/`. It is not an independently versioned release
+  `extensions/contrib/`. It is not an independently versioned release
   product: its native and WASIX carriers belong to the corresponding runtime.
   A contrib member does not own a leaf `VERSION`, changelog, `release.toml`,
   tag, or registry identity.
@@ -25,7 +25,12 @@ Keep the SQL extension name distinct from the release product id and upstream pr
    metadata. For a public external extension, also maintain its product-local
    `release.toml`, `VERSION`, and empty first-release `CHANGELOG.md`. Every
    external extension must own
-   `upstream-license-data.json` beside that metadata. Freeze exactly the source
+   `upstream-license-data.json` beside that metadata. After changing source or
+   license pins, fetch the selected pinned sources and run
+   `moon run extensions:audit-license-sources` to compare the actual upstream
+   bytes. `extensions:packaging-unit` remains a cold-checkout packaging proof
+   and does not silently expand its coverage when a local source cache exists.
+   Freeze exactly the source
    identities and license/notice rows used by that extension, include only the
    referenced content-addressed blobs, and audit those bytes against the clean
    pinned checkout. Never put independently versioned extensions into one
@@ -35,7 +40,7 @@ Keep the SQL extension name distinct from the release product id and upstream pr
    When it does, record that reviewed endpoint as `mirror_url` and prove that
    it serves the exact pinned commit; never infer a mirror or use a community
    fork merely for availability.
-2. The canonical target profiles in `tools/release/extension-target-profiles.toml` apply to every extension on main. A target-specific exception is branch work until its format and shipped behavior are implemented together; do not add status, promotion, or blocker metadata.
+2. The canonical target profiles in `extensions/contracts/extension-target-profiles.toml` apply to every extension on main. A target-specific exception is branch work until its format and shipped behavior are implemented together; do not add status, promotion, or blocker metadata.
 3. For an active public product, declare the stable Cargo façade plus native,
    mobile, WASIX portable/AOT, npm, and Maven carriers actually required by the
    owning release product. Contrib members use the shared bundle carriers and
@@ -45,8 +50,7 @@ Keep the SQL extension name distinct from the release product id and upstream pr
 4. Regenerate the shared extension model:
 
 ```sh
-tools/dev/bun.sh src/extensions/tools/check-extension-model.mjs --write
-cargo run -p xtask -- assets verify-committed
+bash extensions/tools/check-extension-model.sh --write
 ```
 
 Source-pin, patch, recipe, compiler-input, or producer-code changes require the
@@ -56,16 +60,16 @@ target-profile edits are package-envelope changes.
 5. Verify the model and release graph:
 
 ```sh
-tools/dev/bun.sh src/extensions/tools/check-extension-model.mjs --check
-tools/dev/bun.sh tools/release/release-check.mjs
+bash extensions/tools/check-extension-model.sh --check
+bash tools/release/release-check.sh
 ```
 
 When source acquisition or `mirror_url` changes, also run the source-fetch
 fault suite, validate the real manifest, and perform one live exact-commit
 fetch from each newly declared endpoint. The canonical upstream must remain
 the durable origin and every transport must resolve to the same immutable pin.
 
-6. Build the exact extension artifacts for all declared targets. Require package-shape, archive safety, checksums, runtime load/create, restart, and dump/restore evidence where the target contract promises them. The exact-SHA CI lane must run `src/extensions/tools/collect-wasix-evidence.sh` against portable and host-AOT artifacts from that same workflow run. Only that collector may record `wasix-full-lifecycle-v1`; its immutable record must identify the exact commit, tree, workflow run, attempt, and job, and qualification must pass `--require-current-evidence`.
+6. Build the exact extension artifacts for all declared targets. Require package-shape, archive safety, checksums, runtime load/create, restart, and dump/restore evidence where the target contract promises them. The exact-SHA CI lane must run `extensions/tools/collect-wasix-evidence.sh` against portable and host-AOT artifacts from that same workflow run. Only that collector may record `wasix-full-lifecycle-v1`; its immutable record must identify the exact commit, tree, workflow run, attempt, and job, and qualification must pass `--require-current-evidence`.
 7. Run a clean local-registry install for each ecosystem façade. For a contrib
    bundle, select at least two members and prove that only those nested members
    are staged even though one target carrier contains all contrib bytes. Also

.codex/skills/qualify-oliphaunt-change/SKILL.md

@@ -5,101 +5,108 @@ description: Select, run, and diagnose Oliphaunt local and GitHub CI qualificati
 
 # Qualify Oliphaunt Change
 
-Use the repository graph to select work, but require the full exact-SHA gate for releases.
+Use the repository graph to select work and require exact-SHA qualification for releases.
+CI's `release_products_json` input selects stable product IDs and their Moon
+task/dependency closure. Keep platform selectors at `all`; a focused platform
+debug run cannot qualify publication. Empty product selection remains the
+exhaustive audit. Selected-product records must cover every published product;
+producer evidence still comes from the same candidate run.
+Generated same-repository Release PRs and their merged main release commits
+derive scope automatically from Release Please manifest changes. Main push
+qualifies only after Plan and Required succeed; PR results cannot be published.
 
 ## Local feedback
 
 1. Inspect the diff and ask Moon for affected projects/tasks. Do not infer affected products from directory names alone.
 2. Run affected formatting (`format-check`, `js-format-check`, or
-   `rust-format-check`), `lint`, `compile`, `unit`, and `package` tasks
-   independently. Run producer, smoke, regression, and E2E lanes only when
-   their inputs or public behavior changed.
-3. If the diff changes WASIX source pins, patches, build recipes, the toolchain,
-   or producer code, run the product-owned source checks and portable/AOT build.
-   Version, changelog, package-description, smoke-expectation, and
-   target-envelope-only changes do not require that expensive build.
+   `rust-format-check`), `lint`, `typecheck`, and `test` tasks as applicable.
+   Inspect the owner's actual task definitions before selecting `build`,
+   `package`, `test-consumer`, `test-integration`, `test-browser`, or installed
+   device tests. Let Moon build declared prerequisites; task names alone do
+   not justify running every available lane.
+3. If the diff changes a WASIX producer's source pins, patches, recipes,
+   toolchain or code, qualify that owner's affected portable/AOT output. Reuse
+   compiler outputs only when their declared source, dependency and toolchain
+   identities still match. A package envelope or test-only edit alone does not
+   justify rebuilding unrelated core, tools or extension producers.
 4. Select release-policy checks by the contract that changed:
 
 ```sh
 # Product/release metadata only:
 moon run release-tools:metadata
 
 # Release implementation changes:
-moon run release-tools:unit
+moon run release-tools:test
 
-# Moon/release graph topology changes:
+# Release Please candidate ownership/version selection changes:
 moon run release-tools:graph-unit
 
-# Repository policy implementation changes:
-moon run policy-tools:unit
+# Workflow and CI planning changes:
+moon run ci-workflows:check
 
-# Exact release candidate (metadata plus both unit suites):
-tools/dev/bun.sh tools/release/release-check.mjs
-
-# Committed generated runtime assets only:
-cargo run -p xtask -- assets verify-committed
+# Release metadata and release implementation tests:
+bash tools/release/release-check.sh
 
 # Extension catalog, recipe, carrier, or generated extension metadata only:
-moon run extensions:lint extensions:unit
+moon run extensions:lint extensions:test
 ```
 
-Do not run all three for an unrelated package or version edit. The repository
-release-policy gate runs structure, graph, metadata, and mutation checks; it is
-not product build/test/package qualification. `release-tools:check` is the local
-aggregate of metadata plus the release and policy unit suites. Hosted CI runs
-metadata on the publication host, gives workflow/planner tests to
-`ci-workflows:check`, and selects release or policy units only when their actual
-implementation inputs change. Exact release candidates require the combined
-runner in qualification; slim publishers consume that evidence instead of
-replaying source-only checks. Do not schedule both forms in one lane.
-The macOS publication-host metadata job is affected-only on pull requests and
-mandatory on exhaustive push/manual runs; product source alone does not justify
-that toolchain setup unless it changes release metadata or graph inputs.
-`tools/graph/ci_plan.mjs` writes `target/graph/ci-plan.json`; there is no
-`graph-tools` Moon project. Do not substitute policy unit tests: they prove the
-classifiers but do not scan the candidate tree.
+Select only the checks whose inputs changed. `release-tools:metadata` validates
+product versions, compatibility, carrier declarations and derived files;
+`release-tools:test` exercises release behavior; `graph-unit` exercises the
+pinned Release Please candidate integration. `release-tools:check` is their
+local Moon aggregate. There is no separate policy test project. The Shell
+aggregate runs metadata and release tests, not product compilation or installed
+consumer qualification. CI's `Checks / Policy` job runs on Ubuntu and sets up
+only capabilities needed by its selected tasks. Workflow planning, affectedness,
+artifact-transfer and security checks belong to `ci-workflows:check`.
+Publishers consume source qualification and frozen artifacts instead of
+replaying source-only suites. Do not schedule both aggregates and their
+constituent checks in the same lane.
+`tools/ci/ci_plan.mts` writes `target/graph/ci-plan.json`; there is no
+`graph-tools` Moon project. The adapter consumes Moon's selected tasks; its
+behavioral tests do not replace planning against the actual candidate tree.
+
+Ordinary source pushes, PR preparation and CI qualification do not select the
+protected `release-bootstrap` environment. Bootstrap-token lifecycle findings
+from the optional release-controls audit are setup/publication findings, not
+source-qualification blockers. Preserve the actual CI ref, permission and
+artifact checks; do not provision, remove or relabel registry credentials to
+make an unrelated source run pass.
 
 For source-acquisition policy or a source `mirror_url`, run
-`tools/dev/bun.sh test src/sources/tools/source-fetch-core.test.mjs` and
-`tools/dev/bun.sh src/sources/tools/fetch-sources.mjs all --validate-only`. Prove a
+`bash third-party/tools/source-fetch-core.test.sh` and
+`bash third-party/tools/fetch-sources.sh production-all --validate-only`, or the
+complete owner task `moon run source-inputs:test`. The paired Shell test owns
+actual Git/archive operations and invokes its TypeScript assertions once. Prove a
 new endpoint with a live exact-commit fetch, but keep reachability out of the
 deterministic unit gate. Qualification must show bounded canonical-to-mirror
 failover, exact-pin rejection, canonical durable origin, and transactional
 preservation of an existing checkout when every endpoint fails.
 
 5. For any workflow or local-action change, run
-   `bash tools/policy/check-workflows.sh` before waiting for CI. This is the
+   `bash tools/ci/check-workflows.sh` before waiting for CI. This is the
    repository's exact pinned `actionlint` plus `zizmor` gate and its workflow
    behavior tests; running `actionlint` alone is not sufficient. A disposable
-   `publish-dry-run` compiler probe is needed only when a release candidate
+   credential-free workflow compiler probe is needed only when a release candidate
    changes hosted-only job topology, permissions, protected environments, or
    dispatch inputs. The local gate cannot prove hosted environment-secret
    resolution or dispatch-time graph compilation.
-   When a changed release shell block is expected to run on macOS, run its
-   focused behavioral test with GNU Bash 3.2. Run the complete release-policy
-   gate under Bash 3.2 only for a release candidate. On macOS, omit the override;
-   elsewhere, point `OLIPHAUNT_BASH3` at a maintained local Bash 3.2 build:
-
-   ```sh
-   bash3="${OLIPHAUNT_BASH3:-/bin/bash}"
-   case "$bash3" in
-     /*) ;;
-     */*) bash3="$(cd "$(dirname "$bash3")" && pwd -P)/$(basename "$bash3")" ;;
-     *) bash3="$(command -v "$bash3")" ;;
-   esac
-   "$bash3" -c '((BASH_VERSINFO[0] == 3 && BASH_VERSINFO[1] == 2))'
-   PATH="$(dirname "$bash3"):$PATH" \
-     OLIPHAUNT_TEST_BASH="$bash3" \
-     "$bash3" tools/dev/bun.sh tools/release/release-check.mjs
-   ```
-
-   This behavioral gate is authoritative for Bash 3.2 `set -u` empty-array
-   semantics; a syntax check or a source-pattern check is not a substitute.
+   Exercise macOS-executed Shell paths with the Bash actually selected by that
+   job, recording `command -v bash` and `bash --version`. `shell: bash` alone
+   does not establish a version. Normal release/Apple setup does not install
+   another Bash; the WASIX postmaster target job explicitly installs Homebrew
+   Bash. Keep focused Bash 3.2 behavioral checks for scripts claiming macOS
+   `/bin/bash` compatibility, including `set -u` empty-array behavior. Do not
+   impose the entire Linux release-tool suite on Bash 3.2. Syntax checks do not
+   replace actual Apple transport or publication-path behavior.
 6. Declare runner capabilities on the narrowest Moon task that needs them. Use
    `requires-rust` for Cargo, rustc, rustfmt, or another Rust-toolchain command;
    `requires-maintainer-tools` for the pinned tools installed by
    `tools/dev/bootstrap-tools.sh`; and `requires-android-sdk` for Android SDK work.
-   Use `requires-apple` for Swift, Xcode, or Apple-platform work.
+   Use `requires-swift` for the portable Swift compiler; add `requires-apple`
+   only for Xcode, Apple frameworks, simulators or other Apple-only work.
+   Portable Swift source checks use the pinned Linux Swift setup.
    Capabilities propagate through task dependencies. The planner keeps
    capability-bearing checks grouped only with tasks requiring the same setup.
 7. Treat a hosted runner-image pin as a toolchain dependency. Never introduce a mutable `*-latest` alias; after changing an explicit runner pin, inspect the image delta and run the platform binary contract for every affected release target.
@@ -108,30 +115,35 @@ For a WASIX Docker, APT snapshot, or bootstrap trust change, also run the
 product-owned fault test and source verifier before the expensive build:
 
 ```sh
-bash src/runtimes/liboliphaunt/wasix/assets/build/docker/install-pinned-apt-packages.test.sh
-tools/dev/bun.sh src/sources/tools/fetch-sources.mjs wasix-runtime --verify-only
-cargo run -p xtask -- assets source-spine --strict-local
+bash third-party/tools/fetch-sources.sh wasix-runtime --verify-only
+moon run liboliphaunt-wasix:build-orchestration-test liboliphaunt-wasix:test
 ```
 
-Then build the pinned Dockerfile from a clean builder context. Require a
+Then use `liboliphaunt-wasix:compiler-output`, `runtime-portable` and
+`runtime-aot` for the actual selected producer proof. Optional PostgreSQL tools
+and extensions have separate owner producers; do not restore those as core
+runtime build prerequisites. For a Docker trust change, build the pinned
+Dockerfile from a clean builder context. Require a
 successful TLS-verified snapshot transaction and the exact declared wasixcc,
-Clang, and Binaryen versions; a source-spine/static check alone does not prove
+Clang, and Binaryen versions; a source/static check alone does not prove
 that the pinned trust chain still reaches the snapshot service.
 
-For an SDK change, run `moon run sdk-contracts:all`, then run each affected
-SDK's `compile`, `unit`, and `package` tasks in one Moon invocation. These tasks
-are independent; `package` does not silently rerun source qualification. Set
+For an SDK change, run each affected
+SDK's relevant source checks, `test`, and `package` tasks in one Moon invocation.
+Their declared dependencies remain necessary; `package` does not silently rerun
+unrelated source qualification. Set
 `MOON_BASE` and `MOON_HEAD`, inspect affected SDK projects, and pass the exact
 targets to `moon run`; a workspace-wide selector also selects non-SDK products.
 Confirm ownership with `moon query tasks --project <sdk-project>` when changing
 task topology. Never replace the product task with a narrower native command:
-for example, `cargo test -p oliphaunt --lib` excludes Rust executable tests under
-`src/bin/**`, while `moon run oliphaunt-rust:unit` includes the library,
-executable, integration, build-crate, and documentation tests. Add
-the product's `qualify` task when the complete product replay is needed, and run
-`moon run extensions:lint extensions:unit` when an extension catalog or generated SDK
+for example, `cargo test -p oliphaunt --lib` omits other Cargo targets selected
+by the owner task. Carrier producers copy the canonical C header; real consumers
+compile against it instead of running a separate layout gate. Add
+the product's explicit runtime or installed-host tests when that proof is needed, and run
+`moon run extensions:lint extensions:test` when an extension catalog or generated SDK
 extension surface changes. Put new guarantees in a parsed schema/generated
-contract, clean-consumer package check, or product-owned behavioral test. Do
+contract where consumers require one, a clean-consumer package check, or a
+product-owned behavioral test. Do
 not qualify SDK behavior by grepping prose, test names, or
 implementation-source spellings.
 
@@ -153,7 +165,7 @@ implementation-source spellings.
   the final `main` SHA. Do not also create a push run: non-PR runs for the same
   SHA serialize rather than cancel one another.
 - The release prerequisite is the non-cancelled `Qualified` gate for that SHA, including required checks, builds, policy, tests, and selected E2E.
-- When WASIX or an extension is selected, require the same-run full lifecycle evidence artifact. It must cover every catalogued extension in direct, server, restart, materialization, and dump/restore modes and satisfy `--require-current-evidence` for the candidate source digest.
+- When WASIX or an extension is selected, require the same-run full lifecycle evidence artifact. It must cover every catalogued extension in direct, server, restart, materialization, and physical backup/restore modes and satisfy `--require-current-evidence` for the candidate source digest.
 - Ensure artifact attestations and the publication lock reference the same SHA/tree.
 - Require artifact evidence for the compatibility floors in
   `docs/maintainers/release.md`: inspect Mach-O load commands, Android API/ELF