@captain_z/zsk-skills 1.8.3 → 1.8.4

package/README.md

@@ -2,20 +2,20 @@
 
 ZNorth Standard Kit 的可安装 skill 内容包。安装面现在只保留从根级 `skills/` 生成的 **core harness-first skills**；旧 `.best-practices/` 不再批量生成独立 installable skills，而是作为参考源按 skill 携带相关子集。
 
-包内共有 **23 颗 installable skills**，全部来自根级 `skills/`。
+包内共有 **24 颗 installable skills**，全部来自根级 `skills/`。
 
 ## 合规审查（ARCHITECTURE §4.4 硬指标）
 
 | 检查项                                                                                   | 结果    | 说明                                                  |
 | ---------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------- |
-| frontmatter 完整（`name` / `description` / `category` / `domain` / `tier` / `triggers`） | ✓ 23/23 | core 由 root `skills/` 生成 |
-| `name` 使用裸 slug，扁平且不含连字符                                                       | ✓ 23/23 | LLM 原生 skill 入口保持简洁；CLI 选择层使用 `zsk:<slug>` |
-| `description` 简洁表达职责和使用时机                                                       | ✓ 23/23 | 面向索引阅读；triggers 留给机器使用 |
-| `category` / `domain` / `tier` 枚举值合法                                                | ✓ 23/23 | stage/utility · core |
-| `triggers` 数组非空                                                                      | ✓ 23/23 | 至少含裸 slug |
+| frontmatter 完整（`name` / `description` / `category` / `domain` / `tier` / `triggers`） | ✓ 24/24 | core 由 root `skills/` 生成 |
+| `name` 使用裸 slug，扁平且不含连字符                                                       | ✓ 24/24 | LLM 原生 skill 入口保持简洁；CLI 选择层使用 `zsk:<slug>` |
+| `description` 简洁表达职责和使用时机                                                       | ✓ 24/24 | 面向索引阅读；triggers 留给机器使用 |
+| `category` / `domain` / `tier` 枚举值合法                                                | ✓ 24/24 | stage/utility · core |
+| `triggers` 数组非空                                                                      | ✓ 24/24 | 至少含裸 slug |
 | 无硬编码项目名 / 技术栈（统一 `{{config.*}}` 占位符）                                    | ✓       | harness-neutral                                       |
 | `related:` 相对路径合法                                                                  | ✓       | core 不依赖参考层生成物                               |
-| 单文件 ≤ 300 行                                                                          | ✓ 23/23 | core 由 `lint:harness` 强制                           |
+| 单文件 ≤ 300 行                                                                          | ✓ 24/24 | core 由 `lint:harness` 强制                           |
 
 当前 `max-lines` 已由 `tools/lint-frontmatter.ts` 作为 error 强制；新增或修改 skill 不应超过 300 行。
 
@@ -36,10 +36,10 @@ Profile 是流程组合策略，不是新的 skill。Atomic skills 仍然平铺
 | --- | ---: | --- |
 | `zsk-entry` | 2 | 只装 `zskplan` / `zsk` 两个主入口，由它们按 harness 调度 |
 | `zsk-lite` | 11 | 小修、小项目、脚本、低风险任务 |
-| `zsk-sdlc` | 20 | 标准工程交付；需求、实现、审查、验证、验收、归档 |
-| `zsk-frontend` | 21 | UI/UX/browser-facing 交付；强化 demo、视觉证据、前端质量门禁 |
-| `zsk-enterprise` | 21 | 高治理交付；要求 deploy、验收、归档、审计证据 |
-| `sdlc-only` | 23 | 旧入口兼容；安装全部 core skills |
+| `zsk-sdlc` | 21 | 标准工程交付；需求、实现、审查、验证、验收、归档 |
+| `zsk-frontend` | 22 | UI/UX/browser-facing 交付；强化 demo、视觉证据、前端质量门禁 |
+| `zsk-enterprise` | 22 | 高治理交付；要求 deploy、验收、归档、审计证据 |
+| `sdlc-only` | 24 | 旧入口兼容；安装全部 core skills |
 
 ## Skill 搭配流程图
 
@@ -82,7 +82,7 @@ flowchart TD
 | 安装默认 core skills | `npx @captain_z/zsk add` | 交互选择 target 和 bundle |
 | CI 安装 ZSK 主入口 | `npx @captain_z/zsk add zsk-entry --target=~/.claude/skills --yes` | 非交互安装 `zskplan` / `zsk` 两个入口 |
 | CI 安装轻量 profile | `npx @captain_z/zsk add zsk-lite --target=~/.claude/skills --yes` | 非交互安装 11 颗常用 skills |
-| CI 安装标准 SDLC profile | `npx @captain_z/zsk add zsk-sdlc --target=~/.claude/skills --yes` | 非交互安装 20 颗标准 workflow skills |
+| CI 安装标准 SDLC profile | `npx @captain_z/zsk add zsk-sdlc --target=~/.claude/skills --yes` | 非交互安装 21 颗标准 workflow skills |
 | Claude plugin 安装 | `/plugin marketplace add codeshareman/zsk` 后 `/plugin install zsk@zsk` | 使用 `/zsk:<slug>` 命令面 |
 | GitHub skills 管理器安装 | `npx skills add codeshareman/zsk` | 从仓库根 `skills/` 安装；不要加 `@` |
 | 只想让 ZSK 自己规划和执行 | "用 `zsk:zskplan` 规划" / "用 `zsk:zsk` 继续" | 计划写入 `.zsk/plans/`，执行产物写入 `.zsk` |
@@ -113,8 +113,8 @@ Skills 负责更需要判断的部分：理解 SRS、PRD、API 契约、Figma/Mo
 
 | 领域              | skill 数 | 职责                                       |
 | ----------------- | -------- | ------------------------------------------ |
-| `skills/`         | 23       | harness-first 默认工作流入口               |
-| **总计**          | **23**   |                                            |
+| `skills/`         | 24       | harness-first 默认工作流入口               |
+| **总计**          | **24**   |                                            |
 
 ## 安装套件（bundles.yaml）
 
@@ -122,12 +122,12 @@ Skills 负责更需要判断的部分：理解 SRS、PRD、API 契约、Figma/Mo
 | ------------------------------ | ------ | --------------------------------------------- |
 | `zsk-entry`                    | 2      | 只安装 ZSK / ZSK Plan 两个主入口 |
 | `zsk-lite`                     | 11     | 小型低风险任务；ZSK 入口 + fix/coding → smoke → review → commit |
