create-yss-spec 2.1.10 → 2.1.13

package/template/wiki/wiki/LLM Wiki.md

@@ -0,0 +1,30 @@
+# LLM Wiki
+
+LLM Wiki 是由 `raw/`、`wiki/` 与 `.wiki-manifest.json` 组成的本地持久知识库，其中 raw 含 live 拷贝与 derived 摘录。它是中间表示（IR），live 源才是事实；一次性笔记不在本技能范围，也不替代权威源。`ingest` 只把用户点名的外源或已落盘研究笔记编进 IR，不改 live 权威文件。
+
+三层布局：`raw/` 保存不可变拷贝与标明 live 输入的 derived 摘录，不得靠改 raw「修正」事实；`wiki/` 保存 LLM 文章以及 `index.md`、`log.md`、`CLAUDE.md`、可选 `concept-table.md`；`.wiki-manifest.json` 是编译图，与 `raw/`、`wiki/` 并列，不是文章也不是 raw 源。文章 ID 等于文件名去掉 `.md`。`index.md`、`log.md`、`CLAUDE.md`、`AGENTS.md`、`soul.md`、`concept-table.md` 是基础设施文件，不视为文章。本模板 wiki 的入口分类见 [[模板总览]]。
+
+模式为 `init`、`refresh`、`rebuild`、`lint`、`ingest`。已有 `wiki/index.md` 禁止 `init` 覆盖，应询问 refresh 还是 rebuild。`refresh` 只改漂移命中的文章，且 `human-owned` 不改；无映射新文件必须先四态 triage（`New` / `Update` / `Disputed` / `No material`），`No material` 只追加 log。`rebuild` 让 raw 对齐 live，保留稳定 ID 与 human-owned，全量重写 LLM 页。`ingest` 只接受用户点名的外源或已落盘 research 笔记，确认前零文章字节变化；已映射 live 源变了走 `refresh`，禁止 query 顺手 ingest。查询不是模式：有 wiki 就从 wiki 回答，先展示 `inventory.mjs status` 源状态表，再匹配 index；过窄时用 H1/首段兜底，最多打开 8 页并回读 live。
+
+`lint` 完成条件是结构脚本 exit 0，且已跑 `advise.mjs` 并报告条数。advise 报告单向链、无专页专名、未引用 raw 与字面证据 suspects，不改结构失败合同，也不自动建页或改数字。`inventory.mjs status` 是 `drift` 的稳定别名，exit 0 表示报告有效，不得把非空 `changed` 当成脚本失败。
+
+多源冲突或 live 与旧 raw 不一致时，文章可写可选 `## Status`（`Disputed` / `Outdated`），保留双方引用；单一 live 正确则不写。`human-owned` 页只修 wikilink，不写 Status。缺 Status 不是 lint 失败。可选 `concept-table.md` 用三列（概念、关系、文章 ID）作基础设施，rebuild 可重写，不改成 `wiki/entities/`。
+
+本 wiki 的 manifest 使用 `schemaVersion` `1`、`profile` `documents`。编译图还允许 `mixed`（文档 + 代码）与 `code`；source `kind` 为 `document`、`derived` 或 `code-surface`。Agent 填写 `id`、`kind`、`livePath`、`rawPath`、`role`、`articles`；脚本填充 `sha256`、`compiledAt`、`gitCommit`。文章以 `# H1`、摘要段、正文和 `## 来源` 写成，站内只用双方括号包裹的文章 ID 互引。
+
+`llm-wiki` 已写入锁文件 `shared` 分组（`source: project`），并在 `yss-skill-registry.yaml` 中登记为 `layer: core`、`maturity: verified`、`instance_default_discoverable: true`、`impacts: [quality]`。该注册表仍是 `status: shadow`，不得据此裁剪 Router / 生命周期发现面。`llm-wiki` 不在 `yss-public-skills.json`；公开发布面只放 `yss-*` 工程技能（见 [[技能投影与锁定]] 与 [[YSS工程技能体系]]）。强制入口见 [[Agent入口规则]]。权威源修订后应 refresh / rebuild，复盘见 [[复盘与权威资产修订]]；技能变更强度走 [[模板维护流程]]。
+
+## 来源
+
+- `.agents/skills/llm-wiki/SKILL.md`
+- `.agents/skills/llm-wiki/references/schema.md`
+- `.agents/skills/llm-wiki/references/compile.md`
+- `.agents/skills/llm-wiki/references/query.md`
+- `.agents/skills/llm-wiki/references/lint.md`
+- `.agents/skills/llm-wiki/references/ingest.md`
+- `AGENTS.md`
+- `CONTEXT.md`
+- `skills-lock.json`
+- `docs/agents/yss-skill-registry.yaml`
+- `wiki/.wiki-manifest.json`
+- `yss-public-skills.json`

package/template/wiki/wiki/Matt/346/212/200/350/203/275/344/275/223/347/263/273.md

@@ -1,9 +1,21 @@
-# Matt Pocock Engineering Skills
+# Matt技能体系
 
-Matt Engineering Skills 是来自 `mattpocock/skills` 的轻量工程流程技能集合，用于澄清、Spec、Ticket、实现、TDD、诊断、审查和架构治理，不替代 YSS 专项规范（见 [[YSS工程技能体系]]）。
+Matt Engineering Skills 是来自 `mattpocock/skills` 的轻量工程流程技能集合，用于澄清、Spec、Ticket、实现、TDD、诊断、审查和架构治理，不替代 [[YSS工程技能体系]]。
 
-主要技能与用途：`grill-with-docs`（需求澄清与决策沉淀）、`to-spec`（Spec 形成）、`to-tickets`（垂直切片拆分）、`tdd`（测试驱动实现）、`diagnosing-bugs`（Bug 与性能回退诊断）、`code-review`（双轴审查：标准符合性与 Spec 符合性）、`codebase-design` / `improve-codebase-architecture`（深模块设计与架构治理）、`resolving-merge-conflicts`、`maintaining-skills`（轻量技能维护）、`research`（一手事实研究）与 `handoff`（交接记录）。
+当前锁定 revision 以 `skills-lock.json` 的 `sources` 为准：`mattpocock/skills` 的 `revision` 为 `0ab1b63a410a03d3627979a109c8695de27af954`。不要抄 README 里可能过期的 hash。上游技能基线不等于项目当前生效内容；YSS 适配必须同时保留上游内容哈希、有效内容哈希和适配依据（见 [[技能投影与锁定]]）。
 
-专项任务强制入口（见 [[Agent入口规则]]）：技术事实影响决策用 `research`；竞品 / 市场 / 用户口碑事实用 `competitive-intelligence`；UI 设计用 `yss-design-system` 后路由 `product-design:index`；Bug、测试失败或性能回退用 `diagnosing-bugs` 建立可复现反馈，再用 `tdd`；架构治理与深模块设计用 `codebase-design`；跨线程、跨仓库、上下文过长或原型结论回流用 `handoff`。
+`grill-with-docs` 与 `to-spec` 只是用户显式兼容入口；新功能或较大变更的默认路径是 `yss-product-lifecycle` 的原生 Discovery / 需求分析工作单元，[[Spec基线]] 与产品设计影响的完整判定以生命周期注册表和裁剪规则为准（见 [[产品研发生命周期]]）。用户显式 `to-tickets` 同样只是兼容入口；正式化由生命周期原生 Ticket 工作单元完成，禁止只按 Adapter / Application / Domain / Infrastructure 横向拆分（见 [[垂直切片Ticket]]）。
 
-业务行为默认按 `tdd` 使用已确认的公开 seam 逐切片实现。一次性生成、纯配置或流程文档不适用代码 TDD 时，必须记录例外理由和可执行验证方式。
+[[Agent入口规则]] 规定的强制入口包括：技术事实、标准、第三方 API 或框架行为走 `research`；竞品、市场或用户口碑走 `competitive-intelligence`；Bug、测试失败或性能回退先用 `diagnosing-bugs` 再建 `tdd`；merge / rebase 冲突走 `resolving-merge-conflicts`；架构治理、难测模块或深模块设计走 `improve-codebase-architecture` / `codebase-design`；跨线程、跨仓库、上下文过长或原型结论回流走 `handoff`。
+
+业务行为默认按 `tdd` 使用已确认的公开 seam 逐切片实现。一次性生成、纯配置或流程文档不适用代码 TDD 时，必须记录例外理由和可执行验证方式。一次性一手资料走 `research`；要把研究结果落成持久 wiki 则走 [[LLM Wiki]]。`ask-matt` 的关联入口包括 `to-questionnaire`、`wait-what`、`writing-for-agents` 和 `PHASE-BOUNDARIES.md`，这些支持文件随共享 skill 目录一起计算 `effectiveHash`，不得单独投影或维护。
+
+过时技能不会保留兼容别名。已退休、personal 或由 YSS 有意排除的条目不再进入 `.agents/skills`、共享投影根或 `skills-lock.json`；其中 `wizard` 是最新上游仍存在但 YSS 当前有意排除的人工步骤技能，不应描述为上游已退休。
+
+## 来源
+
+- `CONTEXT.md`
+- `AGENTS.md`
+- `skills-lock.json`
+- `docs/agents/skills-maintenance.md`
+- `wiki/raw/skills-lock-names.md`

