@namewta/speculo 1.0.24 → 2.0.1

package/template/workflows/specdev/P-goal-plan/references/replan-and-recovery.md

@@ -1,21 +0,0 @@
-# 重规划、旧票升级与恢复
-
-## 失效范围
-
-导致公共行为、接口、数据、安全、范围、验收或输出数量改变的事实，回到相应上游 owner 决定。记录旧摘要、新摘要、原因、用户决定和受影响票。沿真实依赖边计算失效闭包；同一 change 的 Spec 改变会使相关票重新核对，不能从旧 map 覆盖子合同。独立 change 未受影响的票继续。
-
-父计划沿用 `revision` 与 `source_map_revision`；单 change 新版 map 用 `plan_revision`。先保留旧证据，再生成新活动投影；不能回写旧记录伪装为原先就已批准。
-
-## 旧票升级
-
-既有 v3 Ticket/Map 保持可读；已完成或已归档票不追溯改写。下一次执行未完成旧票前：
-
-1. 核验归属、当前工作树与未闭合事务；保留原文件备份和摘要，不碰其他任务。
-2. 先读取票的背景和验收，扫描真实项目 Skill 入口，补充 `plan_contract_version: 1`、`skill_scan`、`skill_bindings`、`resource_claims` 与调用/停止章节。
-3. Map 补充版本、用户交付数量及其确认记录、控制入口；已有字段和默认行为保持。
-4. 重新执行 T 的 Ready 与计划审查，再运行 tickets 校验。用户指定数量、权限、默认工具或集成策略变化必须明确批准；不能默默“升级”权限。
-5. 从备份与变更清单恢复应只覆盖本任务实际改动，保留原软链接和元数据。任何失败只阻塞受影响票，不将整个 Goal 判为完成。
-
-## 恢复动作
-
-读取而非重建检查点；确认 HEAD、source commit、parent result、Evidence 和 owner。已提交未集成、已执行迁移未验证、已开始正式记忆事务等状态只通过原流程恢复。未知归属或缺少恢复证据时不自动撤销、不解锁、不重试不可逆动作；报告人工恢复要求。

package/template/workflows/specdev/P-goal-plan/references/single-change-plan.md

