V48 (impl-only): Rename Packs→Exchange and AssetPack→DataPack UI

Move experience tree to components/exchange (Packs*→Exchange*), keep
/packs as compat redirect. Product copy and chrome use DataPack(s);
domain packages and wire type ids remain AssetPack for API stability.

Author: geraldarthurdavis

.docs/AGENTS.md

@@ -5,18 +5,18 @@
 - Never explicitly version source code without direct instruction. Source code is always implicitly versioned to the active Bitcode canon and current gate; routes, file names, CSS files, constants, classes, API paths, tests, and implementation identifiers must be written in-place as the single current Bitcode system. Do not introduce names such as `api/v1`, `v27-*`, `first-gate-*`, `wip-*`, or similar version/gate/work-in-progress source constructs unless explicitly directed for a bounded compatibility artifact.
 - Do not implement from historical/superseded materials. The monorepo no longer carries a `_legacy/` tree; living law is under `.specifications/` and current source only.
 - **Source layout and modularity (required):** follow `.docs/BITCODE_SOURCE_LAYOUT.md` and `apps/uapi/components/README.md`. Dependency direction is `packages` → Bitcode/Shadcn adapters → experience components → thin `apps/uapi/app` page shells. Seven experiences (Marketing, Exchange, Reads, Deposits, Docs, Conversations, Auxillaries) plus `Shadcn*` / `Bitcode*` bases. New components live in **named directories** (`ComponentName/ComponentName.tsx` — not `index.tsx`) with co-located `hooks/`, `styles/`, `__tests__/`. Prefer packages for pure domain logic. Product run language is **Pipeline** (UI/product); BTD ledger language is **journal**. Product routes are Exchange, Deposits, Reads, and Docs only.
-- **Product identity renames are totalistic (required learning):** when a **product experience name or route** changes (example: Packs → Exchange / `/packs` → `/exchange`), do **not** stop at nav labels, page chrome, or a single SSOT constant. Close the rename as one complete surface in the **same change set**:
+- **Product identity renames are totalistic (required learning):** when a **product experience name or route** changes (example: Packs → Exchange / `/exchange` → `/exchange`), do **not** stop at nav labels, page chrome, or a single SSOT constant. Close the rename as one complete surface in the **same change set**:
   1. **Canonical SSOT** — route constants, builders, overlays, post-auth landings, invite/callback redirects, deep-link hosts, workspace/nav surface unions and comparisons.
   2. **Compat is intentional and one-way** — retired paths may remain only as redirects/emitters that land on the **new** canon; never leave production redirects or primary assertions pointing at the old path.
   3. **Tests assert the new canon** — every expectation of the retired path is either updated to the new path or explicitly re-scoped as a **compat-only** case (and named as such). Grep the retired path/token across `apps/`, `packages/`, and `tests/` before calling the rename done.
   4. **Types must admit the new identity** — e.g. `NavSurface` / workspace unions must include the new surface or TS will green-wash dead comparisons and fail CI later.
   5. **Full living CI is the bar** — lint + `tsc` + Next build + **Jest** (not typecheck alone). Stale `/old-route` expectations are a rename bug, not “follow-up.”
