@miniidealab/openlogos 0.5.0 → 0.5.3

package/spec/agents-md.md

@@ -0,0 +1,117 @@
+# AGENTS.md 生成规范
+
+> 版本：0.3.0
+>
+> 本文档定义 AGENTS.md 的内容结构、生成规则和多平台适配机制。AGENTS.md 是面向 AI 助手的指令文件，让 AI 工具打开项目就知道该遵循什么规范。
+
+## 概述
+
+AGENTS.md 放在项目根目录。当 AI 工具（Cursor、Claude Code、OpenCode 等）打开项目时，自动读取此文件，了解项目遵循的规范和工作方式。
+
+## 内容结构
+
+```markdown
+# AI Assistant Instructions
+
+This project follows the **OpenLogos** methodology.
+Read `logos/logos-project.yaml` first to understand the project resource index.
+
+## Project Context
+- Config: `logos/logos.config.json`
+- Resource Index: `logos/logos-project.yaml`
+- Tech Stack: [从 logos-project.yaml 读取]
+
+## Methodology Rules
+1. Never write code without first completing the design documents
+2. Follow the Why → What → How progression
+3. All API designs must originate from scenario sequence diagrams
+4. All code changes must have corresponding API orchestration tests
+5. Use the Delta change workflow for iterations (see logos/changes/ directory)
+
+## Interaction Guidelines
+When the user's request is vague or they ask "what should I do next":
+1. Scan `logos/resources/` to determine the current project phase
+2. Suggest the specific next step based on what's missing
+3. Provide a ready-to-use prompt the user can directly say
+4. Never start generating documents without confirming key information
+
+Phase detection logic:
+- `logos/resources/prd/1-product-requirements/` is empty → suggest Phase 1 (prd-writer)
+- requirements exist but `2-product-design/` is empty → suggest Phase 2 (product-designer)
+- design exists but `3-technical-plan/1-architecture/` is empty → suggest Phase 3 Step 0 (architecture-designer)
+- architecture exists but `3-technical-plan/2-scenario-implementation/` is empty → suggest Phase 3 Step 1 (scenario-architect)
+- scenarios exist but `logos/resources/api/` is empty → suggest Phase 3 Step 2 (api-designer + db-designer)
+- API exists but `logos/resources/test/` is empty → suggest Phase 3 Step 3a (test-writer)
+- test cases exist but `logos/resources/scenario/` is empty → suggest Phase 3 Step 3b (test-orchestrator, API projects only)
+- All above exist → suggest Phase 3 Step 4 (code generation)
+- code generated but `logos/resources/verify/` is empty → suggest Phase 3 Step 5 (run tests then `openlogos verify`)
+
+## Active Skills
+[根据 `logos.config.json` 的 `aiTool` 字段动态生成]
+
+当 aiTool = "cursor" 时，列出 `.cursor/rules/` 下部署的 `.mdc` 文件：
+- `skills/prd-writer` — `.cursor/rules/prd-writer.mdc`
+- `skills/product-designer` — `.cursor/rules/product-designer.mdc`
+- ...（共 12 项）
+
+当 aiTool = "claude-code" 或 "other" 时，列出 `logos/skills/` 下部署的 `SKILL.md` 文件：
+- `skills/prd-writer` — `logos/skills/prd-writer/SKILL.md`
+- `skills/product-designer` — `logos/skills/product-designer/SKILL.md`
+- ...（共 12 项）
+
+## Conventions
+- [从 logos-project.yaml 的 conventions 段读取]
+- When writing Markdown files that contain triple-backtick code blocks inside other code blocks, use 4-backtick fences (````) for the outer block
+```
+
+## 生成规则
+
+### 数据来源
+
+AGENTS.md 的内容从以下文件中自动提取：
+
+| 字段 | 来源 |
+|------|------|
+| Tech Stack | `logos-project.yaml` → `tech_stack` |
+| Active Skills | `logos.config.json` → `aiTool` 字段决定路径前缀 + 扫描项目中已部署的 Skills |
+| Conventions | `logos-project.yaml` → `conventions` |
+| Methodology Rules | 固定内容（OpenLogos 核心规则） |
+
+### 核心规则（固定内容）
+
+以下规则在所有 OpenLogos 项目中一致，不可自定义：
+
+1. Never write code without first completing the design documents
+2. Follow the Why → What → How progression
+3. All API designs must originate from scenario sequence diagrams
+4. All code changes must have corresponding API orchestration tests
+5. Use the Delta change workflow for iterations
+6. All generated test code must include an OpenLogos reporter (see spec/test-results.md)
+
+### 生成时机
+
+- `openlogos init`：初始化项目时首次生成（含 Active Skills 段，Skills 同步部署）
+- `openlogos sync`：手动触发重新生成（当项目配置变化时，同时重新部署 Skills 并刷新 Active Skills 段）
+- `project-init` Skill：AI 初始化项目时生成
+
+## 多平台适配
+
+不同 AI 工具使用不同的指令文件名，但内容一致：
+
+| 工具 | 指令文件 | Skills 部署位置 | 处理方式 |
+|------|---------|---------------|---------|
+| **Cursor** | `AGENTS.md`（原生支持） | `.cursor/rules/*.mdc` | `init` / `sync` 自动部署 |
+| **Claude Code** | `CLAUDE.md` | `logos/skills/*/SKILL.md` | `init` / `sync` 自动部署 |
+| **OpenCode** | `AGENTS.md` | `logos/skills/*/SKILL.md` | `init` / `sync` 自动部署 |
+| **GitHub Copilot** | `.github/copilot-instructions.md` | 规划中 | Phase 1.5 |
+
+`openlogos sync` 命令会同时生成所有需要的指令文件，确保不同 AI 工具看到的指令一致。
+
+## 与 logos-project.yaml 的关系
+
+| 文件 | 格式 | 受众 | 内容 |
+|------|------|------|------|
+| `logos-project.yaml` | 结构化 YAML | AI + 工具 | 资源索引、技术栈、约定 |
+| `AGENTS.md` | 自然语言 Markdown | AI 助手 | 行为指令、规则、Skill 列表 |
+
+两者互补：AGENTS.md 引导 AI 去读 logos-project.yaml，logos-project.yaml 提供结构化数据。