-| `zsk-sdlc`（推荐）             | 20     | 标准工程交付；完整需求、实现、审查、验证、验收、归档链路 |
-| `zsk-frontend`                 | 21     | 前端/视觉/browser-facing 任务；强化 demo 和前端质量门禁 |
-| `zsk-enterprise`               | 21     | 高治理交付；要求 deploy、验收、归档、审计证据 |
-| `sdlc-only`                    | 23     | 旧入口兼容；安装全部 core skills |
-| `frontend-project`             | 23     | 旧入口兼容；推荐改用 `zsk-frontend` |
-| `frontend-with-design-handoff` | 23     | 旧入口兼容；推荐改用 `zsk-frontend` |
+| `zsk-sdlc`（推荐）             | 21     | 标准工程交付；完整需求、实现、审查、验证、验收、归档链路 |
+| `zsk-frontend`                 | 22     | 前端/视觉/browser-facing 任务；强化 demo 和前端质量门禁 |
+| `zsk-enterprise`               | 22     | 高治理交付；要求 deploy、验收、归档、审计证据 |
+| `sdlc-only`                    | 24     | 旧入口兼容；安装全部 core skills |
+| `frontend-project`             | 24     | 旧入口兼容；推荐改用 `zsk-frontend` |
+| `frontend-with-design-handoff` | 24     | 旧入口兼容；推荐改用 `zsk-frontend` |
 | `custom`                       | 交互   | 通过 `zsk add` 任意多选                       |
 
 <!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 24 skills -->
@@ -139,7 +139,7 @@ Skills 负责更需要判断的部分：理解 SRS、PRD、API 契约、Figma/Mo
 ### `<slug>/` — Core · harness-first 默认工作流入口 (24)
 
 - **`zskplan`**
-  Use as the ZSK-aware RalphPlan-style planning entrypoint that freezes scope, module decomposition, skill route, expert lanes, Playwright/evidence paths, and stop conditions under .zsk.
+  Use as the ZSK-aware RalphPlan-style planning entrypoint that clarifies vague intake, then freezes scope, module decomposition, skill route, expert lanes, Playwright/evidence paths, and stop conditions under .zsk.
 
 - **`zsk`**
   Use as the ZSK-aware Ralph-style execution loop that follows ZSK plans, dispatches expert lanes, verifies, fixes, and writes only .zsk outputs.
@@ -154,7 +154,7 @@ Skills 负责更需要判断的部分：理解 SRS、PRD、API 契约、Figma/Mo
   After project init, collects resource origins, snapshots evidence, and updates config/manifests before proposal/spec.
 
 - **`preproposal`**
-  Before proposal, turns a brief request into a reviewed product, roadmap, UX, and readiness raw resource pack.
+  Before proposal, turns a one-sentence or vague intake brief into a clear, reviewed product, roadmap, UX, and readiness raw resource pack.
 
 - **`proposal`**
   Before spec, frames the problem, scope, non-goals, success criteria, stakeholders, risks, and resource gaps.

package/acceptance/SKILL.md

@@ -82,8 +82,10 @@ This core skill is governed by the ZSK harness. Enforce these rules even when on
 - Constraint levels: hard requirements and triggered conditional requirements are blocking; advisory guidance may be skipped only with rationale and no broken hard/conditional gate.
 - Required outputs: every output declared in the skill I/O contract is mandatory unless recorded as evidence-backed N/A or BLOCKED with owner, impact, and next action.
 - Collaboration: ordinary stage skills own their declared outputs and handoff quality; workflow skills own route selection. Do not hardcode the next stage inside a stage skill.
+- Stage Challenge Gate: when an existing stage artifact is present, the active skill must challenge only its own responsibility, required inputs, required outputs, must-answer questions, quality checkpoints, current artifact, upstream sources, and downstream consumer; route cross-stage gaps to their owning stage instead of running a generic grill.
 - Dynamic state awareness: identify the active role/stage, project type, stack, runtime, domain, target users/market, and freshness-sensitive decisions before selecting practices or retrieval sources.
 - Filesystem boundaries: write ZSK-managed outputs only under the configured `.zsk` workspace paths.
+- Context recording: durable terminology, naming, decomposition, and load-bearing clarification decisions must update the nearest `CONTEXT.md`, or the handoff must record `Context update: N/A` with rationale.
 - Learning loop: reusable gaps become learning proposals; never mutate core constraints, templates, packs, or skills automatically.
 - Learning authority: reusable ZSK core learning must target the canonical ZSK source repo `.zsk/learning/proposals/`; project-local learning may stay in the current project.
 
@@ -95,7 +97,7 @@ When a `harness/` directory is installed beside this file, treat it as the local
 - Read `harness/workflow/state-machine.yaml` and `harness/constraints/stage-gates.md` before moving between stages.
 - Read `harness/constraints/skill-role-contract.md` before planning or reviewing expert work.
 - Read `harness/constraints/filesystem-boundaries.md` before creating any project artifact.
+- Record durable project/module language in `.zsk/modules/{module}/CONTEXT.md` or `.zsk/docs/CONTEXT.md` before relying on it downstream.
 - Read `harness/constraints/evidence-rules.md` and `harness/workflow/completion-contract.yaml` before claiming READY / PASS / DONE.
 - Read `harness/constraints/issue-taxonomy.md` before creating or updating blockers, risks, defects, or questions.
 - Apply the related best-practice concerns listed in `harness/THIS_SKILL.md`; read bundled `harness/best-practices/` files first when they are listed for the current skill. Search Context7 or the web only when local guidance or local facts are missing, incomplete, stale, too generic, version-sensitive, market-sensitive, or role-incomplete. Record source links, source dates when relevant, and adaptation rationale in the evidence or learning proposal.
-

package/acceptance/harness/THIS_SKILL.md

@@ -91,6 +91,10 @@ This file is generated for the installed skill. Read it before executing this sk
 - Expose the required output contract in the artifact or handoff so the next skill can verify what was produced, blocked, or N/A.
 - Separate facts, decisions, assumptions, open questions, risks, blockers, and evidence.
 - Trace required claims to source artifacts, accepted decisions, scenarios, commands, issues, or human decisions.