package/template/wiki/wiki/OpenAPI/345/245/221/347/272/246.md

@@ -1,9 +1,20 @@
-# OpenAPI Draft 与 Freeze
+# OpenAPI契约
 
-API 契约变更先形成 OpenAPI 3.1 Draft——review-only 的契约草案，Freeze 前不得作为前后端稳定实现契约。Draft 需经过必要的工程基线、系统 / 数据架构和设计审查后进入 OpenAPI Freeze。
+API 契约变更先形成 OpenAPI 3.1 Draft，经必要的工程基线、系统 / 数据架构和设计审查后 Freeze，再进入实现。Draft 是 review-only：Freeze 前不得作为前后端稳定实现契约，也不得用来生成客户端或固化契约测试。
 
-OpenAPI Freeze 指已通过评审、可作为前后端实现和契约测试输入的 OpenAPI 3.1 契约。Freeze 后变更必须回到 API 影响分析和设计审查，形成新的 Draft 循环。OpenAPI 契约的评审要点包括 P0 需求覆盖、页面动作到端点映射、YSS 响应包装、错误、权限、分页、乐观锁、安全红线与契约测试 seam。
+Draft 属于待冻结资产，状态为 `ready-for-human`，见 [[Ticket与流程状态]]。Spec 模板把 OpenAPI 影响写成「无 / 需要 API 影响分析 / 需要 review-only OpenAPI Draft」，Draft 路径为 `docs/.scratch/<feature>/api/<feature>.yaml`。该 YAML 必须是唯一权威的单一 OAS 3.1 document；JSON 只能在 Freeze 后由受锁定工具派生。有 UI 且尚未完成用户确认时，不得进入 OpenAPI Draft 评审。
 
-OpenAPI 契约文件存放于 `docs/api/specs/`，评审检查清单与 Freeze 记录模板见 `docs/api/templates/`。OpenAPI Freeze 或无 API 影响记录完成后，使用 `to-tickets` 拆分成窄垂直切片（见 [[垂直切片Ticket]]）。OpenAPI Draft 属于待冻结资产，使用 `ready-for-human`；只有 Freeze 后的契约才支撑 `ready-for-agent` 的切片。
+`work-unit.technical-analysis` 消费冻结 [[Spec基线]]、适用的原型和 API / 数据 / 工程影响面，产出 OpenAPI、数据架构、工程基线、架构审查和 Slice 合同草案。命中契约必须冻结；无 API 影响要有可读记录。相关门禁按影响面强制，未命中记 `not-applicable`：`gate.openapi-draft-reviewed`、`gate.design-reviewed`、`gate.engineering-baseline-accepted`、`gate.architecture-reviewed`、`gate.openapi-frozen`，见 [[条件强制门禁]]。
 
-YSS 的 OpenAPI 契约以冻结的 OpenAPI 3.1 YAML 为唯一权威。`yss-openapi-governance` 使用锁定的 Redocly CLI 派生 JSON，随后由 `api-integration` 刷新前端 Orval API 客户端；JSON 与生成代码均不得手工修改（见 [[YSS工程技能体系]]）。
+OpenAPI Freeze 是已通过评审、可作为前后端实现和契约测试输入的 OpenAPI 3.1 契约。Freeze 后变更必须回到 API 影响分析和设计审查，重新进入 Draft 循环，不能在实现中直接改契约冒充稳定来源。Router 也要求 API 变化回到生命周期 Draft / Review / Freeze，半成品 backend 不得充当 source of truth。
+
+OpenAPI Freeze 或无 API 影响记录完成后，由生命周期原生 Ticket 正式化工作单元拆成窄垂直切片；用户显式 `to-tickets` 只是兼容入口。切片实现必须消费冻结契约或明确的无 API 影响记录，见 [[垂直切片Ticket]] 与 [[切片实现合同]]。需要页面动作反推端点时，先完成 [[产品设计影响与原型]]，再进入本契约循环。整条链路挂在 [[产品研发生命周期]] 的 `stage.system-data-engineering`；YSS 响应包装与 DTO wire shape 的专项规则由 [[YSS工程技能体系]] 在 Freeze 后执行，不把 Draft 当生成输入。
+
+## 来源
+
+- `CONTEXT.md`
+- `AGENTS.md`
+- `docs/templates/spec-template.md`
+- `docs/process/lifecycle-registry.yaml`
+- `docs/api/templates/openapi-draft-review-checklist.md`
+- `.agents/skills/yss-router/SKILL.md`

package/template/wiki/wiki/SpecDelta.md

@@ -1,9 +1,19 @@
-# Spec Delta
+# SpecDelta
 
-Spec Delta 记录相对既有冻结 Spec 基线的 `ADDED / MODIFIED / REMOVED` 行为、验收场景和测试映射，用于表达冻结后的变更影响。
+Spec Delta 只记录相对既有冻结 [[Spec基线]] 的 `ADDED / MODIFIED / REMOVED` 高风险行为差异，以及对应的验收场景和测试映射。它不是第二份完整 Spec，也不替代 OpenAPI 或架构资产。
 
-触发条件：只对既有冻结 Spec 基线的高风险行为差异生成 Spec Delta。全新产品、全新模块和低风险调整不生成 Spec Delta，也不替代完整 Spec、OpenAPI 或架构资产。当变更需要重新校准产品设计、契约或测试映射时，Spec Delta 作为变更载体进入评审流程（见 [[Spec基线]]）。
+触发面很窄。全新产品、全新模块和低风险调整不生成 Spec Delta。生命周期产物 `artifact.spec-delta` 的触发条件是「已有冻结 Spec 的高风险行为变化」，归属 `stage.spec-architecture`。未命中时按 [[条件强制门禁]] 与 [[影响面分诊与流程裁剪]] 记录 `not-applicable` 及原因，不写空 Delta。明确改变认证或授权行为时，把差异当作普通行为写入本 Delta，不另开专项 Delta。
 
-Spec Delta 与 [[OpenAPI契约]] 的变更管理呼应：OpenAPI Freeze 后的契约变更必须回到 API 影响分析和设计审查。Spec Delta 中的测试映射与验收场景直接支撑 [[垂直切片Ticket]] 的拆分与验证。
+模板 `docs/templates/spec-delta-template.md` 用三列差异表达行为，不引入 OpenSpec CLI 或额外状态机。`ADDED` 是新增用户可见行为、API 行为、状态、权限或数据约束；`MODIFIED` 是已有行为的输入、输出、状态流、权限、错误结构、兼容性或验收标准变化；`REMOVED` 是删除或废弃已有行为、字段、入口、权限、状态或兼容路径。变更摘要还要挂相关 OpenAPI Draft / Freeze、架构 / 设计审查和 Ticket / 切片。
 
-生成与维护 Spec Delta 是条件强制门禁的一部分：命中冻结基线变更触发条件时必须完成，未命中时记录 `not-applicable` 及原因（见 [[条件强制门禁]] 与 [[影响面分诊与流程裁剪]]）。
+受影响范围按维度勾选：UI / 页面 / 交互状态，API / OpenAPI schema / 错误结构，权限 / 认证 / 授权，状态机 / 业务流程，数据模型 / Repository / 查询索引，外部系统 / 跨端协作，发布 / 回滚 / 运维，风险 / 人审点。UI 勾选不等于自动构成 [[产品设计影响与原型]]；只有主流程、导航、权限体验、异常 / 恢复、状态流转或 API 反推才需要页面流和原型校准。API 勾选后必须走 [[OpenAPI契约]] 的 Draft → 审查 → Freeze，Freeze 后变更仍要回到 API 影响分析和设计审查。
+
+验收场景（`SD-001` 起）映射到测试与 fresh verification：单元 / 契约 / E2E / 手工验证，并记录命令、证据路径和 `planned / passed / blocked`。这直接支撑后续 [[垂直切片Ticket]] 的验收与测试 seam，也进入 [[Fresh验证与独立审查]]。结论栏只回答是否允许进入 OpenAPI Freeze / no API impact、是否允许进入 `to-tickets`、必须带入垂直切片的约束，以及 Git checkpoint 状态；`to-tickets` 仍只是兼容入口。
+
+## 来源
+
+- `CONTEXT.md`
+- `AGENTS.md`
+- `docs/templates/spec-delta-template.md`
+- `docs/process/lifecycle-registry.yaml`
+- `docs/templates/spec-template.md`

package/template/wiki/wiki/Spec/345/237/272/347/272/277.md

@@ -1,9 +1,22 @@
-# Spec 基线
+# Spec基线
 