package/spec/change-management.md

@@ -0,0 +1,197 @@
+# Delta 变更管理规范
+
+> 版本：0.3.0
+>
+> 本文档定义 OpenLogos 的 Delta 变更管理机制。每次功能迭代或 Bug 修复，先创建变更提案，审核通过后再合并回主文档。确保变更过程可追溯、可审核、可回滚。
+
+## 核心原则
+
+1. **不直接修改主文档**：每次变更先在 `logos/changes/` 中创建提案
+2. **影响分析先行**：在 `proposal.md` 中明确变更范围
+3. **按需传播**：不是每次都全链路更新，只更新受影响的环节
+4. **归档留痕**：变更完成后归档，保留完整历史
+
+## 目录结构
+
+```
+project-root/
+└── logos/
+    ├── resources/                    # 主文档（当前已生效的"真相"）
+    │
+    └── changes/                      # 变更提案工作区
+        ├── add-remember-me/          # 一个变更提案
+        │   ├── proposal.md           # 变更说明
+        │   ├── tasks.md              # 实现任务清单
+        │   └── deltas/               # 增量修改（Delta）
+        │       ├── prd/
+        │       ├── api/
+        │       ├── database/
+        │       └── scenario/
+        │
+        └── archive/                  # 已完成变更的历史归档
+            └── add-remember-me/
+```
+
+## 文件规范
+
+### proposal.md
+
+变更说明文档，必须包含：
+
+```markdown
+# 变更提案：[变更名称]
+
+## 变更原因
+[为什么要做这个变更？来源于哪个需求/反馈/Bug？]
+
+## 变更范围
+- 影响的需求文档：[列表]
+- 影响的功能规格：[列表]
+- 影响的业务场景：[列表]
+- 影响的 API：[列表]
+- 影响的 DB 表：[列表]
+
+## 变更概述
+[用 1-3 段话概述具体改什么]
+```
+
+### tasks.md
+
+实现任务清单，按 Phase 组织：
+
+```markdown
+# 实现任务
+
+## Phase 1: 文档变更
+- [ ] 更新需求文档的用户故事和验收条件
+- [ ] 更新产品设计文档的功能规格
+
+## Phase 2: 设计变更
+- [ ] 更新 HTML 原型
+- [ ] 更新场景时序图
+- [ ] 更新 API YAML
+- [ ] 更新 DB DDL
+
+## Phase 3: 编排与代码
+- [ ] 更新 API 编排测试用例
+- [ ] 实现代码变更
+- [ ] 部署到测试环境
+- [ ] 运行编排验收
+```
+
+### deltas/ 目录
+
+增量修改文件，使用标记格式：
+
+```markdown
+## ADDED — [新增内容标题]
+[新增的完整内容]
+
+## MODIFIED — [修改内容标题]
+[修改后的完整内容，替换主文档中同名章节]
+
+## REMOVED — [删除内容标题]
+[说明删除原因]
+```
+
+Delta 文件的目录结构映射主文档目录：
+- `deltas/prd/` → 对应 `logos/resources/prd/` 的变更
+- `deltas/api/` → 对应 `logos/resources/api/` 的变更
+- `deltas/database/` → 对应 `logos/resources/database/` 的变更
+- `deltas/scenario/` → 对应 `logos/resources/scenario/` 的变更
+
+## 变更工作流
+
+```
+1. 创建变更提案（CLI）
+   └── openlogos change {slug}
+   └── 生成 logos/changes/{slug}/proposal.md + tasks.md + deltas/
+
+2. AI 辅助填写提案（change-writer Skill）
+   └── AI 分析影响范围，填写 proposal.md 和 tasks.md
+
+3. 按 tasks.md 逐项产出 Delta 文件（各阶段 Skill）
+   └── 每完成一项任务，将增量变更写入 deltas/ 对应子目录
+
+4. 审核变更提案
+   └── 团队/自审 proposal.md 和 delta 文件
+
+5. 生成合并指令（CLI）
+   └── openlogos merge {slug}
+   └── 扫描 deltas/，生成 MERGE_PROMPT.md
+
+6. AI 执行合并（merge-executor Skill）
+   └── AI 读取 MERGE_PROMPT.md，逐个 delta 合并到主文档
+
+7. 归档变更（CLI）
+   └── openlogos archive {slug}
+   └── 将 logos/changes/{slug}/ 移入 logos/changes/archive/
+```
+
+## 变更传播规则
+
+不是每次变更都需要全链路更新。根据变更类型决定影响范围：
+
+| 变更类型 | 最少需要更新 | 说明 |
+|---------|------------|------|
+| 需求级变更 | 全链路 | 需求变了，所有下游都可能受影响 |
+| 设计级变更 | 原型 + 场景 + API/DB + 编排 + 代码 | 需求不变，实现方案调整 |
+| 接口级变更 | API/DB + 编排 + 代码 | 设计不变，接口细节调整 |
+| 代码级修复 | 代码 + 重新验收 | Bug 修复，不涉及设计变更 |
+
+## Git 集成
+
+- 每个变更提案对应一个 Git 分支：`change/{change-name}`
+- 分支合并时，`logos/changes/{change-name}/` 同步移入 `logos/changes/archive/`
+- 重大变更在文档顶部的"最后更新"时间戳中标注
+- `logos/changes/archive/` 提供完整变更历史
+
+## MERGE_PROMPT.md 文件规范
+
+`openlogos merge` 命令自动生成的指令文件，结构如下：
+
+```markdown
+# Merge Instruction
+
+## 变更提案
+- 提案名称：{slug}
+- 提案目录：logos/changes/{slug}/
+
+## 提案内容
+[从 proposal.md 中读取的完整内容]
+
+## 需要合并的 Delta 文件
+
+### 1. {delta-relative-path}
+- Delta 文件：`logos/changes/{slug}/deltas/{category}/{file}`
+- 目标目录：`logos/resources/{category}/`
+- 操作：读取 delta 中的 ADDED / MODIFIED / REMOVED 标记，合并到目标目录中对应的主文档
+
+## 执行要求
+1. 逐个 Delta 文件处理，每处理完一个报告修改摘要
+2. 对于 ADDED 标记：在主文档的指定位置插入新内容
+3. 对于 MODIFIED 标记：替换主文档中同名章节的内容
+4. 对于 REMOVED 标记：从主文档中删除对应章节
+5. 保持主文档的原有格式和风格
+6. 如果主文档有"最后更新"时间戳，同步更新
+7. 所有变更完成后，列出修改清单
+8. 完成后提醒用户运行 `openlogos archive {slug}`
+```
+
+## CLI 命令
+
+```bash
+# 创建变更提案
+openlogos change add-remember-me
+
+# 生成合并指令（由 AI 执行实际合并）
+openlogos merge add-remember-me
+
+# 归档已完成的变更
+openlogos archive add-remember-me
+```
+
+## AI Skills 集成
+
+- **change-writer**：在 `openlogos change` 后使用，辅助填写 proposal.md 和 tasks.md
+- **merge-executor**：在 `openlogos merge` 后使用，读取 MERGE_PROMPT.md 执行实际合并

