easy-coding-harness 0.10.0-beta.9 → 1.0.0-beta.1

package/CHANGELOG.md

@@ -2,10 +2,76 @@
 
 版本号严格使用 `x.y.z`：
 
-- `x`：大的功能迭代；`0.x.x` 表示内测版本
+- `x`：大的功能迭代；带 `-beta.*` 的版本表示预发布版本
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 1.0.0-beta.1
+
+- ANALYSIS 的方案展示改为持久方案回执：后续仍有工具调用时，先前文本只算可能被宿主折叠的
+  过程展示；原生选择返回或迁移调用结束后，最终消息会重新包含核心方案、验收、Workflow、
+  风险与完整 Dev-Spec 链接/路径，不再被一句确认提示覆盖。
+- Guard/Confirm 的取消、超时、空结果或无效结果继续保留 `pending_transition`，并在最终回执中
+  重现完整选择；确认成功会注明接受的分支和目标阶段。Auto 不新增确认或停顿，只把完整
+  Dev-Spec 入口带入同轮下一条持久最终消息。
+- 修复只调整 Agent 展示协议与三平台模板测试，不依赖客户端字符串匹配，不改变状态机、
+  状态 API、任务文件或审批模式语义。
+
+## 1.0.0-beta.0
+
+- 正常修改任务统一使用 `INIT → ANALYSIS → IMPLEMENT → QUALITY → MEMORY → COMPLETE`；
+  QUALITY 在同一候选指纹下编排只读 Review/Verification 双门并汇总一次 Repair Bundle，
+  Fast/Standard/Strict 仅改变证据深度，不再改变状态拓扑。
+- 非 TDD 的 IMPLEMENT 回归纯编码职责，lint/typecheck/test/build 统一由 Verification Gate
+  执行；TDD 的 RED/GREEN/REFACTOR 证据可以在 QUALITY 复用。环境失败留在 QUALITY 重试，
+  用户明确接受检查点后差异时遵从其决策，不自动重跑 Review。
+- 删除新建 `doc` / `analysis` / `report` 只读任务能力：纯对话请求保持 Ready，仓库内文档或
+  配置写入仍走完整状态机。升级会把活动旧只读任务关闭为
+  `legacy-read-only-task-retired`，保留文件和历史。
+- 新增用户显式控制的 `ec-lite`：一次紧凑方案确认后执行最小修改，不生成任务、QUALITY
+  或 MEMORY。活动任务决策由 session 命令锁原子绑定用户看到的 task ID；每次方案生成不可
+  重放 digest，并把当时的 Git 基线一并纳入确认内容；确认时重新校验当前 Git 状态，确认
+  只能执行一次且不能改写基线，完成时校验目标文件的真实变化、范围外改动与 HEAD 漂移。
+  `ec-no-harness` 临时旁路不会清除 Lite 状态或方案。
+- Canonical QUALITY 修复先把当前候选的失败证据写回对应 source task 为 `blocked`，再由
+  IMPLEMENT 仅重开受影响任务；多来源重开先持久化可续跑意图，部分写回失败后可幂等恢复。
+  写回事件必须绑定当前 Harness task、source task、候选指纹、QUALITY attempt 与失败证据，
+  无关 `blocked` 状态不能冒充本轮投影。`execution.jsonl` 的 QUALITY 尝试由状态 API 在两个
+  Gate 结束后一次性 append 并机械校验；repair/replan 按结构化失败类型路由，契约歧义对同轮
+  混合缺陷具有 replan 优先级；候选漂移终结为 cancelled 后强制先回 IMPLEMENT，迟到的旧
+  attempt 证据不会污染新一轮。主动返工与关闭任务同样会终结活动 attempt。
+- Canonical repair 为内容指纹未变化且不依赖变化 source 的仓库追加状态层
+  `quality-carry-forward`，按来源 attempt 和证据索引复用已通过门禁；hard/contract 下游及
+  受影响仓库仍提供当前 attempt 的完整模式级证据。
+- Canonical repair intent 随决策立即持久化，确认边绑定 attempt、双指纹与 affected source；
+  blocked 投影后的候选/配置漂移和部分重开失败都幂等续跑原事务。
+  `add-agent` 遇到项目 Harness 与 CLI 版本不一致时要求先整体 upgrade，避免新旧状态机混装。
+- Adaptive 分级降低误判成本：简单局部修改优先 Fast，普通业务以 Standard 为主，Strict
+  仅在明确高风险与真实复杂度同时存在时触发；未修改仓库、Spec 未选任务和 supermodule
+  子项目不参与抬级。
+- 编码规则强化最近邻风格、最小修改和适度设计：不补无依据防御校验、不为单次 getter
+  return 提取常量、不拆碎方法，不修改无关格式或注释；核心 Java Javadoc 使用多行格式，
+  普通单行说明使用 `//`，逻辑段落使用一个空行分隔。
+- 活动 `REVIEW` / `VERIFICATION` 状态和验收检查点在升级时迁移为 `QUALITY` /
+  `quality_checkpoint`，保留既有审查、验证和历史执行证据。
+- 升级会依据旧安装清单清理已退役的 `ec-reviewing`、`ec-verification` 与三平台
+  `ec-fixer`；仅删除哈希仍与旧版托管内容一致的文件，用户改过的副本会保留且不再写入新清单。
+
+## 0.10.0-beta.10
+
+- `.easy-coding/sessions/` 改为事件触发的有界 GC：只在创建新逻辑 session 前执行，
+  无任务绑定的 session 保留 7 天、仍绑定任务的 session 保留 30 天，并按最近活动时间将
+  根目录 session JSON 控制在 100 个以内；创建前会预留一个名额，已存在 session 的日常
+  turn 不重复扫描。
+- 清理依据 session 内容与活动时间，不依赖 Codex、Claude Code、Qoder、PPID 或旧文件名
+  的字符串匹配；缺失或损坏的时间字段回退到文件修改时间，删除前重新比对内容，避免覆盖
+  并发刷新。
+- `easy-coding upgrade` 在实际升级目标中执行一次存量 GC，`--dry-run` 仅展示影响而不删除；
+  acceptance 快照只清理任务不存在、任务已终态或不再被当前验收检查点引用的孤儿文件，
+  tasks、memory、spec、project.yaml 与项目知识文件保持不变。
+- 新增 TypeScript、共享 Python hook 与 upgrade 集成回归，覆盖双 TTL、LRU 上限、损坏旧
+  session、仅新建触发、dry-run 和活动验收证据保留。
+
 ## 0.10.0-beta.9
 
 - 工作流 owner 改为规范平台身份边界：每份安装后的状态脚本固化宿主身份，新写入只接受