-Spec 是记录用户问题、解决方案、用户故事、关键决策、验收标准和测试 seam 的产品研发规格，是进入实现前的核心契约资产。新资产统一使用 Spec 称谓，过时术语（如旧的需求规格）只在迁移指南或明确标注的旧项目上下文中保留。
+Spec 是记录用户问题、解决方案、用户故事、关键决策、验收标准和测试 seam 的产品研发规格。新资产统一使用 Spec；过时称谓只出现在迁移指南或明确标注的旧项目上下文。它是 [[产品研发生命周期]] 进入实现前的核心需求资产，不是可以直接编码的 Ticket。
 
-新功能或较大变更先用 `grill-with-docs` 澄清需求，再用 `to-spec` 形成 Spec。只要进入 Spec 基线，必须产出产品总体设计或功能架构。Spec 初稿属于待冻结资产，使用 `ready-for-human` 状态，等待人工审查与校准（见 [[Ticket与流程状态]]）。
+新功能或较大变更先进入 `yss-product-lifecycle` 的原生 Discovery / 需求分析工作单元；`grill-with-docs` 与 `to-spec` 只是用户显式兼容入口。Spec 基线与产品设计影响的完整判定以生命周期注册表和 [[影响面分诊与流程裁剪]] 为准，不以兼容入口替代原生工作单元。`work-unit.spec-synthesis` 的输入是已确认的 Discovery 记录和测试 seam，产出 Spec、产品总体设计和功能架构；内容完整后进入 `ready-for-human`，下游推进仍需 `gate.spec-baseline-approved`。
 
-Spec 校准遵循流程：需求澄清 → 产品设计影响评估（见 [[产品设计影响与原型]]）→ Spec 校准与需求冻结 → 若涉及 UI 则评审低保真草图与状态矩阵 → 需要时进行高保真 HTML 原型确认 → 进入 OpenAPI Draft（见 [[OpenAPI契约]]）。
+模板 `docs/templates/spec-template.md` 的 frontmatter 含 `pipeline`、`stage`、`status`、`owner`；`status` 默认 `ready-for-human`，`stage` 默认 `open`，`owner` 默认 `ai`。正文先挂功能父 Ticket，再写问题陈述、解决方案、用户故事、功能需求、非功能需求、验收标准（gherkin）、产品总体设计 / 功能架构、OpenAPI 影响、DDD 影响判断、测试决策、AI / 人工审查点、非目标范围和风险。Local 路径约定为 `docs/.scratch/<feature>/spec.md`，父 Ticket 为 `docs/.scratch/<feature>/parent-ticket.md`。
 
-Spec 变更管理：相对既有冻结 Spec 基线的高风险行为差异通过 Spec Delta 记录（见 [[SpecDelta]]）；全新产品、全新模块和低风险调整不生成 Spec Delta。Spec 模板的权威格式见 raw 源 `spec-template.md`。冻结后的 Spec 是 [[垂直切片Ticket]] 拆分与 [[切片实现合同]] 编译的事实基础。
+验收标准写可观察结果，不写实现步骤。测试决策要标明主要测试 seam、代码库中的相似测试，以及单元 / 领域行为、API / 契约、前端组件、E2E 关键路径是否必需。DDD 影响判断只做轻量检查：统一语言变化回写 `CONTEXT.md`；限界上下文变化在产品总体设计中补 Strategic DDD Check；聚合、不变量或状态机变化在系统概要设计 / 数据架构中补 Tactical DDD Check。未触发时不另开流程阶段。
+
+存在 UI 影响时，Spec 才强制低保真页面草图、状态矩阵、高保真 HTML 原型和用户确认；否则记录 `not-applicable` 及原因。UI 影响不等于 [[产品设计影响与原型]]：只有主流程、导航、权限体验、异常 / 恢复、状态流转或 API 反推才构成产品设计影响。OpenAPI 影响在 Spec 中先勾选「无 / 需要 API 影响分析 / 需要 review-only OpenAPI Draft」，Draft 路径为 `docs/.scratch/<feature>/api/<feature>.yaml`；Draft 在 Freeze 前只供评审，见 [[OpenAPI契约]]。
+
+Spec 初稿、产品设计和待冻结资产使用 `ready-for-human`，见 [[Ticket与流程状态]]。相对既有冻结基线的高风险行为差异才写 [[SpecDelta]]；全新产品、全新模块和低风险调整不生成 Delta。冻结后的 Spec 是 [[垂直切片Ticket]] 拆分与 [[切片实现合同]] 编译的输入，也受 [[条件强制门禁]] 约束：命中才裁决，未命中只记 `not-applicable`。入口边界见 [[Agent入口规则]]。
+
+## 来源
+
+- `CONTEXT.md`
+- `AGENTS.md`
+- `docs/templates/spec-template.md`
+- `docs/process/lifecycle-registry.yaml`
+- `docs/agents/issue-tracker.md`
+- `docs/agents/triage-labels.md`

package/template/wiki/wiki/Ticket/344/270/216/346/265/201/347/250/213/347/212/266/346/200/201.md

@@ -1,9 +1,21 @@
-# Ticket 与流程状态
+# Ticket与流程状态
 
-Ticket 是在追踪平台上承载功能生命周期或可实现工作单元的通用追踪对象；GitHub Issues / GitLab Issues 是具体平台对象名称，领域资产统一称为 Ticket。
+Ticket 是在追踪平台上承载功能生命周期或可实现工作单元的通用追踪对象；GitHub Issues / GitLab Issues 是具体平台对象名称，领域资产统一称为 Ticket。主 tracker 以 `docs/agents/issue-tracker.md` 为准，当前模板默认 `local-markdown`，root 为 `docs/.scratch/`；Git remote 只用于代码托管、分支、PR / MR 和 CI，不代表 tracker 选择。
 
-每个功能先建立功能父 Ticket，用于汇总 Spec、设计、审查、OpenAPI Freeze、阻塞项和阶段证据（见 [[Spec基线]]、[[OpenAPI契约]]、[[条件强制门禁]]）。功能父 Ticket 不作为 Agent 直接实现的垂直切片；可独立验证的实现单元是垂直切片 Ticket（见 [[垂直切片Ticket]]）。
+每个功能先建立功能父 Ticket，用于汇总 Spec、设计、审查、OpenAPI Freeze、阻塞项和阶段证据（见 [[Spec基线]]、[[OpenAPI契约]]、[[产品设计影响与原型]]）。功能父 Ticket 不作为 Agent 直接实现的单元；可独立验证的实现单元是 [[垂直切片Ticket]]。
 
-流程状态规则：Spec 初稿、产品设计、原型、OpenAPI Draft 和待冻结资产使用 `ready-for-human`；只有通过必要门禁、阻塞边已清除并具备直接实现条件的垂直切片 Ticket 才能使用 `ready-for-agent`。`ready-for-human` 不表示可以直接进入实现；`ready-for-agent` 不得用于 Spec 初稿、原型、OpenAPI Draft 或其他未冻结资产。
+Local 完整功能包写入 `docs/.scratch/<feature>/`，其中 `parent-ticket.md` 汇总阶段资产与阻塞边，`issues/01-<slug>.md` 等文件是垂直切片或 Wayfinder 子 Ticket；不得把多个 Ticket 合成一个文件。根目录 `.scratch/` 与 `docs/requirements/tickets/` 只允许只读迁移检查。选定 GitHub / GitLab 但凭据或平台暂不可用时，在 `docs/.scratch/<feature>/` 生成待发布草案，`parent-ticket.md` 保留目标平台并标记 `publication: pending` 与 `pending_publication_to`，不得自动改投另一远程平台（见 [[实现仓库与跨仓库契约]]）。
 
-Ticket、Spec 和阶段证据必须按用户选择或当前主远程路由到 GitHub / GitLab；平台不可用时生成本地待发布草案，不自动改投其他平台（见 [[实现仓库与跨仓库契约]]）。平台规则与五态标签见 `docs/agents/issue-tracker.md` 与 `docs/agents/triage-labels.md`。连续自动推进期间累积的 Ticket 证据在人工暂停、handoff、进入实现、合并或发布边界集中同步范围、验证证据、风险、人工审查点和下一步。
+五态见 `docs/agents/triage-labels.md`：`needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix`。Local 主 tracker 在 Ticket 顶部用同名 `Status:` 记录；评论追加在 `## Comments`，状态变化须保留原因、证据引用和下一步。Wayfinder 的 `claimed` / `resolved` 只是临时工作状态，不是五态，进入正式切片前必须转换为上述之一。
+
+Spec 初稿、产品设计、原型、OpenAPI Draft 和待冻结资产使用 `ready-for-human`。只有通过必要门禁、阻塞边已清除并具备直接实现条件的垂直切片 Ticket，才能使用 `ready-for-agent`（见 [[条件强制门禁]] 与 [[切片实现合同]]）。调用 `to-tickets` 时新建切片的初始 `Status:` 固定为 `ready-for-human`，须由生命周期编排器核验完整就绪公式后才能改为 `ready-for-agent`。
+
+Ticket、Spec 和阶段证据按主 tracker 持久化。连续自动推进期间累积的证据，在人工暂停、handoff、进入实现、合并或发布边界集中同步范围、验证证据、风险、人工审查点、Ticket 状态和下一步（见 [[Fresh验证与独立审查]]、[[Agent入口规则]]）。Git checkpoint 只包含本轮明确范围，并说明主 tracker、同步状态、验证命令、剩余风险和下一步；获得用户授权后才提交或推送。
+
+## 来源
+
+- `docs/agents/issue-tracker.md`
+- `docs/agents/triage-labels.md`
+- `AGENTS.md`
+- `CONTEXT.md`
+- `docs/process/lifecycle-registry.yaml`

