create-yss-spec 2.1.14 → 2.2.0

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`