create-yss-spec 3.3.1 → 3.3.3

package/template/.claude/skills/yss-product-lifecycle/references/orchestration.md

@@ -1,136 +0,0 @@
-# 编排执行协议
-
-## 有界推进循环
-
-1. 识别模式、仓库身份、任务规模和影响面。
-2. `setup readiness`：每个任务只执行一次，核对 tracker、五态标签和领域文档布局，并在本轮缓存结果；仅在 tracker、主远端、真实标签或配置变化时重查。
-3. 加载父 Ticket/checkpoint 与真实资产，计算最近可信阶段。
-4. 评估资产、门禁和 `stale`，选择第一个未阻塞工作单元。进入 `work-unit.slice-implementation` 前，必须先通过 `scripts/lib/lifecycle-transition.mjs` 的 Ticket 正式化、垂直切片绑定和合法 `next_route` 校验；父 Ticket、缺少垂直切片或 `ready-for-human` 的切片一律 `blocked`。
-5. 执行最小生命周期工作单元：主控先按 `docs/process/schemas/digital-human-task-package.schema.json` 编译并校验任务包，再只实际调用允许的 model-invoked skill；原生工作单元可直接持有正式资产，Matt 兼容 user-invoked skill 仅作为 workflow reference，仍由用户显式启动。将结果归一化为 `Workflow Execution Result`，验收输出并回写状态与证据。任务包的 `contract.kind` 按工作单元选择；只有实现子任务使用 `slice-implementation` 并消费 Slice Implementation Contract，其他阶段不伪造该合同。
-6. 若仍在授权和自动推进边界内，回到第 3 步；否则暂停。
-
-不要仅输出下一个提示词后结束 `orchestrate`/`resume`。不要因进入业务代码阶段而退出主控；应把实现交给专项 skill，并在返回后继续核验。
-
-连续阶段自动推进时累积 Ticket 同步和 Git 判断证据，在人工暂停、handoff、进入实现、合并或发布边界集中 checkpoint。发生阻塞、责任人变化或资产需要单独批准时立即落 checkpoint，不因合并记录而丢失阶段因果关系。
-
-## 执行成本
-
-执行策略以 `orchestration-contract.yaml.execution_efficiency` 为准，通过同一次 `query-lifecycle-context` 查询取得。Plan → Spec → Ticket 的耗时应分清脚本执行、Agent 读取与编排、人工等待；没有计时记录时不把总时长归因于摘要计算。
-
-同一工作单元把 mode、stage、work-unit 和必要 include 放进一次查询。查询已给出的内容不再整份读取；已读资料在当前任务内未变化时复用，变化、新影响或恢复时重新加载。只问当前阶段尚缺且会影响判断的问题，独立问题可合并；依赖尚未形成资产的后续批准仍按用户决定协议逐边界取得。
-
-资产写入稳定后、批准或流转前执行当前合同要求的验证。同一边界内，只有输入字节、上游、验证器/schema、参数和仓库根均已确认未变化且实际结果可读时，才引用已执行结果；不确定就重跑。每个工作单元仍生成并校验自己的 context reconciliation；恢复、交接、实现、合并和发布边界重新执行适用验证。`verify-*-scenarios` 与模板全量核验用于模板维护或明确的回归任务，不因产品阶段切换而重复执行；实例合同显式要求的检查仍须执行。
-
-脚本命令、实际退出码和 duration_ms 记入已有 checkpoint 的验证证据；Agent 编排和人工等待仅在有计时来源时记录，否则标为 unknown。无需为耗时再建一套阶段产物。
-
-## 阶段边界
-
-Matt phase boundary 是工作阶段之间的上下文决策，不是新的生命周期状态。按以下顺序判断，第一项适用即停止判断：
-
-1. **Continue**：下一阶段需要当前会话作为 primary source，或当前上下文仍在 smart zone 内。
-2. **`/clear`**：当前探索、死路和决策对下一阶段完全无关。
-3. **`/handoff`**：内容必须跨新 harness、新目录、同事或中途分叉的 side task 携带。
-4. **Subagent**：工作单元边界清晰，可以在无人值守时完成并返回报告。
-5. **`/compact`**：同一 harness、同一目录且上下文仍相关，但需要压缩后继续；它是最后选项。
-
-在 checkpoint 记录 `phase_boundary.decision`；使用 `handoff`、subagent 或 `compact` 时同时记录契约要求的引用。phase boundary 不得改变生命周期阶段、门禁或 Ticket 五态。
-
-## 原型到后端脚手架的接力
-
-阶段 5 在技术分析后固定进入 `work-unit.implementation-repository-preparation`。编排器按 backend / frontend 影响逐项目展示已有或新建工程、Agent 推荐、仓库 scope、目标路径、Git 初始化、验证命令和风险，取得真实用户确认后再执行。已有工程调用 `implementation-repo-onboarding`；新后端按已确认架构调用对应生成器；新前端调用 `yss-frontend-scaffold-generator`。默认 `external-repository`，`harness-apps` / `git-submodule`、`git init` 和远端仓库创建均须显式选择或授权。
-
-所有命中项目必须达到 `existing-and-onboarded` 或 `initialized-and-verified`，未命中的交付面必须有带原因的 `not-applicable`。聚合结果、Manifest、验证和 onboarding 证据必须可读且当前；否则 `gate.implementation-repositories-ready` 阻断 Ticket 正式化。旧实例恢复时保留已有 Ticket，但将相关 Ticket / Slice Contract 标为 `blocked` / `stale` 并返回本工作单元。
-
-`prototype_confirmation` 通过后，先判断实现仓库登记中的 backend `scaffold_status`。当状态为 `required` 时，在工程基线中先完成脚手架架构选择：Agent 按领域复杂度给出 `domain-driven` / `layered-mvc` 推荐和依据，本体选择作为子项目预填默认值，用户通过批量表确认全部项目或逐项覆盖。选择写入 `scaffold-architecture-decisions.yaml`；处于 `undecided`、`recommended`、`awaiting-user-decision` 或 `stale` 时必须阻断，不得默认 DDD，也不得在生成器内交互。
-
-选择达到 `lifecycle-approved` 且 digest 当前后，由 `yss-implementation-contract-compiler` 编译脚手架 schema v3 `controlled-generation` 工作单元合同，生命周期批准并持久化后才能运行对应生成器。顺序为：工程基线与架构推荐 → 用户确认与选择持久化 → 实现合同编译器脚手架合同 draft → 生命周期批准/持久化 → `domain-driven` 使用 `yss-ddd-scaffold-generator` 或 `layered-mvc` 使用 `yss-layered-mvc-scaffold-generator` → 对应基线/Manifest v3 校验 → 实现合同编译器业务合同重编译。`existing` / `initialized` 不重复生成；架构转换必须单独立项。
-
-脚手架工作单元必须使用结构化 schema v3 合同 JSON，至少记录 `contract_id`、`contract_version`、`scaffold_request_id`、`architecture_family`、`generator_skill`、`decision_ref/id/digest`、Profile、能力模块闭包、实现合同编译器 draft 引用、生命周期批准引用、持久化引用、当前版本、允许写路径、预期证据文件和验证命令；不得使用 `slice_id` 伪造工程基线身份。生成器必须读取合同和决策文件并校验状态、digest、版本、skill、工作模式与固定命令。三条 Wrapper 命令必须由受控工作单元真实执行，逐条留存 `exit_code`、`duration_ms`、stdout/stderr 引用和执行时间；生成器打印的下一步命令不构成证据。非空目标、`--force`、旧项目迁移和模板升级均阻断。脚手架不得生成业务规则、状态机、权限、事务、复杂查询、错误映射、用户可见行为或示例业务 API；`validate` 通过、输出目录存在或生成器成功都不是生命周期批准、架构放行或 `ready-for-agent`。
-
-脚手架完成后，所有后续生成的后端代码仍必须重新消费当前版本的批准 Slice Implementation Contract、YSS skill 依赖闭包、允许写路径、预期证据和 Execution Result。业务行为使用 `behavior-tdd`；只有机械结构、样板、配置和冻结客户端使用 `controlled-generation`。缺少合同、skill、证据或实际验证时立即阻断；生成范围从机械内容变成业务行为时触发完整重路由。
-
-## Setup readiness
-
-Readiness 结果在同一任务内复用。只有 tracker、主远端、真实标签或配置发生变化，才重新执行检查；不得把 `setup-matt-pocock-skills` 当作每阶段或每工作单元的固定动作。
-
-| 状态 | 判定 | 动作 |
-|---|---|---|
-| `ready` | tracker、Local `Status:` 或远程标签和领域布局兼容 | 继续 |
-| `missing` | 必要配置缺失 | `needs-human`；说明缺失项并请用户显式运行 `setup-matt-pocock-skills`，随后回到 readiness |
-| `conflict` | 多个持久配置或真实标签/Local 状态互相矛盾 | 暂停并提出迁移方案，不覆盖 |
-| `degraded` | 已选择的 GitHub/GitLab 不可用 | 建 `docs/.scratch/<feature>/` 待发布草案，不改投平台 |
-| `not-applicable` | `template-source` | 只验证模板契约 |
-
-远程 tracker 必须检查真实标签；Local Markdown 必须检查功能包目录和 Ticket 顶部的 `Status:`。仅有 `docs/agents/triage-labels.md` 不代表远程标签存在，也不能替代 Local 文件状态检查。
-
-tracker 选择和冲突按 `docs/agents/issue-tracker.md` 裁决：已持久化 tracker 配置优先，本模板默认 `local-markdown`，Local root 为 `docs/.scratch/`；用户在初始化/迁移时明确选择 GitHub/GitLab 后才切换，Git remote 只代表代码托管。Local 主 tracker 不要求远程 Ticket；只有已选择远程平台但凭据不可用时，才降级为 `docs/.scratch/<feature>/` 待发布草案，不自动改投其他平台。发现根 `.scratch/` 或 `docs/requirements/tickets/` 旧资产时，保留 `migration_ref` 并暂停写入；新旧路径同时存在时返回 `conflict`。恢复前记录最终平台、真实五态标签或 Local `Status:` 检查结果和草案位置。
-
-## Matt flow 进入条件
-
-- `work-unit.technical-analysis` 由 `yss-technical-design` 组织后端技术设计，先按项目确认架构，再调用 DDD `yss-tactical-design` 或传统 MVC `yss-mvc-design`。状态、规则、一致性、持久化影响本身不意味着选择 DDD。无后端技术设计影响记录带原因的 `not-applicable`，其他 API / 前端技术分析继续各自路由。新合同使用 `artifact.technical-design`，通过 `evidence.technical-design-review` 回交现有架构审查；旧 DDD 稳定 ID 只读兼容。批准仍由生命周期维护，编译器消费批准且当前的设计起草实现合同；`stale`、`drift` 或 `new_impacts` 时不得继续 Ticket 正式化。
-
-- `work-unit.plan-requirements` 实际调用 `grilling` 和 `domain-modeling`；`work-unit.plan-opportunity` 按事实类型路由 `competitive-intelligence` 或 `yss-research`。`yss-research:quick` 只用于探索；外部证据进入领域战略、阶段决策或其他生命周期批准输入前必须升级为 `evidence-audited`。生命周期原生工作单元默认负责 Spec、Ticket 和实现资产；`to-spec`、`to-tickets`、`implement` 仅保留为显式兼容入口，结果必须回交生命周期验收。
-- 原生 `work-unit.ticket-decomposition` 只能在 OpenAPI Freeze 或无 API 影响记录后创建垂直切片，初始 Ticket 状态统一为 `ready-for-human`；生命周期复算完整公式后才能提升 `ready-for-agent`。该工作单元必须返回 `ticket_decomposition_result_ref` 和垂直切片引用，并作为实现的必经前置证据。
-- 原生 `work-unit.slice-implementation` 必须在生命周期批准并持久化 Slice Implementation Contract 和 Build Architecture Checklist 后执行；用户显式 `implement` 仍走兼容入口，不得绕过生命周期。
-- `Workflow Execution Result.next_route` 必须通过生命周期转换校验；Spec、原型和技术分析不得直接跳转到 Ticket 正式化或实现，必须先完成 `work-unit.implementation-repository-preparation`，再进入 `work-unit.ticket-decomposition`。
-- `implement` 遇到 backend `scaffold_status=required` 时，还必须满足原型确认后的脚手架策略：脚手架 Execution Result、`yss-backend-scaffold-parent` 基线、Wrapper 验证和 实现合同编译器 合同重编译均已回写；否则停在工程基线，不得写业务代码。
-- `Workflow Execution Result` 出现 `drift`、`new_impacts`、`stale_candidates`、`violation`、`missing_evidence`、空 `evidence_refs` 或缺少必需字段时暂停当前工作单元；旧结果只能先经只读兼容 adapter 归一化。
-
-## 审查与验证
-
-- 调用 `code-review` 前先固定 review input：`review_mode`、`review_base_ref`、`implementation_candidate_ref`、`candidate_snapshot_ref`、`candidate_digest`、Spec/Ticket、Slice Implementation Contract、Build Architecture Checklist 和 YSS Skill Execution Result 引用。`committed` 模式审查不可变 `HEAD`；`worktree` 模式一次捕获 committed、staged、unstaged 和 untracked 内容。必须按 `orchestration-contract.yaml.review_input` 的 manifest 按模式必填字段及 `yss-worktree-candidate-v1` 字节流（raw path、uint64 big-endian 长度、tracked/untracked record）计算 SHA-256，两个 Reviewer 必须消费同一不可变快照。返回后或完成 checkpoint 摘要变化时返回 `blocked`，由编排器决定重新审查。候选为空、漏项或 fixed point 不可解析时阻断。
-- 小改动和中等变更可由同一独立执行者完成 `code-review` 与 fresh verification，并在同一报告中分别记录 findings、命令、结果和残余风险。
-- 该执行者必须独立于实现者；新模块、高风险变更、职责冲突或需双人控制时，Reviewer 与 Verifier 分开。
-- `code-review` 是唯一默认代码审查 skill。GitLab、CI、Sonar、Alibaba Java 与 YSS 前端 / 后端 skill 作为仓库规则或专项检查输入接入 Standards 轴，由 `review_standards_route` 按影响面编译；不再叠加第二个通用审查 skill。漏掉合同 `required_skills`、适用报告行空白、mandatory `violation` 未关闭或可机器检查规则既无工具结果也无原文引用时，不得 `completed`。
-- 产品切片与模板维护共用同一 finding 闭环，强度分别绑定 Slice 合同与 L1 / L2 / L3。`violation`、机器检查失败、适用行空白由实现者在原合同路径修复，再重新捕获候选并全轴复审。`drift`、`new_impacts`、`required_skills` 与真实影响不一致时合同 `stale`，回 实现合同编译器 或更早阶段，禁止在旧合同上继续编码。审查者不得写实现。`not-applicable` 仅当影响面未命中；命中后 mandatory 不得豁免，只允许修复或完整 `seam-deferred`。禁止为日常 Alibaba / YSS 新增生物人豁免门禁。
-- 独立 Reviewer 必须与实现者不同实例，并在能执行已登记 `pnpm` / `./mvnw` 的运行时中审查。模板源 `.cursor/environment.json` 只服务模板校验，不替代实现仓审查运行时。不为此再创建第二个 Cloud 审查环境或 `/code-review` skill。
-- UI 影响切片将 `UI fidelity` 作为 `code-review` 的条件第三轴；任何修复都会使候选摘要失效，必须重新捕获候选并重跑 Standards、Spec、UI fidelity 和 fresh verification。
-
-## Git 授权
-
-实现授权、`orchestrate`/`resume` 的有界写入、当前分支和 Git checkpoint 都不蕴含 commit 或 push 授权。执行 commit 前必须同时取得 `commit_authorized=true`、非空 `commit_scope` 和 `commit_authorization_ref`；执行 push 前必须同时取得 `push_authorized=true`、非空 `push_scope` 和 `push_authorization_ref`。任一缺失时只记录 checkpoint 判断并保持 Git 状态不变；负责人要求、时间压力、测试通过或“本地 commit 可逆”都不能补足用户授权。
-
-`repository_scope: git-submodule` 时授权按仓分别计算：禁止在 detached HEAD 提交；commit / push 顺序必须先子仓、再父仓 gitlink（`superproject-gitlink-update`）；父仓 push 使用 `git push --recurse-submodules=check`。空 gitlink、detached HEAD、`--force` 覆盖挂载点不得当成普通目录脚手架，也不得把实现源码复制进 Harness。登记字段必须能与 `harness-apps` / `external-repository` 区分，并对照工作树 gitlink。
-
-## 用户决定与恢复
-
-关键决定使用 [真实用户回复协议](user-decisions.md)，消费角色注册表的 `user_decision_policy`。会签前先形成可审阅资产；恢复、阶段流转、实施派发和发布时校验原始回复及当前资产摘要。普通会签的数字人审查与用户决定分别保留，关键决定不得以数字人会签、无反对意见或超时放行。等待只阻断依赖事项；新的 `user_decisions` 引用通过 Workflow Execution Result、checkpoint 和任务包传递。
-
-## 必须暂停
-
-- Spec baseline、需求冻结、原型确认、OpenAPI Freeze 或 Architecture Review 等普通门禁等待会签裁决（数字人或生物人，以 `docs/agents/digital-human-roles.yaml` 的 `gate_policy` 为准）。暂停输出必须包含：门禁 ID、指定 `role_id`、`runtime_id`、会签文件路径。恢复前执行 `scripts/verify-approval-record --require-approved`；角色错误、起草者自签或生物人门禁被数字人关闭时返回 `blocked`，不得标 `approved`。
-- 需要目标仓库、外部凭据、发布窗口或其他新授权。
-- 状态与证据冲突且无法可靠重建。
-- 专项 skill 失败或返回不可验收结果。
-- 即将作出可合并、可发布或完成结论。
-
-暂停输出：门禁、指定会签 `role_id`、`runtime_id`、会签文件路径、证据、推荐答案、一个问题、恢复动作。
-
-## Context Plan 与质量基线
-
-实现合同先消费 `common.context_plan`：必需上下文只包含 `CONTEXT.md`、已批准 Spec、当前合同和适用 ADR / 工程基线；专项 references、实现仓库文件和历史证据按影响面按需加载。达到最小充分证据后停止扩展，缺失权威上下文只能 `blocked` 或 `reroute`。
-
-质量标准由 `engineering-baseline` 以 `baseline_id` / `baseline_version` 定义一次，Slice Contract、YSS Skill Execution Result、`code-review` 和发布检查只引用它，并将约束结果写入 `constraint_results`。命中 API / 数据迁移、跨仓契约、发布回滚、实际安全行为或生命周期 / 生成语义时，必须在现有决策或审查记录中完成 Doubt-Driven 主张、反证、证据、残余风险和 Reviewer 引用；普通低风险变更不触发该流程。
-
-## Wayfinder 完成判定
-
-“无 frontier”不等于完成。只有以下条件同时成立，才能 `wayfinder → handoff → to-spec`：
-
-- open child tickets 为 0；
-- 不存在 open blocked 或 open claimed child ticket；
-- `Not yet specified` 无剩余 fog；
-- destination 已清晰。
-
-Decision ticket 产生决策，不是实现切片，不得标记 `ready-for-agent`。
-
-## `grill-with-docs` 退出判定
-
-进入 `to-spec` 前必须区分已确认项与未决项，并确认用户、问题、MVP、非目标、成功标准、术语/ADR 候选和测试 seam。事实问题走 `yss-research`；需 runnable 反馈的问题走 `handoff → prototype → handoff`。存在未回流 blocker 时不得进入 Spec baseline。
-
-Prototype 回流必须有可核验证据：来源 handoff、prototype 资产或运行记录、结论、被更新的 Spec/设计/ADR/Ticket 引用、剩余未决项和返回 handoff。仅在对话中声称“已验证”不算回流完成。
-
-Matt `prototype` 的回流还必须注明 `prototype_branch`，并保留单文件 HTML 主来源；该结果只能作为 YSS 原型输入，仍须完成阶段 4 的低保真评审、H1/H2 档位路由、schema v3 验证和用户确认，不得用 throwaway prototype 替代。
-
-`to-questionnaire` 未收到答案时使用 `external-input-required` 暂停，记录问卷、接收人、所需输出和恢复路由；收到答案后记录 response、重新分类影响面和更新后的权威资产，再回到 `grill-with-docs` 或 `to-spec`。
-
-Release 与 Retrospective 属于生命周期编排器拥有的工作单元。发布和复盘前都必须重新取得 fresh verification；发布还需要发布/回滚证据和独立审查，复盘还需要复盘记录和治理回流判断，再回流权威资产。