package/template/wiki/wiki/YSS/345/267/245/347/250/213/346/212/200/350/203/275/344/275/223/347/263/273.md

@@ -1,9 +1,23 @@
-# YSS 工程技能体系
+# YSS工程技能体系
 
-YSS skills 是项目内置的 YSS 工程规范技能，用于 DDD、UI、OpenAPI、Repository、Controller、DTO、组件和编码规范，与 Matt Pocock 的轻量流程技能互补（见 [[Matt技能体系]]）。
+YSS skills 是本项目内置的工程规范技能，用于 DDD、UI、OpenAPI、Repository、Controller、DTO、组件和编码规范；它们不替代 [[Matt技能体系]] 的通用流程入口。
 
-按领域划分：后端脚手架（`yss-ddd-scaffold-generator` 及 Domain / Application / Infrastructure / Web / Adapter 分层技能）、领域建模（`yss-domain`）、持久层（`yss-repository`、`yss-mybatis`）、Web 契约（`yss-web-controller`、`yss-dto`、`yss-openapi-governance`、`yss-openapi-draft-review`）、前端（`yss-ui`、`yss-components`、`yss-formily`、`yss-hook`、`yss-page-module-development`、`api-integration`）、以及横切组件（`yss-cache`、`yss-exception`、`yss-log`、`yss-userinfo`、`yss-security-algorithm`、`yss-resilience4j` 等）。
+技能清单、来源、版本、哈希和投影目标以 `skills-lock.json` 为准；README 与用户指南只解释。锁文件 `version` 为 `3`，`canonicalRoot` 为 `.agents/skills`。共享技能名的派生摘录见 `wiki/raw/skills-lock-names.md`。公开发布清单 `yss-public-skills.json` 只冻结 `yss-*` 工程技能；`llm-wiki` 不在该清单中，公开仓库 `iloveZzz/yss-spec-dev-skills` 只是单向发布投影，不是新的权威来源。
 
-技能路由纪律：核心 YSS skills 必须消费批准合同并返回 YSS Skill Execution Result（见 [[切片实现合同]]）；路径越界、证据缺失、未执行验证、`drift`、`violation` 或 `new_impacts` 阻断继续实现或触发重路由。禁止绕过合同与检查清单直接在 `AGENTS.md` 中自行发明细则。
+词汇上的分层是：核心技能默认可发现，负责生命周期控制或通用研发入口；专项技能由 Router 按影响面和实现合同按需选择；试验技能只在明确试验范围内使用，不进入 Router 默认技能闭包。`docs/agents/yss-skill-registry.yaml` 记录分层、别名、默认可发现性和运行时入口，但当前 `status: shadow`，Router 与生命周期不得按其裁剪发现面。
 
-技能治理：`yss-router` 选择最小技能集合（见 [[YSS路由与合同编译]]）；技能来源、版本、哈希与投影目标登记在 `skills-lock.json`（见 [[技能投影与锁定]]）；技能维护使用 `maintaining-skills`，验证强度由模板维护 L1 / L2 / L3 规则决定（见 [[模板维护流程]]）。
+进入实现后，后端领域、Application、Repository / Gateway、Web / DTO 由 [[YSS路由与合同编译]] 分别路由到对应 YSS skill；涉及 POJO 样板或对象转换时必须加载 `lombok`、`mapstruct` 和 `alibaba-java-code-style`。核心 YSS skills 必须消费已批准的 [[切片实现合同]] 并返回 YSS Skill Execution Result；路径越界、证据缺失、未执行验证、`drift`、`violation` 或 `new_impacts` 阻断继续实现或触发重路由。
+
+脚手架生成器 `yss-ddd-scaffold-generator` / `yss-frontend-scaffold-generator` 只在 `scaffold_status=required` 且受控生成合同已批准并持久化后运行，只产生机械骨架。UI 设计与原型走 `yss-design-system` 后 `yss-prototype-stage`（见 [[产品设计影响与原型]]）。OpenAPI 治理与 Draft 审查走 `yss-openapi-governance` / `yss-openapi-draft-review`（见 [[OpenAPI契约]]）。
+
+创建、修改或退役 skill 时使用 `maintaining-skills`，并按 [[模板维护流程]] 判定 L1 / L2 / L3。权威内容与投影见 [[技能投影与锁定]]。本地持久知识库走 [[LLM Wiki]]，不得把该技能误写成公开工程技能。
+
+## 来源
+
+- `AGENTS.md`
+- `CONTEXT.md`
+- `skills-lock.json`
+- `wiki/raw/skills-lock-names.md`
+- `docs/agents/yss-skill-registry.yaml`
+- `docs/agents/skills-maintenance.md`
+- `yss-public-skills.json`

package/template/wiki/wiki/YSS/350/267/257/347/224/261/344/270/216/345/220/210/345/220/214/347/274/226/350/257/221.md

@@ -1,9 +1,20 @@
-# YSS 路由与实现合同编译
+# YSS路由与合同编译
 
-`yss-router` 技能在 YSS 垂直切片进入实现时选择最小 YSS skill 集合，编译 Slice Implementation Contract 草案并检查实现就绪度。路由发生在垂直切片需要跨 Frontend / Backend / API 区域、需要实现就绪检查或需要 TDD 模式与证据计划时（见 [[垂直切片Ticket]]）。
+`yss-router` 是阶段 7 的实现合同编译器：它把已批准的生命周期资产和 [[垂直切片Ticket]] 编译为 Slice Implementation Contract 草案，不批准合同、不写业务代码、不设置 `ready-for-agent`。
 
-Router 的职责边界：使用 `yss-router` 选择最小 YSS skill 集合——后端领域、Application、Repository / Gateway、Web / DTO 分别路由到对应 YSS skill（见 [[YSS工程技能体系]]）；涉及 POJO 样板或对象转换时必须加载 `lombok`、`mapstruct` 和 `alibaba-java-code-style`。Router 编译 Slice Implementation Contract 草案后，由生命周期编排器核验并持久化（见 [[切片实现合同]]）。
+进入实现时先读 `docs/process/implementation-repo-integration.md`，完成 [[实现仓库与跨仓库契约]] 登记，再编译最小 skill 集合与当前实现合同。输入包括 Spec、切片 Ticket、需求冻结、适用的原型确认、OpenAPI Freeze / no-impact、系统 / 数据架构、Design Review、Build Architecture Checklist、实现仓库和验证命令；输入缺失、未批准或 `stale` 时输出 `blocked`，交回 `yss-product-lifecycle`（见 [[产品研发生命周期]]）。
 
-Router 不得自行批准合同或设置 `ready-for-agent`；批准、持久化与最终就绪判定属于编排器与门禁（见 [[条件强制门禁]] 与 [[Ticket与流程状态]]）。实现就绪检查还包括确认受影响的 frontend / backend 工程是 `existing`、`required` 还是 `initialized`，并登记实现仓库、分支、CI、验证命令和回滚点（见 [[实现仓库与跨仓库契约]]）。
+编译循环判断 frontend / backend / API / data / cross-repo 影响并填写 backend `component_impacts`，检查工程存在性与核心 / 长尾 skill 可用性，按 `router-contract.yaml` 计算强制依赖闭包，为切片生成基线合同、为当前行为生成工作单元增量路由，并选择 `behavior-tdd` 或 `controlled-generation`。业务行为使用 `behavior-tdd`；只有机械脚手架 / 生成物可用 `controlled-generation`，并记录例外和验证。输出只能是 `draft`、`blocked` 或 `ready-for-lifecycle-review`，交生命周期编排器核验和持久化。
 