+- When an existing stage artifact is present, the active skill must run its own Stage Challenge Gate before downstream handoff: derive the challenge focus from that skill's responsibility, required inputs, required outputs, must-answer questions, quality checkpoints, current artifact, upstream sources, and downstream consumer; classify sourced, accepted, assumed, conflicting, missing, and N/A claims, then repair or block through the owning stage.
+- Keep Stage Challenge Gates skill-local: ask, repair, or block only on questions the active skill owns; route upstream or downstream findings to the owning stage instead of absorbing another skill's responsibility.
+- Every Stage Challenge Gate must align terminology against CONTEXT.md/CONTEXT-MAP.md when present, SYSTEM-SPEC.md, configured raw sources, current artifact identifiers, and code/component/API names when implementation-facing work is touched.
+- Record durable terminology, naming, decomposition, and load-bearing clarification decisions in the nearest CONTEXT.md, or write `Context update: N/A` with rationale.
 - Preserve upstream/downstream stage ownership; do not silently rewrite another skill's artifact.
 - Record accept, reject, or conditional acceptance decision with linked verify/demo evidence.
 - Name accepted criteria, residual risks, owners, and documentation feedback or no-update rationale.
@@ -104,6 +108,7 @@ This file is generated for the installed skill. Read it before executing this sk
 - When behavior is testable, define or consume a traceable test basis before claiming implementation, smoke, review, verify, or acceptance success.
 - When external facts, SDKs, APIs, regulations, market context, or dependency behavior are freshness-sensitive, retrieve current authoritative references or record why local sources are sufficient.
 - When an artifact becomes too large for one reviewable file, split it into `{stage}/index.md` plus linked child Markdown files while preserving the full stage contract.
+- When clarification, grilling, architecture review, artifact repair, or task decomposition introduces a term or naming decision future stages must reuse, update module-local or project-level CONTEXT.md before handoff.
 - When residual risks affect security, privacy, permissions, data, release, or compliance, require owner and follow-up issue.
 - When business/user confirmation is missing, mark acceptance BLOCKED instead of inferred.
 
@@ -112,6 +117,7 @@ This file is generated for the installed skill. Read it before executing this sk
 - Prefer the smallest artifact that lets the next reader decide and act without chat memory.
 - Use tables, matrices, diagrams, or checklists only when they clarify ownership, traceability, risk, or execution.
 - Use project terminology and source identifiers consistently across proposal, spec, design, task, and evidence artifacts.
+- When a skill challenges an artifact, name any overloaded, translated, or conflicting term before asking the user or editing the artifact.
 - Record suggestions separately from current project policy, especially for thresholds that remain `未指定`.
 - Keep acceptance focused on decision and risk, not implementation recap.
 - Preserve rejection reasons in a form that can route back to issue/fix.
@@ -134,7 +140,11 @@ This file is generated for the installed skill. Read it before executing this sk
 - Accepts different project methods and artifact names only when they provide an equivalent control point with evidence.
 - Uses PASS, FAIL, BLOCKED, or N/A only with evidence; missing mandatory evidence remains a failure, not an assumption.
 - Records numeric targets or thresholds as `未指定` when the project has not supplied them; never invents thresholds to make an output look complete.
+- Records `Context update: <path>` or `Context update: N/A` so later stages do not depend on hidden chat terminology.
+- Names terminology alignment status for the active artifact: source-consistent, repaired, conflicting, missing, or N/A.
 - Names owner, dependency, acceptance condition, and verification evidence for every required output or blocker.
+- Names existing stage artifact clarity status as PASS, NEEDS_REPAIR, BLOCKED, or WAIVED when a prior artifact is being consumed or improved.
+- Names the Stage Challenge Gate focus and shows it came from the active skill contract rather than a generic grill.
 - Runs or references the stage-entry quality gate before downstream handoff; below-threshold but non-blocking gaps require explicit risk acceptance instead of silent progression.
 - For testable work, verifies test correctness, not only test execution: traceable test basis, meaningful assertions, negative/boundary/regression coverage, and skipped/unrun checks called out.
 - When proposal, spec, design, or tasks become too large for one reviewable file, the artifact may split to `{stage}/index.md` plus linked child Markdown files; the index remains the entrypoint and the full stage contract still applies.
@@ -171,6 +181,10 @@ This file is generated for the installed skill. Read it before executing this sk
 - Passing because a familiar term appears while the equivalent lifecycle function is absent.
 - Inventing project policy, quality thresholds, source mappings, or platform behavior without configured evidence.
 - Treating missing evidence as low risk when the stage output depends on that evidence.
+- Discarding or rewriting an unclear existing stage artifact before classifying what is sourced, accepted, assumed, conflicting, or missing.
+- Running a generic grill or cross-stage rewrite instead of the active skill's own Stage Challenge Gate.
+- Letting terminology, naming, or decomposition decisions live only in chat instead of CONTEXT.md.
+- Running stage-specific questioning without checking whether the artifact uses the same terms as upstream sources, downstream consumers, and implementation surfaces.
 - Letting a delayed subagent packet block indefinitely instead of marking it stale and falling back or re-emitting.
 - Claiming tests prove behavior when they have no traceable basis, no meaningful assertion, or only prove implementation details.
 - Accepting without verification evidence.

package/acceptance/harness/constraints/filesystem-boundaries.md

@@ -5,8 +5,10 @@ Default project paths:
 - `.zsk/`: the only default ZSK-managed workspace root.
 - `.zsk/docs/`: project-level docs such as `SYSTEM-SPEC.md` and `PROJECT-CONFIG.md`.
 - `.zsk/modules/{module}/`: module config and stage artifacts.
+- `.zsk/modules/{module}/CONTEXT.md`: module-local domain language, naming decisions, decomposition rationale, and accepted clarifications that later stages must reuse.
+- `.zsk/docs/CONTEXT.md`: project-wide domain language and cross-module terms when a term is not owned by one module.
 - `.zsk/raws/`: raw external source snapshots, manifests, imported test cases, market/product research sources, and design/API assets.
-- `.zsk/raws/prepare/**`: reusable source lanes. `preproposal` may add generated or candidate product, roadmap, UX, and design-source readiness resources here only when they are labeled with provenance, review checkpoint status, assumptions, and blockers.
+- `.zsk/raws/prepare/**`: reusable source lanes. `preproposal` may add generated or candidate intake clarity, product, roadmap, UX, and design-source readiness resources here only when they are labeled with provenance, review checkpoint status, assumptions, and blockers.
 - `.zsk/evidence/preproposal/{run}/`: checkpoint review evidence for product direction, roadmap/decomposition, UX/design-readiness, and final readiness before formal proposal.
 - `.zsk/modules/{module}/_issues/`: module-private managed issue records and indexes, created on demand.
 - `.zsk/modules/{module}/_evidence/`: module-private reusable runtime or research evidence, created on demand.
@@ -19,6 +21,21 @@ Default project paths:
 
 Root `docs/`, `.raws/`, `.issues/`, `.playwright/`, and `plans/` are not default write targets for ZSK skills. Use explicit export, promote, import, or migration commands when project-facing root documentation is needed.
 
