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

package/skills/yad-checks/templates/github/yad-verified-commits.yml

@@ -1,8 +1,8 @@
 # yad-managed: yad-checks
-# verified-commits gate for the PRODUCT HUB: every PR (including the Shape review/EP-* PRs)
-# must contain only commits whose signature the platform marks Verified AND whose author email is a
-# known identity (.sdlc/verified-authors — generated by `yad check --fix` from the hub roster).
-# Standalone workflow so it never collides with the hub-flavored yad-checks workflow.
+# verified-commits gate for the PRODUCT: every PR (including the Shape review/EP-* PRs)
+# must contain only commits whose signature the platform marks Verified. Who may author them is who has
+# write access to the repo — yadflow keeps no author list.
+# Standalone workflow so it never collides with the Product-flavored yad-checks workflow.
 name: yad-verified-commits
 on:
   pull_request:

package/skills/yad-checks/templates/gitlab/yad-checks.gitlab-ci.yml

@@ -53,6 +53,15 @@ yad-contract-check:
   script:
     - bash checks/contract-check.sh "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
 
+# E65/E66 — the risk map (.sdlc/risk-map: a risk level per directory, no names). Warnings, and the
+# approver count read from the base branch's map. It never fails the pipeline (the count is reported,
+# not enforced), so the job needs no allow_failure.
+yad-risk-map:
+  extends: .sdlc_mr_only
+  needs: []
+  script:
+    - bash checks/risk-map-check.sh "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
+
 yad-build-test-lint:
   extends: .sdlc_mr_only
   needs: []
@@ -102,7 +111,7 @@ yad-pr-template:
     - body="$(mktemp)"; printf '%s' "$CI_MERGE_REQUEST_DESCRIPTION" > "$body"
     - bash checks/pr-template.sh --profile code "$body"
 
-# No unverified commits from unverified users: platform-Verified signature + allowlisted author.
+# No unverified commits: a platform-Verified signature on every commit (write access decides who authors).
 # Needs a CI/CD variable GITLAB_TOKEN (or SDLC_API_TOKEN) with read_api scope — CI_JOB_TOKEN cannot
 # read the commit-signature API. Without it the job FAILS closed with guidance.
 yad-verified-commits:

package/skills/yad-checks/templates/gitlab/yad-hub-checks.gitlab-ci.yml

@@ -1,11 +1,11 @@
 # yad-managed-include: yad-checks
-# Pattern gates for the PRODUCT HUB, as an INCLUDABLE fragment. Pulled into the hub's root
+# Pattern gates for the PRODUCT, as an INCLUDABLE fragment. Pulled into the Product's root
 # .gitlab-ci.yml via:
 #   include:
 #     - local: '.gitlab/ci/yad-hub-checks.yml'
 # MRs run with `--profile hub` and split by source branch: review/EP-* MRs are Shape artifact-
-# review vehicles (a `review: <artifact> (EP-<slug>)` title + the hub artifact-review template body);
-# every other MR is a tooling/code change to the hub itself and follows the code convention (a
+# review vehicles (a `review: <artifact> (EP-<slug>)` title + the Product artifact-review template body);
+# every other MR is a tooling/code change to the Product itself and follows the code convention (a
 # Conventional-Commits title + the code task template body). The source branch is passed via --head so
 # the gate can tell the two apart. Commit subjects are always Conventional-Commits.
 # Job names are yad-hub-prefixed so they coexist with any code-repo fragment in one pipeline; jobs use
@@ -33,14 +33,14 @@ yad-hub-pr-title:
   extends: .yad_hub_mr_only
   needs: []
   script:
-    - changed="$(mktemp)"; git diff --name-only "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD" > "$changed"
+    - changed="$(mktemp)"; git -c core.quotePath=false diff --no-renames --name-only "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD" > "$changed"
     - bash checks/pr-title.sh --profile hub --head "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME" --changed "$changed" "$CI_MERGE_REQUEST_TITLE"
 
 yad-hub-pr-template:
   extends: .yad_hub_mr_only
   needs: []
   script:
-    - changed="$(mktemp)"; git diff --name-only "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD" > "$changed"
+    - changed="$(mktemp)"; git -c core.quotePath=false diff --no-renames --name-only "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD" > "$changed"
     - body="$(mktemp)"; printf '%s' "$CI_MERGE_REQUEST_DESCRIPTION" > "$body"
     - bash checks/pr-template.sh --profile hub --head "$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME" --changed "$changed" "$body"
 