-YSS Skill Execution Result 是 YSS 专项 skill 完成工作单元后返回的结构化执行证据，记录合同版本、变更文件、证据文件、实际验证、延期 seam、偏离和新增影响；实现者自报不构成最终通过，必须由 Router、生命周期编排器和独立 Reviewer 复核（见 [[Fresh验证与独立审查]]）。
+Router 不得输出 `approved`、`ready-for-agent` 或 `completed`。正式垂直切片必须消费已批准、已持久化且版本当前的 [[切片实现合同]]；Router 只生成草案。合同 schema、Backend 子合同和证据字段以 `yss-router` references 为准。只有通过必要门禁、阻塞边已清除并具备直接实现条件的垂直切片 Ticket，才能使用 `ready-for-agent`（见 [[Ticket与流程状态]]）。
+
+脚手架只在 `scaffold_status=required` 且受控生成合同已持久化、获得生命周期批准后运行；它只产生机械骨架，业务行为回到 Router 并使用 `behavior-tdd`。Harness 内实现路径必须落在 `apps/backend/<project>/` 或 `apps/frontend/<project>/`；`apps/backend/`、`apps/frontend/` 只能作为容器，`app/backend/`、`app/frontend/` 及其子路径一律阻断。专项技能来自 [[YSS工程技能体系]]，由 Router 按影响面选择，而不是按 shadow 注册表裁剪发现面（见 [[技能投影与锁定]]）。
+
+路径越界、证据缺失、未执行验证、`drift`、`violation` 或 `new_impacts` 时停止实现并重新路由。专项 skill 必须消费批准合同并返回 YSS Skill Execution Result；实现者自报不构成最终通过，须由 Router、生命周期编排器和独立 Reviewer 复核（见 [[Fresh验证与独立审查]]）。
+
+## 来源
+
+- `AGENTS.md`
+- `CONTEXT.md`
+- `.agents/skills/yss-router/SKILL.md`
+- `docs/process/implementation-repo-integration.md`

package/template/wiki/wiki/concept-table.md

@@ -0,0 +1,9 @@
+# concept-table
+
+| 概念 | 关系 | 文章 ID |
+|---|---|---|
+| LLM Wiki | IR，不替代 live 权威源 | LLM Wiki |
+| ingest | 把点名外源或已落盘笔记编进 wiki | LLM Wiki |
+| refresh | 已映射 live 源变更后重写命中页 | LLM Wiki |
+| query | 只读，回读 live，不写文件 | LLM Wiki |
+| Agent 入口 | 落成持久 wiki 点名 ingest | Agent入口规则 |

package/template/wiki/wiki/index.md

@@ -1,19 +1,19 @@
 # YSS Spec Project Template 知识索引
 
-本 wiki 收录 yss-spec-project-template 模板的核心知识：仓库身份、研发生命周期、契约资产、技能体系与质量治理。所有事实以 `raw/` 中的权威源文档为准。
+本 wiki 收录模板源仓库的核心知识：仓库身份、研发生命周期、契约资产、技能体系与质量治理。事实以仓库 live 权威源为准；`raw/` 是不可变拷贝或派生摘录。
 
 ## 入口与身份
 
-- [[模板总览]] — 模板总览：定位、结构与 Quickstart
-- [[仓库身份与路由]] — 仓库身份与路由：template-source 与 project-instance
-- [[Agent入口规则]] — Agent 入口规则：硬门禁与禁止事项
+- [[模板总览]] — 模板定位、结构与 Quickstart
+- [[仓库身份与路由]] — `template-source` 与 `project-instance`
+- [[Agent入口规则]] — Agent 入口、硬门禁与禁止事项
 
 ## 生命周期与流程
 
-- [[产品研发生命周期]] — 产品研发生命周期主流程
-- [[条件强制门禁]] — 21 个条件强制门禁
+- [[产品研发生命周期]] — 主阶段、产物与工作单元
+- [[条件强制门禁]] — 按影响面强制的生命周期门禁
 - [[影响面分诊与流程裁剪]] — 影响面分诊与流程裁剪
-- [[模板维护流程]] — 模板维护流程
+- [[模板维护流程]] — 模板源维护与 L1 / L2 / L3
 
 ## 契约资产
 
@@ -28,13 +28,14 @@
 
 - [[YSS路由与合同编译]] — YSS 路由与实现合同编译
 - [[YSS工程技能体系]] — YSS 工程技能体系
-- [[Matt技能体系]] — Matt Pocock Engineering Skills
-- [[技能投影与锁定]] — 技能投影与 skills-lock 锁定
+- [[Matt技能体系]] — Matt Engineering Skills
+- [[技能投影与锁定]] — 技能投影与 `skills-lock.json`
 - [[实现仓库与跨仓库契约]] — 实现仓库与跨仓库契约
+- [[LLM Wiki]] — 本地持久知识库的 init / refresh / rebuild / ingest
 
 ## 质量与治理
 
-- [[Ticket与流程状态]] — Ticket 与流程状态
+- [[Ticket与流程状态]] — Ticket 与五态流程状态
 - [[Fresh验证与独立审查]] — Fresh Verification 与独立审查
-- [[模板发布门禁与验证]] — 模板发布门禁与验证
+- [[模板发布门禁与验证]] — `scripts/verify-template`
 - [[复盘与权威资产修订]] — 复盘与权威资产修订

package/template/wiki/wiki/log.md

@@ -15,3 +15,30 @@
 ## [2026-08-09] ANALYZE | 生成知识图谱
 
 运行 understand-knowledge 解析 wiki，生成交互式知识图谱。
+
+## [2026-08-23] REBUILD | 按 llm-wiki schema 重编译本仓知识库
+
+接入 `llm-wiki` 后走 rebuild（已有 `wiki/index.md`，禁止 init 覆盖）。重建 `.wiki-manifest.json`（schemaVersion 1，profile: documents），raw 对齐 live 并扩展流程 / Agent / 契约源；`skills-lock.json` 只保留技能名派生摘录。保留原 22 个文章 ID，新增 `LLM Wiki`。LLM 页全量重写并补 `## 来源`。`inventory.mjs hash` 后 `lint-wikilinks` 23 篇文章 / 203 条 wikilink 通过。抽查 5 条 claim 对照 live 源。
+
+## [2026-08-23] FIX | 按 code-review 对齐 lint 契约与 wiki 边界
+
+lint 脚本改为失败跨路径 wikilink、校验 manifest sha256，并要求 H1 等于文章 ID。通用 skill 不再写死本仓文档语言。`documents` profile 去掉 `code-surface`。H1 与 `CLAUDE.md` 按审查结论收束。
+
+## [2026-08-23] REFRESH | 登记前端 pnpm / 后端 mvnw 验证命令
+
+`AGENTS.md` 与根目录 `CLAUDE.md` 写入 frontend `pnpm`、backend `./mvnw` 优先序；细则落在 `docs/process/implementation-repo-integration.md`。刷新 [[Agent入口规则]] 与 [[实现仓库与跨仓库契约]]。
+
+## [2026-08-23] REFRESH | llm-wiki 去掉外部技能关联
+
+技能正文不再点名其他 skill。刷新 [[LLM Wiki]]：一次性笔记标为范围外，删除图谱配对与 `/deep-research` 分流表述。
+
+## [2026-08-23] FIX | 按 skill-names 配方重放 derived 摘录
+
+`skills-lock.json` 登记 `extract.kind: skill-names`，用 `extract.mjs` 重写 `raw/skills-lock-names.md`（只含稳定排序的技能名）。
+
+## [2026-08-23] REFRESH | llm-wiki I1–I5 源状态、advise、ingest 与 Status
+- changed: AGENTS.md, CONTEXT.md, skills-lock.json
+- articles: Agent入口规则, LLM Wiki, 模板总览, 技能投影与锁定
+- unmapped: (none)
+
+同步 raw 中的 `AGENTS.md` / `CONTEXT.md`，重放 `skill-names` 摘录（内容未变）。刷新 [[Agent入口规则]]、[[LLM Wiki]] 与 [[模板总览]] 中与 ingest / refresh 分界相关的句子；新增基础设施 `concept-table.md`；`CLAUDE.md` 补 Status / INGEST。未改其余命中页：AGENTS 仅增 ingest 入口句，CONTEXT 仅澄清 ingest 不替代权威源，锁文件只变 `effectiveHash`。

package/template/wiki/wiki//344/272/247/345/223/201/347/240/224/345/217/221/347/224/237/345/221/275/345/221/250/346/234/237.md

@@ -1,9 +1,20 @@
 # 产品研发生命周期
 
-`project-instance` 仓库按产品研发生命周期分诊任务。日常骨架为：入口分诊 → 机会与 Discovery → 业务 / Spec / 功能架构 → 产品设计与需求冻结 → 系统 / 数据架构与工程契约设计审查 → 契约冻结与 Ticket 正式化 → 垂直切片与 TDD 实现 → 验证发布与复盘。
+`project-instance` 按产品研发生命周期分诊任务。主阶段以 `docs/process/lifecycle-registry.yaml` 为准，注册表当前列出 8 个：入口分诊、Discovery、Spec / 功能架构、产品设计、系统 / 数据架构与工程契约、Ticket 正式化、垂直切片实现、验证 / 发布 / 复盘。
 