package/template/.claude/skills/yss-product-lifecycle/references/state-model.md

@@ -1,120 +0,0 @@
-# 生命周期状态模型
-
-## 命名空间
-
-| 域 | 允许值 |
-|---|---|
-| `lifecycle.status` | `routing`、`running`、`paused-human-gate`、`blocked`、`completed` |
-| `workflow.status` | `not-started`、`active`、`paused`、`resolved`、`failed` |
-| `artifacts.*.status` | `missing`、`draft`、`ready-for-human`、`approved`、`stale`、`not-applicable` |
-| `gates.*.status` | `not-evaluated`、`blocked`、`ready-for-human`、`approved`、`stale`、`not-applicable` |
-| `tracker.kind` | `local-markdown`、`github`、`gitlab` |
-| `ticket.role` | `needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix` |
-
-Matt 五态不得扩义。资产的 `ready-for-human` 与 Ticket label 必须带命名空间表达。`paused-human-gate` 表示等待 `docs/agents/digital-human-roles.yaml` 指定的会签人（数字人或生物人），不是「必须是生物人」。但 `user_decision_policy` 命中的关键决定还必须有真实用户回复，数字人会签不能解除该等待。
-
-## 上下文与外部输入证据
-
-状态模型不新增 context 状态域。阶段边界只在状态块或 checkpoint 中保存可选证据：
-
-```yaml
-phase_boundary:
-  decision: continue # continue / clear / handoff / subagent / compact
-  reason: <why-this-choice>
-  source_ref: null
-  destination_ref: null
-  task_package_ref: null
-  convergence_ref: null
-  next_phase: null
-```
-
-`handoff` 必须有来源和目的地；subagent 必须有任务包和汇合证据；`compact` 必须有下一阶段。`Continue`、`clear` 不要求跨上下文引用，但仍应记录判断理由。
-
-`to-questionnaire` 的暂停使用 `pause.reason_code: external-input-required`，并保存 `questionnaire_ref`、`recipient_role`、`requested_outputs` 和 `resume_route`。答案回流后补 `response_ref`、`reclassified_impact` 和 `updated_authoritative_asset`，然后重新计算 `stale`、门禁和可执行 frontier。
-
-## `ready-for-agent` 公式
-
-仅当以下全部为真，垂直切片 Ticket 才能获得该 Ticket 状态：
-
-```text
-required gates ∈ {approved, not-applicable}
-AND 关键决定及当前切片实施范围已有可追溯、当前且未撤回的真实用户批准
-AND related artifacts 不含 stale（若命中技术设计影响，`artifact.technical-design` 必须已批准且版本当前、架构一致；旧 DDD 合同仅按显式兼容入口消费）
-AND blocking edges 全部关闭
-AND `gate.implementation-repositories-ready` 已通过，所有命中的前后端项目均为 `existing-and-onboarded` 或 `initialized-and-verified`，未命中的交付面有带原因的 `not-applicable`
-AND `work-unit.implementation-repository-preparation` 已返回当前且证据可读的 `completed` 结果
-AND implementation repo/branch/CI/test/rollback 已明确
-AND `work-unit.ticket-decomposition` 已返回 `completed`，且其 `ticket_decomposition_result_ref` 证据可读取
-AND `vertical_slice_ticket_ref` 指向 `docs/.scratch/<feature>/issues/` 下的垂直切片 Ticket
-AND `vertical_slice_ticket_kind=vertical-slice-ticket` 且 `vertical_slice_ticket_role=ready-for-agent`
-AND `vertical_slice_ticket_ref` 不得指向 `parent-ticket.md`
-AND Slice Implementation Contract 已由生命周期编排器批准并持久化
-AND Slice Implementation Contract 的 `ticket_ref` 与 `vertical_slice_ticket_ref` 完全一致
-AND 当前工作单元消费的 contract_id/version 与最新批准版本一致
-AND Backend Slice Implementation Contract（后端适用）和 Build Architecture Checklist 已完成
-AND backend 影响且 scaffold_status=required 时，脚手架架构选择已由用户确认并达到 lifecycle-approved、兼容 schema v3 或统一 schema v4 合同与 Manifest 当前、对应 DDD / Layered MVC 基线、Wrapper 验证和 实现合同编译器重编译均已完成
-AND frontend 影响且无已有工程时，统一 schema v4 Project Scaffold Contract 已批准、持久化且当前，模板 commit 已锁定，`pnpm install --frozen-lockfile` 与工程基线要求的 lint/type-check/build 已实际通过
-AND 所有后续生成代码均绑定主 YSS skill、依赖闭包、允许写路径、预期证据和 YSS Skill Execution Result
-AND UI 影响切片的前端实现还原计划已通过 schema 校验、`template=false`、`status=approved`，且基线引用可读取
-```
-
-父 Ticket、Spec、设计、原型、OpenAPI Draft、wayfinder map 和 decision ticket 不得使用 `ready-for-agent`。
-
-发布前还必须满足所有已触发门禁均为 `approved` 或 `not-applicable`；UI 影响切片必须额外通过 `gate.frontend-implementation-verified`，不能只凭 fresh verification 和回滚点放行。
-
-任何 `project-instance` 工作单元进入下一步、任何阶段会签暂停或阶段完成 checkpoint，还必须引用当前工作单元的 `context_reconciliation`。其中 `status=reconciled`、`context_ref=CONTEXT.md`、`document_digest` 与 `referenced_terms_digest` 必须和根目录唯一 `CONTEXT.md` 一致；该证据不改变门禁数量。`template-source` 仅允许以带原因的 `not-applicable` 表示它只校验模板合同，不产生产品业务术语。
-
-用户显式运行 `to-tickets` 后，垂直切片初始 Ticket 状态固定为 `ready-for-human`。原生路径执行 `work-unit.ticket-decomposition` 时同样必须产生等价的垂直切片和 `Workflow Execution Result` 证据。只有 `yss-product-lifecycle` 复算上述公式全部为真后，才能把它提升为 `ready-for-agent`；生命周期不会自动调用 `to-tickets`，但不得跳过实现仓库准备和 Ticket 正式化工作单元。旧实例恢复时若缺少当前工程准备结果，保留既有 Ticket，将 Ticket 与 Slice Contract 标为 `blocked` / `stale` 并回到阶段 5。其默认标签也不参与该裁决。
-
-## Review 与 Git 授权状态
-
-进入代码审查时保存 `review_mode`、`review_base_ref`、`implementation_candidate_ref`、`candidate_snapshot_ref`、`candidate_digest` 及 Spec、Ticket、合同、Checklist、YSS Execution Result 引用，并记录专项检查覆盖与机器检查结果。`worktree` 候选必须一次捕获 committed、staged、unstaged 和 untracked 文件；manifest 的按模式必填字段以及 `yss-worktree-candidate-v1`（raw path、uint64 big-endian 长度、tracked/untracked record、symlink 和不支持条目）以 `orchestration-contract.yaml.review_input` 为唯一执行定义。两个 Reviewer 消费同一不可变快照；返回后或完成 checkpoint 摘要变化则返回 `blocked` 并重新审查。Finding 分流不新增生命周期状态：`violation` 仍在当前合同路径由实现者修复后复审；`drift` / `new_impacts` 把合同标 `stale` 并走既有重路由。该清单只作为审查证据。
-
-Git 动作分别保存 `commit_authorized`、`commit_scope`、`commit_authorization_ref`、`push_authorized`、`push_scope`、`push_authorization_ref`。只有授权值严格为 `true`、范围和用户授权引用均非空时才执行相应动作；缺失授权时保持工作区不变并记录 checkpoint 判断。`git-submodule` 另保存每仓授权、`checkout_state` 和先子后父顺序；空 gitlink、detached HEAD 或 `--force` 覆盖挂载点时不得当成普通目录 commit / 脚手架。
-
-## 状态块
-
-状态块位于主 tracker 的功能父 Ticket，并使用 `docs/process/templates/lifecycle-checkpoint-template.yaml` 的结构化形状和 `lifecycle-checkpoint.schema.json` 校验；Local Markdown 使用 `docs/.scratch/<feature>/parent-ticket.md`，可将完整 checkpoint 保存在 `docs/.scratch/<feature>/gates/lifecycle-checkpoint.yaml` 后由父 Ticket 引用，远程 tracker 使用 Issue 并在本地功能包保留引用。平台不可用时才位于 stage checkpoint。只保存索引、状态、引用和因果关系：
-
-```yaml
-lifecycle:
-  schema_version: 1
-  mode: resume
-  stage: system-data-architecture-and-contract-review
-  status: blocked
-workflow:
-  matt_flow: main
-  active_skill: yss-openapi-draft-review
-  status: paused
-artifacts:
-  spec: {status: approved, ref: docs/.scratch/example/spec.md}
-  openapi: {status: stale, ref: docs/.scratch/example/api/example.yaml, stale_by: [spec]}
-gates:
-  openapi_freeze: {status: stale}
-tracker:
-  kind: local-markdown
-  root: docs/.scratch
-  parent_ticket: docs/.scratch/example/parent-ticket.md
-  role: ready-for-human
-pause:
-  reason_code: human-gate
-  gate_ref: requirement-freeze
-  owner_or_authority: product-owner
-  resume_condition: requirement-freeze-approved
-  next_work_unit: api-impact-assessment
-```
-
-## Schema 兼容与迁移
-
-- 当前只支持 `schema_version: 1`，支持版本列表以 `orchestration-contract.yaml` 为准。
-- 版本缺失、解析失败或版本不在支持列表时，必须暂停并进入迁移检查；不得按 v1 猜测、覆盖或降级写回。
-- 主 tracker 的父 Ticket 状态块优先作为主索引；Local Markdown 的 `docs/.scratch/<feature>/parent-ticket.md` 是主载体，远程 Issue 只是显式选择远程 tracker 时的主载体。根 `.scratch/` 与 `docs/requirements/tickets/` 只作为旧路径迁移来源。stage checkpoint 只在选定平台不可用时降级。两者版本或内容冲突时，不做字段级静默合并：读取真实资产重建新状态，保留旧块引用和迁移记录，再由人工确认主载体。
-- 不得用旧版本状态覆盖较新版本。迁移记录至少包含来源版本、目标版本、来源载体、冲突、真实资产证据、迁移人和时间。
-
-## Resume
-
-读取状态块后必须重新读取引用资产、审查记录、Ticket 最新事件和相关 Git 变化。时间戳只能提示变化，不能单独证明语义失效；应比较内容和影响面。冲突时以权威资产为准，记录修复原因，然后重算依赖、门禁和可执行 frontier。
-
-所有暂停/阻塞必须填写结构化 `pause`：`reason_code`、`gate_ref` 或证据引用、`owner_or_authority`、`resume_condition`、`next_work_unit`。`lifecycle.status` 保持粗粒度，恢复条件以 `pause` 为准。
-
-用户决定不新增状态；等待和恢复的引用字段、失效与复用规则见 [user-decisions.md](user-decisions.md)。