+## Context Recording Authority
+
+Every durable terminology, naming, decomposition, or load-bearing clarification
+created during a Clarification Loop, artifact clarity pass, architecture review,
+stage repair, or task decomposition must be recorded in the nearest
+`CONTEXT.md`.
+
+- Module-local terms and decisions go to `.zsk/modules/{module}/CONTEXT.md`.
+- Cross-module or project-wide terms go to `.zsk/docs/CONTEXT.md`.
+- ZSK core terms go to the source repo `CONTEXT.md`.
+- If no update is needed, the stage handoff records a no-update rationale.
+- Do not use `CONTEXT.md` for transient notes, raw evidence, task execution
+  logs, or unresolved speculation; record those in the owning artifact, issue,
+  evidence directory, or learning proposal.
+
 ## Learning Output Authority
 
 Learning artifacts must be written according to what they are meant to change:
@@ -45,4 +62,4 @@ This rule applies to every underscore module directory, not only `_issues`. For
 
 The skill that produces the final artifact for a module stage writes the formal report to `.zsk/modules/{module}/{stage}.md`. For large `proposal`, `spec`, `design`, or `tasks` artifacts, the skill may upgrade the stage artifact to `.zsk/modules/{module}/{stage}/index.md` and split child Markdown files under the same stage directory. The `index.md` file remains the review entrypoint, must link every child document included in the logical artifact, and must preserve the same stage contract; splitting content does not weaken required gates. Supporting artifacts stay in the appropriate `_issues`, `_evidence`, or `_playwright` directory unless they are deliberately shared/global/public.
 
-`preproposal` is not a module-final stage. Its outputs are proposal-prep raw resources under `.zsk/raws/prepare/**` plus checkpoint evidence under `.zsk/evidence/preproposal/{run}/`. It must not create `.zsk/modules/{module}/proposal.md`, `spec.md`, `design.md`, or `tasks.md`; those remain owned by their formal stage skills.
+`preproposal` is not a module-final stage. Its outputs are intake clarity and proposal-prep raw resources under `.zsk/raws/prepare/**` plus checkpoint evidence under `.zsk/evidence/preproposal/{run}/`. When a target module is specified, use the module id as the default raw topic, for example `.zsk/raws/prepare/ux/{module}/interaction-handoff.md`, and record any narrower page/frame split rationale in the raw artifact. It must not create `.zsk/modules/{module}/proposal.md`, `spec.md`, `design.md`, or `tasks.md`; those remain owned by their formal stage skills.

package/acceptance/harness/constraints/skill-role-contract.md

@@ -54,12 +54,12 @@ Each skill owns one stage contract. Workflow skills may route or schedule work,
 | Skill | Owns | Does Not Own | Consistency / Handoff |
 | --- | --- | --- | --- |
 | `prepare` | Source discovery, configured origin validation, raws snapshots, manifest, source gaps | Product interpretation, requirements decisions, design choices | Hands source manifest, raws indexes, conflicts, and blockers to `proposal` / `spec`; asks before uncertain source-to-lane mapping |
-| `preproposal` | Proposal-prep raw resources: product direction, MVP/phase/module decomposition, UX/design-readiness seeds, assumptions, risks, scenario seeds, checkpoint review evidence | Formal module proposal/spec/design/tasks, formal test cases, implementation | Hands reviewed `.zsk/raws/prepare/**` resources and `.zsk/evidence/preproposal/**` checkpoint verdicts to `proposal`; product review must pass before roadmap, roadmap before UX, UX before readiness |
+| `preproposal` | Intake clarity, proposal-prep raw resources: product direction, MVP/phase/module decomposition, UX/design-readiness seeds, interaction handoff when triggered, candidate code component mapping when code exists, assumptions, risks, scenario seeds, checkpoint review evidence | Formal module proposal/spec/design/tasks, formal test cases, final implementation decisions | Hands reviewed `.zsk/raws/prepare/**` resources and `.zsk/evidence/preproposal/**` checkpoint verdicts to `proposal`; source-discoverable questions must be answered before asking the user; product review must pass before roadmap, roadmap before UX, UX before readiness |
 | `proposal` | Problem, goal, scope, non-goals, stakeholders, risks, success metrics, decision request | Detailed behavior, architecture, task breakdown, implementation | Every goal and metric must trace to sources or accepted assumptions; hands bounded scope to `spec` |
 | `spec` | FR/NFR, acceptance criteria, scenarios, edge cases, constraints, traceability, behavior-level control matrix when triggered | Architecture, file/module design, implementation tasks | Every P0/P1 requirement must trace to proposal/source and be testable; cross-cutting control behavior must trace to subject/action/resource/scope/source; hands behavior contract to `design` and `task` |
-| `design` | Architecture, interfaces, data/state flow, design views/diagrams, ADRs or equivalent decision records, tradeoffs, rollout and verification surfaces, control traceability matrix when triggered | Rewriting requirements, task sequencing, coding, decorative diagrams | Every design decision and diagram must trace to spec/AC/NFR, ADR, risk, or verification need; triggered controls must trace to enforcement/UI/API/state/test surfaces; hands implementation map to `task` |
+| `design` | Code design: architecture, interfaces, data/state flow, implementation surfaces, design views/diagrams, ADRs or equivalent decision records, tradeoffs, rollout and verification surfaces, control traceability matrix when triggered | Rewriting requirements, authoring interaction handoff, deciding missing UX/Figma behavior, task sequencing, coding, decorative diagrams | Every design decision and diagram must trace to spec/AC/NFR, ADR, risk, or verification need; triggered controls must trace to enforcement/UI/API/state/test surfaces; hands implementation map to `task` |
 | `task` | Kiro-style nested checkbox task groups/subtasks, owners, dependencies, scope/files, evidence hooks, proposal/spec/design/ADR coverage matrix, control-row task coverage when triggered | Changing proposal/spec/design intent, coding, review approval | Every task group must align to proposal/spec/design/ADR IDs; every subtask must be executable and evidence-backed before `coding`; triggered control rows must map to implementation and evidence tasks |
-| `coding` | Scoped implementation, changed tests, implementation notes, local validation evidence | Requirements changes, broad refactors, final approval | Every diff maps to task IDs and preserves upstream intent; hands changed files and evidence to `smoke` / `review` |
+| `coding` | Scoped implementation, vertical TDD cycles, changed tests, implementation notes, local validation evidence | Requirements changes, broad refactors, final approval | Every diff maps to task IDs and preserves upstream intent; each testable behavior records RED/GREEN evidence before the next behavior; hands changed files and evidence to `smoke` / `review` |
 | `smoke` | Smallest credible local proof of changed behavior, failure classification, smoke issues | Full acceptance, final verification, release approval | Hands command/scenario evidence and failures to `review`, `defect`, or `ready` |
 | `review` | Scope drift, correctness, maintainability, security, test adequacy, harness compliance findings | Implementing fixes, independent verification, business acceptance | Findings must reference files/artifacts and route fix work to `issue` / `defect` / `coding`; no PASS without evidence adequacy |
 | `commit` | Scoped staging, Lore commit message, commit evidence, known verification gaps | Feature validation, release readiness | Hands immutable change intent and tested/not-tested evidence to `deploy` / `archive` |