-任务开始时先根据影响面判断是小改动、中等变更还是新模块 / 高风险变更，定位最近可信阶段，再执行对应活动。整个生命周期由 [[条件强制门禁]] 中的 21 个条件强制门禁约束：命中触发条件时必须完成，未命中时只记录 `not-applicable` 及原因，不生成空文档。
+任务开始时先读 `yss-project.yaml` 确认仓库身份（见 [[仓库身份与路由]]），再用 [[影响面分诊与流程裁剪]] 判定变更类型、影响面和最近可信阶段，然后按注册表执行命中的工作单元与 [[条件强制门禁]]。条件门禁全部按影响面强制：命中必须完成；未命中只记录 `not-applicable` 及原因，不生成空文档。产物、工作单元和证据不得统称为门禁。
 
-新功能或较大变更先用 `grill-with-docs` 澄清需求，再用 `to-spec` 形成 Spec 基线（见 [[Spec基线]]）。只要进入 Spec 基线，必须产出产品总体设计或功能架构；涉及 UI 与主流程、导航、权限、异常 / 恢复状态或 API 反推时，构成产品设计影响并强制 [[产品设计影响与原型]] 流程。API 契约变更先形成 OpenAPI 3.1 Draft，经必要的工程基线、系统 / 数据架构和设计审查后 Freeze（见 [[OpenAPI契约]]）。
+新功能或较大变更默认进入 `yss-product-lifecycle` 的原生 Discovery / 需求分析工作单元（`work-unit.discovery-opportunity`、`work-unit.discovery-requirements`），再经 Spec 综合形成 [[Spec基线]]。`grill-with-docs` 与 `to-spec` 只是用户显式兼容入口，不是默认路径；Spec 基线与产品设计影响的完整判定以注册表和裁剪规则为准。[[SpecDelta]] 只记录相对既有冻结 Spec 基线的高风险行为差异；全新产品、全新模块和低风险调整不生成。
 
-契约冻结完成后，使用 `to-tickets` 将需求拆成可独立验证的窄垂直切片 Ticket（见 [[垂直切片Ticket]]），禁止只按 Adapter / Application / Domain / Infrastructure 横向拆分。每个功能先建立功能父 Ticket 汇总阶段证据（见 [[Ticket与流程状态]]）。生命周期各阶段资产与门禁的权威映射以生命周期资产映射为准。
+命中产品设计影响时走 [[产品设计影响与原型]]；未命中记录 `not-applicable`。API 契约变更先形成 OpenAPI 3.1 Draft，经必要的工程基线、系统 / 数据架构和设计审查后 Freeze（见 [[OpenAPI契约]]），再进入实现。无 API 影响时显式记录，不编造契约。
+
+OpenAPI Freeze 或无 API 影响记录完成后，由生命周期原生 Ticket 正式化工作单元（`work-unit.ticket-decomposition`）拆成可独立验证的窄 [[垂直切片Ticket]]；用户显式 `to-tickets` 仅作为兼容入口，禁止只按 Adapter / Application / Domain / Infrastructure 横向拆分。每个功能先建功能父 Ticket 汇总 Spec、设计、审查、OpenAPI Freeze、阻塞项和阶段证据（见 [[Ticket与流程状态]]）。正式实现必须消费已批准、已持久化且版本当前的 [[切片实现合同]]；`yss-router` 只生成草案，不批准合同、不设置 `ready-for-agent`。
+
+安全 / 权限不设独立生命周期资料或专属门禁。日常功能不做额外登记、`not-applicable` 或推导校验；只有需求或冻结资产明确要求改变认证、授权、租户隔离、敏感数据或合规行为时，才把该行为写入普通 Spec、API、架构、验收和测试 seam，并仅按实际 UI、API、Backend、Data、High-risk 影响触发既有门禁。普通 action 注册、沿用既有认证中间件、未变化的 `401` / `403`、一般字段、SQL / DDL / 迁移和上传 / 下载本身不构成安全 / 权限专项。`seam-deferred` 只能显式记录风险、责任人、后续 Ticket、验证计划和目标版本或发布日期。
+
+## 来源
+
+- `docs/process/lifecycle-registry.yaml`
+- `docs/process/harness-process-tailoring.md`
+- `AGENTS.md`
+- `CONTEXT.md`

package/template/wiki/wiki//344/272/247/345/223/201/350/256/276/350/256/241/345/275/261/345/223/215/344/270/216/345/216/237/345/236/213.md

@@ -1,9 +1,19 @@
 # 产品设计影响与原型
 
-产品设计影响指 UI 变化触及主流程、导航、权限体验、异常 / 恢复状态、状态流转或 API 反推时构成的设计工作，强制产出页面流（低保真草图）、状态矩阵、Ant Design v6 高保真 HTML 原型和用户确认。
+UI 影响不等于产品设计影响。UI 影响是会改变用户可见页面、导航、交互流程、状态呈现或权限体验的功能影响；纯后端、API、批处理或数据变更不自动构成 UI 影响。产品设计影响更窄：只有 UI 变化触及主流程、导航、权限体验、异常 / 恢复、状态流转或 API 反推时，才需要页面流、状态矩阵和原型校准。
 
-判定规则：只有上述影响才构成产品设计影响并强制完整流程；文案、token、颜色、间距和无行为变化的孤立视觉修复属于 UI 影响，但不自动构成产品设计影响，记录 `not-applicable`（见 [[影响面分诊与流程裁剪]]）。
+文案、token、颜色、间距和无行为变化的孤立视觉修复属于 UI 影响，但不自动构成产品设计影响。未命中时按 [[影响面分诊与流程裁剪]] 记录 `not-applicable` 及原因，不生成空的设计包。[[Spec基线]] 模板也约定：只有存在 UI 影响时，才强制低保真页面草图、状态矩阵、高保真 HTML 原型和用户确认；否则同样记 `not-applicable`。两条判定要同时看，不能把「有一点可见变化」直接升级成完整产品设计流程。
 
-流程：低保真原型（wireframe / Excalidraw / 页面草图）→ 原型评审（对照状态矩阵与交互说明）→ 通过后进入 Ant Design v6 高保真 HTML 原型 → 用户确认 → 反馈 Spec 校准与 OpenAPI Draft（见 [[Spec基线]] 与 [[OpenAPI契约]]）。高保真 HTML 原型用于在浏览器中审查真实视觉密度、交互状态和页面流，不等同于生产前端实现。
+命中产品设计影响时，生命周期在 `stage.product-design` 产出交互说明和低保真原型；存在状态流转、异常或恢复时再补状态矩阵；需要视觉与交互校准时再做高保真 HTML 原型。`work-unit.prototype-design` 的完成条件是原型评审、高保真验证和用户确认门禁均通过。对应门禁为 `gate.prototype-reviewed`、`gate.prototype-verified`、`gate.user-confirmation`，证据分别是独立评审结论、`antd` CLI 与浏览器验证、用户确认记录，见 [[条件强制门禁]]。
 
-UI 设计、原型与主题实现由 `yss-design-system` 技能提供 Ant Design v6 事实，产出前用 `antd` 查询设计系统事实；原型评审使用 `prototype-review`，高保真原型使用 `high-fidelity-html-prototype`（见 [[YSS工程技能体系]] 与 [[Matt技能体系]]）。
+高保真 HTML 原型是低保真评审通过后、在浏览器中审查真实视觉密度、交互状态和页面流的产品设计资产。它不等于生产前端，也不替代 OpenAPI、Spec 校准或垂直切片。UI 设计、原型、组件或主题先走 `yss-design-system`，再走 `yss-prototype-stage`；Codex 再路由 `product-design:index`，其他 Agent 交付等价合同资产。产出前后用 `antd` CLI 记录 Ant Design v6 与浏览器验证事实，技能入口见 [[YSS工程技能体系]]。
+
+Visual Baseline Contract 是为生产前端还原冻结页面、视口、交互状态、参考图像和允许差异的可验收合同。它不是单张原型截图，也不是绝对像素匹配；每条基线必须能定位到同一视口和同一状态再复验。UI 影响切片在提升 `ready-for-agent` 前还要有前端实现还原计划，合并或发布前做还原验证，见 [[垂直切片Ticket]] 与 [[Fresh验证与独立审查]]。校准结论回写 Spec，并作为 [[OpenAPI契约]] Draft 的交互输入；有 UI 且用户未确认前，不得进入 OpenAPI Draft 评审。整段工作挂在 [[产品研发生命周期]]，不越过需求冻结直接写生产页面。
+
+## 来源
+
+- `CONTEXT.md`
+- `AGENTS.md`
+- `docs/templates/spec-template.md`
+- `docs/process/lifecycle-registry.yaml`
+- `docs/api/templates/openapi-draft-review-checklist.md`

package/template/wiki/wiki//344/273/223/345/272/223/350/272/253/344/273/275/344/270/216/350/267/257/347/224/261.md

@@ -1,9 +1,20 @@
 # 仓库身份与路由
 
