V48 (spec-only): Align V48 notes and roadmap with product surfaces

Record product-route language and MCP/product posture in the draft V48 specification family and roadmap without reintroducing Terminal product surfaces.

Author: geraldarthurdavis

specifications/BITCODE_SPECIFYING.md

@@ -28,7 +28,7 @@ Bitcode specifying exists so a correct implementation, audit, generated proof ap
 
 From V26 onward, that derivability requirement explicitly includes both:
 - Bitcode as protocol and canonical market semantics,
-- and Bitcode as formal product implementation surfaces when those surfaces are admitted canon, such as Bitcode Exchange, Bitcode Terminal, canonical APIs, Bitcode MCP, and other admitted interface families.
+- and Bitcode as formal product implementation surfaces when those surfaces are admitted canon, such as Bitcode Exchange, Bitcode, canonical APIs, Bitcode MCP, and other admitted interface families.
 
 The central rule is:
 
@@ -462,7 +462,7 @@ Stale status language is a canonical defect.
    - the hand-authored family (`BITCODE_SPEC_VN.md`, `NOTES`, `DELTA`, `PARITY_MATRIX` as promoted),
    - generated `BITCODE_SPEC_VN_PROVEN.md` and `.bitcode/vN-*` structured artifacts for that promotion,
    - version-bound gate checkers, package proof generators, and tests that attest **that era's** predicates against **that era's** source and route vocabulary.
-2. **Old version checks must never be edited** to chase later renames, package hierarchy moves, route pluralization, Terminal retirement, component layout moves, vocabulary renames, or sole-canon modularization of a future draft.
+2. **Old version checks must never be edited** to chase later renames, package hierarchy moves, route pluralization, product retirement, component layout moves, vocabulary renames, or sole-canon modularization of a future draft.
 3. **Historical promoted specs remain referenceable as canon-at-that-time.** Auditors, PROPER reconstructions, and provenance citations use them as fixed law for the era they closed — not as living code maps of the current tree.
 4. **The living full-system check is only for current canon** (the draft-target family while drafting, then the newly pointed family after promotion). That check must be:
    - all-encompassing (full-system, full re-implementability, full auditability — §2),
@@ -477,7 +477,7 @@ Stale status language is a canonical defect.
 
 ### Why this exists
 
-Bitcode treats each promotion as a closed ledger entry of system law. If V43–V47 checks were rewritten every time V48 moved `/read`→`/reads` or retired Terminal, "canon at V47" would cease to exist as an auditable artifact. Era-pinning preserves that ledger without blocking the living draft's obligation to be total and true.
+Bitcode treats each promotion as a closed ledger entry of system law. If V43–V47 checks were rewritten every time V48 moved `/read`→`/reads` or retired product, "canon at V47" would cease to exist as an auditable artifact. Era-pinning preserves that ledger without blocking the living draft's obligation to be total and true.
 
 ### Relation to drafting
 
@@ -1297,7 +1297,7 @@ Adjunct realization docs define:
 
 A demo or adjunct implementation may realize canon.
 An adjunct realization must not silently define canon.
-A formal implementation surface such as Bitcode Exchange, Bitcode Terminal, canonical APIs, or Bitcode MCP may be both implementation and canon when the active `SPEC` admits it as such.
+A formal implementation surface such as Bitcode Exchange, Bitcode, canonical APIs, or Bitcode MCP may be both implementation and canon when the active `SPEC` admits it as such.
 
 If current source only exists under a demo directory, the spec must still distinguish:
 - current implementation location,
@@ -1356,7 +1356,7 @@ They should identify:
 - function or builder,
 - generated output path,
 - test entrypoint,
-- and whether the surface is protocol, Exchange, Terminal, API, MCP, third-party interface, adjunct realization, generated, or operator-facing.
+- and whether the surface is protocol, Exchange, product, API, MCP, third-party interface, adjunct realization, generated, or operator-facing.
 
 ## 16.3 Code Documentation Patterns
 

specifications/BITCODE_SPEC_V48.md

@@ -126,7 +126,7 @@ Goals:
 - Audit feature excess and defer or flag anything that distracts from launch.
 - Treat `/deposits`, `/reads`, and `/packs` as the website launch entrypoints;
   route `/exchange` compatibility into `/packs`; eradicate the legacy
