lcap-frontend-library 0.0.1

package/packages/lcap-frontend-library/commands/speckit.self-check.md

@@ -0,0 +1,177 @@
+---
+description: 开发完成后执行结构化的「对抗性自检」审计，从接口覆盖、逻辑-样式冲突、平台规范、E2E 断言深度、生命周期与资源清理五个维度发现遗漏与冲突。
+---
+
+## 用户输入
+
+```text
+$ARGUMENTS
+```
+
+执行前请充分考虑用户输入（若不为空）。本命令在**开发完成或阶段性交付前**执行，以**审计模式**对当前组件实现做对抗性检查，而非继续写代码。
+
+## 自检定位
+
+- **执行模式**：按任务清单实现功能、跑测试、修报错。
+- **审计模式（本命令）**：假定实现已有疏漏，从多维度交叉核对 api.ts、测试、样式、plan.md 与平台规范，输出**结构化问题清单**与修复建议，触发补写/修改直至通过。审计不仅是读代码，还须用**更严苛的断言与终端跑测**挑战实现；与 DOM/浏览器强相关的结论须有 **`test:e2e` 或单测等终端证据**支撑，并写入报告中的**测试运行证据**。
+- **与 speckit.plan / speckit.implement 一致（探测优先）**：**必须先**在终端执行 `npm run test:e2e` 并记录结果，**直至通过**；**禁止**未执行或失败未修复就勾选「e2e 已通过」。若工程尚未配置 `test:e2e`，须**先补齐**配置与用例（见 `setup-extension-project.mjs`）再执行，不得留待「以后再说」。
+
+**适用时机**：实现任务全部标记完成后、或提交前、或交付前希望做一轮”找茬”式自检时。
+
+## 零信任验证协议（强制）
+
+> 审计的目标是**找到 bug**，不是确认正确。假设实现有遗漏，直到证据证明没有。
+
+### 三条铁律
+
+1. **强制重读**：审计开始前，必须重新从磁盘读取所有相关文件（spec.md、plan.md、api.ts、组件源码、测试文件）。禁止基于”我记得代码是这样写的”做任何判断——以 Read 到的磁盘内容为唯一事实。
+2. **终端为证**：`npm run test`、`npm run build`、`npm run test:e2e` 的结论**只能**来自本次审计中实际执行的终端命令输出（退出码 + 结果摘要）。禁止引用之前执行的结果或声称”刚才已跑过”。
+3. **有据才判**：每个维度的”通过”结论必须附带至少一条**不可伪造的证据**：
+   - 静态检查：文件路径 + 行号 + 引用内容
+   - 动态验证：命令 + 退出码 + 关键输出行
+
+### 违规判定
+
+以下行为视为无效自检，报告不可信：
+- 结论中出现”根据之前的实现”、”在上面的步骤中已确认”等回溯性表述
+- test/build/test:e2e 结果无对应的终端执行记录
+- 维度结论为”通过”但无任何文件引用或命令输出
+- 未执行 Read 直接对文件内容做断言
+
+## 必要知识
+
+- 当前组件的 `spec.md`、`plan.md`、`api.ts`、e2e 测试文件、组件样式与模板。
+- 平台规范：`references/lcap-extension-component/implementation-rules.md`（样式与主题变量）、`plan-template` 中的「样式与主题适配」与「鲁棒性检查」。
+- **`LEARNINGS.md`**（checklist，只读）：作为额外审计检查项逐条核对，验证本次实现是否踩中已知坑。
+
+## 对抗性自检五维度
+
+按下列五个维度**逐一执行**，每维度输出：检查动作、发现结果、结论与是否触发修复。发现问题时**必须修复**并复检，**直至该维度结论为通过**；**禁止**将问题留作「后续处理」后结束自检。
+
+---
+
+### 1. 接口与测试覆盖率矩阵检查 (API vs. Test Coverage)
+
+**检查动作**：
+- 从 `api.ts` 中提取所有 **Props**（与展示/交互强相关的）、**Methods**、**Events**，列成清单。
+- 逐一核对测试用例中是否存在对应测试（调用、点击、事件监听与断言）。
+- **evolve（增量修改）**：检查范围聚焦于**本次 spec 新增/修改的 API 条目**，但同时确认已有测试未因修改而失败。
+
+**发现结果示例**：
+- `api.ts` 中有 `zoomIn`、`zoomOut` 方法。
+- 测试中只有 `nextPage` 的点击与断言。
+- **结论**：**“缩放功能测试缺失”**，触发补写用例（如：点击缩放按钮后断言 canvas 尺寸或 scale 状态变化）。
+
+**输出**：接口清单 + 每项是否有测试覆盖（是/否），否则记录为待修复项。
+
+---
+
+### 2. 逻辑与样式冲突审计 (Logic-Style Conflict Audit)
+
+**检查动作**：
+- 检索组件中所有涉及**尺寸/比例改变**的逻辑（如 `scale`、`width`、`height`、`transform`、ResizeObserver、库的 resize API）。
+- 检索对应模板与样式（Vue SFC 的 `<style scoped>`/`<style module>`）中可能**限制尺寸**的规则（如 `max-width`、`max-height`、`width: 100%`、`overflow: hidden` 作用于同一元素或父/子链）。
+- **样式隔离检查**（`workflow-guardrails.md` 规则 9）：检查组件是否使用 `<style scoped>` 或 `<style module>`，若存在裸 `<style>`（无 scoped/module）则记为待修复。检查内联 `:style` 是否仅包含运行时动态计算值（如 Canvas backgroundImage、prop 驱动的宽高），静态布局属性不应内联。
+
+**发现结果示例**：
+- JS 逻辑：通过 `scale` 改变渲染比例，期望 canvas 随比例放大。
+- CSS 审计：发现 `canvas` 或其容器存在 `max-width: 100%`。
+- **冲突识别**：`max-width: 100%` 会锁定物理宽度，导致 `scale` 增大时元素无法向外扩张，缩放”表现层被压制”。
+- **结论**：**”缩放功能在表现层被压制”**，触发 CSS 修改（如改为 `max-width: none` 或由 JS 控制的变量，或调整 DOM 结构）。
+- 样式隔离示例：组件使用裸 `<style>` 定义了 `.watermark-overlay`，可能污染全局。**结论**：**”样式未隔离”**，触发改为 `<style scoped>`。
+
+**输出**：尺寸相关逻辑列表 + 可能冲突的 CSS 规则与位置 + 样式隔离检查结果；冲突项和隔离问题列为待修复。
+
+---
+
+### 3. 平台规范合规性扫描 (Platform Compliance Scan)
+
+**合规依据**：本维度须结合 **`references/lcap-extension-component/implementation-rules.md`** 中的 **规则 4（UI 样式规范）** 执行。规则要求：组件主题与样式须优先使用对应 UI 框架的**全局主题变量**，禁止写死颜色、间距等魔法值；变量须从 `platform/theme-variables-*.md` 中选择，且 `plan.md` 中须有「样式与主题适配」及**样式变量映射表**（见 implementation-rules 的「计划阶段要求」「如何落实」「验收要点」）。
+
+**检查动作**：
+- 扫描组件相关样式（SFC 内 `<style>`、组件引用 CSS）中所有**硬编码颜色/尺寸**（Hex、RGB、固定 `px` 的间距/字号等）。
+- 对照 **plan.md** 中「样式与主题适配」的**变量映射表**（若缺失则视为未满足规则 4 的计划阶段要求）。
+- 对照 **implementation-rules.md 规则 4** 所列的 `platform/theme-variables-*.md`（ant-design / element-ui / element-plus / cloud-ui / mobile-ui），核对硬编码是否均已替换为上述文档中的 CSS 变量（如 `var(--cw-xxx)`、`var(--el-xxx)`）。
+- **变量合法性校验**：提取组件内使用的所有 `var(--*)` 变量名，与对应技术栈的 `platform/theme-variables-*.md` 中**已定义变量列表**交叉核对；若某变量在 theme-variables 文档中不存在（如误写为 `--el-color-primary-light` 而实际为 `--el-color-primary-light-3`），记为待修复，确保换肤在生产环境生效而非回退到 CSS 默认值。
+- **JS 绘图变量解析**（见 implementation-rules 规则 4「例外：Canvas 与 JS 绘图」）：若组件涉及 Canvas、WebGL 或 JS 动态绘图，检索传入绘图 API 的颜色参数（如 `ctx.fillStyle`、qrcode 颜色配置）；若发现将 `var(--*)` 字符串直接传给 JS 绘图函数，记为待修复，须改为 getComputedStyle 取计算值或使用绝对值。
+
+**发现结果示例**：
+- 发现 `background-color: #f5f7fa`。
+- 规范要求（implementation-rules 规则 4）：须使用 theme-variables 中的变量，plan.md 映射表中应约定为 `var(--el-fill-color-light)` 或等价变量。
+- **结论**：**“未遵循主题换肤规范”**，触发将硬编码替换为 plan.md 映射表或 theme-variables-*.md 中对应变量。
+- 变量合法性示例：组件中使用了 `var(--el-color-primary-light)`，但 theme-variables-element-plus.md 中仅有 `--el-color-primary-light-3` 等，**结论**：**“变量名在主题中未定义”**，触发修正为文档中存在的变量名。
+
+**输出**：硬编码列表 + 变量合法性核对结果（使用的 var(--*) 是否均在 theme-variables-*.md 中有出处）；未替换的硬编码与未定义变量均列为待修复。
+
+---
+
+### 4. E2E 断言深度评估 (Assertion Depth Audit)
+
+**检查动作（静态）**：
+- 检查 **e2e**（及与浏览器/DOM 强相关的测试）中所有 `expect(...)` 语句，按功能分类。
+- 判断每条断言是**存在性/可见性检查**（如 `toBeVisible()`）还是**物理状态/数值检查**（如宽高、位置、数量、文本、属性值）；**Vitest 单测**中针对布局/尺寸的深度断言可一并纳入评估。
+- 对「缩放」「尺寸」等能力：若仅有可见性断言，视为**断言过浅**，须补充可观测状态（如 `getBoundingClientRect()`、组件暴露状态等）。
+
+**检查动作（动态验证）**：
+- 在完成静态评估且**本维度触发了 e2e 用例修改**（新增/改断言）时：**必须**在终端执行 `npm run test:e2e`，并在报告「测试运行证据」中填写**退出码与结果摘要**；若补充了深度断言，**必须**再次执行直至**通过**。
+- 若工程**尚未配置** `test:e2e`，须先按 speckit.plan / `setup-extension-project.mjs` **补齐脚本与配置**，再执行直至通过，**不得**仅以「未配置」结束本维度。
+
+**发现结果示例**：
+- 对于“缩放”功能，当前仅有 `expect(canvas).toBeVisible()`。
+- **深度评估**：缩放是否生效需验证“尺寸或比例变化”，仅“可见”不足。
+- **结论**：**“断言过浅”**，触发补充像素级或状态验证（如 `getBoundingClientRect()` 的 width/height 随操作变化、或组件暴露的 scale 状态被断言）。
+
+**输出**：功能点 + 当前断言类型（存在性/物理状态）+ 是否满足 spec 验收；不满足的触发补写深度断言；**动态跑测结果**写入报告第六节「测试运行证据」。
+
+---
+
+### 5. 生命周期与资源清理审计 (Lifecycle & Cleanup Audit)
+
+**检查动作**：
+- 针对使用 **ResizeObserver**、**addEventListener**（含 `window`/`document`）或**第三方库实例**（如 PDF.js、图表库）的组件，检索代码中的 `onMounted` / `useEffect`（或等效生命周期），核对是否存在对应的 **onUnmounted** / **cleanup**（或 useEffect 的 return）。
+- **检查点**：`resizeObserver.disconnect()`、`window.removeEventListener` / `document.removeEventListener`、第三方实例的 `destroy()` / `dispose()` 等是否在组件卸载或 effect 清理时被调用。
+
+**发现结果示例**：
+- 组件在 `onMounted` 中创建了 `ResizeObserver` 并 `observe` 了某元素，但未在 `onUnmounted` 中调用 `disconnect()`。
+- **结论**：**“存在资源未清理”**，可能导致反复挂载/卸载时内存泄漏或浏览器卡顿，触发在卸载/cleanup 中补充对应断开或销毁逻辑。
+
+**输出**：使用的观察者/监听/第三方实例列表 + 是否在卸载或 cleanup 中有对应 disconnect/removeEventListener/destroy；缺失项列为待修复。
+
+---
+
+## 工作流程
+
+1. **定位范围**：确定待自检的组件目录、对应 `api.ts`、测试文件、plan.md、组件源码（含生命周期与资源使用）。
+2. **加载输出模板**：读取 `templates/self-check-report-template.md`，自检报告**必须按该模板结构**输出（**含「测试运行证据」**，不得省略）。
+3. **执行五维度**：按 1→2→3→4→5 顺序执行，每维度输出“检查动作 + 发现结果 + 结论 + 待修复项”，并填入模板对应章节。
+4. **修复与验证（强制）**：对每项待修复项执行修复后，**必须**在终端执行验证并**将结果写入报告「测试运行证据」**（见模板第六节）：
+   - **`npm run test`**：**必须**执行（若项目存在该脚本），**严禁**在未获得终端成功输出（或明确失败原因）时勾选「已修复」或「通过」。
+   - **`npm run build`**：若自检流程包含构建验收，须同样执行并记录摘要。
+   - **`npm run test:e2e`**：**必须**执行并记录，**直至通过**；若失败，须修复代码、测试或环境配置后重跑（见「关键规则」），**严禁**虚构通过。
+5. **闭环要求**：**全部**待修复项已关闭、五维度结论均为**通过**、`npm run test` / `npm run build` / `npm run test:e2e` 均在「测试运行证据」中为成功摘要后，方可结束自检。**禁止**在仍有未修复项或测试未通过时输出「自检完成」。
+6. **报告**：按模板输出完整自检报告（可写入 `specs/<id>-<name>/self-check-report.md` 或直接输出），包含五维度结论（均为通过）、**测试运行证据（日志摘要）**、修复后验证。
+
+## 输出要求
+
+- **必须使用** `templates/self-check-report-template.md` 作为报告结构，按模板中的表格与章节逐项填写，**不得省略**「测试运行证据」章节。
+- 以**结构化列表/表格**呈现：维度名、检查项、是否通过、问题描述、修复建议。
+- **测试日志摘要**：在第六节填写各命令的**退出码**与**简短结果摘要**（如 `vitest: 12 passed`、`playwright: 3 passed`）；**禁止**仅勾选复选框而无文字证据；可截断日志、脱敏路径与 token。
+- 若某维度存在待修复项，须在报告中醒目标出，**并修复至该维度通过**，不得留待后续处理。
+
+## 关键规则
+
+- 必须使用中文进行自检描述与报告。
+- 自检阶段以**审计视角**执行，假定存在遗漏与冲突，不默认“已实现即正确”。
+- 发现的问题须对应到具体文件/行或选择器，并给出可执行的修复建议（如替换为某变量、补充某断言）。
+- **测试失败 ≠ 自检结束**：跑测失败时须区分**组件逻辑/断言错误**（应修复代码或测试）与**环境干扰**（如 404、Storybook 未启动、端口占用、代理、超时）。对环境问题须**排查并修复**（如检查 `baseURL`/端口、启动服务、重试）直至相关命令**通过**；**禁止**将环境失败误报为「组件逻辑已验证通过」，**禁止**以单次报错放弃直至全部通过为止的修复闭环。
+- 修复后须重新运行相关测试，确保无回归；**报告中的「通过」须与「测试运行证据」一致**。
+
+## evolve
+
+- 五维审计**聚焦本次 spec 增量**；仍须全量 regression test 证据
+- 维度 1：增量 Prop/Event/Method 覆盖 + 未破坏原有导出
+
+## asset=logic
+
+- 审计项：@NaslLogic、import '@nasl/types'、nasl 类型、logics/index.ts 导出、泛型/rest 规则
+- 跳过 E2E 维度 4；无 api.ts 时维度 1 改为函数签名与测试覆盖

