@mycodemap/mycodemap 0.5.2-beta.1 → 1.9.0

package/docs/archive/ideation/2026-04-22-harness-rules-entry-docs-optimization-ideation.md

@@ -0,0 +1,102 @@
+---
+date: 2026-04-22
+topic: harness-rules-entry-docs-optimization
+focus: 基于 harness mode 优点与 2026-04 最新 Codex / Claude Code 官方 + 社区实践，重构 rules、AGENTS.md、CLAUDE.md 的职责与加载方式
+mode: repo-grounded
+---
+
+# Ideation: Harness-aligned rules and entry docs optimization
+
+## Grounding Context
+
+### Codebase Context
+
+- [证据] 仓库已经明确把入口文档定义为“强约束 + 路由”，并把 `AGENTS.md` 定义为仓库级强约束、把 `CLAUDE.md` 定义为启动清单与最小操作手册：`AGENTS.md:3`、`AGENTS.md:14`、`AGENTS.md:15`。
+- [证据] `CLAUDE.md` 仍同时承载固定 post-edit 命令、rule-system 默认值与交付清单，已经不只是“入口路由”：`CLAUDE.md:25`、`CLAUDE.md:41`、`CLAUDE.md:59`、`CLAUDE.md:63`、`CLAUDE.md:83`。
+- [证据] `docs/rules/README.md` 已主张“先路由、再按需下钻”，`docs/rules/validation.md` 已主张“按改动类型做最小验证”，与根入口中的“统一大礼包命令”存在张力：`docs/rules/README.md:19`、`docs/rules/validation.md:5`、`docs/rules/validation.md:29`、`docs/rules/validation.md:31`。
+- [证据] 任务分级、可信度自评、代码红线等核心治理内容已在多处重复陈述，truth source 不单一：`AGENTS.md:43`、`AGENTS.md:100`、`AGENTS.md:127`、`docs/rules/engineering-with-codex-openai.md:15`、`docs/rules/engineering-with-codex-openai.md:89`、`docs/rules/engineering-with-codex-openai.md:193`。
+- [推论] 当前问题更像“入口过载 + 多真相竞争”，而不是“规则还不够多”；优化重点应是职责重划与加载路径重写，而不是继续往根文件里加内容。
+
+### External Context
+
+- [证据] OpenAI Codex 官方 `AGENTS.md` 指南强调：指令文件要长期有效、优先写项目特有信息、复杂说明要拆到配套 markdown，并且“保持可快速扫读”；同时建议通过回顾重复错误，把稳定流程沉淀成更专门的技能而不是不断膨胀入口文件。来源：https://developers.openai.com/codex/guides/agents-md 与 https://developers.openai.com/codex/learn/best-practices 。
+- [证据] Claude Code 官方 memory 文档明确建议把共享 memory 控制在约 200 行以内；超过后应拆到额外文件并用 `@path` 导入；同时支持在 `CLAUDE.md` 中直接导入 `AGENTS.md`，以及用 `.claude/rules/` + `paths:` 做按路径加载。来源：https://code.claude.com/docs/en/memory 。
+- [证据] Claude Code 官方 best practices 强调：上下文窗口很快会塞满，长会话性能会下降；应把通用或高频操作下沉为子目录 `CLAUDE.md`、hooks、命令或技能，而不是让根文件继续变长；hooks 适合确定性动作，`CLAUDE.md` 更适合行为指导。来源：https://code.claude.com/docs/en/best-practices 与 https://docs.anthropic.com/en/docs/claude-code/hooks 。
+- [证据] 2026-04-21 的社区语料分析（RepoRails）统计了 28,721 个 coding-agent 项目，发现 instruction 文件只有 27.2% 的原子陈述是真正可执行指令，89.9% 缺少具体构造；同时 37% 的项目已是多 agent 配置，最常见组合之一就是 Claude + Codex。来源：https://dev.to/reporails/the-state-of-ai-instruction-quality-35mn 。
+- [证据] 2026-02-12 的论文《Do AGENTS.md Files Help LLM-Based Code Generation Agents?》指出：上下文文件并非总是提升效果，过量要求会拉低成功率并增加 token 消耗；作者建议只保留执行任务所需的最小要求。来源：https://arxiv.org/abs/2602.11988 。
+- [证据] 高信号社区实践也在收敛到“基础记忆 + hooks/settings + skills/agents/rules 分层”而不是单一超级入口文件。一个近期公开示例把 `CLAUDE.md`、settings、hooks、agents、skills、`rules/` 分成独立治理面。来源：https://github.com/ChrisWiles/claude-code-showcase 。
+
+### Past Learnings
+
+- [推论] 本仓库已经具备 harness 友好的关键机制：`route_by_edit_path`、`soft_gate` / `hard_gate`、场景化验证矩阵、短入口路线图；真正缺的是“谁是 live truth source”的清晰边界，而不是新机制本身：`CLAUDE.md:61`、`CLAUDE.md:62`、`CLAUDE.md:63`、`docs/rules/validation.md:10`、`docs/rules/validation.md:21`。
+- [推论] 因为仓库已经同时面向 Claude 与 Codex，任何继续复制规则到多份入口文件的做法，都会与外部多-agent 收敛趋势正面冲突。
+
+## Ranked Ideas
+
+### 1. One Constitution, Two Adapters
+**Description:** [推论] 把 `AGENTS.md` 收缩为唯一共享“治理宪法”：只保留风险分级、证据协议、改动边界、truth-source map、文档职责分层；把 `CLAUDE.md` 收缩为 Claude 适配层，只保留 `@AGENTS.md`、Claude 专属能力边界、检索顺序、最小入口 checklist。
+**Rationale:** [推论] 这条路最直接利用了 Codex 原生 `AGENTS.md` 与 Claude 官方“`CLAUDE.md` 可导入 `AGENTS.md`”的交集；它把双 agent 共识收敛成一份 shared constitution，再用极薄 adapter 承载每个 harness 的差异。
+**Downsides:** [观点] 初次重写需要明确“什么必须共享、什么必须保留为 Claude/Codex delta”，否则容易把 adapter 又写胖。
+**Confidence:** 96%
+**Complexity:** Medium
+**Status:** Explored
+
+### 2. Validation Decision Tree, Not Post-Edit Bundle
+**Description:** [推论] 把 `CLAUDE.md` 里的“修改后必须执行”改成 1 屏决策树：先判断改动类型，再跳到 `docs/rules/validation.md` 的最小验证矩阵；根文件只保留“如何选路径”，不再内嵌固定大礼包命令。
+**Rationale:** [推论] 这最贴合 harness mode 的优势：让 agent 在当前改动上做最小充分验证，而不是默认加载一整套命令；也能把 `CLAUDE.md:25` 与 `docs/rules/validation.md:5` 的冲突消掉。
+**Downsides:** [观点] 决策树如果写得太抽象，用户会失去“一眼能 copy”的即时性；需要在短小与可执行之间拿捏。
+**Confidence:** 94%
+**Complexity:** Medium
+**Status:** Explored
+
+### 3. Behavior / Enforcement Split
+**Description:** [推论] 明确宣布：`AGENTS.md` / `CLAUDE.md` 只负责行为协议与路由；`.claude/settings*.json`、hooks、`scripts/validate-rules.py`、CI 才负责确定性 enforcement；`docs/rules/*` 解释何时、为何、怎样触发这些护栏。
+**Rationale:** [推论] 这同时对齐了 Claude 官方“technical enforcement 用 settings，behavioral guidance 用 `CLAUDE.md`”与本仓库已有 soft/hard gate 设计；一旦边界清晰，入口文件自然会瘦下来。
+**Downsides:** [观点] 需要重写若干表述，把“必须执行”改成“默认路由 / 真正阻断点”，否则读者会误会要求被削弱。
+**Confidence:** 92%
+**Complexity:** Medium
+**Status:** Explored
+
+### 4. Path-Scoped Governance Packs
+**Description:** [推论] 把高细节治理内容继续下沉到按路径加载的文件：Codex 用更近的 `AGENTS.md`，Claude 用 `.claude/rules/**` 的 `paths:`；根入口只保留“何时去哪个包里读”。
+**Rationale:** [推论] 这是把 progressive disclosure 真正落地成结构，而不是口号。Claude 官方已经给出路径规则机制，Codex 也原生按目录查找 `AGENTS.md`；本仓库正好同时受益。
+**Downsides:** [观点] 如果没有严格的命名和归档规则，治理文件数量会增加，反而形成“散落的小真相”。
+**Confidence:** 90%
+**Complexity:** Medium-High
+**Status:** Unexplored
+
+### 5. Live Rulebook / Archive Demotion
+**Description:** [推论] 显式定义 live governance surface：只认 `AGENTS.md`、`CLAUDE.md`、`docs/rules/README.md` 与活跃 `docs/rules/*`；已完成 rollout、模板参考、历史提案全部改成 reference/archive 身份，并在文件头标出“不可作为当前执行真相”。
+**Rationale:** [推论] 这会直接消灭当前最伤 harness 的问题之一——第二真相来源。对于 agent 来说，“哪些文件是历史，哪些文件能执行”比多一条规则更重要。
+**Downsides:** [观点] 文档本身的“身份治理”不性感，短期收益不如入口重写直观；但如果不做，后续任何瘦身都可能再次被旧文档反污染。
+**Confidence:** 91%
+**Complexity:** Low-Medium
+**Status:** Explored
+
+### 6. Retrospective-Driven Rule Admission
+**Description:** [推论] 新规则只允许通过三种入口进入根治理文档：重复性错误、人工 review 反复发现、或 deterministic hook 仍覆盖不了的高风险缺口；其余内容默认进入 scoped rules、skill、prompt template 或参考文档。
+**Rationale:** [推论] 这直接吸收了 Codex 官方“把重复流程沉淀为技能”的建议，以及社区/论文对“说明文件一旦膨胀就掉质”的共同结论；它能防止这次瘦身后再反弹。
+**Downsides:** [观点] 这是治理纪律，不是一次性重构；需要 owner 持续执行，否则很容易回到“先塞进根文件再说”。
+**Confidence:** 89%
+**Complexity:** Low
+**Status:** Unexplored
+
+## Rejection Summary
+
+| # | Idea | Reason Rejected |
+|---|------|-----------------|
+| 1 | `Root 200-Line Budget` | [推论] 很好的 guardrail，但它更适合作为 #1 / #4 的验收指标，而不是顶层方向。 |
+| 2 | `Command Cookbook Extraction` | [推论] 本质上是 #2 的实现动作，不值得单列为产品级 ideation winner。 |
+| 3 | `Assistant Compatibility Matrix` | [观点] 更像 #1 的附属表格，用于落地 shared constitution，而不是单独战略。 |
+| 4 | `Current-vs-Target Architecture Banner` | [推论] 价值很高，但更像 #4 / #5 的具体机制；单独成项会让 ideation 过碎。 |
+| 5 | `Rule Delta Log / Governance Changelog` | [推论] 是 #5 的配套治理件，不是独立顶层方向。 |
+| 6 | `Deterministic Guardrail Ledger` | [推论] 核心价值已被 #3 吸收；单列会重复“behavior vs enforcement”主轴。 |
+| 7 | `Skill-First Escape Hatch` | [观点] 是 #6 的优先级规则，不是独立结构重写。 |
+| 8 | `Per-Tool Twin Rulebooks` | [推论] 与 Claude 官方 `@AGENTS.md` 导入机制和多-agent single-source 方向相冲突，会扩大漂移面。 |
+| 9 | `Universal Mega Entry File` | [推论] 与 Codex / Claude 官方“短入口 + 分层导入 + 作用域加载”全部背离，是反 harness 方案。 |
+
+## Session Log
+
+- [证据] 2026-04-22：交叉阅读本仓库 `AGENTS.md`、`CLAUDE.md`、`docs/rules/README.md`、`docs/rules/validation.md`、`docs/rules/engineering-with-codex-openai.md`，确认当前痛点是“入口过载 + 多真相竞争”。
+- [证据] 2026-04-22：补充 OpenAI Codex 官方 `AGENTS.md` / best practices、Claude Code 官方 memory / best practices / hooks，以及 2026 社区语料分析与论文证据。
+- [推论] 2026-04-22：最终收敛结论不是“再加更多规则”，而是“重建 single source of truth、把 deterministic enforcement 与行为指导拆开、让作用域加载真正生效”。