package/template/.claude/skills/yss-product-lifecycle/references/user-decisions.md

@@ -1,56 +0,0 @@
-# 关键决策的真实用户回复协议
-
-适用门禁、工作单元和条件事项只由 `docs/agents/digital-human-roles.yaml.user_decision_policy` 定义。本协议解释执行和证据格式，不新增阶段、门禁或 Ticket 状态。专业审查记录与用户决定分别保存；关键决定缺少任一适用条件都不能放行。
-
-## 六条执行规则
-
-1. **先展示，再决定**：先完成可独立执行的检查和可审阅材料，展示资产链接、版本、关键变化、风险、推荐方案、批准范围和批准后的动作。优先使用 `renderDecisionRequest(request)` 生成完整展示文本；也接受原始消息已完整覆盖各项资产、版本、变化、风险、范围、推荐方案和后续动作的等价展示，不能因格式不同重复询问。不得请用户批准尚未形成的资产。
-2. **绑定原始回复**：保存回复人、原始消息引用、回复时间、原文、决定、对应事项、范围及请求摘要。Agent 只能整理，不得生成、推测或补造用户同意。来源记录是可追溯证据，不是密码学身份认证。
-3. **无回复就等待**：超时、默认选项、数字人同意、无反对意见和 Agent 自述均无效。依赖该决定的工作保持 `paused-human-gate` / `ready-for-human`；来源错误等使用 `blocked`。独立工作可以继续，不得借其完成清除未决决定。
-4. **回复必须指向明确**：单项明确请求的“同意”有效。多项需要逐项指定、清楚的子集或“同意以上全部事项”；“继续”不算全部批准。拒绝、修改意见和撤回均保留为有效回复，但不放行。编排器结合原文判定语义；机器核验结构、明确性底线、来源和绑定，不能用自填 `approved` 覆盖相反原文。
-5. **复用已有有效确认**：同一版本、范围和依据不重复询问，不按时间自动过期。相关资产或依据摘要变化、范围扩大或撤回时，旧批准失效；展示差异后重新确认。无关文件变化不触发重新确认。回复按来源时间追加，禁止删除拒绝、修改或撤回记录来恢复旧批准。
-6. **提问者和负责人分开**：默认回复人为提问者。其他业务、技术或发布负责人必须由提问者在原始消息中明确指定，包含对应事项和负责人；数字人不得自行代任。用户表达使用自然语言，内部 ID 和引用由 Agent 整理。
-
-## 记录与来源
-
-使用 `docs/process/schemas/user-decision.schema.json` 和 `docs/process/templates/user-decision-template.yaml`。存于 `docs/.scratch/<feature>/decisions/<request-id>.yaml`；已展示的请求快照不改写，修改方案产生新请求并保留旧引用。请求中的 `subject` 指向可独立摘要的资产正文或冻结快照，批准记录另存，避免正文包含自己的批准摘要形成循环。`basis` 列出影响决定的额外冻结依据。
-
-原始消息可由运行时直接读取，或保存为原始会话导出 / 用户提供的确认文件。跨平台统一捕获封装如下；字段必须来自原始来源，保留原始引用和完整原文，不能把 Agent 编写的摘要包装成来源：
-
-```yaml
-source_kind: session-export # platform-message | session-export | user-confirmation-file
-messages:
-  - id: <原始消息 ID>
-    original_ref: <平台消息链接或用户文件原始位置>
-    principal_ref: <原始作者标识>
-    actor_kind: biological-human # 展示请求的 Agent 消息使用 digital-human
-    sent_at: <原始时间，ISO 8601>
-    text: <完整原文>
-    reply_to: <回复关联的原始请求展示消息引用> # 回复必需；用户确认文件也可携带 request_digest
-```
-
-决定记录中的 `source` 绑定 `kind/ref/digest/message_id`。`ref` 必须可读；平台引用可经运行时的只读解析器提供，CLI 默认读取本地原始捕获封装。不能读取消息时使用原始导出或用户确认文件，不能仅填 URL 假定读取成功。文件摘要只能证明捕获内容一致，不证明作者身份；可信作者与消息内容由运行时或用户提供来源建立。
-
-回复人、时间、原文必须与来源一致。来源还须通过原始 `reply_to` 或用户确认文件中的 `request_digest` 指向当前展示，不能把其他对话中的“同意”嫁接到本次批准。平台没有显式 reply-to 时，可以使用同一原始会话导出中紧邻回复之前、原文和原始引用均匹配的请求消息建立关联；无法建立来源关联就保持等待，不由 Agent 虚构。多项映射使用 `single`、`explicit-items`、`explicit-all`；负责人不同的事项分别回复。`decision` 为 `approved/rejected/changes-requested/unclear/revoked`，只对回复列出的事项和范围生效。需要自然语言补充澄清时保持等待，不要求用户手填内部 schema。
-
-`requestDigest` 对请求除 `presented_source` 外的字段按键排序摘要，避免展示来源循环；展示文本包含该摘要。历史有效回复可导入原始展示消息的完整记录；只要原始展示覆盖当前决定且来源、范围与摘要可核验，即可复用，不要求补发模板消息。不能伪造已展示的新格式。无法证明历史请求与当前资产等价时，重新展示并确认。
-
-## 消费边界
-
-`scripts/verify-user-decision --requirements <当前事项.json> <决定记录.yaml>` 校验当前消费者要求的 `boundary/subject_ref/scope`；未给 `--requirements` 时校验请求中全部事项。无回复的草案可以保存，但不能通过批准验证。局部批准只允许已明确批准的事项推进。
-
-会签记录新增 `subject_ref`、`approval_scope` 和 `user_decision_ref`；checkpoint 门禁同时声明 `subject_ref/approval_scope` 并与会签记录一致。`verify-approval-record` 默认严格验证当前放行条件，`--require-approved` 是显式等价选项；只有 `--history` 仅检查历史记录结构，不构成批准。恢复和门禁关闭必须使用严格校验。旧数字人记录仍可读取和用于专业审查，不自动升级成用户决定。
-
-Workflow Execution Result 使用 `user_decisions` 保存当前要求与证据引用。`user_decision_not_applicable` 仅对未命中的既有技术条件门禁记录 `boundary/reason`，不得跳过已经执行的业务决策。完成结果通过 `validateNextRoute(..., result)` 检查；两参数调用仅检查路由结构，不能证明可以实际流转。
-
-checkpoint 的 `human_review` 保存 `user_decisions`、`required_decisions`、`not_applicable` 和需要时的 `external_input`。`stage_trace.completed_work_unit` 标识已完成单元；进入实施时 `human_review.implementation` 保存当前切片及持久化合同引用。等待态可以保存；恢复、流转和完成时重新核验。外部回复、新授权、风险接受均以同一决定记录作为恢复依据，不能以工具恢复或默认答案替代。
-
-## 首次实施与脚手架
-
-首次实施批准的主体为功能级 `implementation-scope` 清单，`slices` 每行包含：`ticket_ref`、`contract`（ref/version/digest）、`repositories`、`allowed_write_paths`、`baselines`（ref/version/digest）。仓库与写路径必须对应当前合同 `common.project_roots/allowed_write_paths`；基线包含合同引用的工程基线。`scope` 使用批准的切片引用集合。合同、范围或基线变化时回到确认；已覆盖的后续切片复用原记录。
-
-实施就绪和派发必须同时提供 `user_decisions`、`slice_contract_ref` 与 `vertical_slice_ticket_ref`。Worker 任务包通过 `user_decisions` 传递记录，不能只声明 `ready_for_agent=true`。
-
-脚手架 `user_confirmation` 新增 `user_decision_ref/decision_subject_ref`，主体为生成前的决策输入快照；当前范围至少包含项目 ID、确认的架构和 `decision_inputs_digest`。先获得真实回复，再由生命周期批准生成合同；不能回到生成器内提问。
-
-Git commit/push、外部动作仍分别检查已有授权和其范围。用户对一个具体动作的明确自然语言授权可整理成结构化记录，不必再次要求填写内部字段；生命周期批准不隐含其他动作授权。

