create-yss-spec 2.1.15 → 2.2.1

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`

package/template/wiki/wiki//346/235/241/344/273/266/345/274/272/345/210/266/351/227/250/347/246/201.md

@@ -1,18 +0,0 @@
-# 条件强制门禁
-
-生命周期门禁（条件强制门禁）只有影响面命中触发条件时才必须裁决；未触发时记录 `not-applicable` 及原因，不生成空文档，也不默认走全部门禁。门禁不是产物、工作单元或证据的统称；主阶段不会因增加门禁而自动增加。
-
-注册表当前列出 14 个门禁，按 `id` 与 `name` 为：`gate.repository-identity-valid` 仓库身份校验、`gate.spec-baseline-approved` Spec 基线批准、`gate.prototype-reviewed` 原型评审、`gate.prototype-verified` 高保真原型验证、`gate.user-confirmation` 用户确认、`gate.openapi-draft-reviewed` OpenAPI Draft Review、`gate.design-reviewed` 设计审查、`gate.openapi-frozen` OpenAPI Freeze、`gate.engineering-baseline-accepted` 工程基线、`gate.architecture-reviewed` 架构审查、`gate.slice-contract-approved` Slice Implementation Contract 批准、`gate.slice-ready-for-agent` 垂直切片实现就绪、`gate.frontend-implementation-verified` 前端实现还原验证、`gate.release-ready` 发布就绪。`gate.release-ready` 还要求 `requires_gates: [gate.frontend-implementation-verified]`。数量以注册表当前列出为准。
-
-这些门禁分布在 [[产品研发生命周期]] 的入口分诊、Spec / 功能架构、产品设计、系统 / 数据架构与工程契约、Ticket 正式化、验证 / 发布 / 复盘等阶段。[[影响面分诊与流程裁剪]] 只减少未触发的门禁，不得跳过已经命中的条件强制门禁。命中证据写入对应 `evidence.*`，并集中回写功能父 Ticket（见 [[Ticket与流程状态]]）。
-
-安全 / 权限不设独立生命周期资料或专属门禁。日常功能不做额外登记或推导校验；只有需求或冻结资产明确改变认证、授权、租户隔离、敏感数据或合规时，才写入普通 Spec、API、架构、验收和测试 seam，并按实际 UI、API、Backend、Data、High-risk 触发上列既有门禁。SQL / DDL / 迁移、上传 / 下载由其数据或 API 影响决定路线，不自动升级为安全专项。`seam-deferred` 必须显式记录风险、责任人、后续 Ticket、验证计划和目标版本或发布日期。
-
-只有通过必要门禁、阻塞边已清除并具备直接实现条件的 [[垂直切片Ticket]] 才能使用 `ready-for-agent`。Spec 初稿、产品设计、原型、[[OpenAPI契约]] Draft 和待冻结资产使用 `ready-for-human`。进入实现前还须由生命周期编排器批准 [[切片实现合同]]；实现者不能承担命中的独立审查，完成结论必须基于 [[Fresh验证与独立审查]]。
-
-## 来源
-
-- `docs/process/lifecycle-registry.yaml`
-- `docs/process/harness-process-tailoring.md`
-- `AGENTS.md`
-- `CONTEXT.md`

package/template/wiki/wiki//346/250/241/346/235/277/345/217/221/345/270/203/351/227/250/347/246/201/344/270/216/351/252/214/350/257/201.md

@@ -1,22 +0,0 @@
-# 模板发布门禁与验证
-
-`scripts/verify-template` 是模板源发布阻断门禁。按 `CONTEXT.md`，模板发布门禁是结构、技能同步、流程语义和压力场景验证的集合，不是只检查文件存在、Markdown 链接或 YAML 语法。通过时输出 `模板发布校验通过`。
-
-Quickstart 要求：`template-source` 修改流程、技能或模板后，执行 `scripts/sync-skills`、`scripts/update-skill-lock` 和 `scripts/verify-template`（见 [[模板维护流程]]、[[技能投影与锁定]] 与 [[模板总览]]）。创建、修改或退役 skill 时使用 `maintaining-skills`，并先按 `docs/process/harness-process-tailoring.md` 判定 L1 / L2 / L3；只有 L3 必须保留完整基线失败、压力场景、修订后验证和正式独立审查证据。发布候选固定按 L3 聚合验证，但不追溯补造每个既有 L1 / L2 修改的独立 RED。
-
-身份为 `template-source` 时，脚本先跑 `.template-source/scripts/evidence-index --check`、`pnpm --dir .template-source/tooling/node test` 与 `check:vendor`，再执行投影 / 锁文件 `--check`、生命周期注册表校验和全部 `scripts/verify-*` 场景脚本。技能清单、来源、版本、哈希和投影目标以 `skills-lock.json` 为准；当前 `mattpocock/skills` 的 `revision` 为 `0ab1b63a410a03d3627979a109c8695de27af954`，不以 README 中可能过期的 hash 覆盖锁文件。
-
-模板与外部 `create-yss-spec` 的跨仓库契约未完成集成验证时，不得声称可发布（见 [[实现仓库与跨仓库契约]] 与 [[仓库身份与路由]]）。公开发布投影前的顺序为：同步 canonical projections → 更新 lock → `scripts/verify-template` → 导出并检查 → 独立审查 → 在 `yss-spec-dev-skills` 提交人工 PR。
-
-任何「完成 / 可合并 / 可发布」结论必须基于 fresh verification（见 [[Fresh验证与独立审查]]），不接受「之前跑过」或实现者自述。`gate.release-ready` 的证据是 `evidence.fresh-verification` 与 `evidence.checkpoint-and-rollback`。Git checkpoint 只包含本轮明确范围；获得用户授权后才提交或推送（见 [[Agent入口规则]]）。
-
-## 来源
-
-- `scripts/verify-template`
-- `README.md`
-- `AGENTS.md`
-- `CONTEXT.md`
-- `docs/agents/skills-maintenance.md`
-- `docs/process/harness-process-tailoring.md`
-- `docs/process/lifecycle-registry.yaml`
-- `skills-lock.json`

package/template/wiki/wiki//346/250/241/346/235/277/346/200/273/350/247/210.md

@@ -1,20 +0,0 @@
-# 模板总览
-
-YSS Spec Project Template 是 Matt Pocock Engineering Skills × YSS × OpenAPI 驱动的轻量 AI 研发文档模板。当前仓库是 Harness / 研发管理仓库，默认承载流程文档、契约模板、Agent skills 与协作约定；运行时代码优先位于已登记的独立实现仓库。
-
-只有用户明确选择让本仓库承载实现代码时，才使用唯一的 `apps/backend/<project>/` 或 `apps/frontend/<project>/` 项目根。`apps/backend/` 与 `apps/frontend/` 只是项目容器；`app/backend/`、`app/frontend/` 及其子路径禁止作为工程输出。跨仓登记与切片绑定见 [[实现仓库与跨仓库契约]]。
-
-任务开始必须先读根目录 `yss-project.yaml`。当前仓库 `repository_mode` 为 `template-source`，走 [[模板维护流程]]，不默认生成具体产品的 Spec、原型、OpenAPI 或垂直切片 Ticket。`create-yss-spec` 创建或接管的产品仓库写入 `project-instance`，再进入 [[产品研发生命周期]]；CLI 只管理研发管理资产，不接管前后端运行时代码。身份判定细则见 [[仓库身份与路由]]。
-
-单一事实来源不得在 README 或用户指南里另写一套：领域与流程词汇以 `CONTEXT.md` 为准（中文术语加 PascalCase `英文标识` 词干，见 [[Agent入口规则]]）；Agent 入口、硬门禁与禁止事项以 `AGENTS.md` 为准（见 [[Agent入口规则]]）；主阶段、门禁、产物、工作单元、证据和稳定 ID 以 `docs/process/lifecycle-registry.yaml` 为准；技能清单、来源、版本、哈希和投影目标以 `skills-lock.json` 为准（见 [[技能投影与锁定]]）。
-
-`.agents/skills` 是跨 Agent 共享技能的权威内容；各平台 root 中的共享技能是生成投影。模板发布阻断门禁是 `scripts/verify-template`，且与外部 `create-yss-spec` 的跨仓库契约未完成集成验证时不得声称可发布（见 [[模板发布门禁与验证]]）。本地知识库的 init / refresh / rebuild，或要把研究结果落成持久 wiki，走 [[LLM Wiki]]（落成持久 wiki 用 `ingest`；已映射 live 源变了用 `refresh`）；一次性一手资料笔记仍走 `research`。
-
-## 来源
-
-- `README.md`
-- `yss-project.yaml`
-- `AGENTS.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//346/250/241/346/235/277/347/273/264/346/212/244/346/265/201/347/250/213.md

