create-yss-spec 2.1.9 → 2.1.10

package/README.md

@@ -33,7 +33,7 @@ npx create-yss-spec@latest
 - 旧、新资产内容冲突或清单 schema / mode 非法时 fail closed
 - 保留模板的共享 skill 投影；生成实例可在尚未 `git init` 时运行模板校验
 
-本次模板适配按 `2.1.6` 发布。`templateCommit` 会写入实例 metadata；“最新模板”指用户执行的 `npx create-yss-spec@latest` 所携带的最新已发布快照，CLI 运行时不会拉取模板仓库。
+本次模板适配按 `2.1.10` 发布。`templateCommit` 会写入实例 metadata；“最新模板”指用户执行的 `npx create-yss-spec@latest` 所携带的最新已发布快照，CLI 运行时不会拉取模板仓库。
 
 ## 接管已有项目
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-yss-spec",
-  "version": "2.1.9",
+  "version": "2.1.10",
   "description": "Initialize a YSS spec project template repository",
   "repository": {
     "type": "git",

package/src/cli.js

@@ -18,6 +18,15 @@ const TEMPLATE_MANIFEST = JSON.parse(TEMPLATE_MANIFEST_TEXT);
 const ROOT_EXCLUDED_ENTRIES = new Set(TEMPLATE_MANIFEST.excludeRootEntries);
 const ROOT_EXCLUDED_FILES = new Set(TEMPLATE_MANIFEST.excludeRootFiles);
 const EXCLUDED_RELATIVE_PATHS = new Set(TEMPLATE_MANIFEST.excludePaths);
+const INIT_EXCLUDED_ROOT_ENTRIES = new Set(
+  TEMPLATE_MANIFEST.initExcludeRootEntries || [],
+);
+const INIT_EXCLUDED_ROOT_FILES = new Set(
+  TEMPLATE_MANIFEST.initExcludeRootFiles || [],
+);
+const INIT_EXCLUDED_RELATIVE_PATHS = new Set(
+  TEMPLATE_MANIFEST.initExcludePaths || [],
+);
 const RENDERED_RELATIVE_PATHS = new Set(TEMPLATE_MANIFEST.renderPaths);
 const EXAMPLE_DOC_PATHS = new Set(TEMPLATE_MANIFEST.exampleDocPaths);
 const TEMPLATE_METADATA_FILENAME = ".yss-template.json";
@@ -323,12 +332,20 @@ function targetPath(targetDir, relativePath) {
   return resolved;
 }
 
-function shouldExcludeRelativePath(relativePath) {
-  return EXCLUDED_RELATIVE_PATHS.has(normalizeRelativePath(relativePath));
+function shouldExcludeRelativePath(relativePath, mode = "managed") {
+  const normalized = normalizeRelativePath(relativePath);
+  return EXCLUDED_RELATIVE_PATHS.has(normalized) ||
+    (mode === "init" &&
+      (INIT_EXCLUDED_RELATIVE_PATHS.has(normalized) ||
+        INIT_EXCLUDED_ROOT_FILES.has(normalized)));
 }
 
-function shouldSkipRootEntry(entryName) {
-  return ROOT_EXCLUDED_ENTRIES.has(entryName) || ROOT_EXCLUDED_FILES.has(entryName);
+function shouldSkipRootEntry(entryName, mode = "managed") {
+  return ROOT_EXCLUDED_ENTRIES.has(entryName) ||
+    ROOT_EXCLUDED_FILES.has(entryName) ||
+    (mode === "init" &&
+      (INIT_EXCLUDED_ROOT_ENTRIES.has(entryName) ||
+        INIT_EXCLUDED_ROOT_FILES.has(entryName)));
 }
 
 function parseRepositoryIdentity(content) {
@@ -438,12 +455,18 @@ function renderTemplateFile(relativePath, content, variables) {
   return content;
 }
 
-function buildCopyPlan(sourceDir, targetDir, variables, relativeDir = "") {
+function buildCopyPlan(
+  sourceDir,
+  targetDir,
+  variables,
+  relativeDir = "",
+  mode = "managed",
+) {
   const operations = [];
   const entries = fs.readdirSync(sourceDir, { withFileTypes: true });
 
   for (const entry of entries) {
-    if (!relativeDir && shouldSkipRootEntry(entry.name)) {
+    if (!relativeDir && shouldSkipRootEntry(entry.name, mode)) {
       continue;
     }
 
@@ -452,7 +475,7 @@ function buildCopyPlan(sourceDir, targetDir, variables, relativeDir = "") {
       : entry.name;
     const relativePath = logicalTemplatePath(bundledRelativePath);
 
-    if (shouldExcludeRelativePath(relativePath)) {
+    if (shouldExcludeRelativePath(relativePath, mode)) {
       continue;
     }
 
@@ -466,7 +489,13 @@ function buildCopyPlan(sourceDir, targetDir, variables, relativeDir = "") {
     if (entry.isDirectory()) {
       operations.push({ type: "mkdir", relativePath, targetPath: targetPathValue });
       operations.push(
-        ...buildCopyPlan(sourcePath, targetDir, variables, bundledRelativePath),
+        ...buildCopyPlan(
+          sourcePath,
+          targetDir,
+          variables,
+          bundledRelativePath,
+          mode,
+        ),
       );
       continue;
     }
@@ -567,14 +596,14 @@ function buildSyncVariables(metadata) {
   };
 }
 
-function buildDesiredManagedOperations(targetDir, variables) {
-  return buildCopyPlan(BUNDLED_TEMPLATE_ROOT, targetDir, variables)
+function buildDesiredManagedOperations(targetDir, variables, mode = "managed") {
+  return buildCopyPlan(BUNDLED_TEMPLATE_ROOT, targetDir, variables, "", mode)
     .filter((operation) => operation.type === "copy" || operation.type === "render")
     .map((operation) => buildDesiredManagedFile(operation, { variables }));
 }
 
 function buildSyncDesiredOperations(targetDir, variables, identity) {
-  return buildDesiredManagedOperations(targetDir, variables).map((operation) => {
+  return buildDesiredManagedOperations(targetDir, variables, "init").map((operation) => {
     if (
       operation.relativePath !== "yss-project.yaml" ||
       identity.state !== "valid" ||
@@ -1096,7 +1125,12 @@ function runTemplateVerification(targetDir, scriptPath) {
   }
 }
 
-function verifyGeneratedTemplate(targetDir) {
+function verifyGeneratedTemplate(targetDir, mode = "managed") {
+  if (mode === "init") {
+    verifyGeneratedInstance(targetDir);
+    return;
+  }
+
   for (const scriptPath of [
     "scripts/sync-skills",
     "scripts/update-skill-lock",
@@ -1106,6 +1140,33 @@ function verifyGeneratedTemplate(targetDir) {
   }
 }
 
+function verifyGeneratedInstance(targetDir) {
+  const forbiddenPaths = [
+    ...[...INIT_EXCLUDED_ROOT_ENTRIES],
+    ...[...INIT_EXCLUDED_ROOT_FILES],
+    ...[...INIT_EXCLUDED_RELATIVE_PATHS],
+  ];
+  for (const relativePath of forbiddenPaths) {
+    if (pathKind(targetPath(targetDir, relativePath)) !== "missing") {
+      throw new Error(`初始化结果包含禁止分发的模板源资产：${relativePath}`);
+    }
+  }
+
+  const identity = readTargetIdentity(targetDir);
+  if (
+    identity.state !== "valid" ||
+    identity.fields.repository_mode !== "project-instance"
+  ) {
+    throw new Error("初始化结果的 yss-project.yaml 必须是 project-instance");
+  }
+
+  const agentsContent = fs.readFileSync(targetPath(targetDir, "AGENTS.md"), "utf8");
+  const readmeContent = fs.readFileSync(targetPath(targetDir, "README.md"), "utf8");
+  if (agentsContent.includes("[填写]") || readmeContent.includes("[填写]")) {
+    throw new Error("初始化结果仍包含模板占位信息");
+  }
+}
+
 function loadTemplateMetadata(targetDir) {
   const metadataPath = targetPath(targetDir, TEMPLATE_METADATA_FILENAME);
   const metadataKind = pathKind(metadataPath);
@@ -1483,7 +1544,13 @@ function runInit(argv = []) {
     readTemplateSnapshot();
     const targetDir = normalizeTargetDir(promptedOptions.targetDir);
     const targetState = inspectTargetDir(targetDir, promptedOptions.force);
-    const operations = buildCopyPlan(BUNDLED_TEMPLATE_ROOT, targetDir, promptedOptions);
+    const operations = buildCopyPlan(
+      BUNDLED_TEMPLATE_ROOT,
+      targetDir,
+      promptedOptions,
+      "",
+      "init",
+    );
 
     if (promptedOptions.dryRun) {
       console.log("dry-run 预览");
@@ -1496,7 +1563,7 @@ function runInit(argv = []) {
 
     prepareTargetDir(targetDir, targetState);
     executePlan(operations, promptedOptions);
-    verifyGeneratedTemplate(targetDir);
+    verifyGeneratedTemplate(targetDir, "init");
     writeTemplateMetadata(
       targetDir,
       buildMetadata(promptedOptions, operations.filter((operation) => operation.type !== "mkdir"), targetDir),
@@ -1671,7 +1738,7 @@ function runSync(argv = []) {
       applyManagedOperation(operation, transaction);
     }
     applyMigrationPlan(migrationPlan, transaction);
-    verifyGeneratedTemplate(targetDir);
+    verifyGeneratedTemplate(targetDir, "init");
     writeTemplateMetadata(
       targetDir,
       buildNextSyncMetadata(metadata, syncPlan, targetDir),

package/template/.agents/skills/diagnosing-bugs/SKILL.md

@@ -127,7 +127,7 @@ If a correct seam exists:
 4. Watch it pass.
 5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.
 
-## Phase 6 — Cleanup + post-mortem
+## Phase 6 — Cleanup
 
 Required before declaring done:
 
@@ -135,6 +135,4 @@ Required before declaring done:
 - [ ] Regression test passes (or absence of seam is documented)
 - [ ] All `[DEBUG-...]` instrumentation removed (`grep` the prefix)
 - [ ] Throwaway prototypes deleted (or moved to a clearly-marked debug location)
-- [ ] The hypothesis that turned out correct is stated in the commit / PR message — so the next debugger learns
-
-**Then ask: what would have prevented this bug?** If the answer involves architectural change (no good test seam, tangled callers, hidden coupling) hand off to the `/improve-codebase-architecture` skill with the specifics. Make the recommendation **after** the fix is in, not before — you have more information now than when you started.
+- [ ] The hypothesis that turned out correct is stated in the commit / PR message, so the next debugger learns

package/template/.agents/skills/domain-modeling/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: domain-modeling
-description: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
+description: Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.
 ---
 
 # Domain Modeling

package/template/.agents/skills/grilling/SKILL.md

@@ -7,11 +7,17 @@ Interview the user relentlessly until you reach a shared understanding. Map this
 
 Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
 
-Each question should be formatted like so:
+Format a round like so:
 
 ```
 ❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
 
+➡️ <your recommended answer>
+
+---
+
+❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
 ➡️ <your recommended answer>
 ```
 

package/template/.agents/skills/triage/SKILL.md

@@ -40,7 +40,7 @@ For a PR, the same states read against the attached code: `ready-for-agent` mean
 
 Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
 
-These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you - run `/setup-matt-pocock-skills` if not.
+These are canonical role names. The actual label strings used in the issue tracker may differ. The mapping should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.
 
 State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
 
@@ -73,7 +73,7 @@ Show counts and a one-line summary per item. Let the maintainer pick.
 
 3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims — check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.
 
-4. **Grill (if needed).** If the request needs fleshing out, run the `/grilling` and `/domain-modeling` skills together — grill it into shape a round of questions at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
+4. **Grill (if needed).** If the request needs fleshing out, call the Skill tool twice, for "grilling" and "domain-modeling", and grill it into shape a round of questions at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
 
 5. **Apply the outcome:**
    - `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).

package/template/.agents/skills/wait-what/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wait-what
-description: Stop. That last message did not land — re-pitch it.
+description: "Stop. That last message did not land: re-pitch it."
 disable-model-invocation: true
 ---
 
-Wait — I don't understand where you've got to here. Re-pitch that: give me a little bit of context, talk in ASD-STE100 Simplified Technical English, and use the ubiquitous language from `CONTEXT.md`.
+Wait, I don't understand where you've got to here. Re-pitch that: give me a little bit of context, talk in ASD-STE100 Simplified Technical English, and use the ubiquitous language from `CONTEXT.md` (follow `CONTEXT-MAP.md` to the right one if the repo has more than one).

package/template/.agents/skills/wayfinder/SKILL.md

@@ -22,7 +22,7 @@ The map is a single issue on this repo's issue tracker, labelled `wayfinder:map`
 
 The map is an **index**, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place — its ticket — so the map never restates it, only gists it and links.
 
-**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you — run `/setup-matt-pocock-skills` if not. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
+**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
 
 ### The map body
 

package/template/.agents/skills/yss-product-lifecycle/SKILL.md

@@ -1,97 +1,49 @@
 ---
 name: yss-product-lifecycle
-description: Use when starting, continuing, auditing, or routing a YSS product/module/change across Discovery, Spec, design, OpenAPI, architecture, Tickets, implementation, review, release, or retrospective; or when lifecycle assets, gates, Matt flows, YSS skills, or readiness are unclear.
+description: 编排 YSS 产品或模块从机会调研到 Spec、原型、技术契约、垂直切片实现、审查、发布和复盘；当阶段、产物、门禁或 YSS skill 不清晰时使用。
 ---
 
 # YSS Product Lifecycle
 
-YSS 产品研发的全生命周期主控编排器。它决定阶段、条件门禁、状态和工作顺序；Matt skills 提供通用工作流，YSS skills 提供专项实现规则。编排器持续主控，但不得绕过专项 skill 直接规定业务实现。
-
-## 启动
-
-1. 读取根目录 `yss-project.yaml`；非法或缺失时停止并进入迁移检查。
-2. 读取 `CONTEXT.md`、相关 ADR、父 Ticket/checkpoint、当前资产与 tracker 配置。
-3. `template-source` 只走模板维护流程；不得生成具体产品 Spec、原型、OpenAPI 或切片 Ticket。
-4. `project-instance` 以 `docs/process/lifecycle-registry.yaml`、由其派生的 `docs/process/lifecycle-artifact-map.md` 和 `docs/process/harness-process-tailoring.md` 为阶段、门禁和裁剪事实来源。
-
-YSS 仓库以本 skill 为直接入口，不机械嵌套调用 `ask-matt`。`ask-matt` 仅在用户显式调用时作为 Matt 通用导航：不得写生命周期资产或改变门禁/Ticket 状态，并须在任何写入前回交本编排器。不要修改 Matt skills 来复制 YSS 规则。
-
-## 选择模式
-
-| 请求 | 模式 | 副作用 |
-|---|---|---|
-| “该怎么做/下一步” | `route` | 只读 |
-| “推进/完成” | `orchestrate` | 在授权范围内有界推进 |
-| “继续之前工作” | `resume` | 先重建并核验状态，再有界推进 |
-| “是否可开发/合并/发布” | `audit` | 严格只读，不顺带修复 |
-
-用户显式模式优先；无法判断时用 `route`。执行协议见 [orchestration.md](references/orchestration.md)。
-
-## 核心规则
-
-- 保留生命周期注册表定义的主阶段；其中条件门禁全部按影响面强制。命中项必须达到 `approved`，未命中项记录 `not-applicable` 和原因；产物、工作单元和证据不得被统称为门禁。
-- 安全 / 权限不设独立生命周期资料、专属门禁或 `not-applicable` 记录。只有需求或冻结资产明确要求改变认证、授权、租户隔离、敏感数据或合规行为时，才把该行为写入普通 Spec、API、架构、验收和测试 seam，并仅按实际 UI、API、Backend、Data、High-risk 影响触发既有门禁；普通 action 注册、沿用认证中间件、未变化的 `401` / `403`、一般字段、SQL / DDL / 迁移和上传 / 下载本身不触发安全 / 权限流程。
-- 有效 `yss-project.yaml` 存在时，Matt user-invoked skill 保持显式用户入口。生命周期可以准备和验收其结果，但不得自动调用它们或代替其创建正式资产；最终入口、仓库身份和模式裁决归本编排器。
-- `template-source` 命中产品 flow 时必须返回 `blocked`（`template-source-product-artifact-forbidden`），不得继续到产品资产或 Ticket 生成。
-- `template-source` 迁移共享工具或验证器前，先区分维护侧构建资产、实例分发面和实例运行资产；冻结公开入口、运行时前提、旧实现处置和跨仓消费者契约后，才可改写实现。
-- 替换自身验证门禁时，不得只用候选门禁自证；必须保留独立 baseline oracle 或同一 fixture 的双跑证据。涉及共享运行资产时，只有生成/同步实例、失败回滚和跨仓消费者的 fresh evidence 齐备，才能声明生态完成或可发布。
-- 文件存在不等于就绪。按内容、审查结论和上游新鲜度评估资产。
-- 父 Ticket/checkpoint 的状态只是索引；与真实资产冲突时，以权威资产为准并修复索引。
-- 上游变化按依赖图精准传播 `stale`；不要无条件重跑完整阶段。
-- Matt 五态保持原义。只有解除阻塞、门禁通过且可直接实现的垂直切片才能使用 `ready-for-agent`。
-- 用户显式运行 `to-spec` 后，生命周期必须把其 `ready-for-agent` 发布提示归一化为 Spec `ready-for-human`；不得把 Spec 初稿当作可直接实现的 Ticket。
-- 用户显式运行 `to-tickets` 后，新建垂直切片统一写为 `ready-for-human`；只有本编排器复算完整 `ready-for-agent` 公式后才能提升，通用默认标签不得提前覆盖生命周期状态。
-- `orchestrate`/`resume` 连续执行安全的准备、校验和 model-invoked 工作单元，直到需要显式用户入口、人工门禁、真实阻塞、新授权、实现/发布裁决或专项失败。
-- 进入实现准备后继续主控，通过 `yss-router`、`code-review` 和 YSS 专项 skills 执行允许的 model-invoked 工作单元；`implement` 本身仍须由用户显式启动，并在其自身流程内按需使用 `tdd`，结果回交后再做独立审查和 fresh verification。只有工作单元真实触碰当前用户、审计、加密或明确的权限业务行为时，才增加 `yss-userinfo`、`yss-audit-log`、`yss-security-algorithm` 等专项依赖。
-- 原型确认 → 后端脚手架：命中产品设计影响时，先按 `yss-prototype-stage` 形成交互说明、独立 Prototype Review、高保真 HTML、AntD CLI 与浏览器验证、用户确认；只有 `gate.prototype-reviewed`、`gate.prototype-verified` 和 `gate.user-confirmation` 均满足时，才能进入下游。若 backend `scaffold_status=required`，随后先完成工程基线，由 `yss-router` 编译脚手架受控生成工作单元合同，经生命周期编排器批准并持久化后，才使用 `yss-ddd-scaffold-generator` 生成后端骨架；随后由 `yss-backend-scaffold-parent` 校验并重新进入 `yss-router`，不得先写业务代码。
-- 所有后续生成的后端代码都必须消费生命周期批准、已持久化且版本当前的 Slice Implementation Contract，绑定最小 YSS skill 闭包、允许写路径、证据文件和 YSS Skill Execution Result；没有这些证据时必须阻断。
-- Harness 内承载运行时代码时，项目路径策略固定为 `apps/backend/<project>/` 和 `apps/frontend/<project>/`；`apps/backend/`、`apps/frontend/` 仅是项目容器，`app/backend/`、`app/frontend/` 及其子路径禁止生成。外部实现仓库不强制使用该目录，但必须登记真实项目根路径并写入合同。
-- Setup readiness 每个任务只评估一次并在本轮缓存；只有 tracker、主远端、真实标签或配置变化时重查。
-- Ticket tracker 支持 `local-markdown`、GitHub 和 GitLab；模板默认 `local-markdown`，以 `docs/.scratch/<feature>/` 完整功能包为主载体。Git remote 只代表代码托管，不能覆盖已持久化的 tracker 选择；Local 主 tracker 不要求远程 Ticket。根 `.scratch/` 与 `docs/requirements/tickets/` 只作为旧路径迁移来源。
-- 小改动和中等变更允许同一独立执行者完成 Review 与 fresh verification；该执行者不得是实现者。新模块、高风险或职责冲突时拆分 Reviewer 与 Verifier。
-- 进入 `code-review` 前必须持久化或明确传入 `review_mode`、`review_base_ref`、`candidate_snapshot_ref`、`candidate_digest` 和完整候选引用；`worktree` 模式必须一次捕获 committed、staged、unstaged、untracked，并让两个 Reviewer 消费同一快照，不能用只看 `HEAD` 或实时变化的 diff 宣称已审查。候选 manifest 和 `yss-worktree-candidate-v1` 不可变摘要流以 `orchestration-contract.yaml.review_input` 为唯一机器契约。
-- 实现授权不包含 Git 授权。只有用户分别明确给出值为 `true` 的 `commit_authorized` / `push_authorized`、非空 scope 和对应 `*_authorization_ref` 时才执行动作；缺失时只记录 checkpoint 判断，不得把 `implement`、`orchestrate`、当前分支或负责人要求解释成隐含授权。
-- “然后 commit”“做完提交”等自然语言意向不构成上述结构化 Git 授权，不能据此预授权或事后补齐 scope / authorization ref。
-- 连续自动推进期间累积 Ticket/Git 证据，在人工暂停、handoff、进入实现、合并或发布边界集中 checkpoint；不为每个连续经过的概念阶段重复写同类记录。
-- 跨线程、仓库、原型分支或上下文边界时使用 `handoff` 或等价记录。
-- 在 Matt 阶段边界（phase boundary）先按 `Continue → /clear → /handoff → subagent → /compact` 判断上下文动作；只在 checkpoint 记录可选 `phase_boundary` 证据，不新增生命周期状态。
-- `to-questionnaire` 进入结构化 `external-input-required` 暂停；回答回流后必须重新分类影响面并更新权威资产，不能直接恢复下游实现。
-- `wait-what` 只重新解释当前结论，不改变阶段、门禁、Ticket 或 `ready-for-agent` 状态；Agent 无法替代的人工步骤使用显式人工 checkpoint，秘密值不得进入持久化输出。
-- Matt `prototype` 是保留在 `prototype/<name>` 分支的单文件可分享 HTML 主来源；YSS 高保真 HTML 原型仍必须经过 Prototype Review、AntD CLI、浏览器验证和用户确认，两者不得互相替代。
-- 新工作单元返回 `Workflow Execution Result`；旧 `Matt Skill Result` 仅可兼容读取后归一化。`drift`、`new_impacts`、`violation`、`stale_candidates`、缺失证据或不完整结果不得推进为 `completed`。
-
-### 原型完成后的后端脚手架与代码生成边界
-
-`prototype_confirmation` 是产品设计门禁，不是业务实现授权。后端新工程的顺序固定为：工程基线 → `yss-router` 编译脚手架合同 draft → 生命周期批准/持久化 → `yss-ddd-scaffold-generator` → `yss-backend-scaffold-parent` → `yss-router` 合同重编译 → 垂直切片实现。
-
-- `scaffold_status=required` 时，脚手架工作单元使用 `controlled-generation`，记录项目名、基础包名、输出目录、数据库类型、预期文件和实际 `./mvnw validate`、`./mvnw test`、`./mvnw package` 结果，并返回 YSS Skill Execution Result。
-- 脚手架合同必须结构化记录 `contract_id`、`contract_version`、`slice_id`、Router draft 引用、生命周期批准引用、持久化引用、当前版本、实现仓库、允许写路径、预期证据文件和验证命令；生命周期批准记录至少包含 `approval_ref`、`approver`、`persisted_ref`、`current_version`。
-- `yss-ddd-scaffold-generator` 必须读取已持久化的结构化脚手架合同 JSON，并校验 `status=approved`、当前版本、主 skill、`controlled-generation` 和固定验证命令；只传任意字符串引用不得放行。
-- 生成项目必须包含 `.yss/scaffold-generation.json`，回勾实际使用的合同 ID、版本、Router draft 引用、生命周期批准引用、持久化引用、生成输入、受控模式和固定验证命令；元数据清单缺失或过期时阻断后续 Router。
-- 三条 `./mvnw` 命令必须由受控工作单元真实执行，并记录每条命令的 `exit_code`、`duration_ms`、stdout/stderr 引用和执行时间；生成器打印的命令、输出目录存在或“生成成功”都不构成验证证据。
-- 脚手架只生成多模块工程结构、POM、配置、Wrapper 和经验证的机械模板；不得生成或承载领域规则、状态机、权限、事务、复杂查询、错误映射或用户可见业务行为。
-- 该生命周期脚手架工作单元必须关闭 `--with-example`，不得把 User CRUD 或业务字段伪装成样板；目标目录非空时 `--force` 默认阻断，只有覆盖范围、备份、回滚点和明确批准全部进入合同后才能另行审查。
-- `scaffold_status=existing` 或 `initialized` 时不重复全量生成，但仍须完成 `yss-backend-scaffold-parent` 基线证据、Wrapper 校验和 `yss-router` 合同重编译。
-- 脚手架完成不等于实现仓库接入、架构放行、契约批准或 `ready-for-agent`。后续每一个 Agent / generator 写入的后端代码都必须绑定批准合同和对应 YSS skill；业务行为只能使用 `behavior-tdd`，机械生成才可使用 `controlled-generation`。
-
-| 压力诱因 | 统一裁决 |
-|---|---|
-| “普通 action、SQL / DDL 或下载也要补安全姿态吗” | 不补。没有明确的安全 / 权限行为需求时只按实际 API、Data 或工程影响推进；明确改变相关行为时也只复用普通产物和门禁。 |
-| “延期项先不写责任人和目标版本，之后再补” | 阻断 `seam-deferred`；必须写风险、责任人、后续 Ticket、验证计划和目标版本 / 发布日期。 |
-| “脚手架本来就是 YSS，先生成代码再补合同” | 先阻断；Router draft 不能批准合同或替代生命周期放行。 |
-| “`./mvnw validate` 已通过，直接继续最省时间” | 只证明工程基线可验证，不证明业务、事务或契约已获批；三条实际命令的结果还必须进入 Execution Result。 |
-| “后续代码也是生成物，不需要重新路由” | 只要写入业务代码，就必须重新消费当前 Slice Implementation Contract 和 YSS skill 闭包。 |
-| “发布窗口快结束了，可以把业务字段放进脚手架” | 时间、上级要求、已有产出和演示压力都不能放宽禁止模式；必须拆为 `behavior-tdd` 工作单元。 |
-
-**红旗：** 输出目录存在、脚手架成功、只打印了 `./mvnw` 命令、`validate` 通过、Router 只有 draft、或生成器参数中出现业务字段 / 权限 / 事务 / 状态机，均不足以继续业务实现；命中任一项即暂停并重路由。
-
-**项目路径策略：** 在 Harness 内生成项目时，先确认目标属于 `apps/backend/<project>/` 或 `apps/frontend/<project>/`；把 `apps/backend/`、`apps/frontend/` 当作项目根，或把单数 `app/backend/`、`app/frontend/` 当作等价路径，均属于路径违规并阻断。
-
-状态和依赖规则见 [state-model.md](references/state-model.md) 与 [artifact-dependencies.md](references/artifact-dependencies.md)；Matt/YSS 对应见 [matt-yss-adapter.md](references/matt-yss-adapter.md)。
-机器可执行的模式、readiness、Wayfinder、影响传播和回流字段见 [orchestration-contract.yaml](references/orchestration-contract.yaml)。说明文档与该契约冲突时必须暂停并修订权威资产，不得猜测。
-
-## 输出
-
-始终输出：模式、当前阶段、影响面、证据、资产/门禁状态、阻塞项、本轮动作、下一工作单元、暂停或继续理由、Ticket 同步和 Git checkpoint 判断；追加 `Workflow Execution Result`，并注明 workflow reference 或实际 model-invoked skill。
-
-暂停时只提出一个具体人工决策，并给出推荐答案与确认后的恢复动作。`audit`/`route` 不得写文件、Ticket、标签或 Git。
+这是生命周期主控 skill：负责识别阶段、判定影响面、检查产物与门禁、选择下一工作单元并验收结果。业务实现必须交给对应的 Matt/YSS 专项 skill；本 skill 不替代它们。
+
+## 入口与边界
+
+1. 先读取 `yss-project.yaml`、`CONTEXT.md`、相关 ADR、父 Ticket/checkpoint 和当前资产。
+2. `repository_mode=template-source` 只走模板维护流程；命中产品流程时返回 `blocked: template-source-product-artifact-forbidden`，不得生成产品 Spec、原型、OpenAPI 或切片 Ticket。
+3. `repository_mode=project-instance` 以 `docs/process/lifecycle-registry.yaml`、`harness-process-tailoring.md` 和本目录 references 为唯一阶段、门禁和裁剪事实源。
+4. 模式：`route` 只读规划；`orchestrate` 有界推进；`resume` 重建后推进；`audit` 严格只读。未明确时使用 `route`。
+
+Matt 的 `grill-with-docs`、`to-spec`、`to-tickets`、`implement` 等保留为显式兼容入口；默认路径是本 skill 持有的原生工作单元，由本编排器创建正式资产、维护状态并在四类人工门禁暂停。兼容入口不得自动调用它们或代替其创建正式资产；Matt 只导航，不得写生命周期资产或改变门禁/Ticket 状态；任何写入前回交本编排器。
+
+## 不可裁剪的主链
+
+机会调研/需求分析 → Spec/功能架构 → 产品设计与原型 → 技术分析（系统、数据、API、工程基线）→ Ticket 正式化 → 垂直切片实现（前后端 TDD）→ 独立 code review 与 fresh verification → 发布/复盘。
+
+裁剪只允许将未命中的条件门禁标记为 `not-applicable` 并写原因；不得删除主阶段、已命中的门禁或必需产物。阶段是否完成取决于“内容 + 审查结论 + 上游新鲜度 + 可读证据”，文件存在不算通过。
+
+## 阶段路由与技能
+
+| 阶段 | 必需产物/门禁 | 工作单元与技能 | 通过条件 |
+|---|---|---|---|
+| 入口分诊 | 身份、影响面、最近可信阶段 | `yss-product-lifecycle` | `yss-project.yaml` 合法且影响面可解释 |
+| 机会调研/需求分析 | Discovery、用户/MVP/非目标/成功标准、测试 seam | `work-unit.discovery-opportunity` + `work-unit.discovery-requirements`；市场/竞品事实用 `competitive-intelligence`，技术/标准事实用 `research`；`grill-with-docs` 为兼容入口 | 未决事实已 research 或 handoff，用户确认，无 runnable blocker |
+| Spec/功能架构 | Spec、产品总体设计、功能架构；必要时 Spec Delta | 原生 `work-unit.spec-synthesis`；`to-spec` 为兼容入口 | 初稿先为 `ready-for-human`；只有 Spec baseline 人工批准后资产才为 `approved` 并进入下游 |
+| 原型设计 | 交互说明、低保真、状态矩阵、高保真 HTML、评审记录 | `yss-design-system` → `yss-prototype-stage` → Codex `product-design:index`（非 Codex 交付等价合同） | `gate.prototype-reviewed`、`gate.prototype-verified`、`gate.user-confirmation` 均有证据 |
+| 技术分析 | OpenAPI Draft/Freeze、数据架构、工程基线、架构审查 | `yss-openapi-governance` / `yss-openapi-draft-review`、`codebase-design`、`implementation-repo-onboarding`、`yss-router` | API/架构契约冻结；无 API 影响有明确记录；脚手架策略满足 |
+| Ticket 正式化 | 功能父 Ticket、垂直切片、Slice Implementation Contract | 原生 `work-unit.ticket-decomposition`；`to-tickets` 为兼容入口；生命周期复算 | 依赖、验收、测试 seam 可执行；合同已批准、持久化且为当前版本 |
+| 技术实现 | 前端/后端代码、TDD 证据、YSS Skill Execution Result | 原生 `work-unit.slice-implementation`；`implement` 为兼容入口；前端按 `yss-ui` + `yss-page-module-development`，后端按 `yss-router` 最小闭包，业务行为统一 `tdd` | 只写允许路径；业务行为用 `behavior-tdd`；UI 影响必须有还原计划 |
+| Review/验证 | 不可变候选快照、review 结论、fresh verification | `code-review`（独立于实现者）；UI 影响追加 `yss-ui` + `yss-design-system` 的 UI fidelity 轴 | findings 已处理；同一候选快照通过全部审查轴与验证 |
+| 发布/复盘 | 发布/回滚证据、复盘记录 | 生命周期自有工作单元 | fresh verification、独立审查和人工发布裁决齐全 |
+
+## 前端实现还原硬检查
+
+原型通过不等于前端实现通过。`ready-for-agent` 前先产生 `frontend_implementation_plan`（原型/Spec、路由与页面清单、桌面/窄屏验收用例、加载/空态/错误/权限/关键交互状态、拟执行的 `pnpm` 命令）；实现完成、发布前再产生 `frontend_implementation_verification`，补齐截图或视觉回归、console warning、命令退出码、未覆盖差异与责任人。差异未解释、截图缺失、只做 type-check 或只声称“已对齐”均为 `blocked`；发现新 API、状态或视觉行为时返回 `new_impacts`/`drift` 并重新路由。优先使用 `yss-ui/references/verification.md` 的分层验证和既有 `pnpm` scripts。
+
+## 结果与暂停
+
+每个工作单元必须返回 `Workflow Execution Result`（workflow reference、skill、changed files、evidence refs、actual verification、deferred seams、drift/new impacts）。缺少可读证据、`stale`、`violation`、`drift`、`new_impacts` 或阻塞信号时不得标记 completed。实现授权不包含 Git commit/push 授权；“做完提交”等自然语言意向不构成上述结构化 Git 授权。
+
+输出固定包含：模式、当前阶段、影响面、资产/门禁状态、证据、阻塞项、本轮动作、下一工作单元、暂停/继续理由、Ticket 同步和 Git checkpoint 判断。暂停时只提出一个具体人工决策，并给出推荐答案与恢复动作。
+
+详细执行循环、readiness、脚手架（包括 `controlled-generation`）、审查快照、状态传播和 Matt 边界见 [orchestration.md](references/orchestration.md)、[orchestration-contract.yaml](references/orchestration-contract.yaml)、[artifact-dependencies.md](references/artifact-dependencies.md) 和 [state-model.md](references/state-model.md)。

package/template/.agents/skills/yss-product-lifecycle/references/matt-yss-adapter.md

@@ -2,12 +2,14 @@
 
 Matt skills 决定如何工作；YSS 生命周期决定是否允许推进；YSS 专项 skills 决定如何符合工程规范。
 
+生命周期默认使用 `work_unit_routes.*.native`；下表中的 Matt flow 是 `work_unit_routes.*.compatibility` 显式兼容输入。兼容入口的正式资产由用户创建并回交生命周期验收，原生工作单元的正式资产由生命周期编排器创建。
+
 ## 入口与仓库身份裁决
 
 - 所有入口先读取 `yss-project.yaml`。缺失、解析失败、schema 不支持或 `repository_mode` 非法时，停止路由并进入 migration-check。
 - **直接调用 `ask-matt`** 时，它只能提供通用 Matt flow 导航，不得写生命周期资产、改变门禁或 Ticket 状态；有效 YSS 仓库必须在任何写入前把最终阶段、影响面、门禁和状态裁决交回 `yss-product-lifecycle`。
 - **直接调用生命周期管理的 Matt user-invoked skill**（`setup-matt-pocock-skills`、`grill-with-docs`、`to-spec`、`to-tickets`、`implement`）时，用户仍是正式资产的创建者；生命周期先校验前置条件，再接受结果并重新计算阶段、门禁和状态。它们不适用 `ask-matt` 的 `navigate-only` 限制。其他 user-invoked skill 同样不得由生命周期自动调用；只有在其专属适配合同存在时才进入 YSS 流程。
-- **直接调用 `yss-product-lifecycle`** 时，不机械嵌套调用任何 Matt user-invoked skill；编排器直接使用兼容映射，并只调用允许的 model-invoked 原语。Matt user-invoked skill 保持显式入口，生命周期只准备、校验并验收其结果。
+- **直接调用 `yss-product-lifecycle`** 时，不机械嵌套调用任何 Matt user-invoked skill；编排器直接使用原生工作单元和允许的 model-invoked 原语。Matt user-invoked skill 保持显式兼容入口，生命周期负责准备、校验并验收其结果。
 - `template-source` 只允许进入模板维护流程。命中 `to-spec`、`to-tickets`、`implement`、Release 或 Retrospective 时返回 `blocked`，原因是 `template-source-product-artifact-forbidden`；`ask-matt` 和 `setup-matt-pocock-skills` 都不得为具体产品生成 Spec、prototype、OpenAPI 或垂直切片 Ticket。
 - `project-instance` 才允许进入产品 Discovery → Spec → 设计 → 契约 → Ticket → 实现 → Release / Retrospective 链路。
 
@@ -20,9 +22,9 @@ Matt skills 决定如何工作；YSS 生命周期决定是否允许推进；YSS
 | 大型模糊工作 | `wayfinder` | map 真正完成后 `handoff → to-spec` |
 | 技术事实 | `research` | 一手资料回填 Spec/OpenAPI/架构/ADR |
 | runnable 问题 | `prototype` | 生成单文件可分享 HTML，保留 `prototype/<name>` 分支作为主来源；必须 source/return handoff 和结论回填，不得替代阶段 4 的低保真评审、Ant Design v6 高保真 HTML、AntD CLI 证据和用户确认 |
-| Spec 综合 | `to-spec`（用户显式） | 生命周期准备与验收；初稿进入 `ready-for-human`，不得直接实现 |
-| 切片 | `to-tickets`（用户显式） | 生命周期准备与验收；仅在冻结/无影响记录后拆垂直切片，初始角色为 `ready-for-human` |
-| 实现 | `implement`（用户显式） | `yss-router` 编译 Slice Implementation Contract 草案；本编排器核验并持久化后才允许用户启动 implement；其内部按自身流程使用 `tdd`，结果回交后再次核验 |
+| Spec 综合 | 原生 `work-unit.spec-synthesis`；`to-spec`（用户显式兼容） | 初稿进入 `ready-for-human`，不得直接实现 |
+| 切片 | 原生 `work-unit.ticket-decomposition`；`to-tickets`（用户显式兼容） | 仅在冻结/无影响记录后拆垂直切片，初始角色为 `ready-for-human` |
+| 实现 | 原生 `work-unit.slice-implementation`；`implement`（用户显式兼容） | 当前合同批准并持久化后执行；内部使用 `tdd`，结果回交后再次核验 |
 | Bug | `diagnosing-bugs`、`tdd` | 先建立红色反馈；高风险影响升级上游门禁 |
 | 审查 | `code-review` | 唯一默认代码审查入口；审查者独立，结合 Spec、仓库治理规则和 YSS 标准 |
 | 跨上下文 | `handoff` | 保存来源、阶段、未决项、命令和下一责任人 |
@@ -60,7 +62,7 @@ blocking_signals: []
 
 Router 状态映射为：`draft → completed`、`blocked → blocked`、`ready-for-lifecycle-review → needs-human`。这里的 `completed` 只表示 Matt 工作单元已产出可验收结果，不表示生命周期完成或可发布。
 
-`completed` 的 `evidence_refs` 至少包含一条可读取或可解析的证据引用；只有字段存在但为空，不能证明工作单元完成。正式 Spec、Ticket 或实现资产仍只能由对应显式用户入口创建。
+`completed` 的 `evidence_refs` 至少包含一条可读取或可解析的证据引用；只有字段存在但为空，不能证明工作单元完成。兼容入口下的正式 Spec、Ticket 或实现资产仍只能由对应显式用户入口创建；原生工作单元由生命周期编排器创建并持有状态。
 
 ## Matt flow 前置条件