create-yss-spec 2.1.15 → 2.2.0

package/template/wiki/wiki/CLAUDE.md

@@ -1,28 +0,0 @@
-# CLAUDE.md — Wiki schema
-
-本文档是本 wiki 的 schema（结构契约）。正文语言遵循宿主项目的文档语言规则；英文专有名词、类名、枚举值、表名与 API 路径保持原样。
-
-本 wiki 收录本仓库模板源流程知识。权威事实以 live 文件为准。
-
-## 三层结构
-
-- **`raw/`** — 不可变原始源。从 live 文档拷贝，或从 live 源提取且标明出处的派生摘要。只读，不靠改 raw 来「修正」事实。
-- **文章（`wiki/*.md`）** — LLM 生成的知识文章。文件名（不含 `.md`）即文章 ID，必须全局唯一。使用 `[[wikilink]]` 互引。
-- **`index.md`** — 内容目录。`##` 节标题定义分类；节下列出该分类下的 `[[wikilink]]`。
-
-## 文章写作约定
-
-- 首行为 `# H1`，H1 文本等于文章 ID，随后紧跟首段摘要。
-- 正文使用 `[[目标文章名]]`；目标必须是本 wiki 内存在的文章文件名（不含 `.md`）。
-- 论断必须能追溯到 `raw/` 或 live 代码路径。文末使用 `## 来源`。
-- 分类归属由 `index.md` 决定。
-- 可选 frontmatter：`human-owned: true` 时 refresh / rebuild 不得重写正文。
-- 仅当多个来源冲突，或 live 与旧 raw 不一致时写可选 `## Status`（`Disputed` / `Outdated`）。单一 live 正确则不写。`human-owned` 页不写 Status。
-
-## 基础设施文件
-
-`index.md`、`log.md`、`CLAUDE.md`、`AGENTS.md`、`soul.md`、`concept-table.md` 为基础设施文件，不视为文章。
-
-## 操作日志
-
-`log.md` 只追加。格式：`## [YYYY-MM-DD] OPERATION | 描述`（CREATE / UPDATE / LINK / FIX / REFRESH / REBUILD / RETIRE / LINT / INGEST）。

package/template/wiki/wiki/Fresh/351/252/214/350/257/201/344/270/216/347/213/254/347/253/213/345/256/241/346/237/245.md

@@ -1,19 +0,0 @@
-# Fresh验证与独立审查
-
-Fresh Verification 指完成前重新执行的验证证据，包括测试命令、契约校验、关键路径检查或人工审查结论。任何「完成 / 可合并 / 可发布」结论必须基于本轮 fresh verification，不接受「之前跑过」或实现者自述。注册表已废弃 `work-unit.fresh-verification` 与 `work-unit.independent-review`；当前对应证据是 `evidence.fresh-verification`。
-
-实现者不能承担命中的独立审查。模板维护按 L1 / L2 / L3 分别使用 `self-check` / 人工 checkpoint、`focused-independent`、`formal-independent`（见 [[模板维护流程]] 与 [[影响面分诊与流程裁剪]]）。强度由 `docs/process/maintenance-intensity.yaml` 计算，未给出 trigger 时使用该策略的 `default_level`（当前为 L2）。L1 至少一项与变更直接相关的实际检查；L2 需要修改前可失败的最小反例以及本轮 fresh verification；L3 需要完整 RED、GREEN、REFACTOR、压力场景与本轮 fresh verification。模板发布、代码切片和高风险变更仍必须由其他 Agent 或人工独立审查。
-
-`project-instance` 的独立代码审查工作单元是 `work-unit.code-review`：输入不可变候选快照、Spec、Ticket、合同和执行结果；输出 Standards、Spec、UI fidelity 三轴 Review 与 fresh verification；findings 已处理后须重新捕获候选并全量复审。旧文「代码审查双轴」已过期，不得再按标准符合性 / Spec 符合性两轴描述（见 [[Matt技能体系]]）。UI 影响切片的前端实现还原验证由独立 Reviewer 通过 UI fidelity 轴（见 [[产品设计影响与原型]]）。
-
-测试质量基线是模板推荐值：Domain / Application `>= 90%`、API `>= 80%`、前端组件 `>= 75%`、已明确的关键流程 `100% E2E`。只有项目实例在测试策略中明确采纳或覆盖后才构成 CI 门禁；未定义关键流程清单时，不得声称其 E2E 覆盖率达到 100%。YSS Skill Execution Result 必须由 Router、生命周期编排器和独立 Reviewer 复核，实现者自报 `implemented` 不构成最终通过（见 [[切片实现合同]] 与 [[YSS路由与合同编译]]）。
-
-`gate.release-ready` 位于 `stage.verification-release-retrospective`，触发于合并、发布或阶段完成，证据为 `evidence.fresh-verification` 与 `evidence.checkpoint-and-rollback`（见 [[条件强制门禁]]）。Git checkpoint 只包含本轮明确范围，须列出验证命令、Ticket 状态和下一步；获得用户授权后才提交或推送（见 [[Ticket与流程状态]]）。
-
-## 来源
-
-- `AGENTS.md`
-- `CONTEXT.md`
-- `docs/process/harness-process-tailoring.md`
-- `docs/process/maintenance-intensity.yaml`
-- `docs/process/lifecycle-registry.yaml`

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

