create-yss-spec 2.1.11 → 2.1.13

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,9 +1,22 @@
 # 实现仓库与跨仓库契约
 
-当前仓库默认是研发管理仓库（Harness），前端、后端和其他运行时代码优先位于独立实现仓库；只有用户明确选择当前仓库承载实现代码时，才按需创建 `apps/backend/` 与 `apps/frontend/`，不得自行新建其他顶层业务代码目录。
+当前仓库默认是研发管理仓库，运行时代码优先位于已登记的独立实现仓库。没有登记记录时，先完成 onboarding，不能用本仓库目录代替实现仓库。每个受影响实现仓库必须登记：仓库地址、分支、代码所有者、CI 入口、测试 / 构建命令、允许写路径、回滚点和 MR / PR。
 
-进入实现前必须：确认受影响的 frontend / backend 工程是 `existing`、`required` 还是 `initialized`，并登记实现仓库、分支、CI、验证命令和回滚点；无可复用工程时，先确认外部目标仓库或输出目录，再分别使用 `yss-ddd-scaffold-generator` / `yss-frontend-scaffold-generator`，不因当前仓库缺少 frontend / backend 目录而绕过脚手架路由。实现仓库接入规则见 `docs/process/implementation-repo-integration.md`（见 [[YSS路由与合同编译]]）。
+只有用户明确选择当前仓库承载实现代码时，才使用唯一的 `apps/backend/<project>/` 或 `apps/frontend/<project>/` 项目根。`apps/backend/` 与 `apps/frontend/` 只是项目容器，不能当作可生成的工程项目根；`app/backend/`、`app/frontend/` 及其子路径一律阻断。`allowed_write_paths`、`expected_evidence_files` 和生成器输出位置必须回指具体项目目录。外部实现仓库不要求采用 Harness 的 `apps/` 布局，但仍必须登记该仓库内的实际项目根；跨仓库切片不得用本 Harness 的占位路径冒充真实路径。
 
-跨仓库契约变更需要两个或多个独立仓库协同实现、验证和按顺序发布。任一参与仓库未完成契约对齐和集成验证时，不得单独声称整体可发布。模板与外部 `create-yss-spec` CLI 的跨仓库契约（身份转换、升级迁移、集成测试、发布顺序）见 raw 源 `create-yss-spec-contract.md`，建议技能为 `cross-repo-implementation-routing`（见 [[模板维护流程]]）。
+每个 Harness 内项目至少登记 `project_type`、`project_name`、`project_root` 和 `repository_scope`。同一 Git monorepo 下的多个项目可以共用一条仓库登记，但必须逐项目列出根路径和独立验证命令；不同 Git 仓库必须分别登记。进入实现时先读 `docs/process/implementation-repo-integration.md`，再使用 [[YSS路由与合同编译]] 编译最小 skill 集合与当前 [[切片实现合同]]。
 
-Ticket、Spec 和阶段证据按用户选择或当前主远程路由到 GitHub / GitLab；平台不可用时生成本地待发布草案，不自动改投其他平台（见 [[Ticket与流程状态]]）。
+实现验证命令按工程类型选择：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,9 +1,20 @@
 # 影响面分诊与流程裁剪
 
-Harness 流程裁剪指南定义了影响面触发与 `not-applicable` 的判定规则：不是所有变更都走完整生命周期，而是根据影响面裁剪流程深度。
+`docs/process/harness-process-tailoring.md` 规定如何根据变更规模和风险选择最近可信阶段。裁剪只减少未触发的门禁，不得跳过已经命中的 [[条件强制门禁]]；未命中只记录 `not-applicable` 及原因，不生成空文档。
 