package/README.md

@@ -21,7 +21,7 @@ npm install -g easy-coding-harness@beta
 easy-coding --version
 ```
 
-`0.x.x` 仍按内测版本管理时，优先使用 `easy-coding-harness@beta`；正式发布后使用默认 `latest` 安装命令。
+预发布版本使用 `easy-coding-harness@beta`；稳定版本使用默认 `latest` 安装命令。
 
 ## 快速开始
 
@@ -64,17 +64,14 @@ easy-coding init --submodules packages/a,packages/b
 /ec-workflow 实现 xxx 功能
 ```
 
-`ec-workflow` 会创建或恢复任务，并按阶段调度分析、实现、审查、验证和记忆归档。
+`ec-workflow` 会创建或恢复修改任务，并按阶段调度分析、实现、统一质量检查和记忆归档。
 
 ## 工作流
 
 ```text
-INIT --[always auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --[always auto]--> COMPLETE
-                                    \--[read-only, mode-aware]-----------------------> COMPLETE
-                 ^            ^          |             |
-                 +-- replan ---+          +--- fix -----+
-                              ^                         |
-                              +------- repair ----------+
+INIT --[always auto]--> ANALYSIS -> IMPLEMENT -> QUALITY -> MEMORY --[always auto]--> COMPLETE
+                 ^            ^          |
+                 +-- replan ---+          +--- repair ---+
 approval --[approve / guard / confirm / auto]--> transition wait policy
 workflow --[adaptive => fast / standard / strict]--> stage execution depth
 tdd --[off by default / Java changed-line gate]--> optional test discipline
@@ -82,27 +79,34 @@ any stage --[user abort via ec-task-close]--> CLOSED
 ```
 
 - 审批模式优先级为 session 覆盖 > 项目 `behavior.approval_mode` > `guard`；`approve`