package/template/.claude/skills/yss-prototype-stage/SKILL.md

@@ -1,58 +0,0 @@
----
-name: yss-prototype-stage
-description: Use when a YSS feature has product-design impact on a primary flow, navigation, state, recovery, permission experience, or UI-driven API contract and needs profile-routed prototype assets before implementation readiness.
----
-
-# YSS Prototype Stage
-
-把产品设计影响收敛为跨 Agent 一致的原型交付物、证据和生命周期回流合同。它不替代 `yss-product-lifecycle` 的门禁裁决，也不把原型当作生产前端代码。
-
-## 进入条件与主入口
-
-- 先由 `yss-product-lifecycle` 判断产品设计影响；无行为变化的孤立视觉修复记录 `not-applicable`，不创建空资产。
-- 先读取 Spec、产品总体设计、`CONTEXT.md`、`yss-design-system`，再按 `DESIGN.md` → `docs/design/design.md` → `docs/design/tokens/*` 顺序消费设计基线，形成交互说明、低保真页面/流程和状态矩阵。
-- 用独立 `prototype-review` 评审低保真与状态；未通过不得选择档位或构建原型交付物。
-- 按 [原型档位路由](references/prototype-profile-routing.md) 选择 H1/H2 中满足当前决策风险的最低档位。没有充分证据时默认 H2。
-- Codex 按档位消费 `product-design:index` 的 focused workflow；H1 可直接走静态适配器，H2 使用 `get-context/image-to-code/design-qa`。其他 Agent 必须交付等价合同资产。
-- `high-fidelity-html-prototype` 仅为历史兼容入口；新资产统一为 `artifact.prototype-deliverable`、Prototype Evidence schema v4 与 Visual Baseline schema v1。
-
-## 执行顺序
-
-1. 形成交互说明、低保真与状态矩阵；状态至少包含事件、转换、guard、动作与可退出路径。
-2. 完成独立 `prototype-review`，提取仍需由原型回答的风险。
-3. 计算并记录 `prototype_profile`。新视觉方向或信息架构不确定时执行三方案 ideation；复用已批准模式时记录 `not-applicable` 与 source visual。
-4. H1 用 `prototype-contract.mjs prepare-static` 生成无 Node 运行时的静态适配器；H2 按 `references/product-design-adapter.md` 构建可运行流程。
-5. 自动采集版本、digest、视口、截图、console 与扫描结果。截图按 `route + page + state + viewport + theme + locale + data_scenario` 写入 `Visual Baseline Bundle`，执行 `visual-baseline-contract.mjs seal` 后由 feature 级 schema v4 `prototype-evidence.yaml` 引用；人工只补决策、风险、允许差异和用户确认。
-6. 以统一六轴 Design QA 和档位验证矩阵完成浏览器/无障碍验证。用户确认后才可校准 Spec、分析 API 影响或进入 实现合同编译器 readiness。
-
-## 档位边界
-
-- H1 `visual-review`：浏览器可复验的 HTML/CSS/少量 JS 或设计工具导出；不得要求 `package.json`、lockfile、Node 或 AntD CLI。
-- H2 `flow-review`：主流程与关键异常状态可操作；Vue 3/Vite + Antdv Next 是受支持默认。React/Vite + Ant Design v6 仅作为显式兼容路线；只消费与实际 `component_basis` 匹配的精确版本事实或 fresh fact pack。
-- 原型代码默认 throwaway；可复用的是项目 Token、组件语义映射、状态、测试场景和验收标准。任何源码进入生产仍需 实现合同编译器、Slice Contract 和 TDD。
-- 原型阶段不得调用 `yss-ui`，不得读取生产组件 API 来制造“真实组件原型”。需要核验真实 YSS/AntDV 组件的事项写入 `implementation_handoff`，由前端实现计划、已批准切片的实现和实现还原验证负责。
-
-## 事实、QA 与确认
-
-优先级固定为：项目根 `DESIGN.md` 规范 Token / 组件变体 → `docs/design/design.md` 治理解释 → `docs/design/tokens/*` 派生快照 → 当前功能语义 → 相关上游组件事实。H2 默认通过 `yss-antdv-next-design` 使用 Antdv Next exact-version fact pack；只有显式选择 `react-antd-6` 时才调用 `yss-antd-design`。fact pack 仅在精确版本、组件集合、根 `DESIGN.md` digest 和项目 Token digest 均匹配且无新 API 疑问时可复用；否则做增量查询。`antd lint/doctor` 只对 React 兼容路线的相关源文件执行。
-
-Design QA 合并 visual、layout、interaction、content、accessibility、cross-platform 六轴，不再建立第二份评审。所有档位至少证明 desktop/narrow 非空渲染、项目 Token、console 和基础键盘/焦点/对比度；H2 追加主流程、关键异常、200% zoom/reduced motion 与按风险视觉回归。图片是视觉基准而非唯一事实来源；模型必须从 `visual-baseline.yaml` 的 `case_id` 读取对应语义引用，禁止靠目录 glob 猜测页面含义。
-
-用户确认必须绑定提问者或其明确指定负责人的原始回复，使用生命周期 `user_decision_policy` 和统一用户决定记录；产品数字人只提供确认建议，不能代答。正式证据追加 `user_decision_ref/decision_subject_ref`，校验原型、视觉基线和操作范围与用户所见快照一致。用户确认只描述原型确认了什么、哪些范围可操作、哪些为模拟或 gap，以及接受/拒绝结论；不要求用户确认技术栈、CLI 或构建细节。
-
-`gate.prototype-reviewed`、`gate.prototype-verified`、`gate.user-confirmation` 保持三个既有门禁。档位选择是 `gate.prototype-verified` 的输入证据，不增加新门禁，也不授权实现。
-
-## 按需读取
-
-- 档位、上游融合与迁移：[prototype-profile-routing.md](references/prototype-profile-routing.md)
-- 渲染适配、fact pack 与命令：[product-design-adapter.md](references/product-design-adapter.md)
-- 证据模板：`docs/design/templates/prototype-evidence-template.yaml`
-- Visual Baseline 模板与 schema：`docs/design/templates/visual-baseline-template.yaml`、`docs/design/schemas/visual-baseline.schema.json`
-
-## 常见错误
-
-- 继续把 React/AntD 当作 H2 默认，或把单个 HTML 文件当成所有档位的答案。
-- 低保真未评审就选择技术栈；用主观评分代替确定性触发规则。
-- H1 伪造 lockfile/AntD 段，或 H2 声称已验证生产 YSS/AntDV 真实组件。
-- 重复抄写机器可采集的版本、digest、截图和 console；创建第二份状态机、QA 或 handoff 资产。
-- 把原型源码直接复制进生产，或在原型阶段调用 `yss-ui`。