-分诊维度包括：小改动（如孤立文案、token、颜色、间距等无行为变化的视觉修复）、中等变更（单个契约或模块内调整）与新模块 / 高风险变更（跨层、跨仓库或破坏性契约变化）。任务开始时先做影响面分析，定位最近可信阶段，再决定执行哪些活动与门禁（见 [[条件强制门禁]]）。
+判定顺序：先读 `yss-project.yaml`，非法、缺失或不支持的身份直接进入迁移检查（见 [[仓库身份与路由]]）；再判断是否为模板源维护、项目实例小改动、中等变更或全新产品 / 模块；再判断 UI、API、数据、后端、前端、跨仓库和高风险影响；最后从最近可信阶段恢复，不因目录里存在某类文件就猜测阶段已通过。
 
-典型裁剪规则：只有 UI 变化触及主流程、导航、权限体验、异常 / 恢复状态、状态流转或 API 反推时，才构成产品设计影响并强制 [[产品设计影响与原型]] 流程；文案、token、颜色和孤立视觉修复记录 `not-applicable`。全新产品、全新模块和低风险调整不生成 Spec Delta（见 [[SpecDelta]]）。未定义关键流程清单时，不得声称 E2E 覆盖率达到 100%（见 [[Fresh验证与独立审查]]）。
+裁剪矩阵的默认入口不同。模板源维护默认入口是影响面分析，必需工作是修改单一事实来源、按强度分级执行证据、必要的技能投影同步和 fresh verification / review，产品 Spec、产品设计、OpenAPI、运行时代码记 `not-applicable`（见 [[模板维护流程]]）。小改动从入口分诊进入，未触发时 Spec、架构、原型、切片可记 `not-applicable`。中等变更从最近可信的 Spec / 架构阶段恢复。全新产品 / 模块从 Discovery 进入。高风险变更从既有冻结基线进入，需要 [[SpecDelta]]、架构 / 数据 / 工程审查、契约复核、切片和回滚设计。
 
-裁剪不是省略质量：被裁剪的环节仍需记录 `not-applicable` 及原因，保证追踪证据完整。
+安全 / 权限不单独分诊。需求或冻结资产没有明确改变认证、授权、租户隔离、敏感数据或合规时，不登记、不解释 `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,9 +1,23 @@
 # 技能投影与锁定
 
-技能投影是从权威共享技能生成、供特定 Agent root 加载的同步副本。`.agents/skills` 是跨 Agent 共享技能的权威内容；`.claude/skills`、`.codex/skills`、`.hermes/skills`、`.pi/skills`、`.qoder/skills`、`.trae/skills` 中的共享技能是生成投影，禁止分别手工修改。
+技能投影是从权威共享技能生成、供特定 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`（机器可读锁文件）与 `yss-public-skills.json` 中。模板维护流程要求：修改技能或流程规则后，运行 `scripts/sync-skills` 同步投影、`scripts/update-skill-lock` 更新锁文件，再执行 `scripts/verify-template` 压力验证（见 [[模板维护流程]] 与 [[模板发布门禁与验证]]）。
+`skills-lock.json` 是技能清单、来源、版本、哈希和投影目标的权威记录，当前 `version` 为 `3`，`canonicalRoot` 为 `.agents/skills`。字段包括 `upstreamHash`（可追溯时的未适配上游内容哈希）、`effectiveHash`（当前生效的完整 skill 目录树哈希）和 `targets`（应投影到的 Agent roots）。只属于某个平台的 skill 由锁文件 `platform` 分组记录。共享技能名以锁文件为准，派生摘录见 `wiki/raw/skills-lock-names.md`。
 