-  逐边确认，`guard` 确认 ANALYSIS → IMPLEMENT 与 VERIFICATION → MEMORY，`confirm` 只在
+  逐边确认，`guard` 确认 ANALYSIS → IMPLEMENT 与 QUALITY → MEMORY，`confirm` 只在
   ANALYSIS → IMPLEMENT 确认一次，随后各阶段在质量门禁通过后自动推进，`auto` 从开始即
-  自动推进。所有模式仅在 VERIFICATION 绿色检查点之后又出现新代码差异时临时暂停：展示
+  自动推进。所有模式仅在 QUALITY 绿色检查点之后又出现新代码差异时临时暂停：展示
   精确 diff 与摘要，由用户确认该摘要后继续；这不会把 `auto` 永久降级为人工审批。
 - 工作流模式优先级为 session 覆盖 > 项目 `behavior.workflow_mode` > `adaptive`。Adaptive
-  以 Standard 作为普通业务默认：单仓单 Unit、非并行且不超过 5 个文件的低风险局部修改
+  以 Standard 作为普通业务默认：单仓、最多三个内聚 Unit 且不超过 8 个文件的低风险局部修改
   优先 Fast；只有明确高风险与真实复杂度/大影响面同时存在才进入 Strict。仓库数只按当前
   execution plan 实际修改的 Git root 计算，用户可在机械风险下限之上调整。
 - ANALYSIS 会先通过问答闭合影响技术路线、接口、模型、状态、范围或验收的实质性问题，
   并在 Dev-Spec 中记录唯一的 `decision_status: closed`。会话只展示核心方案、验收摘要、
-  Workflow Mode 与主要风险；完整 `dev-spec.md` 通过绝对本地链接或路径按需查看。
+  Workflow Mode 与主要风险；完整 `dev-spec.md` 通过绝对本地链接或路径按需查看。原生选择
+  返回或迁移调用结束后的最终消息会重复紧凑方案回执与完整入口，避免前置过程消息折叠后丢失。
 - Java TDD 默认关闭；优先级为 session 覆盖 > 项目配置 > `false/90%`。首次开启前必须运行 `ec-tdd-init`，只建设 JUnit/JaCoCo/GitLab 增量覆盖率基础设施，不补存量业务单测；readiness 通过后才允许显式开启。开启后在 ANALYSIS → IMPLEMENT 冻结开关、baseline 与阈值，只验收本任务新增/修改生产代码行，执行 RED/GREEN/REFACTOR（纯重构使用 characterization GREEN → GREEN），并要求本地单测通过、本地差异覆盖率达到冻结阈值。GitLab TEST-stage job 仍会生成，但远程 pipeline 结果不属于 Harness 验收证据，也不会触发中间提交推送。关闭时普通任务不扫描 CI/JaCoCo、不增加命令或提高原工作流验收深度。
-- 所有新代码任务都完整进入 REVIEW；不同工作流模式只调整各状态内部的上下文加载、执行主体、审查独立性、验证范围和记忆深度，不绕过状态或证据门禁。
-- 显式 `doc` / `analysis` / `report` 只读任务不生成 `test-strategy.md`；展示完整报告后按生效模式进入 COMPLETE，不执行 REVIEW、VERIFICATION 或 MEMORY，也不写任务记忆。
-- `VERIFICATION` 是验证硬门控：Fast 运行最小充分检查，Standard 运行受影响范围检查，
-  Strict 运行项目适用的完整 lint/typecheck/test/build；所选模式要求的检查未真实执行
-  并留下当前指纹下的绿色证据，就不算通过。绿色后会冻结验收检查点；若代码随后变化，
-  Harness 展示完整差异并绑定 `diff_sha256`。用户确认后不重跑 REVIEW：纯非执行差异可沿用
+- 所有修改任务都进入 QUALITY；纯对话分析、解释、报告和只读 review 保持 Ready，不创建任务。文档或配置一旦写入仓库，仍走完整状态机。
+- `QUALITY` 同时编排只读 Review Gate 与 Verification Gate。Fast 使用主 Agent 聚焦自审和最小定向验证，Standard 使用一个独立 reviewer 与受影响检查，Strict 使用至少两个独立维度并只对实际修改仓库运行完整适用检查。两个 Gate 绑定同一候选指纹和 attempt，必须完成或明确取消后才形成一次 Repair Bundle；代码/测试缺陷回 IMPLEMENT，契约歧义优先回 ANALYSIS并保留同轮其他缺陷，环境问题留在 QUALITY 重试；候选漂移会审计为 cancelled 并强制先回 IMPLEMENT。
+- Canonical repair 后重跑受影响仓库及其 hard/contract 下游；其余未变化仓库必须由状态层以 `quality-carry-forward` 精确引用上一 attempt 的通过证据，不能由 Agent 复制或改写旧记录。
+- 非 TDD 的 IMPLEMENT 只负责编码，不运行测试；Verification Gate 统一执行 lint/typecheck/test/build。TDD 的 RED/GREEN/REFACTOR 是唯一例外，当前指纹绿色证据可在 QUALITY 复用。
+- QUALITY 通过后冻结验收检查点；若代码随后变化，Harness 展示完整差异并绑定
+  `diff_sha256`。用户确认后不重跑 Review Gate：纯非执行差异可沿用
   原验证，可执行差异补定向验证，显式风险豁免单独记录。配置、方案或 Canonical 设计漂移
   不能走这条例外。
 - `MEMORY` 先写入本次任务短期记忆，再执行长期记忆阈值门禁；未超过阈值时长期沉淀为 no-op。
