create-yss-spec 3.3.0 → 3.3.1

package/template/docs/discovery/README.md

@@ -1,87 +0,0 @@
-# 发现阶段 (Discovery) — 市场分析 · 竞品分析 · 用户洞察
-
-> **Phase 0 — 需求分析的前置输入。**
-
----
-
-## 工作流
-
-Discovery 不是固定排在 Ideation 后面的单向步骤。它和机会构想共同组成“机会探索环”，用于把事实、假设和 MVP 边界来回校准：
-
-```
-市场 / 竞品 / 用户事实 <-> 机会构想假设 <-> MVP 边界
-```
-
-进入 Spec 前必须收敛为：
-
-- 用户是谁。
-- 痛点是什么。
-- 为什么现在做。
-- 第一版做什么。
-- 明确不做什么。
-- 成功标准是什么。
-- 产品功能建设方向是什么。
-- 后续可能影响哪些 UI、API、数据、权限、架构和安全门禁。
-
-常见入口：
-
-- 只有模糊想法：先机会构想，再用市场、竞品和用户洞察验证。
-- 已有行业、竞品或用户材料：先用 `competitive-intelligence` 整理 Discovery 事实，再生成候选方案。
-- 明确 Bug 或小调整：不走完整 Discovery，直接进入 hotfix / tweak。
-
----
-
-## 市场分析
-
-### 数据源
-- 行业报告、上市公司财报、政府数据、投资机构研报
-
-### 产出物
-- 市场总览报告 / 规模与增长预测 / 趋势洞察
-
----
-
-## 竞品分析
-
-推荐优先使用 `competitive-intelligence`，把公开证据、事实 / 推断、置信度和 Spec 输入分开记录。竞品分析结论只能作为 Discovery / Spec 输入，不能直接冻结为需求。
-
-### 分析维度
-产品功能 / 用户体验 / 技术能力 / 商业模式 / 用户口碑 / 市场表现
-
-### 产出物
-- 竞品情报简报 / 竞品功能矩阵 / 竞品深度分析 / 差异化机会清单 / 产品功能指引输入
-
----
-
-## 用户洞察
-
-### 数据源
-- 应用商店评论 / 社交媒体 / 客服社区 / 行业报告
-
-### 产出物
-- 用户画像 / 用户旅程地图 / 痛点优先级清单
-
----
-
-## Discovery 收敛产物
-
-Discovery 的结论用于影响 Spec、功能架构、产品设计、API 和架构阶段，但不替代这些阶段的正式产物。
-
-- 机会说明。
-- MVP 范围和非目标范围。
-- 产品功能指引 / 能力候选地图。
-- 下游影响清单：UI、API、数据、权限、外部系统、发布回滚和风险 / 回滚约束。
-
----
-
-## 商业论证
-
-### AI Agent 任务
-```python
-delegate_task(
-    goal="基于市场分析和竞品分析，生成商业论证草案",
-    context="""
-    输出：机会陈述 / 目标用户群 / 价值主张 / 商业模式 / 核心指标 / 风险评估
-    """
-)
-```

package/template/docs/discovery/reports/agent-governance-options.md