-  Commodity language (e.g. **AssetPack**) is **not** a product route rename and must not be casually rewritten with the experience name. Partial renames that leave “remaining old paths” for CI to discover are poor development — treat them as incomplete work, not acceptable debt.
-- **Hierarchy naming law (required):** anything based on / extending / specializing a primitive must use **full ancestry names** left→right (primitive → base → specific) in **types, factories, exports, and file names**. Anything based on the **Execution** primitive must include `Execution` (e.g. `ExecutionPipeline`, `ExecutionPipelineSDIVFExecutionPhaseDelegator`, `ExecutionPipelineSDIVFSynthesizeReadAssetPacks`, `execution-pipeline-sdivf-factory.ts`). **Phases** are exclusively `ExecutionPipelineSDIVF` concepts (`ExecutionPipelineSDIVFExecutionPhase*`) under `generic-pipelines/execution-pipeline-sdivf`; `pipelines-generics` is primitives only. No leaf-only labels for layered types. See `.docs/BITCODE_SOURCE_LAYOUT.md` §6.0 and `.docs/FAMILIARIZATION.md` §3.3.
+  Commodity language (e.g. **DataPack**) is **not** a product route rename and must not be casually rewritten with the experience name. Partial renames that leave “remaining old paths” for CI to discover are poor development — treat them as incomplete work, not acceptable debt.
+- **Hierarchy naming law (required):** anything based on / extending / specializing a primitive must use **full ancestry names** left→right (primitive → base → specific) in **types, factories, exports, and file names**. Anything based on the **Execution** primitive must include `Execution` (e.g. `ExecutionPipeline`, `ExecutionPipelineSDIVFExecutionPhaseDelegator`, `ExecutionPipelineSDIVFSynthesizeReadDataPacks`, `execution-pipeline-sdivf-factory.ts`). **Phases** are exclusively `ExecutionPipelineSDIVF` concepts (`ExecutionPipelineSDIVFExecutionPhase*`) under `generic-pipelines/execution-pipeline-sdivf`; `pipelines-generics` is primitives only. No leaf-only labels for layered types. See `.docs/BITCODE_SOURCE_LAYOUT.md` §6.0 and `.docs/FAMILIARIZATION.md` §3.3.
 - **Codebase familiarization:** read `.docs/FAMILIARIZATION.md` for the package catalog, uapi request path, and the inheritance pattern `*-generics` primitives → `generic-*` base implementations → product specializations (agents, tools, pipelines, prompts, LLMs). **Keep `.docs/FAMILIARIZATION.md` up to date with changes** (`.specifications/BITCODE_SPECIFYING.md` §16.3.1): any change that moves package families, inheritance hierarchy, experience entry paths, product routes, or other structure the guide teaches must update `.docs/FAMILIARIZATION.md` in the same change set (accurate short section edits preferred).
 - Highest caliber software engineering crafstmanship (maintainibility, abstractions, architectures, naming, patterns, comments, documentation, structures, algorithmic and data flow designs, UI/UX, etc.), correctness (specification and implementation precision, reliability, completeness, boundaried, scoped, encapsulated, etc.), and auditable (totalistic proofs systems from static code, build time, runtime, etc. etc. as is Bitcode, tests from unit, integration, E2E, linting and building, etc.). Every non-trivial file carries a top-of-file overview comment; obey SRP and DRY; co-locate unit tests with components when practical.
 - Do not push work directly to `main`. Create a version base branch for each draft target, such as `version/v28`, then create scoped gate branches from that version branch. Gate branches must be prefixed with the gate number, such as `v28/gate-3-read-fit-workflow` or `v28/gate-8-promotion-proof`. Pull-request each closed gate back into the version branch. Pull-request the version branch into `main` only when all gates are closed and the version is formally promoted as canon. The default branch is protected by the `Bitcode Core Contributions` ruleset and requires pull requests plus verified signatures.
-- Gate pull request titles must begin with the uppercase version and gate prefix, followed by a concise topical title, for example `V29 Gate 5: AssetPack Disclosure Rights And Preview Depth`. Version-promotion pull requests must begin with the uppercase version and name canonical promotion.
+- Gate pull request titles must begin with the uppercase version and gate prefix, followed by a concise topical title, for example `V29 Gate 5: DataPack Disclosure Rights And Preview Depth`. Version-promotion pull requests must begin with the uppercase version and name canonical promotion.
 - Every commit and gate pull-request **subject line** must declare its Spec/Impl category as a short parenthetical immediately after the version and gate prefix — exactly one of **`(spec-only)`**, **`(impl-only)`**, or **`(spec-impl)`**. Spec and Impl are always abbreviated in that parenthetical; expanded forms are illegal in subjects:
   - `(spec-only)` — Spec only (`BITCODE_SPEC_*` family / version notes)
   - `(impl-only)` — Impl only (code, tests, tooling, scripts)

.docs/APPS.md

@@ -10,7 +10,7 @@ launch-freeze. Domain packages live under `packages/`. Engineering craft:
 [`.docs/AGENTS.md`](./AGENTS.md). Package map:
 [`.docs/FAMILIARIZATION.md`](./FAMILIARIZATION.md). Layout:
 [`.docs/BITCODE_SOURCE_LAYOUT.md`](./BITCODE_SOURCE_LAYOUT.md). Security:
-[`.docs/SECURITY.md`](./SECURITY.md). AssetPack measurement orientation:
+[`.docs/SECURITY.md`](./SECURITY.md). DataPack measurement orientation:
 [`.docs/ASSET_PACKS.md`](./ASSET_PACKS.md).
 
 ---
@@ -21,7 +21,7 @@ launch-freeze. Domain packages live under `packages/`. Engineering craft:
 | --- | --- |
 | Launch surface | Generally available **website MVP** on **staging-testnet** |
 | Settlement money | **BTC-testnet** only; value-bearing **mainnet blocked** until future canon |