@@ -107,13 +107,116 @@ Consistency checks:
 - No skill silently changes another skill's artifact; it records a feedback item, issue, or blocker instead.
 - Workflow skills (`flow`, `zskplan`, `zsk`) choose the route. Stage skills state status, blockers, handoff needs, and next legal candidates only.
 
+## Stage Artifact Clarity Pass
+
+Every stage owns clarity and repair for the artifacts it owns. If a stage artifact
+already exists but is unclear, incomplete, contradictory, placeholder-like, or too
+weak for the next consumer, the workflow must route to the owning stage instead
+of restarting from intake, skipping ahead, or letting a downstream skill repair
+upstream intent.
+
+This is a skill-local Stage Challenge Gate, not a generic grilling session. The
+active skill must auto-identify what to challenge from its own responsibility,
+required inputs, required outputs, must-answer questions, quality checkpoints,
+current artifact, upstream sources, and downstream consumer. It may surface
+upstream or downstream findings, but those findings are routed to the owning
+stage instead of being silently absorbed.
+
+The challenge basis is also skill-local: use this skill's `THIS_SKILL.md`,
+`skill-quality-standards.yaml`, bundled related best-practice files, and current
+official references when local references are incomplete or version-sensitive.
+Do not reuse another stage's checklist as the active challenge unless the finding
+is routed back to that owning stage.
+
+Every skill-local challenge also performs terminology alignment. Compare the
+artifact's domain terms, actor names, module names, stage IDs, FR/AC/NFR/ADR IDs,
+UI component names, route/API names, and source/provider labels against
+`CONTEXT.md` / `CONTEXT-MAP.md` when present, `.zsk/docs/SYSTEM-SPEC.md`,
+configured raw sources, and implementation names when the skill touches code or
+UI surfaces. If a term is overloaded, stale, translated inconsistently, or
+conflicts with upstream/downstream language, classify it explicitly and route the
+repair to the owning stage. Do not introduce a new canonical term only in chat.
+
+The owning stage must:
+
+- preserve the current artifact as evidence and avoid wholesale rewrite unless
+  the artifact is explicitly superseded;
+- state the Stage Challenge Gate focus for this skill, such as proposal
+  problem/scope clarity, spec behavior/AC traceability, design implementation
+  mapping, task execution readiness, or evidence-stage claim validity;
+- classify material claims as `sourced`, `accepted`, `assumed`, `conflicting`,
+  `missing`, or `N/A`;
+- classify terminology conflicts and accepted canonical names with source or
+  context references;
+- repair only the claims that local/configured sources, accepted decisions, or
+  current evidence support;
+- ask at most one blocking question when the missing answer changes scope,
+  behavior, design, task order, or verification;
+- report `Stage artifact clarity: PASS | NEEDS_REPAIR | BLOCKED | WAIVED`
+  with owner, missing input, impact, next action, and downstream consumer.
+
+Examples:
+
+- unclear `proposal` routes to `proposal` for problem/scope/non-goal repair;
+- unclear `spec` routes to `spec` for FR/AC/scenario/source-trace repair;
+- unclear `design` routes to `design` for interface, ADR, data-flow, or control
+  traceability repair;
+- unclear `tasks` routes to `task` for executable checkbox, ownership,
+  dependency, source-alignment, and evidence-hook repair.
+
+## Context Recording Discipline
+
+ZSK treats `CONTEXT.md` as durable project language, not chat memory. When a
+Clarification Loop, artifact clarity pass, architecture review, stage repair, or
+task decomposition creates or sharpens terminology, naming, module/decomposition
+rationale, accepted clarification, or a load-bearing "call this X, not Y"
+decision, the owning skill must update the nearest `CONTEXT.md` before handoff.
+
+Context targets:
+
+- module-local language and decomposition decisions:
+  `.zsk/modules/{module}/CONTEXT.md`;
+- project-wide or cross-module language: `.zsk/docs/CONTEXT.md`;
+- reusable ZSK core language: the source repo `CONTEXT.md`.
+
+The update must separate accepted terms from rejected/ambiguous framings and
+state the downstream impact. If no context update is needed, the handoff records
+`Context update: N/A` with a short reason. A downstream stage must not rely on a
+term that only exists in chat.
+
+## Coding TDD Cycle Discipline
+
+`coding` uses vertical TDD, not horizontal batching. For each testable behavior
+or defect slice:
+
+1. Select one behavior from task, AC, issue, or accepted clarification.
+2. Write or update one public-interface behavior test or scenario expectation.
+3. Run that focused test and record RED evidence. If RED cannot be observed
+   because the harness, fixture, or dependency is unavailable, record the tool
+   gap before implementation.
+4. Implement the smallest code change that can make this behavior pass.
+5. Run the focused test again and record GREEN evidence before starting another
+   behavior.
+6. Refactor only while GREEN, then rerun the affected focused test.
+
+The coding handoff must list cycles separately. A final full-suite result is
+useful only after the vertical cycles; it must not replace per-behavior evidence.
+
 ## Preproposal Team Simulation
 
 `preproposal` is one workflow-node with role lanes, not a set of standalone skills.
 
+Before lane work begins, the lead-integrator owns intake clarity. A one-sentence
+or vague requirement must be restated as known facts, inferred assumptions,
+source gaps, non-goals, and at most one blocking question. The lead must inspect
+available repo docs, code, `.zsk` sources, glossary, and decision records before
+asking the user. Every blocking question includes the recommended answer and
+tradeoff, and accepted clarification is recorded as fact, decision, assumption,
+or open question.
+
 - Product-owner and business-analyst lanes own product direction, user/problem framing, business process, scope options, non-goals, risks, and evidence gaps.
 - Planner and architect lanes own MVP/phase/module decomposition, dependency shape, boundary rationale, deferred work, and feasibility risks.