-仓库身份由根目录 `yss-project.yaml` 显式声明，只包含 `schema_version` 与 `repository_mode` 两个字段，是 CLI 与 Agent 共享的稳定契约（ADR-0002）。`repository_mode` 有两种合法取值：`template-source`（模板源仓库）与 `project-instance`（模板实例仓库）。
+仓库身份只由根目录 `yss-project.yaml` 声明。该清单是 CLI 与 Agent 共享的稳定契约（ADR-0002），只含 `schema_version` 与 `repository_mode`，不写入项目名称、团队规模或 Tracker。`repository_mode` 仅有两个合法值：`template-source`（模板源仓库）与 `project-instance`（模板实例仓库）。
 
-`template-source` 模式使用模板维护流程：影响面分析 → 修改单一事实来源 → 同步技能投影与派生文档 → 执行压力场景与 `scripts/verify-template` → 独立审查与 Git checkpoint。该模式不默认生成具体产品的 Spec、原型、OpenAPI 或垂直切片 Ticket（详见 [[模板维护流程]] 与 [[模板发布门禁与验证]]）。
+文件缺失、schema 版本不支持或模式值非法时，必须停止路由并执行迁移检查；不得根据目录、Git 远程或占位符猜测身份。当前仓库 live 值为 `schema_version: 1`、`repository_mode: template-source`，因此默认走 [[模板维护流程]]，不按具体产品生成 Spec、原型、OpenAPI 或垂直切片 Ticket。总览见 [[模板总览]]。
 
-`project-instance` 模式按产品研发生命周期分诊任务（见 [[产品研发生命周期]]）：入口分诊 → 机会与 Discovery → 业务 / Spec / 功能架构 → 产品设计与需求冻结 → 系统 / 数据架构与工程契约设计审查 → 契约冻结与 Ticket 正式化 → 垂直切片与 TDD 实现 → 验证发布与复盘。
+`template-source` 按「影响面 → 单一事实来源 → 投影 / 派生资产 → 分级证据」维护，发布阻断门禁是 `scripts/verify-template`（见 [[模板发布门禁与验证]]）。`project-instance` 先用 `docs/process/harness-process-tailoring.md` 判定变更类型、影响面和最近可信阶段（见 [[影响面分诊与流程裁剪]]），再按 `docs/process/lifecycle-registry.yaml` 执行命中的工作单元和条件门禁，进入 [[产品研发生命周期]]。
 
-文件缺失、schema 版本不支持或模式值非法时，必须停止路由并执行迁移检查，不得根据目录、Git 远程或占位符猜测身份。外部 `create-yss-spec` CLI 从模板初始化仓库时必须将模式改写为 `project-instance`，这一跨仓库契约的细节见 raw 源 `create-yss-spec-contract.md`。仓库身份判定是 Agent 的首要步骤，直接影响后续所有流程选择（见 [[Agent入口规则]]）。
+外部 `create-yss-spec` 创建或接管的产品仓库必须写入 `repository_mode: project-instance`；合法 `template-source` 可在 attach 时转换为 `project-instance`，合法 `project-instance` 保留并校验，非法身份在写入前阻断。CLI 只管理 manifest 声明的研发管理资产，不接管前后端运行时代码、业务目录、用户文件或 `.git`。
+
+当前仓库默认是研发管理仓库，运行时代码优先位于已登记的独立实现仓库（见 [[实现仓库与跨仓库契约]]）。只有用户明确选择本仓库承载实现代码时，才使用 `apps/backend/<project>/` 或 `apps/frontend/<project>/`；`app/backend/`、`app/frontend/` 及其子路径禁止作为工程输出。身份判定是每个任务的第一步，后续硬门禁见 [[Agent入口规则]]。
+
+## 来源
+
+- `yss-project.yaml`
+- `AGENTS.md`
+- `README.md`
+- `CONTEXT.md`
+- `docs/adr/0002-yss-project-repository-mode.md`
+- `.template-source/contracts/create-yss-spec-repository-mode-contract.md`

package/template/wiki/wiki//345/210/207/347/211/207/345/256/236/347/216/260/345/220/210/345/220/214.md

@@ -1,9 +1,21 @@
-# Slice Implementation Contract
+# 切片实现合同
 
-Slice Implementation Contract 是进入实现前由 `yss-router` 根据冻结资产和垂直切片编译、再由生命周期编排器批准的实现合同。合同至少包含 Common、Frontend、Backend、Contract 和 Cross-repo 子合同，以及工作单元、TDD 模式、允许写路径、禁止模式、证据和验证命令。
+Slice Implementation Contract 是阶段 7 进入实现前的实现合同：由 `yss-router` 根据冻结资产和 [[垂直切片Ticket]] 编译草案，再由生命周期编排器批准并持久化。正式垂直切片必须消费已批准、已持久化且版本当前的合同。Router 只生成草案，不得输出 `approved`、`ready-for-agent` 或 `completed`。
 
-Router 只能生成合同草案，不能自行批准合同或设置 `ready-for-agent`；批准与持久化由生命周期编排器完成（见 [[YSS路由与合同编译]] 与 [[Ticket与流程状态]]）。Backend 子合同保留额外强约束，至少包含 `required_skills`、`allowed_write_paths`、`forbidden_patterns`、`expected_evidence_files`、`seam_deferred`、`verification_commands` 六个字段。
+Router 先读 [[Spec基线]]、切片 Ticket、需求冻结、适用的原型确认、[[OpenAPI契约]] Freeze 或无 API 影响、系统 / 数据架构、Design Review、Build Architecture Checklist、实现仓库和验证命令。输入缺失、未批准或 `stale` 时输出 `blocked`，交回 `yss-product-lifecycle`。编译结果只能是 `draft`、`blocked` 或 `ready-for-lifecycle-review`，见 [[YSS路由与合同编译]] 与 [[Ticket与流程状态]]。
 
-合同将系统 / 数据架构、ADR、工程基线、OpenAPI Freeze 与风险 / 回滚约束转译为 Build Architecture Checklist（见 [[OpenAPI契约]]）。核心 YSS skills 必须消费批准合同并返回 YSS Skill Execution Result；路径越界、证据缺失、未执行验证、`drift`、`violation` 或 `new_impacts` 阻断继续实现或触发重路由。
+合同含 Common、Frontend、Backend、Contract、Cross-repo 子合同，外加 `work_units`。Common 收影响面、项目根、技能闭包、允许写路径、禁止模式、证据、验证命令、人审点和完整重路由触发器。Frontend 在适用时绑定批准原型、状态矩阵、生成客户端和组件 / E2E seam。Contract 记录 API 影响、Freeze 或 no-impact 引用、生成客户端和契约测试。Cross-repo 记录参与仓库、交付顺序、集成验证和回滚顺序，见 [[实现仓库与跨仓库契约]]。Backend 另有强约束：必须逐项填写 `component_impacts`，并补 `application_boundary`、`transaction_boundary`、`persistence_strategy`、`seam_deferred` 等字段；端到端后端切片必须包含 Application。未填写 Backend 合同时不得写后端业务代码。
 
-合同编译依赖已冻结的 Spec 与垂直切片（见 [[Spec基线]] 与 [[垂直切片Ticket]]），跨仓库切片还需补充 Cross-repo 子合同（见 [[实现仓库与跨仓库契约]]）。实现者自报 `implemented` 不构成最终通过，必须由 Router、生命周期编排器和独立 Reviewer 复核（见 [[Fresh验证与独立审查]]）。
+`scaffold_status=required` 时，先由 Router 按脚手架 schema 编译 `controlled-generation` 合同草案，经生命周期编排器批准并持久化后再生成机械骨架。脚手架合同在 Router 阶段只能是 `draft` / `ready-for-lifecycle-review` / `blocked`，只覆盖业务代码前的工程骨架，不能替代随后的 Slice Implementation Contract。骨架完成后业务行为回到 Router，按 `behavior-tdd` 逐单元实现；打印命令或单项 `./mvnw validate` 不能代替合同批准。
+
+路径越界、证据缺失、未执行验证、`drift`、`violation` 或 `new_impacts` 时停止实现并重新路由。专项 skill 必须消费当前批准合同并返回 `YSS Skill Execution Result`；实现者自报 `implemented` 不构成最终通过，须由 Router、生命周期编排器和独立 Reviewer 复核，见 [[Fresh验证与独立审查]]。`seam-deferred` 只能显式记录风险、责任人、后续 Ticket、验证计划和目标版本或发布日期。技能闭包与长尾补齐由 [[YSS工程技能体系]] 按 Router 契约执行，不可用时显式 `blocked`。
+
+## 来源
+
+- `CONTEXT.md`
+- `AGENTS.md`
+- `.agents/skills/yss-router/SKILL.md`
+- `.agents/skills/yss-router/references/slice-implementation-contract.md`
+- `.agents/skills/yss-router/references/yss-skill-execution-result.md`
+- `docs/templates/vertical-slice-ticket-template.md`
+- `docs/process/lifecycle-registry.yaml`

package/template/wiki/wiki//345/236/202/347/233/264/345/210/207/347/211/207Ticket.md

@@ -1,9 +1,23 @@
-# 垂直切片 Ticket
+# 垂直切片Ticket
 