+- `ec-lite` 仅由用户显式启停，不是 Fast 的别名。它只保留“紧凑方案 → 用户确认 → 最小实现”，
+  不创建任务、Dev-Spec、QUALITY 或 MEMORY；存在活动任务时由用户选择取消启动、关闭任务后
+  启动，或只清除当前任务指针后启动。活动任务决策使用 session 级原子锁；每次方案生成一次性
+  digest，并把当时的 Git 基线一并纳入确认内容；确认时会重新校验基线，确认后不能重放或
+  改写。完成时机械校验真实目标改动、范围外文件和 HEAD 漂移；Harness 自身 session 账本
+  不计入业务改动范围。
 
 ## Canonical Dev Spec
 
@@ -124,11 +128,11 @@ Harness 可选择性消费 easy-dev-spec 生成的单文件 `easy-dev-spec/v1` C
 
 Canonical Spec 的静态设计由 design revision + `design_sha256` 冻结；共享
 `EDS:EXECUTION` 则接收 Harness 的 Task/Step/dependency 投影。写回使用
-`execution_revision` CAS、幂等键和断点对账，执行区变化不会使本地 plan/review/verify
+`execution_revision` CAS、幂等键和断点对账，执行区变化不会使本地 plan/QUALITY
 指纹失效，设计变化或 revision 回滚仍会阻塞。显式项目外路径受支持，迁移后只能通过
 身份一致的 rebind 修复定位。静态设计调整必须 revision +1、READY 并执行 `sync-design`；
 机器执行区禁止手工编辑。Canonical task 在 Harness 本地校验完成后仍保持 `implemented`，
-只有 VERIFICATION → MEMORY 边界按显式确认或既有审批模式真正应用时才写为 `verified`，
+只有 QUALITY → MEMORY 边界按显式确认或既有审批模式真正应用时才写为 `verified`，
 并携带验收差异摘要；MEMORY 完成后再写为 `completed`。无 Canonical manifest 的历史
 Dev-Spec 继续走原有整文分析流程。
 
@@ -150,7 +154,7 @@ Dev-Spec 继续走原有整文分析流程。
 | 命令 | 用途 |
 | --- | --- |
 | `easy-coding init` | 首次接入项目，安装所选平台的 skills、hooks、agents、主约束和运行时骨架；supermodule 父仓支持 `--submodules` / `--no-submodules` |
-| `easy-coding add-agent` | 给已接入项目追加 Claude Code、Codex 或 Qoder 支持；supermodule 父仓可按已初始化子仓分层追加 |
+| `easy-coding add-agent` | 给同版本已接入项目追加 Claude Code、Codex 或 Qoder 支持；版本不一致时先执行 upgrade |
 | `easy-coding upgrade` | CLI 升级后同步项目内生成文件，生成区覆盖，用户资产保留；supermodule 父仓会同步升级已初始化子仓 |
 | `easy-coding update` | 更新全局 CLI 到最新发布版 |
 | `easy-coding config` | 交互修改当前项目的 Approval、Workflow、Java TDD 与覆盖率阈值；开启 TDD 前要求 readiness |