@@ -1,151 +0,0 @@
-# 目标规划
-
-
-Goal Plan 只拥有单个 Ticket 无法独立决定的事情：整体 Outcome、跨 Ticket 顺序与并发、共享所有权、里程碑 Gate、动态派单边界、父分支集成、迁移/发布顺序、偏差升级和恢复。Ticket 继续拥有局部实现合同。
-
-每次 Goal Plan 都采用 `lead-directed`：当前主会话是唯一 Lead，负责计划、SpecDev 状态、Evidence、派单、验收、父分支推进和最终回复。形成 Goal Plan 时，用户尚未明确才询问是否开启 worktree 开发，默认不开启；选择写入当前 Goal Plan，不修改全局配置。不开启时 Ticket 严格串行，允许动态派遣 implementation subagent，但同一时间只有一个 implementation owner 可写当前 workspace；开启时沿用每 Ticket 独立 worktree 与 candidate-merge。
-
-产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
-
-
-## 何时运行
-
-满足任一条件时运行：
-
-- 多个 Ticket 可以或需要并行；
-- 存在 shared path、共享合同或集中 owner；
-- 存在 Deep Ticket、expand-contract、迁移、兼容窗口或不可逆步骤；
-- 存在多个 Gate、外部审批、发布窗口或高事故半径；
-- Ticket DAG 的关键路径、汇合点或恢复策略无法由 Tickets Map 安全表达；
-- 用户明确要求正式跨 Ticket Plan。
-
-少量、线性、低风险的 Ready Tickets 可以不生成厚重编排正文，但执行前仍要有最小 Goal Plan 记录 workspace、Lead、Gate 和授权引用；不得引用不存在的当前 Goal Plan。没有 Ticket 的获批小型 Direct Spec 不受 Ticket workspace 合同约束；一旦需要切片，先运行 T-tickets。
-
-## 输入
-
-必须读取：
-
-- `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>`：先枚举 Ticket 入口的 frontmatter、依赖和状态，按 DAG、路径和风险定位需要完整读取的 Ticket。
-- `<Path>{roots.state}/specdev/config.json</Path>`
-
-按存在情况读取：
-
-- 当前 change 架构决策：`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
-- 当前 change 领域上下文：`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
-- 当前 change 设计日志：`<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`
-- 当前 change 诊断：`<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>`
-- 永久架构决策：`<Path>{roots.state}/specdev/adr/</Path>`
-- 永久领域上下文：`<Path>{roots.state}/specdev/context/</Path>`
-- 用户提供的合同、标准、参考实现、环境限制、发布窗口和批准策略。
-
-非当前分支的 ADR、CONTEXT、LOG、Diagnosis、Evidence、研究资料和永久目录先通过索引、状态和关键词定位；只有被当前 Gate、依赖、冲突或恢复条件命中的条目才回读原文。Tickets Map、当前计划和决定 DAG 的 Ticket frontmatter 是权威编排输入，仍需完整读取。
-
-永久目录可以为空，静默继续。缺少 Spec 或 Tickets Map 时返回 `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>` 或 `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>`；当前 ADR/CONTEXT 缺失且规划依赖对应决定时返回 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>`，不在 Goal Plan 中补造上游权威。
-
-## 流程
-
-### 1. 验证上游与执行边界
-
-加载 `<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`：
-
-1. 验证 Spec、Tickets、合同覆盖、DAG、路径所有权和待执行 Deep Ticket 完整性；未来 draft 票按规划输入门记录局部缺口；
-2. 只读探索影响调度的代码与项目事实；
-3. 识别 migration、high-assurance、reference-conformance、release-coordination 等适用模式；
-4. 从 config 读取 `max_implementation_agents` 与 `max_integration_attempts`，将实际值快照到 `implementation_agent_limit` 与 `integration_attempt_limit`；本计划可以降低但不得超过 config 或平台能力，Lead 不计入；
-5. 根据 workspace 策略记录实现 commit 与 direct-parent/candidate integration 授权事实；缺失时仍可完成 plan 文档，但 ready_for_execution 保持 false，并列为 run 的阻塞条件；
-6. 只询问无法发现且会改变 Gate、Wave、owner、迁移、批准或验收的问题。
-
-**完成标准**：计划内 Ticket、范围、覆盖、DAG 与所有权完整；未来 draft 票已记录真实缺口、生产者证据和 DoR 重审条件；Lead、授权状态、实现并发上限和父分支可判定。缺执行授权时可交付规划，但 `ready_for_execution` 保持 `false`。
-
-### 2. 构建 Outcome、DAG、Wave 与 Gate
-
-加载 `<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`：
-
-1. 压缩 Outcome、成功/伪完成、非目标和权威来源；
-2. 从 Ticket frontmatter 构建 DAG、关键路径、扇出与汇合点；
-3. 为 shared path、共享合同和集中修改指定唯一 owner；
-4. 将依赖满足且项目写路径不相交的 Ticket 分入 Wave；current 模式仍按依赖顺序串行执行，不得把 Wave 当作并发授权；
-5. 为合同稳定、垂直路径、迁移完成、发布就绪等状态定义 Gate；
-6. 为每个 Ticket 记录开始条件、workspace 策略、验证层级、Evidence 目标、集成顺序和失败恢复。
-
-**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个 Ticket 有唯一项目写 owner、worktree 合同和可验证集成出口。
-
-### 3. 固定 Lead 编排与动态派单合同
-
-加载 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.md</Path>`，并以 `operation=plan` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`：
-
-1. 固定 Lead 的可恢复 owner/session locator；
-2. 声明 implementation subagent 的 config/平台约束上限，Lead 不计入；
-3. 不为只读 review/research/test-observation agent 写 SpecDev 数字上限；
-4. current 模式固定只有一个 implementation writer 写项目路径，Lead 仍是唯一 SpecDev 工件与状态写入者；required 模式 implementation owner 写自己的 Ticket worktree；
-5. 定义执行期动态 Dispatch Packet、候选返回和 Lead 验收；
-6. provider、模型和具体派单在 Ticket 开始时按事实选择，不在 Goal Plan 中预分配。
-
-**完成标准**：Lead 可以在恢复后重建派单边界；任何 subagent 都不能成为第二个 SpecDev 状态写入者或父分支 integration owner。
-
-### 4. 定义完成、证据与恢复
-
-加载 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`：
-
-1. 定义整体 Definition of Done 和每个 Gate 的关闭证据；
-2. 固化不可协商约束与允许的局部实现自由；
-3. 按 workspace 策略为每个 Ticket 明确 current-workspace/direct-parent 检查或 source-worktree/parent-candidate 检查；
-4. E2E 按 Ticket 实际跨边界风险标记 required 或 not-required；
-5. 定义 direct-parent 验证失败、candidate 冲突/失败、父 HEAD 漂移、偏差、暂停、批准和恢复动作；
-6. 定义 change 完成、远程 reconcile、残余风险和回滚要求。
-
-**完成标准**：每个完成声明映射到不可变 commit、候选/父分支 SHA、命令、Evidence 或人工批准。
-
-### 5. 写入、同步与验证
-
-使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写入 Goal Plan：
-
-1. 只保留适用 planning modes，不创建条件性 topology addendum；
-2. 将 Wave、Gate 和 owner 投影同步到 Tickets Map；
-3. 对照 `<Path>{roots.workflows}/specdev/common/schemas/goal-plan.schema.json</Path>`；
-4. 运行：
-
-```bash
-node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
-  --stage goal-plan \
-  <Path>{roots.state}/specdev/changes/{change}</Path>
-```
-
-5. 原子更新 Goal Plan、Tickets Map、全局/current change 状态并重新读取；
-6. 向用户报告 Outcome、关键路径、Wave/Gate、Lead、实现 agent 上限、shared owner、E2E disposition、迁移与主要风险；
-7. 未经用户要求，不自动进入实现。
-
-## 决策完备标准
-
-每份 Goal Plan 必须让 Lead 无需重新决定：
-
-- Outcome、权威来源和整体完成；
-- 跨 Ticket 先后、Wave、Gate 和关键汇合点；
-- shared path 与共享合同 owner；
-- implementation subagent 上限及动态派单边界；
-- 每 Ticket workspace、implementation commit、对应验证和父分支推进规则；
-- E2E disposition、偏差、暂停、批准和恢复路径。
-
-Goal Plan 不复制 Ticket 的局部施工路线、全部文件预测或逐项验收清单。
-
-## 完成标准
-
-- Goal Plan schema v6 且 `ready_for_execution` 与状态一致；
-- 规划完成与执行就绪分别报告；允许交付 `draft / ready_for_execution: false`，单 change 不创建父 Implementation Map/Plan；
-- 等待上游产物的未来票保持 draft，局部缺口只阻塞依赖闭包；进入执行的票必须重新通过 DoR，上游完成不自动提升 Ready；
-- Lead 唯一，implementation subagent 上限来自 config/平台能力，review/research agent 不受 SpecDev 数字限制；
-- 每个实现 Ticket 都有 workspace、commit、对应 integration gate 和 Evidence 出口；
-- current 模式不创建 source/candidate worktree，适用 E2E 由 Lead 在 current workspace 运行；required 模式保持 source/parent-candidate 边界；
-- 计划只保留当前固定 Lead 与选定 workspace/integration 合同；
-- validator 无 error，Tickets Map 投影同步，用户收到下一步选择。
-
-## 子文件引用
-
-- 规划模式与输入门禁：`<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`
-- DAG、Wave、Gate 与集成队列：`<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`
-- Lead 与动态派单：`<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.md</Path>`
-- 完成、证据与恢复：`<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`
-- Goal Plan 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
-- Agent 交付合同：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`

package/template/workflows/specdev/P-prototype/P-prototype.md

@@ -1,53 +0,0 @@
----
-id: specdev/prototype
-type: workflow-entry
-workflow: specdev
-name: 逻辑与 UI 原型
-description: 按需验证离线逻辑模型，或检测现有项目的 UI 事实，按产品任务推荐并逐步选择设计风格，生成持久化设计系统文档、多风格 HTML 对照和可运行 HTML/CSS/JS 原型。
-keywords: [prototype, UI 原型, 风格检测, 设计系统, HTML, CSS, 交互, design tokens]
----
-
-# 逻辑与 UI 原型
-
-> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
-
-本 Work 的主导词是**设计定向**：先从项目事实识别现状，再让用户看到基于功能而非流行色推荐的候选，最后把选择固化为既可阅读又可运行的 UI 设计包。P 不修改生产 UI；后续 S、Tickets 和 I 以设计包为视觉与交互权威。
-
-激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
-
-## 分支选择
-
-逻辑/状态/规则验证读取 <Path>{roots.workflows}/specdev/P-prototype/logic-protocol.md</Path>，跳过下方 UI 专属步骤。UI 仍默认离线持久化，默认 3 个、最多 4 个方案。只有用户明确要求项目内预览时读取 <Path>{roots.workflows}/specdev/P-prototype/project-preview-protocol.md</Path>；其临时写集与清理由该分支管理，下方 UI 设计权威与离线交付保持。
-
-## 交互和逻辑状态
-
-按项目风险验证正常、空、加载、失败、取消、重试、权限不足和恢复状态。复用既有 token/组件；主题、窗口边缘、响应式、键盘、focus、遮挡与可访问性均由真实项目需求决定，不搬 DSH 视觉常量。失败反馈遵守 <Path>{roots.workflows}/specdev/common/rules/error-handling.md</Path>，提示与有效数据有明确生命周期。原型只证明原型路径，不冒充生产或真实 API 验收。
-
-## 输入与所有权
-
-- 必需输入：目标项目或新产品设想、核心用户任务，以及当前 SpecDev change。
-- 可选输入：现有代码、页面、截图、设计 token、品牌约束、ADR、Spec、调查和用户明确给出的参考产品。
-- 项目事实权威：依赖清单、样式源码、组件实现、路由、真实页面、测试和可复现截图；仅凭依赖名称不得断言实际风格。
-- 用户决定权威：产品方向、候选风格、密度、色调、字体气质、圆角、交互反馈和跨端优先级。
-
-P 拥有 `<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/</Path>`。其中 `design-id` 使用当前 change 内最小未占用的 `UI-NNN`；目录中的设计系统主文档是唯一设计权威，comparison 和 final 文件均由它或其中已记录的候选决定派生。P 不写永久 research namespace，不创建 branch/worktree，不提交生产代码。
-
-## 流程
-
-1. **创建或恢复设计包**：读取 change 与 `<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/design-system.md</Path>`。不存在时从 `<Path>{roots.workflows}/specdev/P-prototype/design-system-template.md</Path>` 创建，写入 `status: detecting` 并原子重读；存在时只询问尚未确认的高影响选择。
-2. **检测现有风格**：加载 `<Path>{roots.workflows}/specdev/P-prototype/detect-existing-style.md</Path>`，穷尽技术栈、布局、视觉 token、组件状态、响应式与可访问性证据。新项目明确记录 `project_kind: new`，不伪造检测结果。
-3. **建立功能候选**：读取 `<Path>{roots.workflows}/specdev/P-prototype/design-library/INDEX.md</Path>`，依据产品任务、平台和信息密度从八种风格及六种布局中推荐 2-4 个候选。每个候选写明适合原因、需要保留/调整/替换的现有事实、参考项目和迁移成本。
-4. **逐项选择并持久化**：加载 `<Path>{roots.workflows}/specdev/P-prototype/style-selection-protocol.md</Path>`。每轮只处理一个决策层；每个答案立即写回设计系统主文档并重读。高影响偏好未确认时保持 `status: selecting`，不得自行标记 Ready。
-5. **生成可视对照与最终原型**：加载 `<Path>{roots.workflows}/specdev/P-prototype/generate-design-package.md</Path>`。为每个候选生成独立 comparison variant，再生成 comparison 索引。用户确认或明确组合后，把最终 HTML/CSS/JS 作为具名代码块写入设计系统主文档，再物化到 final 目录。
-6. **验证并封板**：运行 `<Path>{roots.workflows}/specdev/P-prototype/tools/materialize-prototype.mjs</Path> --check` 和 `<Path>{roots.workflows}/specdev/P-prototype/tools/validate-design-package.mjs</Path>`；随后运行 SpecDev `--stage prototype`。对照 `<Path>{roots.workflows}/specdev/P-prototype/design-package.schema.json</Path>`，全部通过且选择闭合后设置 `status: ready`，更新 `works_run` 并清空 `current_work`。缺少项目事实或用户决定时设置 `blocked` 并保留恢复位置。
-7. **返回路由**：返回设计包、comparison 和 final 的完整路径、验证命令与结果、未决问题和下一 Work。需要补足产品决定时返回 G；需要写外部行为合同返回 S；需要拆实施工作返回 Tickets；已有 Ready Ticket 才返回 I。Wayfinder 调用时只把设计包与 comparison locator 写入对应 solution comment。
-
-## 完成标准
-
-- 现有项目的检测结论逐项有项目相对证据；新项目明确没有既有风格。
-- 候选由功能、平台和密度推导，不只更换颜色；用户已看到每个候选的独立 HTML。
-- 设计系统主文档完整包含 UI 结构、CSS token、交互 JS 和最终 HTML 源码，并记录研究出处与拒绝理由。
-- comparison 索引可导航到 2-4 个候选，final HTML 可离线运行；桌面与移动宽度不存在空白、遮挡或无意横向溢出。
-- 字体、间距、圆角、色彩、层级、控件状态、异步反馈、响应式、键盘、focus 和 reduced motion 均有明确合同。
-- Markdown 代码块与 `final/` 文件逐字一致，schema、局部校验和 SpecDev stage 校验全部通过。
-- 设计包不包含机器绝对路径、敏感值、生产数据写入、发布动作或未授权的生产实现。

package/template/workflows/specdev/P-prototype/design-library/INDEX.md

@@ -1,43 +0,0 @@
-# P-prototype 设计库
-
-本目录是 P-prototype 的静态设计参考层。它帮助 UI 原型先按任务、对象、密度和平台选择结构，再选择视觉表达；它不拥有运行时状态，不替代项目现有设计系统，也不授权修改生产代码。
-
-研究快照固定在 commit `49b565913c52f4867456e609696625157f19b930`。快照是证据与可运行样板，不在原型过程中原地修改；需要复用时，把所需 HTML/CSS/JS/图片和 attribution 复制到当前 change 的设计包。
-
-## 渐进披露入口
-
-| 当前问题 | 读取 | 读完应得到 |
-|---|---|---|
-| 先决定信息架构、密度和组件边界 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/foundations.md</Path>` | 一个主布局范式、密度档和设计系统边界 |
-| 在八种可运行风格中选择起点 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/style-index.md</Path>` | 一个主风格、必要时一个受控对照风格 |
-| 寻找相似产品及其真实模式 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/product-pattern-index.md</Path>` | 对应项目、可借鉴模式和一手研究路径 |
-| 定义浅色/深色、语义 token、字号与层级 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/color-and-theme.md</Path>` | 可实现的主题与密度假设 |
-| 设计导航、表格、表单、反馈或危险操作 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/interaction-patterns.md</Path>` | 完整状态和验证动作 |
-| 需要窄屏、触屏、桌面/Web/移动重排 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/responsive-and-platforms.md</Path>` | 每个平台的任务职责和断点行为 |
-| 需要引用、复制资产或判断证据强度/许可 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-provenance.md</Path>` | 可追溯来源、复用边界和 attribution |
-
-## 使用顺序
-
-1. 检测现有项目或明确新产品设想，并列出核心对象、最常见的 3-5 个任务、目标输入设备和最坏数据状态。
-2. 读取 foundations，选择一个主布局范式。不要先按品牌色、圆角或流行风格选择页面。
-3. 读取 style-index，按功能推荐 2-4 个结构不同的候选，并为每个候选生成独立 comparison HTML。
-4. 读取 product-pattern-index，只深入与当前对象、任务或平台相似的项目研究；星标不构成设计质量或许可结论。
-5. 只加载当前问题涉及的 theme、interaction 或 responsive 文件。精确值必须能回到 snapshot 中的 token、CSS 或研究证据。
-6. 复制样板时保留相对目录关系和所需 attribution；把 demo 名称、权限、Git、同步与审批状态替换为原型自己的假数据，不把演示逻辑当作真实业务逻辑。
-7. 用真实极端数据、键盘、目标宽度和浅/深主题验证。选择、拒绝理由和最终源码进入设计系统主文档，设计库本身保持不变。
-
-## 快照入口
-
-- 总报告：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/report/OPEN_SOURCE_UI_RESEARCH_2026.md</Path>`
-- 八种风格总览：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/ui-gallery/index.html</Path>`
-- 样板使用说明：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/ui-gallery/README.md</Path>`
-- 结构化项目数据：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/data/projects.json</Path>` 与 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/data/extended-projects.json</Path>`
-- 综合 token：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/reference/design-tokens.css</Path>`
-
-## 完成门
-
-- 选择理由落在任务模型、信息密度、输入设备和状态复杂度，而不是“看起来像”；
-- 一个布局范式和一个主风格已明确，所有新增 token 都有语义角色；
-- loading、empty、no-results、error、offline、read-only、permission 与长文本按适用性逐项处理；
-- 窄屏改变任务流而非压缩桌面多栏；
-- 引用与复制均可回到固定 commit、研究文件和 attribution。