-`scripts/export-yss-skills` 负责导出 YSS 技能集，`scripts/verify-yss-ui-scenarios`、`scripts/verify-lifecycle-scenarios`、`scripts/verify-yss-router-scenarios`、`scripts/verify-matt-yss-integration-scenarios` 等分别验证技能投影与流程语义在压力场景下的正确性。投影与锁文件的哈希一致性是模板发布门禁的组成部分。
+新增共享 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`。
 
-技能治理规则：新流程统一使用 Spec、Ticket、`to-spec`、`to-tickets`；过时术语与旧技能名只能出现在迁移指南或明确标注的旧项目上下文中。
+核心技能默认可发现；专项技能由 [[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,9 +1,18 @@
 # 条件强制门禁
 
-模板定义 21 个生命周期门禁，全部是条件强制门禁：只有影响面命中触发条件时才必须完成；未触发时记录 `not-applicable` 及原因，不生成空文档，也不默认所有任务执行全部门禁。
+生命周期门禁（条件强制门禁）只有影响面命中触发条件时才必须裁决；未触发时记录 `not-applicable` 及原因，不生成空文档，也不默认走全部门禁。门禁不是产物、工作单元或证据的统称；主阶段不会因增加门禁而自动增加。
 
-门禁覆盖研发生命周期的关键审查点，包括：需求澄清与 Spec 校准、产品设计审查、原型评审、OpenAPI Draft 评审与 Freeze、工程基线建立、系统 / 数据架构审查、契约冻结、垂直切片就绪检查、独立代码审查、fresh verification 与发布门禁等。每个门禁的触发条件、产物与退出标准由生命周期资产映射统一定义（见 [[产品研发生命周期]]）。
+注册表当前列出 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]`。数量以注册表当前列出为准。
 
-条件强制门禁与 [[影响面分诊与流程裁剪]] 的裁剪指南配合：影响面分诊决定哪些门禁被触发，未命中的门禁以 `not-applicable` 记录。门禁证据（审查结论、验证结果、阻塞项）集中记录在功能父 Ticket 中（见 [[Ticket与流程状态]]）。
+这些门禁分布在 [[产品研发生命周期]] 的入口分诊、Spec / 功能架构、产品设计、系统 / 数据架构与工程契约、Ticket 正式化、验证 / 发布 / 复盘等阶段。[[影响面分诊与流程裁剪]] 只减少未触发的门禁，不得跳过已经命中的条件强制门禁。命中证据写入对应 `evidence.*`，并集中回写功能父 Ticket（见 [[Ticket与流程状态]]）。
 
-只有通过必要门禁、阻塞边已清除并具备直接实现条件的垂直切片 Ticket 才能标记 `ready-for-agent`；Spec 初稿、设计、原型、OpenAPI Draft 和待冻结资产一律使用 `ready-for-human`（见 [[垂直切片Ticket]] 与 [[OpenAPI契约]]）。
+安全 / 权限不设独立生命周期资料或专属门禁。日常功能不做额外登记或推导校验；只有需求或冻结资产明确改变认证、授权、租户隔离、敏感数据或合规时，才写入普通 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,9 +1,22 @@
 # 模板发布门禁与验证
 
-`scripts/verify-template` 是模板发布阻断门禁，模板源发布前必须通过结构、技能同步、流程语义和压力场景验证集合；不等同于只检查文件存在、Markdown 链接或 YAML 语法。
+`scripts/verify-template` 是模板源发布阻断门禁。按 `CONTEXT.md`，模板发布门禁是结构、技能同步、流程语义和压力场景验证的集合，不是只检查文件存在、Markdown 链接或 YAML 语法。通过时输出 `模板发布校验通过`。
 
-`verify-template` 验证五类压力场景（生命周期、YSS Router、YSS UI、Matt × YSS 集成等），由 `scripts/verify-lifecycle-scenarios`、`scripts/verify-yss-router-scenarios`、`scripts/verify-yss-ui-scenarios`、`scripts/verify-matt-yss-integration-scenarios` 等脚本支撑。模板与外部 `create-yss-spec` 的跨仓库契约未完成集成验证时，不得声称可发布（见 [[模板维护流程]] 与 [[实现仓库与跨仓库契约]]）。
+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。
 
-模板维护硬门禁还包括：创建、修改或退役 skill 时使用 `maintaining-skills`，并按 L1 / L2 / L3 执行对应验证与审查；共享技能投影禁止分别手工修改（见 [[技能投影与锁定]]）。
+身份为 `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 覆盖锁文件。
 
-任何"完成 / 可合并 / 可发布"结论必须基于 fresh verification（见 [[Fresh验证与独立审查]]），不接受"之前跑过"或实现者自述。模板发布前还需同步技能投影与派生文档、更新 `skills-lock.json`，并完成独立审查和 Git checkpoint。
+模板与外部 `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,9 +1,20 @@
-# YSS Spec Project Template 总览
+# 模板总览
 