@@ -1,71 +0,0 @@
-# Agent Skill 治理升级决策分析
-
-## 结论摘要
-
-1. 逐技能结构 / 路由 / 行为 eval 不作为 YSS 模板首个升级方向。结构和路由已有确定性校验；行为 eval 成本高、易重复生命周期门禁，应降为后续按变更和风险触发的试验性能力。
-2. invocation metadata 进入 `yss-skill-registry.yaml`；实现合同编译器 合同只定义字段 schema、解析和阻断规则，不复制每个 skill 的示例。trigger examples 进入注册表，但保持少量、结构化、只为消歧服务。
-3. freshness audit 作为生命周期完成条件的 core 能力，不新建一个常驻通用 skill；Doubt-Driven 作为高风险条件触发的 core 路由策略；Wayfinder 保持 maintainer-only / 兼容入口的可选模式，不进入默认 core 路由。
-
-## Q1：eval 是否为首个升级方向
-
-### 现状事实
-
-- 技能身份、层级、成熟度、别名、默认可发现性和来源投影已经由 [`yss-skill-registry.yaml`](../../agents/yss-skill-registry.yaml)、[`skill-registry.mjs`](../../../scripts/lib/skill-registry.mjs)、`sync-skills` 和 `skills-lock.json` 共同校验。
-- 生命周期路由和 实现合同编译器 已经对未登记技能、依赖闭包、原型独立评审、代码审查唯一入口等关键路由做确定性检查。
-- 生命周期完成已经要求 fresh verification、证据可读、阻断信号清空和 stale / drift 重路由。
-
-### 决策
-
-不把“每个 skill 三层 eval”作为 P0。采用以下顺序：
-
-| 层次 | 初始策略 | 原因 |
-|---|---|---|
-| 结构 | 继续使用现有静态 / schema 校验 | 成本最低，收益已覆盖大部分缺陷 |
-| 路由 | 只对注册表、实现合同编译器、生命周期变更做确定性增量校验 | 与现有门禁直接对齐，避免重复运行 |
-| 行为 | P2 试验；只覆盖变更中的 core / 高风险 skill | 避免全量运行导致 token 和维护成本失控 |
-
-行为 eval 的进入条件应是：skill 内容或路由发生变化、命中高风险影响、或出现真实 finding；退出条件是连续真实任务证明它能发现现有静态校验抓不到的问题，且没有形成第二套生命周期门禁。
-
-## Q2：invocation metadata 与 trigger examples 的归属
-
-### 决策
-
-- **注册表**是技能级调用元数据的唯一事实源：调用模式、触发条件、排除条件、主要输出、依赖和少量 trigger examples 均放在这里。
-- **实现合同编译器 合同**定义 schema、解析顺序、依赖闭包和阻断规则；不复制每个技能的完整示例，避免注册表与 实现合同编译器 漂移。
-- **生命周期编排合同**继续保留工作单元级 `workflow_reference.invocation_mode`（例如 `model-invoked` / `reference`）。它描述一次工作单元如何被执行，不与注册表的 `user` / `model` / `both` 技能级模式混用。
-
-### trigger examples 约束
-
-- 仅为消歧提供 1–3 个正向示例，必要时提供反向排除示例。
-- 示例优先使用 `impact:<name>`、显式用户入口或工作单元 ID 等稳定标识；长篇自然语言放入 skill reference，不放在注册表核心字段。
-- specialist 技能可继承 `impacts` 触发条件；只有存在歧义时才增加显式 examples。
-- examples 只影响发现和路由提示，不直接批准门禁、Ticket 状态或 `ready-for-agent`。
-
-当前已落地的低成本基础见 [`yss-skill-registry.yaml`](../../agents/yss-skill-registry.yaml) 的 `invocation_contract`，以及 [`compiler-contract.yaml`](../../.agents/skills/yss-implementation-contract-compiler/references/compiler-contract.yaml) 的合同字段。
-
-## Q3：三项能力的路由层级
-
-| 能力 | 推荐层级 | 具体落点 | 不应做什么 |
-|---|---|---|---|
-| freshness audit | core 能力 | 生命周期完成条件、候选快照、fresh verification、stale / drift 检查 | 不再新增一个对所有任务常驻的通用审计 skill |
-| Doubt-Driven | core 条件路由 | 实现合同编译器 / 工程基线 / 架构与契约审查中的高风险分支 | 不升级为所有低风险任务的默认步骤，不新建生命周期阶段 |
-| Wayfinder | maintainer-only / 兼容入口的可选模式 | 超长、多 Agent、多会话或 frontier 不清晰时，完成后回 `handoff → to-spec` | 不改变阶段、门禁、Ticket 角色或 `ready-for-agent` |
-
-### Doubt-Driven 的高风险触发器
-
-API schema、数据库 schema / 迁移、跨仓库契约、发布 / 回滚、实际改变的认证授权 / 租户 / 敏感数据行为，以及生命周期或生成语义。反证记录进入既有决策、架构、契约或发布审查记录；缺反证、证据不足或残余风险未处理时阻断。
-
-### freshness audit 的边界
-
-freshness 是“完成结论可信度”的 core 约束，而不是新的工作单元。模板维护继续使用 L1/L2/L3 checkpoint；产品切片继续使用 Slice Contract 和候选快照。这样可以复用同一条 finding 闭环，不增加每次调用的上下文负担。
-
-## 证据来源
-
-- [YSS skill registry](../../agents/yss-skill-registry.yaml)
-- [Skill registry validator](../../../scripts/lib/skill-registry.mjs)
-- [YSS 实现合同编译器 contract](../../.agents/skills/yss-implementation-contract-compiler/references/compiler-contract.yaml)
-- [Slice Implementation Contract](../../.agents/skills/yss-implementation-contract-compiler/references/slice-implementation-contract.md)
-- [Lifecycle orchestration contract](../../.agents/skills/yss-product-lifecycle/references/orchestration-contract.yaml)
-- [Harness process tailoring](../../process/harness-process-tailoring.md)
-- [Addy Osmani agent-skills](https://github.com/addyosmani/agent-skills)
-- [Matt Pocock skills](https://github.com/mattpocock/skills)

package/template/docs/discovery/templates/discovery-template.md

@@ -1,94 +0,0 @@
----
-pipeline: <feature-id>
-stage: discovery
-status: draft
-owner: ai
----
-
-# <功能名称> Discovery 收敛文档
-
-> 适用场景：机会探索、竞品分析或用户材料已经有初步输入，需要收敛为 Spec 上游事实。
-> 本文回答“为谁、为什么、第一版做什么、不做什么、如何判断成功、产品能力往哪里建设、后续可能影响哪些设计资产”，不替代 Spec、业务架构、功能架构、OpenAPI 或系统 / 数据架构。
-
-## 1. 输入材料
-
-| 材料 | 路径 / 链接 | 状态 | 备注 |
-|------|-------------|------|------|
-| 机会想法 / 用户反馈 |  |  |  |
-| 竞品 / 市场分析 |  |  |  |
-| 现有系统 / 业务材料 |  |  |  |
-| 约束 / 决策 |  |  |  |
-
-## 2. 目标用户与场景
-
-| 用户 / 角色 | 核心场景 | 当前痛点 | 影响范围 |
-|-------------|----------|----------|----------|
-|  |  |  |  |
-
-## 3. 问题与机会
-
-- 问题陈述：
-- 为什么现在做：
-- 差异化机会：
-- 不做的机会：
-
-## 4. MVP 边界
-
-| 能力 | 是否进入 MVP | 理由 | 成功信号 |
-|------|---------------|------|----------|
-|  | 是 / 否 / 待定 |  |  |
-
-## 5. 非目标范围
-
-| 非目标 | 排除原因 | 后续观察条件 |
-|--------|----------|--------------|
-|  |  |  |
-
-## 6. 产品功能指引 / 能力候选
-
-> 本节用于给 Spec 和功能架构输入方向，不冻结最终功能架构或技术系统方案。
-
-| 能力候选 | 用户价值 | 优先级假设 | 是否进入 MVP | 证据 / 依据 | 下游影响 |
-|----------|----------|------------|---------------|-------------|----------|
-|  |  | P0 / P1 / P2 | 是 / 否 / 待定 |  | UI / API / 数据 / 权限 / 架构 |
-
-## 7. 下游影响清单
-
-> 只记录影响信号和待验证假设；具体方案在 Spec、产品设计、API、系统 / 数据架构和设计审查阶段收敛。
-
-| 影响域 | 是否可能影响 | 说明 | 需要进入的后续门禁 |
-|--------|--------------|------|--------------------|
-| 页面 / 交互 | 是 / 否 / 待定 |  | 产品设计 / Prototype Review |
-| OpenAPI / 契约 | 是 / 否 / 待定 |  | API 影响分析 / 契约草案 |
-| 数据模型 / 持久化 | 是 / 否 / 待定 |  | 数据架构 / Design Review |
-| 外部系统 / 集成 | 是 / 否 / 待定 |  | 系统架构 / ADR |
-| 发布 / 回滚 / 运维 | 是 / 否 / 待定 |  | 系统架构 / Release Review |
-| 高风险变更 / 人工确认项 | 是 / 否 / 待定 |  | 人工确认项 |
-
-## 8. 成功标准
-
-| 指标 / 结果 | 目标 | 验证方式 |
-|-------------|------|----------|
-|  |  |  |
-
-## 9. 风险与待澄清
-
-| 风险 / 问题 | 影响 | 处理方式 | 截止点 |
-|-------------|------|----------|--------|
-|  |  |  | Spec 前 |
-
-## 10. 完成标准
-
-- [ ] 目标用户、痛点、为什么现在做已经明确。
-- [ ] MVP 和非目标范围可直接输入 Spec。
-- [ ] 产品功能指引已经形成能力候选和优先级假设，但未替代正式功能架构。
-- [ ] 下游 UI、API、数据、权限、架构、安全影响信号已列出。
-- [ ] 成功标准可验收。
-- [ ] 业务架构需要的用户旅程、价值流、角色 / 外部系统线索已列出。
-- [ ] 需要回写 `CONTEXT.md` 的术语已标注。
-
-## 11. 下一步门禁
-
-- 结论：Approved / Blocked
-- 下一步：业务架构 / Spec / 继续 Discovery
-- 阻断项：