-- UX and design-specialist lanes own user journey, IA/navigation seeds, interaction states, usability/accessibility risks, and design-source needs.
+- UX and design-source lanes own user journey, IA/navigation seeds, interaction handoff when triggered, interaction states, usability/accessibility risks, provider-backed source maps, and design-source needs during `preproposal`.
 - QA and researcher lanes own scenario seeds, risk seeds, test-basis candidates, current external evidence when needed, and source gaps.
 - Verifier/lead-integrator owns checkpoint completeness, blocker creation, raw manifest/index update or no-update rationale, and readiness handoff.
 

package/acceptance/harness/constraints/source-of-truth.md

@@ -15,6 +15,8 @@ When sources conflict, the stage artifact must record the conflict instead of si
 - Requirements, behavior, scenario order, acceptance criteria, and test expectations must trace back to PRD/SRS, spec, design, task, raw source, code, runtime evidence, or user clarification.
 - Do not invent missing requirements, UI behavior, business rules, edge cases, or test expectations from preference or convention.
 - If the facts are incomplete, ambiguous, conflicting, or insufficient to decide, stop the stage decision and ask for clarification after summarizing the known sources and tradeoffs.
+- For vague intake, ask only after checking local and configured sources; ask one blocking question at a time and include the recommended answer plus tradeoff.
+- If an existing stage artifact is unclear, preserve it as a source instead of discarding it. The owning stage must run its own Stage Challenge Gate, derive the challenge focus from its active skill contract, and classify each important claim as sourced, accepted, assumed, conflicting, or missing before repairing or blocking.
 - If asking is blocked, record a resource gap or issue instead of silently choosing a path.
 - Best practices may shape implementation, but they cannot override project facts or accepted design documents.
 - Before applying a role, run dynamic state awareness: identify the current stage, role, project type, domain, language, framework, SDKs, runtime tools, target market, and freshness-sensitive decisions from local config, module docs, manifests, lockfiles, imports, raw sources, and existing evidence.

package/acceptance/harness/constraints/stage-gates.md

@@ -14,6 +14,8 @@ The harness computes gate status. Skills may propose outputs and record evidence
 
 - For testable behavior changes, `task` should define the test/scenario hook before `coding`.
 - `coding` should start by creating or updating the targeted test/scenario when one does not already cover the behavior.
+- `coding` must run vertical TDD cycles: one behavior -> one failing test or changed test expectation -> minimal implementation -> passing evidence -> next behavior. Do not batch all tests first or all implementation first.
+- Each cycle records behavior id, source task/AC/issue, RED evidence or an explicit reason RED cannot be observed, GREEN evidence, changed files, and refactor evidence when a refactor occurs.
 - `smoke`, `review`, and `verify` must reject tests that cannot be traced to PRD/SRS, spec/design, task, issue, or accepted user clarification.
 - If the test contract is unclear, the stage is `blocked` until the uncertainty is clarified or recorded as a resource gap.
 
@@ -26,12 +28,34 @@ The harness computes gate status. Skills may propose outputs and record evidence
 - Missing required artifacts, placeholder-only upstream docs, missing project/system rules for governed stages, or missing mandatory test basis remain `BLOCKED`; a risk waiver must not convert those into PASS. Very short but non-placeholder artifacts are quality gaps, not hard blockers.
 - Thresholds are project policy. When no project threshold is configured, the CLI default is an advisory 9/10 gate; documents must still record unsupplied numeric thresholds as `未指定` instead of inventing policy.
 
+## Stage Artifact Clarity Gate
+
+- This gate applies to every stage-owned artifact: preproposal raw pack, proposal, spec, design, tasks, implementation handoff, smoke/demo/review/ready/verify reports, acceptance, archive, issue, and learning outputs.
+- When the artifact already exists but is unclear, incomplete, contradictory, placeholder-like, or too weak for its downstream consumer, the workflow must route to the owning stage for that skill's Stage Challenge Gate instead of skipping ahead, discarding the artifact, running a generic grill, or silently rewriting it from another stage.
+- The clarity pass must derive its challenge focus from the active skill contract: responsibility, required inputs, required outputs, must-answer questions, quality checkpoints, current artifact, upstream sources, and downstream consumer.
+- The clarity pass must apply the active skill's bundled related best-practice
+  files and quality standards when their domain is touched. If the bundled
+  references are missing, stale, too generic, version-sensitive, or not matched
+  to the current stack/domain, record the gap and retrieve official/current
+  references before issuing a best-practice challenge.
+- The clarity pass must align terminology against project sources before asking
+  or repairing: `CONTEXT.md` / `CONTEXT-MAP.md` when present, `SYSTEM-SPEC.md`,
+  configured raw sources, current stage artifact identifiers, and existing
+  code/component/API names when the skill touches implementation-facing work.
+  Conflicting or overloaded terms must be classified as conflicting/missing and
+  routed to the owning stage instead of silently renaming them.
+- The clarity pass must classify important claims as sourced, accepted, assumed, conflicting, missing, or N/A; it must name the skill-local challenge focus, downstream consumer, required outputs, source links, blockers, and next action.
+- The owning stage may patch or split its own artifact when local/configured sources support the repair. If the missing fact belongs to an upstream stage, record upstream feedback or route to that stage; if only one answer blocks direction, ask one blocking question with a recommended answer and tradeoff.
+- Durable terminology, naming, decomposition rationale, and load-bearing clarification decisions found during the clarity pass must update the nearest `CONTEXT.md`, or the handoff must record `Context update: N/A` with rationale.
+- Clarity status is `PASS`, `NEEDS_REPAIR`, `BLOCKED`, or `WAIVED`. `NEEDS_REPAIR` cannot progress downstream without an explicit risk acceptance; `BLOCKED` must include owner, missing input, impact, and next action.
+
 ## Preproposal Checkpoint Gate
 
 - Use `preproposal` when a brief request lacks reviewed product direction, roadmap/decomposition, UX/design-readiness, or source-readiness material for `proposal`.
+- Intake clarity runs before product work. It must inspect available sources first, separate known facts from inferred assumptions and gaps, and ask at most one blocking question with a recommended answer when the answer would materially change direction.
 - Product checkpoint must pass before roadmap/decomposition starts. It reviews target users, problem, outcome, scope options, non-goals, risks, assumptions, and source gaps.
 - Roadmap/decomposition checkpoint must pass before UX/detail work starts. It reviews MVP/1.0/2.0 or equivalent phase split, module boundaries, dependencies, deferred work, and merge/split/block rationale.