package/spec/directory-convention.md

@@ -0,0 +1,123 @@
+# 目录结构约定
+
+> 版本：0.3.0
+>
+> 本文档定义遵循 OpenLogos 方法论的项目应采用的标准目录结构。统一的目录结构让 AI 工具和团队成员都能快速定位资源。
+
+## 标准项目结构
+
+```
+project-root/
+├── AGENTS.md                   # AI 助手指令（自动生成，根目录）
+│
+├── logos/                      # OpenLogos 方法论资产（独立收纳）
+│   ├── logos.config.json       # 项目配置（OpenLogos 规范）
+│   ├── logos-project.yaml      # AI 协作索引（OpenLogos 规范）
+│   │
+│   ├── resources/              # 研发资源文档（当前已生效的"真相"）
+│   │   ├── prd/                # 产品文档
+│   │   │   ├── 1-product-requirements/    # Phase 1: 需求文档
+│   │   │   ├── 2-product-design/
+│   │   │   │   ├── 1-feature-specs/       # Phase 2: 功能规格
+│   │   │   │   └── 2-page-design/         # Phase 2: 页面设计 + HTML 原型
+│   │   │   └── 3-technical-plan/
+│   │   │       ├── 1-architecture/        # Phase 3: 架构与技术选型
+│   │   │       └── 2-scenario-implementation/  # Phase 3: 场景实现文档
+│   │   ├── api/                           # Phase 3: OpenAPI YAML
+│   │   ├── database/                      # Phase 3: SQL DDL
+│   │   ├── test/                          # Phase 3: 测试用例规格（Markdown）
+│   │   ├── scenario/                      # Phase 3: API 编排测试（JSON）
+│   │   └── verify/                        # Phase 3: 测试验收结果（JSONL + 报告）
+│   │
+│   └── changes/                # 变更提案工作区
+│       ├── {change-name}/      # 进行中的变更提案
+│       │   ├── proposal.md
+│       │   ├── tasks.md
+│       │   └── deltas/
+│       └── archive/            # 已完成变更的历史归档
+│
+└── src/                        # 源代码（结构由项目技术栈决定）
+```
+
+OpenLogos 的所有方法论资产收纳在 `logos/` 目录下，与项目自身代码和配置彻底分离。`AGENTS.md`（及 `CLAUDE.md`）保留在项目根目录，因为 AI 工具要求指令文件位于根目录。
+
+## 目录职责
+
+### logos/
+
+OpenLogos 方法论的统一入口。包含配置文件、研发资源文档和变更管理。
+
+### logos/resources/
+
+存放所有研发资源文档，是项目当前已生效的"真相源"。按 OpenLogos 三层推进模型组织：
+
+| 子目录 | 对应阶段 | 内容 |
+|--------|---------|------|
+| `prd/1-product-requirements/` | Phase 1: WHY | 需求文档、用户故事、竞品分析 |
+| `prd/2-product-design/1-feature-specs/` | Phase 2: WHAT | 功能规格、信息架构、设计规范 |
+| `prd/2-product-design/2-page-design/` | Phase 2: WHAT | 页面设计文档 + HTML 原型 |
+| `prd/3-technical-plan/1-architecture/` | Phase 3: HOW | 整体架构、技术选型 |
+| `prd/3-technical-plan/2-scenario-implementation/` | Phase 3: HOW | 业务场景文档（时序图 + 步骤说明） |
+| `api/` | Phase 3: HOW | OpenAPI YAML 规格文件 |
+| `database/` | Phase 3: HOW | SQL DDL 设计文件 |
+| `test/` | Phase 3: HOW | 单元测试 + 场景测试用例规格（Markdown） |
+| `scenario/` | Phase 3: HOW | API 编排测试用例（JSON，仅 API 项目） |
+| `verify/` | Phase 3: HOW | 测试运行结果（JSONL）+ 验收报告（Markdown） |
+
+### logos/changes/
+
+变更提案工作区。每次功能迭代或 Bug 修复，先在这里创建变更提案，审核通过后再合并回主文档。详见 [change-management.md](./change-management.md)。
+
+### logos.config.json 与 logos-project.yaml
+
+- `logos/logos.config.json`：项目配置文件，定义文档模块的路径和匹配模式
+- `logos/logos-project.yaml`：AI 协作索引，为 AI 助手提供项目全局上下文
+
+两个文件都放在 `logos/` 目录下。
+
+## 文件命名约定
+
+### 文档文件
+
+- 使用 `{序号}-{英文名}.md` 格式：`01-requirements.md`
+- 序号用于控制显示顺序
+- HTML 原型使用 `{序号}-{英文名}-prototype.html` 格式
+- 设计文档与原型成对出现：`03-homepage-design.md` + `03-homepage-prototype.html`
+
+### API 文件
+
+- 按领域分文件：`auth.yaml`、`payment.yaml`、`license.yaml`
+- 使用 OpenAPI 3.0 YAML 格式
+
+### 数据库文件
+
+- 完整 Schema：`{project-name}.sql`
+- 或按领域分文件：`auth.sql`、`payment.sql`
+
+### 测试用例规格文件
+
+- 按场景分文件：`S01-test-cases.md`、`S02-test-cases.md`
+- 使用 Markdown 格式，包含单元测试和场景测试的用例设计
+- 每个文件对应一个场景编号，覆盖该场景的所有测试层级
+
+### 场景文件
+
+- 按场景分文件：`user-auth.json`、`payment-flow.json`
+- 使用 JSON 格式定义 API 编排
+
+### 验收文件
+
+- 测试结果：`test-results.jsonl`（JSONL 格式，每行一个用例结果）
+- 验收报告：`acceptance-report.md`（由 `openlogos verify` 自动生成）
+- 详细格式定义见 [test-results.md](./test-results.md)
+
+## 可选目录
+
+根据项目需要，可以添加以下目录：
+
+| 目录 | 用途 |
+|------|------|
+| `logos/resources/image/` | 产品图片资源（截图、图标等） |
+| `logos/resources/context/` | 额外的 AI 上下文文件 |
+| `docs/` | 面向用户的文档（部署文档、使用手册等） |
+| `scripts/` | 开发脚本 |

