yadflow 4.0.0-next.3 → 4.0.0

package/skills/yad-connect-repos/references/{hub-config.md → product-config.md}

@@ -7,9 +7,17 @@ no roles, no commit emails (E62). It is a single object for the Product itself
 
 ## Location
 
-`{project-root}/.sdlc/hub.json`
-
-(`config.yaml` `product.config` (older projects: `hub.config`).) Created/updated by `yad-connect-repos action: detect-hub`.
+`{project-root}/.sdlc/product.json`, written together with its older name `{project-root}/.sdlc/hub.json`
+(E122). Read `product.json` first; read `hub.json` only on an older Product that has only that name.
+Every save writes both names with the same bytes, until v5 deletes `hub.json` (check gates an older
+yadflow installed read `hub.json` by path). If both exist and their bytes differ, every yad command but
+`yad doctor`, `yad migrate` and `yad report` refuses with `YAD-STATE-008`, and the CI gates FAIL;
+`yad migrate --apply` (or `--apply --keep product` / `--keep hub`) chooses the copy to keep. To edit a
+setting by hand, edit `product.json`, then run `yad migrate --apply --keep product` (it copies it over
+`hub.json`). A Product that has only `hub.json` has not been migrated: edit `hub.json`, and never create a
+`product.json` beside it by hand — `--keep product` would copy that one file over every other setting.
+
+(`config.yaml` `product.config` (older projects: `hub.config`).) Created/updated by `yad-connect-repos action: detect-product` (older name: `detect-hub`).
 
 ## Schema
 
@@ -27,7 +35,7 @@ no roles, no commit emails (E62). It is a single object for the Product itself
   "solo": false,                                              // SOLO MODE, and the one that decides: true waives the approval requirement on every review gate (the merge + resolved threads still gate). Set by `yad setup --solo` / `--team <n>` or `yad mode`
   "mode": "team",                                             // the roadmap's name for the same switch (E10): "solo" | "team", written beside `solo` by `yad mode` and `yad setup`. NOT read by the gates this major — `yad doctor` warns `mode:disagree` when it contradicts `solo`. Not the ledger switch: "verified mode" elsewhere means `ledger`
   "mode_set": { "from": "solo", "to": "team", "by": "al", "date": "2026-09-15", "reason": null }, // the last change of mode (E10): who, when, why. `yad mode solo` requires the reason
-  "detectedAt": "2026-06-08"                                  // last detect-hub run (YYYY-MM-DD)
+  "detectedAt": "2026-06-08"                                  // last detect-product run (YYYY-MM-DD)
 }
 ```
 
@@ -54,19 +62,19 @@ deletes them (`yad migrate`'s shape-3 step still adds a `product` role key besid
 an older project upgrades the same way it always did). `verified_authors` decides nothing — only `yad doctor`
 reads it, to warn. The roster is read for one thing only: its `name` →
 `login` pairs let a gate write record the login on older approval and comment records
-(`../../yad-hub-bridge/references/login-roster.md` → "Recording the login on older records"). `yad doctor`
+(`../../yad-product-bridge/references/login-roster.md` → "Recording the login on older records"). `yad doctor`
 warns `people:roster-unused` and `people:verified-authors-unused` so nobody edits them believing they decide
 something. Delete `verified_authors` when convenient; delete `roster` when `people:roster-unused` says it
-can go — no older record needs it any more, or only records it cannot place are left and their reviews are
+can go (edit the settings as the rule at the top of this page says) — no older record needs it any more, or only records it cannot place are left and their reviews are
 closed.
 
 ## Detection
 
-`detect-hub` reuses the same host-detection logic this skill already applies to code repos:
+`detect-product` reuses the same host-detection logic this skill already applies to code repos:
 run `git remote get-url origin` **on the Product itself** and read the host —
 `github.com` → `github`, `gitlab.com`/self-hosted GitLab → `gitlab`, no remote → `platform: null`.
 Auth is the **local user's own** `gh`/`glab`/git credentials; **no tokens are ever stored** (same rule
-as the registry). `detect-hub` upserts `hub.json` in place — it is idempotent and safe to re-run.
+as the registry). `detect-product` upserts the file in place: it writes `product.json`, then copies it byte for byte to `hub.json` (`cp`) — idempotent and safe to re-run.
 
 **`git_url` is required whenever `platform` is non-null.** `yad doctor` uses it to scope the auth
 probe to the Product's own host (an unscoped `glab auth status` fails on any unrelated broken instance),
@@ -90,7 +98,7 @@ Keep all three in step.
   review opens a PR/MR on the Product and `yad-review-gate action: sync` pulls platform state into the ledger.
 - `ledger: "local"`, `platform: null`, or no/unauthenticated CLI → the gate falls back to the
   existing **local** flow with no error. The file ledger is the source of truth in both modes.
-- The master switch `config.yaml` `product.bridge: false` (older projects: `hub.bridge`) disables the verified ledger globally regardless of `hub.json`.
+- The master switch `config.yaml` `product.bridge: false` (older projects: `hub.bridge`) disables the verified ledger globally regardless of `product.json`.
 
 ## Review Companion engagement (`review.requireEngagement`)
 
@@ -103,12 +111,12 @@ read the artifact. Applies to both the Shape gate and the Build engineer review.
 
 ## Git tracking
 
-Commit `hub.json` — it is small, reviewable, and carries no secrets or tokens. The only people data in it is the login or git name in `mode_set.by`, plus
+Commit `product.json` and `hub.json` together — it is small, reviewable, and carries no secrets or tokens. The only people data in it is the login or git name in `mode_set.by`, plus
 whatever an older `roster` still lists.
 This mirrors how `repos.json` and the per-epic `.sdlc/` state are committed.
 
 ## Greenfield
 
-A brand-new Product has no `hub.json`. That is valid — the Shape gate runs local until `detect-hub`
+A brand-new Product has no `product.json` (and no `hub.json`). That is valid — the Shape gate runs local until `detect-product`
 records a platform. The verified ledger is purely additive; nothing about authoring or the gate predicate changes.
 ```