-| Sellable unit | **AssetPack** = synthesized **patch + measurements + metadata** (never raw unpaid source) |
+| Sellable unit | **DataPack** = synthesized **patch + measurements + metadata** (never raw unpaid source) |
 | Product language | **Pipeline** = product runs; **journal** = BTD ledger language |
 | Source-safety | No protected/raw source, unpaid pack source, raw prompts/provider bodies, credentials, or private settlement payloads on product surfaces |
 | Identity | Wallet (Bitcoin OAuth / Auxillaries), Supabase session, GitHub App for source connections |
@@ -93,16 +93,16 @@ page client → page client; **never** packages → apps.
 | Route / surface | Owner | V48 commercial role |
 | --- | --- | --- |
 | `/` | Marketing | Landing / public launch messaging |
-| `/deposits` | Deposits | **IP seller:** connect source → **SynthesizeDepositAssetPacks (SDIVF)** → source-safe option review → Depository admission → compensation readback |
+| `/deposits` | Deposits | **IP seller:** connect source → **SynthesizeDepositDataPacks (SDIVF)** → source-safe option review → Depository admission → compensation readback |
 | `/reads` | Reads | **IP buyer:** Read Request → Need comprehension/resynthesis → Fits finding → source-safe preview → quote → **BTC-testnet settle** → BTD rights → delivery |
-| `/packs` | Packs | Searchable **PackActivity** master-detail (deposits, reads, previews, quotes, settlements, rights, delivery, compensation, repairs, proof roots, history) |
+| `/exchange` | Packs | Searchable **PackActivity** master-detail (deposits, reads, previews, quotes, settlements, rights, delivery, compensation, repairs, proof roots, history) |
 | `/docs` | Docs | Public product documentation |
 | Auxillaries | Auxillaries | Identity, org/teams, **wallet**, GitHub/externals, interfaces, histories |
 | Conversations | Conversations | Structure retained; **full commercial UX deferred** post-V48 |
 
 **Compatibility (not product homes):**
 
-- Legacy `/exchange` (and similar cockpit paths) route into **`/packs`**.
+- Legacy `/exchange` (and similar cockpit paths) route into **`/exchange`**.
 - Dead cockpit-only modules are deleted; do not rebuild Terminal or exchange
   cockpit as product.
 
@@ -116,17 +116,17 @@ callback, GitHub App install/callback). Settlement money is **BTC-testnet**.
 ```
 Depositor (/deposits)
   connect source + Obfuscations
-  → SynthesizeDepositAssetPacks (SDIVF)
+  → SynthesizeDepositDataPacks (SDIVF)
   → source-safe option select / admit to Depository
-  → /packs activity + compensation expectation
+  → /exchange activity + compensation expectation
 
 Reader (/reads)
   Read Request → Need → Fits
   → source-safe preview → quote
   → BTC-testnet settlement → BTD rights → delivery
-  → /packs activity
+  → /exchange activity
 
-Operator (Auxillaries + /packs)
+Operator (Auxillaries + /exchange)
   wallet / GitHub authenticity, histories, portfolio readback
 ```
 
@@ -142,9 +142,9 @@ V48 product pipelines that the website drives:
 
 | Pipeline | Pattern | Purpose |
 | --- | --- | --- |
-| **SynthesizeDepositAssetPacks** | **SDIVF** | Depositor repo (+ Obfuscations) → measured AssetPack **options** on `/deposits` |
-| **SynthesizeReadAssetPacks** | **SDIVF** | Reader repo + **Need** → option path on `/reads` |
-| **settle-asset-pack** (and related) | Linear / simple | Post-buy: BTC settle → BTD mint/rights → delivery; **1:1 AssetPack : run** where SPEC requires |
+| **SynthesizeDepositDataPacks** | **SDIVF** | Depositor repo (+ Obfuscations) → measured DataPack **options** on `/deposits` |
+| **SynthesizeReadDataPacks** | **SDIVF** | Reader repo + **Need** → option path on `/reads` |
+| **settle-asset-pack** (and related) | Linear / simple | Post-buy: BTC settle → BTD mint/rights → delivery; **1:1 DataPack : run** where SPEC requires |
 
 **SDIVF** = Setup → Discovery → Implementation → Validation → Finish — the
 **phased corridor** for synthesis pipelines (`packages/asset-packs-pipelines`).
@@ -244,5 +244,5 @@ source-safety or auth boundaries while they remain in-tree.
 
 ---
 
