🎉 init: 小龙的工作空间
This commit is contained in:
大海
@@ -0,0 +1,109 @@
|
||||
# Reflection: Agent Evolution Mode — 四阶段全流程
|
||||
|
||||
> Date: 2026-06-03 | Severity: P0/P1 (multiple failures) | Recurrence: see individual patterns
|
||||
|
||||
## Context
|
||||
深度学习 ECC/Headroom/CodeGraph → 提取能力 → 增强 OpenClaw。4 Phase，16 模块，7,000 行，5h（预估 42.5h）。
|
||||
|
||||
## Pattern Classes Extracted
|
||||
|
||||
### PC-1: SQLite FK Constraint (P0) — Pattern Class: SQL FK/DELETE semantic
|
||||
- **Root Cause**: INSERT OR REPLACE causes rowid change → FK breaks
|
||||
- **Fix**: ON CONFLICT DO UPDATE preserves original rowid
|
||||
- **Future Trigger**: any SQL schema modification, batch inserts with FK
|
||||
|
||||
### PC-2: Heuristic False Positive (P1) — Pattern Class: single-signal detection
|
||||
- **Root Cause**: `[2026-...` prefix triggered JSON detection without valid parse
|
||||
- **Fix**: require 2+ signals (prefix + valid JSON.parse)
|
||||
- **Future Trigger**: any heuristic/content-type detection logic
|
||||
|
||||
### PC-3: Nested Structure Parsing (P1) — Pattern Class: protocol-level vs structural parsing
|
||||
- **Root Cause**: parser relied on structured JSON nesting, failed on content arrays
|
||||
- **Fix**: match "type":"tool_result" byte patterns instead of tree traversal
|
||||
- **Future Trigger**: any nested data structure parsing
|
||||
|
||||
### PC-4: Overly Aggressive Sampling (P2) — Pattern Class: lossy strategy without safety net
|
||||
- **Root Cause**: TimeSeries strategy kept only anchor points (500→5), dropped errors
|
||||
- **Fix**: include error/outlier detection alongside anchor selection
|
||||
- **Future Trigger**: any sampling/compression strategy design
|
||||
|
||||
## 成功经验
|
||||
|
||||
### 1. "分析→设计→实现"三阶段分离
|
||||
- 用 sub-agent 并行做源码分析（3 个 agent 同时跑，2-3 分钟完成 2,670 行分析）
|
||||
- 分析完成后一次性设计 Evolution Plan，不做中间修改
|
||||
- 实现阶段按优先级分 Phase，每个 Phase 内部模块间无依赖 → 可快速迭代
|
||||
- **教训**: 不要在分析阶段就开始设计，不要在设计中就开始编码
|
||||
|
||||
### 2. 先建 MVP，再扩展
|
||||
- P0 三件套 (安全+压缩) 1.5h 上线，立即产生价值
|
||||
- 验证了"Prompt Defense 不改代码"、"SmartCrusher 压缩率 60-95%"
|
||||
- 后续 Phase 基于已验证的架构扩展
|
||||
- **教训**: 最小可验证单元 > 大而全的设计
|
||||
|
||||
### 3. 自给自足的依赖策略
|
||||
- `@iarna/toml` 与 Node v26 不兼容 → 自写 230 行 TOML 解析器
|
||||
- 无 tree-sitter → 自写 8 语言正则解析器
|
||||
- 无 Redis → SQLite WAL 共享后端
|
||||
- **教训**: 每个外部依赖都是风险点，自写核心无依赖模块反而更稳定
|
||||
|
||||
### 4. 测试驱动: 每个模块写完立即测
|
||||
- 风险评分器: 7 个边界用例全覆盖
|
||||
- SmartCrusher: 4 种策略各测一个场景
|
||||
- Byte Surgery: 验证 SHA-256 前缀不变
|
||||
- Budget: 验证 3K→9K→11K 的 ALLOW/WARN/BLOCK 阈值
|
||||
- **教训**: "写完再测" = 返工，"写完即测" = 一次通过
|
||||
|
||||
### 5. 演化思维: 模块可替换
|
||||
- CCR Store: 接口统一，后端 InMemory/SQLite/Redis/Hybrid 可插拔
|
||||
- CodeGraph: 正则提取器 → 可升级 tree-sitter
|
||||
- 配置: TOML 解析器独立 → 可换完整 TOML 库
|
||||
- **教训**: 每个模块留升级路径，不锁死实现
|
||||
|
||||
## 失败经验
|
||||
|
||||
### 1. FK 约束错误: 32 个文件索引失败
|
||||
- 原因: `INSERT OR REPLACE` 导致 file_id 变化，节点 FK 断裂
|
||||
- 修复: `ON CONFLICT DO UPDATE` 保留原有 rowid
|
||||
- **教训**: SQLite 的 REPLACE = DELETE + INSERT，不是 UPDATE。FK 约束下用 ON CONFLICT
|
||||
|
||||
### 2. 内容检测误判: 日志被识别为 JSON
|
||||
- 原因: `[2026-06-03...` 以 `[` 开头触发了 JSON 检测
|
||||
- 修复: 要求 `[` 开头 + 有效的 JSON.parse
|
||||
- **教训**: 启发式检测需要多重信号确认，单信号不可靠
|
||||
|
||||
### 3. Byte Surgery block 检测失败 (第一次)
|
||||
- 原因: 解析器未处理嵌套 content 数组中的 tool_result
|
||||
- 修复: 直接从字节流中匹配 `"type":"tool_result"` 的 JSON 对象边界
|
||||
- **教训**: 协议级解析 > 结构化解析（后者依赖特定 JSON 结构）
|
||||
|
||||
### 4. TimeSeries 策略过于激进 (500→5)
|
||||
- 原因: 仅靠锚点选择，未包含错误检测
|
||||
- 修复: 在 planTimeSeries 中也加入 error/outlier 检测
|
||||
- **教训**: 每个策略的 fallback 必须先保证关键信息不丢失
|
||||
|
||||
## 设计的模式
|
||||
|
||||
### Pattern 1: "阶段隔离"模式
|
||||
分析阶段不写代码 → 设计阶段不改分析 → 实现阶段不改设计
|
||||
每阶段输出物不可变，下一阶段只读
|
||||
|
||||
### Pattern 2: "自包含模块"模式
|
||||
每个模块：(1) 可独立运行 (2) 零外部依赖或可选依赖 (3) CLI + 库双接口
|
||||
例子: risk-scorer.js 可 `node risk-scorer.js '...'` 也可 `require('./risk-scorer')`
|
||||
|
||||
### Pattern 3: "策略分发"模式
|
||||
检测 → 分析 → 推荐策略 → Plan → Execute → Mark
|
||||
SmartCrusher 5 策略、Router 4 策略、压缩 4 类型，都走同一模式
|
||||
|
||||
### Pattern 4: "降级优先"模式
|
||||
每个操作先尝试最优路径 → 失败则降级 → 保证不阻塞
|
||||
CCR Store: Redis → SQLite → InMemory
|
||||
压缩: lossless → SmartSample → passthrough
|
||||
搜索: FTS5 → LIKE → 空结果（不报错）
|
||||
|
||||
## 下次改进
|
||||
|
||||
1. **预检清单**: 每个 Phase 开始前列出"容易踩的坑"（如 FK、编码、检测误判）
|
||||
2. **性能基准**: 记录每个模块在大数据集下的性能（10万行 JSON、1万文件索引）
|
||||
3. **自动回归**: 所有模块跑一次全量测试脚本
|
||||
@@ -0,0 +1,64 @@
|
||||
# Reflection: Memory System Full Audit
|
||||
|
||||
> Date: 2026-06-04 | Severity: P0/P1/P2 mixed | Recurrence: 1
|
||||
|
||||
## Context
|
||||
记忆系统全量审计 + 全链路修复。6 维度扫描（文件/远程/版本/自动化/索引/寄存器），P0(5)→P1(5)→P2(4)。
|
||||
|
||||
## Pattern Class: Infrastructure Drift
|
||||
|
||||
**Root Cause**: 脚本存在 ≠ 脚本在运行。Dream Cycle cron 从未配置，index.md 从未自动更新（15→75 条差距）。
|
||||
|
||||
**Fix**: 添加 3 个 cron jobs（Dream Cycle + Git push + Health check），session-compact.sh 加 pre-compact hook。
|
||||
|
||||
**Future Trigger**: any automated maintenance system, any cron-scheduled task, any script that "should run automatically"
|
||||
|
||||
**Checklist**:
|
||||
- [ ] 新脚本添加后立即验证 cron/trigger 是否配置
|
||||
- [ ] 定期检查 index/registers 的 freshness
|
||||
- [ ] 引用即承诺——引用未创建的文件要么创建要么删引用
|
||||
|
||||
## 成功经验 ✅
|
||||
|
||||
### 1. 全量审计方法论
|
||||
- **先收集后判断**: 不要边查边改。先扫描全部 6 个维度（文件/远程/版本/自动化/索引/寄存器）再排优先级
|
||||
- **分级修复**: P0(立即)/P1(本周)/P2(长期) 三层划分，避免一锅粥
|
||||
- **交叉验证**: vault.md vs registers/ 去重分析，用 Python 脚本做交叉检查
|
||||
|
||||
### 2. Git 版本控制从零到一
|
||||
- 先建 .gitignore（排除 175M+14M+19M 大目录）再 git add
|
||||
- 用 Gitea API 创建仓库（免去 Web UI 操作）
|
||||
- 单个基线提交覆盖 79 文件，保持 history clean
|
||||
|
||||
### 3. vault.md 拆分策略
|
||||
- 不是"移走"，是"精简引用 + 交叉链接"
|
||||
- 保留决策时间线（WHEN），配置详情移到 registers/（WHAT）
|
||||
- 父文件从 206→143 行，回退阈值以下
|
||||
|
||||
## 失败教训 ⚠️
|
||||
|
||||
### 1. 索引长期不更新
|
||||
- index.md 从 15→75 条，说明 memory-sync.sh index 从未被 cron 触发过
|
||||
- **根因**: Dream Cycle cron 未配置，脚本是手动的
|
||||
- **教训**: 脚本存在 ≠ 自动运行，必须验证 cron 列表
|
||||
|
||||
### 2. 注册文件被引用但未创建
|
||||
- people.md 在 _index.md 引用为"按需创建"，但从未被创建
|
||||
- 引用即承诺，要么创建要么删引用
|
||||
|
||||
## 新能力
|
||||
|
||||
- `session-compact.sh pre-compact` — 上下文压缩前自动安全检查 + 同步
|
||||
- 远程服务器健康监控 cron（每 2h，连续 3 次失败告警）
|
||||
- 记忆审计 playbook（可复用）
|
||||
|
||||
## 度量
|
||||
|
||||
| 指标 | 修复前 | 修复后 |
|
||||
|------|--------|--------|
|
||||
| Git commits | 2 (未推送) | 7 (已推送 Gitea) |
|
||||
| Cron jobs | 0 | 3 (Dream Cycle + Git push + Health) |
|
||||
| Index entries | 15 | 75 |
|
||||
| Registers | 4 | 7 |
|
||||
| vault.md 行数 | 206 | 146 |
|
||||
| Daily 覆盖 | 5篇 (缺今日) | 6篇 |
|
||||
@@ -0,0 +1,31 @@
|
||||
# Reflection: DDL CONSTRAINT Leakage into TypeScript Interfaces
|
||||
|
||||
> Date: 2026-06-05 | Severity: P0 | Recurrence: 1
|
||||
|
||||
## Context
|
||||
Backend Builder Agent (SF-04) — `schema.ts` 生成时 DDL PRIMARY KEY / FOREIGN KEY / CONSTRAINT 行被当作数据列，泄露进 TypeScript interface 定义。
|
||||
|
||||
Example: `"PRIMARY KEY (id)"` → parsed as column `PRIMARY` with type `KEY`, `FOREIGN KEY (user_id) REFERENCES users(id)` → parsed as column `FOREIGN` etc.
|
||||
|
||||
## Root Cause
|
||||
DDL parser 没有区分 "column definition" 行和 "constraint" 行。`CREATE TABLE` 语句中的 CONSTRAINT 子句以特殊关键字开头（PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK），不应被解析为列定义。
|
||||
|
||||
## Fix
|
||||
Added `isConstraintLine()` check before parsing each line as a column. Lines starting with `PRIMARY KEY`, `FOREIGN KEY`, `UNIQUE (`, `CHECK (` are skipped in column parsing.
|
||||
|
||||
## Pattern Class
|
||||
**DDL-to-Code Mapping Error** — SQL DDL 的多层结构（column/constraint/index）被扁平化为单一映射时丢失语义。
|
||||
|
||||
## Future Trigger
|
||||
- Any SQL schema → code generation
|
||||
- Any DDL parser
|
||||
- Any ORM code generator
|
||||
|
||||
## Checklist
|
||||
- [ ] DDL 解析器必须有 column / constraint / index 三层分离
|
||||
- [ ] Constraint 行识别：PRIMARY KEY, FOREIGN KEY, UNIQUE (, CHECK (
|
||||
- [ ] 生成后验证：interface 字段数 ≤ 表列数（不含约束行）
|
||||
- [ ] 跑 benchmark 验证所有领域 schema 生成正确
|
||||
|
||||
## Recurrence Count
|
||||
1
|
||||
@@ -0,0 +1,28 @@
|
||||
# Reflection: `||` vs `??` Falsy Coercion Bug
|
||||
|
||||
> Date: 2026-06-05 | Severity: P1 | Recurrence: 2
|
||||
|
||||
## Context
|
||||
Cross-Agent Certification (PR-30) — Fleet score ranking. Using `order[status] || 6` for certification ranking.
|
||||
|
||||
## Root Cause
|
||||
JavaScript `||` operator treats `0` as falsy. When `order["healthy"] = 0`, `order["healthy"] || 6` evaluates to `6`, pushing healthy agents to bottom of ranking instead of top. The certification result was reversed — healthy fleets got low scores.
|
||||
|
||||
## Fix
|
||||
Changed `order[status] || 6` → `order[status] ?? 6`. Nullish coalescing (`??`) only triggers on `null`/`undefined`, not on `0`.
|
||||
|
||||
## Pattern Class
|
||||
**JS/TS Falsy Coercion Trap** — `||` treats `0`, `""`, `false` as falsy. Use `??` for numeric/boolean defaults.
|
||||
|
||||
## Future Trigger
|
||||
- Any JS/TS code writing numeric defaults
|
||||
- Any ranking/scoring/ordering logic
|
||||
- Any code with `value || default` where value can legitimately be 0
|
||||
|
||||
## Checklist
|
||||
- [ ] Grep all `||` in scoring/ranking/ordering code → replace with `??` if value can be 0
|
||||
- [ ] For all numeric defaults: `||` → `??`
|
||||
- [ ] Add `||` vs `??` check to JS/TS Domain Checklist
|
||||
|
||||
## Recurrence Count
|
||||
2 — previously hit in Agent Evolution FK index scoring (same pattern: `count || 0` skipped real zeros)
|
||||
@@ -0,0 +1,32 @@
|
||||
# Reflection: JSX Template Ternary Nesting Syntax Error
|
||||
|
||||
> Date: 2026-06-05 | Severity: P0 | Recurrence: 1
|
||||
|
||||
## Context
|
||||
Frontend Builder Agent (SF-03) — fallback page 模板中的三元表达式产生了语法错误。模板生成代码如 `{loading ? {<Spinner />} : {<div>No data</div>}}`。
|
||||
|
||||
## Root Cause
|
||||
生成器模板中 JSX 三元表达式嵌套了多余的 `{}`。模板本身输出 `{` 字符，内嵌的 JSX 也带 `{` — 双层花括号导致 React 解析失败。
|
||||
|
||||
Incorrect output pattern: `{condition ? {<JSX />} : {<AnotherJSX />}}`
|
||||
Correct: `{condition ? <JSX /> : <AnotherJSX />}` 或 `{condition ? (<JSX />) : null}`
|
||||
|
||||
## Fix
|
||||
Fixed template to not wrap JSX branches in extra `{}`. The outer `{}` (JSX expression) already handles one level; inner JSX elements don't get re-wrapped.
|
||||
|
||||
## Pattern Class
|
||||
**Template Code Generation Syntax** — 代码生成器的模板本身使用目标语言语法时，转义/嵌套层次需仔细处理。
|
||||
|
||||
## Future Trigger
|
||||
- Any code generator that outputs JSX/TSX
|
||||
- Any template-based code generation
|
||||
- Any string-template code with nested braces/quotes
|
||||
|
||||
## Checklist
|
||||
- [ ] 生成器模板验证：输出后立即 `tsc --noEmit` 检查语法
|
||||
- [ ] JSX 三元表达式：禁止 `{cond ? {<X />} : {<Y />}}` 模式
|
||||
- [ ] 模板中使用 `\`` 或字符串拼接替代包含反引号的模板字面量
|
||||
- [ ] Benchmark smoke test 覆盖所有生成项目的 build
|
||||
|
||||
## Recurrence Count
|
||||
1
|
||||
@@ -0,0 +1,31 @@
|
||||
# Reflection: Next.js `src/app/` vs `app/` Path Convention
|
||||
|
||||
> Date: 2026-06-05 | Severity: P0 | Recurrence: 1
|
||||
|
||||
## Context
|
||||
Domain Benchmark Suite v1 — frontend-builder-agent.mjs 生成的 Next.js 项目输出到 `src/app/` 目录。10/10 项目 Build 失败（0/10 Build）。Next.js App Router 默认 pages directory 是 `app/`。
|
||||
|
||||
## Root Cause
|
||||
Frontend Builder Agent 的初始设计内嵌了错误的路径假设。模板代码输出到 `src/app/`，但 Next.js `app/` router 不从 `src/app/` 读取。Tailwind content 配置和 tsconfig paths 也指向了错误路径。
|
||||
|
||||
## Fix
|
||||
全局替换：
|
||||
- `src/app/` → `app/`
|
||||
- 更新 tsconfig paths 匹配 `app/`
|
||||
- 更新 tailwind.config content 匹配 `app/**/*.{ts,tsx}`
|
||||
|
||||
## Pattern Class
|
||||
**Path Convention Mismatch** — Generator/Builders 有硬编码路径假设，与实际 runtime 的 convention 不一致。
|
||||
|
||||
## Future Trigger
|
||||
- Any Next.js project generation
|
||||
- Any framework-specific builder agent creation
|
||||
- Any path-dependent code generation
|
||||
|
||||
## Checklist
|
||||
- [ ] 验证生成器输出目录与目标框架的 default convention 一致
|
||||
- [ ] 在生成器写完第一版后立即跑 build smoke test
|
||||
- [ ] tsconfig paths 与 tailwind content 与 pages directory 三者一致性检查
|
||||
|
||||
## Recurrence Count
|
||||
1
|
||||
Reference in New Issue
Block a user