yadflow 3.18.1 → 4.0.0-next.1

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

@@ -1,6 +1,6 @@
 # Design registry — schema + freshness rule
 
-The registry is the product hub's record of which design tool is connected and how to reach it. It is
+The registry is the Product's record of which design tool is connected and how to reach it. It is
 **project-wide** (one design tool per project, shared across every epic), so it lives at the product
 root, not under any `epics/EP-<slug>/.sdlc/`.
 
@@ -51,6 +51,6 @@ only). This mirrors how `repos.json` and `hub.json` are committed.
 
 ## Greenfield
 
-A brand-new product hub has no `design.json`. That is valid — `yad-ui` treats "no design tool connected"
+A brand-new Product has no `design.json`. That is valid — `yad-ui` treats "no design tool connected"
 the same as `tool: "none"` and produces the Markdown artifacts only. The registry appears the first time
 `connect` runs.

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

@@ -1,16 +1,16 @@
 ---
 name: yad-connect-docs
-description: 'Connects a docs/Pages publishing target to the product hub so the interactive-docs steps can build and deploy the generated SPA — not just commit its source. Registers the target into the project-wide .sdlc/docs.json (GitHub Pages / GitLab Pages / build-only), auto-detecting the platform from .sdlc/hub.json and resolving the Vite base path, with local-user auth and no stored tokens. Detects whether gh/glab is present and degrades to build-only when absent. Run at setup or any time the publish target changes. Reusable, idempotent, refreshable. Use when the user says "connect docs", "connect Pages", "refresh the docs connection", or "list the docs connection".'
+description: 'Connects a docs/Pages publishing target to the Product so the interactive-docs steps can build and deploy the generated SPA — not just commit its source. Registers the target into the project-wide .sdlc/docs.json (GitHub Pages / GitLab Pages / build-only), auto-detecting the platform from .sdlc/hub.json and resolving the Vite base path, with local-user auth and no stored tokens. Detects whether gh/glab is present and degrades to build-only when absent. Run at setup or any time the publish target changes. Reusable, idempotent, refreshable. Use when the user says "connect docs", "connect Pages", "refresh the docs connection", or "list the docs connection".'
 ---
 
 # SDLC — Connect a Docs/Pages Target (make the docs steps publishable)
 
 **Goal:** Let the interactive-docs steps (`yad-docs` per epic, `yad-docs-overview` project-wide)
 **build and deploy** the generated React/Vite SPA to a real URL — a GitHub Pages or GitLab Pages site —
-instead of only committing its source. This skill **connects** a publishing target to the product hub
+instead of only committing its source. This skill **connects** a publishing target to the Product
 and records *how* to reach it (the platform, the publish scope, the base path) — never a credential.
 
-This is **setup/maintenance**, not a gated front state — it never touches `.sdlc/state.json` or any
+This is **setup/maintenance**, not a gated Shape step — it never touches `.sdlc/state.json` or any
 epic's approvals. It only writes the project-wide docs registry. `yad-docs` / `yad-docs-overview`
 consume it: when a target is connected, they theme + generate the site and drive `yad docs deploy`;
 when nothing is connected (`target: "none"`), they still generate and **npm-build** the site but stop
@@ -18,9 +18,9 @@ at a local `dist/` — build-only, no publish, exactly as before.
 
 ## Conventions
 
-- `{project-root}` resolves from the project working directory (the **product hub**).
+- `{project-root}` resolves from the project working directory (the **Product**).
 - The target is **GitHub-Pages-first but pluggable** — a *publish adapter*, mirroring the GitHub/GitLab