package/skills/yad-checks/templates/gitlab/yad-verified-commits.gitlab-ci.yml

@@ -1,13 +1,13 @@
 # yad-managed-include: yad-checks
-# verified-commits gate for the PRODUCT HUB, as an INCLUDABLE fragment. Pulled into the hub's root
+# verified-commits gate for the PRODUCT, as an INCLUDABLE fragment. Pulled into the Product's root
 # .gitlab-ci.yml via:
 #   include:
 #     - local: '.gitlab/ci/yad-verified-commits.yml'
 # Every MR (including the Shape review/EP-* MRs) must contain only commits whose signature the
-# platform marks Verified AND whose author email is a known identity (.sdlc/verified-authors).
+# platform marks Verified. Who may author them is who has write access to the repo — no author list.
 #
 # Needs a CI/CD variable GITLAB_TOKEN (or SDLC_API_TOKEN) with read_api scope — CI_JOB_TOKEN cannot
-# read the commit-signature API. The hub's SDLC_GATE_TOKEN (from the gate-sync wiring) also works:
+# read the commit-signature API. The Product's SDLC_GATE_TOKEN (from the gate-sync wiring) also works:
 # set GITLAB_TOKEN: $SDLC_GATE_TOKEN in the job if you prefer one token.
 # Job name is yad-hub-prefixed so it can coexist with the code-repo fragment in one pipeline.
 yad-hub-verified-commits:

package/skills/yad-checks/templates/hooks/ledger-guard-cursor.sh

