Feat/web#2
Merged
Merged
Conversation
激活方案 Phase 0 的离线消融能力，给此前无生产 caller 的 compare_memory_effectiveness 接上真实入口，并补齐文档误以为已存在、 实则缺失的 memory=off 能力。 **消融开关** - MemoryExtractionConfig.inject_enabled（默认 True）：False 时 orchestrator._inject_memory 跳过 set_memory_store，使 get_memory_context 返回空 = memory=off 臂；抽取/写回经 orchestrator 自有 store 不受影响 **离线 harness** (src/tools/memory_replay.py，纯读) - load_effectiveness_report：从 run 目录或 json 载入 memory_effectiveness.json - build_ablation_comparison：包装 compare_memory_effectiveness（首个真实 caller） - render_ablation_table：输出 memory_decision_lift 对比表 **CLI** - merge eval-memory --on --off [--out]：载入两臂报告→对比→打印表→可选落 JSON **测试** tests/unit/test_memory_replay.py：14 用例覆盖 load/compare/render 与开关真实接线（断言 inject_enabled=False 不 wire store）
把 PR-0a 产出的度量写进权威评估文档，并把"反馈环默认开启"的硬前置 从代码注释固化为可评审验收门（兑现方案原则 P2 先度量再激活）。 - metrics.md §9：记忆有效性指标 MDL/HIR/CRI/MID/PEE/MCPD，含公式、 数据源（对齐 memory_effectiveness.json 字段）、信号通路；标注 P1-C/P2-B 待补指标 - acceptance.md §3：自学习反馈环激活门（MDL>0 硬前置 + HIR 不升 + CRI≥off基线 + MCPD≤×1.15）含判定流程；原 §3–§6 顺延为 §4–§7 - dependency-graph-optimization-plan.md：修正顺延失效的交叉引用 acceptance.md §3→§4（report schema） 激活门为独立章节（≠ 合并质量门），acceptance_thresholds.yaml 仅镜像 §1/§2 故不动。
多文件人工决策时,提交一个文件后视图仍停留在已决文件上,剩余 待决文件(尤其是 conflict_points 为空、右侧无明细的升级文件) 极易被遗漏,导致 run 一直停在 AWAITING_HUMAN。 submitCurrent 发送决策后乐观跳转到下一个 human_decision 仍为 空的待决文件;保留手动点击已决文件查看的能力,不做强制弹走。
human_review 在 resume 后一次性同步执行已提交的决策(大文件 chunked 语义合并可能耗时数分钟),期间 status 始终为 AWAITING_HUMAN,Web UI 持续展示决策表单,用户误以为 run 卡死。 在 Case 1 执行循环前将状态从 AWAITING_HUMAN 切到 AUTO_MERGING,经 transition observer 自动广播新快照,前端 classifyView 据此离开决策 gate 转入实时进度。仅改内存状态与广播,checkpoint 仍按 PhaseOutcome 在相位边界写入,resume 语义不变;后续转入 JUDGE_REVIEWING / ANALYZING_CONFLICTS 及失败再升级 AWAITING_HUMAN 均为合法转换。
将根目录散落的 8 个文件归入对应子目录： - web-ui.md / web-ui-redesign-handoff.md → modules/ - forks-profile-init.md → modules/forks-profile.md（改名去歧义） - migration-aware-merge.md / risk-levels.md → modules/ - multi-agent-optimization-from-merge-experience.md → references/multi-agent-optimization.md - large-scale-file-processing-optimization.md → plan/ - execute/implementation-notes.md → plan/（删除单文件目录 execute/） 同步修复 3 处内部链接（onboarding.md、insforge 测试报告）。 重写 README.md：补齐此前缺失的 bugfix/、evaluation/、review/、 test-report/ 四个目录的说明，更新时间戳至 2026-05-31。
在 forgejo test/fork←origin/forgejo 上用 deepseek-v4-pro 实跑 memory=on/off 两臂消融（同一 ablation_decisions.yaml，唯一变量 inject_enabled），经 merge eval-memory 产出首组基线，回填 acceptance.md §5.1： - MDL=0.0000、HIR(on)=0.20，两臂 overall_correct_rate 均 81.25%（13/16） - off 臂 memory_influenced_decisions=0，证实 inject_enabled 开关有效 - 据 §3 激活门（MDL>0 为硬前置）判定：P1 反馈环不默认开启 - 标注 caveat：单 run/单数据集/judged=16 样本小，仅首组可搬动基线， 需多 run 复算方可据以翻默认开启 PR-0c 至此打通 Phase 0 完整闭环（度量→消融→验收门→首组基线）。
forgejo 首组基线暴露单臂 harmful_influence_rate 的归因缺陷：HIR(on)=0.2 把"记忆恰好注入到本就确定性失败的文件"误算成有害，而消融证明那 3 个失败 在 memory=off 臂逐文件相同（确定性 reverse_impact veto，与记忆无关）。 改为跨臂逐文件因果归因： - MemoryEffectivenessReport 持久化 passed_files/failed_files（原仅计数） - compare_memory_effectiveness 计算 memory_helped(off-fail→on-pass)/ memory_harmed(off-pass→on-fail) + causal_attribution_available - render_ablation_table 增因果区块；HIR 标注为 correlational - metrics.md §9.2 警示 HIR 假阳性 + 新增 §9.7 因果归因；acceptance.md §3 激活门判据由单臂 HIR 改为 memory_harmed=0；§5.1 基线补因果列（harmed=0） 旧产物无 per-file 列表时 causal_attribution_available=False（不可知≠0）。 real forgejo checkpoint 验证：causal helped=0/harmed=0（HIR=0.2 系假阳性）。
把 O-M6 读取期、依赖 hit_tracker 存活的临时有害过滤巩固为持久、可审计的 软删状态，使 prune 在 tracker sidecar 丢失/观测不足时不再"复活"，并覆盖 写入/consolidation 侧（堵 F2 无界增长）。 - MemoryEntry 增 suppressed/suppressed_reason（content_hash 不含新字段， dedup 身份不变；软删保留可审计行，非物理删除） - MemoryStore/SQLiteMemoryStore 增 suppress_entry()；SQLite 加两列 + ALTER TABLE 迁移旧库；get_relevant_context 与 _consolidate_entries 跳过 suppressed 条目 - layered_loader._build_l2 过滤改为"suppressed 或命中 harmful_entry_ids" （持久 + 实时并存） - orchestrator 新增 _apply_suppress_harmful_entries：run 末把满足 suppress_min_observations 的稳定有害条目固化 suppress，豁免 bootstrap/HUMAN - 新 opt-in 开关 memory.persist_suppress（默认 False，按 P2 先度量再激活） 12 新单测 + 3224 unit 绿（1 个 pre-existing 无关 docs 测试除外），mypy/ruff 干净
OPP-5 写回此前只用 judge pass/fail，而 record_outcome 又跑在 build_check 之前——一个 judge 判过但编译失败的合并仍把产生它的记忆记为 helpful。本提交 把每文件 outcome 记录从 judge_review 阶段集中到 orchestrator 的 judge_review 记忆钩子（此时 verdict 已反映 build_check 降级），并按确定性信号融合： - 新增 _record_memory_outcomes：默认 ["judge"] 与旧行为逐字节等价；含 "compile" 时，build_check_failed 的 run 把 judge-passed 的已编译语言文件 demote 为失败， 非编译文件（如 .md）不受牵连 - judge_review.py 移除 inline record_outcome（避免在 build_check 前误记） - 写回为双向（OPP-5 已有 +Δ/−Δ），harmful 跌破阈值由紧随其后的 P1-A _apply_suppress_harmful_entries 固化 suppress——无需新代码 - config.memory 增 writeback_signal_sources: list[Literal["judge","compile"]] （默认 ["judge"]，opt-in 加固，全确定性不引 LLM 自报） CI/partial_failure 信号有意延后：post-merge 确定性发现在 report_generation 产出，晚于本钩子；完整融合需把写回迁到 report 阶段（见 plan P1-B） 7 新单测 + 3231 unit 绿（1 pre-existing 无关 docs 测试除外），mypy/ruff 干净
- pyproject.toml 补充 description / readme / license / authors / classifiers / urls - 新增 LICENSE（MIT） - 新增 .github/workflows/release.yml：v* tag 触发 → 构建 Web UI → 打 wheel → Trusted Publishing 发布到 PyPI
把执行期"用确定性算子修好并最终 judge PASS"的成功事件沉淀为可复用经验， 下次同类错误不再从零试错。provenance 全确定性——LLM 不参与"是否成功"判定。 - 新 MemoryEntryType.REPAIR_RECIPE - state.applied_repairs 记录"修复并放行"的确定性算子（当前唯一会修复而非升级的 算子：duplicate-symbol dedup；其余 foreign_chars/seam/hallucinated 均升级） - executor 在两处 dedup 命中点（语义合并 + 分块合并）经 _record_applied_repair 登记（按 file+operator 去重） - summarizer._build_repair_recipes：仅当算子触发且文件落入 judge passed_files 才铸 recipe，按 error_signature(error_class+operator+dir层) 去重、上限 20 - 读取走既有 get_relevant_context 通道（recipe 带 file_paths），无需新检索代码； 与 ScarListBuilder（历史人工坑）互补=运行期验证过的解法 - config.memory.repair_recipe_enabled 默认 True（纯加性、执行接地，风险低于 会致害的 P1-A/B，故默认开；可关用于 eval-memory 消融） 7 新单测 + 3238 unit 绿（1 pre-existing 无关 docs 测试除外），mypy/ruff 干净
_is_epistemically_empty 拒"模型放弃"标记；本提交补其对偶——拒"空泛无动作" 条目（Renze & Guven：反思信息量是效果杠杆，GPT-4 0.79→0.93）。 - 新 src/memory/content_quality.py：is_actionable_content 仅审 DECISION/ REPAIR_RECIPE（PATTERN/摘要类豁免），保守判据默认 True，仅明确空泛填充词/ 过短无动作才 False；enforce_actionable 不可变降级（降 HEURISTIC + 折半 confidence，de-rank 而非删，保召回） - orchestrator._update_memory 两个入库点（summarizer + memory_extractor llm 出口）统一过 enforce_actionable 8 新单测；mypy/ruff 干净
consolidation 把同组条目摘要成一个 blob，会漂移关键条目内容（F1）。本提交给
验证过的解法与人工决策打 pinned，consolidation 对其 passthrough 不再摘要。
- MemoryEntry.pinned: bool；SQLite 加 pinned 列 + ALTER TABLE 迁移旧库（镜像
P1-A suppressed 的迁移/行映射）
- _consolidate_entries 跳过 pinned（与 suppressed 同 passthrough 分支）
- summarizer 标 pinned=True：REPAIR_RECIPE（验证过的解法）+ judge_review 中
decision_source∈{HUMAN,BATCH_HUMAN} 的文件 DECISION 条目
- security-sensitive 锚定延后（summarizer 无 config patterns，plumbing 已就位）
8 新单测（含 F1 多轮 consolidation 零损失断言 + 迁移）；test_p1c 桩补
file_decision_records；mypy/ruff 干净
GEPA/MIPROv2 式提示进化的确定性可测核心：对某 gate 的系统提示生成具名候选变体、
按 golden 集决策准确率排名、产人工评审报告。gate 是代码 builder，故采纳赢家=人工
按报告编辑提示源，**永不自动写回 gate_registry**（方案"人工评审后才生效"）。
- src/tools/prompt_optimizer.py：PromptCandidate/GoldenCase/CandidateScore/
CostLedger/OptimizationReport；MUTATION_STRATEGIES（GEPA 确定性子集=反思指令注入
stepwise/selfcheck/output_format/evidence_first）；propose_variants（基线+去重）、
score_candidates、select_winner（须超基线 margin 且已评分）、build/render report
- 昂贵的 LLM rollout 有意外移为注入的 rollouts 映射（candidate_id→{case_id:decision}），
harness 纯离线可单测；产 rollout 是操作者按文档自担成本的步骤（~$60/万次）
- CLI `merge optimize-prompts --gate --golden --rollouts --strategies --margin --out`：
仅支持 no-arg/*-SYSTEM gate（其余报错）；无 golden 时只产变体并诚实标注 unscored
- 安全：read-only w.r.t 生产提示；未评分=surfaced 非伪造；margin 内不夺基线
11 harness + 3 CLI 单测（对真实 J-SYSTEM gate）；全量 3268 unit 绿（1 pre-existing
无关 docs 测试除外），mypy 182 文件干净、ruff 过
eval-memory 分析在真实 forgejo 累积 sidecar 上发现：P1-A 的持久软删沿用读取期 单臂 harmful_entry_ids(score<=-0.5)，会把 8 条薄样本(<=4 fail)误判有害并不可逆 软删——正是 PR-0d 为度量层修过的同一相关性假阳性，现落到跨 run 持久副作用上。 持久软删远比读取期 O-M6 过滤(瞬时、可逆)更该严格： - hit_tracker.harmful_entry_ids 增 min_fail_count（默认 0，读取期行为不变） - config: suppress_harmful_threshold=-0.8（严于读取期 -0.5）+ suppress_min_fail_count=5 - _apply_suppress_harmful_entries 用严格阈值 + fail 下限；并加确定性混淆守卫—— 条目若仅关联本 run veto(确定性)失败文件、且不沾任何 passed 文件，则其"有害" 是相关性(确定性门不读 memory)，跳过 suppress 真实 forgejo 实证：旧判据选 8 条软删，新判据选 0 条（全部薄样本被 fail 下限拦住）。 5 新单测(fail下限/严阈值/混淆守卫/守卫不误伤沾 passed 的条目) + 3273 unit 绿 (1 pre-existing 无关 docs 测试除外)，mypy/ruff 干净
此前 golden 集仅 5 个 C-class 升级样本，三个 gate 都只有单一升级标签 （escalate_human / human_required），优化器只能惩罚"误判升级"、无法奖励 "敢自动合并"，决策面残缺。 新增 4 个 forgejo 真实样本（models/auth/auth_token.go，双侧不相交纯增量、 git 3-way 干净合并、go build 通过、golden 保留双方）： - t1-0034/0036：auto_safe + semantic_merge + J-SYSTEM pass - t1-0035：auto_risky（auth 结构改动，弱 risk-hint 非 security_sensitive） - t1-0037：J-SYSTEM fail fixture——golden 正确，rollout 喂丢掉 upstream 所有权校验的 fork-only 树（prepare 的 working_tree），judge 应判 fail 逐 gate 现状：J-SYSTEM 0→4（3 pass + 1 fail）、P-RISK 5+3、CA 5+3。 配套： - golden.md §4/§5：更新 seed 状态，将 J-SYSTEM rollout 输入契约固化为 golden_tree（pass）/ working_tree（fail）的具体约定 - _schemas.py：SampleMeta 增 judgment_intensive / golden_decisions 字段 - 新增真实数据集守卫单测（决策面覆盖 + golden JSON 与 meta 同步） - doc/evaluation/README.md 索引补 golden.md
BCP（Build-Check Pass Rate，metrics.md §8.5 / acceptance.md §2）此前只在 文档声明，summarize 不产出指标、gate.py 也不强制——acceptance_thresholds.yaml 缺该门，属"文档已声明、强制层未实现"的缺口（修复 acceptance.md ↔ acceptance_thresholds.yaml 的 synced_with_sha 漂移时发现）。 打通数据通路： - judge 阶段 _run_build_check 把结果记入 MergeState.build_check_passed （三态 None/True/False） - ci_reporter.build_ci_summary 输出该字段 → eval run_meta.json（RunMeta 新增 build_check_passed）→ summarize._compute_bcp 聚合 → 报告模板 BCP 行 → gate.py 按 soft 门 == 1.0 判定 - acceptance_thresholds.yaml 加 BCP 软门并刷新 synced_with_sha（手改两字段， 不用 update-acceptance-sync 以免 yaml.safe_dump 抹掉注释） 分母口径：仅统计实际执行了 build_check 的 run；未配置工具链、或在 judge 前 升级人工（无合并产物可编译）的 run 记 None、不计入——系统正确升级不应拉低 BCP。整集无人执行时输出 N/A、gate SKIP（绝不误判 fail）。 测试：summarize _compute_bcp、gate BCP pass/fail/skip、ci_summary 透传、 judge _run_build_check 四路径的 build_check_passed 断言、报告夹具补 BCP。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.