-YSS Spec Project Template 是一个基于 Matt Pocock Engineering Skills、YSS 与 OpenAPI 驱动的轻量 AI 研发文档模板。它默认作为 Harness / 研发管理仓库，承载流程文档、契约模板、Agent skills 与协作约定；前端与后端源码默认位于独立实现仓库（见 [[实现仓库与跨仓库契约]]），仅在用户明确选择时才在本仓库按需创建 `apps/` 目录。
+YSS Spec Project Template 是 Matt Pocock Engineering Skills × YSS × OpenAPI 驱动的轻量 AI 研发文档模板。当前仓库是 Harness / 研发管理仓库，默认承载流程文档、契约模板、Agent skills 与协作约定；运行时代码优先位于已登记的独立实现仓库。
 
-模板的核心目录包括：`.agents/skills`（跨 Agent 共享技能权威内容）、`docs/`（按生命周期划分的文档资产，含 adr、api、requirements、design、architecture、agents、templates、process 等子目录）、`scripts/`（模板轻量校验脚本）以及根级权威资产 `AGENTS.md`、`CONTEXT.md` 与 `yss-project.yaml`。
+只有用户明确选择让本仓库承载实现代码时，才使用唯一的 `apps/backend/<project>/` 或 `apps/frontend/<project>/` 项目根。`apps/backend/` 与 `apps/frontend/` 只是项目容器；`app/backend/`、`app/frontend/` 及其子路径禁止作为工程输出。跨仓登记与切片绑定见 [[实现仓库与跨仓库契约]]。
 
-Quickstart 要求：先读取 `yss-project.yaml` 按 `repository_mode` 选择流程（见 [[仓库身份与路由]]）；必读入口为 `AGENTS.md` 与 `CONTEXT.md`；`template-source` 模式走 [[模板维护流程]] 流程，`project-instance` 模式进入 [[产品研发生命周期]] 产品研发生命周期。
+任务开始必须先读根目录 `yss-project.yaml`。当前仓库 `repository_mode` 为 `template-source`，走 [[模板维护流程]]，不默认生成具体产品的 Spec、原型、OpenAPI 或垂直切片 Ticket。`create-yss-spec` 创建或接管的产品仓库写入 `project-instance`，再进入 [[产品研发生命周期]]；CLI 只管理研发管理资产，不接管前后端运行时代码。身份判定细则见 [[仓库身份与路由]]。
 
-本模板强调单一事实来源：领域词汇以 `CONTEXT.md` 为准，流程事实以生命周期映射与裁剪指南为准，技能清单以 `skills-lock.json` 为准（见 [[技能投影与锁定]]）。
+单一事实来源不得在 README 或用户指南里另写一套：领域与流程词汇以 `CONTEXT.md` 为准；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,9 +1,19 @@
 # 模板维护流程
 
-`template-source` 模式（见 [[仓库身份与路由]]）使用模板维护流程管理模板自身的演进，不默认生成具体产品的 Spec、原型、OpenAPI 或垂直切片 Ticket。
+`repository_mode: template-source` 使用模板维护流程，不默认生成具体产品的 Spec、原型、OpenAPI 或垂直切片 Ticket（见 [[仓库身份与路由]]）。默认入口是影响面分析，产品 Spec、产品设计、OpenAPI、运行时代码记 `not-applicable`。
 
