yadflow 3.19.0-next.2 → 4.0.0-next.3

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

@@ -1,23 +1,23 @@
 ---
 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 Shape step — it never touches `.sdlc/state.json` or any
-epic's approvals. It only writes the project-wide registry and the per-repo context cache.
+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 Shape 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 CI gates are the exception — they
   live inside each code repo; see `yad-checks`.)
@@ -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
 
@@ -93,6 +91,30 @@ module layout**. Mark anything unclear `<!-- unverified: ... -->`; never fill ga
 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,7 +138,9 @@ 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
@@ -126,12 +148,12 @@ the Shape phases will now load this repo's code-map. Nothing auto-advances; this
 
 ## 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,14 +161,14 @@ the Shape 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 Shape review bridge)
+## Product detection (the Shape review bridge)
 
-The hub is itself a git repo on a platform. These actions record that so the Shape 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 **all three of** `ledger`, `bridge_enabled` and
   `bridge`:
@@ -155,7 +177,10 @@ write only `{project-root}/.sdlc/hub.json` (`config.yaml` `hub.config`) — neve
   |---|---|
   | `"ledger": "verified"`, `bridge_enabled: true`, `bridge: true` | `"ledger": "local"`, `bridge_enabled: false`, `bridge: false` |
 
-  (Preserve an existing roster.)
+  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
@@ -168,22 +193,15 @@ write only `{project-root}/.sdlc/hub.json` (`config.yaml` `hub.config`) — neve
 
   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 hub verified creates a state no CLI path can produce and the gates read
+  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 verified ledger is disabled, the Shape gate runs
+
+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)
@@ -205,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`):
 
 ```
@@ -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.

package/skills/yad-connect-repos/references/hub-config.md

@@ -1,80 +1,75 @@
-# Hub config — schema, detection, and the reviewer roster
+# Product config — schema, detection, and who is recorded
 
-The hub config is the product hub's record of **its own** platform (so the Shape review/comment/
-approval cycle can run through a real PR/MR on the hub) and the **reviewer roster** that maps a platform
-login to an SDLC name + role. It is a single object for the hub itself — the sibling of the per-repo
+The Product config is the Product's record of **its own** platform (so the Shape review/comment/
+approval cycle can run through a real PR/MR on the Product). It holds **no list of people** — no roster,
+no roles, no commit emails (E62). It is a single object for the Product itself — the sibling of the per-repo
 `repos.json` registry (see `repos-registry.md`), kept separate so it never pollutes that array.
 
 ## Location
 
 `{project-root}/.sdlc/hub.json`
 