@@ -1,19 +0,0 @@
-# 模板维护流程
-
-`repository_mode: template-source` 使用模板维护流程，不默认生成具体产品的 Spec、原型、OpenAPI 或垂直切片 Ticket（见 [[仓库身份与路由]]）。默认入口是影响面分析，产品 Spec、产品设计、OpenAPI、运行时代码记 `not-applicable`。
-
-标准路线是「影响面 → 单一事实来源 → 投影 / 派生资产 → 分级证据」。先按 [[影响面分诊与流程裁剪]] 判定影响，再改对应权威资产（`AGENTS.md`、`CONTEXT.md`、`docs/process/lifecycle-registry.yaml`、`docs/process/harness-process-tailoring.md`、`docs/process/maintenance-intensity.yaml`、`skills-lock.json` 等），再同步技能投影和派生产物，最后按强度做 verification 与 review。创建、修改或退役 skill 时使用 `maintaining-skills`；`.agents/skills` 是跨 Agent 共享技能的权威内容，各平台目录中的共享技能是生成投影，禁止分别手工修改（见 [[技能投影与锁定]]）。
-
-强度只由 `docs/process/maintenance-intensity.yaml` 计算，不由文件所在目录单独决定。未给出 trigger 时 `default_level=L2`；未知 trigger 必须先更新该策略后才可验证。L1 触发项为 `textual-only`、`link-only`、`deterministic-projection`；L2 为 `local-rule`、`template-structure`、`non-core-validator`；L3 为 `lifecycle-gate`、`ticket-state`、`permission-boundary`、`generation-semantics`、`release-semantics`、`cross-repo-contract`、`core-validator`、`historical-important-escape`、`aggregate-behavior-change`、`release-candidate`。
-
-L1 最低证据是至少一项与变更直接相关的实际检查，Review 为 `self-check` 或显式 `human-checkpoint`。L2 最低证据是修改前可失败的最小反例，以及本轮 fresh verification；Review 由一名非实施者执行 `focused-independent`。只有 L3 才要求完整 RED、GREEN、REFACTOR、压力场景与本轮 fresh verification，并在冻结候选后执行 `formal-independent`。发布、合并或阶段完成按整体候选重新判定，不得把共同改变整体语义的修改拆成多个 L1/L2 规避 L3。模板发布候选固定按 L3 聚合验证（见 [[模板发布门禁与验证]]）。
-
-L1/L2 的强度 checkpoint 可直接写入主 Ticket 或集中 checkpoint，不要求新增独立文档；用 `scripts/verify-maintenance-checkpoint` 做只读校验。`scripts/verify-template` 是模板发布阻断门禁。模板与外部 `create-yss-spec` 的跨仓库契约未完成集成验证时，不得声称可发布（见 [[实现仓库与跨仓库契约]]）。完成结论必须基于 [[Fresh验证与独立审查]]，不接受「之前跑过」。出现架构返工、验证返工、IMPORTANT / CRITICAL review finding 或人工确认延期时，按 [[复盘与权威资产修订]] 回流。
-
-## 来源
-
-- `docs/process/maintenance-intensity.yaml`
-- `docs/process/harness-process-tailoring.md`
-- `AGENTS.md`
-- `CONTEXT.md`
-- `docs/process/lifecycle-registry.yaml`