package/template/workflows/specdev/P-prototype/design-library/color-and-theme.md

@@ -1,65 +0,0 @@
-# 色彩、主题与视觉层级
-
-视觉系统先定义角色，再选择色值。固定快照中的 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/reference/design-tokens.css</Path>` 是跨项目综合起点，不是任何单一产品的 token 复制品。
-
-## 最小语义集合
-
-```text
-canvas
-surface-1 / surface-2 / surface-3 / overlay
-text-primary / text-secondary / text-tertiary / text-disabled
-border-subtle / border-default / border-strong
-accent / accent-hover / accent-subtle / accent-contrast
-success / warning / danger / info (+ subtle variants)
-hover / selected / pressed / focus-ring / scrim
-```
-
-业务组件消费语义角色，不直接写 `#fff`、`black` 或任意透明度。品牌 accent 只服务主要动作、选中和链接；状态色必须同时配图标、文本或形状。数据可视化色板、Git diff、syntax highlight 和业务状态分别建组，不复用 UI accent 充当所有含义。
-
-## 浅色与深色
-
-- 两种主题一起设计，不把深色简单反相。深色 overlay 往往比基础表面更亮，边框和语义色需要重新分配明度与对比。
-- 分别检查正文、次要文字、图标、边框、focus ring 和状态，而不只检查按钮。
-- 中性色保持低 chroma，避免所有表面都带强品牌倾向。
-- 用户切换主题时保持布局、选择、输入和面板尺寸；主题改变不应触发内容重排。
-- 高对比需求不能只靠增加饱和度，应重新检查边界、文字与焦点。
-
-## 字体和密度
-
-| 角色 | 字号/行高起点 |
-|---|---|
-| 坐标、元数据、辅助标签 | 11-12px / 16px；不承载长文本、错误原因或主要操作 |
-| 表格、侧栏、紧凑控件 | 13px / 18-20px |
-| 默认 UI 正文与表单 | 14px / 20px |
-| 内容正文 | 15-16px / 24-26px |
-| 小节/弹窗标题 | 16-18px / 22-26px |
-| 页面标题 | 20-24px / 28-32px |
-
-工具界面不使用营销页级大标题。数字表格可启用 tabular numerals，代码/SQL/ID 使用 mono；中英文混排单独验证 CJK 回退和行高。不使用负字距挤压 UI，长名称通过布局、换行或中间截断处理。
-
-| 密度 | 控件高度 | 表格行高 | 典型任务 |
-|---|---:|---:|---|
-| Compact | 28px | 32px | SQL、日志、开发工具 |
-| Default | 32-36px | 36-40px | CRM、项目管理、后台 |
-| Comfortable | 40px | 44-48px | 文档、协作、低频表单 |
-| Touch | 44-48px | 48-52px | 移动与触屏 |
-
-## 圆角、边框与阴影
-
-- 2-4px：代码块、表格小元素、密集工具按钮。
-- 4-6px：输入、按钮、菜单项、紧凑面板。
-- 6-8px：普通卡片、popover、较大控件。
-- 8-12px：dialog、sheet、移动大容器；移动样板可因触屏语言使用更大值。
-- pill：状态徽标、分段选择滑块或真正胶囊语义，不用于所有按钮。
-
-同一视觉层只保留 2-3 个主圆角。常驻页面分区、侧栏、表格和检查器用 1px 边框或背景差建立层级，不用浮卡阴影；popover/menu 使用清晰边框和中等阴影；dialog 使用 scrim 与较大阴影；focus ring 独立于层级阴影。hover、selected、pressed 必须是不同 token。
-
-## 原型验证
-
-- 浅色、深色、200% 缩放和常见色觉差异下，文本与状态仍可区分；
-- 页面没有绕过 token 的随机颜色、圆角和阴影；
-- 状态不只依赖颜色；
-- 最长名称、中文、数字和错误文案不会撑坏控件；
-- reduced motion 时 token 中的 UI duration 降为零或对应交互停止非必要动画。
-
-八种具体 `.theme-*` 实现在 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/ui-gallery/styles/pages.css</Path>`，综合 token 的使用约束在 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/reference/USAGE.md</Path>`。