-(`config.yaml` `hub.config`.) Created/updated by `yad-connect-repos action: detect-hub`.
+(`config.yaml` `product.config` (older projects: `hub.config`).) Created/updated by `yad-connect-repos action: detect-hub`.
 
 ## Schema
 
 ```json
 {
-  "schemaVersion": 2,                                         // the file's shape. Absent means 1 (rule 1). `yad migrate` moves it; see docs/migrations/shape-2.md
-  "platform": "github",                                       // github | gitlab (from the hub's own remote host); null when local-only
+  "schemaVersion": 10,                                        // the file's shape. Absent means 1 (rule 1). `yad migrate` moves it; see docs/migrations/shape-2.md
+  "platform": "github",                                       // github | gitlab (from the Product's own remote host); null when local-only
   "git_url": "https://github.com/abdelrahmannasr/yadflow.git", // REQUIRED when platform is non-null (scopes auth + opens PRs); yad doctor warns YAD-CFG-005 if absent
   "default_branch": "main",
   "ledger": "verified",                                       // WHO WRITES THE LEDGER, and the one that decides: "verified" = CI only, signed; "local" = this machine. Travels WITH platform — verified is both (isVerifiedLedger), so never "verified" beside platform: null (#186)
   "bridge_enabled": true,                                     // the older spelling of the same switch, kept so a check gate that predates `yad update` still reads it. Write it to MATCH `ledger`, never against it
   "bridge": true,                                             // older still. Same rule
-  "gate_sync_version": "3.15.3",                              // OPTIONAL exact pin for the wired gate-sync job; an exact 3.x.y, prereleases included (3.16.0-rc.1) — anything else is skipped. Omitted => the .sdlc/cli-version.json stamp if that qualifies, else floating 3
+  "gate_sync_version": "4.0.0",                              // OPTIONAL exact pin for the wired gate-sync job; an exact release of the wired fragment's major (4.x.y in this release), prereleases included (4.1.0-rc.1) — anything else, a 3.x pin included, is skipped. Omitted => the .sdlc/cli-version.json stamp if that qualifies, else floating on that major
   "review": { "requireEngagement": false },                   // Review Companion: false (soft) counts bare approves but nudges; true counts only verified-engagement approvals
-  "detectedAt": "2026-06-08",                                 // last detect-hub run (YYYY-MM-DD)
-  "roster": [
-    { "login": "abdelrahmannasr", "name": "alice", "email": "alice@example.com",
-      "roles": { "hub": ["owner", "reviewer"] } },
-    { "login": "carol-gh", "name": "carol", "email": "carol@example.com",
-      "roles": { "hub": ["reviewer"], "backend": ["domain-owner", "owner"], "payments": ["reviewer"] } }
-  ]
+  "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)
 }
 ```
 