-标准流程为：影响面分析 → 修改对应单一事实来源 → 同步技能投影和派生文档 → 执行压力场景与 `scripts/verify-template` → 独立审查和 Git checkpoint。影响面分析决定修改哪些权威资产：`AGENTS.md`、`CONTEXT.md`、生命周期映射、裁剪指南或 `skills-lock.json`。
+标准路线是「影响面 → 单一事实来源 → 投影 / 派生资产 → 分级证据」。先按 [[影响面分诊与流程裁剪]] 判定影响，再改对应权威资产（`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 共享技能的权威内容，各平台目录中的共享技能是生成投影，禁止分别手工修改（见 [[技能投影与锁定]]）。
 
-硬门禁包括：创建、修改或退役 skill 时使用 `maintaining-skills`，并按 L1 / L2 / L3 执行对应验证与审查；`.agents/skills` 是跨 Agent 共享技能的权威内容，各平台目录中的共享技能是生成投影，禁止分别手工修改（见 [[技能投影与锁定]]）；`scripts/verify-template` 是模板发布阻断门禁（见 [[模板发布门禁与验证]]）。
+强度只由 `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`。
 
-模板与外部 `create-yss-spec` 的跨仓库契约未完成集成验证时，不得声称可发布；发布顺序与责任边界以 raw 源 `create-yss-spec-contract.md` 为准（见 [[实现仓库与跨仓库契约]]）。模板改动后需运行 `scripts/sync-skills`、`scripts/update-skill-lock` 与 `scripts/verify-template`。
+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`

package/template/yss-public-skills.json