-- UX/design-readiness checkpoint must pass before readiness handoff. It reviews user journey, IA/navigation seeds, interaction states, accessibility/usability risks, and design-source needs.
+- UX/design-readiness checkpoint must pass before readiness handoff. It reviews user journey, IA/navigation seeds, interaction handoff when triggered, interaction states, accessibility/usability risks, source maps, and design-source needs.
 - Readiness checkpoint must pass before formal `proposal`. It verifies that `.zsk/raws/prepare/**` and `.zsk/evidence/preproposal/{run}/` contain enough reviewed raw material for proposal without chat memory.
 - A checkpoint failure loops only while the missing input is actionable. Repeated failures beyond the configured retry limit, or default 2 when no project policy exists, become a tracked blocker/issue with owner, missing source, impact, and next action.
 - Preproposal checkpoint reviews use the target-aware `review` skill. They must not require module `spec`, `design`, `tasks`, or `smoke` artifacts unless the explicit review target is an implementation/code-diff review.

package/acceptance/harness/profiles/frontend.yaml

@@ -1,9 +1,9 @@
 name: zsk-frontend
-description: Frontend delivery profile with design, demo, and visual quality gates.
+description: Frontend delivery profile with code design, demo, and visual quality gates.
 extends: zsk-sdlc
 purpose: >
   Use for UI, UX, visual, interaction, accessibility, and browser-facing work
-  where design handoff, demo evidence, and frontend quality checks matter.
+  where preproposal readiness, demo evidence, and frontend quality checks matter.
 
 stages:
   required:
@@ -82,7 +82,6 @@ strictness:
 
 bestPractices:
   required:
-    - design-handoff.md
     - frontend.md
     - quality.md
   recommended:

package/acceptance/harness/workflow/completion-contract.yaml

@@ -1,11 +1,12 @@
 version: 1
 defaults:
-  required: [artifact, evidence, issue_sync, documentation_feedback]
+  required: [artifact, evidence, issue_sync, documentation_feedback, context_record]
   rules:
     artifact: "Every skill run must declare produced artifacts and write them to project-template paths, not only to chat."
     evidence: "Every pass/fail or completion claim must link local evidence."
     issue_sync: "Actionable findings must classify scope, update the concrete issue in module-private or shared/global/public storage, and refresh module/global issue indexes."
     documentation_feedback: "Confirmed learnings must update spec/design/task docs or record a no-update rationale."
+    context_record: "Terminology, naming, decomposition, and load-bearing clarification decisions must update the nearest CONTEXT.md, or the handoff must record Context update: N/A with rationale."
     execution: "Completion work may be done by a skill-local script or by the agent's normal file-editing tools, but the harness contract decides the required outputs."
     stage_gate: "Downstream progression requires a recorded gate assessment or explicit N/A rationale; non-blocking quality gaps need risk acceptance before continuing."
     durable_dispatch: "Dispatched lanes must leave a durable ledger and packet statuses; stale or timed-out lanes require fallback evidence before completion."
@@ -23,6 +24,11 @@ defaults:
       issues: ".zsk/issues/global/"
       evidence: ".zsk/evidence/global/"
       playwright: ".zsk/playwright/global/"
+      context: ".zsk/docs/CONTEXT.md"
+    context:
+      module: ".zsk/modules/{module}/CONTEXT.md"
+      project: ".zsk/docs/CONTEXT.md"
+      zskCore: "CONTEXT.md in the canonical ZSK source checkout"
     public:
       issues: ".zsk/issues/public/"
       evidence: ".zsk/evidence/public/"
@@ -45,10 +51,15 @@ outputs:
       - ".zsk/raws/prepare/product/{topic}/product-brief.md"
       - ".zsk/raws/prepare/product/{topic}/roadmap.md"
       - ".zsk/raws/prepare/ux/{topic}/ux-readiness.md"
+      - ".zsk/raws/prepare/ux/{topic}/interaction-handoff.md when UI, UX, or design-source interaction is triggered"
+      - ".zsk/raws/prepare/ux/{module}/interaction-handoff.md when a target module and UI, UX, or design-source interaction are triggered"
       - ".zsk/raws/prepare/design/{topic}/design-source-needs.md"
+      - ".zsk/raws/prepare/design/{topic}/design-source-map.md when provider-backed design sources such as Figma are used"
+      - ".zsk/raws/prepare/design/{module}/design-source-map.md when a target module uses provider-backed design sources such as Figma"
       - ".zsk/evidence/preproposal/{run}/checkpoint-product-review.md"
       - ".zsk/evidence/preproposal/{run}/checkpoint-roadmap-review.md"
       - ".zsk/evidence/preproposal/{run}/checkpoint-ux-review.md"
+      - ".zsk/evidence/preproposal/{run}/checkpoint-interaction-review.md when interaction handoff is triggered"
       - ".zsk/evidence/preproposal/{run}/readiness-review.md"
     feedbackTargets: [".zsk/raws/manifest.json", ".zsk/raws/index.md", ".zsk/evidence/preproposal/{run}/readiness-review.md"]
   proposal:

package/acceptance/harness/workflow/skill-io-contract.yaml

@@ -28,8 +28,29 @@ principles:
     and how the evidence changes the recommendation.
   - "Do not decide from uncertainty: summarize conflicting or missing facts and
     ask, or record a resource gap."
+  - For vague intake, answer discoverable questions from local sources first,
+    then ask one blocking question at a time with a recommended answer and
+    tradeoff.
   - "TDD first for testable behavior: tests and scenarios must be accurate and
     traceable to PRD/SRS, spec/design, task, issue, or accepted clarification."
+  - When an existing stage artifact is unclear, incomplete, contradictory, or
+    too weak for its downstream consumer, route to the owning stage's
+    skill-local Stage Challenge Gate before downstream work; preserve the
+    artifact, derive challenge focus from the active skill's contract, classify
+    gaps, repair what sources support, and ask only one blocking question when
+    needed.
+  - "A Stage Challenge Gate is not a generic grill: proposal challenges problem
+    and scope, spec challenges behavior contracts, design challenges
+    implementation mapping, task challenges execution readiness, and later
+    evidence stages challenge the claim they own."
+  - When clarification, grilling, architecture review, stage repair, or task
+    decomposition creates or sharpens project/module terminology, naming,
+    decomposition rationale, or load-bearing decisions, update the nearest
+    `CONTEXT.md` or record an evidence-backed no-update rationale.
+  - "For coding, use vertical TDD cycles for testable behavior: one behavior,
+    one failing test or changed test expectation, minimal implementation,
+    passing evidence, then the next behavior. Do not write all tests first and
+    then all code."
   - Stage skills own their declared outputs and handoff quality; workflow skills
     own route selection. Every handoff must preserve upstream/downstream
     consistency instead of relying on chat memory.

package/acceptance/harness/workflow/skill-quality-standards.yaml

@@ -85,6 +85,23 @@ defaults:
       and evidence.
     - Trace required claims to source artifacts, accepted decisions, scenarios,
       commands, issues, or human decisions.
