diff --git a/docs/superpowers/plans/2026-10-06-split-integrations-crates-implementation-plan.md b/docs/superpowers/plans/2026-10-06-split-integrations-crates-implementation-plan.md
new file mode 100644
index 000000000..e5246907e
--- /dev/null
+++ b/docs/superpowers/plans/2026-10-06-split-integrations-crates-implementation-plan.md
@@ -0,0 +1,224 @@
+# Split Integrations into Dedicated Crates Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Move all concrete Rust and browser integrations into two statically linked crates, then make one ordered `[integrations]` configuration the operator inventory.
+
+**Architecture:** Milestone 1 introduces neutral core contracts, one Rust composition root, and separately owned browser artifacts while retaining the current operator/storage schema and behavior through one temporary normalizer. Milestone 2 replaces only the source schema and ordering contract, adds stored schema 2 with explicit order sidecars and a read-only schema-1 decoder, and cuts over each adapter only after its rollback gate passes.
+
+**Tech Stack:** Rust 2024, Cargo workspace, EdgeZero, Fastly/Axum/Cloudflare/Spin adapters, TOML 1.1, serde, Node 24, TypeScript, Vite, Vitest, Playwright.
+
+**Spec:** `docs/superpowers/specs/2026-09-17-split-integrations-crates-design.md`
+
+**Tracking:** [Issue #1237](https://github.com/IABTechLab/trusted-server/issues/1237), [draft design PR #1194](https://github.com/IABTechLab/trusted-server/pull/1194).
+
+---
+
+## Execution rules and entry gate
+
+This is an implementation plan, not permission to start extraction from the spec worktree. As checked on 2026-10-06, draft PR #1194 is at `c6c34cdcd`, remote `main` is `7f610c0fc`, and the spec checkout still pins EdgeZero v0.0.8. The final implementation baseline is **not** either of those commits. Start a fresh implementation worktree from the post-prerequisite `origin/main`; do not merge the spec branch's old source tree into it. Re-read `AGENTS.md` there.
+
+Before Task 1, prove that independent fixes for #1098, #1196, #1198, #1199, #1200, #1202, #1203, #1204, and #1208 have landed with their focused tests. #1197 is closed, but the broader set-valued serialization audit remains an evidence gate. Confirm #1206/#1207 are resolved by #1208; #1201 belongs to milestone 2; #1205's hidden-first-phase remedy is rejected. Confirm the reviewed EdgeZero typed-config hook and environment-selector revision is available before Task 8. If any requirement is absent, stop that dependent task and land the prerequisite separately. Do not absorb a baseline bug fix into a rename commit. Record the exact `origin/main`, EdgeZero revision, test results, and output-golden hashes in the first implementation PR.
+
+Use the same public API manifest for every extraction commit. Every new/widened/removed symbol must have an owner, direct consumer, stability class, and (if transitional) removal step; an unlisted symbol needs a spec amendment. One active Rust catalog and one browser manifest exist at every revision; a transitional delegation replaces, rather than duplicates, an owner. No per-vendor crate, plugin ABI, runtime loading, second operator inventory, or unrelated audit-code reorganization.
+
+For each task below: write the named failing test or guard first; run it and record the expected failure; make the smallest change; run the focused target-matched command and the neighboring regression set; inspect `git diff --check`; commit one independently reviewable change using the repository's sentence-case imperative convention. The exact path list is based on the reviewed checkout and must be rechecked against the recorded post-prerequisite baseline before editing.
+
+## File and ownership map
+
+| Owner                | Create or change                                                                                                                                                                                                                            | Responsibility                                                                                                                                                                                                    |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Neutral Rust         | `crates/trusted-server-core/src/integration/{mod,registry,claims,browser_assets,processing}.rs`; `auction/{plan,profile,provider,orchestrator}.rs`; `config_payload.rs`, `settings_data.rs`, `publisher.rs`, `html_processor.rs`, `tsjs.rs` | Typed contracts, plan compilation/execution, verified envelopes, neutral processing and browser-asset consumption; no concrete imports. Keep files split by responsibility rather than growing one registry file. |
+| Rust application     | `crates/trusted-server-integrations/{Cargo.toml,src/lib.rs}`, `src/{catalog,composition,config,legacy_config,source_config,validation,secret_metadata}.rs`, `src/integrations/<id>/mod.rs`                                                  | Static definitions, concrete implementations, source views, schema conversion, validation, and final composition. `source_config` is host-feature-gated.                                                          |
+| Neutral browser      | `crates/trusted-server-js/{build.rs,src/bundle.rs}`, `lib/src/core/`, `lib/src/shared/`, `lib/package.json`, `lib/{build-all.mjs,tsconfig.json,vitest.config.ts,eslint.config.js}`                                                          | One versioned runtime facade, core IIFE/finalizer, canonical Node project, neutral owner-private artifacts.                                                                                                       |
+| Integration browser  | `crates/trusted-server-integrations-js/{Cargo.toml,build.rs,src/lib.rs}`, `lib/src/integrations/`, `lib/test/integrations/`                                                                                                                 | Integration IIFEs, inline programs, owned fixtures/tests, typed asset catalog and private artifacts.                                                                                                              |
+| App edges            | `crates/trusted-server-adapter-{fastly,axum,cloudflare,spin}/src/app.rs`, Fastly `src/main.rs`, `crates/trusted-server-cli/src/{app_config,run,prebid_bundle}.rs`                                                                           | Exactly one composition call per loaded config; source/deploy command views and target gates.                                                                                                                     |
+| Cross-cutting checks | `Cargo.toml`, `.cargo/config.toml`, `.github/workflows/{format,test,integration-tests}.yml`, `crates/trusted-server-integration-tests/`, `scripts/`, `docs/guide/`, `trusted-server.example.toml`                                           | Target-matched gates, real embedded-artifact tests, parity, rollout evidence, docs and stale-path guard.                                                                                                          |
+
+The names in the new crates are responsibility boundaries, not a requirement to create empty placeholder modules. Create each file when its first consumer and test arrive. Keep the existing Next.js nested implementation and fixtures together; leave neutral `ec/prebid_eids.rs` in core.
+
+## Milestone 1 — crate boundary with schema-one behavior
+
+### Task 1: Freeze the corrected baseline and public surface
+
+**Files:** Create `crates/trusted-server-integration-tests/tests/integration_split_baseline.rs` and a reviewed output-golden directory under `crates/trusted-server-integration-tests/fixtures/integration_split_baseline/`; create `scripts/check-integration-api-delta.sh` and its checked-in manifest; modify only baseline-test selectors in `.github/workflows/integration-tests.yml`.
+
+- [ ] Add differential cases for every current Rust definition and browser module, globally interleaved APS/Prebid/standard provider IDs, deferred Prebid, GPT diagnostics, Next.js/GTM/RSC, #1135, routes, trusted script attributes, CLI views, and relevant failure classifications. Store actual corrected-baseline output bytes and separate artifact hashes; do not hand-author expected runtime output.
+- [ ] Run the harness against recorded post-prerequisite `main` twice. Expected: byte-identical behavior goldens; artifact hashes may be recorded separately. Prove each golden fails after a deliberate test-only mutation to its observed output, then restore the mutation.
+- [ ] Capture the current public core symbol snapshot and write an explicit delta manifest for the spec's three classes. Test that an undeclared added/removed public item fails the guard, then restore the canary.
+- [ ] Verify deterministic serialization by repeatedly parsing a fixture with at least two values in every set-valued field and comparing envelope SHA and template identity. If it fails, stop for the standalone prerequisite fix.
+- [ ] Commit the baseline evidence and its exact commit/toolchain/EdgeZero pins. Do not proceed if a prerequisite output defect is still present.
+
+### Task 2: Introduce neutral registration, claims, and plan inputs
+
+**Files:** Create `crates/trusted-server-core/src/integration/{mod,registry,claims}.rs`; modify `crates/trusted-server-core/src/{lib.rs,integrations/registry.rs,integrations/mod.rs,auction/plan.rs,auction/profile.rs,auction/provider.rs,auction/mod.rs}`; test in those modules.
+
+- [ ] Write compile/runtime tests for `IntegrationRegistry::from_registrations`, capability-local order, duplicate/reserved route and script claims, and a flat ordinal-bearing provider sequence independent of lookup-map order. Expected initially: missing contracts or wrong order.
+- [ ] Add `IntegrationDeclaration` and only the typed capabilities consumed by current implementations; make the registry accept registrations rather than constructing APS/Prebid or calling `builders()`. Keep the old fixed builder table as the sole schema-one source until the new composition root owns it.
+- [ ] Introduce neutral profile and prepared exchange-or-skip contracts, a consuming bound response parser, renderer descriptors, transport-header view, and mediator registration. Remove vendor enum/downcast/constructor knowledge from core without changing OpenRTB wire bytes or the #1159 skip/admission matrix.
+- [ ] Run `cargo test-fastly`, `cargo test-axum`, and the baseline differential harness. Expected: schema-one provider order and externally visible local labels match the golden. Run the API-delta guard and commit the neutral seam separately from any source moves.
+
+### Task 3: Move lifecycle decisions behind neutral processing requirements
+
+**Files:** Create `crates/trusted-server-core/src/integration/processing.rs`; modify `crates/trusted-server-core/src/{html_processor,publisher,cookies,cache_policy,response_privacy}.rs` and `crates/trusted-server-adapter-{fastly,axum,cloudflare,spin}/src/app.rs` plus Fastly `src/main.rs`.
+
+- [ ] Write failing matrices for DataDome origin/body/privacy requirements, GPT diagnostics preparation/finalization and cache vetoes, reserved Cookie/query normalization even when diagnostics is absent, and request-local mutable document state. Include every adapter's existing fallback and health behavior.
+- [ ] Add narrow neutral per-request requirements and document-state factories. Make core apply requirements and fixed parser phases without importing `datadome` or `gpt_diagnostics`; keep current concrete implementations in their original owner until their individual move.
+- [ ] Move fixed GPT-diagnostics input cleanup to the neutral ingress boundary. Preserve lenient Cookie handling and all-response privacy before cache/origin selection; integration requirements may only restrict baseline cache decisions.
+- [ ] Run focused core module tests, `cargo test-fastly`, `cargo test-axum`, `cargo test-cloudflare`, `cargo test-spin`, and API/differential guards. Commit the lifecycle seam before moving DataDome or GPT diagnostics.
+
+### Task 4: Establish the one browser build lease and two-root toolchain
+
+**Files:** Create `scripts/with-browser-lease.mjs` and its tests; modify `crates/trusted-server-js/lib/{package.json,tsconfig.json,vitest.config.ts,eslint.config.js,build-all.mjs}`, `.github/workflows/{format,test,integration-tests}.yml`, `Cargo.toml`, `.cargo/config.toml`.
+
+- [ ] Add failing lease tests for outer and authenticated nested invocations, absent/wrong nonce, holder PID reuse, a live orphan child, stale recovery, and direct tool invocation. A nested `Cargo build → runner → npm → runner → Node` path must complete without deadlock.
+- [ ] Implement one atomic-directory lease rooted at the canonical Node project. Keep the lock while the complete child process scope lives. Fail closed when ownership cannot be proven dead; no per-crate locks. Put `npm ci`, Vite, Vitest, TypeScript, ESLint, Prettier, Cargo browser builds, and Prebid bundle behind this runner.
+- [ ] Configure the canonical package at `crates/trusted-server-js/lib` to resolve both source roots and `prebid.js` exports. Add production two-root `typecheck`, isolated failing canary, explicit test/lint/format globs, and exact GPT-bootstrap legacy formatter/linter exceptions. Keep one lockfile.
+- [ ] Run runner unit tests and wrapped `npm run typecheck`, `npm run test`, `npm run lint`, `npm run format`. Expected: both roots are selected and the canary fails only in its isolated negative test. Commit tooling before moving browser files.
+
+### Task 5: Define the versioned browser facade and neutral APS/queue seams
+
+**Files:** Create focused facade/IDL/ABI snapshot and tests under `crates/trusted-server-js/lib/src/core/` and `lib/test/core/`; modify `lib/src/core/{index,auction,request,queue,registry}.ts`, `lib/src/shared/dom_insertion_dispatcher.ts`, `lib/src/integrations/{aps,gpt,prebid,permutive,testlight}/` only where required by the seam.
+
+- [ ] Write production-artifact tests proving one `window.tsjs`/first-impression service, Permutive context and log state across IIFEs, APS renderer registration without a core APS import, GPT pre-core adoption, Prebid deferred version mismatch rejection, and idempotent listener/queue behavior. Pin exact ABI IDL, generated record bytes, immutable published snapshot, and mismatch-before-initializer guards.
+- [ ] Move shared state and stateful APIs behind a versioned facade; keep type-only cross-root imports and the one declared neutral bootstrap-safe GPT input. Do not duplicate core state inside IIFEs or change the #1191 first-impression algorithm.
+- [ ] Replace numeric/lexical DOM-handler priority with synchronous registration order. Derive immediate-only DOM need from the dedicated accessor import; reject deferred use. Install the CSP-compatible neutral external queue finalizer after fixed synchronous post-unified assets, preserving success/failure fallback paths.
+- [ ] Run wrapped browser Vitest, production typecheck, facade ABI/artifact tests, and the corrected #1196/#1199/initial-render golden cases. Commit the facade and dispatcher before relocating any browser owner.
+
+### Task 6: Split browser artifact ownership
+
+**Files:** Create `crates/trusted-server-integrations-js/{Cargo.toml,build.rs,src/lib.rs}` and the empty Rust crate shell `crates/trusted-server-integrations/{Cargo.toml,src/lib.rs}`; create owner-specific build modules under `crates/trusted-server-js/lib/`; modify `crates/trusted-server-js/{build.rs,src/bundle.rs}`, `Cargo.toml`, `.cargo/config.toml`.
+
+- [ ] Write failing clean/incremental/concurrent build tests: changing one integration source changes only its owner manifest/hash; changing the neutral first-impression input changes GPT's bootstrap input; stale or partial output and missing npm fail. Discovery includes every `index.ts` regardless of immediate, deferred, or standalone load mode.
+- [ ] Build neutral core/finalizer and integration IIFEs/assets into separate private Cargo `$OUT_DIR` targets. Generate typed module IDs and exact-byte/hash catalogs; validate complete artifact-affecting input manifests, `TSJS_SKIP_BUILD` freshness, and Cargo rerun environment inputs. No shared `dist` scan or copy.
+- [ ] Keep one explicit temporary browser manifest pointing to unmoved source paths, then replace each mapping in Task 11; do not copy an unused duplicate source tree. Create both new Cargo members and update target-matched aliases in this change.
+- [ ] Run wrapped build/test/typecheck and owner-manifest tests, then `cargo check-fastly`, `cargo check-axum`, `cargo check-cloudflare`, `cargo check-spin`. Commit the build split; Task 9 exports exact composed bytes for browser harnesses after the composition root exists.
+
+### Task 7: Make neutral core consume composed browser assets
+
+**Files:** Create `crates/trusted-server-core/src/integration/browser_assets.rs`; modify `crates/trusted-server-core/src/{publisher,tsjs,html_processor}.rs` and `crates/trusted-server-js/src/bundle.rs`; test in core, integration tests, and browser harnesses.
+
+- [ ] Write failing tests for core/creative/immediate/fixed synchronous/finalizer/deferred/standalone order, exact static bytes and hashes, stale `?v=` response behavior, trusted attributes, APS immediacy, and cache fingerprint invalidation when an inline or external asset changes.
+- [ ] Introduce `CompiledBrowserAsset` and `BrowserDocumentAssets` as neutral byte/hash/order inputs. Add and test injection-capable core serving, script-tag, and HTML APIs while the existing production caller remains the sole active asset source until Task 9's atomic composition switch. Core must never link `trusted-server-integrations-js` or look up a concrete module by unchecked string.
+- [ ] Implement the spec's unambiguous document fingerprint and pure composition-digest function with an injected full artifact build ID. Pin raw-byte, length-framing, attribute, asset-order, and secret-reference vectors. Keep the corrected #1198 cache key active until Task 9 assembles the full adapter ID; do not replace it with a core-only digest.
+- [ ] Run focused core tests, browser artifact vectors, template-cache smoke, and the baseline differential harness. Commit this neutral consumption boundary before adapter composition changes.
+
+### Task 8: Add the Rust composition root while retaining schema one
+
+**Files:** Fill `crates/trusted-server-integrations/src/lib.rs`; create `src/{catalog,composition,config,legacy_config,source_config,validation,secret_metadata}.rs`; modify `crates/trusted-server-core/src/{config,config_payload,settings_data,integrations/registry}.rs`, `Cargo.toml`, `.cargo/config.toml`, `Cargo.lock`.
+
+- [ ] Before edits, verify the reviewed EdgeZero `run_*_typed_with_hooks` revision is available and repin all `edgezero-*` dependencies together. Add tests proving one exact config read/value across pre-pass, overlay, validation, serialization, diff, and push, including source replacement and `--no-env`. If the extension is absent, stop; do not substitute filesystem snapshots.
+- [ ] Write failing catalog completeness and schema-one differential tests. The catalog initially has one entry per current definition, each delegating to the old owner through an explicit transitional export. One legacy converter preserves omitted-default behavior, fixed builder sequence, globally lexical flat provider order, implicit APS, current local external labels, and baseline unknown-ID acceptance.
+- [ ] Move `TrustedServerAppConfig`, catalog-owned secret metadata/validation, inactive integration-secret preprocessing, and source/partial/validated views outward. Keep only neutral envelope/chunk verification, global settings, global inactive-secret preprocessing, secret primitives, and plan compilation in core. Add `CompositionAttempt` with the exact settings-capture stage specified in the design.
+- [ ] Reuse the prerequisite canonical generator from core build support to emit labeled raw component digest records for core, OpenRTB, both browser embedding crates, and the integrations crate. Each crate records its own authoritative source/build inputs and forwards direct runtime workspace dependency records; conflicting duplicate labels fail. Do not read another crate's `$OUT_DIR`.
+- [ ] Make the new root produce one settings/plan/orchestrator/registry/assets/target/digest composition in focused tests, without activating a second production catalog. Leave deletion of core's `builders()`/concrete `with_plan` path to Task 9's atomic consumer switch. Add neutral core test stubs behind `test-utils`; do not create a dev-dependency cycle.
+- [ ] Run `cargo test -p trusted-server-integrations`, `cargo test-fastly`, `cargo clippy-fastly`, API/differential guards, and `cargo tree -p trusted-server-core` to prove no reverse dependency. Commit the inert composition root separately from owner moves.
+
+### Task 9: Rewire every adapter, loader, and CLI command to that root
+
+**Files:** Modify four adapter `src/app.rs` files, Fastly `src/main.rs`, `crates/trusted-server-cli/src/{app_config,run,prebid_bundle}.rs`, `src/commands/{config/ad_templates,audit/ad_templates,audit/generate/validate}.rs`, `crates/trusted-server-integration-tests/src/bin/generate-viceroy-config.rs`, `tests/common/config.rs`, and their tests; create `crates/trusted-server-integration-tests/src/bin/export-browser-artifacts.rs`; modify `browser/tests/shared/aps-renderer.spec.ts`, `browser/initial-render/run.cjs`, `scripts/{integration-tests-browser,template-cache-local-test}.sh`.
+
+- [ ] Write failing tests for each adapter's verified-byte source, config location, missing/unpropagated versus corrupt data, Fastly JA4/settings-only failed-startup path, and unchanged adapter health/status matrix. Add a test that no adapter reconstructs plan, registry, browser assets, or digest.
+- [ ] Replace direct core config/catalog imports with the integrations facade. Keep one resolved config location and one verified byte source; pass the staged composition result to existing route construction. Fastly alone changes post-store-open missing root/chunk to transient 503, never partial decode; early store-open and JA4 failures stay 500.
+- [ ] Give each adapter its own component record, collect the transitive runtime workspace records after static linking, and compute the spec's artifact-specific `build_id`. Add a target-matched `cargo metadata` graph test for each adapter that rejects missing/extra/conflicting labels and a perturbation test for adapter, OpenRTB, integration, browser, compiler/flag, and root-workspace inputs. Only then switch the publisher template key to the full composition digest while preserving its existing URL, host, scheme, cookie, Vary, and schema dimensions.
+- [ ] Extract each adapter's fixed route registrations into a checked method/path/pattern manifest and derive the corresponding reserved claims from it. Add a parity test comparing actual router registration, precedence, and fallthrough against claims, including Fastly-only routes, Cloudflare's publisher fallback, and all cache-purge methods. Reject an integration claim that collides with any fixed route before startup.
+- [ ] Route CLI read-only commands through `SourceConfigView`, recovery mutators through bounded `PartialSourceConfigView<T>`, and deploy commands through `ValidatedSourceConfig` plus selected-target validation. Add repeatable `config validate --adapter` while preserving EdgeZero `--strict`. Move Prebid typed module requirements out of CLI schema; retain atomic, non-disclosing staging writes.
+- [ ] In one atomic review unit, switch the CLI, all adapters, Viceroy generator, and parity helper to the facade/storage serializer and remove core's old concrete `builders()`/`with_plan` and asset lookup paths. Run CLI, all four adapter tests, Viceroy parity, failed-startup cases, and differential goldens. No revision may have two active catalogs or loaders.
+- [ ] Add the host-only test exporter now that composition exists: for an explicit fixture, emit exactly its embedded bytes, hashes, IDs, and load phases to a fresh directory. Point out-of-Cargo browser harnesses at its manifest, verify every hash, and remove newest-file/shared-`dist` selection. Run exporter and browser tests before committing this separate tooling change.
+
+### Task 10: Move the fifteen concrete Rust owners and their tests
+
+**Files:** Move `crates/trusted-server-core/src/integrations/{adserver_mock,aps,datadome,didomi,google_tag_manager,gpt,gpt_diagnostics,js_asset_proxy,lockr,nextjs,osano,permutive,prebid,sourcepoint,testlight}` into same-named directories under `crates/trusted-server-integrations/src/integrations/`; add `openrtb/mod.rs`; modify both crates' `lib.rs`, catalog, test support, and migration guards.
+
+- [ ] For each ordinary owner, add a failing catalog/behavior test, move its code and fixtures with a rename-focused diff, remove exactly its transitional export, run its focused tests and API guard, then commit. Suggested independent batches: simple page owners; Next.js/GTM/script claims; DataDome/GPT diagnostics after Task 3; APS/Prebid after Task 2; `adserver_mock` after mediator contracts.
+- [ ] Add the built-in Rust-only `openrtb` definition for the current standard profile. End with exactly sixteen catalog entries, one directory per Rust definition, and no concrete import in core. JavaScript-only `creative` remains a fixed prelude, not a Rust definition.
+- [ ] Move integration-owned test fixtures/helpers outward; replace core tests needing the real catalog with neutral registrations and an integration-owned production-catalog test factory. Move the complete Fastly-SDK guard over moved sources, including nested Next.js, without weakening neutral core checks.
+- [ ] After every batch run `cargo test -p trusted-server-integrations`, `cargo test-fastly`, `cargo clippy-fastly`, completeness/API/path guards, and the differential harness. At the end run native/WASM target checks and prove the transitional Rust-export set is empty.
+
+### Task 11: Move every concrete browser owner, inline program, and test
+
+**Files:** Move `crates/trusted-server-js/lib/src/integrations/` and `lib/test/integrations/` into `crates/trusted-server-integrations-js/lib/`; move integration-owned fixtures from `lib/test/fixtures/` case by case; move `crates/trusted-server-core/src/integrations/gpt_bootstrap.js` and integration-owned executable inline programs to their browser owner; modify `lib/build-all.mjs`, `lib/build-prebid-external.mjs`, `crates/trusted-server-cli/src/prebid_bundle.rs`, and owned Rust includes.
+
+- [ ] For each owner, first add a failing wrapped Vitest/artifact/load-order case, move source and tests with a rename-focused diff, remove its legacy manifest path, run wrapped build/typecheck/lint/format/test and the exporter-based production-artifact check, then commit. Keep owner-specific fixtures with their owner; leave cross-adapter Playwright/parity in the integration-test crate.
+- [ ] Move APS renderer document and GPT bootstrap with their existing CSP/header behavior; audit Sourcepoint, GPT diagnostics, DataDome, Didomi, GPT, Prebid, and Sourcepoint executable inline inputs. Browser core retains no concrete APS import and Rust retains no handwritten production integration browser algorithm.
+- [ ] Make `ts prebid bundle` resolve one canonical package root and all sibling source realpaths in the same checkout, preserve package exports and managed User ID/analytics selection, and prove a two-worktree test cannot use a compile-time path from another checkout.
+- [ ] Run wrapped JS gates, APS/Prebid/GPT production artifact tests, Playwright initial-render and shared suites, all adapter parity tests, and the differential harness. Prove every moved test is selected, the legacy browser manifest path set is empty, and no duplicate unused source tree remains.
+
+### Task 12: Exit milestone 1 only with schema-one parity
+
+**Files:** Modify `.cargo/config.toml`, `.github/workflows/{format,test,integration-tests}.yml`, `AGENTS.md`, relevant `.claude/agents/` and `.claude/commands/`, `scripts/`, `docs/guide/`, crate READMEs, and `crates/trusted-server-core/src/migration_guards.rs`; create the stale-path/selected-test guard under `scripts/`.
+
+- [ ] Add a repository guard for live references to old concrete Rust and browser paths, including constructed paths and test selections; allowlist historical docs only. Update every explicit Fastly alias package list and a dedicated host integrations-crate test/clippy gate. Keep Fastly as sole default member and preserve CLI/codegen host gates.
+- [ ] Prove the catalog has sixteen definitions, browser discovery includes deferred/standalone modules, core's dependency graph has no integrations crate, adapters/CLI do not import vendor modules, no transitional API/path remains, and all schema-one differential outputs match except the spec's explicit milestone-one corrections.
+- [ ] Run every repository gate listed in `AGENTS.md`: Rust format, all target-matched clippy aliases and tests, host CLI/codegen gates, native/WASM checks/builds, cross-adapter parity, wrapped JS build/typecheck/lint/format/Vitest/Playwright, documentation snippets/VitePress and docs format. Record exact commands, exit codes, and intentional behavior deltas.
+- [ ] Merge milestone 1 only as a complete crate boundary. Do not activate schema 2 or schema-2 operator source in this PR.
+
+## Milestone 2 — ordered source, storage, and rollout
+
+### Task 13: Add ordered source parsing and strong identities behind a fence
+
+**Files:** Create `crates/trusted-server-integrations/src/{source_config,provider_ids}.rs` (host feature for source parsing); modify `src/{config,validation}.rs`, `crates/trusted-server-core/src/{auction_config_types,auction/plan}.rs`, workspace `Cargo.toml` and `Cargo.lock`.
+
+- [ ] Add failing fixtures for nonlexical parent and provider order, descendant-before-parent, shorthand parent, missing `enabled`, disabled retained settings, unknown IDs/fields, old/new syntax mixtures, local/qualified ID grammar, and overlays that try to create/remove/reorder tables.
+- [ ] Upgrade the direct `toml_edit` to the selected TOML-1.1 generation and enable direct `toml/preserve_order` only in the host `source-config` feature used by normal CLI/install graphs. Parse source structure before the EdgeZero typed overlay; check typed order equals the pre-pass order. Keep WASM runtime graphs free of host pre-pass code.
+- [ ] Implement the new `[integrations.<id>]` parser as an internal, test-only candidate path with explicit parent `enabled` and nested providers. Normal validate/diff/push still use only schema-one source, and no new-source candidate can serialize or reach a remote write yet. Add `IntegrationId`, `LocalProviderId`, `QualifiedProviderId`, and distinct `ExternalProviderLabel` with exact serde/Display and collision tests.
+- [ ] Run host source-parser, CLI/install dependency-graph, WASM target, and parity tests. Assert an ordinary command rejects new-source syntax while the fence is active. Commit the inert parser/identity work before switching storage or runtime order.
+
+### Task 14: Add schema-2 storage DTO and the dual stored reader
+
+**Files:** Create `crates/trusted-server-integrations/src/{stored_config,legacy_config}.rs`; modify `src/{config,composition,secret_metadata}.rs`, `crates/trusted-server-core/src/config_payload.rs`, CLI and integration-test serializer callers.
+
+- [ ] Write failing TOML → typed → envelope → runtime round trips with permuted JSON map members, sidecar missing/duplicate/extra IDs, every stored integration `enabled` (including `false`), default omission, disabled source-shaped values, and unchanged DataDome secret object paths.
+- [ ] Serialize schema 2 as object maps plus `integration_order` and local `provider_order` sidecars; always emit and require parent `enabled`. Validate the sidecar/map bijection at source-validation, serialization, and runtime read. Runtime order must never come from JSON map iteration.
+- [ ] Keep one schema-one converter that preserves current unknown-ID/default acceptance, implicit APS, globally lexical flat provider sequence, and local external labels. Reject unknown schema marker values before secret resolution; prove archived rollback binaries reject schema-2 root markers.
+- [ ] Keep the schema-2 writer and dual reader reachable only from tests/internal candidate validation until Tasks 15–17 have migrated CLI consumers, activated schema-2 ordering, and installed adapter write fences. Normal CLI commands must still reject new-source syntax or refuse its remote write; add an explicit negative test after this commit. One reviewed final cutover commit removes that fence only after Task 17's no-write gates pass.
+- [ ] Add bidirectional release-compatibility corpus coverage: candidate writer → oldest rollback/deployed/candidate readers and frozen deployed/live schema-2 bytes → candidate reader, including generated leaf/variant coverage. Run serializer, secret, adapter-loader, and source parity tests; commit the storage boundary separately from order activation.
+
+### Task 15: Migrate CLI source consumers and provide a safe migration command
+
+**Files:** Modify `crates/trusted-server-cli/src/{app_config,run,prebid_bundle}.rs`, `src/commands/config/{mod,ad_templates}.rs`, `src/commands/audit/{ad_templates,generate/validate}.rs`; create `src/commands/config/migrate.rs`; modify `crates/trusted-server-integration-tests/{src/bin/generate-viceroy-config.rs,tests/common/config.rs}`.
+
+- [ ] Write failing CLI cases for one exact source read under concurrent replacement, source/pre-pass/overlay parity, stale environment path names, selected-target diff/push/validate, read-only overlay views, bounded recovery edits, and non-disclosing errors. Confirm `--strict` remains EdgeZero's manifest check.
+- [ ] Implement `ts config migrate --dry-run` as a local-only, comment/permission-preserving legacy-source reader that emits a validated schema-2 candidate. Report explicit default normalization, every provider/hook/browser reorder, renamed overlays, unknown tables, and manual decisions; require per-ID unknown discard, explicit noninteractive reorder acceptance, and unchanged-file check before an interactive write.
+- [ ] Implement the candidate-path Prebid bundle, ad-template, audit, and fixture-generator changes behind the same source cutover fence as Tasks 13–14. Before Task 18, ordinary commands retain their schema-one behavior and inventory, while explicit candidate/migrate tests exercise the new paths. At final cutover, Prebid requires an existing explicit parent and edits only descendants, preserving file mode and staged hash/SRI behavior; update help/rule counts and exact-message/docs snippets in that same review unit.
+- [ ] Run CLI command tests, actual `cargo install --path crates/trusted-server-cli --locked` in a temporary install root, Viceroy fixture generation/parity, and secret-sentinel tests. Commit all source consumers before any schema-2 remote write is enabled.
+
+### Task 16: Switch Rust and browser execution to declaration order
+
+**Files:** Modify `crates/trusted-server-core/src/{integration/registry.rs,auction/plan.rs,auction/orchestrator.rs,auction/provider.rs,publisher.rs}`, `crates/trusted-server-integrations/src/{composition,catalog}.rs`, browser dispatcher and integration IIFEs, and relevant tests.
+
+- [ ] Write failing tests for each comparable hook phase, immediate/deferred browser lists, provider launch/response/mediator-input/tie order, remaining deadline before each launch, plan-order recovery after failure, and ordered diagnostics. Include globally interleaved schema-one provider IDs to prove old order remains unchanged under the dual reader. Cover known-disabled bidder suppression without client-side fallback and disabled-mediator local ranking.
+- [ ] Add a stored-schema-2 catalog-drift test: widen one script-source claim and one integration-owned native route in a candidate catalog after a blob is stored. Runtime must stay available; the exact-URL asset-policy clamp restores the original first-party path for an enabled asset or removes a blocked asset, and asset-wins handling drops only the newly colliding integration route. It emits redacted sampled diagnostics. Fixed-route or unrelated native/native conflicts still fail composition.
+- [ ] Feed ordinal-bearing neutral plan and registration inputs from schema-2 sidecars. Use definition-local order only within a single integration. Remove numeric/lexical browser handler sorting; keep fixed core/creative, diagnostics, finalizer, and deferred lifecycle phases explicit.
+- [ ] Validate complete script-source and route claims before execution, including parent-disabled pruning and policy-consistent final chain outcome; do not give `js_asset_proxy` an invisible first phase. Keep corrected #1199/#1208 behavior identical for schema one. Use qualified external labels only for schema 2.
+- [ ] Run ordering, auction, browser, route, cache, and differential tests on both schema versions and every adapter. Commit the intentional ordering change only with all dependent consumers and diagnostics ready.
+
+### Task 17: Fence writes and implement adapter-specific rollout tooling
+
+**Files:** Modify `crates/trusted-server-cli/src/run.rs` and config command modules; create focused copy/export/rollout-record helpers under `crates/trusted-server-cli/src/commands/config/`; modify Fastly, Cloudflare, Spin, Axum config-loader tests and `docs/guide/` rollout guidance.
+
+- [ ] Write failing no-mutation tests for schema-2 push to an unverified Fastly tuple, Cloudflare KV, and unproven remote Spin. Add a Fastly `config gc` test that refuses both protected physical stores and any missing/stale accepted-pair record before EdgeZero can sweep.
+- [ ] Implement checked-in Fastly generation copy using explicit source/destination service-version/store/root-key tuples, chunk-first/root-last exact-byte copy and full readback hash/length verification. Record accepted active/rollback tuples only after both candidates and POP-visible probes pass; do not mutate currently selected immutable roots during paired edits.
+- [ ] Add `ts config validate-stored-catalog --inventory <deployment-inventory> --exports <ephemeral-directory>`. In a test-controlled temporary root, export every authoritative live environment's exact verified envelope and adapter/location metadata, prove inventory/export bijection, then run candidate pure route/script claims without resolving secret values. Refuse missing/tampered exports or any degraded conflict; log only redacted IDs and hashes. The command never deletes its input; release-pipeline cleanup removes only its own nonce-marked, non-symlink temporary directory.
+- [ ] For every candidate release, decode each exported live schema-one envelope with both deployed and candidate readers under identical secret resolution and compare normalized settings, activation, hook/browser/route/provider order, external labels, and errors. A mismatch or missing environment blocks promotion even if the archived baseline fixture passes. Run the bidirectional same-schema-2 corpus gate from Task 14 over all live schema-2 exports too.
+- [ ] Implement protected Cloudflare `export-binding` with exact selected outer property/envelope bytes and no stdout/overwrite. Keep old Worker code + schema-one binding paired for rollback. Reject remote Spin schema-2 push until versioned export/restore/selection drill exists; allow local Axum migration. No generic force flag bypass.
+- [ ] Add authenticated unsampled unique-probe schema/artifact/digest observation and a settings-dependent response predicate without a new public status route. Block activation if live-environment inventory/export bijection, candidate claim validation, version/binding readback, or rollback isolation is unproven. After explicit rollback-window closure, GC may resume only with verified absence of protected version bindings.
+- [ ] Run Fastly tuple/GC/503 tests, Cloudflare binding-fallback tests, Spin no-write tests, Axum local migration, live-export/candidate corpus tests, and documented staged rollback drills. Commit tooling and runbook together; do not perform a production cutover as part of the implementation PR.
+
+### Task 18: Exit milestone 2 and define later cleanup
+
+**Files:** Modify `trusted-server.example.toml`, `docs/guide/{configuration,auction-orchestration,integration-guide}.md`, `docs/guide/integrations/{aps,prebid}.md`, `AGENTS.md`, browser/CI scripts and repository path guards; retain `legacy_config.rs`.
+
+- [ ] After Tasks 13–17 pass, make one final source/write activation change in the same review unit as the operator guidance below: activate the new parser and all Prebid/ad-template/audit/fixture command paths together; ordinary commands accept only new `[integrations]` source, serialize schema 2, and call the installed per-adapter push fence. Assert old source, mixed source, and an unverified destination fail before any remote operation. The read-only schema-one blob decoder remains active.
+- [ ] Convert examples, operator guides, environment names, CLI diagnostics, dashboards/telemetry migration notes, template-cache smoke, and documentation snippets to the single ordered inventory and qualified schema-2 labels. Pin plain-language explanation that TOML parent order controls comparable hooks and nested-provider priority.
+- [ ] Run every milestone-one repository gate again, plus dual-schema, migrate, same-schema release-compatibility, exporter, candidate-live-inventory, and adapter rollback suites. Review exact diff against milestone-one behavior goldens; every intentional change must be identified in the spec.
+- [ ] Merge the dual reader and CLI write fences before any schema-2 data is pushed. Keep the schema-one stored decoder and archived writer for the rollback window. Remove the decoder only in a later separately reviewed release after every production adapter, including Spin, has completed its rollback drill.
+
+## Review checkpoints
+
+1. **Neutral Rust contracts:** after Tasks 1–3, confirm the new API delta is closed and corrected schema-one behavior is unchanged.
+2. **Browser boundary:** after Tasks 4–7, confirm exact embedded bytes are used by runtime and out-of-Cargo tests; no private state copy or shared-`dist` race exists.
+3. **Concrete extraction:** after Tasks 8–12, confirm two crates own all concrete sources, every consumer uses one composition root, transitional sets are empty, and full schema-one gates pass. This is the first merge milestone.
+4. **Ordered config and rollout:** after Tasks 13–18, confirm source/store/runtime order, labels, adapter write fences, and rollback evidence. This is the second merge milestone.
+
+At each checkpoint, perform a self-review against all acceptance criteria in the spec, inspect the dependency graph and public API diff, and request an independent code review. Treat a new capability or public symbol outside the reviewed manifest as a design question, not an opportunistic extraction shortcut.
diff --git a/docs/superpowers/specs/2026-09-17-split-integrations-crates-design.md b/docs/superpowers/specs/2026-09-17-split-integrations-crates-design.md
new file mode 100644
index 000000000..86f41c308
--- /dev/null
+++ b/docs/superpowers/specs/2026-09-17-split-integrations-crates-design.md
@@ -0,0 +1,3944 @@
+# Split Integrations into Dedicated Crates and One Ordered Configuration
+
+**Date:** 2026-09-17
+
+**Status:** Proposed
+
+**Scope:** Move all concrete Rust and browser integrations into two statically
+compiled workspace crates, introduce typed multi-capability registration, and
+make ordered `[integrations]` configuration the single inventory for concrete
+integrations and their auction providers.
+
+## Summary
+
+Trusted Server will separate concrete integrations from its neutral Rust and
+browser runtimes.
+
+The workspace gains two crates:
+
+- `trusted-server-integrations`, containing all concrete Rust integrations.
+- `trusted-server-integrations-js`, containing all integration-specific
+  TypeScript, JavaScript assets, fixtures, tests, and generated bundles.
+
+`trusted-server-core` will retain neutral integration contracts and execution
+engines. `trusted-server-js` will retain the neutral browser runtime. The
+adapters and CLI will use `trusted-server-integrations` as the statically linked
+application composition root.
+
+Each Rust integration will expose one definition that may register multiple
+typed capabilities. APS, for example, may register proxy, head-injection,
+JavaScript, and OpenRTB-profile capabilities. Capabilities are subsystem-owned
+types and traits, not a single `IntegrationType` enum and not a discriminator
+in operator configuration.
+
+`[integrations]` will become the only operator inventory for concrete
+integrations. An integration will own all of its settings, including any named
+auction provider instances. Global `[auction]` settings will continue to own
+cross-integration orchestration such as the auction timeout, bidder routing,
+creative policy, and mediator selection.
+
+Cross-integration runtime order within the same comparable capability phase
+will come exclusively from TOML declaration order. Fixed engine seams such as
+immediate versus deferred loading and the diagnostics post-unified position are
+named phases, not hidden integration priorities. The config push and
+config-store representation will preserve order explicitly; filesystem
+discovery order will never affect execution. For auction providers, that order
+is also operational priority: it controls launch and response order, mediator
+input order, and local equal-price tie-breaking.
+
+Repository discovery started from `origin/main` at `a4e01eb55`, not either
+prior pull request discussed below. That historical discovery commit contains
+the known P1 output defects listed as prerequisites here and is not an
+acceptable compatibility golden. The 2026-10-01 review checkpoint is
+`cb9452545`; it includes the post-discovery configuration-store, EC/EID,
+stored-request, origin-readthrough, first-impression, and deterministic
+context-allowlist changes recorded below. It is a review checkpoint, not the final
+implementation baseline. Implementation branching is blocked until every
+prerequisite fix lands; the recorded baseline is then the resulting
+`origin/main` commit plus captured Next.js/GTM/RSC and browser-runtime output
+goldens. This design changes only the configuration, activation, and ordering
+behavior called out explicitly in this document; all other corrected-baseline
+runtime, browser, CLI, and cache behavior is preserved.
+
+This remains one design, but it has two merge milestones. The crate and runtime
+boundary moves first without changing operator configuration. The ordered,
+integration-owned configuration cuts over only after the compatibility-focused
+boundary, including its explicitly listed baseline bug fixes, is running. The
+milestones share one target architecture without
+forcing the packaging move and configuration migration into one deployment.
+
+## Context
+
+At the historical discovery commit `a4e01eb55`, neutral registry machinery and
+concrete integrations share `crates/trusted-server-core/src/integrations`. The
+concrete Rust units are:
+
+- `adserver_mock`
+- `aps`
+- `datadome`
+- `didomi`
+- `google_tag_manager`
+- `gpt`
+- `gpt_diagnostics`
+- `js_asset_proxy`
+- `lockr`
+- `nextjs`
+- `osano`
+- `permutive`
+- `prebid`
+- `sourcepoint`
+- `testlight`
+
+The ordinary builder table registers twelve units. APS and Prebid are also
+constructed from the compiled auction plan, and `adserver_mock` supplies the
+current mediator. Core additionally imports concrete APS and Prebid code from
+the OpenRTB profile and provider paths, concrete DataDome response state, and
+GPT diagnostics lifecycle functions.
+
+Integration browser code shares a Node project with browser core under
+`crates/trusted-server-js/lib/src/integrations`. The build discovers
+directories containing `index.ts`, emits an IIFE for each entry point, and
+embeds bundles and hashes into the `trusted-server-js` Rust crate. APS renderer
+code is imported directly by browser core even though APS does not currently
+have its own `index.ts`.
+
+The same baseline includes the parser-aware streaming Next.js processor from PR
+#1135, managed Prebid User IDs and their OpenRTB EID/EC
+flow, LiveRamp configuration through that existing managed-ID facility,
+analytics-adapter selection in external Prebid bundles, cookie-keyed publisher
+template caching, additional CLI ad-template and audit config consumers, and
+documentation-snippet verification. These are current behavior and remain in
+scope for parity even though they landed after this design was first drafted.
+
+`core/src/ec/prebid_eids.rs` is historically named after the first browser
+producer, but its `ts-eids` ingestion, consent checks, EC finalization,
+partner-graph ingestion, and admin diagnostics are shared identity machinery.
+They remain in core under their current name for this split. Renaming the
+neutral module is unrelated cleanup and is deferred. Prebid-owned configuration
+and browser-module management move out; the shared EID/EC machinery does not
+become a new capability family, and LiveRamp does not become another
+integration definition.
+
+Configuration is also split by implementation detail. Browser/page settings
+use `[integrations.<id>]`, while server auction providers use
+`[auction.providers.<instance>]` plus `profile = "aps"` or
+`profile = "prebid-server"`. One logical APS integration is therefore
+configured in two inventories and may be activated implicitly by an auction
+plan. `IntegrationSettings` currently uses `HashMap`, so integration
+declaration order is discarded before registry construction.
+
+These conditions produce five related problems:
+
+1. Core owns both neutral contracts and concrete implementations.
+2. Rust registration, auction profiles, deploy validation, and migration guards
+   maintain separate concrete inventories.
+3. Browser core imports integration-specific code.
+4. One logical integration can be configured and activated through unrelated
+   locations.
+5. Runtime integration order is not a stable property of the operator
+   configuration.
+
+## Related Pull Requests and Disposition (Non-Normative)
+
+The following pull requests explain how some current code arrived in the
+repository. They are not design authorities for this specification. The
+normative inputs are the decisions in this document and behavior present at the
+review checkpoint above.
+
+### PR #1016
+
+PR #1016 introduced the ancestor of the current compiled auction plan. The
+following properties are now baseline repository behavior and are preserved
+because current consumers depend on them, not because the PR is authoritative:
+
+- Multiple configured instances may use one integration implementation.
+- One validated provider identity remains shared by bidder routing, backend
+  correlation, diagnostics, and telemetry; this design changes its serialized
+  value from a local ID to a qualified ID.
+- One validated plan remains authoritative across every adapter and runtime
+  consumer.
+- The generic OpenRTB transport remains shared.
+- Existing routing, timeout, notification, response admission, mediation, and
+  telemetry attribution behavior remains unchanged except where provider order
+  is observable.
+
+This design changes the configuration location and identity spelling. Provider
+instances move below their owning integration, and cross-integration references
+use a qualified `<integration>.<instance>` identifier. It also intentionally
+changes deterministic provider priority from lexical provider-ID order to
+operator declaration order. The pricing algorithm is unchanged, but the first
+configured provider retains an equal-price tie and later providers receive the
+remaining shared auction budget after earlier providers launch.
+
+### PR #1084
+
+PR #1084 explores a broader external-provider and plugin ecosystem. That scope
+and its alternate configuration convention are not inputs to this design. This
+specification independently chooses static workspace crates, typed capabilities
+needed by current implementations, one ordered `[integrations]` inventory,
+explicit `enabled`, and APS as an integration. No `[integration]`, `[demand]`,
+or `[adserver]` selector convention is carried forward.
+
+PRs #1043 through #1047 and #1094 implement parts of that alternate convention.
+They cannot merge concurrently with this configuration contract. Their tests or
+neutral wire-format work may be reused after independent verification, but their
+inventory, discriminator, provider-naming, and crate-layout decisions are
+superseded for in-tree integrations by this specification. That disposition is
+coordination, not evidence for the architecture chosen here.
+
+PR #1135 is part of the review checkpoint. The parser-aware streaming Next.js
+implementation and integration-owned fixtures move with their owner. Its
+cross-adapter end-to-end case remains in
+`trusted-server-integration-tests/tests/parity.rs` and consumes
+integration-owned test support; the removed HTML post-processor is not
+recreated by this work.
+
+### Baseline Delta, Open Defect, and In-Flight Work Disposition
+
+The following items are tracked at the 2026-10-01 review checkpoint. Their
+issue states can change before implementation; the final baseline gate checks
+behavior, not only whether an issue is closed. They are coordination inputs,
+not design authorities. “Prerequisite” means the focused fix lands on `main`
+and this specification records a new baseline before extraction begins; the
+crate split does not absorb that bug fix into a move commit.
+
+| Item         | Disposition                                                                                                                                                                                                                                                                                                        |
+| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| #1196        | Prerequisite. Restore cross-IIFE context/log state on the current layout, remove or debug-gate Creative's unconditional log-level bump, and add a production-artifact test. The milestone-one typed facade supersedes any transitional `Symbol.for` storage without reverting behavior.                            |
+| #1197        | Prerequisite behavior. The issue was closed after the context-allowlist fix, but the final baseline gate still proves deterministic serialization for every set-valued configuration input before EdgeZero or template hashes depend on it.                                                                        |
+| #1198        | Prerequisite. Add the deterministic build digest defined below to the current template key before extraction, with the canonical generator owned by core build support; the split reuses the same generator for component digests.                                                                                 |
+| #1199        | Prerequisite. Replace substring browser guards and Rust/HTML script-source matchers, including Permutive, DataDome, Lockr, and Testlight, with canonical parsed URL ownership on the current layout. Declaration and execution use one positive/negative corpus.                                                   |
+| #1200        | Prerequisite. Remove the shared-`dist` partial-build race before two Rust crates consume browser outputs; milestone one then adopts owner-private outputs and the lock contract below.                                                                                                                             |
+| #1201        | Milestone two. New source and schema 2 reject unknown catalog IDs and fields. The temporary schema-1 reader deliberately retains baseline acceptance with a warning and is not “fixed” retroactively.                                                                                                              |
+| #1202        | Prerequisite. Make `ts prebid bundle` use the permission-preserving atomic writer and non-disclosing parse errors; the moved command retains that corrected behavior.                                                                                                                                              |
+| #1203        | Prerequisite and adopted decision. A parsed non-2xx mediator response is a mediation failure and falls back to local ranking as specified below.                                                                                                                                                                   |
+| #1204        | Prerequisite. Every Rust CI job that can trigger a browser build installs the pinned Node toolchain and dependencies; obsolete direct Rust browser dependencies are removed.                                                                                                                                       |
+| #1205        | Proposed remedy superseded. This specification keeps operator order and uses the pure script-source claim validation below instead of an unconditional hidden first phase. The issue must be revised to that contract or closed.                                                                                   |
+| #1206, #1207 | Prerequisites resolved by #1208. Their output regressions are not accepted as differential-harness goldens.                                                                                                                                                                                                        |
+| #1208        | Prerequisite. Compose script-text rewriters on the current layout and add Next.js/GTM output goldens before the baseline is captured.                                                                                                                                                                              |
+| #1098        | Prerequisite. Make neutral Cookie parsing lenient per header field and pair, preserving valid pairs when another pair is malformed and recording only counts/reasons. The catalog normalizer then removes and merges only its reserved names. This chosen remedy is broader and more explicit than the issue text. |
+| #791         | Covered by extraction step 3. The Fastly-SDK guard follows the complete moved source set and dependency graph; this design does not add a second migration guard.                                                                                                                                                  |
+
+The review checkpoint already contains changes that landed after discovery.
+They are baseline behavior, not optional input from their former pull requests:
+
+| Item             | Landed baseline contract                                                                                                                                                                                                                                                                                                                |
+| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| #879             | Preserve manifest-derived logical config-store defaults, service-scoped runtime store-name/root-key selection, Cloudflare's primary/legacy outer-binding fallback, and the rule that a runtime key override does not change the CLI push destination without an explicit `--key`.                                                       |
+| #900–#903, #1157 | Preserve request-scoped EC snapshots and generation binding, conditional EID writes and conflict follow-up, snapshot-gated pull sync, idempotent withdrawal tombstones, grouped batch-sync ordering/accounting, and removal of the legacy consent-store input. These remain neutral core behavior rather than integration capabilities. |
+| #1159            | Preserve `Disabled`/`Explicit`/legacy-inferred stored-request intent, post-override usable-impression admission, zero-impression no-transport `Skip` metadata, and response parsing bound to the exact impressions actually sent. The extraction carries the complete existing regression matrix across the prepared-exchange seam.     |
+| #1169            | Preserve the separate origin-readthrough/shareability gate, method-complete authenticated cache-purge route, and origin diagnostics. Integration requirements may only veto the baseline cache decisions.                                                                                                                               |
+| #1191            | Preserve first-impression ownership, including pending-render behavior, retained denial tokens, one fallback reservation, and no timer-based release of a Trusted Server claim before render. Its bootstrap and browser test harness move with their owners.                                                                            |
+| #1209            | Preserve deterministic serialized context allowlists and canonical hashing of config envelopes and template fingerprints.                                                                                                                                                                                                               |
+
+The landed #1209 change fixes the context allowlist and its canonical hashing
+path. Closing #1197 does not waive the broader deterministic-serialization
+check for other set-valued inputs used by the new fingerprints.
+
+Other open work is coordinated without making it architectural authority or an
+automatic prerequisite:
+
+| Item         | Coordination contract                                                                                                                                                                                          |
+| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| #1179        | Reconcile per-document buffer work with #1208 and select one reviewed EdgeZero pin. Reuse remains optional; composition works per request.                                                                     |
+| #1193        | Rebase caching onto the immutable composition and its fingerprint; do not retain a parallel composition or fingerprint path.                                                                                   |
+| #1185        | External Prebid fork-source selection remains separate. Same-checkout enforcement here covers Trusted Server-owned package and input paths; future vendor-source selection requires an explicit extension.     |
+| #1002        | Its alternate release catalog, bootstrap transport, and hard cutover do not enter this design. Independently verified renderer tests may be reused; the release lines must otherwise be reconciled explicitly. |
+| #1121, #1154 | Preserve accepted diagnostic wire behavior while moving GPT presentation and state outward; core retains only neutral diagnostic facts.                                                                        |
+| #1188        | Independent neutral EC/EID correctness stays in core. Preserve body ingestion and consent checks if it merges; it creates no integration definition.                                                           |
+| #1107        | Separate proposed product feature, deferred. Extraction implies no trace endpoint or general tracing framework.                                                                                                |
+
+PR #1052 may contribute neutral renderer diagnostics, but APS-named browser
+core members do not enter core; they move with APS or become generic renderer
+reason fields. PR #1175 and EdgeZero PR #381 are milestone-one step-3
+prerequisites: the typed-config extension and Fastly store procedure build on
+their reviewed environment-selector line or an equivalent merged successor,
+never on v0.0.8.
+
+This specification partially supersedes the following earlier design documents
+only where they conflict with the new ownership, configuration, or fingerprint
+contracts:
+
+- `2026-08-10-config-first-auction-provider-architecture-design.md`: its
+  provider inventory, selection, and ordering syntax are superseded; reusable
+  neutral auction-engine findings remain evidence to reverify.
+- `2026-07-15-gam-ts-cohort-attribution-design.md` and
+  `2026-08-19-gam-attribution-review-resolution-design.md`: attribution wire
+  behavior remains, while concrete GPT code and assets move to their integration
+  owner.
+- `2026-09-08-1138-per-cookie-template-cache-policy-design.md`: cookie/Vary
+  policy remains, while complete-settings fingerprinting is replaced by the
+  composition/build digest defined here.
+- `2026-07-24-prevent-duplicate-gpt-slot-requests-design.md`: duplicate-slot
+  behavior remains, while concrete GPT state and browser ownership move outward.
+
+Before either milestone branches for implementation, all prerequisite issues in
+the disposition table must have landed, then the baseline commit, output
+goldens, and locked EdgeZero revision are recorded again and every
+baseline-dependent inventory in this document is rechecked. Open or previously
+approved pull requests never override a decision in this specification merely
+because of their review status.
+
+## Rejected Alternatives and Rationale
+
+The following alternatives were considered and are deliberately not part of
+the target design. Each rejection is narrow: where review exposed a valid
+failure mode, the concern is accepted even when the proposed remedy is not.
+The objection and the replacement decision are stated separately so an
+implementation cannot quietly reintroduce the rejected mechanism.
+
+- **One crate per integration or an external plugin ABI.** Concrete ownership
+  boundaries and independent testability are required; that concern is
+  accepted. **Objection:** per-vendor crates, dynamic discovery, or a public SDK
+  would multiply dependency, compatibility, release, and governance surfaces
+  without a current external consumer. **Decision:** use one statically linked
+  Rust integrations crate, one integration-browser crate, per-integration
+  directories, and one compile-checked catalog.
+- **A separate top-level auction-provider inventory, including APS.** APS does
+  provide auction behavior, but it also owns browser, renderer, route, and page
+  behavior. **Objection:** classifying APS as only a provider would split one
+  implementation's activation and ownership across unrelated top-level
+  sections and would make `[integrations]` incomplete. **Decision:** APS is an
+  integration that registers several capabilities. Its provider instances live
+  below `[integrations.aps.auction.providers.<id>]`, as do provider instances
+  owned by other integrations.
+- **A config `type`, `kind`, or `implementation` discriminator.** Multiple
+  configured instances must be able to reuse one implementation; that concern
+  is accepted. **Objection:** an extra discriminator would duplicate the static
+  integration ID already present in the TOML path, admit contradictory ID/type
+  combinations, and expose internal registration types to operators.
+  **Decision:** `[integrations.<id>]` selects the statically cataloged
+  integration, while nested instance names identify reusable provider
+  configurations. Capability types remain Rust contracts, not configuration.
+- **Keeping local provider IDs as the permanent global identity.** Stable
+  external values during the dual-reader rollout are required; that concern is
+  accepted. **Objection:** local IDs can collide across owning integrations and
+  cannot safely key one cross-integration plan. **Decision:** the plan always
+  uses `QualifiedProviderId`, while an explicit external label preserves local
+  schema-1 values and changes to qualified values only at the schema-2 cutover.
+- **Keeping concrete browser integrations in the neutral JS crate or splitting
+  them into one package per vendor.** One tested Node dependency graph is
+  required. **Objection:** leaving vendor sources in the neutral crate preserves
+  the ownership inversion, while per-vendor packages multiply lockfiles,
+  resolution rules, and release surfaces without independent consumers.
+  **Decision:** use one `trusted-server-integrations-js` Rust/source crate for
+  concrete integration browser code and one canonical Node project shared with
+  neutral browser core.
+- **Keeping the existing mediator trait object unchanged.** One reusable
+  mediator implementation and stable fallback behavior are required.
+  **Objection:** the existing object couples configuration selection, request
+  preparation, transport, response parsing, and provider-specific state, which
+  forces concrete knowledge and downcasts across the core boundary.
+  **Decision:** use a typed mediator registration, prepared request, and bound
+  response parser while retaining the existing wire protocol and the corrected
+  fallback policy.
+- **An operator-written `[auction] provider_order` list.** Provider priority
+  must represent schema-1's globally interleaved lexical order; that concern is
+  accepted. **Objection:** a second operator list would duplicate every provider
+  identity, permit the inventory and priority to drift, and separate priority
+  from the configuration block an operator is reviewing. It would make the
+  promised single integrations configuration untrue. **Decision:** schema 2
+  derives priority from declaration order in the one `[integrations]`
+  inventory. The neutral compatibility model carries a flat legacy sequence so
+  schema 1 remains exact; that internal sequence is not a second operator
+  syntax.
+- **A hidden engine override that always runs `js_asset_proxy` first.** Attribute
+  overlap and terminal-removal behavior must be explicit and tested; that
+  concern is accepted. **Objection:** a hidden first phase would make the TOML
+  order contract false and still would not reproduce baseline Prebid removal
+  behavior, because Prebid precedes `js_asset_proxy` today. **Decision:** legacy
+  compatibility paths reproduce the complete baseline sequence. Schema 2
+  exposes chained replacement and terminal removal in declaration order. Pure
+  per-definition script-source transitions validate the complete final outcome
+  for each operator asset. No position, including placing `js_asset_proxy`
+  first, is a privileged override: an operator may reorder integrations, but
+  validate/diff/push accept the result only when the entire chain finishes in
+  the declared asset policy.
+- **Treating PR #1016, PR #1084, or earlier review statements as design
+  authority.** Their code and tests can reveal compatibility constraints, and
+  conflicting in-flight work needs an explicit disposition. **Objection:**
+  review or merge status does not make a prior proposal correct for this design,
+  and importing its architecture would silently expand this spec's scope.
+  **Decision:** current behavior is evidence and prior proposals are context.
+  This specification records its own ownership, ordering, activation, and
+  rollout decisions and records the disposition of incompatible work above.
+- **Requiring the Node package and lockfile to move to a common ancestor.** One
+  Node project must reliably resolve, type-check, lint, format, test, and build
+  both source roots; that concern is accepted. **Objection:** moving the package
+  root is not required to meet that contract and would add unrelated
+  repository-wide path and automation churn. **Decision:** keep one canonical
+  project with explicit, tested resolver and tool-root configuration for the
+  sibling sources. Moving the root remains a fallback only if that contract
+  cannot be made reliable.
+- **A new configuration-status endpoint, public or authenticated.** Runtime settings must be
+  loaded and the expected schema must be observable during rollout; that
+  concern is accepted. **Objection:** even an authenticated endpoint would add
+  a new route, authorization contract, and public support surface unrelated to
+  the crate split.
+  **Decision:** use adapter-native version/binding inspection, startup
+  schema-and-digest logging, and an existing authenticated or
+  settings-dependent probe.
+- **Filesystem snapshots around EdgeZero config commands.** Config commands must
+  validate and serialize the same app-config bytes; that concern is accepted.
+  **Objection:** same-directory manifest copies add write
+  requirements, can survive process termination, expose operator configuration,
+  and require log/path rewriting without freezing every adapter manifest and
+  store target. **Decision:** a narrow two-stage EdgeZero typed-config extension
+  gives the app the exact source bytes and the effective typed command context,
+  providing the required consistency without filesystem snapshots.
+- **Hashing resolved secret values into template identity.** Current integration
+  configuration changes that alter document bytes must invalidate templates;
+  that concern is accepted. **Objection:** current integration secrets authorize
+  upstream calls and do not form HTML variants, so hashing their values adds
+  rotation churn and sensitive derived material without improving correctness.
+  **Decision:** the verified stored-data hash covers secret references. A future
+  secret that shapes output must declare a non-secret behavior fingerprint or
+  force private output.
+- **A second generic per-capability enablement system.** A simple master kill
+  switch and precise optional-feature activation are both required; that
+  concern is accepted. **Objection:** operator-visible capability kinds or a
+  parallel browser/provider activation inventory would recreate the
+  discriminator-driven configuration this design is removing and introduce two
+  answers to whether an integration is active. **Decision:** `enabled` remains
+  the integration master gate, existing typed fields decide which optional
+  capabilities are configured, and routes to known-disabled integrations are
+  pruned so `enabled = false` remains a kill switch.
+- **Silently accepting unknown integrations or providers in schema 2.** Exact
+  baseline acceptance must remain exact while schema 1 can still be loaded;
+  that concern is accepted. **Objection:** extending that permissiveness to new
+  source would turn typos into silently inactive configuration and prevent the
+  static catalog from validating ownership. **Decision:** exact legacy
+  acceptance belongs only to the schema-1 compatibility reader. New source and
+  stored schema 2 fail on unknown IDs; only references to an explicitly
+  disabled, known integration receive the kill-switch treatment defined below.
+
+## Goals
+
+1. Move every concrete Rust integration implementation out of core and into one
+   `trusted-server-integrations` crate.
+2. Move all integration-specific browser sources and artifacts into one
+   `trusted-server-integrations-js` crate.
+3. Give each concrete integration one Rust directory and, when applicable, one
+   same-named browser directory.
+4. Keep one explicit compile-checked Rust catalog and discover browser modules
+   from integration directories at build time.
+5. Let one integration register multiple typed capabilities without a global
+   integration-kind enum.
+6. Remove concrete integration construction, auction-profile, validation, and
+   lifecycle imports from core.
+7. Make `[integrations]` the single ordered inventory for concrete integration
+   configuration, including auction providers.
+8. Preserve behavior on the current `origin/main` baseline except for the
+   explicitly documented configuration, activation, and ordering changes.
+9. Make core compile without depending on either integrations crate.
+10. Keep all integrations statically linked; no runtime loading is introduced.
+
+## Non-Goals
+
+This design does not introduce:
+
+- One Cargo crate per vendor.
+- External vendor crate injection or adapter-supplied registration.
+- Runtime-loaded integrations, dynamic linking, or an ABI.
+- A stable public plugin or integration SDK.
+- Independent vendor release, compatibility, security-response, or governance
+  policies.
+- New identity, EC, geo, device, or permission-signal provider systems. The
+  existing neutral `ts-eids`/EC flow and managed Prebid User ID behavior remain
+  supported.
+- A jurisdiction or permission-policy redesign.
+- Client-cycle EC resolution or provider-code allocation.
+- Upstream EdgeZero lifecycle, host-evidence, store, or adapter changes. One
+  narrow typed-config validation extension is allowed: a source-bytes check and
+  a post-parse command-validation callback over the same loaded value. It does
+  not change target selection, deployment, storage, or adapter behavior.
+- New auction protocols, pricing algorithms, notification policies, or
+  telemetry schemas. Configuration order intentionally replaces lexical
+  provider-ID order wherever deterministic provider priority is observable.
+- A reorganization of CLI audit detection that is unrelated to configuration
+  validation and composition.
+
+The design adds only capabilities needed to move current implementations. A
+future non-OpenRTB provider, external crate, or new provider family requires a
+separate design with a real consumer.
+
+## Terms
+
+The following terms are distinct:
+
+- **Integration definition:** the statically cataloged code definition for a
+  stable integration ID such as `aps`.
+- **Capability registration:** one typed contribution made by an integration,
+  such as a proxy, HTML rewriter, JavaScript module, OpenRTB profile, or
+  mediator.
+- **Integration configuration:** the single ordered operator block at
+  `[integrations.<id>]` that activates and configures the definition.
+- **Auction provider instance:** one named endpoint and policy configuration
+  below an integration, such as `aps.aps-main`. Multiple instances may use the same
+  integration implementation.
+- **Local provider ID:** the provider name within one integration, such as
+  `aps-main`.
+- **Qualified provider ID:** the strong, globally unique pair of an integration
+  ID and local provider ID, such as `aps.aps-main`, serialized as
+  `<integration>.<local-provider>`.
+- **Integration registry:** core runtime state containing the enabled page,
+  request, response, and browser capabilities in configuration order.
+- **Auction plan:** core runtime state containing the validated configured
+  provider instances, routes, and orchestration policy.
+
+An integration is therefore a container for capabilities; it is not itself a
+single capability type.
+
+## Target Workspace Layout
+
+```text
+crates/
+  trusted-server-core/
+    src/
+      integration/
+        mod.rs
+        registry.rs
+
+  trusted-server-js/
+    lib/
+      package.json
+      package-lock.json
+      build-all.mjs
+      build-prebid-external.mjs
+      src/core/
+      test/core/
+    src/
+
+  trusted-server-integrations/
+    Cargo.toml
+    src/
+      lib.rs
+      integrations/
+        adserver_mock/
+          mod.rs
+        aps/
+          mod.rs
+        datadome/
+          mod.rs
+          protection.rs
+          protection_scope.rs
+        didomi/
+          mod.rs
+        ...
+        nextjs/
+          mod.rs
+          rsc.rs
+          rsc_placeholders.rs
+          rsc_stream.rs
+          script_rewriter.rs
+          shared.rs
+          fixtures/
+        openrtb/
+          mod.rs
+
+  trusted-server-integrations-js/
+    build.rs
+    Cargo.toml
+    lib/
+      src/integrations/
+        aps/
+          index.ts
+          render.ts
+          renderer-document.html
+        creative/
+          index.ts
+        datadome/
+          index.ts
+        prebid/
+          index.ts
+          user_id_modules.json
+        ...
+      test/
+        integrations/
+        fixtures/
+    src/
+      lib.rs
+```
+
+Every current flat Rust integration file becomes
+`src/integrations/<id>/mod.rs`. Restricting the completeness scan to that
+directory prevents helper modules from being mistaken for integrations.
+Existing nested modules and fixtures stay with their owner. The current
+Next.js `rsc_stream` implementation moves; the removed `html_post_process`
+module does not return. `openrtb` is a built-in Rust-only, directory-backed
+integration adapter that exposes configuration for the current standard
+OpenRTB profile without turning the neutral OpenRTB execution engine into
+concrete code. The target Rust catalog therefore has sixteen definitions:
+fifteen moved implementations plus the new `openrtb` adapter.
+
+JavaScript-only `creative` remains valid without a Rust directory. Rust-only
+integrations remain valid without a browser directory. Cross-adapter Playwright
+and parity tests remain in `trusted-server-integration-tests`; their paths and
+load-order assertions change, but system tests do not become source owned by
+one integration crate.
+
+`creative` is the sole fixed, non-configurable browser prelude in this design;
+it is runtime support rather than an operator integration. Directory discovery
+may build other JavaScript-only assets, but `[integrations]` cannot activate one
+unless a Rust definition with that ID registers its browser-module capability.
+
+## Dependency Direction
+
+The Cargo dependency graph is one-way:
+
+```text
+trusted-server-integrations ──→ trusted-server-core ──→ trusted-server-js
+             │                         │
+             │                         └──→ trusted-server-openrtb
+             └───────────────→ trusted-server-integrations-js
+
+adapters and CLI ────────────→ trusted-server-integrations
+adapters and CLI ────────────→ trusted-server-core
+trusted-server-integration-tests ──→ trusted-server-integrations
+```
+
+The rules are:
+
+1. Core never depends on either integrations crate.
+2. Concrete Rust integrations use public neutral core contracts and domain
+   types.
+3. `trusted-server-integrations` links Rust definitions with generated browser
+   modules from `trusted-server-integrations-js`.
+4. Integration TypeScript may use the explicit browser-core API, but browser
+   core never imports a concrete integration and integration bundles never
+   embed a private copy of stateful browser-core modules.
+5. The CLI uses the source-validation APIs from
+   `trusted-server-integrations`; every adapter uses its single runtime
+   composition entry point from that crate. Both phases resolve the same static
+   catalog and integration schemas.
+6. No adapter reconstructs a concrete catalog or imports `aps`, `prebid`, or
+   another integration module directly.
+
+### Application composition ownership
+
+`trusted-server-integrations` is the application composition root, not only a
+directory of implementations. It owns:
+
+- `TrustedServerAppConfig`, the typed operator-facing app-config root used by
+  the CLI.
+- Source-aware TOML structure validation and ordered integration
+  deserialization.
+- Aggregation of core and integration secret metadata.
+- Integration-owned preprocessing for conditionally active secrets.
+- Catalog-aware validation and capability construction.
+- Pure source parsing, structural validation, and deploy-validation APIs used by
+  the CLI at the validation level appropriate to each command.
+- The public runtime entry points that load a config-store blob and return one
+  composed runtime value.
+- A structural `SourceConfigView` and a deploy-validated
+  `ValidatedSourceConfig` used by non-runtime CLI commands.
+- A generic `PartialSourceConfigView<T>` for recovery-oriented commands that
+  intentionally type only one owned subtree of an otherwise invalid document.
+
+`TrustedServerAppConfig` contains neutral core configuration plus the ordered
+integration-owned source configuration. Concrete integration configuration is
+not added to core's `Settings`. Composition consumes the integration portion
+into capabilities and returns a neutral runtime `Settings` value containing
+only state that core execution engines understand.
+
+The public-API snapshot classifies exports as stable neutral contract,
+integration-owned facade, or milestone-one transitional delegation. A
+transitional export must name its replacement and owning move step; adding one
+requires review, and the class must be empty before milestone 1 exits.
+
+The delta allowlist applies only to public items newly added or visibility-
+widened by this design and to concrete public paths removed by extraction.
+Existing neutral core exports outside the touched integration, auction,
+configuration-loading, browser-composition, and lifecycle seams are captured in
+a grandfathered baseline snapshot; they need not map to this table and may not
+change in an extraction commit. The allowed delta is deliberately
+category-sized but not open ended:
+
+| Owner/export class            | Allowed surface                                                                                                                                                                                                                                                                                                                                                                                                                                            | Consumer and lifetime                                                                                                                                      |
+| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Core stable neutral contracts | Neutral `Settings` subsets; `AuctionPlan` and ordinal-bearing provider/slot/header inputs; OpenRTB profile, compiled profile, prepared exchange-or-skip, consuming bound response parser, and response-admission contracts; bounded backend/body transport; neutral renderer descriptors; route/script claims; request-processing requirements; browser assets; registry builders; verified-envelope/chunk helpers; and neutral stubs behind `test-utils`. | The integrations composition root and adapters. These are behavior-oriented contracts and contain no vendor configuration or concrete implementation type. |
+| Integrations-owned facade     | Source/partial/validated config views, catalog metadata, the runtime composition attempt/result, CLI read models, and the production catalog test factory.                                                                                                                                                                                                                                                                                                 | Adapters and CLI. These may expose catalog-backed application behavior but never a concrete `aps`, `prebid`, or other vendor module.                       |
+| Transitional delegation       | One named catalog entry or browser path still delegated to its old owner, with its replacement and removal step recorded in the snapshot.                                                                                                                                                                                                                                                                                                                  | Milestone 1 only; the class is empty at its exit. No new consumer may adopt it.                                                                            |
+
+Before implementation changes visibility, step 1 generates and commits a
+symbol-level delta manifest from the baseline snapshot. Every added, widened,
+or removed item must map to one row and record its exact path, owning module,
+stability class, direct workspace consumers, and removal condition when
+transitional. The expected new entries include the ordinal-bearing auction
+inputs and transport-header view; OpenRTB profile, prepared outcome/exchange,
+and consuming parser traits; mediator traits; bounded backend/body transport and
+response-admission diagnostics; `IntegrationDeclaration`, route/script and
+reserved-route claims, and registry construction; renderer descriptor,
+`CompiledBrowserAsset`, and `BrowserDocumentAssets`; request-processing
+requirements; `ResolvedConfigLocation` and `ConfigurationUnavailable`;
+integration-owned `CompositionAttempt`; and neutral `test-utils` stubs. A needed
+symbol outside this closed set requires a spec amendment rather than an
+unreviewed allowlist addition.
+
+Current `trusted_server_core::integrations::<vendor>` paths are
+workspace-internal migration paths, not a compatibility API: imports move
+atomically with their owners and the concrete modules are deleted without
+re-export shims. The snapshot rejects piecemeal `pub` widening of current
+auction/OpenRTB helpers when a smaller neutral DTO or trait satisfies the
+consumer, and rejects unrelated changes to grandfathered neutral exports.
+
+The public API has four explicit levels:
+
+1. `SourceConfigView` performs the TOML pre-pass, typed parse, catalog
+   resolution, and structural validation. It does not run deploy validation.
+   Read-only diagnostics that already require a complete typed root use this
+   level so unrelated deployment checks do not become new failures.
+2. `PartialSourceConfigView<T>` retains the source document plus one typed,
+   command-owned subtree. Recovery-oriented mutators and generators use it when
+   their current contract tolerates an invalid unrelated root. It cannot be
+   converted into a storage DTO or runtime composition, and each command names
+   the only source paths it may read or write.
+3. `ValidatedSourceConfig` applies the selected environment overlay, aggregates
+   secret metadata, runs every secret-independent integration and
+   cross-integration check, serializes the storage DTO, and validates its order
+   sidecars. It invokes the same pure auction-plan compiler used at runtime,
+   including provider routing, browser/server bidder ownership, mediator
+   capability and enablement, and duplicate routes, then discards the
+   validation-only plan. A separate pure `validate_for_targets` operation runs
+   the resulting plan against the command's resolved target set. Neither path
+   creates executable capabilities or attempts to use unresolved secret values.
+4. Runtime composition begins after envelope verification, inactive-secret
+   preprocessing, and secret resolution. It repeats the shared pure validation
+   kernel against resolved values, compiles the authoritative plan, constructs
+   plan-dependent capabilities, and returns the final composition.
+
+This distinction makes "runtime-only construction" precise: it does not move
+any currently push-time, secret-independent plan failure to startup. Diff and
+push have one selected adapter and fail when its target validation fails. The
+existing EdgeZero `config validate --strict` meaning is unchanged: it enforces
+the manifest-completeness and handler-path checks already owned by EdgeZero.
+Trusted Server target-plan validation is exposed separately as a repeatable
+`ts config validate --adapter <adapter>` option. With no `--adapter`, the
+command runs target-neutral Trusted Server checks plus existing EdgeZero
+validation; with one or more adapters, every selected target is checked and any
+target failure makes the command fail. Auction-testing documentation and smoke
+commands use this same adapter spelling. A fixture rejected by runtime
+composition for a secret-independent reason must produce the same
+target-neutral error or the same named target result in the CLI.
+
+The complete source and validated views retain the typed operator configuration
+and expose only the data their CLI consumers need: neutral global settings,
+ordered integration and qualified-provider metadata, and integration-owned read
+models. A partial view retains only its owned typed subtree and the source
+document needed for a bounded edit. None is a runtime registry or contains
+resolved secret values or executable capability objects.
+
+The runtime value, conceptually `TrustedServerComposition`, contains the
+validated neutral `Arc<Settings>`, one `Arc<AuctionPlan>`, the plan-backed auction
+orchestrator including the selected mediator, one `IntegrationRegistry`, the
+composed `BrowserDocumentAssets`, the validated deployment target, and a lazy
+canonical composition digest. Adapters consume this value; they do not
+separately compile the auction plan, construct the orchestrator, rebuild the
+integration registry, enumerate browser bundles, or reconstruct the digest.
+
+The composition is immutable and may live for a request, a Fastly sandbox, or a
+bounded adapter cache without changing semantics. Stored capabilities are
+`Send + Sync` and request-stateless. Script text buffers, Next.js stream state,
+document observations, and other mutable transformation state are created by
+per-document factories and live in request/processor state, never in a reused
+registry object. Composition work is O(configuration); exact asset hashes are
+build-time inputs and template identity is lazy/memoized as described below.
+
+Runtime construction returns a staged `CompositionAttempt`, not only
+`Result<TrustedServerComposition, _>`. The attempt contains
+`validated_settings: Option<Arc<Settings>>` and
+`composition: Result<Arc<TrustedServerComposition>, Report<TrustedServerError>>`.
+The settings view becomes `Some` only after envelope/schema decoding,
+inactive-secret preprocessing and resolution, resolved-value validation,
+auction-plan compilation, plan-dependent enabled-integration validation, and EC
+partner validation. It is captured before target validation, mediator lookup,
+route insertion, and executable capability construction. A failure before that
+point returns `None`; a failure after it returns the same `Arc<Settings>` beside
+the error. Fastly retains its JA4 gate and failed-startup finalization paths
+through that value without re-reading the config store. Other adapters may
+ignore the view, but none reconstructs it independently.
+
+Adapter configuration resolution produces one `ResolvedConfigLocation` and one
+verified byte source before composition. It identifies the adapter, logical
+selector, platform store/binding name, physical store identity when the platform
+exposes one, and exact root key. Defaults and service-scoped overrides are
+resolved once by the adapter/EdgeZero boundary; core chunk reconstruction never
+re-derives them, and the integrations crate never reads process configuration.
+Root/chunk absence or an unavailable platform read becomes a redacted
+`ConfigurationUnavailable` error category. Envelope, pointer, chunk hash,
+length, schema, or parse failures remain configuration corruption. The category
+does not define one cross-adapter HTTP status; adapters retain their baseline
+startup policy except for the named Fastly correction:
+
+| Adapter    | Unavailable source                                                                                                                                                                                   | Verified-data corruption                                                                        |
+| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| Fastly     | A missing or not-yet-propagated root/chunk uses the intentional transient 503 startup path. A store-open or other platform I/O failure retains the baseline 500; `GET /health` remains 200 liveness. | Application routes use the existing configuration/500 path; `GET /health` remains 200 liveness. |
+| Axum       | Existing configuration/500 startup router on every route, including `/health`.                                                                                                                       | Same existing configuration/500 path.                                                           |
+| Cloudflare | Existing configuration/500 startup router on every routed request.                                                                                                                                   | Same existing configuration/500 path.                                                           |
+| Spin       | Existing startup-error router: application routes return 503 and `/health` remains 200.                                                                                                              | The same baseline router/status behavior; structured logs retain the corruption classification. |
+
+Fastly's entry-point config-store open before app construction and pre-router
+JA4 settings read retain their existing 500 failure path; the named 503
+correction applies only after a store opens successfully and its selected
+root/chunk is absent or unpropagated. `GET /health` bypasses these reads.
+
+No error includes configuration bytes, store contents, or secret values.
+
+Core retains neutral config-store access, Fastly chunk reconstruction, blob
+envelope verification, preprocessing for inactive neutral/global secret
+references, secret-resolution primitives, global settings types, and
+auction-plan compilation. Today the neutral preprocessor removes inactive
+Tinybird token references and disabled EC-partner pull-token references; that
+behavior remains in core. These helpers accept or return neutral data and never
+call the concrete catalog. Adapter-specific readers consume the resolved
+location and produce one verified envelope/data value; Fastly chunk
+reconstruction remains a core loader helper, while Cloudflare and Spin adapt
+their existing binding/KV inputs to the same verified-data boundary. The
+integration crate composes it in this order:
+
+```text
+config-store bytes
+  → core chunk reconstruction and envelope verification
+  → application-schema dispatch
+  → schema-2 sidecar/map bijection or schema-1 normalization
+  → core-owned neutral/global inactive-secret preprocessing
+  → catalog-owned integration inactive-secret preprocessing
+  → aggregated core + integration secret resolution
+  → catalog-aware resolved-value validation
+  → core AuctionPlan compilation
+  → catalog-aware plan-dependent and core EC-partner validation
+  → validated settings-only neutral view
+  → target validation
+  → mediator resolution
+  → plan-dependent capability construction
+  → core IntegrationRegistry and orchestrator construction
+  → browser asset composition and document fingerprint
+  → TrustedServerComposition
+```
+
+The CLI imports `TrustedServerAppConfig`, the complete, partial, and validated
+source views, and pure validation APIs from `trusted-server-integrations`. The
+host-only CLI continues to own command dispatch and the direct `edgezero-cli`
+dependency; `trusted-server-integrations`, which is linked into every WASM
+adapter, never depends on `edgezero-cli`.
+
+The current locked EdgeZero revision does not expose enough context for this
+contract. Building on EdgeZero PR #381 and Trusted Server PR #1175, EdgeZero
+therefore gains narrow `run_*_typed_with_hooks` entry points with source and
+command hook objects supplied by the downstream caller; their defaults are
+no-op. Trusted Server owns a wrapper argument type that flattens EdgeZero's
+non-exhaustive `ConfigValidateArgs` and adds repeatable `--adapter`; it does not
+add fields to EdgeZero's public argument type. Each command resolves its
+adapter set before either hook: zero or more for validate and the existing one
+for diff/push. One exact source read supplies both the raw/source-aware parse
+and the typed overlay view, secret checks, command callback, diff, envelope, and
+serialization; neither EdgeZero nor a callback may reopen the path. Hook context
+contains the command kind, resolved adapter set, app environment-variable
+prefix, `--no-env`, EdgeZero's existing `strict` flag, raw path and bytes, and a
+borrow of the overlay-applied typed value. EdgeZero invokes command validation
+and serializes that same value. Validate, diff, and push therefore cannot
+validate one app-config read or typed value and serialize another.
+
+All workspace `edgezero-*` dependencies are then repinned together to one
+immutable, reviewed successor tag or commit containing both the environment
+selector work and this extension. The review checkpoint happens to use v0.0.8;
+the design does not assume that version is the successor's immediate parent.
+The extension does not alter manifest parsing, target selection,
+environment-overlay mechanics, logging, storage, or adapter behavior. It
+replaces the filesystem snapshot wrapper entirely: config commands do not write
+temporary operator or manifest copies, require a writable checkout, rewrite
+logged paths, or rely on destructor cleanup around `process::exit` and signals.
+If the extension cannot land and the workspace cannot repin to its reviewed
+revision, milestone 1 is blocked rather than restoring the snapshot design.
+Push-time selected-target validation is an explicit milestone-one CLI delta
+needed to place all deploy validation behind the new composition root; it does
+not enable schema 2 or configuration-order semantics.
+
+Read-only `config ad-templates` and `audit ad-templates` commands load the
+effective `SourceConfigView` with the existing optional environment overlay when
+they currently require the complete typed root. Mutating or generator commands
+load file bytes without the overlay, so environment-only values are never
+persisted. Recovery-oriented ad-template generation uses an explicitly bounded
+`PartialSourceConfigView<AdTemplateConfig>` against an otherwise invalid
+baseline, preserving its current warning and non-disclosure behavior.
+"Structural-only" means valid TOML, explicit parent/descendant structure, ID
+grammar, and typed parsing of the subtree the command reads or writes; it
+excludes unrelated required values, plan compilation, target validation, active
+secret values, and publisher-domain deploy checks. Candidate and baseline use
+the same selected validation level: a valid candidate is written; an invalid
+candidate is refused when the baseline was valid; and an invalid candidate over
+an already-invalid baseline retains the current warning and atomic-write escape
+hatch without disclosing source values. Final validate, diff, and push always
+use the complete `ValidatedSourceConfig` path.
+
+The migration updates ad-template lint/help text and `--explain` rule counts in
+the same commit so neither describes `[auction.providers]` or reports a stale
+number of checks. Documentation-snippet and exact-message tests pin the new
+integration-owned paths and counts.
+
+`ts prebid bundle` obtains typed bidder, User ID, analytics, and managed-module
+requirements through an integration-owned
+`PartialSourceConfigView<PrebidConfig>` rather than a duplicate CLI schema. It
+intentionally does not require unrelated app
+configuration or an `external_bundle_url` to be deploy-valid: `bundle.modules`,
+`external_bundle_sha256`, and `external_bundle_sri` are inert staging metadata,
+while `external_bundle_url` activates the browser capability. The command
+retains its current ability to build first, patch hash/SRI metadata through the
+permission-preserving `write_file_atomically` path, and tell the operator to
+upload and set the URL. It validates the structural
+pre-pass and affected Prebid subtree before writing; full app validation remains
+the contract of config validate/push. Because parent position is runtime order,
+the command no longer invents or appends a missing `[integrations.prebid]`
+parent. It requires an existing parent with explicit `enabled`, or exits with a
+placement example; it may create only owned descendants beneath that parent.
+Provider diagnostics display qualified providers in configuration order rather
+than alphabetizing a detached map. TOML parse failures report only the path and
+line/column; diagnostics never echo source lines or configuration values. The
+command canonicalizes both the Node package root and every integration-owned
+source input and rejects realpaths that do not belong to the same workspace and
+worktree checkout.
+
+`ts audit generate` may retain detector and edit metadata for concrete
+integrations under this design's audit-reorganization non-goal. That metadata is
+not a second runtime schema: audit candidates and final writes are parsed and
+validated through `SourceConfigView`/`ValidatedSourceConfig`, and the audit code
+does not define activation, defaults, secret metadata, or capability
+construction independently.
+
+## Static Rust Catalog and Browser Discovery
+
+### Rust
+
+`trusted-server-integrations/src/lib.rs` declares a small, explicit static
+catalog. Each entry names an `IntegrationId` and a crate-private `definition`
+function from a same-named directory. Rust compilation checks every listed
+module and definition signature. A host-target completeness test enumerates
+immediate `src/integrations/<id>/mod.rs` directories and fails if a valid
+directory is missing from the catalog or a catalog ID has no directory. IDs
+must parse as the `IntegrationId` defined by this design and must be unique.
+
+There is no directory-local numeric order. Runtime order belongs to
+configuration.
+
+This intentionally avoids a Rust build script and generated module
+declarations for a sixteen-entry table. The catalog-completeness test provides
+the missing-registration guard without making filesystem discovery part of
+compilation.
+
+### JavaScript
+
+`trusted-server-js` and `trusted-server-integrations-js` use one browser Node
+toolchain project, one browser lockfile, and one coordinated set of Vitest,
+ESLint, Prettier, Vite, and Prebid resolution rules. The canonical project root remains
+`crates/trusted-server-js/lib`; `trusted-server-integrations-js` does not add a
+second `package.json` or lockfile. Neutral browser sources remain under
+`trusted-server-js`; integration sources, owned unit/artifact fixtures, and
+owned unit/artifact tests live under `trusted-server-integrations-js`. The
+shared configuration does more than include that sibling source root:
+
+- Vite and Vitest resolve bare packages through the canonical project's
+  exports-aware resolver. Runtime state is externalized behind the facade; the
+  build does not depend on bundler deduplication of stateful entry points.
+- TypeScript includes both source roots and supplies exact package paths where
+  Node's ancestor walk cannot reach the canonical `node_modules`. Milestone 1
+  first adds ambient `?inline`/`?raw` module declarations, a production
+  two-root `tsconfig` with `vite/client`, `DOM.Iterable`, and the current target,
+  and fixes the existing duplicate `w`/`h` production errors. It then enables a
+  no-emit typecheck of production sources; legacy Vitest typing is not hidden
+  behind that production gate.
+- Vitest names the sibling test directory and includes its runtime tests. A
+  separate isolated canary command intentionally typechecks a fixture with one
+  expected error and asserts that exact diagnostic, so an empty glob or disabled
+  source checking cannot pass silently. The canonical package provides a real
+  `npm run typecheck` script for both production roots.
+- ESLint is invoked from their common ancestor with explicit source globs; it
+  does not require moving `package.json`. Prettier always
+  receives the canonical `--config` path for sibling files.
+- Generated external-Prebid entries live under the canonical project or use an
+  explicit resolver that preserves the `prebid.js` package `exports` map; a
+  directory alias that bypasses package exports is forbidden.
+- Because the current `gpt_bootstrap.js` fails the canonical formatter and
+  legacy browser lint rules, its move preserves output behind one exact-path
+  Prettier ignore and one documented, exact-path ESLint legacy override. The
+  shared rules are not weakened; modernizing that file is separate work.
+
+Separate build targets emit neutral and integration artifacts directly into
+private owner-specific directories below their Cargo `$OUT_DIR` and validate
+per-target manifests before embedding them. The GPT integration target bundles
+one bootstrap-safe entry point owned by neutral browser source before its own
+listener code in the existing tag. This source-level dependency is explicitly
+declared and allowlisted in the cross-root import gate; it is not a general
+permission to import stateful core facilities. The integration manifest hashes
+that neutral entry point and its generated ABI record, so a service change
+invalidates GPT output without making unrelated integration source part of the
+neutral manifest. No build script reads a sibling Cargo `$OUT_DIR`, and GPT
+does not maintain a second claim algorithm. The targets never clean, discover, or copy from one shared `dist`
+directory. A checked-in, dependency-free Node runner
+outside `node_modules` acquires one atomic-directory lease at the canonical
+project root and records holder PID, process-start identity, nonce, start time,
+and child process-group/session identity. One public command acquires the outer
+lease. It passes an unguessable inherited nonce to nested npm scripts or helper
+runners; a nested runner verifies that nonce against the live lease and joins
+the ownership scope without acquiring or releasing it. A missing, mismatched,
+or externally supplied token fails rather than granting re-entrancy. This makes
+the concrete Cargo-build-script → runner → `npm run` → nested runner → Node
+chain non-deadlocking while keeping build, manifest validation, and output copy
+under one lease.
+
+The outer runner starts the requested command in a dedicated process group or
+the host's equivalent job/session and does not release the lease until that
+ownership scope is gone. Stale recovery requires the recorded holder and the
+complete recorded child scope to be absent for the grace interval; if the host
+cannot prove that condition, recovery refuses with a diagnostic instead of
+replacing `node_modules` beneath a possible orphan. PID reuse is rejected using
+the recorded process-start identity. `npm ci`, Vite, Vitest, TypeScript, ESLint,
+Prettier, both Cargo embed builds, and the CLI Prebid builder all use this outer
+or authenticated nested path. Owner manifests record a digest of their complete
+artifact-affecting source inputs and reject stale output. Browser npm scripts,
+build scripts, and workflows use the same runner and lock path; a repository
+guard rejects bare `npx` or unwrapped production-browser-tool invocations.
+Per-crate locks are invalid. Independent docs and Playwright projects retain
+their own dependency trees and commands and are outside this production-browser
+lease unless they invoke the canonical browser project.
+
+Out-of-Cargo browser tests do not find the newest Cargo `$OUT_DIR` or read a
+shared `dist`. A host-only integration-test artifact exporter links the
+integrations composition root, which links both Rust browser crates, and
+accepts an explicit test configuration fixture. It writes that composition's
+embedded production bytes, IDs, SHA-256 hashes, and load phases to a fresh
+caller-selected temporary directory plus a manifest. The export includes GPT
+bootstrap, APS renderer document, the neutral finalizer, immediate, deferred,
+and standalone assets selected by the fixture. The exporter refuses a
+pre-existing output directory and verifies every written hash against the
+embedded value. Playwright and initial-render harnesses receive that manifest
+path explicitly, verify hashes before evaluation, and fail on a missing or
+unexpected asset. CI builds the exporter and runs any canonical Node project
+work through the shared lease; it never stages a second authoritative bundle
+set or guesses an output by modification time. The exporter is test tooling,
+not a runtime endpoint or operator CLI command.
+
+The integration build discovers all directories containing `index.ts` and
+emits one IIFE per entry point. Typed Rust registration and composition classify
+those built assets as immediate, deferred, or standalone; filesystem discovery
+does not select a load phase. An IIFE may call the external versioned
+browser runtime facade and therefore is not described as self-contained. Its Cargo build embeds each
+output and its SHA-256 hash. CI, browser integration scripts, and the CLI
+Prebid builder use the single workspace root rather than maintaining a second
+dependency graph. Dependabot's existing browser entry continues to watch this
+one lockfile; the existing docs entry is unchanged.
+
+Canonical npm build, typecheck, lint, format, and test commands include both
+source roots explicitly, and CI invokes those commands rather than core-only
+paths. A resolution test imports `vitest`, `prebid.js`, and one exported Prebid
+module from a sibling integration file. The neutral Rust build script watches
+and hashes only neutral source plus shared configuration that can affect its
+artifact. The integration Rust build script watches and hashes the integration
+source plus the public facade declaration, the declared neutral
+first-impression source entry point and ABI record consumed by GPT, and shared configuration that can
+affect its artifacts. The production two-root typecheck and other repository
+validation commands remain separate validation inputs; they do not make sibling
+integration bytes part of the neutral owner manifest. Clean, incremental, and
+concurrent build tests change one integration source and prove the integration
+manifest is regenerated without spuriously changing the neutral manifest or
+observing another build's partial output. Changing the neutral entry point
+regenerates GPT's bootstrap artifact and its integration manifest; changing an
+unrelated integration leaves both neutral output and GPT's bootstrap unchanged.
+
+`build-prebid-external.mjs` and its npm command remain at the canonical Node
+root as build orchestration, not browser runtime. The Prebid registry, aliases,
+shims, and other integration-owned source inputs move with Prebid into
+`trusted-server-integrations-js`. The launcher receives their resolved sibling
+paths explicitly and has no hard-coded `src/integrations/prebid` assumption.
+The CLI resolves the canonical package root for dependencies and obtains the
+integration-owned input paths and typed module requirements from the
+integrations facade; it does not locate a registry through its own relative
+path constant. The facade returns repository-relative paths, never absolute
+compile-checkout paths. The CLI resolves both the package root and inputs under
+one selected runtime repository/worktree root, canonicalizes them, and rejects
+any realpath that escapes or crosses that checkout. A two-worktree test proves
+it cannot fall back to a compile-time `CARGO_MANIFEST_DIR` in the other checkout.
+
+When a browser build is required, a missing `npm` or failed dependency setup is
+a hard error. `TSJS_SKIP_BUILD=1` is a local-development escape hatch only when
+every expected owner manifest and artifact exists and its recorded input digest
+matches; CI never sets it. Build scripts emit `rerun-if-env-changed` for
+`TSJS_SKIP_BUILD`, `TSJS_TEST`, and every tool environment variable that changes
+output, in addition to complete `rerun-if-changed` input coverage. Every Rust CI
+job that can build either browser crate installs the repository-pinned Node
+version and dependencies, satisfying prerequisite #1204.
+
+The generated Rust API exposes typed module identifiers rather than accepting
+unchecked strings. A Rust registration referencing a missing browser module
+therefore fails compilation. JavaScript-only modules are valid and need no Rust
+definition.
+
+The explicit Rust catalog and generated browser catalog are independent;
+neither inventory is treated as the canonical list for the other.
+
+## Neutral Core Contracts
+
+The neutral contents of `integrations/registry.rs` move to singular
+`trusted_server_core::integration`. Core continues to own:
+
+- `IntegrationDefinition` and `IntegrationRegistration` contracts.
+- `IntegrationRegistry` and registry execution.
+- Proxy, request-filter, attribute-rewriter, script-rewriter,
+  HTML-stream-processor, and head-injector traits and contexts.
+- Neutral request-preparation and response-finalization hooks.
+- Neutral request-processing and response-sharing annotations.
+- Neutral browser-asset metadata, byte/hash access, load modes, and composed
+  document fingerprints.
+- OpenRTB profile registration contracts consumed by the generic plan and
+  transport engines.
+- Mediator registration contracts consumed by auction orchestration.
+- Duplicate route, ID, renderer-type, and capability detection.
+- Empty and stub registrations for core tests.
+
+Core does not own a global `IntegrationType` enum. The builder has typed methods
+for each supported contribution, and one definition may supply any compatible
+combination. The initial methods correspond only to behavior present in the
+repository.
+
+An APS definition conceptually registers:
+
+```text
+APS
+├── proxy capability
+├── head-injection capability
+├── JavaScript renderer module
+└── OpenRTB profile capability
+```
+
+Capability multiplicity is explicit. Collection capabilities such as routes
+and rewriters may register multiple entries. Single-valued capabilities such as
+an OpenRTB profile or mediator may appear at most once per integration
+definition; duplicate registration fails composition. Because provider tables
+have no profile discriminator, an integration that owns
+`auction.providers` must register exactly one OpenRTB profile capability.
+
+Before constructing executable capabilities, each definition produces a pure
+`IntegrationDeclaration` from its validated, unresolved-secret source view. It
+contains provider/profile facts, mediator presence, browser modules, reserved
+inputs, exact or pattern-based route claims, and ordered script-source claims.
+These declarations are the shared input to CLI and runtime validation; they do
+not allocate clients, read secrets, or execute a rewriter.
+
+A script-source claim is a pure transition
+`apply_script_source(context) -> Unchanged | Replace(new_url) | Remove` with its
+owning integration ID and source field. `context` carries the exact element and
+attribute names, parsed URL, and relevant `rel`/`as` tokens; it therefore does
+not confuse arbitrary `src`/`href` attributes with `<script src>` or
+`<link rel="preload" as="script" href>`. Every executable native/proxy rewriter
+calls the same transition function it declared; there is no separately
+reimplemented matcher. Prerequisite #1199 converts the current raw-substring
+matchers to canonical URL ownership and supplies one shared positive/negative
+corpus used against both declaration and execution paths.
+
+Schema-2 validation evaluates the complete enabled chain for every enabled or
+blocked `js_asset_proxy` asset, carrying each replacement URL and unchanged element
+context into all later claims. It simulates both policy subjects: script source
+and script preload. An `enabled` policy must finish at that asset's
+configured first-party `path`; a `blocked` policy must finish in `Remove`, so an
+earlier compatible removal is accepted rather than called a conflict. Any other
+final outcome fails validate, diff, and push, naming every participating table,
+transition, element kind, original URL, and final outcome. Schema-1
+compatibility uses the frozen legacy chain and does not apply new schema-2
+operator-policy strictness.
+
+`disabled` retains the asset definition without registering its proxy route or
+imposing an operator script-source outcome. Its own transition is `Unchanged`;
+other enabled rewriters may still change or remove the element. Validation and
+the runtime clamp below do not turn a disabled asset into an enabled or blocked
+one. This preserves the existing three-state `JsAssetProxyMode` behavior.
+
+Runtime repeats the check, but catalog drift in a previously stored schema-2
+blob is not an all-routes startup failure. On an asset-policy mismatch it emits
+a sampled structured error containing the tables, URL, element kind, and build
+ID. The rewrite engine first records the original canonical script/preload URL
+and computes the complete ordinary chain, including a terminal `Remove`. Before
+committing that outcome to the HTML processor, an engine-owned exact-URL policy
+clamp overrides it for this stored asset: enabled emits the original element
+with its source set to the configured first-party path, and blocked removes the
+element. A removed element is never expected to reach another ordinary
+rewriter. The clamp is a catalog-drift disaster-containment exception for the
+script-source policy chain; unrelated document, consent, or response
+suppression outside that chain still applies. It does not change validation or
+ordinary `Remove` semantics. When a newly
+declared integration-owned native route collides with an operator asset path,
+the asset route is kept and that integration route is dropped with the same
+diagnostic. Fixed application routes are never droppable. Native/native and
+other configuration errors still fail composition.
+
+The release gate is a checked-in `ts config validate-stored-catalog` workflow
+linked to the candidate catalog, invoked with
+`--inventory <deployment-inventory> --exports <ephemeral-directory>`. The
+deployment control plane supplies the authoritative environment inventory and
+exports each environment's exact verified envelope plus adapter and resolved
+location metadata into a restricted ephemeral workspace; values and envelope
+bytes never enter logs or build artifacts. The command proves inventory/export
+bijection, verifies each envelope, runs application-schema dispatch and the
+pure unresolved-secret declaration/route/script-policy checks, and reports only
+environment identity, hashes, build ID, and redacted diagnostics. These checks
+need no resolved secret values because source-visible claims are forbidden from
+depending on them. A missing environment/export, verification failure, or any
+degraded conflict blocks promotion. The pipeline deletes the exports after the
+gate. `--exports` is a read-only input to the command; the command never deletes
+or rewrites a caller-supplied path. The release pipeline creates the export
+directory beneath its controlled temporary root, records a nonce-bearing
+ownership marker, and in its unconditional cleanup validates the directory's
+non-symlink real path and marker before removing only that directory. Runtime
+repetition remains disaster containment rather than accepted steady state.
+
+For every candidate release while schema-one readers remain deployed, this
+same inventory also runs each live schema-one export through the deployed reader
+and candidate reader under identical secret resolution in a restricted
+environment. It compares normalized settings, activation, hook/browser/route
+and provider order, external labels, and error classifications, modulo only
+explicitly reviewed behavior changes. Missing exports or a difference block
+promotion. The archived fixture used at initial cutover supplements rather
+than replaces this per-release, per-environment differential gate; no secret
+value or decoded envelope is logged.
+
+`ts config migrate` evaluates the complete schema-2 chain. Because its
+deterministic output order may make reordering unreachable, it comments out a
+mismatched asset table with a preservation/report block instead of emitting a
+candidate that will fail or silently bypass policy.
+
+Route claims likewise carry method plus canonical path/pattern ownership and
+are derived from pure configuration, including Prebid `script_patterns` and
+`js_asset_proxy` routes. Source validation inserts them into neutral routers
+using exactly the runtime's HTTP-method partitioning, trailing `/*` to
+`/{*rest}` normalization, and pinned `matchit` insertion behavior. A conflict
+is a failed insertion, not merely equal source strings or overlapping accepted
+URLs. Runtime registry construction calls the same helper. Duplicate routes
+therefore fail in `ValidatedSourceConfig`; runtime uses only the narrow
+operator-asset drift fallback above. A future integration whose route shape
+depends on a resolved secret needs a separate contract; it may not defer an
+otherwise source-visible route collision to startup.
+
+The same router begins with fixed `ReservedRouteClaim` values. Core owns the
+common application-route inventory—discovery, auction, page-bids and its legacy
+alias, first-party routes, `POST /verify-signature`, the method-complete
+`/_ts/admin/cache/purge` claim, and only admin routes actually registered by
+every adapter. Fastly alone claims `POST /_ts/api/v1/batch-sync` and
+`GET`/`OPTIONS /_ts/api/v1/identify`; those paths retain their existing
+publisher fallthrough on adapters without the routes. Each adapter adds its
+target-specific fixed routes and dynamic namespaces, including `/health` only
+where that adapter actually registers it. Claims come from the same typed route declarations that register
+fixed handlers; an adapter that cannot use those declarations directly must
+provide a route-table parity gate comparing its actual registrations with the
+claims by HTTP method, canonical path/pattern, catch-all precedence, and
+method fallthrough. A separately maintained list of presumed routes is not a
+completeness proof. In particular, every method that can reach publisher
+fallback at the cache-purge path must stay intercepted so an unsupported method
+cannot forward authenticated admin credentials to the publisher origin; methods
+rejected by the adapter before fallback are outside this claim. Target-neutral validation checks the
+common set; `validate_for_targets` adds the selected adapter set; runtime uses
+the identical combined helper before inserting integration claims. A
+configured asset or integration claim colliding with a
+reserved route is always a hard source/startup error, including under catalog
+drift. The asset-wins exception applies only to a newly added
+integration-owned route competing with an already stored operator asset.
+
+The OpenRTB profile boundary has three stages:
+
+1. `OpenRtbProfileDefinition` is the catalog-level capability. It supplies the
+   stable profile ID, default timeout policy, typed configuration compiler,
+   endpoint canonicalization and validation, and supported routing policy.
+2. `CompiledOpenRtbProfile` is an object-safe, `Send + Sync` immutable profile
+   stored as an `Arc` in each provider plan. It exposes only neutral routing
+   facts and prepares one provider exchange from neutral auction input.
+3. Preparing a provider returns `Exchange(PreparedOpenRtbExchange)` or
+   `Skip { metadata }`. `Skip` preserves the current no-impressions/no-transport
+   outcome and any profile-specific diagnostic metadata. An exchange contains
+   the finalized outbound request plus a boxed, object-safe response parser
+   bound to that exact provider and request. The parser owns any request-local
+   APS, Prebid, or standard parsing state and consumes itself when parsing the
+   response.
+
+The prepared exchange lets the core engine retain shared backend registration,
+transport, deadlines, notification policy, normalized response handling, and
+telemetry. The profile owns request specialization, profile-specific headers,
+debug capture, response parsing, diagnostics, and renderer descriptors.
+
+The neutral preparation input explicitly carries the current request facts:
+DNT, raw Cookie, User-Agent, Referer, Accept-Language, attested client IP,
+zone, consent-filtered identity/EIDs, routed demand, logical budget, transport
+budget, and optional signer. Core constructs that snapshot, stamps the
+`QualifiedProviderId`, and owns the generic request/response envelope. A
+profile owns only its current branch points and bound parser state; moving code
+does not duplicate the shared OpenRTB engine inside each integration.
+
+Renderer-bearing bids use a neutral, versioned descriptor with
+`renderer_type`, opaque payload, and the handler-supplied targeting bid ID. Its
+serde representation is byte-for-byte compatible with the existing tagged
+`BidRenderer::Aps` JSON. Core may carry and serialize the descriptor, but only
+the registered renderer handler interprets its payload or supplies APS/GPT
+browser metadata.
+
+Neutral routing policy replaces checks such as `is_prebid_server`. It expresses
+only behaviors the generic router needs, including whether `all_eligible` is
+allowed, whether trusted stored-request demand is recognized, and how bidder
+parameters are admitted. Endpoint policy likewise replaces string comparisons
+against profile IDs.
+
+No stage returns `Any`, requires a downcast, or indexes a vendor-keyed side
+table. Because the response parser is created by the same profile object that
+prepares the request, state from one provider instance cannot be supplied to
+another accidentally.
+
+The standard OpenRTB implementation is registered by the built-in `openrtb`
+integration. APS and Prebid register their implementations from their own
+directories. `adserver_mock` registers the existing mediator capability.
+
+The mediator does not reuse or expose the legacy `AuctionProvider` trait. Its
+neutral boundary has three parts:
+
+1. `MediatorDefinition` compiles one integration's mediator configuration.
+2. `CompiledMediator` receives the original auction request, the already
+   ordered provider responses, and the remaining bounded runtime context. It
+   returns a `PreparedMediatorExchange`.
+3. `PreparedMediatorExchange` contains the finalized outbound request and a
+   bound response parser that consumes the upstream response into the existing
+   normalized mediation result.
+
+Core retains mediator transport, deadline enforcement, telemetry, and the
+corrected prerequisite #1203 outcome policy. Dispatch, transport, deadline,
+parse, and non-2xx failures warn and fall back to local ranking. Non-2xx uses
+the existing response metadata `error_type = "http_status"`, which maps to the
+existing telemetry row status `http_status_error`; numeric status and fallback
+use structured logs or existing metadata rather than new datasource columns.
+It never fabricates a mediator winner, and the original ordered provider
+outcomes and locally selected winner remain attributed to their providers. The
+current mediator endpoint policy, including
+an allowed HTTP endpoint where supported today, is preserved. Its response
+correlation remains the current mediator integration identity rather than being
+silently rewritten as an auction-provider identity.
+`adserver_mock` owns only request construction and response interpretation. The
+old mediator use of `Arc<dyn AuctionProvider>` is deleted when its last caller
+migrates.
+
+No unused generic `AuctionProviderFactory` extension is added. A provider that
+cannot use the current OpenRTB engine will define that additional seam in a
+future design.
+
+## Static Catalog and Activation
+
+The explicit static catalog establishes what the binary supports.
+Configuration establishes what runs.
+
+Source validation and runtime startup both resolve IDs through the same catalog.
+Source validation runs the validation-only plan path described above. At
+runtime, after secrets are resolved:
+
+1. Parse `[integrations]` into an ordered sequence.
+2. Resolve each ID against the static definition catalog.
+3. Ask each owning definition to parse and validate its complete configuration
+   and expose catalog-level profile/mediator definitions.
+4. Collect enabled integration-owned provider instances into the independent
+   flat provider sequence and ask core to compile the single canonical auction
+   plan.
+5. Construct plan-independent capabilities, then construct plan-dependent
+   capabilities such as Prebid bidder ownership, head injection, and mediator
+   selection with a read-only `Arc<AuctionPlan>`.
+6. Resolve typed browser modules and construct the neutral integration registry
+   and orchestrator in configured order.
+
+An absent integration is inactive. Every explicit parent integration table must
+contain `enabled = true` or `enabled = false`; there is no integration-specific
+default. `enabled` is the integration's master gate, not an assertion that every
+optional capability is configured. An explicitly disabled integration may
+retain its settings and provider instances but contributes no runtime
+capabilities or providers. Configuration cannot activate APS or Prebid through
+an auction plan while omitting its parent. References to an absent or unknown
+parent fail validation. References to an explicitly disabled, known integration
+remain in source as a kill switch: they are omitted from the compiled route or
+mediator plan with one aggregated warning and ordered diagnostics. Their IDs,
+references, and structure are still fully validated; only active-value
+semantics resume when the parent is enabled. No unknown ID is silently treated
+this way.
+
+Provider-owning integrations use the following explicit activation rules. They
+do not add capability names or implementation discriminators to operator
+configuration.
+
+| Integration     | Enabled configuration                            | Runtime contribution                                                                                                                            |
+| --------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| `aps`           | No provider instances                            | No runtime contribution; retained settings remain structurally validated.                                                                       |
+| `aps`           | One or more provider instances                   | One OpenRTB provider plan per instance plus coupled APS renderer/head/browser support and the mode-dependent proxy required by those providers. |
+| `prebid`        | No providers and no `external_bundle_url`        | No runtime contribution; retained settings remain structurally validated.                                                                       |
+| `prebid`        | Provider instances, but no `external_bundle_url` | Server-side OpenRTB provider plans only; no proxy, rewriter, head injector, managed browser User IDs, or deferred browser module.               |
+| `prebid`        | Valid `external_bundle_url` and browser settings | Existing Prebid proxy, rewriter, head injector, managed User IDs, and deferred browser module, with zero or more server providers.              |
+| `openrtb`       | Zero or more provider instances                  | One standard OpenRTB provider plan per instance; zero instances is a valid staged no-op.                                                        |
+| `adserver_mock` | Enabled parent                                   | The existing mediator capability, independently of provider count.                                                                              |
+
+Thus a current server-only Prebid provider migrates beneath an enabled Prebid
+parent without activating Prebid's page/browser behavior. Browser-only Prebid
+continues to be selected by the same required external-bundle URL that current
+startup validation already uses. The closed browser-only source-field set is
+`account_id`, `debug`, `timeout_ms`, `script_patterns`, `client_side_bidders`,
+`excluded_gam_ad_unit_path_suffixes`, and `managed_user_ids`. Any field in that
+set whose normalized value differs from its current declared default requires
+`external_bundle_url`; merely spelling the current default remains inert and is
+omitted at the storage boundary. Runtime applies the same closed-set rule by
+presence because stored default-valued leaves have already been omitted. This
+prevents a partial browser path while allowing a later binary's defaults to
+apply without a repush. An implicit or explicitly equivalent default
+script-pattern set alone does not activate or fail.
+CLI-only `bundle.modules`, `external_bundle_sha256`, and
+`external_bundle_sri` may be staged without a URL and never activate runtime
+browser behavior. For APS, a configured provider necessarily activates its
+renderer support; an enabled APS parent with no provider is a staged no-op.
+
+Requiring the enabled parent is an intentional activation change from the
+current split inventory. Today an APS auction profile can activate rendering
+support without an enabled `[integrations.aps]` block. After cutover, every APS
+provider requires an explicit enabled parent, and its coupled server and
+renderer capabilities activate together.
+
+Disabled configuration receives schema-safety validation only: unknown fields,
+wrong types, integration/provider ID grammar, duplicates, and secret-reference
+name/store-reference/collision/adapter rules still fail. Active-only required
+fields and value validators—including ranges, endpoint policy, format patterns,
+and cross-field rules—are deferred until the integration is enabled. This preserves current
+disabled placeholders such as the example Google Tag Manager container while
+preventing malformed structure or secret references from being stored. At
+runtime, integration-owned preprocessing removes inactive secret paths before
+value resolution, so disabled behavior does not leak into the runtime plan.
+
+Each definition implements that split with an owner-provided structural DTO or
+parser and a separate enabled semantic compiler. The structural phase names the
+fields that may be absent only while disabled and still parses every present
+field with its real type; it never classifies a serde error by matching error
+text such as `missing field`. Enabling reparses or converts the same structural
+value through the semantic compiler, which enforces the deferred required and
+cross-field rules. Catalog completeness tests require both paths for every
+definition that supports disabled placeholders.
+
+The four adapters share the runtime composition path. The CLI and adapters
+share the source/catalog validation rules; runtime and deploy validation cannot
+use different catalogs, integration schemas, or plan-input validation.
+
+## One Integration Configuration
+
+### Operator-facing shape
+
+`[integrations]` is the single concrete integration inventory. No `type` field
+is added; the table key resolves the statically compiled definition.
+The `enabled` field is mandatory on every parent integration table, including
+the built-in `openrtb` integration.
+
+```toml
+[integrations.prebid]
+enabled = true
+
+[integrations.prebid.auction.providers.pbs-main]
+endpoint = "https://prebid.example.com/openrtb2/auction"
+timeout_ms = 1000
+routing = "explicit"
+debug = false
+test_mode = false
+consent_forwarding = "both"
+
+[integrations.prebid.auction.providers.pbs-main.notifications]
+suppress_all = false
+suppress_seats = []
+
+[integrations.aps]
+enabled = true
+rendering_mode = "trusted_server"
+
+[integrations.aps.auction.providers.aps-main]
+endpoint = "https://aps.example.com/e/pb/bid"
+timeout_ms = 800
+routing = "all_eligible"
+account_id = "example-account"
+debug = false
+allow_script_creatives = false
+```
+
+The parent integration determines the implementation. Integration-owned
+providers therefore do not accept `profile`, `implementation`, or
+`profile_config`. Common provider fields and integration-specific profile
+fields form one typed provider schema owned by that integration. Common
+notification settings may remain in the nested `notifications` table.
+
+The legacy `protocol = "openrtb-2.6"` field is also retired and rejected with
+migration guidance. Every provider capability in this design uses the existing
+OpenRTB 2.6 engine, so repeating its one accepted protocol value adds no choice.
+A future non-OpenRTB engine requires a separate capability design rather than a
+string switch in this schema.
+
+Multiple named provider instances are supported beneath one integration.
+
+The standard generic path uses the same inventory:
+
+```toml
+[integrations.openrtb]
+enabled = true
+
+[integrations.openrtb.auction.providers.example-direct]
+endpoint = "https://bidder.example.com/openrtb"
+timeout_ms = 1000
+routing = "explicit"
+```
+
+### Global auction configuration
+
+`[auction]` retains settings that coordinate integrations:
+
+```toml
+[auction]
+enabled = true
+timeout_ms = 2000
+rewrite_creatives = true
+sanitize_creatives = false
+mediator = "adserver_mock"
+
+[auction.bidders.example-bidder]
+provider = "prebid.pbs-main"
+```
+
+Provider references use the canonical `<integration>.<local-provider>` form.
+The qualified value is the provider identity used by the compiled plan,
+backend correlation, diagnostics, and telemetry. The local provider name may
+repeat under different integrations without collision.
+
+Provider identity uses three strong types rather than broadening the existing
+local identifier:
+
+- `IntegrationId` matches `^[a-z][a-z0-9]*(?:_[a-z0-9]+)*$`, with a maximum of
+  63 ASCII bytes. This permits existing IDs such as `adserver_mock` while
+  forbidding dots, leading/trailing underscores, and repeated underscores.
+- `LocalProviderId` retains the current
+  `^[a-z][a-z0-9-]{0,62}$` grammar; dots are forbidden. Its maximum length is
+  63 ASCII bytes.
+- `QualifiedProviderId` stores an `IntegrationId` and `LocalProviderId`, parses
+  exactly one dot separator, and has a maximum serialized length of 127 ASCII
+  bytes.
+
+`QualifiedProviderId` is the internal identity used by bidder routes, provider
+plans, and lookup indexes. Its canonical `Display` and serde representation is
+`<integration>.<local>`. `ExternalProviderLabel` is the separate validated
+string used on backend discriminators, auction responses, diagnostics,
+telemetry, mediator correlation, and other externally keyed maps: it contains
+the legacy local ID for schema 1 and the qualified ID for schema 2. Every such
+map is built from an explicit `ExternalProviderLabel -> plan ordinal` index;
+label collisions fail validation and no lookup uses `unwrap_or(usize::MAX)` or
+map iteration as a fallback ordering rule.
+
+No consumer reconstructs either type with ad hoc string concatenation,
+truncates it, or treats a local provider ID as globally unique. Adapter target
+validation predicts and rejects backend-name collisions using the complete
+qualified identity. A platform backend name is not itself the provider
+identity. Where an adapter's normalization is lossy, as with Axum mapping dots,
+hyphens, and underscores to the same character, its correlation name includes
+a stable digest of the full qualified ID. Target validation rejects any
+remaining final name collision. Tests cover aliases such as `a_b.c` and
+`a.b-c`.
+
+Internal qualified identity and externally serialized identity cut over at
+different times. The schema-1 compatibility reader constructs a qualified
+internal key but retains the legacy local provider ID for backend names,
+mediator wire correlation, public `/auction` provider details, ts-debug, and
+telemetry. Schema 2 uses the qualified value on those external surfaces. Thus
+deploying the dual reader over an unchanged schema-1 blob does not split metrics
+or mediator correlation; the documented rename occurs only when schema 2 is
+pushed. The rollout updates exact-match dashboards, alerts, Tinybird filters,
+mediator expectations, and the local template-cache harness before that push.
+
+The mediator selects an enabled integration that registered a mediator
+capability. Its settings remain under that integration:
+
+```toml
+[integrations.adserver_mock]
+enabled = true
+endpoint = "https://adserver.example.com/mediate"
+timeout_ms = 500
+```
+
+## Ordering Contract
+
+No manifest field, filename, alphabetic sort, hash-map iteration, or numeric
+priority controls runtime order.
+
+The contract is:
+
+1. Integration order is the explicit declaration order of parent
+   `[integrations.<id>]` tables.
+2. Each parent integration table must appear before any descendant table. A
+   nested auction or provider table cannot implicitly create or position an
+   integration.
+3. Provider order is the explicit declaration order of
+   `[integrations.<id>.auction.providers.<provider>]` tables. Each provider
+   parent must appear before descendant tables such as `notifications`.
+4. Every parent integration table contains an explicit `enabled` value.
+5. Disabled integrations contribute nothing; remaining integrations keep their
+   relative order.
+6. Schema-2 plan input flattens providers first by owning integration and then
+   by local provider declaration. The neutral plan input nevertheless carries
+   one independent flat provider sequence so legacy compatibility can represent
+   globally interleaved provider IDs without regrouping them.
+7. Every hook list and each immediate/deferred JavaScript list retains
+   integration order. When one integration registers multiple hooks of the same
+   capability, their relative order is the explicit order returned by that
+   integration's definition; the integration remains one operator-visible
+   position and does not expose a second priority mechanism.
+8. Browser output is neutral browser core first, the existing fixed
+   JavaScript-only `creative` prelude second, and configured integration modules
+   afterward.
+9. Auction provider launch, response, and mediator-input order follows the
+   flattened plan. With the existing strict-greater-than price comparison, the
+   first configured provider retains an equal-price tie during local winner
+   selection. Dispatch checks the remaining shared deadline immediately before
+   each back-to-back launch. A later provider receives
+   `min(remaining_deadline, provider_timeout)`; elapsed time reduces the shared
+   remainder but may not change the logical budget when the provider's own
+   shorter timeout still caps it. Order remains launch-, response-, mediator-,
+   and tie-visible even when budget values happen to match.
+10. Shared browser dispatchers execute immediate handlers by IIFE registration
+    sequence and then definition-local registration order. Because immediate
+    IIFEs are concatenated in configuration order and must register
+    synchronously during evaluation, this sequence is the configured order
+    without a second ordinal channel. Numeric priority, lexical handler ID, and
+    later wall-clock callbacks are not alternate ordering mechanisms.
+
+Ordered runtime introspection carries the configured ordinal with each
+integration and provider. Lookup indexes may use maps, but iterating a
+`BTreeMap`, `HashMap`, or alphabetized metadata view never defines or displays
+execution priority. CLI diagnostics and registry metadata that show order use
+the ordered plan/registration view.
+
+The stale comment that `js_asset_proxy` is globally first is retired. The
+effective baseline registration sequence is, when each entry is active:
+
+```text
+prebid, aps, js_asset_proxy, testlight, nextjs, permutive, lockr, didomi,
+sourcepoint, osano, google_tag_manager, datadome, gpt, gpt_diagnostics
+```
+
+Milestone-one normalization and schema-one decoding use that complete sequence;
+they do not move `js_asset_proxy` ahead of Prebid. Schema 2 instead chains
+attribute rewriters in operator-visible integration order: a replacement becomes
+the next rewriter's input and a removal is terminal. Order alone is not an
+asset-policy safeguard: validation carries every replacement through the whole
+chain and accepts only a final policy-consistent result. Reordering may change
+that result, but no position is a privileged or guaranteed override. Overlap
+tests cover blocked and enabled assets against GPT, Google Tag Manager,
+DataDome, Sourcepoint, Permutive, Lockr, Testlight, and Prebid in both
+legacy-compatible and deliberately reordered configurations. No engine-only
+override is hidden from TOML.
+
+Before either crate move, prerequisite #1208 makes script-text rewriters receive
+the current text produced by the preceding rewriter rather than having
+independent `lol_html` handlers repeatedly replace the original chunk. That
+composition applies to schema-1 and schema-2 blobs; milestone two changes only
+which integration order supplies the already-composed chain. Next.js
+App-Router/RSC flight capture is a fixed parser phase before that chain. Its
+serialized flight payload is not treated as executable script text and URLs
+inside it are not rewritten; actual executable script text and URL attributes
+outside the captured payload still traverse the composed chain. Prerequisite #1199
+similarly makes DOM-insertion guards claim canonical parsed host/path ownership,
+not substring coincidences in a query string. Built-in ownership sets are
+disjoint and tested with exactly one claimant for every canonical URL;
+configured order applies to genuinely composable handlers, not to select the
+winner of an ownership bug.
+
+Browser load mode remains a lifecycle phase, not a second operator priority:
+immediate code necessarily evaluates before deferred code. Config order is
+preserved within each phase. An emitted module that imports the dedicated
+DOM-registration accessor is marked by the integration build as requiring
+initial DOM dispatch; Rust cannot declare or override that fact by hand.
+Composition accepts such a module only with `load_mode = immediate`, and its
+IIFE must register the handler synchronously before returning. Diagnostics
+display each module's derived requirement and fixed load mode so this phase
+boundary is visible rather than inferred from timing.
+
+All recovery paths obey the same provider ordinals. Existing stable plan-index
+sorts remain. The abandon/failure path that can emit providers from `HashMap`
+iteration is changed to plan-order recovery before the new ordering contract is
+enabled; no no-op lexical-sort change is claimed as a compatibility break.
+
+Inline-table and dotted-key shorthand may not define an integration parent or
+provider parent. Requiring ordinary table headers makes activation, ownership,
+and order visible in one form and lets the pre-pass produce targeted errors.
+
+The `trusted-server-integrations` host-only `source-config` feature activates a
+direct optional, non-dev `toml` dependency with `features = ["preserve_order"]`;
+the CLI enables that feature. `handlebars` enables only
+`serde_json/preserve_order` and is not relied upon. The request is therefore
+present for the normal CLI, `cargo install`, and release binaries but absent
+from WASM-only graphs. A non-lexical fixture
+asserts that EdgeZero's overlay-applied typed integration/provider order equals
+the independent `toml_edit` pre-pass order before sidecars are generated. The
+integration-owned source model uses ordered map types with explicit iteration
+semantics, never `HashMap` or `BTreeMap`, and stored runtime order comes only
+from sidecars.
+
+Before typed deserialization, the host-only `source-config` module of
+`trusted-server-integrations` parses the source with `toml_edit`. The dependency
+and code are feature-gated out of every WASM adapter graph. This source-aware
+pre-pass rejects descendant-before-parent declarations, missing explicit parent
+tables, and missing `enabled` fields. It then permits the existing EdgeZero
+scalar environment overlay; overlays may
+replace values but may not create, remove, or reorder integration or provider
+tables. Validate, diff, and push inspect app-prefixed overlay variable names
+without reading their values into diagnostics and fail when a name targets a
+retired auction-provider or integration path; silently ignoring an old endpoint
+override is not permitted.
+
+The direct `toml_edit` dependency is pinned to the same TOML 1.1 parser
+generation as the workspace `toml` package and EdgeZero's typed parser. Parser
+parity fixtures cover otherwise-unrelated valid and invalid TOML syntax so the
+pre-pass cannot accept a document the typed path rejects, or reject one merely
+because it used an older TOML grammar.
+
+Milestone 2 explicitly upgrades the workspace's direct `toml_edit` dependency
+from its current TOML-1.0 generation to the selected TOML-1.1 generation before
+the pre-pass lands. The dependency-graph gate asserts the resolved package
+version/spec generation in addition to `toml/preserve_order`; the presence of a
+newer transitive `toml_edit` does not satisfy this requirement.
+
+Every entry point that accepts TOML uses this pre-pass, including local loading,
+CLI validate/diff/push, ad-template diagnostics and candidate validation, and
+the Prebid bundle command. The integration-test `generate-viceroy-config`
+binary also uses the same source parser and schema-2 storage serializer rather
+than retaining a direct `toml::from_str`/legacy-envelope path. Recovery mutators
+may request the structural-only mode described above. Ad-template generation
+applies the comparative candidate/baseline rule, and the Prebid builder
+validates only its owned partial view; neither recovery path is silently
+tightened into unconditional full-app validation. EdgeZero's typed mechanics
+remain responsible for overlay, validation invocation, diff, envelope
+construction, consent, and store writes after the pre-pass succeeds.
+
+The EdgeZero extension uses EdgeZero's existing path and target resolution: an
+explicit `--app-config` wins; otherwise the path is
+`<manifest-dir>/<app.name>.toml`; diff/push provide their resolved adapter; and
+the Trusted Server validate hook receives only the repeatable `--adapter`
+selections, possibly empty. EdgeZero separately retains the manifest-declared
+target set for its existing validation and `--strict` checks. Parity
+tests cover exact-byte validation and serialization, command/target context,
+explicit and default paths, manifest paths with and without parent directories,
+concurrent app-config replacement, and `--no-env`. The environment overlay can
+replace only scalar leaves already present in TOML; it cannot create an omitted
+`enabled` field, integration, provider, table, or array. Operator templates must
+contain every leaf intended for overlay.
+
+### Config-store representation
+
+JSON object member order is not an ordering contract. Config push therefore
+keeps integration and provider configuration in object maps but adds explicit
+order sidecars to the hash-verified blob envelope. This preserves the existing
+object paths used by secret metadata while making runtime order independent of
+JSON map iteration. `serde_json/preserve_order` is not required and does not
+become a workspace-wide behavior change.
+
+Conceptually, the stored representation carries:
+
+```json
+{
+  "trusted_server_schema": 2,
+  "integration_order": ["prebid", "aps"],
+  "integrations": {
+    "prebid": {
+      "enabled": true,
+      "auction": {
+        "provider_order": ["pbs-main"],
+        "providers": {
+          "pbs-main": {
+            "endpoint": "https://prebid.example.com/openrtb2/auction"
+          }
+        }
+      }
+    },
+    "aps": { "enabled": true }
+  }
+}
+```
+
+`TrustedServerAppConfig` uses custom serialization at this boundary.
+Deserialization accepts the operator TOML table shape after the source pre-pass;
+serialization emits object-shaped configuration plus the schema and order
+sidecars above. `Validate` checks the sidecar/map bijection even for commands
+such as `config validate` that do not serialize. Serialization defensively
+checks it again, and runtime loading performs the same check before constructing
+ordered settings. Missing, duplicate, extra, or mismatched names fail at all
+three boundaries.
+
+This is an explicit asymmetric serde boundary. EdgeZero's typed CLI
+deserializes and validates `TrustedServerAppConfig`, then its manual `Serialize`
+implementation emits the schema-2 storage DTO. Runtime reads that DTO rather
+than deserializing it back into the operator type. The DTO omits absent leaves
+and every leaf semantically equal to its declared default, even when the source
+spelled it explicitly; defaults are applied only by the reading binary. The
+mandatory integration `enabled` field is an exception: every stored schema-2
+integration object emits its explicit boolean, including `false`, and the
+schema-2 reader rejects an object without it. There is no implicit stored
+enablement default and no path that turns a disabled block on by omission.
+Default comparison is field-specific and uses runtime canonicalization. For
+example, Prebid `script_patterns` use case-sensitive, order-preserving,
+duplicate-rejecting comparison after the exact route-pattern normalization used
+by `matchit`, because those strings feed both a case-insensitive script-source
+matcher and case-sensitive route registration. A field may use set-like or
+case-folded default equality only when every declaration, validation, runtime,
+and CLI consumer has the same semantics. Disabled
+integration blocks remain known-field/type/schema-validated source-shaped
+objects, so fields required only when active need not be invented or defaulted
+into storage. This extends the repository's existing `skip_serializing_if`
+rollback policy: a later binary's new or changed defaults take effect without a
+repush, while any newly stored non-default field still requires the
+release-compatibility gate below or an application-schema bump. The retained
+`toml_edit` view preserves comments and editing intent for source edits; it is
+not serialized into the blob. `integration_order` is always present.
+`provider_order` is required whenever the corresponding `providers` object is
+present, including when both are empty; both are absent when an integration has
+no provider collection.
+
+For each candidate release R, the same-schema release-compatibility gate uses
+R's writer to serialize its checked-in compatibility corpus and decodes those
+exact bytes with the oldest binary retained for rollback, the deployed N
+reader, and R's reader. The candidate corpus includes minimal, explicit-default,
+disabled-retention, and maximal non-default candidates for every integration
+and provider shape. A generated coverage assertion maps every serializable
+schema-2 leaf and variant in R to at least one candidate that emits it, so a new
+key cannot hide outside a “representative” fixture. Because schema 2 rejects
+unknown fields, a new non-default stored key cannot be emitted while that older
+binary is a rollback target. The release must omit the key, wait until the
+rollback generation closes, or introduce a new application schema with the
+full version/store cutover; merely retaining the numeric schema value does not
+make the change compatible.
+
+The gate is bidirectional. In addition to candidate-writer bytes passing old and
+new readers, R must decode the frozen exact bytes emitted by the deployed N
+writer for N's complete compatibility corpus and every exported live schema-2
+envelope in the release inventory. Normalized results must match N modulo only
+documented default changes. Removing or changing an N field, variant, sidecar,
+or wire representation therefore fails even when R no longer emits it.
+
+`trusted_server_schema`, `integration_order`, and `provider_order` are reserved
+storage fields. They are generated by serialization and rejected if supplied in
+operator TOML.
+
+The schema-2 sidecars are sufficient to derive the neutral flat provider
+sequence: iterate `integration_order`, then each present `provider_order`.
+Schema 1 instead supplies the independent sequence directly in global lexical
+local-ID order before local IDs are mapped to qualified internal keys. The
+neutral compiler never reconstructs legacy order by grouping providers under
+their owners.
+
+Object-shaped storage keeps secret paths such as
+`integrations.datadome.server_side_key_secret_name` valid. Core and integration
+secret metadata traverse that resolution view before ordered settings are
+constructed. Integration-owned inactive-secret preprocessing also receives the
+object-shaped integration entry by ID and removes inactive references; the
+shared resolver later writes active resolved values back to the same entry.
+Neither searches an `{ id, config }` sequence. End-to-end tests
+prove both active DataDome secret fields are presence-checked, resolved, and
+removed when inactive. Before storage, EdgeZero's static secret metadata still
+validates every reference actually present in source, including a reference
+retained under a disabled integration; runtime filtering prevents inactive
+value resolution, not source syntax or adapter validation.
+
+Provider tables do not contain secret-reference fields in this design because
+the locked EdgeZero secret metadata cannot address arbitrary map keys. Adding a
+provider secret requires a separate EdgeZero metadata prerequisite or a fixed,
+integration-owned non-map path; implementations may not add an unresolvable
+map-keyed secret ad hoc.
+
+The private Rust type names may differ, but the serialized order must be
+explicit and covered by compatibility tests across:
+
+```text
+trusted-server.toml
+  → typed CLI configuration
+  → hash-verified blob envelope
+  → config store
+  → runtime composition
+  → Settings, registry, JavaScript lists, configuration digest, and AuctionPlan
+```
+
+## Configuration Ownership and Validation
+
+Core retains global settings and auction-orchestration validation. Each
+integration owns the typed schema and validation for its full configuration,
+including its provider instances.
+
+`TrustedServerAppConfig` and the static definition catalog live in
+`trusted-server-integrations`. The catalog supplies integration parsing,
+validation, secret metadata, pre-resolution handling for conditionally active
+secrets, and capability construction to both runtime startup and the CLI. Core
+exposes its non-integration secret metadata through a neutral helper; the
+composition root combines it with catalog metadata. Core also retains its
+neutral/global inactive-secret preprocessor for Tinybird and EC partners; the
+composition root runs both core and catalog preprocessors before one shared
+resolution pass.
+
+For example, DataDome's inactive secret references are filtered by its
+definition before the shared secret resolver runs; core's config-payload code
+does not retain a DataDome-specific JSON path. Config-store loading, `config
+validate`, `config diff`, and `config push` use the same catalog resolution,
+schemas, and pure validation functions as the adapters. Only config-store
+loading proceeds through resolved-value validation and runtime capability
+composition.
+
+Source validation treats secret leaves as key/store references only. It does
+not call constructors such as DataDome `try_new` with an unresolved key name;
+format and semantic checks on the resolved secret value run only after runtime
+resolution. References retained under disabled integrations still receive the
+locked EdgeZero name, store, collision, and adapter checks described below.
+
+The DataDome move accounts for every current production coupling rather than
+only its response marker: direct HTML-processor state, publisher
+template/body/privacy decisions, startup and deploy validation, legacy settings
+cleanup, secret metadata and resolved-value validation, and inactive-secret
+preprocessing. Integration-owned code moves outward; the neutral processing
+requirements and object-shaped secret-resolution view replace the two places
+where core genuinely coordinates behavior.
+
+Validation fails for:
+
+- An unknown integration ID.
+- A parent integration table with a missing or non-boolean `enabled` field.
+- Integration configuration not accepted by its owner under the enabled or
+  disabled validation phase defined above.
+- A descendant integration or provider table declared before its explicit
+  parent.
+- Duplicate local provider IDs or duplicate qualified provider identities.
+- A bidder route to an unknown or incompatible provider.
+- A selected mediator whose integration is absent, unknown, or lacks the
+  mediator capability when enabled.
+- Duplicate routes or renderer types.
+- A referenced browser module absent from the generated browser catalog.
+- An unsupported capability combination.
+
+A disabled integration may retain provider configuration, but every retained
+child ID and reference is resolved and structurally validated before pruning;
+a typo or missing child fails even while disabled. Active-only semantic checks
+remain skipped. A globally disabled auction may likewise retain otherwise
+valid enabled integration and provider configuration so operators can prepare
+configuration before enabling the auction.
+
+References to an explicitly disabled known integration are retained in a
+validated suppression set and omitted from executable capabilities with one
+aggregated warning. A pruned bidder route produces the distinct diagnostic
+outcome `disabled_by_integration`, not `unroutable`, and its bidder stays
+suppressed from Prebid client-side fallback. A selected disabled mediator
+intentionally falls back to local ranking with a warning instead of the
+baseline startup error; this is an explicit behavior change. This makes
+`enabled = false` a one-line integration kill switch without making typos or
+absent definitions valid. The global auction switch remains the
+cross-integration emergency stop. The design does not add a second generic
+capability-specific enablement system; server-only Prebid remains an enabled
+parent without browser-activating fields.
+
+## Configuration Migration
+
+This is a deliberate operator-source migration. Ordinary config commands in the
+new CLI accept only the new inventory and never define precedence between old
+and new source fields. `ts config migrate` is the sole legacy-source entry
+point; it transforms one complete old source into a candidate and never treats
+that source as deployable input. The runtime temporarily supports two stored
+application schema versions only to make deployment safe; it normalizes exactly
+one complete stored shape and never merges inventories.
+
+Representative mappings are:
+
+| Previous configuration                                          | New configuration                                                                                     |
+| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
+| `[auction.providers.pbs-main]` with `profile = "prebid-server"` | `[integrations.prebid.auction.providers.pbs-main]`                                                    |
+| `[auction.providers.aps-main]` with `profile = "aps"`           | `[integrations.aps.auction.providers.aps-main]`                                                       |
+| APS provider with no `[integrations.aps]` parent                | Add `[integrations.aps]` with `enabled = true`                                                        |
+| Server-only Prebid provider with no Prebid browser block        | Add `[integrations.prebid]` with `enabled = true`; omit `external_bundle_url` and browser-only fields |
+| Existing browser Prebid block with `enabled = true`             | Retain its browser fields and nest any server providers beneath the same enabled parent               |
+| Any retained integration parent that relied on a default        | Add an explicit `enabled = true` or `enabled = false`                                                 |
+| A standard profile provider named `example-direct`              | `[integrations.openrtb.auction.providers.example-direct]`                                             |
+| `[auction.providers.<id>.profile_config]`                       | Flattened into the owning integration's provider table                                                |
+| `protocol = "openrtb-2.6"`                                      | Remove it; the registered provider capability fixes the protocol                                      |
+| Bidder route `provider = "pbs-main"`                            | `provider = "prebid.pbs-main"`                                                                        |
+
+Milestone 2 includes `ts config migrate [--dry-run] [--accept-reordering]` plus
+repeatable `--discard-unknown-integration <id>`. The command is a
+comment-preserving `toml_edit` transformation, never a push. It:
+
+- rejects mixed old/new inventories and operates on one complete legacy source;
+- detects every legacy integration table unknown to the static catalog before
+  transforming known parents. Dry-run reports each unknown table's ID and
+  source location, but never prints its values or an exact preservation block
+  to stdout or logs; the source file remains untouched, and the command exits 1.
+  A normal run refuses to write unless the operator explicitly names each ID
+  with repeatable `--discard-unknown-integration <id>`; the report records that
+  irreversible discard without printing values. Unknown data is never silently
+  dropped or emitted as an invalid active schema-2 table;
+- maps every profile to its owning integration, flattens `profile_config`, drops
+  the fixed protocol, qualifies cross-integration references, and creates each
+  required parent before its descendants;
+- first derives the complete legacy flat provider sequence in lexical local-ID
+  order. Provider-owning parents with active providers are promoted to a prefix
+  before `js_asset_proxy`, ordered by the first occurrence of one of their
+  providers in that sequence; each parent's provider tables retain their legacy
+  local order. If each owner's entries were contiguous, this exactly preserves
+  legacy priority. If owners were interleaved, grouping is unavoidable: the
+  report prints every old and new ordinal and every reordered pair, then asks
+  for confirmation before writing. Remaining parents follow the frozen legacy
+  hook sequence `prebid, aps, js_asset_proxy, testlight, nextjs, permutive,
+lockr, didomi, sourcepoint, osano, google_tag_manager, datadome, gpt,
+gpt_diagnostics, openrtb, adserver_mock`, excluding promoted entries and
+  filtering to configured entries. This does not preserve the previously
+  cosmetic order of legacy `[integrations.*]` tables or assume
+  `js_asset_proxy` was globally first. First-occurrence grouping is a
+  deterministic compatibility policy, not a claim to minimize pair
+  inversions. After selecting parent order, migration compares the frozen
+  schema-1 order with schema-2 order for every comparable capability phase,
+  including Rust hooks, immediate browser evaluation, DOM insertion, routes,
+  rewriters, head injection, and providers. The report prints each changed pair
+  and old/new ordinal even when provider order itself was preserved;
+- writes explicit `enabled` using a frozen table of the baseline defaults rather
+  than guessing one value for every integration; the baseline-true set is
+  Prebid, GPT, Didomi, Lockr, and Permutive, and retained blocks for other
+  integrations remain false unless legacy server activation requires an
+  enabled parent;
+- handles server-only Prebid and implicit APS activation explicitly, and warns
+  before enabling a retained disabled APS block whose `rendering_mode` would
+  change renderer-route behavior;
+- for a server-only Prebid migration, enables the parent and comments out every
+  present non-default browser-only field. Explicit current-default values such
+  as `debug`, `timeout_ms`, or an empty bidder set may remain because validation
+  treats them as inert and storage omits them. It always comments out a staged
+  `external_bundle_url`; the report says “browser Prebid stays off” and names
+  every edit. Inert `bundle.modules`,
+  `external_bundle_sha256`, and `external_bundle_sri` staging fields remain.
+  The emitted candidate must pass the normalized activation validation;
+- prints old-to-new environment-overlay variable paths. Migration warns and
+  maps stale names when possible; `--no-env` skips even the environment-name
+  scan and reports that it did so. Ordinary validate, diff, and push fail any
+  app-prefixed variable that still targets a retired path;
+- preserves file permissions and uses the existing permission-preserving atomic
+  writer. Immediately before its atomic replacement, it compares the current
+  file's exact bytes and file identity with the bytes and identity read for
+  migration. An edit, replacement, or disappearance observed while the operator
+  was reviewing the prompt aborts without writing and asks the operator to
+  rerun migration. This is optimistic conflict detection, not an atomic
+  compare-and-swap against unrelated editors: an external edit in the narrow
+  interval after the final comparison can still race with rename. The command
+  reports that limitation before an in-place write; accepting a prompt does
+  not waive the final comparison.
+
+An interactive write prints all old/new ordinals and reordered pairs and
+prompts unless `--accept-reordering` was supplied. That flag covers any changed
+comparable provider, hook, or browser phase caused by grouping or parent
+promotion, not only provider-pair changes. A non-interactive write refuses such
+a result without the flag. It does not waive unknown-integration discard, which
+requires the per-ID option above. Dry-run never prompts and never writes. It
+keeps the entire candidate in memory and emits only redacted IDs, locations,
+ordinals, and decisions, never source, transformed configuration, or overlay
+values. It exits 0 for a valid candidate needing no unaccepted decision, 1 when reorder
+acceptance, unknown-table disposition, or another reported manual edit is still
+required, and at least 2 for invalid input or tool failure. A whole-chain asset
+mismatch is one such manual edit: migration comments out the asset table and
+reports the exact decision instead of proposing an unreachable automatic
+reorder.
+
+For migrate, validate, diff, and push, `--no-env` skips both overlay values and
+the stale environment-name scan and reports that the scan was skipped. Without
+it, an app-prefixed variable targeting a retired path is a validation error.
+
+Missing-`enabled` diagnostics name the exact old default even when operators
+migrate by hand. An exact golden test migrates the shipped example and proves
+that its current-default Prebid browser values remain inert, non-default values
+and any staged URL stay commented, bundle staging metadata is preserved, and
+the result validates. A second golden covers a disabled Prebid block with a
+staged URL plus an active legacy Prebid Server provider. The shipped example,
+`config init`, audit drafts, operator guides, and environment-overlay examples
+contain a complete migrated shape.
+
+Old `[auction.providers]`, `profile`, `profile_config`, and `protocol` fields
+fail with an actionable message naming the new integration-owned location or
+instructing the operator to remove the fixed protocol. A mixed old/new operator
+configuration also fails. There is no deprecation interval for operator TOML.
+The temporary old-blob reader is not an accepted source format and does not
+make old fields valid in the new CLI.
+
+Examples, integration fixtures, environment-overlay tests, CLI documentation,
+and operator guides migrate in the same change.
+
+### Stored schema and rollout
+
+The EdgeZero `BlobEnvelope` version describes EdgeZero's envelope and canonical
+hash rules; it is not a Trusted Server application-schema version. Both old and
+new data therefore remain in envelope version 1. New data carries
+`trusted_server_schema = 2` inside `data`; absence of that field identifies the
+existing stored shape during the transition. Unknown application schema values
+fail before secret resolution.
+
+One shared legacy DTO-to-neutral converter serves both the milestone-one source
+normalizer and the schema-one stored-blob reader. It accepts exactly what the
+baseline typed loader plus runtime validation accepts: unknown integration IDs
+are ignored with a rate-limited warning, integration-specific omitted
+`enabled` fields retain their baseline defaults, implicit APS activation
+remains, and providers enter the independent flat sequence in global lexical
+local-ID order. New schema-2 strictness is never applied retroactively to an
+unchanged schema-one blob. The application-schema marker remains at the data
+root, and every rollback binary is proven to reject an unknown root marker.
+New CLI writes schema 2 only. `config push` resolves the selected adapter and
+deployment destination before any write and checks a schema-2 activation
+capability for that exact destination. Fastly requires the verified new
+service-version/store/root-key tuple described below. Cloudflare KV push is
+rejected because the Worker reads a version-bound binding, not that KV entry;
+schema 2 reaches Cloudflare only through the verified Worker-version binding
+cutover. Remote Spin push is rejected while its export/restore and versioned
+selection drill is blocked; the gate opens only for a deployment proven to
+select and restore the named versioned key/store atomically with its component.
+The gate cannot be bypassed by a generic force flag. Validate, diff, and local
+Axum migration remain available without a remote write. Tests assert that
+rejected pushes leave the selected store or binding unchanged.
+
+The CLI also stops delegating `ts config gc` without a rollout check. Fastly
+cutover tooling records the accepted active and rollback service-version,
+physical-store, and root-key tuples in an operator-controlled rollout record;
+each paired edit replaces that accepted pair only after both candidates are
+verified. During that pair's rollback window, `config gc` refuses either
+physical store before invoking EdgeZero's sweeping command. It also refuses
+when the record is missing, stale, or inconsistent with control-plane bindings
+for a schema-2-capable service; no generic force flag bypasses this check.
+After explicit rollback-window closure, GC may resume only after the control
+plane proves that no selectable active or rollback version references the
+protected roots. Tests prove rejected GC leaves both generations untouched.
+
+Rollout is adapter-specific:
+
+| Adapter    | Forward cutover                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | Rollback isolation and evidence                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Fastly     | The checked-in `ts config copy-store-generation` command resolves separate source and destination tuples: service ID, service version, service-scoped selector/store link, selected platform name, linked physical store ID, and selected root key. It rejects ambiguity, a selector/link mismatch, equal old/new physical IDs, or a root key not selected by that service version. It prints only those identities and natively wraps `fastly config-store-entry list --store-id ... --json` plus `update --store-id ... --key ... --upsert --stdin`; it never reserializes through `ts`. It copies referenced chunks first and pointer/root bytes last. Readback verifies the selected destination root key, pointer bytes, every chunk length/hash, pointer `envelope_len`/`envelope_sha256`, then reconstructed `BlobEnvelope.sha256` over canonical data. Production and staging resolve independently after PR #1175/EdgeZero #381. The schema-2 push and archived schema-1 writer must consume the verified destination tuple explicitly; a runtime root-key override never changes a push destination without its corresponding explicit key. Before push, the control plane proves the dual-reader version selects only the new tuple and the prior version only the old tuple. The activation observation and representative POP probes prove the same store/root-key tuple, expected schema, and a settings-dependent route. Missing/unpropagated root or chunk is `ConfigurationUnavailable`/503; hash mismatch is corruption, and partial decode is forbidden. | Rollback is only reactivation of the prior service version linked to the old schema-one tuple. Never redeploy an old release or bind it to the new store. Config GC is forbidden for either generation until the rollback window closes; control-plane linkage is necessary but POP-visible probes are the evidence. During the window, each accepted operator-semantic edit is translated and validated independently as schema 1 under frozen legacy semantics for the old generation and as schema 2 under new semantics for the new generation. An intent not representable in both is deferred or explicitly closes and reseeds the rollback generation before activation. |
+| Cloudflare | Create a new Worker version while preserving the outer `TRUSTED_SERVER_CONFIG` JSON binding shape. Its manifest-derived `trusted_server_config` property—or the legacy `app_config` fallback only when the primary property is absent or exactly the empty string—contains the string `BlobEnvelope`; application schema 2 lives inside that envelope's `data`. Whitespace-only strings and non-string primary values are malformed and never fall back. `ts config push` to KV is not treated as a runtime cutover. The primary/legacy/exact-empty-primary selection remains until a separately reviewed retirement.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | Worker rollback restores the previous code and schema-one binding together. Verify schema-one and schema-two envelopes through both accepted outer properties, the bound version, startup schema/digest log, and a settings-dependent route.                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| Spin       | Use a named versioned KV key/store only when the deployment platform can export, restore, and select it atomically with the component version.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              | The default remote Spin path is blocked from schema-2 rollout until a concrete control-plane export/restore drill exists; liveness alone is not evidence because the startup-error router stays healthy.                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| Axum       | Use the migrated local file/environment as a development-only cutover.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | Retain the archived schema-one file and restart the matching binary/config pair.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+
+The Cloudflare deployment producer is a checked-in
+`ts config export-binding --adapter cloudflare --output <protected-file>`
+command. It uses the same validated source, environment overlay, schema-two
+serializer, and canonical `BlobEnvelope` writer as `config push`, then writes
+the exact JSON value for `TRUSTED_SERVER_CONFIG` with the manifest-selected
+`trusted_server_config` outer property and the envelope as its string value.
+It emits no binding bytes to stdout or logs and uses a restrictive, atomic
+output file; a pre-existing output is not overwritten. The deployment control
+plane binds those exact bytes to a new Worker version, compares the bound
+version and envelope hash with the protected export, and requires a
+settings-dependent route plus authenticated schema/digest observation before
+activation. An unavailable version-bound readback or mismatch blocks cutover.
+The reader still accepts the existing `app_config` legacy and exact-empty-
+primary fallback; the new producer does not create new legacy-property writes.
+KV push alone never counts as a Cloudflare cutover.
+
+Before rollout, inventory and export the exact verified schema-one envelope
+from every live environment. Under the same secret-resolution context, the
+old and candidate readers compare normalized settings, activation, compiled
+plan, hook/browser/route and provider order, every `ExternalProviderLabel`,
+and error classification. A missing export or unexplained difference blocks
+dual-reader promotion. An archived production envelope remains an additional
+regression fixture.
+The common release order is: freeze writes; archive and verify schema one;
+deploy the dual-reader code against schema one; verify a settings-dependent
+route and explicitly enabled rollout observation reporting application schema,
+artifact ID, and non-secret composition digest; run
+`ts config migrate --dry-run`; cut over through the adapter-specific mechanism;
+then verify registry order, provider order, browser asset hashes, external
+provider IDs, and auction behavior. Fastly retains the freeze unless the
+version-bound paired-edit protocol below is available. Cloudflare retains the write freeze
+for its entire rollback window: if an operator-semantic edit is needed, the
+control plane creates and behavior-compares new schema-one and schema-two
+Worker versions with their respective bindings, verifies both, and only then
+activates the pair or explicitly ends the old rollback generation. It never
+rolls back to a binding older than the latest accepted edit. Blocked Spin
+remains frozen from schema-2 writes. Existing
+authenticated diagnostics may expose the same evidence, but no new public
+status route is introduced.
+
+For Fastly, the initial freeze remains the default throughout the rollback
+window. The table's paired-generation write policy is permitted only through
+fresh, immutable version-bound roots in separate old/new stores; it never
+updates either root selected by the currently accepted active/rollback pair in
+place. The archived legacy source and schema-one writer remain available solely
+for this runbook. For an operator-semantic edit, the control plane holds one
+edit/rollback lock, stages and verifies schema-one and schema-two roots, creates
+the matching old-reader rollback and dual-reader active service versions, and
+decodes and behavior-compares both candidates, including kill switches. It
+verifies each candidate's service-version/store/root-key linkage and
+representative POP-visible settings response and authenticated observation
+before allowing the new active version or its matched rollback version to be
+selected. If the platform cannot probe both candidates before selection, it
+keeps semantic writes frozen rather than claiming paired activation. For an
+edit, the newly verified old-reader version becomes the only permitted
+rollback target; the previously accepted rollback version is stale and cannot
+be selected. The control plane then selects only the matched new active version, waits for
+representative POP convergence, and marks the pair accepted together. During
+staging or partial propagation it prohibits rollback to either unverified or
+older-intent version; a failure leaves or restores the last accepted pair,
+reconciles any staged orphan, and keeps writes frozen until verification. No
+schema-one-only or schema-two-only edit is accepted. Comparison is modulo the documented schema
+differences: schema 1 retains local external labels and frozen lexical provider
+priority, while schema 2 uses qualified labels and configuration order. Shared
+intent such as enablement, provider membership, endpoints, timeouts, and
+admission policy must agree; each schema's expected identity and ordering are
+asserted separately. Ending the dual-write policy is the explicit end of that
+rollback generation, never an incidental result of an unrepresentable edit.
+
+Store/version isolation makes downgrade structurally safe where the platform
+supports it. Normal old CLI writers remain fenced; the explicit Fastly paired-
+generation runbook is the only authorized schema-one writer during its rollback
+window. That fence is defense in depth, not a credential guarantee or the only
+protection. The dual reader still accepts a schema-one write on the new
+generation but records one structured
+schema-regression/rollback event. Schema-one reappearance after cutover is an
+explicit rollback event. The compatibility reader is removed only in a later
+release after every production adapter, including Spin, has completed and
+drilled its rollback window; a blocked Spin cutover blocks reader cleanup.
+
+## Required Neutral Lifecycle Boundaries
+
+### Request processing and sharing annotations
+
+DataDome currently communicates a concrete request marker to core before
+template lookup. Core uses it to bypass a shared template, require an
+unconditional complete origin representation for HTML documents by stripping
+conditional and range headers, and make synthesized body-carrying HTML private.
+It does not select buffered body processing. Replacing it with either a late
+cache-only flag or a blanket buffering requirement would change behavior.
+
+Core therefore owns a small monotonic `RequestProcessingRequirements` value
+with three independent axes:
+
+- origin freshness and sharing: ordinary, bypass shared template/readthrough,
+  or require an unconditional full HTML representation;
+- response privacy scope: unchanged, synthesized body-carrying HTML only, or
+  every response;
+- fixed browser placement requirements, including a request-conditional
+  synchronous asset immediately after the unified tag.
+
+These requirements do not choose `Stream` versus `Buffered` routing and cannot
+turn a DataDome-suppressed document into a size-limited full-body buffer.
+
+Every hook may only make a requirement more restrictive. The registry combines
+requirements before template-cache, origin-readthrough, and origin-selection
+decisions, carries the result through HTML processing, and enforces privacy at
+the declared response scope. This is a
+processing contract, not a general policy, permission, or vendor-state system.
+
+Registry requirements are an additional monotonic veto, never an alternate
+cache authorization path. The request-side shared-template/readthrough gate
+remains the conjunction of the current method, request-cache, diagnostics,
+key-cookie, bypass-cookie, unlisted-cookie, cookie-independent-origin, and
+assembly-mode checks plus the registry requirement. It governs warm lookup
+and is retained for cold-store authorization. On a miss, origin-response
+status, headers, and cacheability additionally gate storage; after processing,
+the completed transformation, seam, and nonce requirements can veto storage
+again. Neither response-derived gate is retroactively applied to a warm lookup.
+A registry hook can make
+an otherwise shareable request private or origin-bound; it cannot make a
+request shareable when any existing cookie or cache gate rejected it.
+
+The verification matrix covers key-cookie, bypass-cookie, malformed, unlisted,
+absent, and empty cookie cases plus cookie-independent origins. Integration
+requirements may only restrict those existing decisions. DataDome request
+filtering and template-cache effects remain Fastly-only where they are
+Fastly-only on the baseline; this split does not invent equivalent adapter
+behavior.
+
+DataDome sets these requirements inside the request-filter hook at the point
+where it already decides client-tag suppression. Its tag-suppression detail
+remains opaque integration-owned request/document state. Core sees only the
+neutral requirements and an opaque token returned to later hooks; it has no
+DataDome type, field, or JSON path.
+
+### Request preparation and response finalization
+
+GPT diagnostics currently has direct preparation calls in adapters and core
+and a direct finalization call in core. Add neutral typed hooks for those two
+existing lifecycle points. The registry owns opaque request-scoped state
+between them. Separately, the static catalog exposes reserved-input normalizers
+for every compiled definition whether that integration is absent, disabled, or
+enabled.
+
+Prerequisite #1098 makes core's neutral Cookie path byte-oriented and lenient
+per field and semicolon-delimited pair. It preserves valid visible-ASCII
+name/value pairs in their original order, drops only malformed or non-ASCII
+pairs, applies the existing merge rules to the survivors, and emits aggregated
+counts and reason codes without logging values. One malformed pair never turns
+the request into HTTP 400 or discards valid pairs from the same or another
+field. Every adapter path, including Fastly admin EC/EID routes, and direct core
+tests use this neutral helper.
+
+After neutral sanitation, the GPT-diagnostics reserved-input normalizer
+captures console activation from the exact `ts_console` query and
+`__Host-ts-console` cookie names into `ReservedInputState`, removes only those
+reserved inputs, and merges retained fields. The integrations composition
+boundary runs catalog normalization before EC setup, template-key construction,
+origin forwarding, or generic classification. This static normalization
+contract is not an enabled runtime capability, so an absent or disabled
+GPT-diagnostics block cannot leak reserved inputs upstream. Core never calls
+the concrete catalog, and its tests use neutral Cookie fixtures rather than an
+integrations-owned wrapper.
+
+Preparation returns the opaque per-integration decision plus its declared
+`RequestProcessingRequirements`. The neutral requirements are available before
+the existing template-cache/private decision; under ESI, request-private opaque
+state is never copied into a shared template. Registry preparation remains at
+the integrations-owned wrapper; request extensions make a repeated neutral
+preparation a no-op where an adapter boundary can be re-entered. Core invokes
+finalization on the existing response path. GPT diagnostics may request the
+fixed synchronous post-unified asset phase
+and all-response privacy; an active diagnostics request also sets origin
+freshness/sharing to bypass both shared templates and origin readthrough before
+the early reader-origin decision whenever the decision requires private/no-store,
+including activation, cookie clearing, and malformed or duplicate directive
+cleanup. The veto is independent of the response privacy axis and retains
+#1169's origin-shareability telemetry. Ordinary head
+injectors cannot approximate that position. The current auction-correlation decision is deployment-scoped, not
+request-activation-scoped, and becomes a neutral enabled-capability query so
+SPA and non-navigation auctions retain correlation without a concrete GPT
+import.
+
+## Browser Composition and APS Renderer
+
+`trusted-server-js` builds only the neutral core IIFE and owns the
+bootstrap-safe first-impression source entry point declared as a GPT build
+input; it does not emit a second standalone bootstrap tag. Before extraction, the
+implementation audits every production value import from an integration or the
+fixed `creative` prelude into today's `core/` and `shared/` trees. Each import
+is classified rather than copied blindly:
+
+- Stateful facilities use one versioned `TrustedServerBrowserRuntime` facade.
+  Browser core owns its API and adoption rules, while bootstrap code that must
+  run before the unified bundle may create the backing `window.tsjs` object and
+  selected state first. The initial surface
+  includes logging, context-provider registration and context collection,
+  auction request construction and normalized response parsing, queue
+  installation, slot lookup and rendering helpers, an opaque first-impression
+  service, DOM insertion-handler registration, and renderer
+  registration/dispatch/lifecycle operations.
+- Pure stateless helpers may move to an integration-owned shared source module
+  and be bundled into the consuming IIFE. They must not close over or initialize
+  browser-core state.
+- Types are imported from declaration-only entry points. There are no runtime
+  relative imports across the two crate source roots.
+
+The first-impression service owns the physical-element/generation claim map and
+all transitions. Its facade methods cover element resolution and read-only
+ownership/admission lookup;
+Trusted Server claim and pre-request release; publisher auction registration,
+pending-delivery transition, delivery consumption, and release; GPT request and
+render observation; one fallback reservation; retry delay; the lease duration;
+and navigation-generation advance with claim retirement. GPT stores a
+Trusted-Server targeting snapshot through a claim handle; Prebid presents the
+generation token captured when its callback was scheduled, plus an auction
+handle when one exists, and asks the service for a restore decision
+and snapshot only while the same physical element/generation has a
+Trusted-Server claim awaiting render. A by-element-only lookup cannot authorize
+a late callback from an older navigation. Neither caller
+reads or mutates claim owner, phase, or targeting fields. GPT may retain its
+separate navigation scheduler counter, but it advances the service generation
+and retires old claims before new-page admissions; a late old-generation
+Prebid callback cannot restore targeting or deliver. The service returns
+opaque claim/auction handles or admission decisions, not mutable
+`FirstImpressionState` or `FirstImpressionSlotClaim` objects. GPT and Prebid
+call this one service. The contract retains #1191's
+exact-element/generation binding, bounded overlapping publisher auctions,
+retained suppression/denial tokens, pending-render diagnostic without a timer
+unlock, and one fallback reservation after an abandoned publisher lease.
+Behavioral browser tests cover every transition, targeting restoration before
+render but not after render, SPA retirement, and a late overlapping callback
+after fallback or navigation. No integration duplicates the claim algorithm.
+
+Runtime calls use a stateless accessor mapped by the integration build to the
+already-installed namespace. Facade version 1 is exact, not a compatible range.
+Each post-core integration IIFE has a generated outer guard that reads the installed
+facade's version and ABI hash before executing any module initializer, global
+assignment, listener, timer, DOM operation, or inner IIFE body. A mismatch logs
+one diagnostic and returns from the outer IIFE, leaving all installed/shim flags
+unset and no integration side effects; this includes Prebid's current
+module-scope `window.pbjs` initialization. Install callbacks and later event
+callbacks resolve `getRuntimeV1()` again when they run rather than retaining an
+eager imported runtime object. The integration build fails on any undeclared
+cross-root value import. This covers current imports such as Permutive context
+registration, Prebid auction helpers, Testlight queue installation, GPT slot
+resolution, and the shared script/beacon guards; it is not limited to the APS
+renderer examples.
+
+A published facade version is immutable. One checked-in, versioned facade IDL
+is the authority for every public value-level member and every named type
+reachable from its arguments, results, callbacks, or adoption markers. It
+generates the TypeScript declaration consumed by both browser crates and the
+ABI record set; the implementation typechecks against that declaration, and an
+artifact gate enumerates actual public value members so undeclared extras fail.
+The canonical type grammar admits explicit primitive/literal types, ordered
+tuples, arrays, records and objects with UTF-8-sorted field names and explicit
+optional/nullable flags, unions sorted by their canonical member encoding,
+callback and Promise signatures, named opaque handles, and named live DOM
+references such as `HTMLElement`.
+Overloads are distinct records with explicit ordinal and parameter order;
+aliases expand through the reachable named-type graph with cycle references by
+stable name. Unsupported TypeScript constructs fail generation instead of
+being stringified ad hoc. Records cover namespace members, the opaque
+first-impression operations, and adoption markers; only types unreachable from
+the facade may change without a new version. Records use a fixed kind byte plus
+the same
+`U32_BE(UTF8_LEN) || UTF8` framing for member path and canonical signature, are
+sorted by kind and path, and hash as
+`SHA-256("ts-browser-runtime-abi-records-v1\0" || U32_BE(count) || records)`.
+The `records-v1` suffix versions the manifest encoding independently of the
+facade accessor number. A change in any reachable type or value member changes
+the record bytes even when JavaScript erases that type at runtime.
+
+Each released numeric accessor has checked-in exact record bytes and a derived
+hash under a versioned ABI snapshot directory. A merge-base-aware CI guard
+rejects modification or deletion of any snapshot/version entry already marked
+published on the target branch; a changed surface must add a new numeric
+accessor and new snapshot. Updating an editable hash beside a changed manifest
+cannot pass. The build regenerates the current records, compares them byte for
+byte with the declared version's snapshot, recomputes the hash instead of
+trusting stored text, and embeds the version/hash pair in browser core and every
+integration artifact. Runtime rejects a stale same-version/different-hash asset
+exactly as it rejects a numeric mismatch.
+
+The pre-core GPT bootstrap is the deliberate exception to the post-core guard:
+it cannot read a facade that has not yet been installed. It stamps its neutral
+first-impression service with the expected facade version and ABI hash before
+installing listeners. Core checks that marker before adoption; on mismatch it
+does not create a competing service or reinterpret pre-core claims. It marks
+the service unavailable and makes new-core, immediate-GPT, and deferred-Prebid
+admissions fail closed with a diagnostic. Bootstrap callbacks or listeners
+already installed by the mismatched artifact may continue; this is not a
+document-wide fail-closed guarantee. The GPT bootstrap still runs before the unified bundle and creates or adopts
+`window.tsjs`. The neutral browser crate owns a bootstrap-safe
+first-impression service fragment generated from the same service source and
+facade ABI as core. The integration build places that fragment before GPT's
+listener code in the existing synchronous bootstrap tag; this is the one
+declared cross-root build import, not a runtime import or a second script tag. GPT
+bootstrap installs the service once, and its pre-core lifecycle listeners call
+that service rather than closing over a separate claim implementation. Core
+adopts the exact compatible service instance and `window.tsjs` identity,
+preserves pre-bundle claims and listener markers, validates the runtime-facade
+version, and initializes only missing registries. An unmarked pre-upgrade
+bootstrap may already have queued callbacks or listeners closing over its own
+claim algorithm. Core therefore preserves the `window.tsjs` object for
+unrelated APIs, marks the neutral first-impression service unavailable, and
+makes new-core, immediate-GPT, and deferred-Prebid admissions fail closed
+instead of attempting to migrate those live closures or install a second claim
+engine. Already-installed legacy callbacks may still run; this mixed-artifact
+document is diagnosed and is not claimed to have safe first-impression
+ownership. GPT may intentionally replace legacy
+`adInit`/`scheduleInitialAdInit` functions as the facade is installed; object and
+first-impression state identity are preserved, not function identity. Immediate
+GPT and deferred Prebid likewise adopt the facade and keep listener installation
+idempotent. A Prebid installation marker includes the facade version and ABI
+hash; an earlier unversioned or mismatched shim marker is diagnosed and cannot
+count as a current installation. Its prior side effects cannot be undone, so
+the new shim fails closed without double-installing patches or setting a current
+marker. Integration bundles consume the facade through an external runtime shim and
+type-only browser-core declarations; their bundler must not inline the stateful
+registry implementation. Artifact tests load bootstrap, core, immediate GPT,
+synchronous GPT diagnostics, the neutral finalizer, and deferred Prebid in
+production order and prove that first-impression claims, Permutive context,
+logging configuration, renderer registrations, and APS frame supersession use
+the same shared state.
+
+Prerequisite #1196 removes or debug-gates Creative's unconditional log-level
+bump before extraction. The default remains `warn`, and an explicit publisher
+`warn` setting is never overwritten; a production-artifact test pins both.
+Restoring shared context makes Permutive context visible to core collection,
+which is an intentional bug fix with a consent caveat: server-side
+`allowed_context_keys` remains only a key allowlist, not a browser consent gate.
+This extraction adds no new browser consent check and does not redesign consent
+policy.
+
+Browser core installs `tsjs.que` in buffering mode and immediately arms one
+idempotent microtask failure fallback. Composition appends a marker after the
+complete sequence of immediate integration IIFEs in the unified asset. When
+reached, that marker says unified evaluation completed, so the earlier microtask
+becomes a no-op. Composition emits a dedicated neutral, same-origin external
+classic-script finalizer after the unified immediate asset and every fixed
+synchronous post-unified asset, including GPT diagnostics when active. It uses
+the same trusted tag-attribute and CSP authorization path as the unified asset,
+has neither `async` nor `defer`, and is served by the existing static-asset
+handler at `/static/tsjs=tsjs-finalizer.min.js?v=<content-hash>` from bytes
+embedded by the neutral browser crate. This is a reserved fixed browser asset,
+not an integration module ID; stale query hashes follow the existing static
+route's non-immutable current-byte behavior. Its exact bytes/hash
+enter `BrowserDocumentAssets` and the document fingerprint as a fixed external
+asset. The finalizer invokes the same drain when evaluation reaches it, after
+Permutive, all other immediate registrations,
+and diagnostics setup are complete. It is not concatenated into the unified
+bundle. The drain executes opaque callbacks FIFO, including calls forwarded by
+Testlight or pushed while draining, isolates a throwing callback so later
+entries still run, and only then changes `push` to execute immediately. If an
+immediate IIFE throws before the completion marker, the microtask drains after
+that classic script unwinds. If unified evaluation succeeds but diagnostics
+throws, the later finalizer still runs. If document injection aborts before the
+finalizer, the queue remains buffered and fails closed rather than draining
+before required synchronous setup.
+
+Deferring every preloaded callback until synchronous setup finishes is an
+explicit milestone-one browser behavior change, not a claim that only
+`requestAds()` is delayed. Production artifact tests cover a preloaded call
+with GPT diagnostics active, a Testlight-forwarded call, a callback that
+enqueues another callback, throwing unified and diagnostics IIFEs, and the
+microtask fallback. For one deprecation window, the facade also backs the
+compatibility alias `window.tsjs.apsPrebidRenderers` used by bundles predating
+#967.
+
+Every integration IIFE declares the facade version it requires. A mismatched
+deferred or stale asset fails closed for that integration with a diagnostic
+rather than creating a second registry or mutating an incompatible shape. This
+is the runtime version-skew contract for static routes that historically serve
+current bytes even when a stale `?v=` value is requested.
+
+`trusted-server-integrations-js` builds integration IIFEs. Immediate modules
+are concatenated in the ordering contract above. Deferred and standalone
+modules remain separate assets but retain their configuration-relative order
+and typed identities.
+
+The browser DOM-insertion dispatcher follows the same ordering rule as Rust
+hooks. Its current numeric priority and ID-lexical sort are removed. Immediate
+IIFEs evaluate in configured concatenation order, so their registration
+sequence already is the configured sequence; no separate ordinal mapping or
+inline mapping script is emitted. A handler registers under its owning
+integration ID and executes by registration sequence, then by that
+integration's local registration sequence. Handler IDs remain diagnostic
+identities only, and DOM-insertion handlers are immediate-only so an absent
+deferred handler cannot observe mutations too late. Built-in guards must have
+disjoint parsed URL ownership as specified above; configuration order is not a
+repair mechanism for overlapping substring matchers.
+
+The Rust registration does not carry only a string module ID. Core owns an
+immutable `CompiledBrowserAsset` containing the typed module ID, embedded bytes,
+SHA-256 hash, and load mode. Composition binds configuration-dependent trusted
+script-tag attributes separately and produces a `BrowserDocumentAssets` value
+containing:
+
+- the exact ordered byte parts and concatenated hash for the unified asset;
+- the ordered deferred and permitted standalone assets with their bytes and
+  hashes;
+- the fixed creative prelude and neutral external queue-finalizer bytes and hash;
+- the configured managed-external Prebid bundle tag, including its emitted
+  source URL and every effective attribute, even when its remote bytes have no
+  configured hash;
+- a deterministic document fingerprint covering injected asset IDs, hashes,
+  order, attributes, and the exact static or configuration-rendered inline
+  bytes.
+
+The document fingerprint has one canonical byte encoding:
+
+```text
+bytes(value) = U64_BE(BYTE_LEN(value)) || value
+text(value)  = bytes(UTF8(value))
+attribute    = text(ASCII_LOWER(name)) || text(value)
+attributes   = U32_BE(count) || SORT_BY_NORMALIZED_NAME(attribute records)
+external     = U8(kind) || U32_BE(emission_ordinal) || text(asset_id)
+             || attributes || U8(0) || raw_sha256_32
+inline       = U8(kind) || U32_BE(emission_ordinal) || text(asset_id)
+             || attributes || U8(1) || bytes(exact_inline_bytes)
+managed_external = U8(6) || U32_BE(emission_ordinal) || text(asset_id)
+             || attributes || U8(2) || U8(has_configured_sha256)
+             || (raw_sha256_32 if has_configured_sha256 else empty)
+document_fingerprint = SHA-256(
+  UTF8("ts-browser-document-v1\0") || U32_BE(asset_count)
+  || external/inline/managed_external records in emission order
+)
+```
+
+`kind` is `1` for unified, `2` for deferred, `3` for standalone, `4` for
+inline, `5` for the neutral external finalizer, and `6` for a managed-external
+script whose bytes are fetched rather than embedded; `0` is reserved. Ordinals
+are zero-based positions in actual document
+emission order; records are never sorted. The trusted attribute-name constructor
+accepts ASCII HTML attribute names only. Names are ASCII-lowercased for encoding,
+and duplicate normalized names are rejected before hashing except equal
+duplicates collapsed as described below. External payloads use the raw
+validated 32-byte content hash; inline payloads include the exact bytes. The
+managed-external record includes the exact emitted `src`, `defer`, `integrity`,
+`crossorigin`, and any other effective tag attributes in `attributes`; its
+optional configured SHA-256 has an explicit presence bit. Without that SHA,
+the fingerprint identifies the emitted tag and configuration, not the remote
+response bytes. Counts
+and lengths make empty values and field boundaries unambiguous. The lowercase
+hexadecimal representation is display only; composition embeds the raw 32-byte
+digest.
+
+Trusted attributes from immediate assets are merged onto the unified script
+tag through validated name/value constructors. Invalid names or values and
+duplicate names with different values fail release-mode composition; equal
+duplicates collapse to one attribute. None of these checks is only a debug
+assertion.
+
+Static serving, cache-busting URLs, and immutable-cache validation consume
+`BrowserDocumentAssets`; core no longer performs a crate-global
+`all_module_ids()` lookup. Its document fingerprint includes only assets that
+can affect the composed document and includes GPT bootstrap bytes. Each head
+injector whose generated inline output varies with integration configuration
+supplies the exact immutable bytes for that output. The verified EdgeZero
+envelope hash already covers configuration, so injectors do not invent
+additional configuration fingerprints. Request-dependent head variation is
+permitted only when its neutral
+`RequestProcessingRequirements` bypass shared-template reuse; request data is
+never folded into a composition-wide fingerprint.
+
+Publisher template invalidation is broader than the browser document, but it
+does not invent another canonical serializer or hash resolved secret values.
+The composition digest is:
+
+```text
+SHA-256(
+  UTF8("ts-composition-v1\0") ||
+  HEX_DECODE_32(verified_envelope.sha256) ||
+  BrowserDocumentAssets.document_fingerprint_raw_32 ||
+  U32_BE(application_schema) ||
+  U32_BE(LEN_UTF8(build_id)) || UTF8(build_id)
+)
+```
+
+The two digests are raw 32-byte values inside this framing; the EdgeZero digest
+is decoded from its validated canonical 64-character lowercase hexadecimal
+representation. `application_schema` is an unsigned 32-bit integer. `build_id`
+is UTF-8 with a four-byte big-endian byte-length prefix. These fixed widths and
+the one explicit length prefix make the input unambiguous; implementations do
+not hash the displayed formula, hexadecimal text, or delimiter-free strings.
+
+`BlobEnvelope.sha256` is EdgeZero's already-verified canonical hash of stored data
+before secret resolution. It covers schema 2 order sidecars, enabled and
+disabled source, neutral settings, overlay results, and secret references
+without exposing secret values. Raw resolved secrets never enter a template
+key. If a future resolved secret changes document bytes rather than only
+authorizing an upstream call, its owner must contribute a reviewed non-secret
+behavior fingerprint or make the output request-private; it may not hash the
+secret itself. Semantically set-valued fields serialize in deterministic order
+before EdgeZero hashes them. When `trusted_server_schema` is absent, the
+application schema contribution is exactly `1`.
+
+`build_id` is an artifact-specific deterministic digest of build-time inputs. Prerequisite
+#1198 adds the canonical generator in core build support, initially invoked from
+`trusted-server-core/build.rs`; extraction reuses that implementation from each
+output-affecting crate/build context rather than cloning its rules. Each context
+emits a labeled component digest from its authoritative source and environment,
+and the final adapter supplies a deployed-artifact ID composed from those
+component digests:
+
+```text
+record(label, value) = U32_BE(UTF8_LEN(label)) || UTF8(label)
+                     || U64_BE(BYTE_LEN(value)) || value
+component_id = SHA-256("ts-build-component-v1\0" || SORT_BY_LABEL(records))
+build_id     = LOWER_HEX(SHA-256(
+  "ts-build-v1\0" || SORT_BY_LABEL(component-id records)
+))
+```
+
+Each component-ID record has a unique stable component label and the raw
+32-byte component digest as its value. Traversal deduplicates an identical
+label/digest pair reached through two dependencies; a label with differing
+digests fails composition.
+
+File labels are normalized workspace-relative UTF-8 paths. The deployed
+component set is every runtime workspace crate reachable from the selected
+adapter, including that `trusted-server-adapter-*` crate,
+`trusted-server-integrations`, `trusted-server-core`,
+`trusted-server-openrtb`, and both browser embedding crates where reachable.
+External registry/git dependency source is represented by `Cargo.lock`; local
+workspace dependency source receives its own component. Each output-affecting
+workspace crate's build script invokes the canonical generator in its own build
+context and emits a public raw 32-byte component constant plus its stable label.
+Core build support emits the root-workspace component. Each runtime workspace
+crate exposes a small component-record traversal that includes its own record
+and forwards its direct runtime workspace dependencies' records. The adapter
+combines those records once after static linking, deduplicates identical
+transitive records, and supplies the resulting ID to composition and template
+keys. This is a deterministic ID of compiled build-time digests, even though
+the final hash is assembled at startup. No adapter build script tries to read a
+dependency's `$OUT_DIR` or infer that dependency's Cargo feature environment.
+A target-matched `cargo metadata` gate compares the adapter's resolved runtime
+workspace dependency graph with the labels actually assembled; a missing,
+extra, or conflicting record fails. Adapters do not reuse a core-only constant
+as the deployed artifact ID.
+
+Each component inventory covers its Rust source, build script, manifest,
+embedded source assets/templates, and every file declared by that build script
+as output-affecting. One labeled workspace component covers root `Cargo.toml`,
+`Cargo.lock`, `edgezero.toml`, pinned toolchain/version files, and the canonical
+`package.json`/`package-lock.json`; those inputs are not copied into every crate
+component. The generator and each build script derive hash inputs and matching
+`rerun-if-changed`/`rerun-if-env-changed` directives from the same checked-in
+inventory helper; adding an output-affecting `rerun-if-changed` input without
+hashing it fails a gate. Each crate's own build context records `TARGET`,
+`HOST`, `PROFILE`, `OPT_LEVEL`, `DEBUG`, and sorted relevant `CARGO_CFG_*` and
+`CARGO_FEATURE_*` values; no crate infers another crate's effective features.
+It also records the actual `RUSTC` compiler identity (`rustc -vV` plus binary
+identity), effective `CARGO_ENCODED_RUSTFLAGS` including target features and
+codegen flags, and any effective profile or target-specific override not
+already represented by the recorded values. Release builds with a nonempty
+`RUSTC_WRAPPER` or `RUSTC_WORKSPACE_WRAPPER` must fingerprint the wrapper
+executable and version as an explicit component input or fail; unknown
+output-affecting compiler inputs fail closed. The checked-in toolchain file
+alone is not a substitute for the compiler and invocation actually used.
+`.git`, `node_modules`, `dist`, `target`, every Cargo `$OUT_DIR`, and generated
+manifests/digests are excluded. Exact built browser bytes remain covered by
+`BrowserDocumentAssets`, so generated artifacts do not enter this source digest
+recursively.
+
+Checked-in `.gitattributes` enforces LF for hashed text and `-text` for binary
+inputs; CI rejects CRLF in the hashed text inventory. Build-ID output is
+canonical lowercase hexadecimal. Target, profile, optimization, debug, or
+effective-feature changes may intentionally produce different IDs for different
+adapter artifacts; rollout records the expected ID per deployed artifact rather
+than expecting one workspace-wide value. Any ID change forces a cold template
+namespace.
+
+The composition digest is computed lazily and memoized so non-document routes
+and ineligible template-cache requests pay no repeated full-config hash cost.
+Normal request execution never forces it merely for logging. An adapter that
+retains compositions may keep a process-local `CompositionObservationCache`,
+keyed only by application schema, envelope hash, and build ID, with at most 32
+LRU entries; this is an opportunistic deduplicator, not a global once guarantee.
+During rollout, the control plane supplies an adapter-specific, version-scoped
+`RolloutObservationKey` and a bounded expiry outside operator TOML. For each
+settings-dependent probe it sends a fresh 128-bit hexadecimal probe ID and
+`HMAC-SHA256(key, probe_id)` in a dedicated observation request header. The
+adapter validates the tag in constant time, consumes the header before any
+origin forwarding or cache-key construction, and only then forces and emits
+the observation without sampling or instance-level deduplication. An absent,
+expired, or invalid tag does not trigger observation; the header is still
+stripped. The event includes the non-secret probe ID, adapter/version, platform
+location, selected outer binding property where applicable, verified envelope
+SHA-256, application schema, build ID, composition digest, ordered active
+integration IDs, and ordered browser asset IDs/hashes; Fastly also records the
+resolved platform store and root key. It contains no key, tag, config bytes, or
+secret values. For every generation/version, the control plane preselects a
+settings-dependent request and expected response predicate derived from that
+generation's intended configuration. When old and new configurations are
+deliberately behavior-equivalent, the authenticated version/binding/envelope
+evidence distinguishes them; the HTTP response need not differ artificially.
+For a paired semantic edit, the predicate must exercise the edited behavior.
+The gate matches each unique probe ID and location to
+both the expected HTTP response and at least one expected
+binding/envelope/artifact/schema/digest event from that request, rejects
+conflicting responses or events, and fails if any representative probe/POP has
+none. A generic 2xx or `/health` is never sufficient. The rollback version is
+probed before it is declared usable. A platform unable to supply a version-scoped key and
+expiry cannot activate schema 2 until an equivalent private control exists.
+Outside authenticated rollout probes, optional debug or sampled observations
+may reuse the event schema, but ordinary requests do not force the digest. A
+fresh instance may emit again for a new probe; the opportunistic
+`CompositionObservationCache` applies only outside this mode. Runtime provider-order
+evidence comes from existing ordered `/auction`
+`ext.orchestrator.provider_details`. This makes rollout verification executable
+without a new endpoint. The composition digest remains distinct from the exact
+concatenated unified-bundle hash, whose byte-content semantics are unchanged.
+
+Core uses that configuration digest directly as the template fingerprint's
+configuration-and-document contribution; it does not append
+`BrowserDocumentAssets.document_fingerprint` a second time because the digest
+already covers it. This replaces only the old complete-`Settings` plus
+global-bundle digest; it does not replace any other `TemplateCacheKey`
+dimension. Full URL, request host and scheme, origin identity, assembly mode,
+ordered `Vary` values, selected cookie values, and `TEMPLATE_SCHEMA_VERSION`
+remain independent key inputs. `TEMPLATE_SCHEMA_VERSION` changes only when the
+cache-entry serialization or interpretation format changes; transform/output
+code changes are already covered by `build_id`. Tests prove neutral settings, non-head integration
+rewriter settings, external and inline assets, and cookie policy changes
+invalidate templates without exposing raw configuration.
+
+Browser core currently imports APS renderer logic directly. Replace that
+reverse dependency with one neutral renderer registration mechanism. A
+renderer-type handler owns descriptor validation, render dispatch, any
+renderer-specific bounded capability state, and the renderer metadata needed
+to construct a Prebid Universal Creative response. Browser core owns only the
+type-keyed handler registry and neutral calls into it:
+
+- Core parses the existing renderer envelope far enough to identify its type
+  and retain its opaque payload.
+- The APS IIFE registers the one APS handler. GPT and Prebid call the neutral
+  registry and never import APS source; no APS source or private APS state is
+  inlined into core, GPT, or Prebid.
+- APS descriptor validity remains the current handler-owned contract: exact
+  required keys, successful encoded-payload decoding and parsing, descriptor/
+  bid identity equality, and current price constraints. Core does not weaken or
+  reproduce those checks.
+- Prebid validates a descriptor before bid admission, carries it only until
+  Prebid assigns an `adId`, and scrubs the carrier from both the normalized bid
+  and metadata. On `bidAccepted`, with the current `bidResponse` fallback, it
+  registers a bounded-TTL capability containing the `adId`, ad-unit binding,
+  validated descriptor, and `markWinningBidAsUsed` callback. Registration
+  failure demotes the bid to the current negative-CPM failure state.
+- GPT authenticates the requesting iframe against the expected slot or ad unit
+  before it consumes a capability. Consumption is compare-and-consume atomic,
+  source-bound, TTL-bounded, and replay-safe. Only the selected renderer handler
+  supplies its renderer source, version, URL, payload, and dimensions for the
+  Universal Creative response; GPT does not know APS constants.
+- Server-originated renderer descriptors use the same registered validation and
+  dispatch handler while retaining the current slot-scoped replay protection.
+  The Prebid `adId` path and server-bid path remain distinct neutral entry
+  points so one cannot consume the other's authority accidentally.
+- The direct `/auction` renderer-bid path in browser core also dispatches
+  through this registry; it is not a third APS-aware implementation. Its
+  neutral handler receives the validated `impid` targeting/slot binding and the
+  handler's own validated descriptor, not bid-normalized generic creative
+  metadata. The APS handler applies its existing exact descriptor validation
+  and owns renderer dimensions, creative ID, source, version, URL, and payload.
+  Separately, the generic-`adm` path preserves its current bid/default dimension
+  and creative-ID fallback rules. A malformed renderer descriptor is treated as
+  absent and an otherwise valid `adm` follows that generic path. Only after the
+  handler validates a descriptor and renderer dispatch is selected does a
+  missing or rejecting handler suppress the bid without generic fallback.
+  Provider admission/drop classification remains unchanged and failures expose
+  stable neutral reason codes.
+  Renderer failure reasons cross the neutral boundary as stable reason codes
+  for the GPT bridge without adding an APS enum to core.
+
+An enabled APS integration whose provider can emit APS renderer descriptors
+includes its immediate APS browser module. The synchronous unified script
+evaluates core, the fixed creative prelude, and all immediate integration IIFEs
+before the separate post-synchronous-assets finalizer drains queued auction
+calls; no renderer dispatch runs as an IIFE top-level side effect. On successful
+evaluation APS registration and GPT-diagnostics setup are therefore complete
+before a queued or later page call can render a descriptor; if an earlier IIFE
+aborts evaluation, the microtask failure drain observes no APS handler and
+renderer-bearing bids fail closed.
+APS module activation is explicit in the activation matrix above. APS renderer
+registration is an immediate-only capability; composition rejects
+a deferred APS renderer. Its current rendering mode continues to be read while
+the synchronous unified script tag is executing, and the APS-owned trusted
+attribute remains on that tag. A future switch to a standalone or deferred APS
+asset requires replacing `document.currentScript` configuration first.
+
+GPT is also immediate. Its current GPT module reads `document.currentScript`
+during module evaluation, so `data-ts-gam-attribution` remains on the unified
+synchronous tag and an artifact-level test proves the value is available at
+evaluation time. Moving source ownership must not silently make GPT deferred or
+move that attribute to a later tag.
+
+Renderer failure is scoped to the owning valid renderer-bearing bid or message.
+A missing or rejecting renderer suppresses that bid with no generic-creative
+or native-Prebid fallback; malformed direct-auction descriptors retain the
+ordinary `adm` behavior above, and unrelated bids and the page continue. A duplicate type
+fails Rust composition, while a defensive browser-side duplicate poisons that
+type rather than using last-registration-wins. No renderer route, DOM, message,
+response, or beacon side effect is newly created before the selected handler
+accepts the payload. This rule does not remove the baseline APS supersession
+bookkeeping or GPT's fail-closed event propagation, which may occur while
+deciding whether a payload is admissible.
+Carrier scrubbing, failed admission, bounded capacity and TTL, source binding,
+atomic consumption, replay rejection, and `markWinningBidAsUsed` are part of
+the compatibility contract rather than APS-private implementation details that
+may disappear during extraction.
+
+The serialized descriptor, validation, sandbox flags, message authentication,
+timeouts, and render results do not change.
+
+The production `APS_RENDERER_DOCUMENT`, including its inline browser
+JavaScript, moves from the APS Rust source into
+`trusted-server-integrations-js/lib/src/integrations/aps/renderer-document.html`.
+The browser crate exports its immutable bytes and hash; APS Rust serves those
+exact bytes with the existing content type, CSP, and other response headers.
+The document's nonce binding, sandbox, message authentication, runner load, and
+failure tests move with the asset. No production APS renderer program remains
+as a Rust string literal.
+
+`gpt_bootstrap.js` moves with GPT into `trusted-server-integrations-js` and is
+exported as a hashed integration-owned inline asset. GPT's Rust head injector
+consumes that exported asset; core never embeds it directly. Tests resolve the
+asset through the owning package instead of a cross-crate relative path. APS
+golden renderer fixtures likewise move to an integration-owned shared fixture
+location used by both Rust and browser tests.
+
+The move includes a repository-wide inventory of production executable browser
+programs assembled by integration Rust, not only files that already end in
+`.js`. The current DataDome, Didomi, GPT, Prebid, and Sourcepoint config
+initializers, Sourcepoint `_sp_` property trap, and GPT-diagnostics
+activation/history bootstrap move with their owners. Sourcepoint response
+patches are Rust regex rewriting behavior rather than standalone browser
+programs, so that patch logic stays with the Rust Sourcepoint integration while
+only executable fragments/assets move. Core-owned `build_bids_script`,
+`build_seam_script`, and `build_ad_slots_script` remain core-owned neutral
+document programs.
+
+This split does not introduce a general template language. Integration-owned
+program bodies live in `trusted-server-integrations-js`; integration Rust may
+serialize safe data and fill a narrowly generated owner-specific renderer that
+preserves the baseline escaping model. This permits the existing narrowly
+scoped safe substitutions but does not expose generic templating. Static and
+configuration-rendered inline bytes and hashes participate in the document
+fingerprint. Request-dependent GPT-diagnostics bytes bypass shared-template
+reuse and do not enter the composition-wide document fingerprint. Canonical
+formatting may change generated bytes during the move, so behavior and reviewed
+goldens—not a blanket byte-for-byte promise—are the acceptance contract. A source/artifact
+guard fails when a new production executable integration algorithm is
+introduced directly in Rust without an explicitly reviewed data-only exception.
+
+## Error Handling
+
+Failures occur as early as the available information allows, with policy
+defined per capability rather than one blanket rule.
+
+Build-time failures include an invalid static catalog, missing typed browser
+modules, JavaScript compilation failures, and missing generated bundles.
+
+CLI validation rejects retired or mixed configuration shapes, unknown
+definitions, invalid integration settings, unresolved qualified provider
+references, duplicate routes, incompatible capabilities, invalid auction plans,
+and unavailable assets. Startup repeats these checks and normally fails on the
+same conditions. Its sole catalog-drift containment exception is the previously
+accepted schema-2 operator-asset conflict defined above: exact asset policy wins
+and a colliding newly declared integration-owned route is dropped with a
+sampled diagnostic. Reserved application routes are never dropped. The
+exception does not make native/native duplicates or other invalid configuration
+recoverable.
+
+Runtime hooks retain their current `Report<TrustedServerError>` context and HTTP
+behavior. Request filters and HTML hooks preserve their existing propagation;
+provider failures remain materialized provider outcomes; mediator dispatch,
+transport, deadline, parse, and non-2xx failures warn and fall back to local
+ranking using the existing telemetry representation; renderer failure follows
+the per-bid rule above. Moving a concrete call behind a registry must not change
+that hook's policy or introduce a panic.
+
+Core visibility changes are governed by a reviewed allowlist and a public-API
+snapshot gate. Helpers move with their integration when possible. The
+implementation plan names every module and item widened for Prebid, APS, and
+the other integrations, classifies it as a neutral contract or moves it
+outward, and fails CI on an unreviewed new export. Auction-engine inputs such as
+transport headers and response-admission diagnostics are specified as part of
+the neutral OpenRTB contract rather than exposed accidentally one helper at a
+time.
+
+Core tests do not add a dev-dependency on `trusted-server-integrations`, which
+would form a cycle. Vendor-specific unit tests and fixtures move with their
+owner. Core tests use neutral stubs behind `test-utils`; the implementation plan
+inventories current vendor-bearing fixtures, registry constructors, and test
+call sites and checks that moved tests are still selected by a native or
+target-matched gate.
+
+The integrations crate exposes test-only
+`routes_with_source_config`/`routes_with_composition_and_services` helpers (or
+an equivalent `TestCompositionFactory` under `test-utils`) for adapter route
+tests and cross-adapter parity. Core unit tests use only neutral stub
+registrations. The #1135 end-to-end case remains in
+`trusted-server-integration-tests/tests/parity.rs`; only integration-owned unit
+fixtures move outward. This keeps test construction on the production
+composition path without creating a core-to-integrations dev-dependency cycle.
+
+Some names remain in core because they are established wire/configuration
+contracts rather than implementation ownership. The reviewed retained-name
+allowlist includes `creative_opportunities.slot.providers.{aps,prebid}`, the
+browser `tsjs.scheduleInitialAdInit` and `trustedServer` namespace, the GAM
+`hb_*` handshake and slot fields, `nextjs-static`, `TrustedServerError::Gam`,
+`rsc_flight`, APS/Prebid slot parameter types, and the historical `prebid_eids`
+neutral identity module. Their current serialized forms and CLI editing
+behavior remain. Conversely, `TrustedServerError::Prebid`, concrete Prebid
+request extensions, the JS-asset-proxy header constant, the `"adserver_mock"`
+plan literal, DataDome-only staging input, vendor benches, and the concrete core
+test fixture move outward or become a named neutral contract. A mechanical
+guard scans production Rust/JS beneath core, excluding tests, fixtures,
+generated output, and exact allowlisted paths/tokens. It rejects any additional
+concrete vendor token unless added with a wire-compatibility reason; it is not a
+raw substring ban across the repository.
+
+## Compatibility Contract
+
+The change intentionally does not preserve operator configuration or config
+blob shape. It also intentionally changes provider priority from lexical local
+provider-ID order to qualified configuration order. It preserves:
+
+- Integration IDs.
+- Existing routes and endpoint behavior.
+- Existing integration hook behavior in milestone 1, except for the explicitly
+  listed shared-browser-state corrections; schema 2 then changes applicable
+  hook order to configuration order.
+- Auction plan compilation semantics after configuration normalization, except
+  for the documented provider-priority source.
+- OpenRTB request, response, routing, timeout, notification, and response
+  admission behavior.
+- Auction price comparison, mediation protocol, renderer descriptors, and
+  provider telemetry schema. #1203 uses the existing mediator error metadata
+  and row-status mapping. Provider response order and a locally selected
+  equal-price winner may change when configuration order differs from the old
+  lexical order.
+- Managed Prebid User ID aliases, collision checks, consent gating, opaque
+  LiveRamp envelopes, OpenRTB EID production, EC partner ingestion, and admin
+  diagnostics.
+- External Prebid bidder, User ID, and analytics-module selection, manifests,
+  hashes, SRI values, and runtime codes.
+- Cache privacy, streaming/buffer decisions, origin-representation policy,
+  cookie-key and bypass policy, and every
+  existing publisher template-key dimension.
+- Current CLI ad-template diagnostics, audit/generator recovery behavior, and
+  corrected prerequisite #1202 Prebid bundle mutation behavior.
+- The route and behavioral parity of Fastly, Axum, Cloudflare, and Spin, except
+  for the explicitly listed Fastly missing-root/chunk classification correction.
+
+The intentional compatibility breaks are:
+
+- Auction providers move from `[auction.providers]` beneath their owning
+  integration and references become qualified.
+- External provider labels change at the schema-2 cutover from local values
+  such as `pbs-main` to qualified values such as `prebid.pbs-main`; schema 1
+  retains the legacy labels during the dual-reader window.
+- The corrected #1203 policy classifies non-2xx with existing
+  `error_type = "http_status"`/`http_status_error` telemetry and falls back to
+  local ranking. Numeric status and fallback appear only in structured logs or
+  existing metadata; no datasource column is added.
+- The fixed legacy `protocol = "openrtb-2.6"` field is removed from operator
+  source rather than copied into each integration-owned provider.
+- Every retained integration parent requires an explicit `enabled` value,
+  including parents whose current schema supplies a default.
+- Disabled retained blocks must deserialize against the new structural schema:
+  unknown fields, wrong types, malformed IDs, and invalid retained secret
+  references now fail even though active-only value checks remain deferred.
+- Integration and provider parents must use ordinary table headers in
+  parent-before-descendant order; dotted-key or inline-table parent shorthand
+  is rejected.
+- APS providers no longer activate without an enabled `[integrations.aps]`
+  parent.
+- A retained enabled Prebid parent with neither a provider nor browser-activating
+  URL becomes a valid staged no-op; the activation matrix and migration tool
+  make this explicit rather than inheriting an integration-specific default.
+- References to a known disabled integration are pruned as a kill switch:
+  bidder routes report `disabled_by_integration` and stay suppressed from
+  client-side fallback, while a disabled selected mediator warns and uses local
+  ranking instead of the baseline startup error. Absent and unknown targets
+  still fail.
+- Attribute and script rewriters use schema-2 configuration order instead of
+  the complete legacy sequence. The migration tool shows this order and its
+  overlap diagnostics; it does not falsely describe `js_asset_proxy` as the
+  baseline first rewriter.
+- The unordered abandon/failure provider path begins using plan order.
+- Conflicting trusted attributes for the unified script tag fail composition
+  instead of warning and keeping the first value; identical duplicates still
+  collapse.
+- `js_asset_proxy` blocked/enabled policy also governs matching script preloads,
+  rather than leaving a preload for a removed or rewritten script. This is an
+  explicit milestone-one correction and is covered separately from ordinary
+  non-script `href`/`src` handling.
+- Every opaque preloaded browser-queue callback waits until immediate
+  registrations and fixed synchronous post-unified setup finish; successful
+  evaluation drains in the separate finalizer, an aborted immediate IIFE uses
+  the microtask failure fallback, and a missing finalizer remains buffered.
+- Serialized Next.js Flight/RSC payload bytes are intentionally outside URL
+  rewriting after prerequisite #1208: an origin or GTM-looking URL inside Flight
+  remains upstream while an executable URL outside that payload is still
+  rewritten. The captured corrected-baseline golden, not the historical
+  discovery output, is the compatibility authority.
+- Browser state that is accidentally duplicated across self-contained IIFEs is
+  unified behind the runtime facade: Permutive context reaches core collection,
+  integration logging follows `tsjs.setConfig`, and APS renderer/frame state is
+  shared across core, GPT, and Prebid. These are explicit baseline bug fixes,
+  not invisible "pure moves." Permutive's newly restored context can now be
+  emitted for allowlisted keys without a new browser consent gate;
+  `allowed_context_keys` is not represented as consent enforcement, and a
+  consent-policy redesign is explicitly out of scope.
+- Stored data gains the application schema and explicit order sidecars. The
+  rollout decoder, not the steady-state schema, provides temporary old-blob
+  compatibility.
+
+No alternate `[integration]`, `[demand]`, or `[adserver]` selector convention
+is supported alongside the single `[integrations]` design. There are no aliases
+or precedence rules between competing inventories.
+
+Bundle hashes and cache-busting URLs may change because browser sources are
+rebuilt in different crates. The server must emit URLs matching the new
+embedded hashes; bundle hashes are not a stable public contract.
+
+## Delivery Scope
+
+This is one architecture design but not one undifferentiated refactor. It has
+four reviewable workstreams:
+
+1. Neutral Rust capability and lifecycle contracts.
+2. Browser-core separation and `trusted-server-integrations-js`.
+3. Concrete Rust extraction and application composition ownership.
+4. Ordered configuration, provider identity, and auction-profile migration.
+
+The implementation plan must give each workstream its own verification
+checkpoint and keep behavior-preserving moves separate from intentional config
+and ordering changes.
+
+The first merge milestone contains workstreams 1 through 3 and retains the
+current operator schema and provider activation semantics through a temporary
+normalization adapter. It delivers the crate boundary without an operator
+cutover. The second milestone contains workstream 4, introduces stored schema
+2 and the rollout decoder, and replaces the temporary source normalizer with
+the new source parser. Neutral contracts from workstream 1 may land as
+behavior-inert preparatory commits, but milestone 1 is not complete or
+deployable as the new architecture until workstreams 1 through 3 all meet its
+exit criteria.
+
+Intermediate revisions keep exactly one active catalog while moving
+integrations incrementally. The catalog may temporarily delegate individual
+entries to explicitly allowlisted implementations still in core, and the
+browser manifest may temporarily point individual entries at the legacy source
+root. Each move removes one transitional entry. There are never two catalogs or
+two interpreted provider inventories, and copied-but-unused duplicate source
+trees are forbidden. This scope does not include an external plugin ecosystem.
+
+The milestone-one normalizer is a compatibility boundary, not a second
+catalog. It accepts only the current operator and stored shape, resolves current
+profile strings through the new static definitions, preserves the current fixed
+integration-builder order, lexical provider priority, and implicit APS
+activation, and emits the one neutral model consumed by composition. Milestone
+two atomically replaces that source parser with the new `[integrations]` parser;
+it does not accept both operator inventories. Only the read-only stored-blob
+decoder continues to accept the complete legacy shape during rollout.
+
+Milestone exit criteria are independent:
+
+- **Milestone 1 — crate boundary:** only the current operator and stored schema
+  are accepted; fixed integration-builder order, lexical provider priority,
+  implicit APS activation, operator source semantics, cache policy, adapter behavior, and
+  Fastly settings-only failure paths remain unchanged except that a missing or
+  not-yet-propagated config root/chunk follows the documented transient
+  startup/503 outcome instead of configuration/500. The EdgeZero typed hook,
+  `config validate --adapter`, and selected-target diff/push validation are the
+  explicit milestone-one CLI deltas. The browser-state
+  corrections listed in the compatibility contract and one-time artifact/hash
+  invalidation, queue deferral, script-preload policy, and release-mode trusted-
+  attribute validation are explicit milestone deltas. Corrected script chaining
+  and disjoint parsed DOM ownership are prerequisites and apply to schema 1 as
+  well as schema 2; only their ordering source changes later. Every live consumer uses the new
+  composition root, every concrete source has moved, the public-API snapshot's
+  explicitly classified transitional-export set is empty, and the full
+  repository gates pass.
+- **Milestone 2 — ordered configuration cutover:** the new operator source is
+  the only writable shape; the dual stored-schema reader is deployed; qualified
+  identities and order sidecars are used end to end; every normal and recovery
+  path uses plan ordinals; activation rules, CLI output, examples, diagnostics,
+  scripts, documentation, and the rollout runbook are updated together; and the
+  full repository and rollout tests pass before schema 2 is pushed.
+- **Later release — cleanup:** the schema-1 reader is removed only after the
+  rollback and support conditions in the rollout contract are satisfied.
+
+## Migration Sequence
+
+Implementation uses reviewable commits, but the merged workspace must never
+have two active integration or provider inventories. Steps 1 through 6 comprise
+milestone 1; each crate/source move is independently testable under the one
+transitional catalog.
+
+1. Add neutral capability, processing-requirement, browser-asset, OpenRTB
+   profile/exchange, and mediator contracts to core. Extend the `test-utils`
+   feature with only neutral stubs required by extracted integration tests.
+2. Replace the closed APS and Prebid profile variants and the mediator's legacy
+   `AuctionProvider` use while implementations are still in core. Convert GPT
+   diagnostics and DataDome call sites to the neutral lifecycle contracts.
+3. Create both new crates and update Cargo aliases, native/WASM checks, JS
+   discovery/typecheck/lint/format commands, Dependabot inputs, and test package
+   selection in the same change. Update compiled documentation snippets and
+   crate-path documentation required for that workspace state. Move
+   `TrustedServerAppConfig`, integration validation/secret metadata, and the
+   composition facade to the integrations crate; rewire every adapter and the
+   CLI to that one composition root while retaining the legacy schema through
+   the shared converter. Move catalog-dependent loading, inactive integration-
+   secret preprocessing, resolved-value validation, mediator lookup, every
+   settings reload caller, and configuration-fixture generator behind that
+   facade. First add neutral
+   `IntegrationRegistry::from_registrations` construction; convert core engine
+   tests to neutral registrations and move tests requiring the real catalog to
+   integration-owned test support. Create the explicit Rust catalog as the one
+   active catalog, initially delegating through a shrinking, reviewed class of
+   transitional core exports, and delete core's old `builders()` and concrete
+   `with_plan` composition paths. Create the one browser manifest with an
+   equally explicit shrinking map to legacy source paths. No production code is
+   copied into an unused duplicate tree. The EdgeZero extension and selected-
+   target push validation land here so config consumers cannot bypass the new
+   root.
+4. Move ordinary Rust integrations one owner at a time, then DataDome and GPT
+   diagnostics after their lifecycle seams, APS and Prebid after the profile
+   seam, and `adserver_mock` after the mediator seam. Add `openrtb`. Each move is
+   a rename-focused change that moves its unit tests/fixtures, removes its
+   transitional export, runs the public-API guard, and proves the moved tests
+   are selected.
+5. Move browser integrations one owner at a time with their unit/artifact tests,
+   GPT bootstrap, APS renderer document, integration-owned executable inline
+   programs, registry inputs, and shared fixtures. Each move removes one legacy
+   manifest path and updates its JS gates immediately. Complete the cross-root
+   import audit, remove browser-core APS imports, adopt the shared runtime
+   facade, and make composed assets authoritative. Under schema 1, immediate
+   concatenation reproduces the corrected frozen legacy order through the new
+   registration-sequence dispatcher; schema 2 later changes only the order
+   source. Cross-adapter system tests remain in
+   `trusted-server-integration-tests` and gain bootstrap/core/immediate/deferred
+   load-order coverage.
+6. Remove the final Rust and browser transitional exports/path mappings, prove
+   the public-API snapshot's transitional class is empty, and run the complete
+   schema-one differential and repository gates. This is cleanup and
+   verification of the composition switch made in step 3, not a second switch.
+7. Add the TOML source pre-pass, ordered in-memory maps, application schema 2,
+   object-shaped storage with explicit order sidecars, strong qualified
+   provider IDs, the shared schema-one reader, `ts config migrate`, and the
+   integration-owned provider schema. Replace and remove only the legacy source
+   entry point from ordinary config commands; the isolated migration parser may
+   read legacy source only to emit a schema-2 candidate.
+8. Switch the already-composed hook and provider pipelines from frozen legacy
+   order to schema-2 configuration order, and activate schema-2 external
+   qualified labels and plan-order recovery only after focused baseline and
+   failure-path tests pass. Script chaining, disjoint DOM ownership, and trusted
+   attribute validation do not wait for this step.
+9. Update operator examples, fixtures, migration diagnostics, guides, and the
+   adapter-specific rollout runbook. Repository/CI path updates associated with
+   moved code are already complete from steps 3 through 6. Deploy the dual
+   reader, then cut over schema 2 according to the rollout section.
+10. Remove the read-only schema-1 blob decoder only in the later release defined
+    by the rollout contract.
+
+Steps 7 through 9 are one deployable milestone-two cutover. They may be
+implemented as separately reviewed commits, but schema 2 must not merge or
+deploy while lexical recovery ordering, CLI consumers, or operator guidance
+still implement the old contract.
+
+When files leave core, the Fastly-SDK migration guard is not weakened. Its
+integration `include_str!` entries move to an equivalent guard owned by
+`trusted-server-integrations`; neutral core entries remain in core. Integration
+tests move integration-owned fixtures and helpers outward. Only platform-neutral
+stubs become public under `test-utils`; production APIs are not widened merely
+to preserve `cfg(test)` imports.
+
+## Testing and Verification
+
+### Discovery and dependency tests
+
+- The static Rust catalog contains exactly the sixteen expected definitions,
+  and every valid `src/integrations/<id>/mod.rs` directory appears exactly once.
+- Invalid, missing, or duplicate catalog IDs fail tests or compilation.
+- JavaScript-only and Rust-only directories are accepted.
+- A typed Rust reference to an absent browser module fails compilation.
+- Embedded bundle hashes match built bytes.
+- Core has no dependency on either integrations crate.
+- `trusted-server-integrations` has no `edgezero-cli` dependency and compiles in
+  every native and WASM adapter graph; the `toml_edit` source module is absent
+  from WASM graphs and host command dispatch remains in `trusted-server-cli`.
+- Browser core imports no integration source.
+- Adapters and CLI import no concrete integration module.
+- The public-API gate rejects an added/widened/removed symbol absent from the
+  reviewed delta manifest and rejects unrelated changes to the grandfathered
+  neutral baseline; core tests introduce no dev-dependency cycle.
+- A dedicated native test/clippy gate executes the integrations catalog and
+  host-only completeness tests; relying on adapter dependency builds is not
+  sufficient to run them.
+
+### Configuration and ordering tests
+
+- TOML parent-table order becomes the integration-owned source-model order.
+- The `toml_edit` pre-pass and typed `toml`/EdgeZero parser use the same TOML
+  language generation and agree on parity fixtures outside `[integrations]`.
+- A dependency-graph gate proves the normal, non-dev CLI and `cargo install`
+  graphs directly enable `toml/preserve_order` and resolve the direct
+  `toml_edit` dependency to the selected TOML-1.1 generation; a production-mode
+  non-lexical fixture fails if either condition is removed. Adapter runtime
+  graphs consume only explicit stored sidecars and never depend on TOML or JSON
+  object iteration order. Storage tests permute JSON object members and prove
+  identical runtime order.
+- Nested provider declaration order is retained.
+- A parent integration or provider table declared after one of its descendants
+  fails before typed deserialization.
+- Missing `enabled` fails; omitted integration tables remain inactive.
+- TOML-to-envelope-to-runtime round trips preserve both order sidecars exactly,
+  independent of JSON object-member order.
+- Order sidecars reject missing, duplicate, extra, or mismatched map keys.
+- Every stored schema-2 integration object emits `enabled`; a missing value is
+  rejected, and a disabled block remains disabled after push and reload.
+- Schema-1 stored blobs normalize through the transition reader; schema N+1 and
+  every other unknown schema value fail before secrets are resolved. Golden
+  rollback tests prove every binary retained for the rollback window rejects a
+  schema-2 root marker and cannot mistake it for schema 1.
+- Each candidate schema-2 compatibility corpus has generated leaf/variant
+  coverage and is serialized by the candidate writer, then decoded by the
+  oldest rollback reader, deployed N, and the candidate reader. Its minimal,
+  explicit-default, disabled, and maximal candidates prove absent and
+  semantically default-valued leaves stay omitted, later defaults apply without
+  repush, non-default new fields are release-gated, and disabled source-shaped
+  blocks decode without synthesizing enabled-only required fields. Prebid
+  script-pattern fixtures prove exact case/order comparison after route
+  normalization, duplicate rejection, and identical CLI/runtime route claims
+  after round trip. The candidate reader also decodes frozen exact bytes from
+  deployed N's complete corpus and every live schema-2 release export, with
+  normalized parity except for documented default changes.
+- The shared schema-one converter preserves omitted integration defaults,
+  ignores baseline-accepted unknown integration IDs with one rate-limited
+  warning, retains local external IDs, and reproduces globally interleaved
+  lexical provider priority before qualification.
+- Config-store loading produces the same registry, JavaScript, and provider
+  order that the CLI validated.
+- Registry metadata and CLI provider diagnostics report configured ordinals;
+  lookup-map or alphabetic iteration cannot masquerade as execution order.
+- CLI validation compiles and discards the complete secret-independent plan,
+  including routes, bidder ownership, mediator capability, and duplicate
+  claims, without constructing runtime capabilities from unresolved secret key
+  names. Diff/push fail selected-target validation. Validate with no `--adapter`
+  runs target-neutral Trusted Server checks plus unchanged EdgeZero validation;
+  each explicit repeatable `--adapter` is reported and any selected-target
+  rejection fails. EdgeZero `--strict` retains its existing manifest meaning.
+  Every secret-independent runtime rejection has a matching target-neutral
+  error or named-target CLI fixture.
+- Read-only CLI consumers see the effective overlay through
+  `SourceConfigView` without deploy validation; deploy commands use
+  `ValidatedSourceConfig` after the overlay. Mutators and generators operate on
+  file-only bytes, retain invalid-baseline recovery where currently supported,
+  and never persist overlay values. Invalid candidate plus valid baseline
+  refuses; two invalid values retain the current non-disclosing warning and
+  write escape hatch.
+- Validate/diff/push use the EdgeZero typed-config extension, proving the
+  pre-pass, command/target validation, and typed serialization consume one exact
+  read and one effective typed value even under concurrent source replacement.
+  No command creates config or manifest snapshots. Migrate/validate/diff/push
+  with `--no-env` skip both overlay and stale-name scanning and report the skip;
+  without it, every retired app-prefixed environment path fails.
+- Prebid bundle selection and managed-module requirements come from the
+  integration-owned `PartialSourceConfigView<PrebidConfig>`, not a CLI-local
+  schema or hard-coded registry path. Bundle modules and generated hash/SRI
+  metadata can be staged without an external URL, remain runtime-inert, and are
+  patched atomically over an otherwise-invalid unrelated baseline. The command
+  fails with a placement example when the explicit `[integrations.prebid]`
+  parent is absent and never appends a parent that silently chooses runtime
+  order. Tests preserve the original file mode and prove parse diagnostics
+  contain path and line/column but no source content.
+- Disabled integrations may retain structurally valid provider settings, contribute no
+  providers or capabilities, and do not reorder enabled neighbors.
+- Every definition with disabled placeholders pairs an omitted active-only field
+  that passes structural validation with an omitted structural field that fails;
+  no test or implementation classifies serde error strings.
+- Disabled placeholder values that current examples rely on, including the
+  Google Tag Manager placeholder container, deserialize safely and defer their
+  active-only format validation until enabled.
+- Retained secret references in disabled source still pass EdgeZero name,
+  store-reference, collision, and adapter validation; omitted active-only
+  references are accepted, and inactive paths are not value-resolved at
+  runtime.
+- Bidder and mediator references to explicitly disabled known integrations are
+  omitted from the compiled plan with one warning, including while the global
+  auction is disabled; absent and unknown targets still fail. Pruned routes
+  report `disabled_by_integration` and remain suppressed from Prebid client-side
+  fallback, while a disabled selected mediator warns and uses local ranking.
+- Nested-only, unknown, missing-enabled, descendant-before-parent, and mixed
+  old/new configurations fail with actionable messages.
+- Qualified provider references resolve correctly and reject missing or
+  incompatible targets.
+- Local and qualified provider IDs enforce their separate grammars and bounds.
+- Multiple provider instances under APS, Prebid, and standard OpenRTB compile
+  with stable qualified identities.
+- Provider launch, response, mediator-input, and local equal-price tie order
+  follows integration then local-provider declaration order.
+- Every later launch receives its actual remaining logical budget, and tests
+  cover adapter timeout bucket boundaries even without deadline expiration.
+- Transport-failure recovery paths retain plan order and never fall back to
+  lexical provider sorting.
+- APS, Prebid, and `openrtb` fixtures cover enabled parents, disabled-parent
+  retention, missing-enabled rejection, and the nested provider migration.
+- Activation-matrix tests cover APS and Prebid with zero and multiple
+  providers, server-only Prebid without browser activation, browser-only Prebid,
+  standard OpenRTB, and the `adserver_mock` mediator.
+- Qualified IDs that alias under Axum's legacy normalization receive distinct
+  correlation names or fail target validation before deployment.
+- `ts config migrate --dry-run` preserves comments and permissions, emits
+  frozen explicit defaults and environment-variable path mappings, handles
+  server-only Prebid and implicit APS, preserves exact legacy priority when
+  provider owners are contiguous, reports every old/new ordinal and reordered
+  pair for every affected comparable capability phase, rejects mixed input, and
+  never performs a remote write. Tests pin dry-run exit 1 for unaccepted
+  provider/hook/browser reordering, unknown legacy integration tables, and
+  manual edits; non-interactive refusal without `--accept-reordering`; explicit
+  per-ID unknown discard; and interactive confirmation. Goldens cover the
+  shipped example, a redacted unknown-table report with a sentinel secret that
+  never appears in stdout, stderr, or logs, parent promotion that
+  changes hook order without changing provider order, and disabled Prebid with
+  a staged URL and active legacy Prebid Server provider.
+- Ordering diagnostics cover provider details, ts-debug, telemetry `is_win`,
+  mediator `ext.bidder_responses`, backend names, and CLI provider listings in
+  addition to launch and response order.
+
+### Capability and behavior parity tests
+
+- After every prerequisite lands, a focused differential harness records the
+  exact baseline commit and captures actual output goldens for a matrix covering
+  all integrations, APS/Prebid/standard providers including globally interleaved
+  IDs, deferred Prebid, GPT diagnostics, Next.js/GTM script rewriting, RSC
+  streaming, and the #1135 path. It compares hook order, rendered output,
+  module ID lists, head inserts, trusted tag attributes, route tables,
+  plan/provider order, mediator input order, and relevant CLI views. Rebuilt
+  artifact hashes are recorded separately from behavior deltas.
+- The static catalog contains all current integration IDs plus `openrtb`.
+- APS and Prebid register page/browser and auction capabilities without core
+  importing their types.
+- `adserver_mock` registers and is selected through the mediator capability.
+- Route tables and duplicate detection retain behavior.
+- Common and target-specific reserved-route claims are inserted before
+  integration claims. Asset and integration collisions with discovery, admin,
+  auction, page-bids, `POST /verify-signature`, first-party, dynamic TSJS,
+  `/health` only on adapters that register it, and adapter-only routes fail
+  source validation and startup on every affected adapter. The common claims
+  include canonical admin routes and denied legacy `/admin/keys/*` aliases;
+  Fastly-only claims include tester routes and the pre-router JA4 probe as well
+  as batch-sync and identify. Cloudflare `/health` remains publisher fallback.
+  A route-manifest parity gate proves actual fixed
+  registrations and reserved claims have the same method, canonical pattern,
+  precedence, and fallthrough behavior, including prefix-dispatched TSJS and
+  root/catch-all behavior; all seven methods that can reach publisher fallback
+  at the authenticated cache-purge path remain intercepted. Fastly's batch-sync and identify methods
+  are reserved only for Fastly, and their existing fallthrough on Axum,
+  Cloudflare, and Spin remains observable. The catalog-drift asset-wins fallback
+  is tested only against a newly added integration route.
+- A schema-2 blob accepted by catalog N is exercised under candidate N+1 after
+  N+1 widens both a script-source claim and a native route into conflicts. The
+  runtime remains available, enforces the exact operator asset policy, drops
+  only the colliding integration-owned route, and emits sampled diagnostics
+  naming the tables, URL/path, and build ID; the candidate-versus-live-config
+  promotion gate rejects that release.
+- Catalog-drift asset tests cover both script sources and preloads with an
+  earlier `Remove`, `Replace` then `Remove`, and an unchanged element. The
+  engine-boundary clamp restores an enabled asset to its exact first-party path
+  or removes a blocked asset before committing the ordinary chain's outcome;
+  normal chains still stop at `Remove`. A disabled asset registers no proxy
+  route, imposes no final-outcome clamp, and does not prevent a later native
+  rewriter from changing the element.
+- The checked-in stored-catalog gate proves deployment-inventory/export
+  bijection, accepts verified schema-one and schema-two envelopes without
+  resolving secret values, rejects missing/tampered exports and degraded
+  conflicts, and emits only redacted identities/hashes. The command never
+  deletes its `--exports` input. Release-pipeline tests create a marked directory
+  under a controlled temporary root, clean it on success or failure, and refuse
+  cleanup for a mismatched marker, outside-root path, or symlink substitution.
+  Every candidate release also differentially decodes every live schema-one
+  export with the deployed and candidate readers under identical secret
+  resolution and rejects unexplained activation, ordering, label, or error
+  changes; one archived fixture is not a substitute for the live inventory.
+- DataDome preserves unconditional HTML origin-representation handling without
+  selecting buffering, and scopes privacy to body-carrying synthesized HTML.
+- GPT diagnostics preparation, bootstrap injection, finalization, and caching
+  remain unchanged on every adapter path.
+- With Next.js and Google Tag Manager enabled together, an exact RSC golden
+  proves a GTM URL inside serialized flight data remains upstream, an executable
+  URL outside the flight payload is rewritten, and streaming completes with the
+  expected successful response.
+- GPT-diagnostics reserved query/cookie normalization runs and remains
+  idempotent when the integration is absent, disabled, or enabled. All four
+  adapters cover multiple Cookie fields and non-ASCII bytes before generic
+  cookie handling. Activation-dependent preparation/finalization stays gated,
+  while auction correlation uses deployment capability rather than request
+  activation.
+- APS and Prebid request construction, transport, parsing, response admission,
+  and auction results remain equivalent to current `origin/main` behavior
+  except for the documented provider-priority, external-identity, and shared
+  browser-state corrections.
+- Prepared response parsers consume profile-owned request state without `Any`,
+  downcasts, vendor enums, or cross-provider state reuse.
+- Prepared outcomes cover both a bound exchange and no-impressions `Skip`, and
+  renderer descriptor JSON plus targeting bid identity remains wire-compatible.
+- The complete #1159 matrix crosses zero through two providers and pins
+  `Disabled`, `Explicit`, and legacy-inferred stored-request intent; malformed
+  envelopes; omitted/empty legacy demand; overrides before usable-impression
+  admission; zero-impression no-transport `Skip` with
+  `routing.skipped_no_usable_demand`; and parser rejection of bids for
+  impressions absent from the sent request.
+- Bidder routing, backend naming, notification suppression, telemetry identity,
+  and mediator behavior remain equivalent apart from documented ordering and
+  schema-2 qualified-identity changes.
+- Active DataDome secrets are presence-checked and resolved through unchanged
+  object paths; inactive protection and bypass secrets are removed before the
+  shared resolver.
+- Core-owned preprocessing continues to remove inactive Tinybird token and
+  disabled EC-partner pull-token references before the shared resolver.
+- Neutral `ts-eids` ingestion retains managed User ID aliases and collision
+  checks, opaque LiveRamp envelopes, consent gating, OpenRTB EID production, EC
+  partner ingestion, and admin diagnostics without adding a LiveRamp catalog
+  definition or an identity-provider capability system.
+- Core EC tests preserve one request-scoped snapshot across navigation,
+  `/auction`, page-bids, publisher work, finalization, and pull sync; at most one
+  conditional EID write plus one conflict follow-up; no overwrite of divergent
+  state or concurrent withdrawal; idempotent tombstones; snapshot-gated no-op
+  pull-read avoidance followed by the required consent reread; grouped
+  batch-sync order/accounting; and continued rejection of the removed legacy
+  consent-store input.
+- Request-processing requirements preserve DataDome origin bypass, full-body
+  representation, streaming/buffering selection, scoped private caching, and
+  origin-readthrough vetoes, and prevent request-private GPT diagnostics state
+  from entering ESI templates. Every GPT-diagnostics decision requiring
+  private/no-store independently vetoes shared-template and origin-readthrough
+  reuse before origin selection while setting all-response privacy. Tests cover
+  active diagnostics, inactive cookie clearing, and malformed/duplicate query
+  cleanup, including origin-shareability telemetry under the #1169 readthrough
+  path.
+- Warm-hit and cold-store matrices combine DataDome/GPT requirements with key,
+  bypass, malformed, unlisted, absent, and empty cookies; integration privacy
+  can only restrict the existing cookie/cache decision.
+- The dedicated mediator capability preserves request construction, ordered
+  response input, bounded transport, parsing, and dispatch/transport/deadline/
+  parse/non-2xx fallback without exposing the legacy `AuctionProvider` trait. A
+  parsed non-2xx response maps existing `http_status` metadata to
+  `http_status_error` and falls back to local ranking without a fabricated
+  mediator winner, as fixed by prerequisite #1203.
+- Fastly's JA4 gate and failed-startup finalization still receive the
+  validated settings-only view when a later target, mediator, route, or
+  capability stage fails; failures in the baseline loader validations still
+  withhold it. Tests inspect the staged `CompositionAttempt`, prove no config
+  re-read on the failure path, map missing or unpropagated root/chunk to redacted 503,
+  and retain hash/schema/parse corruption as 500. Reusable capability objects
+  are immutable and request-stateless, with document buffers created per HTML
+  processor. Fastly adapter tests prove a missing root or referenced config
+  chunk takes the milestone-one transient startup/503 path and never partially
+  decodes the envelope, while a hash mismatch remains corruption.
+- Fastly copy-tool tests exercise the pinned CLI JSON shape and exact stdin
+  bytes, verify per-chunk length/hash and pointer
+  `envelope_len`/`envelope_sha256` before inner `BlobEnvelope.sha256`, reject an
+  ambiguous store name, wrong service-version selector/link, wrong root key, or
+  equal old/new physical IDs. An end-to-end fixture uses distinct non-default
+  source/destination physical names and root keys and proves both schema writers
+  consume their verified tuples. A runbook test keeps writes frozen through POP
+  probes. During the rollback window it either retains the freeze or stages
+  immutable schema-one/schema-two roots and matching service versions, verifies
+  both before selection, blocks rollback during partial propagation, and
+  accepts the pair only after the new active version converges. Failure leaves
+  the last accepted pair selectable, never a half-updated pair. Cloudflare
+  fixtures pass schema-one and schema-two envelopes
+  through the manifest-derived property, legacy property, and exact-empty-primary
+  fallback without changing the outer binding shape; whitespace-only and
+  non-string primary values fail without consulting the legacy property.
+- Fastly `ts config gc` refuses both physical stores in the accepted
+  active/rollback pair, refuses a missing or stale rollout record before an
+  EdgeZero sweep, and leaves bytes unchanged. It resumes only after explicit
+  closure and verified absence of protected version bindings.
+- `config push` refuses a schema-2 write to the uncutover Spin destination and
+  to Cloudflare KV, leaves remote bytes untouched, and accepts only a verified
+  Fastly new-generation tuple. Cloudflare's protected export command produces
+  the exact validated outer JSON binding without logging bytes; deployment
+  tests compare its envelope hash and selected property with the bound Worker
+  version before activation and reject mismatches. Cloudflare rollback tests apply a post-cutover
+  kill-switch edit and prove the activated rollback binding reflects it through
+  paired version/binding verification, or prove writes stayed frozen. Rollout
+  probes deterministically emit a redacted event with each authenticated unique
+  probe ID and representative POP; a missing event fails the gate. Missing,
+  expired, or invalid tags never force a digest or appear in telemetry, and the
+  observation header never reaches an origin or cache key. Each probe also
+  asserts a preselected settings-dependent response predicate; when the two
+  generations are behavior-equivalent, authenticated binding/envelope evidence
+  distinguishes them, and paired edits additionally probe the changed
+  behavior. `/health` or a generic 2xx cannot pass. Fastly's early
+  store-open and JA4 failures retain baseline 500, missing or unpropagated
+  root/chunk uses 503, and verified corruption uses 500; `GET /health` remains
+  200 in each case.
+- Interactive migration detects a changed, replaced, or disappeared source
+  during a reordering prompt and leaves the operator's newer file untouched;
+  the command states the narrow external-editor race after its final comparison.
+
+### Browser tests
+
+- Unified output order is core, creative prelude, and configured immediate
+  integrations; fixed synchronous post-unified assets follow, then the neutral
+  queue finalizer. Deferred and standalone phases remain separate.
+- Immediate and deferred lists preserve configuration-relative order.
+- Artifact/import-graph checks reject undeclared cross-root value imports and
+  duplicate state-owner signatures. Permutive registration through its IIFE is
+  visible to core context collection; Prebid auction helpers and Testlight
+  queue behavior still use the single installed runtime.
+- Built-in DOM-insertion guards claim disjoint parsed host/path sets with
+  exactly one claimant per canonical URL. In milestone 1, composable handlers
+  run in immediate IIFE registration order sourced from the corrected frozen
+  legacy sequence; in milestone 2, the same dispatcher receives schema-2
+  configuration order. Numeric priority and lexical handler ID cannot affect
+  either result, query-string substrings cannot steal ownership, and a deferred
+  DOM handler fails composition. The build derives the DOM requirement from the
+  dedicated registration-accessor import; removing or hiding that import fails
+  the artifact check rather than trusting a Rust-authored flag.
+- Whole-chain asset tests pin exact final outcomes for
+  `/assets/prebid.min.js` and `/assets/testlight.js` as both script sources and
+  script preloads, while unrelated element/attribute contexts retain their
+  legacy handling.
+- APS is absent from browser core and registers its renderer from its own IIFE.
+- Core, GPT, and Prebid artifacts contain no private copy of APS renderer state.
+- Existing APS validation, sandbox, messaging, timeout, and rendering tests pass
+  through neutral dispatch.
+- APS Rust serves the exported integration-owned renderer-document bytes with
+  unchanged CSP and response headers; no production APS browser program remains
+  embedded as a Rust literal.
+- APS remains immediate and reads its rendering mode from the synchronous
+  unified tag; a deferred APS renderer is rejected during composition.
+- GPT remains immediate and reads `data-ts-gam-attribution` from the unified
+  tag through `document.currentScript` at evaluation time.
+- Equal duplicate trusted script attributes collapse, while invalid names,
+  invalid values, and conflicting duplicates fail release-mode composition
+  before HTML is served.
+- Missing or rejecting renderers drop only the renderer-bearing bid with no
+  fallback or newly created route/DOM/message/response/beacon side effect;
+  baseline supersession and fail-closed event handling remain, and duplicate
+  registration poisons the type or fails composition.
+- Direct-auction tests separately pin generic-`adm` bid/default metadata
+  precedence and malformed-descriptor fallback. Valid APS descriptors use the
+  handler's exact-key, decoded-payload, equality, and price validation and its
+  descriptor-owned dimensions/creative ID even when bid-level values differ;
+  valid-descriptor dispatch remains fail-closed.
+- Both server-bid and Prebid-`adId` renderer paths cover carrier scrubbing,
+  failed admission/registration, bounded TTL and capacity, authenticated source
+  and slot binding, atomic consume, replay rejection, renderer-owned Universal
+  Creative response metadata, and `markWinningBidAsUsed` preservation.
+- Unified, deferred, standalone, and inline assets expose bytes and hashes that
+  match the emitted document fingerprint and static responses.
+- The neutral finalizer is a synchronous same-origin external classic script
+  with its own static response, content hash, fingerprint discriminant, and
+  trusted tag attributes. A real-browser test enforces `script-src 'self'` and
+  proves the unified asset and finalizer run in order and queued callbacks
+  drain. A blocked or missing finalizer leaves the success-path queue buffered.
+- Independent document-fingerprint vectors cover every asset discriminant,
+  emission order, canonical attribute order, empty fields, duplicate normalized
+  attributes, exact inline bytes, raw external hashes, managed-external Prebid
+  tags with and without configured SHA/SRI, URL and attribute changes, and ambiguous-boundary
+  inputs; implementations hashing hex text or delimiter-joined fields fail.
+- Composition-digest vectors combine the verified EdgeZero data hash,
+  document-assets fingerprint, schema, and build ID using the specified raw-byte
+  and length framing; reject hex-text or ambiguous concatenation variants;
+  change when configured integration/provider order changes; never include
+  resolved secret values; and are lazily memoized. Authenticated rollout probes
+  force and log the digest for each unique probe ID without sampling;
+  optional debug/sampled observations may reuse that event schema. Retained
+  compositions deduplicate opportunistically, fresh instances may emit again,
+  and requests outside rollout/debug mode do not force it. Set-valued source
+  fields serialize deterministically.
+- Build-ID generator vectors are deterministic across repeated builds and
+  independently perturb core, integrations, OpenRTB, selected-adapter Rust,
+  browser source, `edgezero.toml`, `Cargo.lock`, target, host, profile,
+  optimization, debug, configuration, and authoritative feature inputs; each
+  relevant change alters that deployed artifact's lowercase ID while record
+  ordering does not. Tests prove every output-affecting build-script watch input
+  is hashed and every selected workspace dependency contributes exactly one
+  component. Exclusion, LF/CRLF rejection, label/value-width, and per-deployment
+  expected-ID vectors are pinned. The adapter traversal is checked against
+  target-matched Cargo metadata, deduplicates identical transitive records,
+  rejects conflicting labels, and changes ID when the actual compiler binary,
+  encoded rustflags, target features, codegen flags, or a permitted wrapper
+  changes; untracked release wrappers fail.
+- Changing any integration setting that affects generated head output changes
+  the document fingerprint; request-dependent head variation bypasses shared
+  template reuse through processing requirements.
+- GPT bootstrap, APS renderer document, Sourcepoint trap, GPT-diagnostics
+  bootstrap, and DataDome/Didomi/GPT/Prebid/Sourcepoint executable inline
+  programs resolve from their integration-owned package locations and pass
+  reviewed behavior/output goldens. Sourcepoint's Rust regex response patches
+  stay with its Rust owner. A guard rejects handwritten production integration
+  browser algorithms in Rust string literals without introducing a general
+  template framework.
+- External Prebid artifacts preserve bidder, User ID, and analytics category
+  selection, manifest/hash/SRI generation, managed-name alias and collision
+  checks, `identityLinkIdSystem` requirements, consent behavior, and runtime
+  codes after registry and shim paths move.
+- Owner-specific private `$OUT_DIR` directories and manifests reject stale or
+  partial output; the atomic-directory runner serializes installation and every
+  Vite, Vitest, TypeScript, ESLint, Prettier, Cargo browser build, and CLI
+  Prebid command for its entire process. Tests cover direct invocation and the
+  nested Cargo → outer runner → npm script → authenticated nested runner → Node
+  chain, token mismatch, PID reuse, normal cleanup, a dead holder, and a dead
+  holder with a surviving child. Recovery never proceeds while any recorded
+  ownership scope may be alive. The scoped repository guard rejects bare
+  `npx`/unwrapped production-browser tools without treating independent docs or
+  Playwright dependency trees as this project's lease members.
+- Clean and incremental Cargo builds prove that changing a sibling integration
+  source reruns the integration embed build and changes its manifest/hash while
+  leaving an unrelated neutral artifact unchanged.
+- Cross-adapter Playwright tests remain in
+  `trusted-server-integration-tests` and verify core, creative, APS, GPT, and
+  Prebid load order using the moved assets.
+- Out-of-Cargo browser harnesses consume the explicit host-exporter manifest
+  of Rust-embedded production bytes, verify every hash and load phase, and
+  reject stale, mixed-owner, missing, or modification-time-selected artifacts.
+- An artifact test loads GPT bootstrap, core, immediate GPT, synchronous GPT
+  diagnostics, the neutral finalizer, and deferred Prebid in production order;
+  proves object and neutral service identity/listener idempotence across
+  pre-core bootstrap and adoption, plus the opaque first-impression service's
+  claim, targeting snapshot/restore, pending, suppression-token, fallback,
+  render, navigation retirement, and lease
+  transitions. A stale marked pre-core service fails the adoption check without
+  a second service or listener installation; new-code admissions stop, while
+  previously installed callbacks are reported as uncontrolled. A separate unmarked legacy
+  bootstrap fixture proves new-core/GPT/Prebid admissions stop and the old
+  callbacks are reported as uncontrolled, not silently treated as migrated.
+  Post-core IIFEs reject
+  numeric-version and same-version/ABI-hash mismatches
+  without new mutations by the mismatched shim or setting its current-install
+  marker. The earlier Rust Prebid config tag may already have created
+  `window.pbjs`, and an external older bundle may already have installed a
+  shim; neither prior effect can be undone. A stale unversioned or mismatched
+  installation marker is diagnosed and cannot satisfy current idempotence or
+  cause a double patch. The test also verifies the temporary
+  `apsPrebidRenderers` compatibility alias. ABI tests pin the IDL grammar,
+  reachable named types, overload ordinals, DOM references, adoption markers,
+  and framed record/hash vectors, regenerate each declared surface byte-for-byte,
+  reject an undeclared actual value member or modification/deletion of a
+  target-branch published snapshot, and permit only a newly numbered snapshot.
+  Preloaded and Testlight-forwarded callbacks drain FIFO
+  only after diagnostics setup on successful evaluation and observe Permutive
+  context. A throwing immediate IIFE triggers the microtask failure fallback; a
+  throwing diagnostics IIFE is followed by the external finalizer; missing
+  finalizer leaves the queue buffered; and each drain path isolates a throwing
+  queued callback.
+- Production logging artifacts prove the default remains `warn`, an explicit
+  publisher `warn` is not overwritten, and Creative does not raise the shared
+  level.
+- Sibling-root gates resolve `vitest`, `prebid.js`, and an exported Prebid module
+  through the canonical project; the production two-root typecheck passes, an
+  isolated failing canary proves source checking is active, and
+  Prettier/ESLint use explicit canonical roots.
+
+### Repository gates
+
+Before handoff, run every gate required by `AGENTS.md`, including Rust format,
+all target-matched clippy aliases, Fastly/Axum/Cloudflare/Spin tests, CLI and
+cross-adapter parity tests, required native and WASM builds, JavaScript builds
+and Vitest suites for both browser source roots, JavaScript formatting, and
+documentation formatting. The explicit package lists in every Fastly
+build/check/clippy/test alias include both new Rust crates where applicable;
+the CLI and codegen host lint gates remain intact; and a dedicated host gate runs
+catalog completeness and integration test support. The migrated Fastly-SDK
+guard walks the complete moved integration directory and checks the dependency
+graph rather than copying the baseline's incomplete handwritten file list.
+Each crate/source move updates these selectors in the same change; a coverage
+gate proves moved Rust and JavaScript tests were discovered.
+
+The path migration covers repository automation as well as compiled code and
+paths assembled dynamically at runtime:
+GitHub workflows and PR templates, Dependabot, `AGENTS.md`, `.claude` agents and
+commands, the CLI Prebid builder, browser and template-cache smoke scripts,
+TypeScript/Vitest/format/lint configuration, crate READMEs, reader-facing docs,
+`trusted-server.example.toml`, and documentation-snippet tests. In particular,
+the GPT bootstrap fixture path, APS Rust fixture includes, browser integration
+build script, and local template-cache harness must resolve the new owners.
+VitePress lint/build and `documentation_snippets` remain gates. Historical
+archived specs are not rewritten as though they described the new layout.
+
+A repository path guard rejects active code or tooling that still points to
+`trusted-server-js/lib/src/integrations` or concrete
+`trusted-server-core/src/integrations/<vendor>` paths, except for an explicitly
+allowlisted transitional or historical reference. It checks string literals and
+known path joins, not only exact static paths. Dependabot's existing browser and
+docs entries remain; this split adds no second browser entry. The
+Cargo graph also records the direct `trusted-server-openrtb`
+and integration-test dependencies explicitly and removes unused direct browser
+crate dependencies from adapters.
+
+## Baseline Defects and Scope Containment
+
+The open-defect and in-flight-work disposition table is the authoritative
+inventory of prerequisite fixes, milestone corrections, and coordination-only
+work. Each prerequisite lands independently with focused regression tests and
+is included in the newly recorded baseline before extraction. Move commits
+preserve that corrected baseline. Review findings are not a reason to add a
+plugin system, second configuration inventory, or unrelated public API.
+
+## Risks and Mitigations
+
+### Scope expansion through generic extension points
+
+Moving concrete implementations can invite abstractions for hypothetical
+providers.
+
+Mitigation: add only capability contracts exercised by current code. External
+providers, non-OpenRTB factories, and additional lifecycle stages remain
+separate designs.
+
+### Configuration migration obscures the crate boundary
+
+Combining packaging and configuration work increases the number of affected
+files.
+
+Mitigation: keep the behavioral invariant explicit: configuration is
+normalized into the same core auction plan and registries. Use focused commits
+and parity tests around each boundary.
+
+### Ordering loss across serialization
+
+TOML order can be lost through unordered Rust maps or JSON objects.
+
+Mitigation: use ordered in-memory types, object-shaped stored configuration,
+and explicit order sidecars in the hash-verified blob. Enable
+`toml/preserve_order`, reject descendant-before-parent source declarations with
+the `toml_edit` pre-pass, and test the complete push/store/load path rather than
+only the TOML parser.
+
+### Binary and stored-config cutover drift
+
+An old binary cannot consume application schema 2, and a binary rollback after
+config cutover would otherwise fail at startup.
+
+Mitigation: use the adapter-specific version/store isolation table, archive a
+complete schema-one generation, deploy the dual reader before schema 2, fence
+old writers, prove the active binding and settings-dependent behavior, and
+remove the legacy reader only after every platform's rollback drill passes.
+
+### Configuration order silently changes auction priority
+
+Provider order affects launch budget, mediator input, response order, and equal
+price ties. Treating it as cosmetic would make operator edits surprising.
+
+Mitigation: define configuration order as operational priority, document the
+change from the baseline's lexical order, and test each observable consequence.
+
+### Hidden reverse dependencies
+
+Concrete integrations use core-private helpers and vendor-specific enum arms.
+
+Mitigation: move owned helpers outward, replace vendor matches with the narrow
+typed capability and prepared-exchange contracts, and review every new core
+public item.
+
+### Divergent validation paths
+
+CLI validation and adapter startup could use different catalogs or schemas.
+
+Mitigation: structural read-only commands use `SourceConfigView`; deploy
+commands and adapters share the complete secret-independent validation kernel;
+only adapter startup continues through resolved-secret construction. No
+secondary validation inventory is allowed. Adapters receive the settings,
+plan, orchestrator, registry, browser assets, target result, and digest rather
+than reconstructing them.
+
+### Stale or incorrectly ordered browser artifacts
+
+Splitting Rust ownership while sharing one Node workspace can embed previous
+output, race build scripts, or load APS too late.
+
+Mitigation: write each build directly into a private owner `$OUT_DIR`, serialize
+every installer and reader through the checked-in atomic-directory lease runner,
+configure every sibling-root resolver/tool explicitly, retain stale-output
+refusal, hash built bytes, load core and the creative prelude first, reject
+deferred APS composition, and run artifact-level renderer, fingerprint,
+version-skew, and ordering tests.
+
+## Acceptance Criteria
+
+The change is complete when:
+
+1. Both new crates are workspace members and statically linked by the CLI and
+   every adapter where required.
+2. All fifteen current concrete Rust implementation units live under
+   `trusted-server-integrations/src/integrations/<id>/`.
+3. The standard provider configuration is supplied by the built-in Rust-only
+   `openrtb` integration, making sixteen static definitions in total.
+4. All integration-owned browser sources, assets, unit/artifact fixtures, and
+   unit/artifact tests, including production executable inline programs, live
+   under `trusted-server-integrations-js`; cross-adapter system tests remain in
+   the integration-test crate.
+5. Rust definitions use one explicit compile-checked catalog with a directory
+   completeness test; browser modules remain directory-discovered.
+6. Core owns only neutral contracts and execution engines and imports no
+   concrete integration.
+7. One integration can register multiple typed capabilities; APS, Prebid, and
+   `adserver_mock` are not special construction paths.
+8. `[integrations]` is the only concrete integration and auction-provider
+   inventory.
+9. Configuration and provider ordering survive config push and runtime loading
+   through validated order sidecars and define the documented auction priority.
+10. The old `[auction.providers]`, `profile`, `profile_config`, and fixed
+    `protocol` fields are rejected with targeted migration guidance.
+11. The compiled auction plan retains current-baseline behavior after
+    schema-one normalization through an independent flat provider sequence;
+    schema 2 makes the explicit change from lexical to configuration-order
+    provider priority.
+12. Browser core imports no concrete integration, and APS rendering works
+    through one immediate registration without private copies in core, GPT, or
+    Prebid bundles; the shared-state facade adopts GPT bootstrap state, DOM
+    ownership is disjoint, composable handler registration obeys frozen legacy
+    order for schema 1 and configuration order for schema 2, and GPT retains its
+    synchronous-tag bootstrap contract. Facade versions have immutable
+    published IDL-derived ABI snapshots and pre-initializer mismatch guards.
+    The first-impression lifecycle remains one opaque core-owned service, and
+    queued callbacks drain through a CSP-compatible external finalizer after
+    synchronous GPT diagnostics on the success path with separate failure
+    fallbacks.
+13. `TrustedServerAppConfig`, `SourceConfigView`,
+    `PartialSourceConfigView<T>`, `ValidatedSourceConfig`, integration secret
+    handling, and final runtime composition are owned by
+    `trusted-server-integrations`; core has no concrete config or loader
+    dependency, the CLI has no duplicate integration schema, and the host-only
+    TOML pre-pass is feature-gated out of WASM graphs. EdgeZero's typed-config
+    source/command extension replaces filesystem snapshots and all EdgeZero
+    dependencies share its reviewed immutable revision.
+14. The CLI source phase and adapter runtime phase use the same catalog-backed
+    schemas and pure validation definitions, and all adapters receive one
+    post-secret-resolution
+    settings/plan/orchestrator/registry/browser-assets/target/digest
+    composition attempt plus the settings-only view captured after baseline
+    loader validation and preserved across later composition failures. Adapters
+    resolve the config location once; unavailable and corrupt data follow the
+    explicit adapter status matrix, including Fastly's intentional unavailable/
+    503 correction and `/health` liveness; fixed application routes are
+    hard-reserved in the shared claim routers and actual adapter router tables
+    are proven complete against those claims.
+15. OpenRTB request-local state crosses the transport boundary through a
+    prepared exchange-or-skip outcome and bound response parser without `Any`
+    or vendor enum variants in core; renderer descriptors retain their wire
+    shape through a neutral type.
+16. Explicit `enabled`, parent-before-descendant, disabled-retention, activation
+    matrix, local-ID, and qualified-ID rules have end-to-end tests, including a
+    server-only Prebid migration that does not activate browser behavior and
+    known-disabled reference pruning that acts as a kill switch.
+17. Schema-1 blobs remain readable for the documented rollout release, schema-2
+    blobs preserve existing secret paths, and binary rollback uses drill-tested
+    adapter-specific version/store isolation or verified restoration where
+    isolation is unavailable; Fastly verifies the exact old/new
+    service-version/store/root-key tuples and permits paired schema-one/schema-two
+    edits during its rollback window only through verified immutable roots and
+    matched service versions, otherwise keeping writes frozen; Cloudflare preserves and tests its outer
+    primary/legacy binding shape and keeps the rollback binding current or
+    writes frozen throughout the window; unsafe schema-2 pushes and old
+    schema-1 CLI writers are fenced, rollout observation is deterministic, and
+    stored-schema regression is monitored as a rollback event.
+18. Browser assets carry bytes and hashes through composition; the versioned,
+    unambiguously framed document fingerprint feeds the unambiguously framed
+    composition digest and is included once in publisher template fingerprints;
+    the artifact-specific build ID covers every reachable runtime workspace
+    crate, the selected adapter, OpenRTB, build-script inputs, and
+    `edgezero.toml` plus the actual compiler and effective flags; all existing
+    URL, host, scheme, origin, assembly, Vary,
+    cookie, and schema-version key dimensions remain; and request-dependent
+    variants bypass shared reuse.
+19. Core test support, the Fastly-SDK migration guard, Cargo aliases, CI,
+    Dependabot, repository automation, browser and cache smoke scripts,
+    documentation and snippet tests, and the CLI Prebid builder cover the new
+    crate boundaries, with a stale-path guard and a dedicated native
+    integrations-crate gate.
+20. Managed Prebid User IDs and external bundle bidder/User-ID/analytics
+    selection retain their current alias, collision, consent, manifest, hash,
+    SRI, and runtime-code behavior.
+21. Neutral OpenRTB-EID/EC ingestion, including opaque LiveRamp envelopes,
+    partner ingestion, and admin diagnostics, remains in core without creating
+    another integration definition or provider framework.
+22. Both milestone exit criteria and the full repository verification gates
+    pass.
+23. `ts config migrate --dry-run` produces a validated schema-2 candidate,
+    reports default normalization, environment-overlay renames, priority
+    changes across every comparable capability phase, unknown legacy tables,
+    and required manual decisions with stable exit semantics; discarding unknown
+    data requires an explicit per-ID option; interactive writes reject
+    intervening local edits, and migration never writes remotely.
+24. Reserved GPT-diagnostics inputs and malformed Cookie fields are normalized
+    on baseline routes even when diagnostics is absent or disabled.
+25. The adapter-specific rollout proves schema, physical binding, artifact, and
+    digest state through authenticated, unsampled unique-probe observation and
+    a configuration-dependent response predicate, with version/binding/envelope
+    evidence distinguishing behavior-equivalent generations, without adding
+    any new status endpoint; optional sampled/debug logs are not acceptance
+    evidence.
+26. The candidate release gate proves an authoritative live-environment
+    inventory/export bijection and runs the candidate catalog's pure claim
+    validation over each verified envelope without persisting or logging source
+    values; any missing environment or degraded result blocks promotion.
+27. The one browser lease has a non-deadlocking authenticated nested path and
+    cannot be reclaimed while a recorded child scope may survive; neutral and
+    integration owner manifests hash only their artifact-affecting inputs.
+28. Before implementation branches, the review checkpoint is replaced by the
+    final post-prerequisite `origin/main` commit, current-main delta contracts
+    and output goldens are captured, and every baseline-dependent inventory is
+    rechecked.
+
+## Deferred Work
+
+The following require separate designs and real consumers:
+
+- External vendor-owned crates or adapter-supplied registrations.
+- Runtime integration loading or a stable integration SDK.
+- Independent integration release and compatibility policies.
+- New identity, EC, geo, device, and permission-signal provider systems.
+- Permission and jurisdiction policy changes.
+- Non-OpenRTB auction provider factories.
+- Upstream EdgeZero composition and host-service changes beyond the narrow
+  typed-config source/command extension required above.
+- Moving CLI audit detection metadata into integration directories.