package/template/workflows/specdev/P-prototype/design-library/foundations.md

@@ -1,66 +0,0 @@
-# 设计基础与六种布局
-
-先按任务模型选择布局，再决定视觉风格。以下结论来自固定研究快照的综合报告；尺寸是原型起点，不是脱离目标用户的硬规范。
-
-## 决策顺序
-
-1. 定义核心对象，以及用户最常做的 3-5 个任务。
-2. 定义对象层级、可恢复 URL、权限和状态模型。
-3. 从六种布局中选择一个主范式，并画出空、错、加载、只读和无权限状态。
-4. 根据任务时长、信息密度和输入设备选择密度档，再定字号、控件高度和面板宽度。
-5. 同时建立浅色与深色的语义 token。
-6. 先建立 primitives，再建立高频 patterns，最后组合页面。
-7. 用真实极端数据、键盘和目标宽度验证。
-
-## 六种高价值布局范式
-
-| 范式 | 适用任务 | 结构与不可丢失的行为 | 代表项目 |
-|---|---|---|---|
-| 全局侧栏 + 页面内容 | 项目管理、CRM、设置、普通后台 | 全局栏只放跨页面稳定对象，页面动作靠近内容头；二级项超过约 5-7 个再引入上下文栏；折叠后保留 tooltip、选中态和持久化状态 | Plane、Twenty、Cal.com |
-| 图标轨 + 上下文侧栏 | 多产品模块、组织或工作区平台 | 图标轨回答“在哪个产品/工作区”，上下文栏回答“范围内有哪些对象”；两层不重复菜单；移动端通常合并为一层 drawer | Supabase Studio、Directus、Mattermost、Paseo |
-| 列表-详情主从 | 客服、邮件、任务、对象浏览、数据库表 | 选择与 URL 同步，宽度可恢复；处理未保存修改、键盘上下移动、空选择、删除落点；窄屏提供列表与详情的明确返回路径 | Chatwoot、Twenty、Open WebUI、CloudCLI |
-| 编辑器/画布 + 检查器 | 设计、白板、SQL、API、低代码 | 主创作面无装饰卡框；工具区和检查器可折叠/调整；快捷键、选择、撤销、缩放和平移属于统一交互模型 | Penpot、Excalidraw、Appsmith、DBX、Hoppscotch |
-| 仪表盘网格 | BI、可观测性、运营概览 | 稳定列系统、拖放手柄、组件最小/最大尺寸；区分编辑/查看；每个 panel 独立呈现无数据、加载和错误 | Grafana、Metabase |
-| 内容中心/文档编辑器 | 知识库、文档、长内容 | 正文限制行长，资源树、目录和评论独立占栏；工具随选择出现；自动保存安静但可确认；低频动作进入斜杠命令或命令面板 | Outline、AFFiNE、AppFlowy、Notesnook、Joplin |
-
-一个原型可以在局部嵌套第二范式，例如“全局侧栏 + 页面内容”中的仪表盘，但必须明确哪个是 shell、哪个只服务当前页面；不要让两套导航或两个检查器竞争同一职责。
-
-## 基础尺度
-
-| 项目 | 建议起点 |
-|---|---|
-| 全局图标轨 | 48-56px |
-| 展开侧栏 | 224-272px |
-| 顶栏 | 44-56px |
-| 右侧检查器 | 288-360px，可调整 |
-| 阅读/表单宽度 | 720-960px |
-| 宽应用内容 | 最多约 1280-1440px；表格、画布、日志和仪表盘使用可用宽度 |
-| 紧凑/默认/触屏控件 | 28-32px / 32-36px / 44-48px |
-| 常用图标 | 14 / 16 / 20px |
-| 主圆角 | 4 / 6 / 8px；更大值留给 dialog、sheet 与触屏容器 |
-
-采用 4px 间距基准，2px 只做视觉校正。图标与文字通常间隔 6-8px，相邻字段 12-16px，表单分组 24-32px，页面区块 32-48px。不要仅靠缩小字体提高密度；先去掉重复标签、合并工具栏并使用渐进披露。
-
-## 工程边界
-
-原型应保持四层逻辑边界，即使暂时没有拆成发布包：
-
-```text
-tokens/       raw scale + semantic roles + themes
-primitives/   button, input, dialog, menu, tooltip
-patterns/     table, filter bar, command palette, inspector
-domain/       注入业务数据、文案、权限与动作
-```
-
-`primitives` 不依赖业务；`patterns` 组合原语但不拥有页面数据；业务层不得绕过 token 散落任意颜色、圆角和阴影。组件库需要薄封装，以固定默认密度、焦点、圆角和 API。
-
-## 原型检查
-
-- 用户能在 5 秒内判断当前位置、作用域和主要动作；
-- 全局、上下文与对象内导航没有重复职责；
-- 画布、表格、正文或消息流是第一视觉信号，而不是装饰卡片；
-- 最长名称、中文、数字、空值和错误文案不会重叠或改变稳定布局；
-- token、primitive、pattern 与领域组件边界可说清；
-- 选择的布局在窄屏有任务重排方案。
-
-更完整的原始论证见 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/report/OPEN_SOURCE_UI_RESEARCH_2026.md</Path>` 第 6-7、11-13 节。

package/template/workflows/specdev/P-prototype/design-library/interaction-patterns.md

@@ -1,61 +0,0 @@
-# 交互模式
-
-原型要呈现完整状态和可恢复行为，而不只展示静态 happy path。以下模式按工具型产品的高频任务组织。
-
-## 导航与状态保持
-
-- shell 在路由切换时保持挂载，侧栏滚动、展开组、面板宽度、筛选和编辑上下文不意外丢失。
-- 选中态同时使用背景、文字/图标对比和位置线索；breadcrumb 只表达层级，不替代明确返回动作。
-- 深层对象提供可复制 URL；刷新后尽量恢复选择、筛选和视图。
-- 列表-详情必须定义空选择、删除当前对象后的落点、未保存修改处理和窄屏返回路径。
-
-## 搜索、命令与快捷键
-
-命令面板服务跨模块跳转、低频动作和主题/设置切换；当前列表的局部搜索仍放在对象附近。命令项包含分组、最近使用、键盘导航、不可用原因和快捷键提示。不要把所有能力藏进 `Cmd/Ctrl+K`。
-
-## 数据表格与网格
-
-按原型问题逐项决定并呈现：
-
-- 列显示/隐藏、排序、筛选、调整宽度和固定列；
-- 行选择与批量动作，批量工具条只在有选择时出现；
-- 虚拟滚动和键盘导航，编辑态不因滚动丢失；
-- 空值、布尔、长文本、代码、日期、时区和大数字格式；
-- loading、无数据、无结果、局部错误和无权限分别建模；
-- 危险写操作展示预览、影响范围、只读或事务提示。
-
-## 表单与保存
-
-- 创建流程有明确主要动作和取消路径；提交后错误与字段程序化关联并可快速定位。
-- 设置页选择“显式保存”或“可靠自动保存 + 可见状态”，不混用而不说明。
-- 长表单按领域分组，标签位置一致；帮助文字解释决策，不重复标签。
-- 危险设置独立成区；只有高损失、不可逆操作才要求输入对象名确认。
-
-## 异步反馈
-
-| 时长 | 反馈 |
-|---|---|
-| 约 100ms 内 | 通常不显示 loading，避免闪烁 |
-| 约 100ms-1s | 按钮局部进度或轻量 skeleton |
-| 1s 以上 | 持续进度、取消能力或后台任务入口 |
-
-Toast 只承载非阻塞确认，不承载必须阅读的错误修复步骤。错误说明发生了什么、影响什么、下一步是什么，并保留用户输入。离线、只读和权限不足不是通用 error 的文案变体，应各有可行动状态。
-
-## 危险操作与撤销
-
-能撤销时优先“执行后短时撤销”；真正不可逆或影响范围不明显时才用 confirmation dialog。按钮写具体动作和范围，例如“删除 12 条记录”，不用“确定”。审批流程同时呈现请求对象、能力边界、允许范围、拒绝路径和可见结果。
-
-## 画布、编辑器与可调面板
-
-- 选择、撤销、缩放、平移和快捷键由统一模型管理；上下文工具随选择出现。
-- 可调 panel 有最小/最大尺寸、键盘或替代控制、持久化和重置路径。
-- 画布型产品为核心对象和操作提供非纯画布的可访问替代路径。
-- 代码/diff/terminal/preview 的 tabs 或 panes 保持稳定尺寸，loading、长标签和状态图标不引起布局跳动。
-
-## 完整组件状态
-
-Button、IconButton、Link、Input、Textarea、Select/Combobox、Checkbox、Radio、Switch、Tooltip、Menu、Popover、Dialog、Drawer/Sheet、Tabs、Toast、InlineAlert、Skeleton 和 EmptyState 至少覆盖适用的 `default / hover / pressed / focus / disabled / loading / error / selected`。工具产品再按问题补 AppShell、Sidebar、CommandPalette、DataTable、FilterBar、ResizablePanel、Inspector、Tree、CodeEditor wrapper 和 PermissionGate。
-
-## 样板验证证据
-
-快照的 Playwright 测试验证九个页面在 390x844 下无横向溢出、Lucide 与图片加载、主题和 token drawer 可交互，以及移动审批产生可见结果：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/ui-gallery/tests/gallery.spec.js</Path>`。复制样板后，用原型自己的状态和任务补充测试，不把这组检查当作生产验收。