@@ -3,6 +3,7 @@
   "repository": "iloveZzz/yss-spec-dev-skills",
   "canonical_root": ".agents/skills",
   "skills": [
+    "yss-antd-design",
     "yss-api-integration",
     "yss-audit-log",
     "yss-application",
@@ -67,6 +68,7 @@
       "title": "前端",
       "description": "用于 YSS Vue、Formily、页面模块和 UI 实现的技能。",
       "skills": [
+        "yss-antd-design",
         "yss-components",
         "yss-design-system",
         "yss-formily",

package/template.snapshot.json

@@ -3,14 +3,14 @@
   "templateName": "yss-spec-project-template",
   "templateSource": "github:iloveZzz/yss-spec-project-template",
   "templateRepository": "https://github.com/iloveZzz/yss-spec-project-template.git",
-  "requestedRef": "47eaf46d096f9ed03c5e93cbc030e25770dda685",
-  "templateCommit": "47eaf46d096f9ed03c5e93cbc030e25770dda685",
+  "requestedRef": "7f6158b5f4997c81ebc0440366938a6d37484d76",
+  "templateCommit": "7f6158b5f4997c81ebc0440366938a6d37484d76",
   "encodedPaths": {
     ".codex/skills/data-analytics/.gitignore": ".codex/skills/data-analytics/__yss_dotfile__.gitignore",
     ".codex/skills/product-design/.npmignore": ".codex/skills/product-design/__yss_dotfile__.npmignore",
     ".codex/skills/product-design/templates/prototype/.npmrc": ".codex/skills/product-design/templates/prototype/__yss_dotfile__.npmrc",
     ".gitignore": "__yss_dotfile__.gitignore"
   },
-  "snapshotHash": "6b34f825d2ba8d0eeb166908c86f059be830aed125a406875981694a64cfaeb3",
-  "generatedAt": "2026-08-22T18:07:26.040Z"
+  "snapshotHash": "968c9df9d552c8041e32423c0c78a471e216859cc50b03660f79dbdf606149f1",
+  "generatedAt": "2026-08-23T14:47:09.357Z"
 }

package/template/wiki/raw/create-yss-spec-contract.md

@@ -1,59 +0,0 @@
-# `create-yss-spec` 仓库身份与迁移契约
-
-本文定义模板仓库与外部 `create-yss-spec` CLI 仓库之间的跨仓库发布契约。模板治理父 Ticket 为 [#24](https://github.com/iloveZzz/yss-spec-project-template/issues/24)，CLI 交接子 Ticket 为 [#26](https://github.com/iloveZzz/yss-spec-project-template/issues/26)。
-
-## 契约目标
-
-- 模板源仓库保留 `repository_mode: template-source`。
-- CLI 创建的产品仓库必须写入 `repository_mode: project-instance`，不得原样保留模板源身份。
-- 清单只包含 `schema_version` 与 `repository_mode`；项目名称、团队规模、Tracker 和实现仓库信息不得写入清单。
-- CLI 初始化与升级后的落地文档正文以简体中文为标准语言。
-
-## 初始化转换
-
-CLI 从模板内容生成目标仓库时，必须在写入目标目录后、执行模板验证前完成以下转换：
-
-1. 将根目录 `yss-project.yaml` 的 `repository_mode` 从 `template-source` 改为 `project-instance`。
-2. 保持 `schema_version: 1`，拒绝未知 schema 版本或未知模式。
-3. 保持 `.agents/skills` 为共享技能权威内容，并保留其他 Agent root 的生成投影与平台专属技能。
-4. 执行目标仓库的 `scripts/sync-skills --check`、`scripts/update-skill-lock --check` 和 `scripts/verify-template`。
-
-## 旧版升级转换
-
-升级已有仓库时必须执行 `docs/user-guide/规格与任务迁移指南.md` 中的路径迁移，删除过时 skill 目录且不创建兼容别名。若目标路径已存在或旧、新资产内容冲突，CLI 必须停止并输出冲突清单，不得静默覆盖用户内容。
-
-## 外部仓库验收测试
-
-CLI 仓库至少补充以下集成场景：
-
-1. 从当前模板初始化空目录，断言输出清单为 `project-instance` 且只含两个字段。
-2. 断言初始化输出不存在过时 skill、旧模板路径和单数 Agent skill root。
-3. 断言共享 skill 投影及 `skills-lock.json` 完整目录树哈希校验通过。
-4. 用旧版 fixture 执行升级，断言 Spec / Ticket 新路径生效；存在内容冲突时 fail closed。
-5. 在初始化后的仓库运行 `scripts/verify-template`，断言五类压力场景、Markdown 链接和 YAML 解析全部通过。
-
-## 发布顺序
-
-1. 模板仓库完成 fresh verification 与独立审查，形成待发布 commit / tag，但暂不声明整体可发布。
-2. CLI 仓库按本契约实现身份转换与升级测试，并绑定模板的确定 commit / tag。
-3. 两个仓库共同执行初始化和升级集成测试。
-4. 先发布模板兼容版本或确定模板引用，再发布 CLI major 版本；最后同步父 Ticket、迁移说明和发布记录。
-
-任一仓库未通过共同集成验证时，只能声明“本仓库实现完成，跨仓库发布受阻”，不得声明整体可发布。
-
-## 当前责任边界
-
-- 本仓库负责：清单 schema、流程事实源、迁移指南、skills 投影与锁定、模板验证脚本。
-- `create-yss-spec` 仓库负责：初始化转换、升级转换、冲突处理、CLI 集成测试、CLI major 发布。
-- 模板实现 PR：[#30](https://github.com/iloveZzz/yss-spec-project-template/pull/30)，修正 Ticket 目录、空 skill 锁登记和无 Git 初始化时的模板校验。
-- CLI 实现 PR：[`create-yss-spec` #10](https://github.com/iloveZzz/create-yss-spec/pull/10)，实现身份转换、旧版迁移、fail closed、skill 投影复制和 `2.0.0` 版本准备。
-- 共同验证：`YSS_SPEC_TEMPLATE_REF=codex/ticket-directory-contract npm test`，20/20 通过；生成实例执行 `scripts/verify-template` 通过；`npm pack --dry-run` 通过。
-- 下一责任人：模板与 CLI 独立 reviewer；合并后由发布负责人绑定确定 commit / tag 重跑验证并确认 npm `2.0.0` 发布。
-- 建议 skills：`cross-repo-implementation-routing`、`tdd`、`code-review`。
-
-## 当前阻断条件
-
-- 模板 PR #30 尚未独立 review 与合并。
-- CLI PR #10 尚未独立 review 与合并。
-- 当前共同测试绑定开发分支；合并后必须改绑确定 commit / tag 再执行 fresh verification。
-- npm `2.0.0` 尚未获得发布确认，本轮不执行 npm 发布。