package/docs/archive/ideation/2026-04-22-rules-claude-agents-optimization-ideation.md

@@ -0,0 +1,107 @@
+---
+date: 2026-04-22
+topic: rules-claude-agents-optimization
+focus: 基于 harness 模式优点优化 rules、CLAUDE.md 和 AGENTS.md
+---
+
+# Ideation: Rules / CLAUDE.md / AGENTS.md 优化
+
+## Codebase Context
+
+**项目形状**：TypeScript CLI 工具（`@mycodemap/mycodemap`），为 AI 辅助开发提供代码地图与结构化上下文。采用 MVP3 五层架构，构建输出到 `dist/`，CLI 入口为 `dist/cli/index.js`。
+
+**关键痛点**：
+1. **规则重复**：代码红线在 3 处出现（code-quality-redlines.md、AGENTS.md 7.1、engineering-with-codex-openai.md §6），阈值相同但格式不同步
+2. **路径路由缺失**：CLAUDE.md 路由表仅覆盖 5 个 src/ 子目录，遗漏 worker/、cache/、watcher/、plugins/ 等活跃目录
+3. **幽灵命令**：`check:architecture` 和 `check:unused` 是 echo stub，但文档当作真实命令引用
+4. **交付清单无 enforcement**：CLAUDE.md 要求"失败场景+可信度自评"，但无自动化检查点
+5. **双 CLAUDE.md**：根目录与 `.claude/` 各有一份，内容重叠且部分矛盾
+6. **无解决方案归档**：`docs/solutions/` 不存在，知识随会话结束蒸发
+7. **规则自身无审计**：链接失效、命令更名、路径迁移无自动检测
+
+## Ranked Ideas
+
+### 1. 规则去重即活契约 (Single-Source-of-Truth Rules)
+**Description:** 将分散在 3 份文档中的代码红线合并为单一结构化数据源（YAML/JSON），通过生成脚本自动渲染所有 markdown 表格。规则变更时，一次编辑、全处同步。
+**Rationale:** 当前同一规则在 3 处出现，格式不同（AGENTS.md 无"阻断标准"列，engineering-with-codex-openai.md 有"阻断标准"列，code-quality-redlines.md 有"失败后果"列），已存在漂移证据。单一数据源消除同步负担，让规则系统自身可维护。
+**Downsides:** 需要编写和维护生成脚本；迁移期间需人工比对确保无遗漏；新同事需要学习"编辑源文件而非 markdown"的工作流。
+**Confidence:** 90%
+**Complexity:** Medium
+**Status:** Unexplored
+
+### 2. CLAUDE.md 路径路由自动补全
+**Description:** 补全路径路由表缺失的 `src/worker/`、`src/cache/`、`src/watcher/`、`src/plugins/` 映射。同时添加 CI 检查：若新增 `src/*/` 目录而无路由条目，构建失败。
+**Rationale:** 当前 14 个 src/ 子目录中仅 5 个有路由映射。AI 助手触碰未映射目录时要么防御性读取全部规则（烧 token），要么在无知觉中违反约束。自动化检查防止路由表永远滞后于代码现实。
+**Downsides:** 目录归属可能存在争议（如 worker/ 应映射到 architecture-guardrails.md 还是 testing.md）；遗留目录 orchestrator/、core/ 需明确策略。
+**Confidence:** 95%
+**Complexity:** Low
+**Status:** Unexplored
+
+### 3. 替换 Echo Stub 为真实检查
+**Description:** `npm run check:architecture` 和 `check:unused` 当前是 echo 占位符，但 architecture-guardrails.md 将其列为"快速验证"步骤。dependency-cruiser 已在 dependencies 中，应配置真实规则并启用。
+**Rationale:** "幽灵命令"摧毁信任——操作者运行后获得虚假安全感。这是 harness rollout doc 中标记为"已配置"但实际不可用的项目。修复后架构护栏真正生效，每次提交自动验证分层依赖。
+**Downsides:** dependency-cruiser 规则配置需要校准（false positive 可能很多）；可能暴露现有违规需批量清理；knip 仍需安装。
+**Confidence:** 85%
+**Complexity:** Medium
+**Status:** Unexplored
+
+### 4. 可信度自评结构化输出
+**Description:** 当前可信度自评（AGENTS.md 5.1）是纯散文，写后即弃。定义轻量 schema（YAML frontmatter 或 JSON），AI 在任务完成时输出结构化数据，收集为 per-task 日志。
+**Rationale:** 从"荣誉系统"转变为可分析数据集。长期可识别：哪些风险标记最常被忽略、哪些"确定信息"后来被证伪、哪些任务类型的自评最不可靠。数据驱动的可信度校准比直觉更可靠。
+**Downsides:** 需要定义和迭代 schema；历史数据无法回溯；存储和索引结构化日志需要基础设施。
+**Confidence:** 80%
+**Complexity:** Medium
+**Status:** Unexplored
+
+### 5. 双 CLAUDE.md 职责澄清/合并
+**Description:** 根目录 `CLAUDE.md`（自称为"入口路由"）与 `.claude/CLAUDE.md`（自称为"项目特定指令"）内容重叠且部分矛盾（如交付清单项目不同、TDD 要求表述不同）。需明确职责分割或合并为单一入口。
+**Rationale:** 每次新会话都要在脑中协调两份"主文档"，决策疲劳真实存在。根目录 CLAUDE.md 说"只做入口路由"却包含路由表、规则默认值、dogfood 命令、交付清单——它实际上在做 `.claude/CLAUDE.md` 的事。
+**Downsides:** 合并可能丢失 Claude Code 自动读取 `.claude/CLAUDE.md` 的便利性；分割需要精心设计边界，否则会变成"三份文档"问题。
+**Confidence:** 85%
+**Complexity:** Low
+**Status:** Unexplored
+
+### 6. 解决方案归档 (Post-Task Diff as Institutional Memory)
+**Description:** 每次 L1+ 任务完成后，将 diff、计划、验证命令、结果捕获为结构化记录存入 `docs/solutions/`。按问题类型、受影响模块、解决模式索引。
+**Rationale:** 当前知识随会话结束而蒸发。`docs/exec-plans/completed/` 有计划记录但无解决方案记录。"我们上次如何解决跨层导入违规？""那个 YAML 正则 prerelease 坑是什么来着？"无法回答。
+**Downsides:** 需要建立记录格式和索引约定；维护负担随时间增长；可能变成垃圾堆（需要定期清理）。
+**Confidence:** 75%
+**Complexity:** Medium
+**Status:** Unexplored
+
+### 7. 规则系统自我审计
+**Description:** 系统定期自动审计自身健康：检查 AGENTS.md / CLAUDE.md 中所有链接是否有效、引用的命令是否存在、路径路由是否覆盖实际目录、每条规则是否有对应自动化检测。生成"规则健康报告"。
+**Rationale:** 规则自身也会腐烂——链接失效（如 AGENTS.md §6 引用 `analyze` 命令参数可能已变化）、命令更名、路径迁移、阈值过时。当前是"被动修复"模式，发现问题才修复。主动审计防止规则系统悄悄失效。
+**Downsides:** 审计规则本身也需要维护；可能产生误报（如某些链接故意指向外部资源）；需要决定审计频率和触发条件。
+**Confidence:** 70%
+**Complexity:** Medium
+**Status:** Unexplored
+
+## Rejection Summary
+
+| # | Idea | Reason Rejected |
+|---|------|-----------------|
+| 1 | 单文件真相源（YAML 替换 AGENTS.md + CLAUDE.md + ARCHITECTURE.md） | 过于激进，会破坏现有工作流；#1 已覆盖规则去重痛点 |
+| 2 | 规则数据库（SQLite/JSON） | 过度工程化，500 行规则不需要数据库查询能力 |
+| 3 | 路径路由自动推导 | 有趣但复杂；静态补全 + CI 检查（#2）更务实 |
+| 4 | Harness 可执行化（TypeScript 模块） | 工程量大；当前核心痛点是同步而非可执行性 |
+| 5 | Harness MCP Server | 同 #4，范围过大，不适合当前阶段 |
+| 6 | Harness 即测试框架 | 同 #4，当前阶段不适用 |
+| 7 | 文档漂移自动检测修复 | 价值高但实现复杂，需解析 markdown 中代码片段 |
+| 8 | 自收缩文档系统 | "零引用"不等于"无价值"，误伤风险高 |
+| 9 | 活架构（自动生成 ARCHITECTURE.md） | 设计决策和迁移计划无法从代码自动生成 |
+| 10 | TODO-DEBT 激活 | 问题真实但范围小，当前优先级不高 |
+| 11 | 自动可信度回填（基于执行轨迹） | 太复杂，需大量基础设施；#4 更务实 |
+| 12 | 自动验证交付（git post-commit） | 被 #4 部分覆盖，实现复杂 |
+| 13 | 验证命令依赖图（DAG） | `check:all` 硬编码问题不严重 |
+| 14 | Agent 性能遥测 | 数据驱动好，但当前更紧迫的是修复规则系统 |
+| 15 | 规则变更金丝雀流水线 | 高杠杆但复杂，适合未来考虑 |
+| 16 | Context Injection API | 太抽象，项目已有 CodeMap CLI |
+| 17 | 类型化文档（TypeScript 接口生成 md） | 与 #1 类似但更局限 |
+| 18 | 自动任务分级 | L0-L3 主观判断难完全自动化 |
+| 19 | 自我修复验证（ESLint auto-fix 扩展） | ESLint --fix 已存在，增量价值有限 |
+| 20 | 失败场景注册表 | 范围较小，当前优先级不高 |
+
+## Session Log
+
+- 2026-04-22: Initial ideation — 40 raw candidates generated across 4 frames (user pain, inversion/automation, assumption-breaking, leverage), 7 survivors after adversarial filtering