-## The roster — login → name → per-scope roles
-
-The roster is how a platform identity (a GitHub/GitLab **login**) becomes an SDLC **name + role(s)** in
-the file ledger (`approvals.json` / `comments.json`). Roles are the same three the gate uses:
-`owner | reviewer | domain-owner`. Populate and edit it any time with the **`yad roster`** CLI command
-(`list` / `add` / `grant` / `revoke` / `remove`) — `add` walks the connected repos asking for each
-one's role, and a `domain-owner` grant keeps `repos.json` `domain_owners` in sync.
-
-- **`login`** — the platform username whose PR review / approval is being mapped.
-- **`name`** — the SDLC name written into the ledger (the same names used across `approvals.json`,
-  `comments.json`, and `epic.md` `owner`). Keep it stable.
-- **`email`** — the commit email; drives the **committer → login** reverse lookup that auto-assigns PRs.
-- **`roles`** — a **per-scope map**: scope (`hub`, or a connected repo name) → the roles held there. A
-  person can be **owner + reviewer + domain-owner at once** and across scopes; a repo gets **several**
-  people per role by appearing in several entries' maps. Validated against the hub during `yad setup` /
-  `yad doctor`; a login that does not resolve is flagged `unverified` (warn-only, never blocks).
-
-**Back-compat:** readers also accept a flat array `"roles": ["owner","reviewer"]` (treated as `hub`
-roles) and the legacy single `"role": "owner"` (a `hub` role).
-
-**`domain-owner` may also be DERIVED from `repos.json`.** A roster entry whose `name` equals a repo's
-`domain_owner`/`domain_owners` in `repos.json` is treated as that repo's domain-owner **when that repo is
-a touched domain for the step under review** — kept as a fallback so pre per-scope projects still resolve.
-New setups write the grant directly into the person's `roles[<repo>]` map.
-
-- **Unmapped login fallback.** A login absent from the roster maps to `name: <login>`, `role: reviewer`,
-  and is flagged `<!-- unverified login: <login> -->` in the review record (mirrors the code-map
-  `unverified` convention). An unmapped login is **never** auto-promoted to `owner` or `domain-owner` —
-  it stays a plain reviewer until a human adds it to the roster, so a stranger cannot satisfy the
-  owner/domain-owner requirement.
+## People — no roster (E62)
+
+yadflow keeps **no stored list of people**. A list is a claim that goes stale; the platform already knows
+who is logged in and who has access.
+
+- **Who a record names.** A record's `by` is the platform login that `gh api user` / `glab api user`
+  reports, else git `user.name` (no platform, CLI missing or logged out, no network).
+  `YAD_PLATFORM_LOGIN=0` turns the lookup off.
+- **Approvals.** Each approval records the platform login that gave it as `approver`, with no `role` and
+  no `domain`. A team gate needs at least **1 approval from someone other than the author**, plus
+  resolved threads and a merged PR. The full count is `base 1 + risk step` (`contract` +2, `auth` /
+  `payments` +1, the largest and never the sum); the gate caps it at the active people less one and
+  reports that (E72); the risk step is advisory. Solo
+  mode still waives the approval.
+- **Reviewers.** Nothing requests reviewers on a PR/MR. Ask them on the PR/MR itself. `yad open-pr`
+  prints a suggestion for a code-repo PR (E68) from recent history and CODEOWNERS — a hint only.
+
+**Legacy data an older release wrote.** A `roster` array (with `login`/`name`/`email`/`roles`, or the
+older `role`) and a `verified_authors` list may still sit in this file. Nothing adds them, and nothing
+deletes them (`yad migrate`'s shape-3 step still adds a `product` role key beside `hub` in an old roster, so
+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`
+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
+closed.
 
 ## Detection
 
 `detect-hub` reuses the same host-detection logic this skill already applies to code repos:
-run `git remote get-url origin` **on the hub itself** and read the host —
+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.
 
 **`git_url` is required whenever `platform` is non-null.** `yad doctor` uses it to scope the auth
-probe to the hub's own host (an unscoped `glab auth status` fails on any unrelated broken instance),
+probe to the Product's own host (an unscoped `glab auth status` fails on any unrelated broken instance),
 and the verified ledger/PR flow uses it to open PRs. Doctor flags its absence with a warn (`YAD-CFG-005`);
 re-running `yad setup` backfills it from the origin remote (idempotent, non-interactive).
 
@@ -92,10 +87,10 @@ So on a migrated project `ledger` wins, and writing a boolean that contradicts i
 Keep all three in step.
 
 - `ledger: "verified"` **and** a non-null `platform` **and** `gh`/`glab` authenticated → the Shape
-  review opens a PR/MR on the hub and `yad-review-gate action: sync` pulls platform state into the ledger.
+  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` `hub.bridge: false` 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 `hub.json`.
 
 ## Review Companion engagement (`review.requireEngagement`)
 
@@ -108,11 +103,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 (logins and names only, never tokens).
+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
+whatever an older `roster` still lists.
 This mirrors how `repos.json` and the per-epic `.sdlc/` state are committed.
 
 ## Greenfield
 
-A brand-new hub has no `hub.json`. That is valid — the Shape gate runs local until `detect-hub`
+A brand-new Product has no `hub.json`. That is valid — the Shape gate runs local until `detect-hub`
 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

@@ -1,6 +1,6 @@
 # Repos registry — schema + freshness rule
 
-The registry is the product hub's record of which code repos are connected and where their cached
+The registry is the Product's record of which code repos are connected and where their cached
 code-context lives. It is **project-wide** (shared across every epic), so it lives at the product root,
 not under any `epics/EP-<slug>/.sdlc/`.
 
@@ -21,8 +21,6 @@ not under any `epics/EP-<slug>/.sdlc/`.
       "path": "demo-repos/backend",              // path to the code repo, rel. to {project-root} (or absolute)
       "git_url": "git@github.com:org/backend.git", // optional remote; SSH or HTTPS; GitHub or GitLab; null if local-only
       "platform": "github",                       // github | gitlab (from the URL host); null when local-only
-      "domain_owners": ["carol", "dave"],         // engineers who own this repo's domain (review routing); a repo may have several
-      "domain_owner": "carol",                    // legacy single-owner mirror = domain_owners[0] (kept for back-compat readers)
       "default_branch": "main",
       "connectedAt": "2026-06-08",                // first connect (YYYY-MM-DD)
       "lastSyncedAt": "2026-06-08",               // last connect/refresh
@@ -37,6 +35,9 @@ not under any `epics/EP-<slug>/.sdlc/`.
 
 ## Rules
 
+- **No owners.** An entry names no people (E62). `connect` writes no `domain_owner`/`domain_owners`. An
+  entry an older release wrote with them keeps them; nothing reads them, nothing deletes them, and
+  `yad doctor` warns `people:domain-owners-unused`.
 - **`name`** is the join key. It MUST match the names used in epic/story `repos:` tags so the Shape
   phases can map `epic.repos` → registry entries → code-maps. Keep it stable.
 - **Auth is never stored.** No tokens, passwords, or PATs in the registry. `git_url` is a plain remote;
@@ -52,14 +53,14 @@ 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 hub's default
+`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.
-**Ignore** the full Repomix `pack.md` — it is large and regenerable (`action: refresh`). The product
-hub's `.gitignore` carries `.sdlc/code-context/*/pack.md` for this. This mirrors how the per-epic
+**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.
 
 ## Greenfield
 
-A brand-new product hub has no `repos.json` (or an empty `{ "repos": [] }`). That is valid — the Shape
+A brand-new Product has no `repos.json` (or an empty `{ "repos": [] }`). That is valid — the Shape
 phases treat "no repos connected" as "nothing to consider yet" and proceed unchanged. The registry
 appears the first time `connect` runs.

package/skills/yad-connect-repos/references/risk-map.md

@@ -0,0 +1,81 @@
+# Risk map — format, the classification rubric, and the rules for the agent
+
+A code repo's **risk map** is one file, `.sdlc/risk-map`, **in the code repo** (not the Product). It
+gives each directory a risk level. It holds **no names** — no people, no roles, no teams, no `@login`.
+It is the team's file: `yad update` never installs, owns or overwrites it, and it changes only through
+that repo's PRs (E65).
+
+**What the levels do (E66).** A change touching a `high` directory asks for one more approver. The count
+reads the map on the **base branch**, so a PR cannot lower its own count, and a `guessed` level counts
+exactly as a `confirmed` one. That is why a guess matters: a `high` guess adds a reviewer to every change
+under that directory until a person confirms or changes it. `medium` and `low` add nothing. The count is
+reported, not enforced: branch protection holds the merge, and `yad open-pr` shows the count capped by the
+active people (E72). A `high` directory also asks for an approval from someone who has committed there in the last 30 days
+(E67), named live from the base branch's history — so a guess here decides who can review, too.
+
+## Format
+
+```
+# yad-risk-map v1
+src/payments/   high    confirmed  # charge.js calls the card processor
+src/catalog/    low     guessed    # read-only product listing
+docs/           unset
+./              low     confirmed  # the files at the repo root
+```
+
+| Rule | Meaning |
+|---|---|
+| Header | The first line is `# yad-risk-map v1`. |
+| One line per directory | `<dir>/ <level> <guessed\|confirmed>`, fields split on spaces or tabs, so a path holds none. |
+| Directory | Written from the repo root, ending in `/`. No leading `/` or `#`, no `.` or `..` segment, no space, tab, `*`, `?`, `[` or `\`. A directory whose name holds one of those (`app/[slug]/`) cannot have a line of its own: its parent's line covers it. At the top level (`my docs/`) nothing can, and the check says to rename it. |
+| `./` | The files **at** the repo root only — not everything below it. |
+| Which line decides | The deepest listed directory above a file. |
+| Levels | `high`, `medium`, `low`, or `unset` (listed, not classified; its state may be left out). |
+| States | `guessed` (an AI agent filled it in) or `confirmed` (a person checked it). |
+| Comment | Everything from the first `#` that follows a space or tab. |
+| Names | A word starting `@` (`@alice`, `@org/team`) is a name and is warned about. A word ending in `/` (`@types/`) is a directory. |
+| No `contract` | The contract surface keeps its own lock, `contract-check` and `Contract-Change` trailer. |
+
+The rules are code: `cli/riskmap.mjs`, with a bash twin in `checks/risk-map-check.sh`.
+
+## Rubric — read the CODE, not the folder name (one exception, below)
+
+Decide from what the code in the directory **does**: the calls it makes, the data it writes, the
+libraries it imports. A folder called `utils/` can move money; a folder called `payments/` can hold only
+display text. Use the pack and the code-map first, and open the files themselves when they do not say.
+
+| Level | The code in the directory… |
+|---|---|
+| `high` | moves money or bills anyone; handles login, sessions, tokens, permissions, secrets or keys; deletes stored data or changes its shape (migrations); reads or writes personal data (identity, contact, health, payment details); builds, deploys or releases (CI workflows, deploy scripts, infrastructure); and `.sdlc/` — see the exception below the table |
+| `medium` | writes to a database, a queue or an outside service in ordinary ways; serves a public API or event others depend on; is a shared library most of the code imports; sets build or dependency configuration |
+| `low` | only reads and shows data; styling and UI text; documentation; tests, fixtures and examples; developer tooling that never ships |
+
+- **When unsure between two levels, choose the higher one** and say what you could not tell in the reason.
+- **Split a directory when its parts differ.** If `src/` holds `payments/` (`high`) and `catalog/` (`low`),
+  write a line for each part, and keep a line for `src/` itself for the files directly in it.
+- **The one exception: `.sdlc/` is `high`**, judged by what it HOLDS — this map, which decides how much
+  review every later change needs — not by what its code does (the user's decision, 2026-09-17). A
+  `yad update` PR touches that folder too, so those PRs ask for the extra approver as well; accepted,
+  because they rewrite the gate scripts the repo runs.
+- **The reason is one line, taken from the code**: a file and what it does (`charge.js calls the card
+  processor`). Never a name, a secret, a customer value or an address.
+
+## What the agent may and may not change
+
+| Line | The agent may… | The agent may not… |
+|---|---|---|
+| `unset` | give it a level, a reason and `guessed` | mark it `confirmed` |
+| `guessed` | change its level or reason, keeping `guessed` | mark it `confirmed` |
+| `confirmed` | nothing — print a **suggestion** when the code now says otherwise | edit, re-level or delete it |
+| any | add a deeper line when a directory's parts differ | delete a line, or add a name |
+
+Only a person turns `guessed` into `confirmed`, in a PR in the code repo. The commit records who.
+
+## Staying true
+
+| Where | What it says |
+|---|---|
+| `checks/risk-map-check.sh` on every PR (both CI templates) | a file this change adds or edits that no line covers (names the directory to add); a line whose directory holds no file; a touched line still `unset` or `guessed`; a line it cannot read or that names a person; a change that edits the map itself. **Warnings only** — it never fails the build |
+| `yad risk-map check [repo]` | the same, for the whole repo |
+| `yad doctor`, section `risk-map` | one line per connected repo on disk |
+| `yad repo refresh` + this skill | a new directory is drafted `unset` and classified; a `confirmed` line the code now contradicts is printed as a suggestion |

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

@@ -1,13 +1,13 @@
 ---
 name: yad-connect-testing
-description: 'Connects a testing tool (Playwright, or another tool — pluggable) to the product hub so the test-cases step can implement the actual automation tests, not just Markdown test cases. Registers the tool into the project-wide .sdlc/testing.json (local-user / MCP-session auth, no stored tokens), detecting whether a testing-tool MCP is available and degrading to artifacts-only when it is not. Run at setup or any time the testing tool changes. Reusable, idempotent, refreshable. Use when the user says "connect Playwright", "connect a testing tool", "refresh the testing connection", or "list the testing connection".'
+description: 'Connects a testing tool (Playwright, or another tool — pluggable) to the Product so the test-cases step can implement the actual automation tests, not just Markdown test cases. Registers the tool into the project-wide .sdlc/testing.json (local-user / MCP-session auth, no stored tokens), detecting whether a testing-tool MCP is available and degrading to artifacts-only when it is not. Run at setup or any time the testing tool changes. Reusable, idempotent, refreshable. Use when the user says "connect Playwright", "connect a testing tool", "refresh the testing connection", or "list the testing connection".'
 ---
 
 # SDLC — Connect a Testing Tool (make the test-cases step automation-aware)
 
 **Goal:** Let the test-cases step (`yad-test-cases`) produce the **actual automation tests** — the
 runnable specs in a connected code repo — alongside the Markdown artifact (`test-cases.md`). This skill
-**connects** a testing tool such as **Playwright** to the product hub and records *how* to reach it (the
+**connects** a testing tool such as **Playwright** to the Product and records *how* to reach it (the
 tool, the suite references, which MCP runs it) — never a credential.
 
 This is **setup/maintenance**, not a gated Shape step — it never touches `.sdlc/state.json` or any
@@ -18,7 +18,7 @@ connected, `yad-test-cases` runs artifacts-only 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 integration is **Playwright-first but pluggable** (`config.yaml` `testing.tools`): a testing-tool
   *adapter*, like the GitHub/GitLab platform adapter or the design-tool adapter. Playwright is the
   primary provider; `cypress`, `pytest` and `maestro` are second providers; `none` → artifacts-only.
@@ -29,7 +29,7 @@ connected, `yad-test-cases` runs artifacts-only exactly as before.
   the sibling of `.sdlc/repos.json`, `.sdlc/hub.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 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
 
@@ -101,7 +101,7 @@ automation tests here**. Nothing auto-advances; this is setup.
   **available/unavailable** flag for the MCP (best-effort, the user's own session). No testing tool
   connected ⇒ "artifacts-only".
 - **`disconnect`** — remove the registry file (or set `tool: "none"`). The testing tool's own
-  project/suites are **never touched** — only the hub's record of them.
+  project/suites are **never touched** — only the Product's record of them.
 
 ## Hard rules
 

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

@@ -27,8 +27,7 @@ produce.
 
 ## Generate (write automation tests into the repo)
 
-When the connected provider is write-capable, the `test architect` lens (Murat, `bmad-tea` +
-`bmad-testarch-automate`) produces the epic's automation tests in the connected code repo(s), covering
+When the connected provider is write-capable, the `test architect` lens produces the epic's automation tests in the connected code repo(s), covering
 the cases `test-cases.md` enumerates and the acceptance criteria the stories define:
 
 - **Playwright** — the lens authors `*.spec.ts` E2E/API specs (reusing the repo's existing fixtures and
@@ -43,7 +42,7 @@ the cases `test-cases.md` enumerates and the acceptance criteria the stories def
 
 Reuse what already exists: load the connected code repos' code-maps (`yad-test-cases` Step 2b) so
 generated tests target real endpoints/components, not invented ones, and prefer the lowest useful test
-level (unit > integration > E2E) per Murat's principles.
+level (unit > integration > E2E).
 
 ## Link (reference an existing suite)
 
@@ -55,7 +54,7 @@ path/name + URL, and map it to the story it covers.
 
 Either direction ends by writing `epics/EP-<slug>/.sdlc/test-links.json` — the machine-readable
 case→test map — and a `## Automation (<tool>)` section in `test-cases.md` linking each case to its test.
-The tests themselves live in the code repo; the hub keeps the *links* and the Markdown spec beside the
+The tests themselves live in the code repo; the Product keeps the *links* and the Markdown spec beside the
 other epic artifacts.
 
 ## Degrade path (no MCP / no tool)