package/skills/yad-connect-repos/references/repos-registry.md

@@ -54,7 +54,7 @@ not under any `epics/EP-<slug>/.sdlc/`.
 Commit the **registry** (`repos.json`) and each repo's **`code-map.md`** — they are small, reviewable,
 and are what the Shape phases actually read (a diff on a code-map shows when a repo's surface moved).
 `yad repo refresh --push` commits and pushes exactly these (never `pack.md`) to the Product's default
-branch as one `chore(hub): sync code-context … [skip ci]` audit commit.
+branch as one `chore(product): sync code-context … [skip ci]` audit commit.
 **Ignore** the full Repomix `pack.md` — it is large and regenerable (`action: refresh`). The Product
 's `.gitignore` carries `.sdlc/code-context/*/pack.md` for this. This mirrors how the per-epic
 `.sdlc/` state (state.json, approvals.json, build-log.json) is committed.

package/skills/yad-connect-testing/SKILL.md

@@ -26,7 +26,7 @@ connected, `yad-test-cases` runs artifacts-only exactly as before.
   same shape as the design tool's MCP, not Repomix's `npx`. The skill detects the MCP and degrades when
   it is absent; it never installs an MCP server.
 - Registry: `{project-root}/.sdlc/testing.json` (project-wide, shared across all epics — NOT per-epic),
-  the sibling of `.sdlc/repos.json`, `.sdlc/hub.json`, and `.sdlc/design.json`.
+  the sibling of `.sdlc/repos.json`, `.sdlc/product.json`, and `.sdlc/design.json`.
 - Per-epic test→suite links are written later by `yad-test-cases`
   (`epics/EP-<slug>/.sdlc/test-links.json`), not here.
 - Speak in the `communication_language` set in `{project-root}/.sdlc/config.yaml`; write documents in `document_output_language`.

package/skills/yad-connect-testing/references/testing-registry.md

@@ -46,7 +46,7 @@ root, not under any `epics/EP-<slug>/.sdlc/`.
 ## Git tracking
 
 Commit the **registry** (`testing.json`) — it is small, reviewable, and holds no secrets (references
-only). This mirrors how `repos.json`, `hub.json`, and `design.json` are committed.
+only). This mirrors how `repos.json`, `product.json`, and `design.json` are committed.
 
 ## Greenfield
 

package/skills/yad-discovery/SKILL.md

@@ -45,7 +45,7 @@ reserved `EP-discovery` epic; that older spelling is still read (see Step 1).
   - on a **verified** ledger CI owns that ledger and it cannot be moved by hand — keep working in
     `epics/EP-discovery/`, and review it with `yad gate open EP-discovery discovery/`.
 
-Detect the project mode from `{project-root}/.sdlc/hub.json` `profile.codebase`
+Detect the project mode from `{project-root}/.sdlc/product.json` (`.sdlc/hub.json` on an older Product that has only that name) `profile.codebase`
 (`greenfield` | `brownfield`, set by `yad setup`). If absent, ask the user; default `greenfield`.
 
 ### Step 2 — Shape with the field-expert lenses (assist: analyst + pm)
@@ -159,7 +159,7 @@ yad gate open EP-foundation foundation/
 the gate passes, the ledger moves to the `foundation-done` sentinel (not `ready-for-build` — the
 Foundation has no Build). From then on `foundation/roadmap.md` and `foundation/scope.md` are the inputs
 each `yad-epic` reads (its "Step 2c"). When the Product has a platform, the gate opens a review PR on the
-Product (via `yad-hub-bridge`) and `yad-review-gate action: sync` pulls platform approvals and comments
+Product (via `yad-product-bridge`) and `yad-review-gate action: sync` pulls platform approvals and comments
 into the ledger; otherwise the review is recorded locally.
 
 ## Reference

package/skills/yad-discovery/references/discovery-schema.md

@@ -15,7 +15,7 @@
 
 The project discovery phase ("epic zero") lives under `{project-root}/epics/EP-discovery/`. It reuses
 the per-epic ledger files (`.sdlc/state.json`, `approvals.json`, `comments.json`, `reviews/`,
-`hub-prs.json`) unchanged — `EP-discovery` is a valid epic id, so the existing gate, PR/MR bridge, CI
+`product-prs.json` + `hub-prs.json`) unchanged — `EP-discovery` is a valid epic id, so the existing gate, PR/MR bridge, CI
 sync, and `yad next` all operate on it. What is special is the `kind: "discovery"` marker on the state
 object and the 2-step chain.
 

package/skills/yad-docs/SKILL.md