package/template/.claude/skills/yss-prototype-stage/references/product-design-adapter.md

@@ -1,82 +0,0 @@
-# YSS 原型渲染适配器
-
-生命周期调用方只选择 H1/H2 并验证 schema v3；静态与流程原型渲染细节留在本适配器内。
-
-## H1：静态视觉评审
-
-目录固定为 `docs/.scratch/<feature>/design/prototypes/`。运行：
-
-```bash
-node .agents/skills/yss-prototype-stage/scripts/prototype-contract.mjs prepare-static \
-  --project-root <project-root> \
-  --root <project-root>/docs/.scratch/<feature>/design/prototypes \
-  --feature <feature>
-```
-
-命令生成语义化 `index.html`、`styles.css` 和 `yss-prototype-adapter.json`，引用项目 Token CSS。它不创建 `package.json`、lockfile、`node_modules` 或运行时构建合同。设计者在此最小壳中实现布局和少量关键交互；交付可以是静态目录或 URL，不要求单文件。
-
-校验：
-
-```bash
-node .agents/skills/yss-prototype-stage/scripts/prototype-contract.mjs validate-project \
-  --profile H1 --root <prototype-root>
-```
-
-## H2：可运行流程
-
-H2 可选择任何能稳定浏览器交付的轻量前端实现。默认 `component_basis=vue-antdv-next`，使用 Vue 3/Vite + Antdv Next：
-
-```bash
-node .agents/skills/yss-prototype-stage/scripts/prototype-contract.mjs prepare-flow \
-  --project-root <project-root> \
-  --root <prototype-root> \
-  --feature <feature> \
-  --pnpm-version <actual-pnpm-version>
-
-node .agents/skills/yss-prototype-stage/scripts/prototype-contract.mjs validate-project \
-  --profile H2 --root <prototype-root>
-```
-
-默认命令生成最小 Vue/Vite starter，精确写入 `antdv-next@1.5.2`、`vue@3.5.21`、`vite@6.4.2`、`@vitejs/plugin-vue@5.2.4`，登记实际 pnpm，生成 Vue 入口、`src/yss-theme.js` 与 provider-neutral adapter schema v3。设计 workflow 在 starter 中替换占位页面，再以 `ConfigProvider`、`pnpm install`、`pnpm build` 形成可移植静态输出。已有 Vue 页面不会被重写，但必须通过合同验证。
-
-显式兼容 React/Vite + Ant Design v6 时传入：
-
-```bash
-node .agents/skills/yss-prototype-stage/scripts/prototype-contract.mjs prepare-flow \
-  --project-root <project-root> \
-  --root <prototype-root> \
-  --feature <feature> \
-  --component-basis react-antd-6 \
-  --library-version <exact-6.x-version> \
-  --pnpm-version <actual-pnpm-version>
-```
-
-历史 `--target-antd-version` 继续映射到 `react-antd-6`，只为在途兼容，不再是默认调用。其他 H2 基座必须在证据中明确记录，不得伪造 Antdv Next 或 AntD 字段。
-
-### Provider fact pack
-
-默认目录为 `docs/design/facts/antdv-next/<exact-version>/`；React 兼容路线使用 `docs/design/facts/antd/<exact-version>/`。至少包含 `manifest.json`、design-md 摘要、组件事实与 digest。只有以下全部相等才为 fresh：
-
-- manifest 的 package 与 exact version 等于原型 lockfile；
-- 所需组件均被覆盖；
-- 根 `DESIGN.md` path / digest 与当前规范源相等；
-- `project_token_baseline_digest` 等于当前 Token 派生基线；
-- 没有新的 API/semantic 疑问。
-
-不满足时只查询缺失或变化的事实。默认 Vue 路线调用 `yss-antdv-next-design`；React 兼容路线调用 `yss-antd-design`，且 `lint/doctor` 只在存在相关 React 源时运行。不要创建占位 fact 目录；feature 证据只引用实际 manifest。
-
-## 共同映射与验证
-
-映射的是 semantic role、项目 Token、状态和验收行为，不是 React API 表面。默认视口为 desktop `1440x900` 与 narrow `390x844`；按影响追加其他断点。Design QA 固定写 feature 级 verification 路径，并按 visual/layout/interaction/content/accessibility/cross-platform 六轴执行。
-
-浏览器/Design QA 将每个风险驱动 case 捕获为 PNG，写入 `docs/.scratch/<feature>/handoff/visual-baseline-v<version>/images/`，并从 `docs/design/templates/visual-baseline-template.yaml` 生成 manifest。截图必须使用固定数据、sRGB、DPR 1，等待字体完成，关闭动画、过渡和光标闪烁；长页面使用固定滚动分段。捕获完成后运行：
-
-```bash
-node .agents/skills/yss-prototype-stage/scripts/visual-baseline-contract.mjs seal \
-  docs/.scratch/<feature>/handoff/visual-baseline-v1/visual-baseline.yaml \
-  --bundle-root docs/.scratch/<feature>/handoff/visual-baseline-v1
-```
-
-`seal` 校验 PNG 尺寸与大小并写入图像和整包摘要；随后以 `validate` 重验。模型和下游实现只从 manifest 的 `case_id` 取图，不通过 glob 推断含义。工作目录可位于被忽略的 `.scratch`，但 Strategic Design Handoff 必须携带或引用可读取的自包含 Bundle。
-
-H1/H2 的条件验证矩阵与实现阶段交接规则见 [prototype-profile-routing.md](prototype-profile-routing.md)。原型阶段禁止调用 `yss-ui`；真实组件事实只在批准后的前端实现与实现还原验证中取得。