-  platform adapter the hub already uses. `github-pages` and `gitlab-pages` are the providers; `none` →
+  platform adapter the Product already uses. `github-pages` and `gitlab-pages` are the providers; `none` →
   build-only (deliberate, no error).
 - The platform CLI (`gh` / `glab`) is a **subprocess**, used read/deploy-only via the user's own auth —
   never installed by this skill, never given a token. Absent ⇒ degrade to build-only (`source:
@@ -29,15 +29,15 @@ at a local `dist/` — build-only, no publish, exactly as before.
   NOT per-epic), the sibling of `.sdlc/hub.json`, `.sdlc/repos.json`, and `.sdlc/design.json`.
 - Per-epic / overview build manifests (`docs-build.json`) are written later by `yad-docs` /
   `yad-docs-overview`, not here. This skill describes the *connection*; it does not build.
-- Speak in the configured `communication_language`; write documents in `document_output_language`.
+- Speak in the `communication_language` set in `{project-root}/.sdlc/config.yaml`; write documents in `document_output_language`.
 
 ## Inputs
 
 - `action` — `connect` (default) | `refresh` | `list` | `disconnect`.
 - `target` — `github-pages` | `gitlab-pages` | `none`. Default **auto-detected** from `.sdlc/hub.json`
-  `platform` (github → `github-pages`, gitlab → `gitlab-pages`, null/no hub → `none`).
+  `platform` (github → `github-pages`, gitlab → `gitlab-pages`, null/no Product → `none`).
 - `scope` — `hub` (default) | `<repo-name>` | `dedicated`. Where the Pages site is published from (the
-  hub repo, one connected code repo, or a dedicated docs repo).
+  Product repo, one connected code repo, or a dedicated docs repo).
 - `public` — `true` (default) | `false`. Whether the published site is public.
 - `base_path` — optional explicit override of the Vite `base` (otherwise resolved, Step 2).
 
@@ -45,7 +45,7 @@ at a local `dist/` — build-only, no publish, exactly as before.
 
 ### Step 1 — Resolve the target + detect the platform (the publish adapter)
 Determine the `target`. If not given, read `{project-root}/.sdlc/hub.json` `platform` and map it the same
-way the hub bridge maps repos: `github` → `github-pages`, `gitlab` → `gitlab-pages`, `null`/no hub →
+way the Product bridge maps repos: `github` → `github-pages`, `gitlab` → `gitlab-pages`, `null`/no Product →
 `none` (deliberate build-only). Reject a `target` value outside the three providers (fall back to the
 detected default with a warning, the way `registerRepo` falls back on an unknown platform).
 
@@ -61,7 +61,7 @@ tokens**; everything in the registry is a plain reference. Do **not** install a
 
 ### Step 2 — Decide the publish scope + resolve the base path
 Resolve `scope` → `publishRepo`:
-- `hub` (default) → publish from the hub repo (read its name from `hub.json` `git_url`).
+- `hub` (default) → publish from the Product repo (read its name from `hub.json` `git_url`).
 - `<repo-name>` → publish from that connected code repo (must exist in `.sdlc/repos.json`).
 - `dedicated` → a dedicated docs repo the user names (recorded as `publishRepo`).
 
@@ -109,7 +109,7 @@ the site here — `yad-docs` builds.**
   **available/unavailable** flag for the platform CLI (best-effort, the user's own session). No target
   connected ⇒ "build-only".
 - **`disconnect`** — remove the registry file (or set `target: "none"`). The platform's own Pages site is
-  **never touched** — only the hub's record of it.
+  **never touched** — only the Product's record of it.
 
 ## Hard rules
 
@@ -127,6 +127,6 @@ the site here — `yad-docs` builds.**
 - Registry schema, the base-path resolution table, and the freshness/degrade rules:
   `references/docs-registry.md`.
 - The connect pattern this mirrors (design tool): `../yad-connect-design/SKILL.md`.
-- The connect pattern this mirrors (code repos + hub detection): `../yad-connect-repos/SKILL.md`.
+- The connect pattern this mirrors (code repos + Product detection): `../yad-connect-repos/SKILL.md`.
 - The consumers — how `yad-docs` / `yad-docs-overview` build + deploy: `../yad-docs/SKILL.md`,
   `../yad-docs-overview/SKILL.md`.

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

@@ -38,7 +38,7 @@ Holds **no credentials** — every field is a plain reference. Auth is always th
 
 ## Platform auto-detection (from `.sdlc/hub.json`)
 
-When `target` is not given, map the hub's `platform` the same way `yad-connect-repos` maps a repo host:
+When `target` is not given, map the Product's `platform` the same way `yad-connect-repos` maps a repo host:
 
 | `hub.json` `platform` | default `target` |
 |-----------------------|------------------|

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

@@ -1,13 +1,13 @@
 ---
 name: yad-connect-learning
-description: 'Connects a learning/tutoring tool (DeepTutor, or another tool — pluggable) to the product hub so the cross-cutting learning layer can tutor any team member, at any SDLC stage, in the context of what is being built. Registers the tool into the project-wide .sdlc/learning.json (local-user auth, no stored tokens), detecting whether the DeepTutor CLI is on PATH and degrading to harness-native tutoring (the harness model reading project artifacts) when it is not. Optionally builds a project knowledge base from the SDLC artifacts + secret-scanned code-maps so tutoring is grounded. Run at setup or any time the learning tool changes. Reusable, idempotent, refreshable. Use when the user says "connect DeepTutor", "connect a learning tool", "refresh the learning connection", or "list the learning connection".'
+description: 'Connects a learning/tutoring tool (DeepTutor, or another tool — pluggable) to the Product so the cross-cutting learning layer can tutor any team member, at any SDLC stage, in the context of what is being built. Registers the tool into the project-wide .sdlc/learning.json (local-user auth, no stored tokens), detecting whether the DeepTutor CLI is on PATH and degrading to harness-native tutoring (the harness model reading project artifacts) when it is not. Optionally builds a project knowledge base from the SDLC artifacts + secret-scanned code-maps so tutoring is grounded. Run at setup or any time the learning tool changes. Reusable, idempotent, refreshable. Use when the user says "connect DeepTutor", "connect a learning tool", "refresh the learning connection", or "list the learning connection".'
 ---
 
 # SDLC — Connect a Learning Tool (the cross-cutting learning layer)
 
 **Goal:** Let any team member pause at **any** SDLC stage and ask to learn a concept — and get tutored
 *in the context of what the team is actually building*. This skill **connects** a learning tool such as
-**DeepTutor** to the product hub and records *how* to reach it (the tool, the CLI, an optional grounded
+**DeepTutor** to the Product and records *how* to reach it (the tool, the CLI, an optional grounded
 knowledge base) — never a credential. The consumer skill **`yad-learn`** does the tutoring per request
 and records the team's skills.
 
@@ -19,7 +19,7 @@ explains the concept. The learning layer is **purely opt-in and never blocks a g
 
 ## Conventions
 
-- `{project-root}` resolves from the project working directory (the **product hub**).
+- `{project-root}` resolves from the project working directory (the **Product**).
 - The integration is **DeepTutor-first but pluggable** (`config.yaml` `learning.tools`): a learning-tool
   *adapter*, like the design/testing adapters. `none` → harness-native (yad-learn still tutors via the
   harness model).
@@ -30,7 +30,7 @@ explains the concept. The learning layer is **purely opt-in and never blocks a g
   the sibling of `.sdlc/repos.json`, `.sdlc/hub.json`, `.sdlc/design.json`, and `.sdlc/testing.json`.
 - Per-epic, per-member learning records + rendered tutorials are written later by `yad-learn`
   (`epics/EP-<slug>/.sdlc/learning-records.json` and `epics/EP-<slug>/learning/`), not here.
-- Speak in the configured `communication_language`; write documents in `document_output_language`.
+- Speak in the `communication_language` set in `{project-root}/.sdlc/config.yaml`; write documents in `document_output_language`.
 
 ## Inputs
 
@@ -113,7 +113,7 @@ auto-advances; this is setup.
   **available/harness-native** flag for the CLI (best-effort). No learning tool connected ⇒
   "harness-native".
 - **`disconnect`** — remove the registry file (or set `tool: "none"`). DeepTutor's own config and
-  knowledge bases are **never touched** — only the hub's record of them.
+  knowledge bases are **never touched** — only the Product's record of them.
 
 ## Hard rules
 

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

@@ -1,6 +1,6 @@
 # Learning registry — schema + freshness rule
 
-The registry is the product hub's record of which learning tool is connected and how to reach it. It is
+The registry is the Product's record of which learning tool is connected and how to reach it. It is
 **project-wide** (one learning tool per project, shared across every epic), so it lives at the product
 root, not under any `epics/EP-<slug>/.sdlc/`.
 
@@ -55,6 +55,6 @@ only). This mirrors how `repos.json`, `hub.json`, `design.json`, and `testing.js
 
 ## Greenfield
 
-A brand-new product hub has no `learning.json`. That is valid — `yad-learn` treats "no learning tool
+A brand-new Product has no `learning.json`. That is valid — `yad-learn` treats "no learning tool
 connected" the same as `tool: "none"` and tutors harness-native. The registry appears the first time
 `connect` runs.

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

@@ -1,25 +1,25 @@
 ---
 name: yad-connect-repos
-description: 'Connects code repos to the product hub so the front/"brain" phases are code-aware. Registers N code repos (GitHub or GitLab, local-user auth, no stored tokens) into the project-wide .sdlc/repos.json, then caches an AI-readable picture of each — a compressed Repomix pack and a lightweight code-map (existing endpoints/events/data-models/modules), secret-scanned. Run at one-time setup or any time a new repo is added. Reusable, idempotent, refreshable; staleness is tracked by HEAD sha. `yad repo refresh --push` publishes the refreshed code-maps + registry to the hub default branch as a chore(hub): sync code-context [skip ci] audit commit. Use when the user says "connect a repo", "connect the code repos", "refresh the code context", "list connected repos", or "push the code-map refresh".'
+description: 'Connects code repos to the Product so the front/"brain" phases are code-aware. Registers N code repos (GitHub or GitLab, local-user auth, no stored tokens) into the project-wide .sdlc/repos.json, then caches an AI-readable picture of each — a compressed Repomix pack and a lightweight code-map (existing endpoints/events/data-models/modules), secret-scanned. Run at one-time setup or any time a new repo is added. Reusable, idempotent, refreshable; staleness is tracked by HEAD sha. `yad repo refresh --push` publishes the refreshed code-maps + registry to the Product default branch as a chore(hub): sync code-context [skip ci] audit commit. Also drafts each code repo's risk map (.sdlc/risk-map — a level per directory, no names), classified by reading the code and marked guessed for a person to confirm. Use when the user says "connect a repo", "connect the code repos", "refresh the code context", "list connected repos", or "push the code-map refresh".'
 ---
 
 # SDLC — Connect Code Repos (make the brain code-aware)
 
 **Goal:** Give the front/"brain" phases (`yad-epic` → `-architecture` → `-ui` → `-stories`)
 full context about what **already exists** in the code, so the AI does not author a contract, UI, or
-stories that contradict or duplicate what is built. This skill **connects** code repos to the product
-hub and caches an AI-readable picture of each. It is the product → code half of the 2-way link (the
+stories that contradict or duplicate what is built. This skill **connects** code repos to the Product and caches an AI-readable picture of each. It is the product → code half of the 2-way link (the
 code → product half is the existing `link.md` back-pointer each spec carries).
 
-This is **setup/maintenance**, not a gated front state — it never touches `.sdlc/state.json` or any
-epic's approvals. It only writes the project-wide registry and the per-repo context cache.
+This is **setup/maintenance**, not a gated Shape step — it never touches `.sdlc/state.json` or any
+epic's approvals. It writes the project-wide registry, the per-repo context cache, and — in the code
+repo itself — a draft of that repo's risk map (Step 3b), which the team commits there through a PR.
 
 ## Conventions
 
-- `{project-root}` resolves from the project working directory (the **product hub**).
-- The **product repo is the front-phase toolchain hub** (`config.yaml` `code_context`): Repomix (and
+- `{project-root}` resolves from the project working directory (the **Product**).
+- The **product repo is where the Shape phase toolchain runs** (`config.yaml` `code_context`): Repomix (and
   Impeccable, later) are installed/run **here** and target the connected code repos **by path**. The
-  code repos themselves need no install for this. (The build-half CI gates are the exception — they
+  code repos themselves need no install for this. (The Build CI gates are the exception — they
   live inside each code repo; see `yad-checks`.)
 - **Repomix is a true CLI subprocess** (Phase 0 / RESEARCH-NOTES §3): `npx repomix@latest [flags]` —
   NOT a slash-command. It secret-scans by default (Secretlint).
@@ -28,18 +28,15 @@ epic's approvals. It only writes the project-wide registry and the per-repo cont
 
 ## Inputs
 
-- `action` — `connect` | `refresh` | `list` | `disconnect` | `detect-hub` | `roster` (default `connect`).
+- `action` — `connect` | `refresh` | `list` | `disconnect` | `detect-hub` (default `connect`).
 - `repo` — the repo's short name (the key used in stories' `repos:` tag, e.g. `backend`).
-- `login`, `name`, `email`, `roles` — for `roster` (map login → name + commit email + the per-scope
-  `roles` map, e.g. `roles: hub=owner,reviewer backend=domain-owner`). Validate the login against the
-  hub (`gh api users/<login>` / `glab api users?username=`); a miss is flagged `unverified` (warn-only).
 - `path` — local path to the code repo (relative to `{project-root}` or absolute). For local repos.
   It must resolve inside the **workspace** — the project root's parent — so the standard layout, where
-  the code repos sit **beside** the hub rather than under it, registers as `../backend`:
+  the code repos sit **beside** the Product rather than under it, registers as `../backend`:
 
   ```text
   project/          <- the workspace (containment boundary)
-    product/        <- the hub repo; `yad setup` runs here
+    product/        <- the Product repo; `yad setup` runs here
     backend/        <- ../backend
     frontend/       <- ../frontend
   ```
@@ -49,12 +46,13 @@ epic's approvals. It only writes the project-wide registry and the per-repo cont
   later used as a working directory (repomix) and written into (`.coderabbit.yaml`, CI wiring).
   It is stored **exactly as typed**; every consumer re-resolves it against the project root.
 
-  The workspace is the trust boundary, so **put the hub one level below it** (`project/product`), not
-  directly in `$HOME` — with the hub at `~/product` the workspace becomes `~` and every home-dir
+  The workspace is the trust boundary, so **put the Product one level below it** (`project/product`), not
+  directly in `$HOME` — with the Product at `~/product` the workspace becomes `~` and every home-dir
   sibling turns into a registrable repo. The workspace directory itself (`..`) is never registrable.
 - `git_url` — optional remote (SSH or HTTPS; GitHub or GitLab). Used when the repo is not yet on disk.
-- `domain_owners` — the engineer(s) who own this repo's domain (a repo may have several; drives per-repo
-  review routing). Each name is also written into that person's `roles[<repo>]` map in `hub.json`.
+
+yadflow keeps **no list of people** (E62): no roster, no roles, no repo owners, no commit emails. Do not
+ask for them and do not write them.
 
 ## On Activation
 
@@ -90,9 +88,33 @@ Feed the pack to the AI with the **"describe what exists, do not invent"** instr
 (`references/code-context.md`) and write `{project-root}/.sdlc/code-context/<repo>/code-map.md`: a small
 index of **stack/conventions, entry points, public endpoints/APIs, events, data models/entities, and
 module layout**. Mark anything unclear `<!-- unverified: ... -->`; never fill gaps with invented
-behaviour. This is the cheap artifact every front phase loads by default (the full pack is read only
+behaviour. This is the cheap artifact every Shape phase loads by default (the full pack is read only
 when a phase needs depth).
 
+### Step 3b — Draft the risk map (a level per directory, from the code)
+Each code repo keeps `.sdlc/risk-map` **in the code repo**: one line per directory saying `high`, `medium`
+or `low`, and **no names** (E65). Format, rubric and edit rules: `references/risk-map.md`.
+
+1. Run `yad risk-map draft <path>` with the repo's **path**, not its name: on a first `connect` the repo is
+   not in `repos.json` until Step 4, and a name it does not know is refused. It adds an `unset` line for
+   every directory no line covers and never changes a line that is already there.
+2. For every `unset` line, **read the code in that directory** — the pack, the code-map, and the files
+   themselves when those do not say — and decide the level by the rubric. Judge by what the code does,
+   never by the folder's name — with one exception, `.sdlc/`, which is `high` because it holds the risk
+   map (see the rubric). Write the level, `guessed`, and a one-line reason from the code
+   (`src/payments/  high  guessed  # charge.js calls the card processor`). When unsure between two levels,
+   choose the higher one. When a directory's parts differ, add a deeper line for each part.
+3. A `guessed` line may be re-levelled if the code says otherwise — except `.sdlc/`, which is raised to
+   `high` if it is not (the rubric's one exception). **Never edit, re-level or delete a `confirmed` line**:
+   when the code now contradicts one, report it as a suggestion for a person. Never mark anything
+   `confirmed` — only a person does that. Write no name, secret or customer value.
+4. Run `yad risk-map check <path>` and report what is left.
+5. Tell the person to review every `guessed` line, change the right ones to `confirmed`, and commit
+   `.sdlc/risk-map` **in the code repo, on a new branch, through a PR** — never straight to its default branch. Its `risk-map` check warns on that PR that the map
+   was edited — expected, and advisory.
+
+With no AI agent available, stop after step 1 and tell the person the `unset` lines are theirs to fill.
+
 ### Step 4 — Record the repo in the registry
 Upsert the repo into `{project-root}/.sdlc/repos.json` (create the file if absent). Record the current
 HEAD sha as `syncedHead` (this drives staleness):
@@ -104,8 +126,6 @@ HEAD sha as `syncedHead` (this drives staleness):
       "path": "<path rel. to project-root>",
       "git_url": "<url or null>",
       "platform": "github|gitlab|null",
-      "domain_owners": ["<owner>", "…"],
-      "domain_owner": "<domain_owners[0] — legacy mirror>",
       "default_branch": "<branch>",
       "connectedAt": "<YYYY-MM-DD>",
       "lastSyncedAt": "<YYYY-MM-DD>",
@@ -118,20 +138,22 @@ HEAD sha as `syncedHead` (this drives staleness):
 }
 ```
 `connect` is **idempotent** — re-running it for an existing repo refreshes its entry in place. Adding a
-new repo later is the same `connect` action.
+new repo later is the same `connect` action. Write no `domain_owner`/`domain_owners`; an entry an older
+release wrote with them is left as it is (nothing reads them, and `yad doctor` warns
+`people:domain-owners-unused`).
 
 ### Step 5 — Report
 Report the connected repo, its `platform`, the pack + code-map paths, the secret-scan result, and that
-the front phases will now load this repo's code-map. Nothing auto-advances; this is setup.
+the Shape phases will now load this repo's code-map. Nothing auto-advances; this is setup.
 
 ## Other actions
 
-- **`refresh`** — re-run Steps 2–4 for an already-connected repo (after its code moves). Updates
+- **`refresh`** — re-run Steps 2–4 (including Step 3b) for an already-connected repo (after its code moves). A new directory gets an `unset` line and a guess; a `confirmed` line is only ever suggested against. Updates
   `syncedHead` + `lastSyncedAt`. Same machinery as `connect`. Once the AI has regenerated the
-  `code-map.md` (Step 3), publish it to the product hub with **`yad repo refresh <repo> --push`**: it
+  `code-map.md` (Step 3), publish it to the Product with **`yad repo refresh <repo> --push`**: it
   commits the tracked code-maps + `.sdlc/repos.json` (never the gitignored `pack.md`) as one
   audit-trail commit `chore(hub): sync code-context — <repos> by @<login> [skip ci]` and pushes it
-  straight to the hub's **default branch** (add `--allow-branch` to commit on a non-default branch).
+  straight to the Product's **default branch** (add `--allow-branch` to commit on a non-default branch).
   This is the code-context analogue of `yad checkpoint` — human-owned machine state, no Task trailer,
   no Co-Authored-By.
 - **`list`** — print every registry entry with a **fresh/stale** flag: compare each repo's current HEAD
@@ -139,38 +161,51 @@ the front phases will now load this repo's code-map. Nothing auto-advances; this
 - **`disconnect`** — remove the repo from the registry and delete its cache dir. Leaves the **code repo
   itself untouched**.
 
-## Hub detection + reviewer roster (the front-half review bridge)
+## Product detection (the Shape review bridge)
 
-The hub is itself a git repo on a platform. These actions record that so the front-half review/comment/
-approval cycle can run through a real PR/MR on the hub (`yad-review-gate` + `yad-hub-bridge`). They
-write only `{project-root}/.sdlc/hub.json` (`config.yaml` `hub.config`) — never an epic's state/approvals.
+The Product is itself a git repo on a platform. This action records that so the Shape review/comment/
+approval cycle can run through a real PR/MR on the Product (`yad-review-gate` + `yad-hub-bridge`). It
+writes only `{project-root}/.sdlc/hub.json` (`config.yaml` `product.config` (older projects: `hub.config`)) — never an epic's state/approvals.
 
-- **`detect-hub`** — detect the hub's own platform and upsert `.sdlc/hub.json`. Run
-  `git remote get-url origin` **on the hub** and read the host with the SAME logic Step 1 uses for code
+- **`detect-hub`** — detect the Product's own platform and upsert `.sdlc/hub.json`. Run
+  `git remote get-url origin` **on the Product** and read the host with the SAME logic Step 1 uses for code
   repos: `github.com` → `github`, GitLab host → `gitlab`, no remote → `platform: null`. Record
-  `git_url`, `default_branch`, `detectedAt`, and `bridge_enabled` — **`true` only when a platform was
-  detected, `false` alongside `platform: null`** (preserve an existing roster). The two travel
-  together: bridge mode is a platform AND the flag (`isBridge`, `cli/gate.mjs`), and `yad setup`
-  derives both from one value, so writing the flag onto a platform-less hub creates a state no CLI
-  path can produce and the gates read differently (#186).
+  `git_url`, `default_branch`, `detectedAt`, and **all three of** `ledger`, `bridge_enabled` and
+  `bridge`:
+
+  | a platform was detected | no platform (`platform: null`) |
+  |---|---|
+  | `"ledger": "verified"`, `bridge_enabled: true`, `bridge: true` | `"ledger": "local"`, `bridge_enabled: false`, `bridge: false` |
+
+  Write no `roster`. Leave any other key already in the file as it is — including a `roster` or
+  `verified_authors` an older release wrote. Neither decides anything (the roster's name → login pairs
+  only help the first sync recognise older approvals); `yad doctor` warns
+  `people:roster-unused` / `people:verified-authors-unused`, and nothing deletes them.
+
+  **`ledger` is the one that decides.** `isVerifiedLedger` (`cli/manifest.mjs`) reads it first and
+  falls back to the booleans only when it is absent — so on a project that has already run
+  `yad migrate`, writing `bridge_enabled: true` while leaving `"ledger": "local"` in place turns
+  verified mode ON in the file and OFF in the engine. Nothing would be wired, no guard would arm,
+  and the report would say it worked. Write all three, and keep them saying the same thing.
+
+  The booleans are still written because a check gate committed in the repo may predate
+  `yad update`; see `docs/migrations/shape-2.md`.
+
+  A platform and a verified ledger travel together: verified mode is a platform AND the switch
+  (`isVerifiedLedger`, `cli/manifest.mjs`), and `yad setup` derives both from one value, so marking a
+  platform-less Product verified creates a state no CLI path can produce and the gates read
+  differently (#186).
   Auth is the local user's own `gh`/`glab`/git; **store no tokens**. Idempotent — safe to re-run.
-- **`roster`** — set one roster entry mapping a platform `login` → SDLC `name` + `email` + a per-scope
-  `roles` map (`roles: { hub: ["owner","reviewer"], <repo>: ["domain-owner", …] }`). Upsert by `login`;
-  a person may hold several roles across several scopes, and a repo several people per role. Validate the
-  `login` against the hub (warn-only; flag `unverified` on a miss). `domain-owner` is written into
-  `roles[<repo>]` (and still **derived** as a fallback when a roster `name` equals a repo's
-  `domain_owner`/`domain_owners` in `repos.json` — see `references/hub-config.md`). An unmapped login
-  degrades to a plain `reviewer`, never auto-promoted to owner/domain-owner.
-  **The deterministic half is the `yad roster` CLI command** — runnable any time, not just at setup:
-  `yad roster list`; `yad roster add <login>` (upsert, then a repo-driven walk that asks for each
-  connected repo's role); `yad roster grant|revoke <name> <repo> <role>`; `yad roster remove <login>`.
-  A `domain-owner` grant/revoke keeps `repos.json` `domain_owners` in sync so the gate never drifts.
-
-If the hub has no remote (`platform: null`) or the bridge is disabled, the front-half gate runs
-file-only with no error — the bridge is purely additive.
+
+There is **no roster action** (removed in E62). `yad roster` is gone too: typing it prints a notice and
+exits 1. A team gate needs 1 approval from someone other than the author, and each approval records the
+platform login that gave it. The platform, not a stored list, decides who can approve.
+
+If the Product has no remote (`platform: null`) or the verified ledger is disabled, the Shape gate runs
+local with no error — the verified ledger is purely additive.
 
 ## Live on-demand (the third context layer)
-The cached pack + map are the default. When a front phase needs an **area** not in the map, it may
+The cached pack + map are the default. When a Shape phase needs an **area** not in the map, it may
 re-run Repomix **live**, scoped to that area:
 ```bash
 npx repomix@latest --compress --include "<area globs>" --style markdown -o -
@@ -188,11 +223,14 @@ it does not silently re-pack. Refreshing the cache is a human decision. Document
 - **Describe what exists; never invent.** The code-map records built behaviour, not a design.
 - **Setup, not a gate.** Never touch `.sdlc/state.json`, approvals, or the contract lock from here.
 - **Idempotent + refreshable.** `connect`/`refresh` are safe to re-run; staleness is HEAD-sha based.
+- **The risk map holds no names, and the agent never confirms.** It fills `unset`, may re-level `guessed`,
+  and only suggests against `confirmed`.
 
 ## Reference
 - Registry schema + freshness rule: `references/repos-registry.md`.
-- Hub config + reviewer roster (the review bridge): `references/hub-config.md`.
+- The risk map — format, rubric, what the agent may change: `references/risk-map.md`.
+- Product config (the review bridge): `references/hub-config.md`.
 - Repomix command, secret-scan, degrade path, the code-map prompt, and live on-demand:
   `references/code-context.md`.
 - The repomix discipline this reuses (one-feature-at-a-time variant): `../yad-backfill/references/backfill.md`.
-- Repos convention + per-repo review routing: `../yad-stories/references/story-schema.md`.
+- Repos convention: `../yad-stories/references/story-schema.md`.

package/skills/yad-connect-repos/references/code-context.md

@@ -6,7 +6,7 @@ variant; backfill is the one-feature-at-a-time variant).
 
 ## Layer 1 — the cached pack (full context)
 
-Run from the product hub, targeting the connected repo (flags from `config.yaml`
+Run from the Product, targeting the connected repo (flags from `config.yaml`
 `code_context.pack_flags`):
 
 ```
@@ -64,12 +64,12 @@ source: repomix
 <!-- the main directories/modules and what each owns -->
 ```
 
-The code-map is deliberately small so every front phase can load it cheaply. The full `pack.md` is read
+The code-map is deliberately small so every Shape phase can load it cheaply. The full `pack.md` is read
 only when a phase needs depth (the architecture phase, primarily).
 
 ## Layer 3 — live on-demand (a specific area, not a stale repo)
 
-When a front phase needs an area not captured in the code-map, it may re-pack that **slice** live,
+When a Shape phase needs an area not captured in the code-map, it may re-pack that **slice** live,
 scoped to the area, without writing the cache:
 
 ```bash
@@ -81,11 +81,11 @@ side-effect:** when a repo is stale (HEAD ≠ `syncedHead`), the phase **flags i
 "`<repo>` is stale; run `yad repo refresh <repo>` to re-pack the cache + `syncedHead`" — rather than
 silently re-packing the whole repo. A phase never refreshes the registry on its own; the human runs
 `yad repo refresh` (or `yad check --fix`). After the AI regenerates the code-map, `yad repo refresh
---push` publishes the refreshed code-maps + registry to the hub's default branch as a `chore(hub): sync
+--push` publishes the refreshed code-maps + registry to the Product's default branch as a `chore(hub): sync
 code-context … [skip ci]` audit commit (never the pack's content; `--allow-branch` overrides the branch
 guard). The `pack.md` is gitignored — `yad repo refresh`/`yad setup` scaffold
-`.sdlc/code-context/*/pack.md` into the hub `.gitignore` (so a regenerated pack never dirties the tree),
-and a hub that tracked the pack *before* that ignore existed is self-healed: `--push` untracks it and
+`.sdlc/code-context/*/pack.md` into the Product `.gitignore` (so a regenerated pack never dirties the tree),
+and a Product that tracked the pack *before* that ignore existed is self-healed: `--push` untracks it and
 lands the removal + the managed `.gitignore` line in the same audit commit. The commit is a scoped
 `git commit -- <paths>` — it never sweeps unrelated staged work, and an unrelated hand-edit to
 `.gitignore` is left for the human to commit rather than riding the `[skip ci]` audit commit.