package/template/workflows/specdev/P-prototype/design-library/product-pattern-index.md

@@ -1,73 +0,0 @@
-# 38 个产品模式映射
-
-本索引覆盖 snapshot 中 19 个基础项目、8 个 Claude Code 客户端和 11 个多端个人应用。映射用于找到相似约束和进一步阅读入口，不是统一评分、设计排名或许可建议。
-
-## 研究入口
-
-- D：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/research/data-dev-tools.md</Path>`
-- P：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/research/productivity-collaboration.md</Path>`
-- C：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/research/creative-ai-communication.md</Path>`
-- A：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/research/claude-code-modern-clients.md</Path>`
-- M：`<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/research/personal-multiplatform-apps.md</Path>`
-
-结构化事实源是 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/data/projects.json</Path>` 和 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/data/extended-projects.json</Path>`。
-
-## 基础项目（19）
-
-| 项目 | 核心布局/产品模式 | 最适合借鉴 | 入口 |
-|---|---|---|---|
-| Supabase Studio | 产品轨 + 模块侧栏 + 数据工作区 | 设计系统分层、数据工具 shell、语义颜色 | D |
-| Grafana | 顶栏 + 可停靠菜单 + 仪表盘画布 | 主题契约、密集 dashboard、插件化 UI | D |
-| Metabase | 应用栏 + 集合侧栏 + 查询/仪表盘 | 低门槛分析、主题封装、命令面板 | D |
-| DBeaver Community | 对象树 + 多标签编辑器 + 辅助视图 | 极高密度桌面工作台、上下文命令 | D |
-| Directus | 模块轨 + 集合导航 + 多布局 + 侧栏 | schema 驱动界面、扩展点、多视图 | D |
-| Appsmith | 实体树 + 画布 + 属性面板 + 调试器 | 低代码编辑器、检查器、调试反馈 | D |
-| DBX | 连接树 + tabs + 编辑/数据区 + 工具面板 | 轻量现代桌面端、可调多窗格、AI/MCP | D |
-| Plane | 可调侧栏 + List/Kanban/Gantt + 详情 | 同一数据多视图、peek 侧栏、高效工作台 | P |
-| AppFlowy | 插件式 workspace + 文档/数据库视图 + 原生响应式导航 | local-first、真正跨端、移动任务重排 | P |
-| Twenty | 表格/管道 + 记录侧面板 + 移动导航首页 | 元数据驱动业务 UI、对象表、记录面板 | P |
-| Cal.com / Cal.diy | 管理配置 shell + 独立公开预约流程 | 后台与客户界面分离、预约表单、品牌定制 | P |
-| Outline | 文档树 + 聚焦编辑器 + 情境协作工具 | 低干扰写作、树导航、命令栏 | P |
-| AFFiNE | Page/Edgeless 双模 + 浮动/可调侧栏 | local-first、多模文档、响应式侧栏 | P |
-| Penpot | 无限画布 + 左侧对象/资产 + 右侧 inspector | 专业画布、原生设计 token、设计到代码交付 | C |
-| Excalidraw | 全屏画布 + 漂浮工具岛 + 情境属性 | 低学习成本画布、上下文工具、手绘语言 | C |
-| Open WebUI | 会话侧栏 + 单列聊天 + 模型/工具/RAG workspace | AI 会话 IA、文字缩放、渐进披露 | C |
-| Chatwoot | 导航 + 队列列表 + 会话 + 客户上下文 | 密集主从、实时状态、客服上下文 | C |
-| Mattermost | 团队轨 + 频道栏 + 消息流 + 可调线程栏 | 长期复杂协作、主题、线程上下文 | C |
-| Hoppscotch | 协议导航 + 请求/响应 split panes + collection 栏 | API 工作流、可调 pane、协议切换 | C |
-
-## Claude Code 客户端（8）
-
-| 项目 | 平台与产品模式 | 可用于回答 | 入口 |
-|---|---|---|---|
-| CloudCLI / Claude Code UI | Web/PWA/Electron；会话 drawer/sidebar + transcript + tool/git/file/terminal views | 自托管响应式 Agent UI、工具视图编排 | A |
-| Happy | iOS/Android/Web/macOS；活动会话 inbox + event timeline + 移动 composer/approval | 移动监督、通知、权限审批 | A |
-| Paseo | iOS/Android/Web/Electron/CLI；workspace/agent 侧栏 + chat/editor tabs + file/diff/terminal panes | 真正多端、多个 Agent 与 workspace | A |
-| Opcode | Windows/macOS/Linux；项目/会话浏览 + agent console + analytics/MCP/config modules | 单色本地控制台、管理与分析 | A |
-| CodePilot | Electron；侧栏 + chat workspace + split sessions + provider/MCP/skills/media | 柔和个人 AI、模块化桌面 workspace | A |
-| cdesktop | 响应式 Web；sessions + transcript/terminal/diff + plan/files/preview，最多四 cells | IDE 密度、多 pane 验证工作区 | A |
-| TOKENICODE | Tauri 桌面；会话导航 + chat + local file/editor tools | 本地桌面 AI、编辑器与会话组合 | A |
-| OpenClaudgents | Tauri 桌面；多会话 chat + agent-team status visualization | 新兴的 Agent 团队状态可视化；成熟度不足时只作概念线索 | A |
-
-## 多端个人应用（11）
-
-| 项目 | 平台实现/共享模式 | 可用于回答 | 入口 |
-|---|---|---|---|
-| Notesnook | React/React Native/Electron；共享 editor、core、theme，平台 view 分层 | 内容编辑、主题共享、Web/桌面/移动壳分工 | M |
-| Standard Notes | React/React Native/Electron；共享领域模型，Web/desktop 与 mobile shells | 加密笔记的领域共享与平台壳 | M |
-| Joplin | React/React Native/Electron monorepo；共享 sync/data，平台 UI packages | local-first 同步、多端内容编辑 | M |
-| Logseq | ClojureScript/React/Electron；共享 block model/domain，平台 capability 分层 | 块编辑器、知识图谱与平台能力 | M |
-| LocalSend | Flutter 单一跨平台 UI | 高共享率的桌面/移动任务流 | M |
-| Immich | SvelteKit Web + Flutter mobile；共享 API/领域词汇，UI 分开 | 媒体优先、拍摄/上传与桌面浏览职责分离 | M |
-| Bitwarden Clients | 共享 Web/browser/desktop stack；native mobile 独立 | 共享领域与安全流程、平台原生 UI 取舍 | M |
-| RustDesk | Rust core + Flutter 跨平台 UI | 深度本地能力与统一多端控制界面 | M |
-| Element Web and Element X | 共享协议、SDK、设计语言；Web React，移动 SwiftUI/Compose | 协议一致、平台原生实现、实时通信 | M |
-| Home Assistant Frontend | 响应式 Web UI 嵌入 iOS/Android companion shells | Web-first 多端、设备能力由 native shell 补充 | M |
-| Actual Budget | 共享 React UI；browser worker 与 desktop Node data adapters | local-first 财务工具、共享 UI 与数据适配器 | M |
-
-## 使用映射
-
-1. 先从当前原型的对象、任务、密度和平台筛选 1-3 个项目。
-2. 读取对应详细报告，区分源码事实、界面观察和研究者推断。
-3. 只迁移结构性选择和当前问题所需模式；不要复制品牌、受限源码或迁移中的旧组件。
-4. 需要视觉起点时，再将项目与 `<Path>{roots.workflows}/specdev/P-prototype/design-library/style-index.md</Path>` 的八种样板关联。样板的“主要参考”是综合实现，不等于项目逐像素复制。