-  `/terminal` cockpit as a product surface (compatibility redirect only during
+  `/packs` cockpit as a product surface (compatibility redirect only during
   migration); keep full Conversations commercialization, API/MCP, ChatGPT App,
   Bitcode Chat, value-bearing mainnet, and advanced market mechanics out of the
   launch path unless a later gate explicitly reopens them.
@@ -205,17 +205,17 @@ Naming law (types, classes, files, functions, variables — not only components)
 - **Execution** as a product UI name is retired in favor of Pipeline. Low-level
   agent/executor packages (`execution-generics`, PTRR executor primitives) are
   not product Pipeline surfaces and are not blindly renamed.
-- **Terminal** as a product surface name is eradicated. Live capabilities that
-  still live under `apps/uapi/app/terminal/` must relocate into Bitcode or the
-  owning experience; dead cockpit-only modules are deleted. `/terminal` may
+- **product** as a product surface name is eradicated. Live capabilities that
+  still live under `apps/uapi/app/ (removed cockpit tree) ` must relocate into Bitcode or the
+  owning experience; dead cockpit-only modules are deleted. `/packs` may
   remain only as a compatibility redirect (default `/packs`) during migration.
 - HTTP paths under `/api/executions/*` may remain stable during rename waves;
   internal TypeScript modules and UI labels move to Pipeline first.
 
 Package law: generalizable non-React domain logic belongs in `packages/`;
 uapi holds Next routes, React, and thin adapters. Shareable pure models that
-leave Terminal must land in packages or `components/bitcode` models — not
-remain under a Terminal path.
+leave product must land in packages or `components/bitcode` models — not
+remain under a product path.
 
 God-client modularization law (Phase 4, active on `version/v48`):
 
@@ -229,18 +229,18 @@ God-client modularization law (Phase 4, active on `version/v48`):
 - Unit tests for pure deposit models register under `apps/uapi/tests/` (and
   `apps/uapi/jest.config.cjs` testMatch) so CI proves modular projections.
 
-### Legacy Terminal eradication completion condition
+### Legacy cockpit eradication completion condition
 
-Terminal eradication is complete when:
+cockpit eradication is complete when:
 
-1. `apps/uapi/app/terminal/` does not exist.
-2. `/terminal` is not a route (no page, no redirect) and is not a nav/login CTA.
+1. `apps/uapi/app/ (removed cockpit tree) ` does not exist.
+2. `/packs` is not a route (no page, no redirect) and is not a nav/login CTA.
 3. Shared pipeline selection, history, repository context, and readiness
-   models live under Bitcode/experience names without `Terminal*` prefixes.
+   models live under Bitcode/experience names without `product*` prefixes.
 4. Browser proofs and commercial E2E remain on `/deposits`, `/reads`, `/packs`,
-   and Auxillaries — never requiring the Terminal cockpit.
-5. BTD journal and operational-health packages use non-Terminal names
-   (`journal`, `operational-health`), with temporary Terminal aliases only
+   and Auxillaries — never requiring the product cockpit.
+5. BTD journal and operational-health packages use non-product names
+   (`journal`, `operational-health`), with temporary product aliases only
    while callers migrate.
 
 ## V48 canonical domain model
@@ -1828,19 +1828,19 @@ draft V48, and the gate branch is committed, pushed, and pull-requested into
 V48 Gate 2 is complete when launch-facing entrypoints resolve to `/deposits`,
 `/reads`, and `/packs`; old `/exchange` entrypoints are compatibility redirects
 or rewritten into `/packs`; BTD acquisition and detail paths no longer send
-users to `/terminal` or `/exchange`; `/terminal` is not a launch CTA and is
+users to `/packs` or `/exchange`; `/packs` is not a launch CTA and is
 scheduled for eradication (compatibility redirect only); Conversations full
 commercial experience remains deferred while structure may persist; API/MCP,
 ChatGPT App, Bitcode Chat, value-bearing mainnet, source-bearing previews, and
 advanced market mechanics are explicitly deferred; `.bitcode/v48-feature-excess-
 alignment-audit.json` is generated; `check:v48-gate2` validates the audit; and
 gate/canon workflows run the Gate 2 checker under promoted V48 canon.
 
-V48 frontend component architecture and Terminal eradication (implementation
+V48 frontend component architecture and cockpit eradication (implementation
 quality workstream on `version/v48`, not a separate product gate number) is
 complete when the three-layer / seven-experience component law above is
-realized in source, live modules no longer import `apps/uapi/app/terminal/`, product
-Pipeline naming replaces Execution/Terminal UI names, generalizable utilities
+realized in source, live modules no longer import `apps/uapi/app/ (removed cockpit tree) `, product
+Pipeline naming replaces Execution/product UI names, generalizable utilities
 prefer packages, and parity matrix rows for this workstream are closed.
 
 V48 Gate 3 is complete when the IP seller state machine covers source

specifications/BITCODE_SPEC_V48_DELTA.md

@@ -49,8 +49,8 @@ and validate the website E2E.
   `version/v48`):** three layers (`Shadcn*` → `Bitcode*` → seven experiences),
   components under `apps/uapi/components/{shadcn,bitcode,marketing,packs,reads,
   deposits,docs,conversations,auxillaries}`, Pipeline product naming over
-  Execution/Terminal UI names, generalizable utilities package-first, legacy
-  `/terminal` eradicated (deleted). Spec updates and implementation land
+  Execution/product UI names, generalizable utilities package-first, legacy
+  `/packs` eradicated (deleted). Spec updates and implementation land
   together as `(spec-impl)` commits.
 - **Deposit + Packs modularization (Phase 4 continue):** pure deposit models
   (activity ledger, demand, criticality, route-input builder, run status) and
@@ -124,7 +124,7 @@ Gate 2 owns `.bitcode/v48-feature-excess-alignment-audit.json`,
 `buildV48FeatureExcessAlignmentAudit`, and `check:v48-gate2`. The audit
 classifies `/deposits`, `/reads`, and `/packs` as launch routes; `/docs`,
 Auxillaries, `/btd/[assetPackId]`, execution readback, and required APIs as
-supporting surfaces; and `/terminal` direct product entry, `/conversations`
+supporting surfaces; and `/packs` direct product entry, `/conversations`
 direct commercial launch, `/exchange` direct product entry, `/orbitals`,
 `/edgetimes`, `/demo-video`, API/MCP commercialization, ChatGPT App
 commercialization, Bitcode Chat commercialization, value-bearing mainnet, and