@@ -0,0 +1,91 @@
+#!/usr/bin/env bash
+# ledger-guard CURSOR ADAPTER — the same guard, answered in the protocol Cursor requires (E11).
+#
+# Cursor's `preToolUse` is a PERMISSION hook, and its docs are explicit: for a permission hook,
+# "invalid JSON or a response that doesn't match the hook's schema blocks the action". Empty stdout is
+# invalid JSON. The plain `ledger-guard.sh` prints nothing when it allows — so wiring it directly
+# would have blocked EVERY file write in a verified project, which is the exact opposite of this
+# guard's fail-open design.
+#
+# This wrapper guarantees one thing: a permission answer on stdout, always, whatever happens below.
+#
+#   allow   {"permission":"allow"}   exit 0
+#   deny    {"permission":"deny","user_message":"<reason>","agent_message":"<reason>"}   exit 0
+#
+# A deny exits 0 because the JSON is the authoritative answer and exit 0 is what tells Cursor to read
+# it; exit 2 blocks too, but is documented as the code for "no JSON to read" and would discard the
+# reason — and naming the command that owns the transition is the whole point of speaking at edit time.
+#
+# It takes NO arguments, deliberately. Cursor's `hooks.json` holds one command STRING and does not
+# document whether it is run through a shell, so a command with a flag in it might never be split into
+# program and argument — a command not found, silently, on every call.
+set -uo pipefail
+
+# `CDPATH=` is load-bearing, and the Cursor entry is what makes it so: that entry invokes the script
+# by a RELATIVE path, so `${BASH_SOURCE[0]}` is relative and `cd` consults $CDPATH before the current
+# directory. An exported CDPATH in a login profile — an ordinary thing to have, and inherited by the
+# harness — would resolve `hooks` to some other tree entirely, and the guard would fail open on every
+# write for as long as that profile lived.
+#
+# The loop resolves a symlinked SCRIPT, which `cd -P` does not: `-P` resolves the directory path, and
+# a script reached through a link in another directory would otherwise look for its sibling beside the
+# LINK and not find it. `readlink` without `-f` because `-f` is not portable to macOS.
+_src="${BASH_SOURCE[0]}"
+while [ -L "$_src" ]; do
+  _dir="$(CDPATH= cd -P -- "$(dirname -- "$_src")" && pwd)"
+  _src="$(readlink -- "$_src")"
+  case "$_src" in /*) ;; *) _src="$_dir/$_src" ;; esac
+done
+HOOK_DIR="$(CDPATH= cd -P -- "$(dirname -- "$_src")" && pwd)"
+ALLOW='{"permission":"allow"}'
+
+# Every failure below this line resolves to ALLOW, because this guard fails open by design and CI is
+# what fails closed. A wrapper that blocked when it could not reach `yad` would stop an agent editing
+# anything at all the moment an install went sideways.
+if [ ! -x "$HOOK_DIR/ledger-guard.sh" ]; then
+  echo "  • yad hook: $HOOK_DIR/ledger-guard.sh is missing or not executable — allowing (run \`yad check --fix\`)" >&2
+  echo "$ALLOW"
+  exit 0
+fi
+
+# stdout is CAPTURED (the JSON verdict), stderr is not (it flows through to Cursor's log). stdin is
+# inherited by the command substitution, so the tool-call payload still reaches the guard.
+raw="$("$HOOK_DIR/ledger-guard.sh" --format cursor)"
+rc=$?
+
+# THE VERDICT IS THE LAST NON-EMPTY LINE, not the whole of stdout, and it is recognised by containing
+# a `"permission"` key rather than by starting with one.
+#
+# Both halves of that matter. `yad`'s own top-level failure handler prints to STDOUT, so a usage error
+# or a crash banner can land in front of the JSON; a prefix test would then fail to recognise our own
+# deny and fall through to the allow below, turning a real refusal into a permitted write with nothing
+# on stderr to say so. And a containment test does not care what order the JSON's properties are in,
+# so the deny answer's shape on the other side of this language boundary is not silently load-bearing.
+verdict="$(printf '%s\n' "$raw" | awk 'NF { line = $0 } END { print line }')"
+
+# `ledger-guard.sh` has its own fail-open branches that exit 0 with EMPTY stdout — no `yad` on PATH,
+# an install it cannot resolve — and each one of those would otherwise reach Cursor as invalid JSON
+# and block the write.
+case "$verdict" in
+  *'"permission"'*) echo "$verdict"; exit 0 ;;
+esac
+
+# EXIT 2 IS A DENY, even with nothing on stdout — and this branch is reached in a real, ordinary case.
+# `ledger-guard.sh` resolves `yad` from the Product's own `node_modules/yadflow` BEFORE `PATH`, so a
+# project pinned to a yadflow older than `--format` parses the flag, ignores it, and answers in the
+# exit protocol: exit 2, empty stdout. Falling through to the generic allow below would turn a real
+# refusal into a permitted write, and print "exited 2 — allowing" while doing it.
+#
+# The message is a FIXED literal with nothing interpolated. The reason the older `yad` printed has
+# already gone to stderr, where Cursor logs it; escaping arbitrary multi-line text into JSON in bash
+# is exactly the sort of thing that produces an off-schema response, and there is no need to risk it.
+if [ "$rc" -eq 2 ]; then
+  echo '{"permission":"deny","user_message":"yad: this edit touches CI-owned gate state.","agent_message":"This edit touches CI-owned gate state, which CI is the sole writer of. Do not edit the ledger by hand: use `yad gate open` for the transition, and commit only the artifact. The installed yadflow is older than this hook, so the full reason is in the hook log rather than here — `yad doctor` will name the version gap."}'
+  exit 0
+fi
+
+if [ "$rc" -ne 0 ]; then
+  echo "  • yad hook: ledger-guard.sh exited $rc — allowing (run \`yad doctor\` to check the install)" >&2
+fi
+echo "$ALLOW"
+exit 0

package/skills/yad-checks/templates/hooks/ledger-guard.sh

@@ -2,7 +2,8 @@
 # ledger-guard HARNESS HOOK — the local half of the CI gate of the same name (#171).
 #
 # The gate ledger is CI-owned in verified mode: `checks/ledger-guard.sh` rejects any non-bot commit
-# that changes `epics/*/.sdlc/{state,approvals,comments,hub-prs}.json` or `epics/*/reviews/*.md`.
+# that changes `epics/*/.sdlc/{state,approvals,comments,product-prs,hub-prs}.json` or `epics/*/reviews/*.md`,
+# and the same files for the Foundation in `foundation/.sdlc/` and `foundation/reviews/` (E75).
 # This hook says so at the moment an agent tries the edit, instead of twenty minutes later in a
 # failed pipeline, and names the command that owns the transition (`yad gate open`).
 #
@@ -14,21 +15,51 @@
 #   exit 0  allow
 #   exit 2  deny, reason on stderr
 #
-# Wired for Claude Code as a `PreToolUse` hook in `.claude/settings.json` (`yad check --fix` writes
-# that entry). Any harness that can run a command and read those two exit codes can use it.
+# Wired by `yad check --fix` for every harness that can refuse a write BEFORE it lands:
+#   Claude Code  a `PreToolUse` hook in `.claude/settings.json`, pointing straight at THIS script
+#   Cursor       a `preToolUse` hook in `.cursor/hooks.json`, pointing at `ledger-guard-cursor.sh`
+#
+# DO NOT WIRE THIS SCRIPT INTO CURSOR DIRECTLY, and check the same thing before wiring it into any
+# other harness by hand. Cursor's `preToolUse` is a PERMISSION hook: it wants a JSON verdict on
+# stdout, and treats an empty or off-schema answer as a refusal. This script prints NOTHING when it
+# allows — so wired there directly it would block every file write in the project, which is the
+# opposite of the fail-open stance below. `ledger-guard-cursor.sh` exists to speak that protocol.
+#
+# A harness that reads the EXIT CODE can use this script as it stands. A hook that only fires AFTER
+# the write — Cursor's `afterFileEdit`, for one — is deliberately not used: it could report the edit
+# but never refuse it, and reporting is what the CI gate already does.
+#
+# The project root is resolved from this script's own location below, so it does not matter which
+# variable the harness sets ($CLAUDE_PROJECT_DIR, $CURSOR_PROJECT_DIR) or where it runs the command
+# from; those variables appear only in the wiring, to point at this file.
 #
 # FAIL-OPEN: if no `yad` can be found, this ALLOWS and says why on stderr. A guardrail that blocked
 # every edit the moment an install went sideways would be worse than the problem. The CI gate fails
 # CLOSED and is what actually protects the ledger.
 set -uo pipefail
 
-# The hub root is this script's grandparent — hooks/ledger-guard.sh — so the resolution below does
+# The Product root is this script's grandparent — hooks/ledger-guard.sh — so the resolution below does
 # not depend on the harness's working directory.
-HOOK_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
+# `CDPATH=` is load-bearing, and the Cursor entry is what makes it so: that entry invokes the script
+# by a RELATIVE path, so `${BASH_SOURCE[0]}` is relative and `cd` consults $CDPATH before the current
+# directory. An exported CDPATH in a login profile — an ordinary thing to have, and inherited by the
+# harness — would resolve `hooks` to some other tree entirely, and the guard would fail open on every
+# write for as long as that profile lived.
+#
+# The loop resolves a symlinked SCRIPT, which `cd -P` does not: `-P` resolves the directory path, and
+# a script reached through a link in another directory would otherwise look for its sibling beside the
+# LINK and not find it. `readlink` without `-f` because `-f` is not portable to macOS.
+_src="${BASH_SOURCE[0]}"
+while [ -L "$_src" ]; do
+  _dir="$(CDPATH= cd -P -- "$(dirname -- "$_src")" && pwd)"
+  _src="$(readlink -- "$_src")"
+  case "$_src" in /*) ;; *) _src="$_dir/$_src" ;; esac
+done
+HOOK_DIR="$(CDPATH= cd -P -- "$(dirname -- "$_src")" && pwd)"
 HUB_ROOT="$(dirname -- "$HOOK_DIR")"
 
 # Resolution order, cheapest and most specific first: an explicit override, then the copy installed
-# in this hub, then whatever is on PATH, then a network-free npx. `--no-install` matters — a hook
+# in this Product, then whatever is on PATH, then a network-free npx. `--no-install` matters — a hook
 # runs on every tool call and must never pause an agent to download a package.
 CMD=()
 _yad_bin="${YAD_BIN:-}"

package/skills/yad-checks/templates/hooks/yad-capture.sh

@@ -0,0 +1,53 @@
+#!/usr/bin/env bash
+# yad-capture HARNESS HOOK — background capture of Shape artifacts (E43).
+#
+# Runs AFTER an agent edits a file, and snapshots every changed artifact of the Product onto the
+# person's private `yad/wip/<name>/<epic>` branches — built with git plumbing, so the checkout, the
+# index and the current branch are never touched. The push runs in the background, at most once
+# every few minutes. The decision lives in `yad capture --hook`; this file only locates `yad`.
+#
+# Wired by `yad check --fix`, in BOTH ledger modes:
+#   Claude Code  a `PostToolUse` hook in `.claude/settings.json`
+#   Cursor       an `afterFileEdit` hook in `.cursor/hooks.json`
+# Any other harness: run this script (or `yad capture --hook`) after a file write.
+#
+# The contract: it ALWAYS exits 0 — a capture must never block or slow an agent. A problem is one line on
+# stderr. Stdout carries ONE thing, and only under Claude Code: when a file this edit changed is also being
+# edited by someone else (E46 claims), a PostToolUse JSON note the agent reads. Otherwise it prints nothing.
+# `YAD_CAPTURE=0`, or `"capture": false` in the Product config, turns it off.
+set -uo pipefail
+# Drain the payload the harness sends on stdin, so it never sees a broken pipe — but never wait on it: not
+# at all from a terminal (someone ran this by hand), and at most a second on a pipe that never closes.
+if [ ! -t 0 ]; then
+  while IFS= read -r -t 1 _ 2>/dev/null; do :; done
+fi
+_src="${BASH_SOURCE[0]}"
+while [ -L "$_src" ]; do
+  _dir="$(CDPATH= cd -P -- "$(dirname -- "$_src")" && pwd)"
+  _src="$(readlink -- "$_src")"
+  case "$_src" in /*) ;; *) _src="$_dir/$_src" ;; esac
+done
+HOOK_DIR="$(CDPATH= cd -P -- "$(dirname -- "$_src")" && pwd)"
+HUB_ROOT="$(dirname -- "$HOOK_DIR")"
+[ "${YAD_CAPTURE:-}" = "0" ] && exit 0
+CMD=()
+_yad_bin="${YAD_BIN:-}"
+if [ -n "${_yad_bin//[[:space:]]/}" ]; then
+  read -r -a CMD <<< "$_yad_bin"
+elif [ -f "$HUB_ROOT/node_modules/yadflow/bin/yad.mjs" ] && command -v node >/dev/null 2>&1; then
+  CMD=(node "$HUB_ROOT/node_modules/yadflow/bin/yad.mjs")
+elif command -v yad >/dev/null 2>&1; then
+  CMD=(yad)
+elif command -v npx >/dev/null 2>&1; then
+  CMD=(npx --no-install yadflow)
+else
+  echo "  • yad capture: no \`yad\` on PATH and none installed in $HUB_ROOT — nothing captured" >&2
+  exit 0
+fi
+[ "${#CMD[@]}" -eq 0 ] && exit 0
+# Claude Code sets CLAUDE_PROJECT_DIR for its hooks; it reads JSON back. Cursor reads nothing back.
+FORMAT=()
+[ -n "${CLAUDE_PROJECT_DIR:-}" ] && FORMAT=(--format claude)
+# `${FORMAT[@]+…}`: bash 3.2 (macOS) calls an empty array unbound under `set -u`.
+"${CMD[@]}" capture --hook ${FORMAT[@]+"${FORMAT[@]}"} --dir "$HUB_ROOT" </dev/null
+exit 0

package/skills/yad-commit/SKILL.md

@@ -14,7 +14,7 @@ and `yad-ship` use. It **never auto-advances**; it just commits.
 ## Conventions
 
 - Run **inside the repo holding the staged change** — a code repo under
-  `{project-root}/demo-repos/<repo>/`, or the product hub itself. Use absolute paths.
+  `{project-root}/demo-repos/<repo>/`, or the Product itself. Use absolute paths.
 - **Stage first.** Only the staged (`git add`) atomic change is committed. The guard refuses more than
   `ATOMIC_FILE_LIMIT` (3) staged files unless `--force` — split the change instead.
 - **Subject** — `<type>: <lowercase imperative description, no trailing period>`; types are
@@ -22,8 +22,8 @@ and `yad-ship` use. It **never auto-advances**; it just commits.
 - **Task trailer** — required on a code repo (anchors the `spec-link` + `commit-message` gates). Given
   with `--task` (a `<story>-T<NN>` id — an explicit value is validated against the `spec-link`
   contract, so a malformed id like a bare `EP-x-S01` fails locally instead of after a push), else
-  derived from the branch (`feat/<story>-<task>-…`). Hub commits are not
-  task-scoped, so the trailer is optional there — a missing-Task warning is informational on the hub
+  derived from the branch (`feat/<story>-<task>-…`). Product commits are not
+  task-scoped, so the trailer is optional there — a missing-Task warning is informational on the Product
   (`spec-link` is a code-repo gate) and only flags a real gate failure in a code repo.
 - **Contract-Change trailer** — `--contract-change` only when the diff touches the locked contract
   surface; it routes the change back to the architecture gate.
@@ -70,6 +70,6 @@ the architecture gate. To also open the PR/MR in the same step, use `yad-ship`.
 
 ## Reference
 - Branch/commit conventions + the file-boundary rule: `../yad-implement/references/implement-conventions.md`.
-- The full convention text: `CONTRIBUTING.md`; the config: `skills/sdlc/config.yaml` `build`.
+- The full convention text: `CONTRIBUTING.md`; the config: `.sdlc/config.yaml` `build`.
 - The gate that enforces the subject pattern: `../yad-checks/references/check-gates.md` (`commit-message`).
 - Open the PR/MR after committing: `../yad-open-pr/SKILL.md`; both at once: `../yad-ship/SKILL.md`.

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

@@ -1,13 +1,13 @@
 ---
 name: yad-connect-design
-description: 'Connects a design tool (Figma, or another tool — pluggable) to the product hub so the UI design step can materialize the full feature design (mobile screens / web pages) inside it, not just Markdown. Registers the tool into the project-wide .sdlc/design.json (local-user / MCP-session auth, no stored tokens), detecting whether a design-tool MCP is available and degrading to markdown-only when it is not. Run at setup or any time the design tool changes. Reusable, idempotent, refreshable. Use when the user says "connect Figma", "connect a design tool", "refresh the design connection", or "list the design connection".'
+description: 'Connects a design tool (Figma, or another tool — pluggable) to the Product so the UI design step can materialize the full feature design (mobile screens / web pages) inside it, not just Markdown. Registers the tool into the project-wide .sdlc/design.json (local-user / MCP-session auth, no stored tokens), detecting whether a design-tool MCP is available and degrading to markdown-only when it is not. Run at setup or any time the design tool changes. Reusable, idempotent, refreshable. Use when the user says "connect Figma", "connect a design tool", "refresh the design connection", or "list the design connection".'
 ---
 
 # SDLC — Connect a Design Tool (make the UI step design-tool aware)
 
 **Goal:** Let the UI design step (`yad-ui`) produce the **actual feature design** — the mobile screens
 and/or web pages — inside a design tool such as **Figma**, alongside the Markdown artifacts
-(`ui-design.md` / `DESIGN.md`). This skill **connects** a design tool to the product hub and records
+(`ui-design.md` / `DESIGN.md`). This skill **connects** a design tool to the Product and records
 *how* to reach it (the tool, the project/file references, which MCP renders 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 @@ markdown-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 **Figma-first but pluggable** (`config.yaml` `design.tools`): a design-tool
   *adapter*, like the GitHub/GitLab platform adapter. Figma is the primary provider; `pencil`
   (the `.pen` web/mobile editor) is a second, write-capable provider; `none` → markdown-only.
@@ -29,7 +29,7 @@ markdown-only exactly as before.
   the sibling of `.sdlc/repos.json` and `.sdlc/hub.json`.
 - Per-epic screen→frame links are written later by `yad-ui` (`epics/EP-<slug>/.sdlc/design-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
 
@@ -94,7 +94,7 @@ Nothing auto-advances; this is setup.
   **available/unavailable** flag for the MCP (best-effort, the user's own session). No design tool
   connected ⇒ "markdown-only".
 - **`disconnect`** — remove the registry file (or set `tool: "none"`). The design tool's own
-  project/files are **never touched** — only the hub's record of them.
+  project/files are **never touched** — only the Product's record of them.
 
 ## Hard rules
 

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

@@ -46,7 +46,7 @@ a screen, capture its node id + URL, and map components/tokens into `DESIGN.md`.
 
 Either direction ends by writing `epics/EP-<slug>/.sdlc/design-links.json` — the machine-readable
 screen→frame map — and a `## Design (<tool>)` section in `ui-design.md` linking each screen to its frame
-URL. The design itself lives in the tool; the hub keeps the *links* and the Markdown spec beside the
+URL. The design itself lives in the tool; the Product keeps the *links* and the Markdown spec beside the
 other epic artifacts.
 
 ## Degrade path (no MCP / no tool)

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,13 +1,13 @@
 ---
 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 Shape step — it never touches `.sdlc/state.json` or any
@@ -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.