package/docs/brainstorms/2026-04-22-rules-entry-docs-phase1-structure-consolidation-requirements.md

@@ -0,0 +1,110 @@
+---
+date: 2026-04
+topic: rules-entry-docs-phase1-structure-consolidation
+---
+
+# Rules 入口文档一期结构收敛
+
+## Problem Frame
+
+当前仓库存在三层入口文档面：`AGENTS.md`、根 `CLAUDE.md`、`.claude/CLAUDE.md`。它们在治理规则、执行流程、验证要求和交付约束上存在交叠，导致 agent 和人类贡献者难以快速判断：
+
+- 哪份文档才是权威来源
+- 哪份文档只是入口路由
+- 被移出的内容应该落到哪里维护
+
+本期要解决的问题不是“规则不够多”，而是“入口面职责不清、共享真相源不清、入口文档容易再次膨胀”。第一阶段因此聚焦**结构收敛**：先把三层入口文档的角色和内容归宿切清，再把后续信任修复、自审机制、历史文档治理等议题留给后续阶段。
+
+| 文档 | 一期目标角色 | 允许内容 | 必须移出 |
+|---|---|---|---|
+| `AGENTS.md` | 严格宪法 | 风险分级、证据协议、文档职责、改动边界、交付底线 | 操作清单、工具专属适配、长命令列表 |
+| `CLAUDE.md` | 纯路由页 | 加载顺序、去哪读下一份文档、去哪找验证规则 | 策略正文、命令清单、默认值、dogfood、交付 checklist |
+| `.claude/CLAUDE.md` | 超薄 adapter | 仅 Claude 专属导入/适配差异 | 通用执行规则、TDD/commit/验证政策、第二套手册 |
+
+## Requirements
+
+**权威模型**
+
+- R1. `AGENTS.md` 必须成为仓库级治理主题的唯一权威来源，覆盖风险分级、证据协议、文档职责分层、改动边界与交付底线。
+- R2. 根 `CLAUDE.md` 必须收缩为纯路由页，只负责告诉 agent 去哪里读，不再作为独立规则面存在。
+- R3. `.claude/CLAUDE.md` 必须收缩为 Claude 专属 adapter，只保留 Claude 需要的导入或装配差异。
+- R4. 每一条规范性要求必须只有一个权威文件；其他入口文档只允许链接或导入，不允许复述为第二套规则面。
+- R5. 本阶段采用零重复原则：入口文档之间不保留提醒式摘要、简化 checklist 或重复政策条目。
+
+**内容归宿**
+
+- R6. 本阶段从 `AGENTS.md`、`CLAUDE.md`、`.claude/CLAUDE.md` 中移出的内容，必须在同一轮迁移到现有文档归宿，不允许留下悬空 `TODO` 作为规范性承接。
+- R7. 本阶段只复用现有文档体系承接迁移内容，例如 `docs/rules/*.md`、`AI_GUIDE.md`、`ARCHITECTURE.md`，不新增中间治理文档。
+- R8. 验证顺序、验证命令、gate 说明等操作性内容，必须归入现有验证或工程规则文档，不再停留在三份入口文档中。
+- R9. 工具发现、命令速查、dogfood、使用提示等内容，必须归入现有 AI 指南或其他既有归宿，不再停留在三份入口文档中。
+- R10. `AGENTS.md` 不得承接从两份 `CLAUDE` 文档移出的操作性细节；宪法层必须保持窄而稳定。
+- R11. 本阶段交付物必须明确给出“被移出内容 → 新归宿文件”的映射，保证后续维护者知道去哪里编辑。
+
+**路由与可发现性**
+
+- R12. 重构完成后，无论从 `AGENTS.md`、根 `CLAUDE.md` 还是 `.claude/CLAUDE.md` 开始，贡献者都应能快速回答三个问题：哪份是权威、下一步去哪读、规则变更时该改哪一份。
+- R13. 收敛后的入口面必须同时保持对 Codex 风格 `AGENTS.md` 读取和 Claude 专属 adapter 加载方式的可发现性。
+- R14. 路由面必须保持简洁，表达导航关系而不是重新长成第二本执行手册。
+
+**阶段范围控制**
+
+- R15. 第一阶段只解决结构角色澄清与内容迁移，不要求同时完成治理自审、自动生成表格或文档防漂移系统。
+- R16. 第一阶段不新增治理中间层、生成式文档系统或新的规则承接机制。
+- R17. 第一阶段不要求重写所有规则本身；只在消除重复、明确权威和修正归宿所必需时调整措辞。
+- R18. 第一阶段不以“完全修复 ghost commands / 验证信任 / archive 身份治理”为成功前提，除非这些问题会阻断结构迁移本身。
+
+## Success Criteria
+
+- [ ] `AGENTS.md` 只保留宪法级内容，不再承载操作清单或工具专属执行细节
+- [ ] 根 `CLAUDE.md` 变为纯路由页，不再内嵌命令清单、默认值、dogfood 或交付 checklist
+- [ ] `.claude/CLAUDE.md` 只保留 Claude 专属 adapter 内容，不再重复通用执行政策
+- [ ] 三份入口文档之间不存在重复的规范性要求
+- [ ] 每一类从入口文档移出的内容都有明确且现成的目标文档承接
+- [ ] 本阶段未引入新的中间治理文档
+- [ ] 维护者能从任一入口文档快速定位权威文件与下一步阅读路径
+
+## Scope Boundaries
+
+- 不在本阶段新增新的治理承接文档
+- 不在本阶段引入文档生成器、自审框架或重复检测自动化
+- 不在本阶段重写全部规则正文，只做必要的归宿与措辞收敛
+- 不把 ghost commands、验证可信度或 archive/live 身份治理作为本阶段主目标
+- 不把 `.claude/CLAUDE.md` 扩展为第二套 Claude 独立规则手册
+
+## Key Decisions
+
+- **D1** `AGENTS.md` 定位为严格宪法：仓库级规范只在这里定权
+- **D2** 根 `CLAUDE.md` 定位为纯路由页：负责导航，不负责再定义规则
+- **D3** `.claude/CLAUDE.md` 定位为超薄 adapter：只保留 Claude 专属差异
+- **D4** 零重复是硬约束：入口文档之间不保留摘要式复述
+- **D5** 所有被移出内容必须同轮迁移，且只允许迁移到现有文档体系
+- **D6** 第一阶段是结构收敛，不是一次性解决全部治理问题
+
+## Alternatives Considered
+
+- **根 `CLAUDE.md` 继续保留轻量执行面**：被否决，因为会继续让路由页承担规则职责
+- **`.claude/CLAUDE.md` 保留完整 Claude 手册**：被否决，因为会继续制造第二套权威入口
+- **`AGENTS.md` 承接更多执行框架或 checklist**：被否决，因为会让宪法层重新膨胀成超级入口
+
+## Dependencies / Assumptions
+
+- 现有 `docs/rules/*.md`、`AI_GUIDE.md`、`ARCHITECTURE.md` 会继续作为 live 文档面存在
+- Claude 侧可以通过 adapter/import 方式消费共享规则，而不必复制整套规则正文
+- 后续规划阶段可以逐项确认“旧 section → 新文件”的精确映射与改写顺序
+
+## Outstanding Questions
+
+### Resolve Before Planning
+
+_None — 本阶段的产品级结构决策已收敛。_
+
+### Deferred to Planning
+
+- [Technical] 根 `CLAUDE.md` 最终采用什么路由表现形式最清晰：路径表、场景表、还是最小导航清单
+- [Technical] `.claude/CLAUDE.md` 采用何种最小导入/引用写法，既满足 Claude 使用，又不形成第二套文本面
+- [Technical] 现有入口文档中的每个 section 应如何一对一映射到现有目标文档
+- [Technical] 为保证迁移后仍可发现，是否需要同步微调 `docs/rules/README.md` 或 `AI_GUIDE.md` 的导航表达
+
+## Next Steps
+
+-> `/ce:plan` for structured implementation planning