package/packages/lcap-frontend-library/commands/speckit.specify.md

@@ -0,0 +1,91 @@
+---
+description: 根据用户输入的完整规格内容创建功能规格说明（spec.md）。
+---
+
+## 用户输入
+
+```text
+$ARGUMENTS
+```
+
+在继续之前**必须**充分考虑用户输入（若为空则报错「未提供需求内容」）。
+
+## 范式分支
+
+读取 init 阶段报告的 `paradigm` 与 `asset`：
+
+- **create + component** → 走下方「create · component」；模板 `templates/component-template.md`
+- **create + logic** → 走「create · logic」；模板 `templates/logic-template.md`
+- **evolve** → 走「evolve」；必须先读取现有实现再写增量 spec
+
+## create · component
+
+触发消息中用户在 `/speckit.specify` 之后输入的内容**即**需求内容，假定本对话中始终可用。
+
+- **简单需求**：用户仅用一两句话或简短描述说明想要什么（如「做一个二维码组件」「需要一个用户登录的弹窗」），未包含完整的概述、功能、验收标准、接口定义等结构。
+- **完整需求**：用户已提供与 `templates/component-template.md` 结构一致的内容，包含：标题、概述、功能列表（含描述、验收标准、接口设计、使用示例）、**视觉与交互契约**、接口定义、样式定制、注意事项。
+
+**处理规则**：
+
+1. 若判定为**简单需求**：必须参考 `templates/component-template.md` 的**结构与字段**，将用户的简短描述扩展为一份**标准规格**。需补全：
+   - 标题、概述、功能（含描述、验收标准、接口设计、使用示例）
+   - **视觉与交互契约**：按模板逐项填充「视觉表现」与「交互副作用」；复杂展示/容器类组件为**必填**，简单组件可简述「不适用」。
+   - 接口定义、样式定制、注意事项、生成时间。
+2. 若判定为**完整需求**：**契约完整性优先于原文保持度**。
+   - 若**不属于**复杂展示/容器类组件，或**已包含**完整的「视觉与交互契约」（初始状态、响应式行为、溢出规则、Resize 行为、可观测 DOM 状态）且验收标准中已含可观测的 DOM/状态描述 → 将用户**原文**写入 `spec.md`。
+   - **否则**（属于复杂组件但缺失契约或验收中无可观测状态）：**严禁**直接透传原文。必须在保留用户原文核心内容的基础上，**强制补全**缺失的「视觉与交互契约」与验收标准中的可观测项（如：某元素存在、尺寸随参数变化、某 class 出现），再写入 `spec.md`。
+3. 自动流程约定（不追问/不澄清）：当用户未提供足够细节但属于复杂展示/容器类组件时，按常规最优方案补齐契约（如：容器驱动、占满容器、Resize 重绘、溢出规则按语义选择），并在「注意事项」中写明默认假设。
+
+## create · logic
+
+参考 `templates/logic-template.md` 的结构与字段。触发消息中用户在 `/speckit.specify` 之后输入的内容**即**需求内容。
+
+- **简单需求**：用户仅用简短描述说明想要什么逻辑函数（如「日期格式化，支持多种输出格式」），未包含完整的函数签名、@NaslLogic 元数据、验收标准等结构。
+- **完整需求**：用户已提供与 `templates/logic-template.md` 结构一致的内容。
+
+**处理规则**：
+
+1. 若判定为**简单需求**：必须参考 `templates/logic-template.md` 的**结构与字段**，将用户的简短描述扩展为一份**标准规格**。需补全函数签名、@NaslLogic 元数据、参数/返回值说明、验收标准、注意事项、生成时间。
+2. 若判定为**完整需求**：在满足 logic-template 结构完整的前提下，将用户**原文**写入 `spec.md`；缺失关键字段时补全后再写入。
+3. 短名规则与 create · component 相同（2–4 个英文词 kebab-case）。
+
+## evolve
+
+1. **evolve 上下文加载**（必须先于写 spec 执行）：
+   - **component**：读取现有 `api.ts`（当前接口定义）、`index.vue`（当前实现结构）、`specs/` 下该组件最近的 `spec.md`（已有功能规格）
+   - **logic**：读取 `src/logics/<name>.ts` 或 `src/logics/index.ts` 中对应导出（当前实现与 @NaslLogic 元数据）
+   - 以上作为增量规格的**基础上下文**，后续仅描述新增/修改的部分
+2. spec 标题：`# [资产名] — 增量需求（基于现有实现）`
+3. 正文结构：## 现状摘要（事实）→ ## 本次增量 → ## 验收标准（仅本次）
+4. 接口表标注「新增 / 修改」
+5. 仍执行 create-spec.sh 创建独立 specs 目录
+
+## 工作流程
+
+按 `paradigm` 与 `asset` 选择上方对应章节（create · component / create · logic / evolve），然后：
+
+1. **生成短名**：从规格标题或概述中提取 2–4 个英文词的短名（kebab-case），例如：
+   - 「特殊组件-二维码组件（qrCodeComponent）」→ `qr-code-component`
+   - 「用户认证」→ `user-auth`
+   - **evolve**：短名应反映**本次变更**而非资产本身，如「给水印增加图片水印」→ `watermark-image`
+
+2. **执行脚本**：**确认 cwd 为工程目录**（含 package.json 且依赖 @lcap/builder）后，执行
+   `bash scripts/bash/create-spec.sh --json --short-name "你生成的短名"`
+   解析 JSON 输出得到 SPEC_FILE、FEATURE_DIR（均为绝对路径）。脚本仅执行一次。
+   > 脚本自动编号递增（扫描现有最大编号 +1），无论是新资产还是 evolve 增量都会创建独立目录。
+
+3. **写入规格**：
+   - **create + component**：按「create · component」处理规则写入 SPEC_FILE（简单需求扩展后写入；完整需求经契约完整性检查后写入）。
+   - **create + logic**：按「create · logic」处理规则与 `templates/logic-template.md` 结构写入 SPEC_FILE。
+   - **evolve**：先完成「evolve」§1 上下文加载，再按 §2–§4 写入 SPEC_FILE。
+
+4. **报告**：输出规格文件路径，以及可进入下一阶段（`/speckit.plan`）。
+
+## 通用准则
+
+- 规格聚焦**做什么**与**为什么**，避免写实现细节（技术栈、API、代码结构）。
+- 面向业务与产品，表述清晰可验收。
+- create · component 扩展简单需求时，保持与 component-template 的章节和表格格式一致，内容基于用户描述合理推断，勿编造与需求无关的接口。
+- create · logic 扩展简单需求时，保持与 logic-template 的章节和格式一致，内容基于用户描述合理推断，勿编造与需求无关的函数签名。
+- 规格允许并鼓励写“契约级”内容（如：初始视觉状态、Resize 行为、溢出/裁剪规则、可观测的 DOM 结果），但避免写到代码与文件结构层面；这些契约将用于 plan 阶段输出「技术架构方案」与 tasks 阶段的可观测验收标准。
+- 验收标准必须使用 checkbox 列表格式（`- [ ]`），属性表格必须包含「可选值」与「是否双向绑定」列，事件表格必须包含「参数类型」列，方法表格必须包含「返回值」列。

