@colin4k1024/tsp 2.4.4 → 2.4.6

package/docs/runbooks/parallel-execution-usage.md

@@ -1,179 +0,0 @@
-# Parallel Execution Framework 使用指南
-
-## 概述
-
-Parallel Execution Framework（并行执行框架）提供：
-- 任务智能拆分
-- Git worktree 多分支并行
-- 动态实例扩展
-- 结果自动汇总
-
-## 架构
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Parallel Execution                       │
-├─────────────────────────────────────────────────────────────┤
-│  Task Input  →  Decomposer  →  Task Queue                  │
-│                              ↓                              │
-│              ┌────────────────┼────────────────┐           │
-│              ↓                ↓                ↓           │
-│         Instance 1       Instance 2      Instance N         │
-│              ↓                ↓                ↓           │
-│              └────────────────┼────────────────┘           │
-│                              ↓                              │
-│                        Aggregator                           │
-│                              ↓                              │
-│                    Execution Summary                        │
-└─────────────────────────────────────────────────────────────┘
-```
-
-## 任务分解策略
-
-### 独立任务 (Independent)
-
-```python
-tasks = [
-    {"id": "1", "type": "independent", "command": "npm test -- --testNamePattern=auth"},
-    {"id": "2", "type": "independent", "command": "npm test -- --testNamePattern=api"},
-    {"id": "3", "type": "independent", "command": "npm test -- --testNamePattern=ui"},
-]
-```
-
-### 串行任务 (Sequential)
-
-```python
-tasks = [
-    {"id": "1", "type": "sequential", "command": "npm run build"},
-    {"id": "2", "type": "sequential", "command": "npm run test", "depends_on": ["1"]},
-]
-```
-
-### 级联任务 (Cascade)
-
-```python
-tasks = [
-    {"id": "main", "type": "cascade", "command": "npm run build"},
-    {"id": "sub1", "type": "cascade", "trigger": "on_success", "parent": "main", "command": "./deploy.sh staging"},
-    {"id": "sub2", "type": "cascade", "trigger": "on_success", "parent": "main", "command": "./notify.sh"},
-]
-```
-
-## Git Worktree 并行
-
-### 创建 Worktree
-
-```bash
-git worktree add ../feature-auth-worktree feature-auth
-git worktree add ../feature-api-worktree feature-api
-```
-
-### 管理 Worktrees
-
-```bash
-# 列出所有 worktree
-git worktree list
-
-# 列出所有 worktree（详细）
-git worktree list --verbose
-
-# 移除 worktree
-git worktree remove ../feature-auth-worktree
-
-# 清理无效 worktree
-git worktree prune
-```
-
-### 在 Worktree 中执行任务
-
-```bash
-cd ../feature-auth-worktree
-npm test
-cd ../feature-api-worktree
-npm test
-```
-
-## 动态扩展
-
-### Scale Out（横向扩展）
-
-增加并行实例数量：
-
-```python
-# 从 2 个实例扩展到 4 个
-scale_out(max_instances=4)
-```
-
-### Scale Up（纵向扩展）
-
-提升单个实例规格：
-
-```python
-# 切换到更大内存的实例
-scale_up(instance_type="large")
-```
-
-## 使用场景
-
-### 场景 1：多模块并行测试
-
-```
-任务：为 4 个独立模块运行测试
-策略：scale_out with 4 instances
-
-→ Instance 1: npm test -- --testNamePattern=module-auth
-→ Instance 2: npm test -- --testNamePattern=module-api
-→ Instance 3: npm test -- --testNamePattern=module-db
-→ Instance 4: npm test -- --testNamePattern=module-ui
-
-汇总结果
-```
-
-### 场景 2：多分支并行开发
-
-```
-任务：在 feature-a 和 feature-b 分支上并行开发
-策略：Git worktree
-
-→ Worktree 1: feature-a 分支，单独开发
-→ Worktree 2: feature-b 分支，单独开发
-
-合并到主分支时解决冲突
-```
-
-### 场景 3：构建 + 部署级联
-
-```
-任务：构建 → 部署 staging → 部署 prod
-策略：Cascade
-
-→ Step 1: npm run build (sequential)
-    → Step 2a: ./deploy.sh staging (cascade on success)
-    → Step 2b: ./run-tests.sh (cascade on success)
-        → Step 3: ./deploy.sh prod (cascade on success of all)
-```
-
-## 最佳实践
-
-1. **任务拆分粒度**：每个子任务耗时 2-10 分钟最佳
-2. **避免写冲突**：并行任务不要写同一个文件
-3. **共享状态**：使用文件、数据库或消息队列传递
-4. **失败处理策略**：
-   - `fail-fast`：一个失败立即停止
-   - `fail-continue`：部分失败继续，返回完整报告
-   - `retry`：自动重试 N 次
-5. **资源估算**：预估总耗时 = 最长任务时间 + 汇总时间
-
-## 与其他模块配合
-
-### 与 Verification Loop 配合
-
-验证任务天然适合并行执行（多个验证点同时检查）。
-
-### 与 TDD Guide 配合
-
-TDD 的 red-green-refactor 可用 cascade 串联。
-
-### 与 Harness Optimizer 配合
-
-根据历史执行数据，自动推荐最优并行策略。

package/docs/runbooks/platform-capability-demo-execution-log.md

@@ -1,184 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-29
-updated: 2026-03-29
-owner: 工程团队
-doc_tier: historical
-last_verified: 2026-04-17
-source_of_truth:
-  - ./platform-capability-demo-script.md
-  - ./command-and-capability-matrix.md
----
-
-# 平台能力升级演示执行记录
-
-> 历史快照（非现行操作手册）：本页保留当次演示执行轨迹，不作为当前命令与流程的权威定义。
-> 本页出现的 `validate_library.py` 属于历史命名；当前等价命令是 `node scripts/validate-library.js`。
-
-本文记录一条面向“平台能力升级同步”的演示链路，不替代旧的业务场景 demo。它的目标是展示新增命令、角色手册同步、示例补齐和 runtime 说明如何形成闭环。
-
-## 1. 场景定义
-
-### 背景
-
-- 仓库最近新增了一批 specialist 命令、ECC skills、hooks 和 runtime 组件
-- 旧的业务演示仍可用，但无法解释本轮新增的 `/tdd`、`/harness-audit` 与 runtime 机制
-- 需要补一套更适合团队同步和平台汇报的演示材料
-
-### 演示目标
-
-- 让观众理解当前命令面已经扩展
-- 让观众理解 runtime 是后台机制而不是显式命令
-- 让观众看到文档同步不是单点修改，而是成套收敛
-
-## 2. 阶段 1：/team-intake
-
-### 输入
-
-```text
-/team-intake
-目标：重审平台新增命令、skills、hooks 和文档入口，并补齐使用文档、示例和演示材料
-范围：README、quick start、usage scenarios、examples、角色手册、demo 脚本、demo 执行记录
-不做：修改历史快照文档、调整平台生成逻辑
-约束：旧的业务 demo 需要保留，新增演示材料必须可单独复用
-```
-
-### 产出
-
-| 字段 | 内容 |
-|------|------|
-| 任务类型 | 平台治理与文档同步 |
-| 主体对象 | 命令入口、ECC skills、runtime 说明、角色手册、示例材料 |
-| 风险 | 文档面已扩散到多层入口，容易出现只改总表不改高频页 |
-| 收口要求 | 保留历史文档，新能力另建 evergreen 演示材料 |
-
-## 3. 阶段 2：/team-plan
-
-### 拆解结果
-
-| 模块 | 动作 | 收口位置 |
-|------|------|----------|
-| 总入口 | README、CLAUDE、AGENTS、usage docs 对齐新命令面 | evergreen 文档 |
-| 次级入口 | quick start、prompt recipes、workflow essentials 对齐 | 快速上手与模板 |
-| 角色手册 | 各角色日常操作文档补 `/tdd`、`/harness-audit`、矩阵入口 | 角色层 |
-| 演示材料 | 补平台能力升级剧本与执行记录 | demo 层 |
-| 最终验证 | 逐批无错 + 历史命令 `validate_library.py`（当前等价 `node scripts/validate-library.js`）通过 | 校验层 |
-
-### 识别出的关键判断
-
-- 适合进入 `/tdd` 的不是“业务逻辑”，而是“平台同步完成标准”
-- 适合进入 `/harness-audit` 的不是单个文档，而是整个平台入口一致性
-
-## 4. 阶段 3：/tdd
-
-### 定义的完成标准
-
-```text
-1. quick start 与 usage scenarios 显式出现 /tdd 和 /harness-audit
-2. specialist 手册能解释这两个入口的适用边界
-3. 角色日常手册能解释何时使用测试先行和平台体检
-4. demo 材料能独立说明 runtime 是后台机制
-5. 仓库校验通过
-```
-
-### 价值说明
-
-- 把“文档更新”变成“有验证口径的收敛任务”
-- 避免只更新少数入口，导致团队使用路径不一致
-
-## 5. 阶段 4：/team-execute
-
-### 执行批次
-
-#### 批次 A：入口文档与 quick start
-
-- 更新 README、CLAUDE、AGENTS
-- 更新 Claude/Codex quick start 与 usage scenarios
-- 新增 [command-and-capability-matrix.md](command-and-capability-matrix.md)
-- 新增 [runtime-capabilities-overview.md](runtime-capabilities-overview.md)
-
-#### 批次 B：模板、手册与 onboarding
-
-- 更新 prompt recipes、workflow essentials、onboarding
-- 更新 specialist playbook 和 quick prompts
-- 更新首个命令 60 秒引导
-
-#### 批次 C：角色日常手册
-
-- Tech Lead 明确何时用 `/tdd`、`/harness-audit`
-- Product / Project Manager 明确何时前置可测标准
-- Architect / Frontend / Backend / QA 明确测试先行如何介入
-- DevOps 明确平台入口变化后何时做平台体检
-
-#### 批次 D：演示材料
-
-- 新增 [platform-capability-demo-script.md](platform-capability-demo-script.md)
-- 新增本文，作为平台能力升级的执行记录
-
-## 6. 阶段 5：/harness-audit
-
-### 体检前观察到的缺口
-
-- 新命令已经存在，但模板与角色手册未同步
-- runtime 机制存在，但缺少独立讲解页和演示话术
-- 旧 demo 仍然偏业务流程，无法单独解释本轮能力升级
-
-### 体检后的收敛结果
-
-| 维度 | 收敛动作 | 状态 |
-|------|----------|------|
-| 命令覆盖 | `/tdd`、`/harness-audit` 已进入 quick start、playbook、角色手册 | 已补齐 |
-| skills 完整度 | `eval-harness`、`continuous-learning`、`cost-aware-llm-pipeline`、`strategic-compact` 已进入矩阵与说明 | 已补齐 |
-| hooks 与 runtime | memory、observe、budget、compact、instinct 已有独立总览页 | 已补齐 |
-| 文档同步 | 主入口、次级入口、角色层、demo 层形成闭环 | 已补齐 |
-| 演示可复用性 | 旧业务 demo 保留，新增平台升级 demo 单独存在 | 已补齐 |
-
-## 7. runtime 说明在本次演示中的位置
-
-本次演示没有把 runtime 当作“要执行的步骤”，而是把它作为讲解层：
-
-- memory persistence：解释会话摘要、决策和待办如何回存
-- observation：解释系统怎样观察工具调用模式
-- cost awareness：解释复杂任务为何要关注预算与成本
-- compact/archive：解释长会话如何防止上下文失控
-- instinct learning：解释持续学习为何属于平台增强能力
-
-## 8. 校验结果
-
-### 文档静态检查
-
-- 本轮新增与修改的 demo/role/onboarding 文档无错误
-
-### 仓库校验
-
-```text
-Validation passed.
-- Roles: 8
-- Shared skills: 3
-- ECC skills: 9
-- Private overlay skills: not shipped in public repo
-- Specialist agents: 27
-- Generated artifacts: 70
-```
-
-## 9. 演示结论
-
-### 结论 1
-
-本轮平台升级不只是“新增几个文件”，而是公开命令、ECC skills、runtime 和文档入口四层同步扩展。
-
-### 结论 2
-
-`/tdd` 和 `/harness-audit` 已经从“存在于仓库里”提升为“存在于用户路径里”。
-
-### 结论 3
-
-runtime 能力已有单独说明和 demo 话术，不再需要依赖听众从 hooks 目录自行推断。
-
-## 10. 推荐搭配材料
-
-- [platform-capability-demo-script.md](platform-capability-demo-script.md)
-- [command-and-capability-matrix.md](command-and-capability-matrix.md)
-- [runtime-capabilities-overview.md](runtime-capabilities-overview.md)
-- [demo-execution-log.md](demo-execution-log.md)

package/docs/runbooks/platform-capability-demo-script.md

@@ -1,192 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-29
-updated: 2026-03-29
-owner: 工程团队
-doc_tier: historical
-last_verified: 2026-04-17
-source_of_truth:
-  - ./command-and-capability-matrix.md
-  - ./runtime-capabilities-overview.md
----
-
-# 平台能力升级演示剧本
-
-> 历史快照（非现行操作手册）：本页用于保留当时演示叙事，不作为当前安装或校验命令的权威来源。
-> 本页出现的 `validate_library.py` 属于历史命名；当前等价命令是 `node scripts/validate-library.js`。
-
-本文是一份可直接照着讲的演示脚本，专门用于展示本轮新增的 `/tdd`、`/harness-audit`，以及 memory、observe、budget、compact、instinct 等 runtime 能力。
-
-如果你需要先看命令和能力总表，配合阅读 [command-and-capability-matrix.md](command-and-capability-matrix.md)。如果你需要看后台机制定义，配合阅读 [runtime-capabilities-overview.md](runtime-capabilities-overview.md)。
-
-## 1. 演示目标
-
-- 说明平台现在不只有主链，还有测试先行和平台体检入口
-- 说明 runtime 能力是后台自动生效，不是手工命令
-- 说明文档、示例、角色手册和 quick start 已同步到新能力面
-
-## 2. 适用对象
-
-- 新接入项目团队
-- 需要做平台介绍的 Tech Lead
-- 需要做阶段汇报的工程负责人
-- 需要解释 ECC Harness Layer 的讲解人
-
-## 3. 演示时长建议
-
-- 5 分钟：只讲命令面变化
-- 10 分钟：讲命令面 + runtime
-- 15 分钟：完整走一遍“发现缺口 -> 测试先行 -> 文档补齐 -> 平台体检”的闭环
-
-## 4. 演示脚本
-
-### Step 1. 用 1 分钟讲清平台当前新增了什么
-
-建议讲法：
-
-```text
-这次平台不是只新增了几个 runbook，而是扩展了三层能力：
-第一层是公开命令，新增了 /tdd 和 /harness-audit；
-第二层是 ECC skills，新增了 eval-harness、continuous-learning、cost-aware-llm-pipeline、strategic-compact 等能力；
-第三层是 runtime 机制，包括 memory persistence、observation、instinct learning、context budget 与 compact/archive。
-```
-
-配套材料：
-
-- [command-and-capability-matrix.md](command-and-capability-matrix.md)
-- [runtime-capabilities-overview.md](runtime-capabilities-overview.md)
-
-### Step 2. 用 `/team-intake` 讲清当前平台治理任务是什么
-
-建议输入：
-
-```text
-/team-intake
-目标：审视近期新增命令、skills、hooks 与文档入口是否同步
-范围：README、quick start、usage scenarios、examples、角色手册
-不做：修改历史快照文档、重构平台代码
-约束：需要保留旧的业务演示，同时补一套面向新增能力的 demo 材料
-```
-
-讲解重点：
-
-- 这不是业务需求，而是平台治理任务
-- 需要区分 evergreen 文档和历史快照文档
-- 从一开始就说明“不做什么”，避免演示中被带偏
-
-### Step 3. 用 `/team-plan` 说明这类平台治理任务如何拆解
-
-建议输入：
-
-```text
-/team-plan
-基于当前 intake 结果，拆出文档刷新、示例补齐、角色手册同步、演示材料补齐和最终校验的动作清单。
-输出必须包含：依赖、收口节点、哪些事项适合进入 /tdd，哪些事项适合最终进入 /harness-audit。
-```
-
-讲解重点：
-
-- 新增能力同步不是“一次性改 README”
-- 要分入口文档、次级模板、角色手册、demo 材料四层推进
-
-### Step 4. 用 `/tdd` 讲“测试先行”不只用于代码，也能用于平台文档收敛
-
-建议输入：
-
-```text
-/tdd
-基于当前 /team-plan 结果，先定义这轮平台能力同步的完成标准。
-至少覆盖：
-1. quick start 明确出现 /tdd 与 /harness-audit
-2. specialist 与角色手册能解释何时用这两个入口
-3. 演示材料能独立说明 runtime 是后台机制，不是显式命令
-4. 历史命令 `validate_library.py`（当前等价 `node scripts/validate-library.js`）最终通过
-```
-
-讲解重点：
-
-- `/tdd` 的核心不是只能写测试代码，而是先把“什么算完成”说清楚
-- 对平台文档治理来说，它能减少返工和漏项
-- 如果需要更强的验证闭环，可以搭配 `eval-harness`
-
-### Step 5. 用 `/team-execute` 讲实际收敛动作
-
-建议讲法：
-
-```text
-执行阶段不再只是改一两个文件，而是分批补入口、补角色手册、补示例、补 demo。
-每一批都先说明目标，再批量修改，再局部检查，最后统一校验。
-```
-
-可展示的材料：
-
-- [claude-quick-start.md](claude-quick-start.md)
-- [codex-quick-start.md](codex-quick-start.md)
-- [specialist-commands-playbook.md](specialist-commands-playbook.md)
-- [tech-lead-daily-operations.md](tech-lead-daily-operations.md)
-
-### Step 6. 用 `/harness-audit` 讲平台体检为什么是新增关键入口
-
-建议输入：
-
-```text
-/harness-audit
-请从命令覆盖、skills 完整度、hooks 有效性、文档同步、集成深度五个方向审视当前平台。
-输出必须区分：
-1. 需要立即补齐的问题
-2. 可下一轮处理的问题
-3. 仅记录观察的问题
-```
-
-讲解重点：
-
-- `/harness-audit` 面向平台自身，不替代业务任务的 review 或 release
-- 它适合在仓库刚新增命令、skills、hooks、安装入口或大量 runbook 后使用
-- 它的价值是把零散缺口收敛成统一治理动作
-
-### Step 7. 单独用 2 分钟说明 runtime 是怎样工作的
-
-建议讲法：
-
-```text
-这轮新增的 runtime 能力不是你每次都要手动执行的命令。
-它们包括会话摘要回存、行为观察、成本记录、预算预警、上下文压缩和 instinct 学习。
-它们在后台帮助长会话保持稳定，但不会替代主链和 specialist 的显式决策入口。
-```
-
-建议配套展示：
-
-- [runtime-capabilities-overview.md](runtime-capabilities-overview.md)
-- [ecc-harness-usage.md](ecc-harness-usage.md)
-
-### Step 8. 用校验结果收尾
-
-建议讲法：
-
-```text
-文档和演示补齐后，最终仍要回到平台校验脚本。
-只要历史命令 `validate_library.py`（当前等价 `node scripts/validate-library.js`）通过，就说明角色、skills、agents 和生成产物基线没有被破坏。
-```
-
-## 5. 建议演示顺序
-
-1. 先展示 [command-and-capability-matrix.md](command-and-capability-matrix.md)
-2. 再展示 [runtime-capabilities-overview.md](runtime-capabilities-overview.md)
-3. 然后讲 `/team-intake` 和 `/team-plan`
-4. 再讲 `/tdd`
-5. 再讲 `/team-execute`
-6. 最后讲 `/harness-audit` 和校验结果
-
-## 6. 观众常见问题
-
-- `/tdd` 是不是只适合代码开发：不是，它适合先定义完成标准的场景
-- `/harness-audit` 能不能替代 `/team-review`：不能，它面向平台治理，不面向业务放行
-- runtime 能力是不是要手动触发：不是，runtime 是后台机制
-- 为什么还保留旧 demo：因为旧 demo 解释业务主链，新 demo 解释能力升级
-
-## 7. 演示后建议发给观众的材料
-
-- [command-and-capability-matrix.md](command-and-capability-matrix.md)
-- [runtime-capabilities-overview.md](runtime-capabilities-overview.md)
-- [platform-capability-demo-execution-log.md](platform-capability-demo-execution-log.md)

package/docs/runbooks/plugin-extension-platform-demo-execution-log.md

@@ -1,136 +0,0 @@
----
-version: "0.1.0"
-status: draft
-created: 2026-03-29
-updated: 2026-03-29
-owner: 工程团队
----
-
-# 插件与扩展平台演示执行记录
-
-本文记录一条插件 / 扩展平台演示路径，重点展示团队如何把命令入口、配置项、宿主兼容和安装路径收敛成可验证的交付链路。
-
-## 1. 场景定义
-
-### 背景
-
-- 仓库当前维护 extension / plugin 的命令入口、配置项和安装说明
-- 团队准备新增一个宿主命令入口，并同步补齐兼容与升级说明
-- 希望避免“功能能用，但安装、升级和禁用态无人解释”的交付状态
-
-### 演示目标
-
-- 让观众理解命令面、配置面和安装路径是三个不同层次
-- 让观众看到 `/tdd` 如何前置定义兼容标准
-- 让观众看到 `/verify` 如何把安装和升级验证结果正式回写到 review
-
-## 2. 阶段 1：/team-intake
-
-### 输入
-
-```text
-/team-intake
-目标：为插件仓库新增命令入口并补齐安装、配置与兼容性说明
-范围：命令、配置项、集成点、安装文档、测试计划
-不做：无关业务服务改造
-约束：必须说明宿主版本边界、升级路径、禁用态和失败回退行为
-```
-
-### 产出
-
-| 字段 | 内容 |
-|------|------|
-| 任务类型 | 插件 / 扩展交付 |
-| 主体对象 | 命令入口、配置项、宿主集成、安装路径 |
-| 主要风险 | 兼容矩阵不清、升级失败、安装路径失联 |
-| 收口要求 | review 必须承接兼容与安装验证结果 |
-
-## 3. 阶段 2：/team-plan
-
-### 拆解结果
-
-| 模块 | 动作 | 收口位置 |
-|------|------|----------|
-| 命令面 | 新增或调整命令入口 | 代码 / docs |
-| 配置面 | 定义配置项与默认值 | 代码 / docs |
-| 安装面 | 更新安装、升级、禁用路径 | docs / verify |
-| 兼容面 | 明确宿主版本与例外项 | verify / review |
-
-### 关键判断
-
-- 命令入口变更必须同步到安装和配置说明
-- 兼容矩阵需要进入 verify，而不是只口头说明
-
-## 4. 阶段 3：/tdd
-
-### 定义的完成标准
-
-```text
-1. 命令入口、配置边界和安装路径说明清晰
-2. 宿主兼容矩阵有正式记录
-3. verify 能汇总安装、升级、禁用态和回退结果
-4. review 能明确说明阻塞项与例外
-5. 仓库校验通过
-```
-
-## 5. 阶段 4：/team-execute
-
-### 执行批次
-
-#### 批次 A：命令与配置
-
-- 调整命令入口
-- 调整配置项与默认值
-
-#### 批次 B：安装与升级
-
-- 更新安装路径
-- 更新升级与禁用说明
-
-#### 批次 C：兼容收口
-
-- 汇总宿主版本矩阵
-- 整理 verify 所需证据
-
-## 6. 阶段 5：/verify
-
-### Verify 结果
-
-| 检查项 | 判断 |
-|--------|------|
-| 命令入口 | 已确认 |
-| 配置项 | 已确认 |
-| 安装路径 | 已确认 |
-| 升级 / 禁用态 | 已确认 |
-| 兼容矩阵 | 已确认 |
-
-## 7. 阶段 6：/team-review
-
-### Review 结论
-
-- 当前交付已经覆盖命令、配置、安装和兼容四层
-- 若仍有例外项，应明确标记为下一轮优化或限制说明
-
-## 8. 校验结果
-
-### 文档静态检查
-
-- 本轮新增 walkthrough、demo script 与 execution log 无错误
-
-### 仓库校验
-
-```text
-Validation passed.
-- Roles: 8
-- Shared skills: 3
-- ECC skills: 9
-- Private overlay skills: not shipped in public repo
-- Specialist agents: 27
-- Generated artifacts: 70
-```
-
-## 9. 推荐搭配材料
-
-- [plugin-extension-platform-demo-script.md](plugin-extension-platform-demo-script.md)
-- [plugin-extension-platform-walkthrough.md](plugin-extension-platform-walkthrough.md)
-- [../../examples/plugin-extension-platform-CLAUDE.md](../../examples/plugin-extension-platform-CLAUDE.md)