-**V48 website launch entrypoints:** `/deposits`, `/reads`, `/packs`, Auxillaries  
-**Settlement:** BTC-testnet · **Rights:** BTD · **Unit:** AssetPack · **Safety:** source-safe always
+**V48 website launch entrypoints:** `/deposits`, `/reads`, `/exchange`, Auxillaries  
+**Settlement:** BTC-testnet · **Rights:** BTD · **Unit:** DataPack · **Safety:** source-safe always

.docs/ASSETPACK_EXECUTION.md

@@ -1,36 +1,36 @@
-# Bitcode AssetPack Execution Notes
+# Bitcode DataPack Execution Notes
 
 Status: non-canonical internal note. Canonical requirements live only in `BITCODE_SPEC_V26.md` and its V26 companion proof/specification family after promotion.
 
 ## Purpose
 
-AssetPack execution is the retained implementation corridor that turns a measured and accepted Read into source-to-shares outputs.
+DataPack execution is the retained implementation corridor that turns a measured and accepted Read into source-to-shares outputs.
 
 The operator-facing product meaning is:
 - Bitcode gathers source, repository scope, attachments, and output destination intent.
 - Bitcode Exchange measures a Read from that evidence.
 - The measured Read is reviewable before fitting.
 - Accepted Reads can search for source-to-shares fit.
-- Implementation produces AssetPack synthesis artifacts and stored AssetPack evidence.
+- Implementation produces DataPack synthesis artifacts and stored DataPack evidence.
 - Finish saves the result and delivers the V26 Shippable through a GitHub pull request.
 
 ## Current Source Carriers
 
 - `apps/uapi/app/executions/*` remains a compatibility execution surface used by the Bitcode.
-- `packages/api/src/routes/shippables.ts` remains the main server execution route while its product meaning is AssetPack execution and PR Shippables.
-- `packages/asset-packs-pipelines/{domain,syntheses/domain,syntheses/deposit,syntheses/read,settle}` is the live layout for AssetPack pipelines (all-3 / both-synths / product co-location); the predecessor package path is no longer an active filesystem owner.
+- `packages/api/src/routes/shippables.ts` remains the main server execution route while its product meaning is DataPack execution and PR Shippables.
+- `packages/asset-packs-pipelines/{domain,syntheses/domain,syntheses/deposit,syntheses/read,settle}` is the live layout for DataPack pipelines (all-3 / both-synths / product co-location); the predecessor package path is no longer an active filesystem owner.
 - `packages/execution-generics/*`, `packages/pipelines-generics/*`, `packages/agent-generics/*`, and `packages/prompts/*` provide the reusable execution, registry, and prompt substrate.
 
-Storage-edge compatibility names are not product vocabulary. Any later SPEC promotion should describe the product as Bitcode Read measurement, fit review, AssetPack synthesis, Finish, and delivery mechanisms.
+Storage-edge compatibility names are not product vocabulary. Any later SPEC promotion should describe the product as Bitcode Read measurement, fit review, DataPack synthesis, Finish, and delivery mechanisms.
 
 ## Product Flow
 
 1. Source anchoring binds provider, repository, branch, commit, attachments, and operator intent.
 2. Read measurement synthesizes a reviewable Read from source evidence.
 3. Read review emits accept, reject, or remeasure-with-feedback state before fitting is admitted.
 4. Fit search ranks candidates with quantized objective qualities visible at review time.
-5. AssetPack synthesis produces code diffs, written assets, proofs, receipts, and settlement metadata.
-6. Finish saves the AssetPack result and calls delivery-mechanism tools only after validation.
+5. DataPack synthesis produces code diffs, written assets, proofs, receipts, and settlement metadata.
+6. Finish saves the DataPack result and calls delivery-mechanism tools only after validation.
 7. Packs and Exchange history reread the same execution, proof, and settlement state.
 
 ## V26 Boundaries
@@ -44,8 +44,8 @@ Storage-edge compatibility names are not product vocabulary. Any later SPEC prom
 ## SPEC Promotion Obligations
 
 When these notes are lifted into canonical specification, the SPEC must state:
-- AssetPacks are the stable output unit.
-- Delivery mechanisms are wrappers over stable AssetPacks, not the stable product object.
+- DataPacks are the stable output unit.
+- Delivery mechanisms are wrappers over stable DataPacks, not the stable product object.
 - Read review is mandatory before fit search.
 - Fit-quality receipts shown at present-fit-for-settlement-review time must be persisted into settlement evidence.
 - Finish is the canonical final SDIVF phase.