-垂直切片（Vertical Slice）是贯穿所有受影响层、可独立验证的窄功能路径。契约冻结后，使用 `to-tickets` 将需求拆成可独立验证的窄垂直切片 Ticket，禁止只按 Adapter / Application / Domain / Infrastructure 横向拆分。
+垂直切片是贯穿所有受影响层、可独立验证的窄功能路径。每个功能先建立功能父 Ticket，用来汇总 Spec、设计、审查、OpenAPI Freeze、阻塞项和阶段证据；父 Ticket 本身不是 Agent 直接实现的切片。契约冻结后，由生命周期原生 `work-unit.ticket-decomposition` 拆出窄切片；用户显式 `to-tickets` 只是兼容入口。禁止只按 Adapter / Application / Domain / Infrastructure 横向拆分。
 
-垂直切片 Ticket 记录范围、阻塞关系、验收标准和验证证据，是 Agent 直接实现的工作单元。只有通过必要门禁、阻塞边已清除并具备直接实现条件时，才能标记 `ready-for-agent`；其余切片保持 `ready-for-human`（见 [[Ticket与流程状态]] 与 [[条件强制门禁]]）。
+模板 `docs/templates/vertical-slice-ticket-template.md` 默认 `Status: ready-for-human`，frontmatter `status` 同值。正文必须写清要构建的端到端行为、覆盖的用户故事、OpenAPI 影响、验收标准、测试 seam、Slice Implementation Contract、阻塞关系和完成定义。它必须贯穿受影响层，不能只是某一层的横向任务。YSS active 调用 `to-tickets` 时，新建切片的初始 `Status:` 也固定为 `ready-for-human`。
 
-切片拆分以冻结的 Spec 与 OpenAPI 契约为输入（见 [[Spec基线]] 与 [[OpenAPI契约]]）。每个切片进入实现前，先由 `yss-router` 编译 Slice Implementation Contract 草案，再由生命周期编排器核验并持久化（见 [[切片实现合同]] 与 [[YSS路由与合同编译]]）。后端切片必须在统一合同中补齐 Backend Slice Implementation Contract，包含 `required_skills`、`allowed_write_paths`、`forbidden_patterns`、`expected_evidence_files`、`seam_deferred` 与 `verification_commands`。
+Spec 初稿、产品设计、原型、OpenAPI Draft 和待冻结资产一律使用 `ready-for-human`。只有通过必要门禁、阻塞边已清除并具备直接实现条件的垂直切片，才能使用 `ready-for-agent`。五态标签为 `needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix`，见 [[Ticket与流程状态]]。Ticket、Spec 和阶段证据按 `docs/agents/issue-tracker.md` 选定的主 tracker 持久化；Git remote 不代表 tracker 选择。当前模板默认 `local-markdown`，根为 `docs/.scratch/`。
 
-垂直切片按 `tdd` 使用已确认的公开 seam 逐切片实现，核心 YSS skills 必须消费批准合同并返回 YSS Skill Execution Result；路径越界、证据缺失、未执行验证、`drift`、`violation` 或 `new_impacts` 阻断继续实现或触发重路由。切片模板见 raw 源 `vertical-slice-ticket-template.md`。
+切片拆分以冻结 [[Spec基线]] 和 [[OpenAPI契约]]（或无 API 影响记录）为输入。每个切片进入实现前必须挂当前 [[切片实现合同]]：`contract_id`、`contract_version`、`contract_ref`，Router 状态只能是 `draft / blocked / ready-for-lifecycle-review`，生命周期批准状态为 `pending / approved / rejected`。Router 不得自行批准合同，也不得把本 Ticket 推进为 `ready-for-agent`；只有生命周期编排器核验并持久化当前版本、清除阻塞边后才能改状态。合同编译见 [[YSS路由与合同编译]]。
+
+工作单元必须写验收行为、主 / 辅 skill、`behavior-tdd` 或 `controlled-generation`、允许写路径、预期证据和验证命令。业务规则、状态机、事务、权限、错误映射、复杂查询和用户可见交互必须 `behavior-tdd`；`controlled-generation` 只覆盖机械脚手架、样板、冻结客户端或配置，并记录 exception reason。涉及后端时必须填写 Backend 合同与 skill 表，不得只写「符合 YSS」。出现 `drift`、`violation` 或非空 `new_impacts` 时暂停受影响工作单元，不得先完成代码再补合同。
+
+完成定义要求：实现与测试通过，调试 / 原型代码已移除，合同与 `YSS Skill Execution Result` 已回勾，实际 changed files 均在允许路径内，验证结果含执行时间，重路由状态有明确结论且合同未 `stale`。路径越界、证据缺失、未执行验证时停止实现并重新路由，见 [[条件强制门禁]] 与 [[实现仓库与跨仓库契约]]。整条链路属于 [[产品研发生命周期]] 的 Ticket 正式化与垂直切片实现阶段。
+
+## 来源
+
+- `CONTEXT.md`
+- `AGENTS.md`
+- `docs/templates/vertical-slice-ticket-template.md`
+- `docs/process/lifecycle-registry.yaml`
+- `docs/agents/issue-tracker.md`
+- `docs/agents/triage-labels.md`
+- `.agents/skills/yss-router/SKILL.md`

package/template/wiki/wiki//345/244/215/347/233/230/344/270/216/346/235/203/345/250/201/350/265/204/344/272/247/344/277/256/350/256/242.md

@@ -1,9 +1,20 @@
 # 复盘与权威资产修订
 
-发布后或阶段性完成后做复盘判断：出现架构返工、验证返工、IMPORTANT / CRITICAL review finding 或人工确认延期时，落简体中文复盘并修订权威资产。
+发布后或阶段性完成后做复盘判断。`artifact.retrospective` 属于 `stage.verification-release-retrospective`，触发条件是发布后或阶段性完成后满足复盘触发条件。出现架构返工、验证返工、IMPORTANT / CRITICAL review finding 或人工确认延期时，落简体中文复盘并修订权威资产。
 
-复盘输入包括验证证据、审查报告、Ticket 证据与 Git checkpoint 记录（见 [[Fresh验证与独立审查]] 与 [[Ticket与流程状态]]）。复盘输出按 `docs/templates/retro-report-template.md` 记录，发现的问题回流到对应单一事实来源：流程语义问题修订生命周期映射或裁剪指南，词汇问题修订 `CONTEXT.md`，决策问题沉淀 ADR，技能问题进入 `maintaining-skills` 修订流程（见 [[模板维护流程]] 与 [[条件强制门禁]]）。
+复盘与发布工作单元是 `work-unit.release-and-retrospective`：输入已审查候选、发布窗口和回滚点；输出发布 / 回滚证据和复盘记录；完成条件为人工发布裁决、fresh verification 和治理回流均完成（见 [[Fresh验证与独立审查]] 与 [[产品研发生命周期]]）。
 
-复盘修订遵循影响面分析与条件强制门禁：命中触发条件才生成对应资产，未命中记录 `not-applicable`（见 [[影响面分诊与流程裁剪]]）。复盘发现的跨仓库问题（如 `create-yss-spec` 契约偏差）须同步到外部仓库责任边界（见 [[实现仓库与跨仓库契约]]）。
+复盘输入包括验证证据、审查报告、Ticket 证据与 Git checkpoint（见 [[Ticket与流程状态]]）。落地文档可用 `docs/templates/retro-report-template.md`，包含「做得好的地方」「需要改进的地方」「改进动作」「沉淀去向」。发现回流到对应单一事实来源：领域词汇修订 `CONTEXT.md`，入口与硬门禁修订 `AGENTS.md`，主阶段 / 门禁 / 工作单元修订 `docs/process/lifecycle-registry.yaml`，影响面与 `not-applicable` 修订 `docs/process/harness-process-tailoring.md`，技能问题进入 `maintaining-skills` 并更新 `skills-lock.json`（见 [[模板维护流程]] 与 [[条件强制门禁]]）。
 
-复盘是模板维护流程的最后一步，也是下一次迭代影响面分析的输入，形成持续改进闭环。
+复盘修订仍按影响面分诊：命中触发条件才生成对应资产，未命中只记录 `not-applicable` 及原因，不生成空文档（见 [[影响面分诊与流程裁剪]]）。跨仓库契约偏差须同步到外部仓库责任边界，任一参与仓库未完成契约对齐和集成验证时，不得单独声称整体可发布（见 [[实现仓库与跨仓库契约]]）。
+
+Git checkpoint 只包含本轮明确范围；获得用户授权后才提交或推送。复盘记录是下一次入口分诊与影响面分析的输入，不替代权威源本身。
+
+## 来源
+
+- `AGENTS.md`
+- `CONTEXT.md`
+- `docs/process/lifecycle-registry.yaml`
+- `docs/process/harness-process-tailoring.md`
+- `docs/templates/retro-report-template.md`
+- `docs/agents/skills-maintenance.md`