@@ -88,7 +88,7 @@ Copy the shell from `templates/app/` **verbatim**, then:
 2. **Derive stakeholder roles** (`roles.ts`) from the yadflow lens set (analyst / pm / architect / ux /
    dev / tester / reviewer / engineer), kept only where the epic's artifacts give that lens something to
    read (which steps have artifacts, and the stories' `repos:` tags). No people or roles are read from
-   `.sdlc/hub.json` — yadflow keeps no list of people. Each role → its relevant doc `sectionIds` +
+   `.sdlc/product.json` — yadflow keeps no list of people. Each role → its relevant doc `sectionIds` +
    `relevantPathIds` (`references/data-mapping.md`).
 3. **Theme the `:root` block of `src/index.css`** from the design tokens, by the 4-tier priority in
    `references/theme-map.md`: **DESIGN.md → design.json/design-links.json palette → code-map tokens →

package/skills/yad-docs/references/data-mapping.md

@@ -54,7 +54,7 @@ contract is rendered exactly as locked — the docs are a *view* of the locked s
 
 A stakeholder role is generated for each lens that is **relevant to this epic** — that is, the epic's
 artifacts give the lens something to read. yadflow keeps no list of people, so no people or roles are
-read from `.sdlc/hub.json`.
+read from `.sdlc/product.json`.
 
 1. Start from the **yadflow lens set**: `analyst`, `pm`, `architect`, `ux`, `dev`, `tester`, `reviewer`,
    `engineer`.

package/skills/yad-docs/templates/app/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "yadflow-docs-site",
-  "version": "0.0.0",
+  "version": "0.0.2",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "yadflow-docs-site",
-      "version": "0.0.0",
+      "version": "0.0.2",
       "dependencies": {
         "framer-motion": "^12.34.4",
         "react": "^19.2.0",
@@ -1484,9 +1484,9 @@
       }
     },
     "node_modules/@typescript-eslint/typescript-estree/node_modules/brace-expansion": {
-      "version": "5.0.9",
-      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.9.tgz",
-      "integrity": "sha512-ScQ4IuvIEF1TMlP7Zt+vjJ//9zlPb2SDcxWxM3bk8s6t6GGdJ7KO1dCcTidOPJKePW30LE/2cT7wCyPho9/Wxg==",
+      "version": "5.0.12",
+      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.12.tgz",
+      "integrity": "sha512-YovQ3rzhaLMIrDjNDMkNS01tea93qhEhG5xy8f6+R0l+dw3Ki+5sCoIoI942iuLZTHWogWktgwVDhU09iNEimQ==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
@@ -1685,9 +1685,9 @@
       }
     },
     "node_modules/brace-expansion": {
-      "version": "1.1.18",
-      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.18.tgz",
-      "integrity": "sha512-Edep/X9fGqVNmzKBVsDYIOtD+z1tuezV70LBjdCst9Tqu76lsnvRiZ6oTic1n+/BIwX6QDGAO94PN4N2SADvtw==",
+      "version": "1.1.21",
+      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.21.tgz",
+      "integrity": "sha512-9zeA+KLZNNzglF2TPKRQEDyx6Yby7daAkuy8MiPzpXPsYDWi/DRM8jmwUDxokQjYqBpv5DgPiwD4h4ZZSy1Ujw==",
       "dev": true,
       "license": "MIT",
       "dependencies": {

package/skills/yad-docs/templates/app/package.json

@@ -1,7 +1,7 @@
 {
   "name": "yadflow-docs-site",
   "private": true,
-  "version": "0.0.0",
+  "version": "0.0.2",
   "type": "module",
   "scripts": {
     "dev": "vite",

package/skills/yad-docs/templates/app/src/components/Canvas/FlowCanvas.tsx

@@ -77,11 +77,11 @@ export const FlowCanvas: React.FC = () => {
 
   // Optional loop-back arc, swept below the canvas to read as "the pipeline repeats".
   // Rendered only when both endpoint nodes exist (e.g. the SDLC-overview's
-  // trust-log → product-hub cycle); a no-op for diagrams without them.
+  // trust-log → product cycle); a no-op for diagrams without them.
   const loopBack = useMemo(() => {
     if (dims.width === 0) return null;
     const a = COMPONENTS.find((c) => c.id === 'trust-log');
-    const b = COMPONENTS.find((c) => c.id === 'product-hub');
+    const b = COMPONENTS.find((c) => c.id === 'product');
     if (!a || !b) return null;
     const x1 = (a.position.x / 100) * dims.width;
     const y1 = (a.position.y / 100) * dims.height;

package/skills/yad-docs-overview/references/pipeline-model.md

@@ -26,7 +26,7 @@ and never gates.
 
 | Step (skill) | Outputs / sideEffects |
 |--------------|------------------------|
-| `yad-connect-repos` | `repos.json`, `code-context/<repo>/pack.md` + `code-map.md` (+ `detect-hub` → `hub.json`) |
+| `yad-connect-repos` | `repos.json`, `code-context/<repo>/pack.md` + `code-map.md` (+ `detect-product` → `product.json` + `hub.json`) |
 | `yad-connect-design` | `design.json` |
 | `yad-connect-testing` | `testing.json` |
 | `yad-connect-learning` | `learning.json` |
@@ -76,7 +76,7 @@ The gated authoring chain + the reusable review gate (10 steps, or 12 with the o
 | `yad-test-cases` | → `test-cases-review` (parallel, non-blocking) | `test-cases.md`, `test-links.json` |
 | `yad-review-gate` | the shared gate | `reviews/*.md`, `approvals.json`, `comments.json` |
 | `yad-review-companion` | the fun/visible review layer (trailer/cards/chat + engagement) | `approvals.json` `engagement`, platform trailer/cards |
-| `yad-hub-bridge` | the platform PR/MR bridge | `hub-prs.json` |
+| `yad-product-bridge` | the platform PR/MR bridge | `product-prs.json` + `hub-prs.json` |
 
 ### Path: Build (`phase: 3-build`)
 Per-story, per-repo: `spec → tasks → implement → checks → engineer-review`, plus the commit/PR helpers.
@@ -123,7 +123,7 @@ runs the sweep. The three thread gates ride in the Build `yad-checks` set above.
 ## System components = the durable state objects
 
 `components.ts` renders these on the canvas (deterministic positions): the **Product**; each
-`.sdlc/*.json` (`state.json`, `approvals.json`, `comments.json`, `hub.json`, `repos.json`, `design.json`,
+`.sdlc/*.json` (`state.json`, `approvals.json`, `comments.json`, `product.json`, `repos.json`, `design.json`,
 `testing.json`, `learning.json`, `docs.json`, `contract-lock.json`, `build-state/*`, `trust-log.json`,
 and the change-thread ledgers `change.json`, `reconcile-debt.json`, `build-log.json`);
 the **connected code repos**; the **design / testing / learning tools**; and the **platform**

package/skills/yad-engineer-review/SKILL.md

@@ -118,7 +118,7 @@ as one list: someone who has worked in ANY of them meets the ask. Nothing says w
 Record `engagement: verified` when the engineer reviewed through the companion (else `none` for a bare
 approve); `yad review reconcile --epic <id> --repo <r> --pr <n>` stamps it onto the ship record from the
 platform (mutating the ship's shard where it lives, or its folded entry if already tidied). Soft by default (both count; a bare approve draws `yad review nudge`); only gates when
-`hub.review.requireEngagement: true`. The signal is gameable by design and sits **beside** the CI gates,
+`review.requireEngagement: true` in the Product settings. The signal is gameable by design and sits **beside** the CI gates,
 never above them.
 Recording an approval does **not** ship — shipping is a separate, explicit step. Shape discipline:
 the gate talks only through files; refuse to treat AI review as a human approval.
@@ -153,7 +153,7 @@ engineer-review rule is satisfied (Step 2). Then:
   (it never weakens the merge gate — the engineer still owns the merge).
 - **Commit the machine-written ledgers.** Run `yad checkpoint --push` from `{project-root}` to commit
   the Build ledgers just written (the `build-log/` shard, and the `trust-log/` shard /
-  `build-state/<story>.json` if the story ran through `yad-run`) as one `chore(hub): …` audit-trail
+  `build-state/<story>.json` if the story ran through `yad-run`) as one `chore(product): …` audit-trail
   commit — default branch only, staging the shard dirs (`yad tidy up` folds finished shards later),
   never a Shape gate file. It is the Build analogue of the Shape `yad gate` sync. The
   same commit also **carries the story `status:` flip** you just wrote (`approved → in-build/shipped`,

package/skills/yad-engineer-review/references/ship-and-record.md

@@ -70,7 +70,7 @@ This is the Build analogue of Shape's `approvals.json` — files only, no hidden
 future service can drive ship by writing the same records. Like the trust log and build-state, it is a
 machine-written ledger committed by **`yad checkpoint`** (the Build analogue of `yad gate` sync),
 not by hand: after recording the ship, `yad checkpoint --push` lands the new `build-log/` shard as a
-`chore(hub): …` audit-trail commit on the default branch (allowlist-scoped to the Build ledgers,
+`chore(product): …` audit-trail commit on the default branch (allowlist-scoped to the Build ledgers,
 never a Shape gate file); `yad tidy up` folds finished shards into `build-log.json` later.
 
 ### Retroactive ship — a pre-tracking story (#142)
@@ -134,7 +134,7 @@ reclaimed after 30s, and a live one reports `YAD-STATE-006` rather than writing
 (`yad review trailer/context/nudge`, a real trailer/cards/chat session over the diff), `none` for a bare
 approve. The optional `companion` block records which faces ran. It is **soft by default** (both count;
 a bare approve draws a friendly `yad review nudge`); it only gates ship when
-`hub.review.requireEngagement: true`. `yad review reconcile --epic <id> --repo <r> --pr <n>` reads the
+`review.requireEngagement: true` in the Product settings. `yad review reconcile --epic <id> --repo <r> --pr <n>` reads the
 code PR's approvals (with the engagement signal) and stamps them onto the matching ship record — writing
 back into the ship's shard where it lives (or its folded entry if the story was already tidied) — the
 Build **bridge**, the analogue of `yad gate sync`. The signal is gameable by design ("visible, not
@@ -151,7 +151,7 @@ The story frontmatter `status` reflects build progress:
 - `shipped` — **every** task in `tasks.md` has a ship record.
 
 You write this flip into `stories/<story>.md`, but **do not hand-commit it** — the next
-`yad checkpoint --push` carries it in the same `chore(hub)` commit as the ledgers (the story now has a
+`yad checkpoint --push` carries it in the same `chore(product)` commit as the ledgers (the story now has a
 build-log ship, so checkpoint stages it; #112). This is what keeps the story artifact from drifting
 from the build ledger, so there is never a reason to fall back to a raw `git push origin main`.
 

package/skills/yad-epic/SKILL.md

@@ -19,7 +19,9 @@ drafted, control passes to `yad-review-gate`.
   inline with the analyst, assigns `EP-<slug>`, and seeds the **10-step** chain.
 
 This skill enforces the build plan's core rules: all state lives in files; IDs are generated by the
-engine (never typed by hand); Shape steps are locked to `advance: human`.
+engine (never typed by hand); every Shape step starts at `advance: human`. A review gate is always
+human; only the team can set a Shape author step to auto (`yad dial`, recorded in
+`.sdlc/automation.json`; nothing acts on it yet).
 
 ## Conventions
 
@@ -186,7 +188,7 @@ yad epic new EP-<slug> --profile chore    # the short upkeep lane — see below
 
 That writes `{project-root}/epics/EP-<slug>/.sdlc/state.json`, the empty `approvals.json` and
 `comments.json`, and the `reviews/` directory. Without `--profile` the chain is the full **10-step**
-`classic` route (no analysis). Every step is `advance: human` and locked; `epic` is open and the rest
+`classic` route (no analysis). Every step starts at `advance: human`; `epic` is open and the rest
 are blocked. The chain comes from the step catalogue and the lifecycle profile in the engine
 (`references/state-schema.md`), so there is one definition of it and no copy here to drift from it.
 
@@ -236,7 +238,7 @@ Notes:
 *(**Always run this**, on both entry modes. The chain is seeded by now either way — by `yad-analysis`,
 by `yad epic new` in Step 5, or by `yad epic new` before this skill was invoked — and `epic.md` is
 written. This is the step that closes the authoring step and opens its gate.)*
-**Check the mode first — the two modes have opposite instructions here.** Read `.sdlc/hub.json`:
+**Check the mode first — the two modes have opposite instructions here.** Read `.sdlc/product.json` (`.sdlc/hub.json` on an older Product that has only that name):
 **verified mode** is `platform` set AND `ledger: "verified"` — or, on a project that has not run `yad migrate` yet, `bridge_enabled` (or legacy `bridge`) `true`. `ledger` wins whenever it is present.
 
 **verified mode — do NOT write `state.json`.** The ledger is CI-owned: the `ledger-guard` check rejects
@@ -281,7 +283,7 @@ reviewers approve, through the gate.
 Report: epic ID, the path to `epic.md`, and that the next action is **review** via
 `yad-review-gate`. **Never mark the epic-review step approved here** — only real reviewers do that
 through the gate. Shape steps do not auto-advance. When the Product has a platform, the gate opens a review
-PR on the Product (via `yad-hub-bridge`) and `yad-review-gate action: sync` pulls platform approvals/
+PR on the Product (via `yad-product-bridge`) and `yad-review-gate action: sync` pulls platform approvals/
 comments into the ledger; otherwise the review is recorded local.
 
 ## Reference

package/skills/yad-epic/references/state-schema.md

@@ -28,8 +28,8 @@ Three rules go with it, and they are permanent (`docs/roadmap-idea-1.md`, Part 2
 1. **A file with no version counts as version 1.** Nothing has to be rewritten to be readable. Files
    written before the stamp existed are read as shape 1, and get the key the next time the engine
    writes them.
-2. **The list files never carry it.** `approvals.json`, `comments.json`, `hub-prs.json` (also written
-   as `product-prs.json`) and `reconcile-debt.json` are JSON arrays at the top level, and an array cannot hold a key. Rule 1
+2. **The list files never carry it.** `approvals.json`, `comments.json`, `product-prs.json` (also written
+   under its older name `hub-prs.json`) and `reconcile-debt.json` are JSON arrays at the top level, and an array cannot hold a key. Rule 1
    covers them: no version means version 1.
 3. **`schemaVersion` is not the CLI version.** `.sdlc/cli-version.json` records which release of the
    `yad` CLI set the project up, and changes on every release. `schemaVersion` describes the file's
@@ -206,7 +206,7 @@ A chain missing steps still matches — dropping `ui-design` is normal. An epic
 nothing gets NO `profile` key from the migration: inventing one would silence `step:off-route` by
 making the file agree with itself.
 
-> **Two different things are called a profile.** This one is the lifecycle route. `hub.json.profile` is
+> **Two different things are called a profile.** This one is the lifecycle route. `product.json.profile` is
 > the unrelated setup record `yad setup` writes: `{ codebase, repo_layout, team_size }`.
 
 ### The six phases
@@ -556,7 +556,7 @@ unchanged.)
 Each front **authoring** step opens its own git branch at the start of the step, named
 `<step>/EP-<slug>` where `<step>` ∈ `analysis | epic | architecture | ui-design | stories | test-cases`
 (`config.yaml` `defaults.shape_authoring_branch`). This is **distinct** from the review branch
-`review/EP-<slug>/<artifact-base>` that `yad-hub-bridge` opens later for the review PR/MR.
+`review/EP-<slug>/<artifact-base>` that `yad-product-bridge` opens later for the review PR/MR.
 
 The shared procedure (run once the `EP-<slug>` is known):
 1. **Git-safe / greenfield-safe:** if `{project-root}` is not a git work tree
@@ -596,10 +596,10 @@ name. The gate never reads the role. While the roster is on disk, the next sync
 `yad gate ci`) records the login on such an entry when the roster places it for certain, removes `role`
 and `domain`, and keeps the old name in `rosterName` (E64). Some entries are left as they are — a name two
 logins share, or several records that do not prove they are one review (most GitLab role records); see
-`yad-hub-bridge/references/login-roster.md`. The dated `approved.md` still prints the roles as recorded.
+`yad-product-bridge/references/login-roster.md`. The dated `approved.md` still prints the roles as recorded.
 
 `source: "bridge"` marks an approval synced from a Product review PR/MR by `yad-review-gate action: sync`
-(via `yad-hub-bridge`). Manual approvals omit `source` and are never altered by `sync`, except for the
+(via `yad-product-bridge`). Manual approvals omit `source` and are never altered by `sync`, except for the
 login recorded on an older entry (above). A manual approval written by `yad gate approve` (E112, a
 Product with no platform) carries `artifactHash`, so an edit to the artifact revokes it as it revokes a
 bridge approval; one written by hand before E112 has none, so an edit does not revoke it.
@@ -614,7 +614,7 @@ rather than *who approved*:
 | `pr` | the PR/MR number the approval arrived on. The second proof of a genuine re-approval, and the only one available on GitLab: a re-opened review is always a new PR, so an approval on a different number cannot be the old one re-read. Records written before this field existed are stamped once, from the `hub-prs.json` pointer they were recorded against. |
 | `commit`, `url`, `reviewId` | the platform's evidence for the review (E64): the commit it was given on, its link, and its node id. GitHub only, and only when the read gave them — never written `null`. An MR approval on GitLab is not tied to a commit, so none is recorded there. For the record only; the gate never reads them. |
 | `rosterName` | on an older entry whose login was recorded from the roster (E64), the name it had. The gate lets an exact submission time move such an entry to the person who really submitted that review. |
-| `engagement` | `verified` when the approval carried the companion's engagement marker, else `none`. Advisory unless `hub.review.requireEngagement` is on. |
+| `engagement` | `verified` when the approval carried the companion's engagement marker, else `none`. Advisory unless `review.requireEngagement` (Product settings) is on. |
 
 `date` is when the sync **recorded** the approval, not when it was given — it is preserved across an
 unchanged re-sync so that re-reading a review never churns the ledger.
@@ -632,7 +632,7 @@ Append-only ledger (an array), the machine-readable counterpart to the `reviews/
 written by `yad gate comment` (E112, no platform) also carries `artifactHash`, the fingerprint of the
 artifact its round was opened with (a late record joining the round carries the same one): a round is one version, so `--new-round` opens the next only after an edit. An older entry may still carry `role` and `domain`; the gate never reads them, and while the roster is on disk the next sync write records the login on it, keeping the old name in `rosterName` — unless two records in one round would then name the same login (E64).
 
-## `hub-prs.json`
+## `product-prs.json` (and `hub-prs.json`)
 Present only when the Shape review runs through the platform bridge. Per review step, the review
 PR/MR opened on the Product (sibling of `approvals.json`, so the locked `state.json` step shape is untouched):
 
@@ -640,8 +640,9 @@ PR/MR opened on the Product (sibling of `approvals.json`, so the locked `state.j
 { "step": "<review step id>", "artifact": "<artifact>", "platform": "github|gitlab", "number": <n>, "url": "<pr/mr url>", "branch": "review/EP-<slug>/<artifact-base>", "lastSyncedAt": "<YYYY-MM-DD or null>" }
 ```
 
-The same array is written under two names: `product-prs.json` (the name from shape 3) and `hub-prs.json`
-(the old name, kept for one major). `yad gate sync` may add `nudged`, the logins it has already asked to
+The same array is written under two names, with identical bytes: `product-prs.json` (the name from shape 3,
+read first) and `hub-prs.json` (the old name, written until v5 and read only when `product-prs.json` is
+absent — E122). `yad gate sync` may add `nudged`, the logins it has already asked to
 use the review companion, so it never asks them twice.
 
 ## `design-links.json`
@@ -693,10 +694,10 @@ whether to advance on its own. Two new files under `.sdlc/` do this.
 > **Who commits these.** `build-state/<story-id>.json`, `trust-log.json`, and `build-log.json` are
 > **machine-written** by Build (`yad-run`, `yad-engineer-review`) and committed by
 > **`yad checkpoint`** — the Build analogue of the Shape `yad gate ci` sync. It lands them as
-> one `chore(hub): sync Build state — <epic>/<story> by @<login>` audit-trail commit, on the
+> one `chore(product): sync Build state — <epic>/<story> by @<login>` audit-trail commit, on the
 > default branch, staging **only** these three ledgers by an explicit allowlist (never a Shape
 > gate file — `state/approvals/comments/product-prs/hub-prs.json`, `reviews/*.md` — so `ledger-guard` never trips).
-> Teammates don't review these machine writes; the commit exists so CI, `yad status`, and other
+> Teammates don't review these machine writes; the commit exists so CI, the `yad-status` skill, and other
 > machines always see current trust evidence.
 
 ## `build-state/<story-id>.json`

package/skills/yad-open-pr/SKILL.md

@@ -32,7 +32,7 @@ the Product.
     `pull_request_template.md`, so the Product `pr-template` gate passes.
   In a code repo nothing changes — it reads the repo's own committed code-task template.
 - **Base branch** — **resolved, never assumed.** In order: `--base` → the repo's `default_branch` in
-  `.sdlc/repos.json` → (for a PR against the Product itself) `hub.json`'s `default_branch` → what the
+  `.sdlc/repos.json` → (for a PR against the Product itself) `product.json`'s `default_branch` (`hub.json` on an older Product) → what the
   platform reports (`gh repo view --json defaultBranchRef` / `glab api projects/:id`) → local
   `origin/HEAD` → `main`. The same **configuration-outranks-the-remote** order `yad repo sync` and the
   contract-check gate already use (they stop at `origin/HEAD`; only this chain also asks the platform).

package/skills/yad-pair-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yad-pair-review
-description: 'The guided, two-way, teaching pair-review walkthrough for the SDLC review gates — the AI-driven companion face. The human opens a PR/MR with an AI session and the AI walks them through the change ONE STOP AT A TIME (highest-risk first), giving comprehensive context per change, then asking the human a Socratic question about it; the human answers and asks back, and both keep going until BOTH declare satisfied. The session doubles as a learning session: it demonstrates a transferable review method, scores the engineer against it, and records their review-skill growth in the local-only yad-learn ledger (rolled up by yad status). Works on the Build code PR/MR (yad review) and the Shape artifact-review PR/MR (yad gate). Soft and additive — it NEVER blocks a merge or gate; it rides the existing engagement signal and surfaces genuine concerns as normal blocking comments. Use when the user says "pair review this", "walk me through the PR/MR", "review with me", "co-review", or "teach me to review".'
+description: 'The guided, two-way, teaching pair-review walkthrough for the SDLC review gates — the AI-driven companion face. The human opens a PR/MR with an AI session and the AI walks them through the change ONE STOP AT A TIME (highest-risk first), giving comprehensive context per change, then asking the human a Socratic question about it; the human answers and asks back, and both keep going until BOTH declare satisfied. The session doubles as a learning session: it demonstrates a transferable review method, scores the engineer against it, and records their review-skill growth in the local-only yad-learn ledger (rolled up by the yad-status skill). Works on the Build code PR/MR (yad review) and the Shape artifact-review PR/MR (yad gate). Soft and additive — it NEVER blocks a merge or gate; it rides the existing engagement signal and surfaces genuine concerns as normal blocking comments. Use when the user says "pair review this", "walk me through the PR/MR", "review with me", "co-review", or "teach me to review".'
 ---
 
 # SDLC — Pair Review (the guided, two-way, teaching walkthrough)
@@ -99,7 +99,7 @@ addresses them) — nothing advances on a half-finished session.
 
 ### Step 5 — Record the session (twice) — see `references/session-state.md`
 1. **Session comment (PR/MR history).** Post one comment built by the CLI helper `pairSessionBody`
-   (carries `<!-- yad:pair -->` so `yad status` can count paired reviews, and `<!-- yad:noblock -->` so it
+   (carries `<!-- yad:pair -->` so the `yad-status` skill can count paired reviews, and `<!-- yad:noblock -->` so it
    never holds the gate): the transcript summary, the **review-skill scorecard**, your AI verdict, and
    both sign-offs. Post it with the platform CLI (`gh pr comment` / `glab mr note`).
 2. **Learning record (local-only).** Append a `yad-learn` record for the `member`: `concept` =
@@ -108,14 +108,14 @@ addresses them) — nothing advances on a half-finished session.
    comprehension), `comprehension` = the scorecard roll-up, `tutorial` = a rendered
    `learning/<member>--review-<pr>.md` capturing the method as applied to this PR + the engineer's gaps.
    **First ensure the Product `.gitignore` covers the learning paths** (reuse yad-learn's guard), then write —
-   these are personal, gitignored, **never committed or pushed**. The growth rolls up under `yad status`
-   "My skills".
+   these are personal, gitignored, **never committed or pushed**. The growth rolls up under the `yad-status`
+   skill's "My skills".
 
 ## Hard rules
 
 - **Never a gate.** This skill never moves `currentStep`, never records an approval on the human's
   behalf, and never merges. It enriches the input and rides the existing soft `engagement` signal only.
-  Strict mode (`hub.review.requireEngagement`) is the gate's switch, not this skill's.
+  Strict mode (`review.requireEngagement` (Product settings)) is the gate's switch, not this skill's.
 - **The CLI never calls an LLM.** The sequencer (`stops[]`) and the markers are deterministic; *you*
   generate every briefing, question, and answer. Same split as the companion.
 - **Grounded only in real material.** Briefings/answers come from the diff + artifact + contract +

package/skills/yad-pair-review/references/session-state.md

@@ -8,7 +8,7 @@ of which ever blocks the gate. The gate's predicate (approvals + resolved thread
 Built by the CLI helper `pairSessionBody({ summary, scorecard, verdict, humanSignoff, aiSignoff })` in
 `cli/companion.mjs`. It carries **both** markers:
 
-- `<!-- yad:pair -->` — so this is countable as a *paired review* in the `yad status` 🏆 roll-up.
+- `<!-- yad:pair -->` — so this is countable as a *paired review* in the `yad-status` skill's 🏆 roll-up.
 - `<!-- yad:noblock -->` — so the thread is excluded from the gate's blocking check and persists as
   permanent history (a deliberate, unresolved trail), exactly like the companion's card/chat threads.
 
@@ -71,7 +71,7 @@ Field notes:
 Also render the tutorial artifact `epics/EP-<slug>/learning/<member>--review-<pr>.md` (front-matter:
 `member`, `concept`, `stage`, `tool`, `requestedAt`) — the review method as applied to *this* PR plus the
 engineer's specific gaps and how to close them. Both files are **local-only, gitignored, never committed
-or pushed, and never written into a code repo** — they are a private personal skills log. `yad status`
+or pushed, and never written into a code repo** — they are a private personal skills log. The `yad-status` skill
 rolls them up by stage (e.g. "engineer-review: 3").
 
 ## Optional: stamp the build-log (Build)

package/skills/yad-pr-template/SKILL.md

@@ -23,21 +23,21 @@ routing helper.
   - `templates/gitlab/merge_request_templates/Default.md` → installs to
     `<repo>/.gitlab/merge_request_templates/Default.md`
   - `templates/checks/risk-route.sh` → installs to `<repo>/checks/risk-route.sh` (advisory routing helper)
-  - **Product variants** (`repo: hub`) — Shape artifact-review PR/MR bodies:
-    `templates/hub/github/pull_request_template.md` → `{project-root}/.github/pull_request_template.md`;
-    `templates/hub/gitlab/merge_request_templates/Default.md` →
+  - **Product variants** (`repo: product`) — Shape artifact-review PR/MR bodies:
+    `templates/product/github/pull_request_template.md` → `{project-root}/.github/pull_request_template.md`;
+    `templates/product/gitlab/merge_request_templates/Default.md` →
     `{project-root}/.gitlab/merge_request_templates/Default.md`. The Product body carries no `Task:` trailer
-    (Product PRs change artifacts, not code); its routing helper is `yad-hub-bridge`'s
-    `templates/checks/hub-route.sh`, run from the skill (nothing installs it into the Product's `checks/`).
+    (Product PRs change artifacts, not code); its routing helper is `yad-product-bridge`'s
+    `templates/checks/product-route.sh`, run from the skill (nothing installs it into the Product's `checks/`).
 - **GitLab reads a truncated description.** The `pr-template` gate is fed
   `$CI_MERGE_REQUEST_DESCRIPTION`, which GitLab cuts at **2700 characters** — a required section below
   that cutoff is invisible to the gate even though the MR shows it, and the failure reads "does not use
   the template" (#164). Both GitLab templates say so in a comment and keep `## Summary` /
-  `## Impact & Risk` / `## Checklist` (hub: `## Artifact under review` / `## Impact & Risk (front-half)`
+  `## Impact & Risk` / `## Checklist` (Product: `## Artifact under review` / `## Impact & Risk (front-half)`
   / `## Checklist`) early, so a truncated body still passes. Long narrative goes **after** them.
   Sections may be reordered freely; deleting one fails the gate. GitHub is unaffected.
 - **Installed code-repo templates are yad-managed.** `yad update` rewrites them on upgrade (the Product
-  variants under `templates/hub/` are copied by hand in Step 2 and are not managed). An edit yad can
+  variants under `templates/product/` are copied by hand in Step 2 and are not managed). An edit yad can
   prove — the file's sha differs from the one it recorded when it wrote the template — is reported as
   `modified` and left alone; a copy it has no record of is replaced after a `.yad-orig` backup (see
   `docs/CLI.md` → *Managed files*). Either way, put knowledge that must survive an upgrade in an ADR
@@ -54,7 +54,8 @@ routing helper.
 
 ## Inputs
 
-- `repo`   — the code repo to add the template to (one of an epic's repos), or `hub` for the Product.
+- `repo`   — the code repo to add the template to (one of an epic's repos), or `product` for the Product (`hub`, the old name, still works). A code repo that is itself named
+  `product`: give its registered path instead (for example `repos/product`), so it is not taken for the Product.
 - `action` — `wire` (commit the matching template + helper) | `route` (print the approver count from a
   PR body). Default `wire`.
 - `body`   — for `route`: a file holding the PR/MR description to evaluate.
@@ -62,17 +63,18 @@ routing helper.
 ## On Activation
 
 ### Step 1 — Resolve the repo and detect the platform
-Map `repo` → `{project-root}/demo-repos/<repo>/` (or the registry `path`). Detect the platform: a GitHub
+Map `repo` → `{project-root}/demo-repos/<repo>/` (or the registry `path`). A `repo` value with a `/` in it is a registry `path`, not a name: match it against each entry's `path`
+(so a code repo named `product` is reached as, for example, `repos/product`). Detect the platform: a GitHub
 remote or `.github/` → GitHub; a GitLab remote or `.gitlab/` → GitLab. If ambiguous, ask. For
-`repo: hub`, the target is `{project-root}` itself and the platform comes from `.sdlc/hub.json`.
+`repo: product`, the target is `{project-root}` itself and the platform comes from `.sdlc/product.json` (`.sdlc/hub.json` on an older Product that has only that name).
 
 ### Step 2 — `wire` (drop only the matching template)
 Copy from this skill's `templates/`:
 - GitHub → `templates/github/pull_request_template.md` to `<repo>/.github/pull_request_template.md`.
 - GitLab → `templates/gitlab/merge_request_templates/Default.md` to
   `<repo>/.gitlab/merge_request_templates/Default.md`.
-- **`repo: hub`** → use the `templates/hub/<platform>/…` variants, installed into `{project-root}`'s own
-  `.github/`/`.gitlab/`. The Product's routing helper (`hub-route.sh`) stays in `yad-hub-bridge`'s
+- **`repo: product`** → use the `templates/product/<platform>/…` variants, installed into `{project-root}`'s own
+  `.github/`/`.gitlab/`. The Product's routing helper (`product-route.sh`) stays in `yad-product-bridge`'s
   `templates/checks/`; neither this skill nor `yad setup` / `yad check --fix` installs it.
 Drop **only the matching** template (drop both only if the repo genuinely uses both). For code repos also
 install `templates/checks/risk-route.sh` to `<repo>/checks/` (`chmod +x`), beside