@@ -166,15 +170,15 @@ Dev-Spec 继续走原有整文分析流程。
 | `ec-workflow` | 统一入口，负责任务创建、恢复、阶段流转和 stage skill 调度 |
 | `ec-brainstorming` | 实现前的设计探索和方案发散 |
 | `ec-analysis` | 生成 dev-spec、执行计划和测试策略 |
-| `ec-implementing` | 按确认后的计划执行代码实现或显式无代码只读交付 |
-| `ec-reviewing` | 多维度代码审查，输出 accept / fix / replan / blocked 结论 |
-| `ec-verification` | 执行 lint、typecheck、test 等验证硬门控，并处理验收修复循环 |
+| `ec-implementing` | 按确认后的计划执行代码实现；非 TDD 不运行质量命令 |
+| `ec-quality` | 编排 Review/Verification 双门、证据复用和一次性 Repair Bundle |
 | `ec-memory` | 写短期记忆，并在超过阈值时沉淀长期记忆 |
 | `ec-task-management` | 任务面板：查看、创建、选择、恢复、交接任务 |
 | `ec-config` | 只读查看或显式修改项目/session 的 Approval、Workflow、TDD 与阈值 |
 | `ec-tdd-init` | 在 TDD 关闭态初始化/刷新 Java changed-line coverage 基础设施，不补存量单测 |
 | `ec-task-close` | 用户主动中断任务并关闭 |
 | `ec-no-harness` | 当前会话仅旁路 Easy Coding Harness，使用原生 Agent 能力 |
+| `ec-lite` | 用户显式启停的极简直达模式：一次方案确认后最小实现，不创建任务/QUALITY/MEMORY |
 | `ec-git` | 约束 git diff、commit、push、跨仓库提交等交付动作 |
 
 ### 内置 skills
@@ -203,7 +207,7 @@ Dev-Spec 继续走原有整文分析流程。
 easy-coding upgrade
 ```
 
-`upgrade` 会刷新生成区内的 skills、hooks、agents、主约束模板和运行时模板，不会删除已有任务、spec、memory、project.yaml 或项目知识文件。
+`upgrade` 会刷新生成区内的 skills、hooks、agents、主约束模板和运行时模板，不会删除已有任务、spec、memory、project.yaml 或项目知识文件。0.10.0-beta.10 起，实际升级还会执行一次 session GC；`--dry-run` 不删除数据。升级到 1.0.0-beta.0 时，活动 REVIEW/VERIFICATION 合并为 QUALITY；活动旧只读任务以 `legacy-read-only-task-retired` 关闭并保留全部历史。
 
 升级到 0.9.0 时，旧 `strict_confirm` / `auto_mode` / `confirm_mode` 会一次性迁移为
 `behavior.approval_mode` 与 `behavior.workflow_mode`；旧 `lite` 映射为 `guard + fast`。
@@ -216,6 +220,10 @@ session 临时覆盖统一通过 `ec-config` 对话修改。升级到 0.10.0-bet
 不会被静默改写。0.10.0-beta.4 起，仍停在 ANALYSIS 的旧任务必须补齐决策闭环后才能
 进入 IMPLEMENT；已经进入后续阶段的任务不受影响。
 
+session GC 只在创建新逻辑会话前和实际升级时触发：无任务绑定的会话保留 7 天、仍绑定
+任务的会话保留 30 天，并按最近活动时间将根目录 JSON 控制在 100 个以内。活动任务仍在
+引用的 acceptance 验收快照会被保留；任务、记忆、Spec 和项目知识不参与清理。
+
 若当前会话不希望 Harness 接管，显式调用 `/ec-no-harness`（Codex 使用
 `$ec-no-harness`）。它只旁路 Easy Coding，不关闭其他 hooks，也不忽略其他 skills；
 当前任务状态会原样保留。
@@ -224,7 +232,7 @@ session 临时覆盖统一通过 `ec-config` 对话修改。升级到 0.10.0-bet
 
 版本号使用 `x.y.z`：
 
-- `x`：大的功能迭代；`0.x.x` 表示内测版本
+- `x`：大的功能迭代；带 `-beta.*` 的版本表示预发布版本
 - `y`：常规功能升级
 - `z`：日常 bug 修复