@@ -1,30 +0,0 @@
-# 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,21 +0,0 @@
-# Matt技能体系
-
-Matt Engineering Skills 是来自 `mattpocock/skills` 的轻量工程流程技能集合，用于澄清、Spec、Ticket、实现、TDD、诊断、审查和架构治理，不替代 [[YSS工程技能体系]]。
-
-当前锁定 revision 以 `skills-lock.json` 的 `sources` 为准：`mattpocock/skills` 的 `revision` 为 `0ab1b63a410a03d3627979a109c8695de27af954`。不要抄 README 里可能过期的 hash。上游技能基线不等于项目当前生效内容；YSS 适配必须同时保留上游内容哈希、有效内容哈希和适配依据（见 [[技能投影与锁定]]）。
-
-`grill-with-docs` 与 `to-spec` 只是用户显式兼容入口；新功能或较大变更的默认路径是 `yss-product-lifecycle` 的原生 Discovery / 需求分析工作单元，[[Spec基线]] 与产品设计影响的完整判定以生命周期注册表和裁剪规则为准（见 [[产品研发生命周期]]）。用户显式 `to-tickets` 同样只是兼容入口；正式化由生命周期原生 Ticket 工作单元完成，禁止只按 Adapter / Application / Domain / Infrastructure 横向拆分（见 [[垂直切片Ticket]]）。
-
-[[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,20 +0,0 @@
-# OpenAPI契约
-
-API 契约变更先形成 OpenAPI 3.1 Draft，经必要的工程基线、系统 / 数据架构和设计审查后 Freeze，再进入实现。Draft 是 review-only：Freeze 前不得作为前后端稳定实现契约，也不得用来生成客户端或固化契约测试。
-
-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 评审。
-
-`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`，见 [[条件强制门禁]]。
-
-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,19 +0,0 @@
-# SpecDelta
-
-Spec Delta 只记录相对既有冻结 [[Spec基线]] 的 `ADDED / MODIFIED / REMOVED` 高风险行为差异，以及对应的验收场景和测试映射。它不是第二份完整 Spec，也不替代 OpenAPI 或架构资产。
-
-触发面很窄。全新产品、全新模块和低风险调整不生成 Spec Delta。生命周期产物 `artifact.spec-delta` 的触发条件是「已有冻结 Spec 的高风险行为变化」，归属 `stage.spec-architecture`。未命中时按 [[条件强制门禁]] 与 [[影响面分诊与流程裁剪]] 记录 `not-applicable` 及原因，不写空 Delta。明确改变认证或授权行为时，把差异当作普通行为写入本 Delta，不另开专项 Delta。
-
-模板 `docs/templates/spec-delta-template.md` 用三列差异表达行为，不引入 OpenSpec CLI 或额外状态机。`ADDED` 是新增用户可见行为、API 行为、状态、权限或数据约束；`MODIFIED` 是已有行为的输入、输出、状态流、权限、错误结构、兼容性或验收标准变化；`REMOVED` 是删除或废弃已有行为、字段、入口、权限、状态或兼容路径。变更摘要还要挂相关 OpenAPI Draft / Freeze、架构 / 设计审查和 Ticket / 切片。
-
-受影响范围按维度勾选：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,22 +0,0 @@
-# Spec基线
-
-Spec 是记录用户问题、解决方案、用户故事、关键决策、验收标准和测试 seam 的产品研发规格。新资产统一使用 Spec；过时称谓只出现在迁移指南或明确标注的旧项目上下文。它是 [[产品研发生命周期]] 进入实现前的核心需求资产，不是可以直接编码的 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`。
-
-模板 `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`。
-
-验收标准写可观察结果，不写实现步骤。测试决策要标明主要测试 seam、代码库中的相似测试，以及单元 / 领域行为、API / 契约、前端组件、E2E 关键路径是否必需。DDD 影响判断只做轻量检查：统一语言变化回写 `CONTEXT.md` 的中文术语和 PascalCase `英文标识`；限界上下文变化在产品总体设计中补 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,21 +0,0 @@
-# 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]]。
-
-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`，不得自动改投另一远程平台（见 [[实现仓库与跨仓库契约]]）。
-
-五态见 `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,23 +0,0 @@
-# YSS工程技能体系
-
-YSS skills 是本项目内置的工程规范技能，用于 DDD、UI、OpenAPI、Repository、Controller、DTO、组件和编码规范；它们不替代 [[Matt技能体系]] 的通用流程入口。
-
-技能清单、来源、版本、哈希和投影目标以 `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` 只是单向发布投影，不是新的权威来源。
-
-词汇上的分层是：核心技能默认可发现，负责生命周期控制或通用研发入口；专项技能由 Router 按影响面和实现合同按需选择；试验技能只在明确试验范围内使用，不进入 Router 默认技能闭包。`docs/agents/yss-skill-registry.yaml` 记录分层、别名、默认可发现性和运行时入口，但当前 `status: shadow`，Router 与生命周期不得按其裁剪发现面。
-
-进入实现后，后端领域、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,20 +0,0 @@
-# YSS路由与合同编译
-
-`yss-router` 是阶段 7 的实现合同编译器：它把已批准的生命周期资产和 [[垂直切片Ticket]] 编译为 Slice Implementation Contract 草案，不批准合同、不写业务代码、不设置 `ready-for-agent`。
-
-进入实现时先读 `docs/process/implementation-repo-integration.md`，完成 [[实现仓库与跨仓库契约]] 登记，再编译最小 skill 集合与当前实现合同。输入包括 Spec、切片 Ticket、需求冻结、适用的原型确认、OpenAPI Freeze / no-impact、系统 / 数据架构、Design Review、Build Architecture Checklist、实现仓库和验证命令；输入缺失、未批准或 `stale` 时输出 `blocked`，交回 `yss-product-lifecycle`（见 [[产品研发生命周期]]）。
-
-编译循环判断 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`，交生命周期编排器核验和持久化。
-
-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

@@ -1,9 +0,0 @@
-# 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,41 +0,0 @@
-# YSS Spec Project Template 知识索引
-
-本 wiki 收录模板源仓库的核心知识：仓库身份、研发生命周期、契约资产、技能体系与质量治理。事实以仓库 live 权威源为准；`raw/` 是不可变拷贝或派生摘录。
-
-## 入口与身份
-
-- [[模板总览]] — 模板定位、结构与 Quickstart
-- [[仓库身份与路由]] — `template-source` 与 `project-instance`
-- [[Agent入口规则]] — Agent 入口、硬门禁与禁止事项
-
-## 生命周期与流程
-
-- [[产品研发生命周期]] — 主阶段、产物与工作单元
-- [[条件强制门禁]] — 按影响面强制的生命周期门禁
-- [[影响面分诊与流程裁剪]] — 影响面分诊与流程裁剪
-- [[模板维护流程]] — 模板源维护与 L1 / L2 / L3
-
-## 契约资产
-
-- [[Spec基线]] — Spec 基线：产品研发规格
-- [[SpecDelta]] — Spec Delta：相对冻结基线的高风险差异
-- [[OpenAPI契约]] — OpenAPI Draft 与 Freeze
-- [[产品设计影响与原型]] — 产品设计影响与原型
-- [[垂直切片Ticket]] — 垂直切片 Ticket
-- [[切片实现合同]] — Slice Implementation Contract
-
-## 技能与实现
-
-- [[YSS路由与合同编译]] — YSS 路由与实现合同编译
-- [[YSS工程技能体系]] — YSS 工程技能体系
-- [[Matt技能体系]] — Matt Engineering Skills
-- [[技能投影与锁定]] — 技能投影与 `skills-lock.json`
-- [[实现仓库与跨仓库契约]] — 实现仓库与跨仓库契约
-- [[LLM Wiki]] — 本地持久知识库的 init / refresh / rebuild / ingest
-
-## 质量与治理
-
-- [[Ticket与流程状态]] — Ticket 与五态流程状态
-- [[Fresh验证与独立审查]] — Fresh Verification 与独立审查
-- [[模板发布门禁与验证]] — `scripts/verify-template`
-- [[复盘与权威资产修订]] — 复盘与权威资产修订

package/template/wiki/wiki/log.md

@@ -1,51 +0,0 @@
-# 操作日志
-
-## [2026-08-09] CREATE | 初始化 yss-spec-project-template 知识 wiki 骨架
-
-创建三层结构：`raw/`（不可变源）、文章目录、`index.md`、`log.md`、`CLAUDE.md`。
-
-## [2026-08-09] CREATE | 收录模板权威资产至 raw/
-
-复制 9 份权威源文档：AGENTS.md、CONTEXT.md、README.md、yss-project.yaml、skills-lock.json、ADR-0002、create-yss-spec 契约、Spec 模板、垂直切片 Ticket 模板。
-
-## [2026-08-09] CREATE | 编写知识文章
-
-为入口身份、生命周期、契约资产、技能实现、质量治理五大类编写 22 篇文章，全部使用 `[[wikilink]]` 建立主题关联。
-
-## [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`。
-
-## [2026-08-24] REFRESH | CONTEXT 英文标识词干
-- changed: AGENTS.md, CONTEXT.md, spec-template.md, vertical-slice-ticket-template.md, yss-skill-registry.yaml, skills-lock.json
-- articles: Agent入口规则, Spec基线, 垂直切片Ticket, 模板总览, 复盘与权威资产修订
-- unmapped: (none)
-
-同步 raw 中的 `CONTEXT.md` / `AGENTS.md` / Spec 与垂直切片模板。刷新上述文章中与 PascalCase `英文标识` 词干相关的句子。未改其余命中页。`yss-skill-registry.yaml` 与 `skills-lock.json` 为既有 live 漂移，仅对齐 raw / hash（补入 `yss-antd-design`），不改技能投影文章。

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,20 +0,0 @@
-# 产品研发生命周期
-
-`project-instance` 按产品研发生命周期分诊任务。主阶段以 `docs/process/lifecycle-registry.yaml` 为准，注册表当前列出 8 个：入口分诊、Discovery、Spec / 功能架构、产品设计、系统 / 数据架构与工程契约、Ticket 正式化、垂直切片实现、验证 / 发布 / 复盘。
-
-任务开始时先读 `yss-project.yaml` 确认仓库身份（见 [[仓库身份与路由]]），再用 [[影响面分诊与流程裁剪]] 判定变更类型、影响面和最近可信阶段，然后按注册表执行命中的工作单元与 [[条件强制门禁]]。条件门禁全部按影响面强制：命中必须完成；未命中只记录 `not-applicable` 及原因，不生成空文档。产物、工作单元和证据不得统称为门禁。
-
-新功能或较大变更默认进入 `yss-product-lifecycle` 的原生 Discovery / 需求分析工作单元（`work-unit.discovery-opportunity`、`work-unit.discovery-requirements`），再经 Spec 综合形成 [[Spec基线]]。`grill-with-docs` 与 `to-spec` 只是用户显式兼容入口，不是默认路径；Spec 基线与产品设计影响的完整判定以注册表和裁剪规则为准。[[SpecDelta]] 只记录相对既有冻结 Spec 基线的高风险行为差异；全新产品、全新模块和低风险调整不生成。
-
-命中产品设计影响时走 [[产品设计影响与原型]]；未命中记录 `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,19 +0,0 @@
-# 产品设计影响与原型
-
-UI 影响不等于产品设计影响。UI 影响是会改变用户可见页面、导航、交互流程、状态呈现或权限体验的功能影响；纯后端、API、批处理或数据变更不自动构成 UI 影响。产品设计影响更窄：只有 UI 变化触及主流程、导航、权限体验、异常 / 恢复、状态流转或 API 反推时，才需要页面流、状态矩阵和原型校准。
-
-文案、token、颜色、间距和无行为变化的孤立视觉修复属于 UI 影响，但不自动构成产品设计影响。未命中时按 [[影响面分诊与流程裁剪]] 记录 `not-applicable` 及原因，不生成空的设计包。[[Spec基线]] 模板也约定：只有存在 UI 影响时，才强制低保真页面草图、状态矩阵、高保真 HTML 原型和用户确认；否则同样记 `not-applicable`。两条判定要同时看，不能把「有一点可见变化」直接升级成完整产品设计流程。
-
-命中产品设计影响时，生命周期在 `stage.product-design` 产出交互说明和低保真原型；存在状态流转、异常或恢复时再补状态矩阵；需要视觉与交互校准时再做高保真 HTML 原型。`work-unit.prototype-design` 的完成条件是原型评审、高保真验证和用户确认门禁均通过。对应门禁为 `gate.prototype-reviewed`、`gate.prototype-verified`、`gate.user-confirmation`，证据分别是独立评审结论、`antd` CLI 与浏览器验证、用户确认记录，见 [[条件强制门禁]]。
-
-高保真 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,20 +0,0 @@
-# 仓库身份与路由
-
-仓库身份只由根目录 `yss-project.yaml` 声明。该清单是 CLI 与 Agent 共享的稳定契约（ADR-0002），只含 `schema_version` 与 `repository_mode`，不写入项目名称、团队规模或 Tracker。`repository_mode` 仅有两个合法值：`template-source`（模板源仓库）与 `project-instance`（模板实例仓库）。
-
-文件缺失、schema 版本不支持或模式值非法时，必须停止路由并执行迁移检查；不得根据目录、Git 远程或占位符猜测身份。当前仓库 live 值为 `schema_version: 1`、`repository_mode: template-source`，因此默认走 [[模板维护流程]]，不按具体产品生成 Spec、原型、OpenAPI 或垂直切片 Ticket。总览见 [[模板总览]]。
-
-`template-source` 按「影响面 → 单一事实来源 → 投影 / 派生资产 → 分级证据」维护，发布阻断门禁是 `scripts/verify-template`（见 [[模板发布门禁与验证]]）。`project-instance` 先用 `docs/process/harness-process-tailoring.md` 判定变更类型、影响面和最近可信阶段（见 [[影响面分诊与流程裁剪]]），再按 `docs/process/lifecycle-registry.yaml` 执行命中的工作单元和条件门禁，进入 [[产品研发生命周期]]。
-
-外部 `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,21 +0,0 @@
-# 切片实现合同
-
-Slice Implementation Contract 是阶段 7 进入实现前的实现合同：由 `yss-router` 根据冻结资产和 [[垂直切片Ticket]] 编译草案，再由生命周期编排器批准并持久化。正式垂直切片必须消费已批准、已持久化且版本当前的合同。Router 只生成草案，不得输出 `approved`、`ready-for-agent` 或 `completed`。
-
-Router 先读 [[Spec基线]]、切片 Ticket、需求冻结、适用的原型确认、[[OpenAPI契约]] Freeze 或无 API 影响、系统 / 数据架构、Design Review、Build Architecture Checklist、实现仓库和验证命令。输入缺失、未批准或 `stale` 时输出 `blocked`，交回 `yss-product-lifecycle`。编译结果只能是 `draft`、`blocked` 或 `ready-for-lifecycle-review`，见 [[YSS路由与合同编译]] 与 [[Ticket与流程状态]]。
-
-合同含 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 合同时不得写后端业务代码。
-
-`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,23 +0,0 @@
-# 垂直切片Ticket
-
-垂直切片是贯穿所有受影响层、可独立验证的窄功能路径。每个功能先建立功能父 Ticket，用来汇总 Spec、设计、审查、OpenAPI Freeze、阻塞项和阶段证据；父 Ticket 本身不是 Agent 直接实现的切片。契约冻结后，由生命周期原生 `work-unit.ticket-decomposition` 拆出窄切片；用户显式 `to-tickets` 只是兼容入口。禁止只按 Adapter / Application / Domain / Infrastructure 横向拆分。
-
-模板 `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 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/`。
-
-切片拆分以冻结 [[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`。领域或架构决策变化时更新 `CONTEXT.md` / ADR，新增业务术语含 PascalCase `英文标识`，代码与契约字段能追溯到该词干。路径越界、证据缺失、未执行验证时停止实现并重新路由，见 [[条件强制门禁]] 与 [[实现仓库与跨仓库契约]]。整条链路属于 [[产品研发生命周期]] 的 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,20 +0,0 @@
-# 复盘与权威资产修订
-
-发布后或阶段性完成后做复盘判断。`artifact.retrospective` 属于 `stage.verification-release-retrospective`，触发条件是发布后或阶段性完成后满足复盘触发条件。出现架构返工、验证返工、IMPORTANT / CRITICAL review finding 或人工确认延期时，落简体中文复盘并修订权威资产。
-
-复盘与发布工作单元是 `work-unit.release-and-retrospective`：输入已审查候选、发布窗口和回滚点；输出发布 / 回滚证据和复盘记录；完成条件为人工发布裁决、fresh verification 和治理回流均完成（见 [[Fresh验证与独立审查]] 与 [[产品研发生命周期]]）。
-
-复盘输入包括验证证据、审查报告、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`

package/template/wiki/wiki//345/256/236/347/216/260/344/273/223/345/272/223/344/270/216/350/267/250/344/273/223/345/272/223/345/245/221/347/272/246.md

@@ -1,22 +0,0 @@
-# 实现仓库与跨仓库契约
-
-当前仓库默认是研发管理仓库，运行时代码优先位于已登记的独立实现仓库。没有登记记录时，先完成 onboarding，不能用本仓库目录代替实现仓库。每个受影响实现仓库必须登记：仓库地址、分支、代码所有者、CI 入口、测试 / 构建命令、允许写路径、回滚点和 MR / PR。
-
-只有用户明确选择当前仓库承载实现代码时，才使用唯一的 `apps/backend/<project>/` 或 `apps/frontend/<project>/` 项目根。`apps/backend/` 与 `apps/frontend/` 只是项目容器，不能当作可生成的工程项目根；`app/backend/`、`app/frontend/` 及其子路径一律阻断。`allowed_write_paths`、`expected_evidence_files` 和生成器输出位置必须回指具体项目目录。外部实现仓库不要求采用 Harness 的 `apps/` 布局，但仍必须登记该仓库内的实际项目根；跨仓库切片不得用本 Harness 的占位路径冒充真实路径。
-
-每个 Harness 内项目至少登记 `project_type`、`project_name`、`project_root` 和 `repository_scope`。同一 Git monorepo 下的多个项目可以共用一条仓库登记，但必须逐项目列出根路径和独立验证命令；不同 Git 仓库必须分别登记。进入实现时先读 `docs/process/implementation-repo-integration.md`，再使用 [[YSS路由与合同编译]] 编译最小 skill 集合与当前 [[切片实现合同]]。
-
-实现验证命令按工程类型选择：frontend 的依赖、测试、type-check 与构建优先 `pnpm`；backend 的 `validate` / `test` / `package` 优先项目根 `./mvnw`。不要默认 `npm`、`yarn` 或裸 `mvn`。Ticket、合同、CI 和 Review 证据必须写下实际执行的命令。既有仓库缺少 pnpm 或 Maven Wrapper 时，先记录受控例外、替代命令和责任人。本模板源没有产品 frontend / backend 运行时，其 Node 校验仍用 `pnpm --dir .template-source/tooling/node`。入口纪律见 [[Agent入口规则]]。
-
-无可复用工程时，先确认外部目标仓库或输出目录，再使用 `yss-ddd-scaffold-generator` / `yss-frontend-scaffold-generator`；当前仓库缺少 frontend / backend 目录不改变此路由。脚手架只在 `scaffold_status=required` 且受控生成合同已持久化、获得生命周期批准后运行，只产生机械骨架；业务行为回到 Router 并使用 `behavior-tdd`。正式垂直切片见 [[垂直切片Ticket]]。
-
-跨仓库契约变更需要两个或多个独立仓库协同实现、验证和按顺序发布。任一参与仓库未完成契约对齐和集成验证时，不得单独声称整体可发布（见 [[模板发布门禁与验证]]）。当前 `yss-spec-project-template` 与 `create-yss-spec` 的模板接管 / 同步变更属于 Harness-only 加 release-only 影响，不创建前端、后端或运行时代码目录。
-
-Ticket、Spec 和阶段证据按 `docs/agents/issue-tracker.md` 选定的主 tracker 持久化；Git remote 不代表 tracker 选择（见 [[Ticket与流程状态]]）。路径越界、证据缺失、未执行验证、`drift`、`violation` 或 `new_impacts` 时停止实现并重新路由。完成结论必须基于 [[Fresh验证与独立审查]]。仓库身份见 [[仓库身份与路由]]。
-
-## 来源
-
-- `AGENTS.md`
-- `CONTEXT.md`
-- `docs/process/implementation-repo-integration.md`
-- `.agents/skills/yss-router/SKILL.md`

package/template/wiki/wiki//345/275/261/345/223/215/351/235/242/345/210/206/350/257/212/344/270/216/346/265/201/347/250/213/350/243/201/345/211/252.md

@@ -1,20 +0,0 @@
-# 影响面分诊与流程裁剪
-
-`docs/process/harness-process-tailoring.md` 规定如何根据变更规模和风险选择最近可信阶段。裁剪只减少未触发的门禁，不得跳过已经命中的 [[条件强制门禁]]；未命中只记录 `not-applicable` 及原因，不生成空文档。
-
-判定顺序：先读 `yss-project.yaml`，非法、缺失或不支持的身份直接进入迁移检查（见 [[仓库身份与路由]]）；再判断是否为模板源维护、项目实例小改动、中等变更或全新产品 / 模块；再判断 UI、API、数据、后端、前端、跨仓库和高风险影响；最后从最近可信阶段恢复，不因目录里存在某类文件就猜测阶段已通过。
-
-裁剪矩阵的默认入口不同。模板源维护默认入口是影响面分析，必需工作是修改单一事实来源、按强度分级执行证据、必要的技能投影同步和 fresh verification / review，产品 Spec、产品设计、OpenAPI、运行时代码记 `not-applicable`（见 [[模板维护流程]]）。小改动从入口分诊进入，未触发时 Spec、架构、原型、切片可记 `not-applicable`。中等变更从最近可信的 Spec / 架构阶段恢复。全新产品 / 模块从 Discovery 进入。高风险变更从既有冻结基线进入，需要 [[SpecDelta]]、架构 / 数据 / 工程审查、契约复核、切片和回滚设计。
-
-安全 / 权限不单独分诊。需求或冻结资产没有明确改变认证、授权、租户隔离、敏感数据或合规时，不登记、不解释 `not-applicable`、不增加门禁；明确改变时只按实际 UI、API、Backend、Data、High-risk 复用普通 [[产品研发生命周期]]，不另设专属资料。SQL / DDL / 迁移、上传 / 下载继续由其数据或 API 影响决定路线。文案、token、颜色、间距和无行为变化的孤立视觉修复属于 UI 影响，但不自动构成产品设计影响，也不强制 [[产品设计影响与原型]]。
-
-`grill-with-docs`、`to-spec`、`to-tickets` 只是用户显式兼容入口，不是默认路径；新功能或较大变更走生命周期原生 Discovery / 需求分析与 Ticket 正式化。Spec Delta 只记录相对既有冻结 Spec 基线的高风险行为差异；全新产品、全新模块和低风险调整不生成。跨仓库变更必须绑定实现仓库、分支、CI、验证命令、发布顺序和回滚点。`seam-deferred` 必须显式记录风险、责任人、后续 Ticket、验证计划和目标版本或发布日期。
-
-任何裁剪都要写明原因和证据。阶段证据在集中 checkpoint 回写，至少包含范围、变更文件、受影响仓库、验证命令及结果、阻塞项、人工审查点、Ticket 状态和下一步。同一独立执行者可以在一个连续工作单元内完成相邻实现动作，但不能替代独立审查者（见 [[Fresh验证与独立审查]] 与 [[Agent入口规则]]）。
-
-## 来源
-
-- `docs/process/harness-process-tailoring.md`
-- `docs/process/lifecycle-registry.yaml`
-- `AGENTS.md`
-- `CONTEXT.md`

package/template/wiki/wiki//346/212/200/350/203/275/346/212/225/345/275/261/344/270/216/351/224/201/345/256/232.md

@@ -1,23 +0,0 @@
-# 技能投影与锁定
-
-技能投影是从权威共享技能生成、供特定 Agent root 加载的同步副本；锁文件对技能名做 derived 摘录，见 `wiki/raw/skills-lock-names.md`。`.agents/skills` 是跨 Agent 共享技能的唯一权威内容；`.claude/skills`、`.codex/skills`、`.cursor/skills`、`.hermes/skills`、`.pi/skills`、`.qoder/skills`、`.trae/skills` 中的同名共享技能是生成投影，禁止分别手工修改。Cursor 的契约运行时入口是 `.cursor/skills`；不得把 canonical `.agents/skills` 与某个平台投影当作同权双入口。
-
-`skills-lock.json` 是技能清单、来源、版本、哈希和投影目标的权威记录，当前 `version` 为 `3`，`canonicalRoot` 为 `.agents/skills`。字段包括 `upstreamHash`（可追溯时的未适配上游内容哈希）、`effectiveHash`（当前生效的完整 skill 目录树哈希）和 `targets`（应投影到的 Agent roots）。只属于某个平台的 skill 由锁文件 `platform` 分组记录。共享技能名以锁文件为准，派生摘录见 `wiki/raw/skills-lock-names.md`。
-
-新增共享 skill 必须先执行 `scripts/update-skill-lock --add=<name>`，再运行 `scripts/sync-skills` 与 `scripts/update-skill-lock`。新增平台专属 skill 使用 `scripts/update-skill-lock --add-platform=<root>:<skill-name>`。脚本不会把工作区中偶然出现的未跟踪目录自动纳入发布清单。单独检查使用 `scripts/sync-skills --check` 与 `scripts/update-skill-lock --check`。
-
-核心技能默认可发现；专项技能由 [[YSS路由与合同编译]] 按影响面选择；试验技能不进入默认闭包。`docs/agents/yss-skill-registry.yaml` 当前 `status: shadow`，不改变 Agent 实际发现列表，也不允许 Router / 生命周期按其裁剪闭包。`llm-wiki` 已在该表登记为 `layer: core`、`maturity: verified`、`instance_default_discoverable: true`、`impacts: [quality]`，并已写入锁文件 `shared` 分组（`source: project`）；它仍不是 `yss-public-skills.json` 条目。
-
-YSS 技能的公开发布仓库为 `iloveZzz/yss-spec-dev-skills`，是 `.agents/skills` 的单向发布投影。公开清单只放 `yss-*` 工程技能；[[LLM Wiki]] 与 Matt 流程技能不在公开发布面。发布阻断校验是 `scripts/verify-template`（见 [[模板发布门禁与验证]]）。创建、修改或退役 skill 走 [[模板维护流程]] 的 `maintaining-skills` 与 L1 / L2 / L3。
-
-Matt 上游 revision 见 [[Matt技能体系]]；YSS 专项规范见 [[YSS工程技能体系]]。入口纪律见 [[Agent入口规则]]。投影可以是指向权威目录的符号链接，也可以是完整同步副本。
-
-## 来源
-
-- `AGENTS.md`
-- `CONTEXT.md`
-- `skills-lock.json`
-- `docs/agents/skills-maintenance.md`
-- `docs/agents/yss-skill-registry.yaml`
-- `wiki/raw/skills-lock-names.md`
-- `yss-public-skills.json`