package/docs/brainstorms/999.1-mycodemap-init-enhancements-requirements.md

@@ -0,0 +1,166 @@
+---
+date: 2026-04-20
+topic: mycodemap-init-enhancements
+---
+
+# mycodemap init 增强：项目状态收敛器
+
+## Problem Frame
+
+当前 `mycodemap init` 命令仅在项目根目录创建一个 `mycodemap.config.json` 文件。随着 CodeMap 功能扩展，项目已经出现多类 AI 助手基础设施：`.mycodemap/` 工作区、日志目录、workflow 目录、git hooks、AI 护栏规则等。问题不只是“缺少初始化入口”，而是项目状态已经进入半迁移阶段：工具实际行为、文档承诺、配置路径和 `.mycodemap/` 产品心智不再完全一致。
+
+这导致：
+
+- 新用户不清楚 CodeMap 生成了哪些文件
+- git hooks 和 AI 规则需要手动复制和配置
+- 配置文件和输出目录的命名不一致（根目录 `mycodemap.config.json` vs `.mycodemap/` 目录）
+- 旧配置、旧目录、已有 hooks、已有 AI 上下文文件等状态被隐式处理，用户无法判断哪些已经完成、哪些需要手动处理
+- `init` 容易给出“初始化完成”的印象，但实际只完成了部分基础设施接入
+
+本需求将 `init` 命令升级为“项目状态收敛器”：先扫描当前仓库状态，识别 config / workspace / hooks / rules / first-run guide 的 drift，再向用户展示将要收敛的差异，最后执行选择的动作并产出可解释的 receipt。成功标准不再是“写出一个配置文件”，而是“用户和后续 AI/CLI 都能知道这个项目的 CodeMap 基础设施处于什么状态、做过什么、还缺什么”。
+
+## Requirements
+
+**状态扫描与收敛**
+
+- R1. `init` 启动时先扫描当前项目状态，包括 `.mycodemap/`、根目录旧配置、旧 `.codemap/`、hooks、rules、首次运行标记和需要人工接入的 AI 上下文文件
+- R2. `init` 将每个被扫描资产分类为明确状态：`missing`、`already-synced`、`migrated`、`installed`、`conflict`、`manual-action-needed` 或 `skipped`
+- R3. 交互式模式下，`init` 在写入文件前展示 reconciliation preview，说明将创建、迁移、覆盖、跳过或要求人工处理的项目
+- R4. `init` 执行后输出 human-readable receipt，并在 `.mycodemap/status/init-last.json` 写入 machine-readable receipt
+- R5. receipt 必须区分“已完成动作”和“仍需人工动作”，不得用单个“初始化完成”掩盖部分完成状态
+- R6. 重复运行 `init` 必须是幂等的：已同步资产显示 `already-synced`，漂移资产显示 `conflict` 或 `manual-action-needed`
+
+**Workspace 集中化**
+
+- R7. `init` 命令创建 `.mycodemap/` 目录作为所有 mycodemap tool-owned 资源的根目录
+- R8. 配置文件命名为 `.mycodemap/config.json`（不再使用根目录的 `mycodemap.config.json` 作为 canonical 配置）
+- R9. `.mycodemap/` 内部使用统一子目录结构：`logs/`、`workflow/`、`rules/`、`hooks/`、`storage/`、`status/`
+- R10. 若根目录已存在旧配置（`mycodemap.config.json` 或 `codemap.config.json`），自动复制内容到 `.mycodemap/config.json`，保留旧文件并在 receipt 中提示用户可删除
+- R11. 清理 `.codemap` → `.mycodemap` 的旧迁移提示，仅保留与本次 root config → `.mycodemap/config.json` 收敛有关的提示
+- R12. 如果旧 `.codemap/` 或旧 storage 路径仍存在，`init` 必须在 receipt 中显式标记为 drift，而不是静默忽略
+
+**Git Hooks 安装与同步**
+
+- R13. `init` 检测目标项目是否为 Git 仓库；若不是，workspace 和 rules 仍可收敛，hooks 状态标记为 `skipped` 或 `manual-action-needed`
+- R14. 若目标项目 `.git/hooks/` 已存在同名 hooks（pre-commit / commit-msg），检测内容差异并提示用户选择：保留、跳过、覆盖或 shim 合并
+- R15. shim 合并策略：`.git/hooks/pre-commit` 和 `commit-msg` 为轻量 shim 脚本，调用 `.mycodemap/hooks/` 下的完整 hooks 实现，保留用户已有的 hooks 逻辑
+- R16. `.mycodemap/hooks/` 下的 hooks 内容为 CodeMap 自身 `.githooks/` 下 hooks 的完整复制
+- R17. 每次运行 `mycodemap init` 时检查 hooks 同步状态（对比文件哈希），如有变化提示用户更新
+- R18. hooks 冲突检测基于文件内容哈希，而非仅文件名存在性
+- R19. hooks 的安装、跳过、冲突和人工处理结果必须写入 receipt
+
+**AI 护栏规则生成与同步**
+
+- R20. `init` 生成内置精简规则集到 `.mycodemap/rules/` 目录（通用型，不依赖项目类型）
+- R21. 规则文件按分类子目录组织：`.mycodemap/rules/commit/`、`.mycodemap/rules/test/`、`.mycodemap/rules/lint/` 等
+- R22. 规则注入通过 CLI 输出提示信息，引导用户手动在 `CLAUDE.md` 或 `AGENTS.md` 中添加引用，不自动修改用户文件
+- R23. CLI 输出必须包含可复制的引用片段，说明应把 `.mycodemap/rules/` 作为 tool-owned rules bundle 引入用户自己的 AI 上下文文件
+- R24. 每次运行 `mycodemap init` 时检查规则文件同步状态，如有变化提示用户更新并显示 diff 预览
+- R25. 规则文件内容参考 CodeMap 自身 `docs/rules/` 下的文档提炼生成
+- R26. 规则同步状态和仍需人工添加的引用动作必须写入 receipt
+
+**init 交互模式**
+
+- R27. 三个子功能（workspace 集中化、hooks 安装、rules 注入）以“一键选择”方式呈现，用户可以一次性勾选/取消要收敛的目标状态
+- R28. 提供 `--yes` 标志跳过交互，使用默认选择全部启用
+- R29. 提供 `--interactive` 标志显式进入交互模式（默认行为）
+- R30. init 流程输出采用“状态收敛器”风格：每项都有明确状态标记（✅ done / ⚠️ manual action / ❌ conflict / ⏭ skipped）
+
+**首次运行引导**
+
+- R31. 首次运行（无配置、无标记文件）时显示精简欢迎信息：init → generate → help
+- R32. 当用户实际运行 init 后，在 init 输出中根据 receipt 展示下一步，而不是固定展示同一套后续步骤
+- R33. 若 receipt 中存在 `manual-action-needed`，后续步骤必须优先展示人工动作（如向 `CLAUDE.md` / `AGENTS.md` 添加规则引用）
+
+**路径兼容性**
+
+- R34. `init` 将 `.mycodemap/config.json` 作为 desired canonical config，并把根目录旧配置视为迁移来源
+- R35. 本 phase 不要求修改非 `init` 命令的路径解析逻辑；如果 downstream 命令仍可能读取旧路径，`init` 必须在 receipt 中将 downstream config readiness 标记为 `manual-action-needed` 或 `conflict`
+- R36. 规划阶段必须验证最小路径变更边界，避免 `init` 创建的新 canonical config 被后续命令忽略
+
+**Git 集成**
+
+- R37. `init` 自动在目标项目的 `.gitignore` 中追加 `.mycodemap/logs/`，确保本地日志不进入版本控制
+- R38. 若 `.gitignore` 中已存在该条目，静默跳过，不重复追加
+- R39. `.gitignore` 的新增、跳过或冲突状态必须写入 receipt
+
+**资产台账与兼容引导**
+
+- R40. `.mycodemap/status/init-last.json` 必须按资产粒度记录最少必要事实：资产类型、ownership、origin、当前状态，以及用于重跑对账的 hash / version 线索；避免后续 rerun 只能依赖启发式猜测
+- R41. receipt 必须显式解释 canonical `.mycodemap/config.json` 与根目录旧配置、旧 storage 路径之间的关系，给出 forward guidance，而不是只报告“发现旧文件”
+- R42. 对于本 phase 内可逆的收敛动作（如配置迁移、hook shim 接入、`.gitignore` 追加），receipt 必须提供简短 rollback hint，帮助用户恢复到执行前的项目状态
+- R43. 本 phase 的 machine-readable receipt 兼作轻量 managed asset ledger，只保留会在 rerun / support / drift 检测中复用的事实，不引入新的独立状态数据库或额外 sync surface
+
+## Success Criteria
+
+- [ ] 全新项目运行 `mycodemap init` 后，终端输出 reconciliation preview 和执行后的 receipt
+- [ ] 全新项目运行 `mycodemap init` 后，`.mycodemap/` 目录包含完整的子目录结构（config.json、logs/、workflow/、rules/、hooks/、storage/）
+- [ ] 已有旧配置（根目录 `mycodemap.config.json`）的项目运行 init，旧配置自动迁移到新位置，旧文件保留但提示删除
+- [ ] 已有旧 `.codemap/` 或旧 storage 路径的项目运行 init，receipt 明确标记 drift 和下一步动作
+- [ ] 非 Git 项目运行 init，workspace / rules 可以完成收敛，hooks 被标记为 `skipped` 或 `manual-action-needed`
+- [ ] Git 项目运行 init，若已有 hooks，用户可选择覆盖/跳过/shim；shim 模式下用户原有 hooks 逻辑不被破坏
+- [ ] 规则文件成功生成到 `.mycodemap/rules/` 子目录，内容符合 CodeMap 自身规则文档的质量标准
+- [ ] `init` 不自动修改 `CLAUDE.md` / `AGENTS.md`，但输出可复制的规则引用片段
+- [ ] `.mycodemap/status/init-last.json` 包含 config、workspace、hooks、rules、gitignore、manual actions 的结构化状态
+- [ ] 重复运行 `mycodemap init` 时，receipt 能基于已记录的资产事实稳定地区分 `already-synced`、`conflict`、`manual-action-needed`
+- [ ] receipt 对已执行的可逆动作提供简短 rollback hint，用户无需阅读源码即可理解如何回退
+- [ ] `npm run check:all` 通过（类型检查 + 测试 + Lint）
+- [ ] init 输出风格与现有 CLI 保持一致（chalk 颜色 + emoji + 中文）
+
+## Scope Boundaries
+
+- 不为 AI 规则创建新的 CLI 子命令（如 `mycodemap sync-rules`）
+- 不修改非 mycodemap 相关的项目文件（如 package.json）
+- 不自动修改用户项目的 `CLAUDE.md` / `AGENTS.md`
+- 不支持非 Git 版本控制系统（如 Mercurial）
+- 不根据项目类型（npm/python/go 等）动态生成不同规则集
+- 不在本 phase 中承诺重写所有非 `init` 命令的配置读取路径；若必要，只允许规划阶段确认最小兼容改动
+- 不在本 phase 中新增 `.mycodemap/exports/` 或 `.mycodemap/assistants/` 目录；当前只要求生成可复制的接入片段
+- 不把 `.mycodemap/status/init-last.json` 扩展为通用状态数据库；仅记录 init 重跑与支持所需的最小事实
+
+## Key Decisions
+
+- **D-00** `init` 是项目状态收敛器：先扫描和解释现状，再执行选择的收敛动作
+- **D-01** 配置文件收到 `.mycodemap/config.json`：简化命名，放在命名空间目录下冲突概率低
+- **D-02** 自动迁移旧配置：零用户操作，复制后提示删除旧文件
+- **D-03** receipt 是成功输出的核心：所有完成、跳过、冲突和人工动作都必须显式呈现
+- **D-05** hooks 通过 `.git/hooks/` 接入：不修改 Git 全局配置，保持项目隔离
+- **D-16** shim 合并策略：轻量 shim 调用 `.mycodemap/hooks/` 的完整实现，不破坏用户已有逻辑
+- **D-17** 非 Git 项目不阻止 workspace / rules 收敛：hooks 以 `skipped` 或 `manual-action-needed` 呈现
+- **D-18** 自动追加 `.mycodemap/logs/` 到 `.gitignore`：防止本地日志污染版本控制
+- **D-19** 两步欢迎流程：未 init 时不展示无法执行的步骤，init 后根据 receipt 展示下一步
+- **D-20** 用户 AI 上下文文件属于 team-owned surface：工具只生成引用片段，不自动改写
+- **D-21** `init-last.json` 兼作轻量 managed asset ledger：记录 ownership / origin / hash / status 等会被 rerun 复用的事实，而不是额外引入独立 ledger 系统
+- **D-22** assistant compatibility pack 先收敛为 receipt 中的 copy-paste 片段：本 phase 不新增 `.mycodemap/exports/` / `.mycodemap/assistants/` 目录面
+- **D-23** 当前 phase 优先显式资产级 reconcile，而不是引入 `Minimal / Guardrails / Team Ready` 之类 profile 抽象，以免遮蔽 drift 与人工动作细节
+
+## Alternatives Considered
+
+- **独立 ledger / manifest 文件面**：有价值，但当前先吸收到 `.mycodemap/status/init-last.json`，避免过早引入第二套状态 surface
+- **assistant compatibility pack 目录化**：长期可能有价值，但当前用 receipt + copy-paste 片段即可满足“不自动改用户文件”的目标
+- **bootstrap profiles（Minimal / Guardrails / Team Ready）**：适合作为后续体验优化；本 phase 先保留资产级选择，确保状态透明优先于预设抽象
+
+## Dependencies / Assumptions
+
+- 目标项目已安装 mycodemap CLI（全局或本地）
+- CodeMap 自身 `.githooks/` 目录存在 `pre-commit` 和 `commit-msg` 作为内置 hooks 源
+- 用户使用支持环境变量或文件引用的 AI 工具（Claude Code、Cursor 等）来消费护栏规则
+- `.mycodemap/status/init-last.json` 是 init 自己的状态 contract，不是全局稳定 public API
+
+## Outstanding Questions
+
+### Resolve Before Planning
+
+_None — all product decisions resolved._
+
+### Deferred to Planning
+
+- [Needs research] 内置 hooks 源文件（`.githooks/pre-commit` 和 `.githooks/commit-msg`）在打包发布后的路径解析方式（相对于 CLI 安装位置）
+- [Technical] shim 脚本的具体实现方式（shell 脚本 vs Node.js 脚本），取决于 `.githooks/` 中现有 hooks 的实现方式
+- [Technical] 规则文件的 diff 预览实现方式（使用内置 diff 还是依赖外部工具）
+- [Technical] `--yes` 和 `--interactive` 选项的 CLI 注册方式（ commander.js 的选项配置）
+- [Technical] downstream 命令读取 `.mycodemap/config.json` 的最小兼容边界，避免本 phase 扩大到全 CLI 路径重构
+
+## Next Steps
+
+-> `/ce:plan` for structured implementation planning