+    - "When an existing stage artifact is present, the active skill must run its
+      own Stage Challenge Gate before downstream handoff: derive the challenge
+      focus from that skill's responsibility, required inputs, required outputs,
+      must-answer questions, quality checkpoints, current artifact, upstream
+      sources, and downstream consumer; classify sourced, accepted, assumed,
+      conflicting, missing, and N/A claims, then repair or block through the
+      owning stage."
+    - "Keep Stage Challenge Gates skill-local: ask, repair, or block only on
+      questions the active skill owns; route upstream or downstream findings to
+      the owning stage instead of absorbing another skill's responsibility."
+    - Every Stage Challenge Gate must align terminology against
+      CONTEXT.md/CONTEXT-MAP.md when present, SYSTEM-SPEC.md, configured raw
+      sources, current artifact identifiers, and code/component/API names when
+      implementation-facing work is touched.
+    - "Record durable terminology, naming, decomposition, and load-bearing
+      clarification decisions in the nearest CONTEXT.md, or write `Context
+      update: N/A` with rationale."
     - Preserve upstream/downstream stage ownership; do not silently rewrite
       another skill's artifact.
   conditionalRequirements:
@@ -107,6 +124,9 @@ defaults:
     - When an artifact becomes too large for one reviewable file, split it into
       `{stage}/index.md` plus linked child Markdown files while preserving the
       full stage contract.
+    - When clarification, grilling, architecture review, artifact repair, or
+      task decomposition introduces a term or naming decision future stages must
+      reuse, update module-local or project-level CONTEXT.md before handoff.
   advisoryGuidance:
     - Prefer the smallest artifact that lets the next reader decide and act
       without chat memory.
@@ -114,6 +134,8 @@ defaults:
       ownership, traceability, risk, or execution.
     - Use project terminology and source identifiers consistently across
       proposal, spec, design, task, and evidence artifacts.
+    - When a skill challenges an artifact, name any overloaded, translated, or
+      conflicting term before asking the user or editing the artifact.
     - Record suggestions separately from current project policy, especially for
       thresholds that remain `未指定`.
   qualityCheckpoints:
@@ -134,8 +156,16 @@ defaults:
       evidence remains a failure, not an assumption.
     - Records numeric targets or thresholds as `未指定` when the project has not
       supplied them; never invents thresholds to make an output look complete.
+    - "Records `Context update: <path>` or `Context update: N/A` so later stages
+      do not depend on hidden chat terminology."
+    - "Names terminology alignment status for the active artifact:
+      source-consistent, repaired, conflicting, missing, or N/A."
     - Names owner, dependency, acceptance condition, and verification evidence
       for every required output or blocker.
+    - Names existing stage artifact clarity status as PASS, NEEDS_REPAIR,
+      BLOCKED, or WAIVED when a prior artifact is being consumed or improved.
+    - Names the Stage Challenge Gate focus and shows it came from the active
+      skill contract rather than a generic grill.
     - Runs or references the stage-entry quality gate before downstream handoff;
       below-threshold but non-blocking gaps require explicit risk acceptance
       instead of silent progression.
@@ -164,6 +194,15 @@ defaults:
       behavior without configured evidence.
     - Treating missing evidence as low risk when the stage output depends on
       that evidence.
+    - Discarding or rewriting an unclear existing stage artifact before
+      classifying what is sourced, accepted, assumed, conflicting, or missing.
+    - Running a generic grill or cross-stage rewrite instead of the active
+      skill's own Stage Challenge Gate.
+    - Letting terminology, naming, or decomposition decisions live only in chat
+      instead of CONTEXT.md.
+    - Running stage-specific questioning without checking whether the artifact
+      uses the same terms as upstream sources, downstream consumers, and
+      implementation surfaces.
     - Letting a delayed subagent packet block indefinitely instead of marking it
       stale and falling back or re-emitting.
     - Claiming tests prove behavior when they have no traceable basis, no

package/acceptance/harness/workflow/stage-contracts.yaml

@@ -6,8 +6,8 @@ contracts:
     outputs: [resource-manifest, resource-gaps]
   preproposal:
     requiredResources: [brief-or-request, zsk-config]
-    optionalResources: [project-config, system-spec, existing-product-design, existing-roadmap, existing-ux-design, design-sources, market-research, user-research, stakeholder-notes, resource-manifest]
-    outputs: [preproposal-raw-pack, product-brief, roadmap-decomposition, ux-flow-seeds, design-source-needs, assumptions-ledger, risk-ledger, scenario-seeds, checkpoint-review-evidence, readiness-handoff]
+    optionalResources: [target-module, module-docs, module-context, project-config, system-spec, existing-product-design, existing-roadmap, existing-ux-design, design-sources, market-research, user-research, stakeholder-notes, resource-manifest]
+    outputs: [preproposal-raw-pack, module-scoped-raw-pack-when-targeted, intake-clarity-brief, accepted-clarifications, product-brief, roadmap-decomposition, ux-flow-seeds, interaction-handoff-when-triggered, module-scoped-interaction-handoff-when-targeted, design-source-needs, design-source-map-when-triggered, assumptions-ledger, risk-ledger, scenario-seeds, checkpoint-review-evidence, readiness-handoff]
   proposal:
     requiredResources: [project-config, system-spec, requirements]
     optionalResources: [reviewed-preproposal-raw-pack, market-research, competitor-research, pricing-research, user-personas, user-research, business-model, regulatory-sources]
@@ -18,8 +18,8 @@ contracts:
     outputs: [project-rules-gate, spec, scenario-contracts, behavior-control-matrix-when-triggered]
   design:
     requiredResources: [project-config, system-spec, spec, code]
-    optionalResources: [api-contracts, design-sources, design-assets, user-personas, competitive-benchmarks]
-    outputs: [project-rules-gate, design, design-views, adr-decision-records, locator-strategy, control-traceability-matrix-when-triggered, playwright-scenario-plan]
+    optionalResources: [api-contracts, reviewed-preproposal-raw-pack, user-personas, competitive-benchmarks]
+    outputs: [project-rules-gate, design, design-views, adr-decision-records, locator-strategy, ui-implementation-mapping-when-triggered, control-traceability-matrix-when-triggered, playwright-scenario-plan]
   task:
     requiredResources: [project-config, system-spec, spec, design]
     outputs: [project-rules-gate, kiro-style-nested-checkbox-todo-list, proposal-spec-design-adr-alignment-matrix, control-row-task-coverage-when-triggered, tasks, playwright-case-skeletons, scenario-synthesis-plan]