package/spec/logos-project.md

@@ -0,0 +1,135 @@
+# logos-project.yaml 规范
+
+> 版本：0.3.0
+>
+> logos-project.yaml 是 OpenLogos 项目的 AI 协作索引文件。它为 AI 助手提供项目的全局上下文，让 AI 打开项目就知道该读哪些资料、项目用了什么技术栈、遵循什么约定。
+
+## 文件位置
+
+`logos/logos-project.yaml`（位于 `logos/` 目录下）
+
+## 字段定义
+
+### 顶层字段
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `project` | object | 是 | 项目基本信息 |
+| `tech_stack` | object | 是 | 技术栈描述 |
+| `resource_index` | array | 是 | 资源索引列表 |
+| `conventions` | array | 否 | 项目约定 |
+
+### project
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `name` | string | 是 | 项目名称 |
+| `description` | string | 是 | 项目一句话描述 |
+| `methodology` | string | 否 | 遵循的方法论（默认 "OpenLogos"） |
+
+### tech_stack
+
+自由格式的键值对，描述项目使用的技术栈。推荐包含以下 key：
+
+| Key | 说明 | 示例 |
+|-----|------|------|
+| `framework` | 主框架 | "Astro 5.x" |
+| `language` | 主语言 | "TypeScript" |
+| `hosting` | 部署平台 | "Cloudflare Pages" |
+| `database` | 数据库 | "Supabase (PostgreSQL)" |
+| `auth` | 认证方案 | "Supabase Auth" |
+
+### external_dependencies
+
+数组，声明项目依赖的外部服务及其测试策略。在架构设计阶段（S12）确定，供编排测试阶段（S06）自动消费。
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `name` | string | 是 | 外部依赖名称（如"邮件服务"、"图形验证码"） |
+| `provider` | string | 是 | 具体服务商（如"SendGrid"、"reCAPTCHA"） |
+| `used_in` | array | 是 | 涉及的场景列表（如 `["S01-用户注册", "S03-忘记密码"]`） |
+| `test_strategy` | string | 是 | 测试策略枚举值（见下表） |
+| `test_config` | string | 是 | 测试策略的具体配置说明 |
+
+`test_strategy` 枚举值：
+
+| 值 | 说明 | 典型场景 |
+|----|------|---------|
+| `test-api` | 测试环境提供后门 API 获取验证码/回调等 | 邮件验证码、短信验证码 |
+| `fixed-value` | 特定测试数据使用固定值 | 测试手机号固定验证码 |
+| `env-disable` | 通过环境变量关闭该功能 | 图形验证码、滑块验证 |
+| `mock-callback` | 编排中主动调用模拟回调端点 | 支付回调、Webhook |
+| `mock-service` | 使用本地 mock 服务替代 | OAuth Provider、第三方 API |
+
+### resource_index
+
+数组，每个元素描述一个关键资源文件：
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `path` | string | 是 | 文件相对路径 |
+| `desc` | string | 是 | 一句话描述——告诉 AI 什么场景下需要读这个文件 |
+
+### conventions
+
+数组，每个元素是一条项目约定（字符串格式）。
+
+## 完整示例
+
+```yaml
+project:
+  name: "My SaaS Product"
+  description: "一个基于 OpenLogos 方法论构建的 SaaS 产品"
+  methodology: "OpenLogos"
+
+tech_stack:
+  framework: "Next.js 15"
+  language: "TypeScript"
+  hosting: "Vercel"
+  database: "Supabase (PostgreSQL)"
+  auth: "Supabase Auth"
+  payment: "Paddle"
+
+external_dependencies:
+  - name: "邮件服务"
+    provider: "SendGrid"
+    used_in: ["S01-用户注册", "S03-忘记密码"]
+    test_strategy: "test-api"
+    test_config: "GET /api/test/latest-email?to={email}"
+  - name: "图形验证码"
+    provider: "reCAPTCHA"
+    used_in: ["S01-用户注册", "S02-密码登录"]
+    test_strategy: "env-disable"
+    test_config: "CAPTCHA_ENABLED=false"
+  - name: "支付回调"
+    provider: "Paddle"
+    used_in: ["S05-订阅付费"]
+    test_strategy: "mock-callback"
+    test_config: "POST /api/test/simulate-payment-callback"
+
+resource_index:
+  - path: logos/resources/prd/1-product-requirements/01-requirements.md
+    desc: 产品核心需求文档。涉及产品定位、目标用户、功能需求时必读。
+  - path: logos/resources/prd/2-product-design/1-feature-specs/01-information-architecture.md
+    desc: 信息架构文档。涉及页面结构、导航设计时必读。
+  - path: logos/resources/api/auth.yaml
+    desc: 认证相关 API 规格。涉及登录、注册、OAuth 接口设计时必读。
+  - path: logos/resources/database/schema.sql
+    desc: 数据库完整 Schema。涉及表结构、字段设计、RLS 策略时必读。
+  - path: logos/resources/scenario/user-auth.json
+    desc: 用户认证场景的 API 编排。涉及认证流程验收时必读。
+
+conventions:
+  - "所有 API 路径以 /api/ 开头"
+  - "数据库金额字段使用 INTEGER 存储分值"
+  - "时间字段统一使用 TIMESTAMPTZ"
+  - "每次变更必须先创建 logos/changes/ 变更提案"
+```
+
+## 与 AGENTS.md 的关系
+
+`logos-project.yaml` 是项目资源的结构化索引，`AGENTS.md` 是面向 AI 的自然语言指令。两者互补：
+
+- AGENTS.md 告诉 AI "先读 `logos/logos-project.yaml`"
+- logos-project.yaml 告诉 AI "这个项目有哪些关键文件、什么时候该读"
+- `openlogos sync` 命令会根据 logos-project.yaml 的内容更新 AGENTS.md