package/packages/lcap-frontend-library/commands/speckit.tasks.md

@@ -0,0 +1,61 @@
+---
+description: 基于 spec.md 与 plan.md，生成前端 UI 组件的可执行任务清单。
+---
+
+## 用户输入
+
+```text
+$ARGUMENTS
+```
+
+执行前请充分考虑用户输入（若不为空）。执行任何操作前，先理解当前工程架构与规范需求、实现计划。
+
+## 必要知识
+
+任务拆分须考虑 LCAP 扩展组件规范。**必须先阅读** `references/lcap-extension-component/SKILL.md`，确保任务涵盖 api.ts、block.stories、ideusage 等必要配置，与 component 目录下详细文档对齐。
+
+## 产出路径约束（与 `/speckit.implement` 对齐）
+
+任务清单是执行期的**直接指令**：除「做什么」外，必须写清「**落到哪个路径**」，否则易出现路径歧义、import 漂移或与 LCAP 工程约定不一致。
+
+- **硬性要求**：凡涉及新增或修改文件的任务，在 **「产出」** 中列出 **相对扩展工程根目录** 的完整路径（如 `src/components/workshop-floor-plan-drawer/api.ts`），并标注 **必须在此路径**（或等价表述）。禁止仅用「编写 api.ts」「改样式」等模糊说法。
+- **路径来源**：与 `plan.md` 中「文档与源码产出」的组件目录、`stories/`、`e2e/` 等规划**一致**，并与 **「文件路径与模块化规划」** 表**逐行对齐**（任务产出路径须能映射到该表中的模块）；若 `plan.md` 已写死组件目录，任务里须用**同一字符串**展开，不得换目录名。
+- **多文件任务**：可列多条路径；若某步只改一个文件，产出只列该文件即可。
+- **自检**：每项任务完成后，应用 `ls` / 编辑器或项目搜索确认**文件存在于约定路径**；若测试报 import 失败，优先核对是否**放错目录**，而非随意改路径迁就 import。
+
+## 工作流程
+
+1. **定位规范**：在 `specs/` 下找到对应规范需求目录，完整阅读 `spec.md` 与 `plan.md`（重点核对「文档与源码产出」「**文件路径与模块化规划**」「内置 UI 控件清单」与组件目录、stories 位置）。
+
+2. **加载模板**：读取 `templates/tasks-template.md`。
+
+3. **生成任务清单**：按 `plan.md` 中的「实现顺序」表格，逐行生成任务项，写入 `specs/<id>-<name>/tasks.md`（若项目约定使用 `tasks/` 子目录，则生成 `tasks/01-xxx.md`、`02-xxx.md` 等）。**前提**：组件文件基础骨架已存在，任务以**在现有文件上修改**为主，无需“创建组件目录与骨架”类任务。每项任务包含：
+   - **标题**：与实现顺序中的任务描述对应
+   - **描述**：实现要点（在现有骨架基础上补充/修改 Props、模板、方法、样式等，勿写成从零创建）
+   - **依赖**：按实现顺序表格
+   - **产出**（**必填，且含确定性路径**）：列出相对扩展工程根的路径列表，与上节「产出路径约束」一致；供 `/speckit.implement` 按图索骥
+   - **验收**：与 spec、plan.md 对齐；含「约定路径上文件存在且内容符合要求」；**适用时**增加「代码质量」项：`index.vue`/`index.tsx` 仅保留 UI 组装与编排，复杂逻辑落在 `plan.md` 已规划路径；内置 UI 与 spec 交互一致（参见 tasks-template「代码质量验收」）
+   - **测试任务要求**（涉及 Vitest/E2E/stories 的任务）：
+     - **Vitest 任务**：对 plan.md 测试层标注为 `Vitest(调用参数)` 的模块，须在任务描述中写明需 mock 的具体 API 名及「仅验证参数，禁止断言返回值」
+     - **E2E 任务**：须写明目标 storyId（来自 plan.md 锁定列表，格式 `<组件名-kebab>-example--<story导出名-kebab>`）
+     - **example.stories 任务**：title 字段必须为 `<组件名 PascalCase> Example`（单数）
+
+4. **报告**：输出任务清单路径与任务数量，以及可进入下一阶段（`/speckit.implement`）。
+
+## 关键规则
+
+- 必须使用中文进行任务编排与回复。
+- 任务按依赖顺序排列，可独立执行，避免遗漏或循环依赖。
+- **产出路径为硬性交付物**：不因篇幅省略；与 `plan.md` 目录规划冲突时，应先澄清或回写 `plan.md`，再写 `tasks.md`。
+- 本项目仅处理前端 UI 组件，任务聚焦：在**已有组件骨架**上修改与实现（Props/Events/Slots、模板与样式、导出方法等），不包含从零创建目录与骨架。
+- **测试任务须写明约束**：涉及 jsdom 不支持 API（Canvas/ResizeObserver/getBoundingClientRect 等）的模块，Vitest 任务须写明需 mock 的 API 名、「仅验证参数，禁止断言返回值或渲染产出」；样式验证归 E2E 任务，禁止在 Vitest 任务中要求验证 CSS 渲染效果。
+
+## evolve 模式补充
+
+- 每条变更任务后追加「回归验证」子任务：`npm run test`（component 另加 test:e2e）
+- 产出路径仍必填；仅列变更相关路径
+- logic：禁止生成 stories/e2e 任务
+
+## asset=logic
+
+- 任务清单禁止包含 stories、block.stories、e2e 相关任务；测试任务仅 vitest

package/packages/lcap-frontend-library/references/frontend-design/LICENSE.txt

@@ -0,0 +1,177 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS

package/packages/lcap-frontend-library/references/frontend-design/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: frontend-design
+description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
+license: Complete terms in LICENSE.txt
+---
+
+This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
+
+The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
+
+## Design Thinking
+
+Before coding, understand the context and commit to a BOLD aesthetic direction:
+- **Purpose**: What problem does this interface solve? Who uses it?
+- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
+- **Constraints**: Technical requirements (framework, performance, accessibility).
+- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
+
+**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
+
+Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
+- Production-grade and functional
+- Visually striking and memorable
+- Cohesive with a clear aesthetic point-of-view
+- Meticulously refined in every detail
+
+## Frontend Aesthetics Guidelines
+
+Focus on:
+- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
+- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
+- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
+- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
+- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
+
+NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
+
+Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
+
+**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
+
+Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.