package/template/workflows/specdev/P-prototype/design-library/research-provenance.md

@@ -1,54 +0,0 @@
-# 研究来源、快照与复用边界
-
-## 固定快照
-
-| 字段 | 值 |
-|---|---|
-| 上游仓库 | `open-source-ui-research`（authoring 来源；安装后的运行时不依赖上游工作树） |
-| snapshot commit | `49b565913c52f4867456e609696625157f19b930`（短 SHA `49b5659`） |
-| commit subject | `feat: add visual UI style gallery` |
-| 研究基准日 | `2026-08-30` |
-| 快照目录 | `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/</Path>` |
-| tracked file count | 38 |
-
-`research-snapshot` 来自该 commit 的 Git archive，保留全部 tracked 相对结构和字节内容。它包含 Markdown 研究、两个 JSON 数据集、综合 CSS token、八个 HTML 页面、共享 HTML/CSS/JS、Playwright 测试、package lock、本地 Lucide、三张 JPEG、截图和 attribution；不包含 `.git/`、`node_modules/` 或未跟踪的 `test-results/`。
-
-快照内 `.gitignore` 文件是 tracked 内容，必须保留。不要因目录名以点开头而把它们误判为上游 Git 元数据。
-
-## 内容清单
-
-| 分区 | 数量 | 权威内容 |
-|---|---:|---|
-| 根文件 | 3 | `.gitignore`、README、研究方法 |
-| data 分区 | 2 | 19 个基础项目 + 8 个 Claude Code 客户端 + 11 个多端项目，共 38 个记录 |
-| reference 分区 | 2 | 综合 token 与使用约束 |
-| report 分区 | 1 | 总报告、六种布局、跨项目结论和验收清单 |
-| research 分区 | 7 | 项目模板、研究索引和五份分类研究 |
-| ui-gallery 分区 | 23 | 8 个风格页、总览、样式、脚本、测试、依赖锁、Lucide、图片、截图与 attribution |
-| 合计 | 38 | 与 pinned Git tree 一致 |
-
-## 证据等级
-
-| 等级 | 证据 | 可以支持 |
-|---|---|---|
-| A | 仓库 design token、主题、组件源码、官方设计系统 | 精确颜色、字号、圆角、间距、组件状态和实现 |
-| B | 官方架构/产品文档、Storybook、官方截图 | 技术栈、信息架构、主要布局和交互流程 |
-| C | 可访问产品界面与发布说明 | 带“约”的界面观察与响应行为 |
-| D | 第三方资料、搜索摘要、研究者推断 | 线索或明确标注的推断，不支持精确数值 |
-
-精确值必须回到 A 级证据。GitHub stars 是 2026-08-30 附近的近似快照，只说明关注度，不代表 UI 质量。许可字段是研究提示，不构成法律意见；代码公开也不自动等于 OSI 开源或允许直接复用。
-
-## 资产与 attribution
-
-三张本地示例图来自 Unsplash，具体 photo ID 与署名记录在 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/ui-gallery/assets/ATTRIBUTION.md</Path>`。Lucide 是本地 vendored UMD 1.37.0，ISC license。复制包含图片或 Lucide 的样板时同时携带 attribution，并在进入生产前由项目 owner 重新核对依赖与许可。
-
-逐项目源码许可差异很大，包括 Apache/MIT/MPL、AGPL、BSL、混合目录许可和 source-available restrictions。设计库用于研究结构、任务和交互；没有明确许可与项目需要时，不复制项目源码或品牌表达。
-
-## 快照不变性
-
-- 原型运行只读 snapshot；复用资产只写入当前 change 的设计包。
-- snapshot 的相对链接、资源路径和 package lock 保持原样。
-- 更新研究库必须显式选择新的完整 commit，重新从 Git tracked tree 建立整个 snapshot，重新核对 38 项映射、链接、文件清单、二进制 hash、测试和 attribution；不得混入上游工作树的未提交文件。
-- 更新后在本文件替换 commit、基准日和 inventory，并将差异作为研究升级审查，不做静默刷新。
-
-原始方法与局限见 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/METHODOLOGY.md</Path>`；总报告见 `<Path>{roots.workflows}/specdev/P-prototype/design-library/research-snapshot/report/OPEN_SOURCE_UI_RESEARCH_2026.md</Path>`。