package/docs/exec-plans/README.md

@@ -14,6 +14,9 @@
 - `completed/` 当前包含：
   - `2026-03-03-deps-path-extension-fix.md`
   - `2026-03-03-post-task-plan.md`
+  - `2026-04-17-eatdogfood-codemap-cli.md`
+  - `2026-04-19-prerelease-trusted-publishing-fix.md`
+  - `harness-engineering-rollout.md`
 - `tech-debt/` 当前包含：
   - `2026-03-15-lint-guardrail-gap.md`
 

package/docs/ideation/2026-04-20-mycodemap-init-enhancements-ideation.md

@@ -0,0 +1,96 @@
+---
+date: 2026-04-20
+topic: mycodemap-init-enhancements
+focus: 把 mycodemap init 从“创建根目录配置文件”升级为“项目级 AI 助手基础设施初始化器”
+mode: repo-grounded
+---
+
+# Ideation: mycodemap init enhancements
+
+## Grounding Context
+
+### Codebase Context
+
+- [证据] 当前 `src/cli/commands/init.ts` 主要只处理根目录 `mycodemap.config.json` / `codemap.config.json` 的存在检查、旧配置迁移和默认配置写入。
+- [证据] `src/cli/paths.ts` 仍以根目录配置文件作为发现入口，而 `src/cli/config-loader.ts` 的默认 `output` 已转向 `.mycodemap`，但默认 `storage.outputPath` 仍是 `.codemap/storage`。
+- [证据] `src/cli/first-run-guide.ts` 已把 marker 放进 `.mycodemap/`，但欢迎语仍把 init 叙述成“初始化配置”而不是“初始化 AI 工作区”。
+- [证据] 仓库已经拥有可复用的 `.githooks/`、规则校验脚本、first-run guide、chalk + emoji + 中文 CLI 风格。
+
+### Past Learnings
+
+- [推论] 当前最大的产品问题不是“功能不存在”，而是“看起来成功但其实只做了一部分”。
+- [推论] 半迁移状态应该被显式解释、对账和修复，而不是继续依赖隐式 fallback。
+- [证据] 本 phase 已锁定：不自动修改用户 `CLAUDE.md` / `AGENTS.md`，并要求在 `.mycodemap/` 中集中化 config、rules、workflow、logs 等资产。
+
+### External Context
+
+- [推论] 2024–2026 的主流 AI / dev tooling 明显收敛到“双层结构”：隐藏目录存放 tool-owned 资产，显式文件存放 team-owned / shared rules。
+- [推论] hooks 安装的成熟心智是 ownership、冲突检测、可逆迁移，而不是静默覆盖。
+- [推论] 最贴近市场共识的做法不是自动改用户上下文文件，而是生成 tool-owned bundle + 明确的人工接入片段。
+
+## Ranked Ideas
+
+### 1. Init Reconciler Dashboard
+**Description:** [推论] 让 `mycodemap init` 先扫描 config / workspace / hooks / rules / first-run 状态，再展示统一状态表并执行勾选后的 reconcile，而不是一上来创建文件。
+**Rationale:** [推论] 这是最强的主心智重写：它同时吸收了“状态透明”“半迁移修复”“不新增 sync surface”三条信号，并把 init 从 file-creator 提升为 repo-state reconciler。
+**Downsides:** [观点] 需要先定义稳定的状态模型和 CLI 展示格式，否则实现容易碎片化。
+**Confidence:** 93%
+**Complexity:** Medium
+**Status:** Explored
+
+### 2. Bootstrap Receipt + Managed Asset Ledger
+**Description:** [推论] 每次 init 产出 receipt，并在 `.mycodemap/` 持久化 ledger / manifest，记录配置、hooks、rules、exports、marker 的 ownership、origin、hash、版本、rollback hint 和当前状态。
+**Rationale:** [推论] 这是把“看起来成功但其实没做完”变贵的最直接手段，也为后续 rerun、support、sync、future commands 提供统一事实源。
+**Downsides:** [观点] 若 schema 设计过重，容易提前抽象；需要克制到“只记录会复用的事实”。
+**Confidence:** 90%
+**Complexity:** Medium
+**Status:** Unexplored
+
+### 3. Drift-First Compatibility Bridge
+**Description:** [推论] 把根配置、旧 `.codemap/storage`、旧路径 fallback、旧文档心智全部视为显式 drift；init 负责解释旧世界和新 canonical `.mycodemap/config.json` 的关系，并提供 forward / rollback 指引。
+**Rationale:** [推论] 这是最直击当下 repo 痛点的方向：它不是再加一个功能，而是修复“根配置 vs `.mycodemap` 工作区”的双中心叙事。
+**Downsides:** [观点] 需要同时碰实现、文档和路径叙事；若边界定义不清，会继续扩大兼容负担。
+**Confidence:** 91%
+**Complexity:** Medium
+**Status:** Unexplored
+
+### 4. Ownership-Preserving Hook Contract
+**Description:** [推论] 把 hooks 从“复制文件”升级为 ownership negotiation：优先用 shim / adapter 指向 `.mycodemap/hooks/` 下的 canonical assets，显式处理 adopt / preserve / manual / conflict / rollback。
+**Rationale:** [推论] hooks 是最高杠杆也最高敏感的边界；这个方向兼顾强能力、可逆性和团队信任，且与外部成熟模式一致。
+**Downsides:** [观点] Git 环境差异和已有团队 hooks 形态很多，边缘案例会拖高实现复杂度。
+**Confidence:** 86%
+**Complexity:** Medium-High
+**Status:** Unexplored
+
+### 5. Rules Link Mode + Assistant Compatibility Pack
+**Description:** [推论] 在 `.mycodemap/rules/`、`.mycodemap/exports/`、`.mycodemap/assistants/` 中生成可引用的 rules bundle、copy-paste include blocks、per-tool stubs 和文档片段，而不是自动改 `CLAUDE.md` / `AGENTS.md`。
+**Rationale:** [推论] 这条路最贴近行业共识：隐藏目录归工具，显式上下文归团队；同时把多工具接入和文档同步成本一起压低。
+**Downsides:** [观点] 用户仍需手动完成最后一步粘贴；若提示文案不够强，可能有人觉得“不够自动化”。
+**Confidence:** 88%
+**Complexity:** Medium
+**Status:** Unexplored
+
+### 6. First-Run Concierge + Bootstrap Profiles
+**Description:** [推论] 把 first-run guide 重写成状态驱动的 remediation concierge，并用少量 profile（如 Minimal / Guardrails / Team Ready）承载交互式一键选择。
+**Rationale:** [推论] 这是最低成本修复 mental model 的方法：既改善第一分钟体验，也避免 init 变成一长串低层开关。
+**Downsides:** [观点] profile 设计如果过粗，会掩盖复杂边界；如果过细，又会退化回问卷。
+**Confidence:** 84%
+**Complexity:** Low-Medium
+**Status:** Unexplored
+
+## Rejection Summary
+
+| # | Idea | Reason Rejected |
+|---|------|-----------------|
+| 1 | `.mycodemap` as Agent Control Plane | [推论] 更像 framing，总体价值已被 #3 和 #5 吸收 |
+| 2 | `Manual Action Needed` as success | [推论] 是 #1 / #2 的成功语义，不值得独立成产品方向 |
+| 3 | `Project Safety Contracts` framing | [观点] 叙事强但产品增量弱，更适合后续命名或定位文案 |
+| 4 | `Customs Declaration Lanes` | [推论] 是 status receipt 的隐喻版本，重复度高 |
+| 5 | `Building Commissioning Sheet` | [推论] 与 Reconciler Dashboard / Drift-First 思路重复 |
+| 6 | `Board Game Setup Tray` | [推论] 是 Profiles 的隐喻版，没有新增结构价值 |
+| 7 | `Canonical Locator Map` | [观点] 更像 #2 / #3 的内部机制，而非顶层 ideation winner |
+| 8 | `Migration Journal + Undo Receipts` | [推论] 很有价值，但已折叠进 #2 的 ledger 方案 |
+| 9 | `Capability Matrix for Downstream Commands` | [推论] 值得做，但依赖 #2 的事实层先成立 |
+| 10 | `Portable Hook Adapter Contract` | [推论] 作为 hook 方向的底层机制已吸收到 #4 |
+| 11 | `Doc Snippet Registry` | [推论] 已并入 #5 的 compatibility pack |
+| 12 | `Recovery Partition + Bootloader` | [观点] 类比很强，但太偏实现隐喻，顶层价值已并入 #4 |