package/template/.claude/skills/yss-prototype-stage/references/prototype-profile-routing.md

@@ -1,69 +0,0 @@
-# 原型档位路由与 Designer Skills 适配
-
-本合同是 `artifact.prototype-deliverable` 的档位选择单一入口。生命周期只依赖 `prototype_profile` 和统一证据，不感知渲染器内部结构。
-
-## 选择算法
-
-先读取已批准 Spec、交互说明、低保真、状态矩阵和独立 `prototype-review`。按下列确定性规则选择，最高命中档位优先；无命中或证据不充分时使用 H2。人工可以直接升级，降级必须写明已关闭的触发风险与证据。
-
-| 档位 | 名称 | 命中条件 | 默认适配器 |
-|---|---|---|---|
-| H1 | `visual-review` | 仅需确认布局、密度、层级、文案或少量关键交互；不涉及多页面导航、复杂联动、权限、恢复、冲突或真实组件差异 | 语义 HTML + 项目 Token CSS + 最小 JavaScript；可使用设计工具导出，但必须有浏览器可复验入口 |
-| H2 | `flow-review` | 多页面/路由、复杂表单联动、权限体验、失败恢复、并发冲突或需要可操作主流程测试 | 可运行前端原型；Vue 3/Vite + Antdv Next 是受支持默认，React/Vite + Ant Design v6 为显式兼容路线 |
-
-真实 YSS/AntDV 组件行为、lockfile、props、slots、events 或 Storybook 状态不是第三种原型档位。它们属于前端实现计划、已批准切片的生产实现与实现还原验证。原型中发现的相关不确定性写入 `implementation_handoff`，不得为解决它调用 `yss-ui` 或把实现仓组件代码引入原型。
-
-## 共同资产
-
-- `decision_to_inform`：本轮原型要支持的具体决策。
-- `risk_assumptions` 与 `trigger_results`：机器可读档位来源。
-- Spec、交互说明、状态矩阵、设计系统与低保真评审引用。
-- 浏览器入口、产物 digest、desktop/narrow 非空渲染、console 结果，以及由 `case_id` 定位的 Visual Baseline Bundle。
-- 统一 Design QA 六轴：visual、layout、interaction、content、accessibility、cross-platform。
-- 独立原型评审引用、用户确认、blockers 和 gaps。
-- `implementation_handoff`：只记录生产组件假设、待验证事项和目标阶段，不提前执行生产组件核验。
-
-机器优先采集版本、digest、视口、截图、console 与扫描结果；人只填写决策、风险解释、允许差异和用户确认。PNG 基准图统一使用 sRGB、DPR 1，关闭动画并隐藏光标；长页面使用固定滚动分段，full-page 只可作总览。每张图不超过 5 MiB，整包不超过 100 MiB。不得把同一事实复制到多个段落。
-
-`visual-baseline.yaml` 是模型与实现验证的唯一图片索引。每个 case 必须绑定 route、page、state、viewport、theme、locale、data scenario、PNG digest、语义引用和允许差异；至少覆盖 1440x900 与 390x844。原型用户确认时冻结版本，后续变更创建新版本并使依赖的实现计划与 Slice Contract `stale`，禁止覆盖旧版本。
-
-## 档位证据
-
-### H1
-
-- 浏览器不依赖 Node/runtime build；原型目录不得伪造 `package.json`、lockfile 或 AntD 查询段。
-- 至少验证一个或少量关键交互，以及基础键盘、焦点和对比度。
-- 200% zoom 与 reduced motion 只在影响面命中时要求；视觉回归和真实组件 story 不强制。
-
-### H2
-
-- 主流程与关键 failure / no-permission / conflict 状态可操作。
-- 验证键盘、焦点、对比度、200% zoom、reduced motion；按风险决定视觉回归。
-- 默认使用 `vue-antdv-next` 并记录 package 与精确版本；显式兼容路线记录 `react-antd-6`。fact pack 只有在 provider、版本、组件集合和项目 Token baseline digest 全部匹配且没有新 API 疑问时才可复用，否则只补增量查询。
-- 使用其他基座时记录 `component_basis`，不创建空 Antdv Next 或 AntD 字段。
-
-### 实现阶段交接
-
-- 若原型结论依赖真实 YSS/AntDV 组件能力，在 `implementation_handoff.production_component_assumptions` 中记录假设，在 `verification_targets` 中写明待验证行为。
-- 实现合同编译器 将这些事项编入 `frontend_implementation_plan`；真实组件事实在实现准备或进入已批准切片后由 `yss-ui` 基于目标 lockfile 核验，最终写入 `frontend_implementation_verification`。
-- 原型门禁只证明设计决策、流程与状态可验证，不得声称已证明生产组件兼容性。
-
-## 条件 ideation
-
-新视觉方向、信息架构不确定或存在两个以上合理布局时，`product-design:ideate` 的三方案比较为 mandatory。沿用已批准模式且 source visual 可定位时记录 `not-applicable`、复用来源和理由，不制造三份无意义变体。
-
-## 上游融合记录
-
-- 来源：`https://github.com/Owl-Listener/designer-skills`
-- 检查 revision：`20e34c4a587e5eb09fcdf8351fa97b3ad761b31e`
-- 许可证：MIT
-- 采用：`prototype-strategy` → 本档位算法；`state-machine` → 现有状态矩阵；`design-qa-checklist` → 统一六轴 QA；`handoff-spec` → 交互说明、状态矩阵、前端实现计划与 Slice 合同。
-- 不采用：上游 107 skills / 32 commands 的整包安装、第二套生命周期与第二份 handoff 资产。
-- 更新：仅人工 diff 新 revision；YSS `CONTEXT.md`、生命周期注册表、设计系统与本合同冲突时始终以 YSS SSOT 为准。
-- `taste-skill` revision `ccbc15639c97057cbfcf32ecebc38ef716e4bb37` 本轮不集成；未来只能作为 H1/H2 可选视觉 lens，不能覆盖 dashboard、data table 或 multi-step flow 的主合同。
-
-## 迁移
-
-- 新证据只生成 schema v4、Visual Baseline schema v1 与 `artifact.prototype-deliverable`。
-- prototype evidence schema v1/v2/v3 和 `artifact.high-fidelity-html-prototype` 只读兼容；已经关闭的历史证据保持有效，不补造图片。
-- 在途 UI 证据必须迁移到 v4 并产生 Visual Baseline 后才能关闭 `gate.prototype-verified`；非 UI 功能不生成空包。