决策记录
本文档记录 moot-court 技能开发过程中的重要技术决策。
[DEC-001] - 2026-09-18 - 以"要件审查"做骨架，漏洞定义为三种坐标
状态：保留要件映射方法；具体证据分类以当前 references/checklist.md 为准，复盘分类由 DEC-006 修订。
背景
庭前准备的痛点是"不知道自己不知道"：案件材料看了很多遍，心里没底，但说不清到底哪里没底。需要一个客观的框架把"没底"变成具体条目。
决策
用要件审判的思路做骨架：诉讼请求 → 权利基础规范 → 构成要件 → 待证事实 → 证据，逐格填表。漏洞只有三种坐标：要件没有证据（✗）、证据有瑕疵或证明力存疑（△）、法律适用存在对方可打的争点。自查产出的空格直接成为推演的重点清单。
理由
- 要件审查是法官审案和律师办案通用的案件分解方法，对律师是"换到合议庭位置审自己的案子"，不引入新概念。
- 表格化之后"没底"变成可数的空格，每格可检验、可补强；应诉时反向用同一张表拆对方，质证与反证的着力点也随之明确。
[DEC-002] - 2026-09-18 - 推演设两个视角：对方代理人打攻防，承办法官问回避
状态：由 DEC-005 扩展为独立角色编排；无限追问不再适用，按当前 SKILL.md 的回合预算停止，未回答不得直接认定实体失败。
背景
自查的盲区在视角：自己很难站到对方位置想问题，也想不全法官关心什么。需要外部视角补盲。
决策
- 对方代理人视角：只做攻防，规则是"每次出手落到具体证据、要件或法条"，空击重来；打得通的承认，打不通换目标——保证攻击密度集中在真问题上。
- 承办法官视角：不打攻防，只列问题清单逐个要答案，来源是自查空格、含糊表述、文书与证据出入、金额计算；同一问题追问到"明确回答"或"确认回答不了"为止，后者直接进漏洞清单。
理由
- 两个视角互补：对方视角暴露"会被怎么打"，法官视角暴露"自己都说不清的地方"——后者往往是前者的弹药。
- 规则约束（落到具体、不空击、不引用案卷外材料）保证推演结果可采信，而不是互相表演。
[DEC-003] - 2026-09-18 - AI 代打我方时刻意保持"合格但真实"水准
状态：已被 DEC-006 替代，保留历史，不再作为执行规则。
背景
用户不亲自下场时由 AI 代打我方答辩。若把 AI 调成完美答辩手，推演会变成"AI 打 AI"的表演，什么都暴露不出来。
决策
代打水准保持"合格但真实"：像真人律师一样偶有遗漏、绕开问题、口径不一。总盘点按"答上了/绕开了/没答上"三档统一判定，绕开与没答上的问题单独成表，开庭前要么备好答案、要么准备当庭处理口径。
理由
- 推演的产出价值取决于漏洞能否暴露；完美的我方表现等于零信息量。
- 用户亲自下场时不存在此问题，且练兵价值更高，因此作为推荐方式。
[DEC-004] - 2026-09-18 - 交付物只有行动项，不写分析报告
状态：行动导向保留；交付范围已由 DEC-006 扩展，旧版“只有行动项”不再适用。
背景
开庭前时间有限，一份"案件全面分析报告"看着完整，但没有一条能直接执行。
决策
第三道工序只出三份可执行交付物：漏洞与补强清单（每条含"开庭前动作"与紧急程度分级）、证据补强动作（途径/责任人/截止日，客观无法补的写替代思路）、庭审提纲（应答口径三句以内可直接引用、发问清单写明目的与后续动作）。分析判断只作为条目的理由出现，不单独成篇。
理由
- 庭前准备的终点是"进法庭时手里有提纲、心里有底"，不是又一份报告。
- 每条发现强制对应一个动作，倒逼推演产出落到实处；动作做不了的要写明替代思路，避免清单变成愿望列表。
[DEC-005] - 2026-09-18 - 以书记员中转实现跨 Runtime 自动庭审
背景：用户明确要求自动分派法官、原被告或控辩，并提出 Subagent 不支持相互通信时经书记员记录交换发言。
决策：主 Agent 兼任调度员和书记员；独立角色只接收限定材料包并提交自己的发言。书记员单写者提交顺序事件，下一回合明确材料版本、读取截止与必答发言。事件含内部材料快照，不能向角色共享原始 events 目录；笔录与状态由事件派生，不另设第二份权威来源。
理由与影响：依赖宿主最基础的派发和结果返回能力，避免绑定 Agent Teams 邮箱格式。复用或冷启动角色都可通过材料与备忘录衔接；自动唤醒、跨机器同步及主会话关闭后继续运行不在本版范围。私有材料逻辑过滤不等于系统权限隔离。
重新评估条件：实际出现无法顺序推进、长案卷上下文超限、严格隔离要求或多主控写入需求时，再扩展传输与权限层，不预先搭建通用 Agent 平台。
[DEC-006] - 2026-09-18 - 撤销故意弱化角色，分离执行失误与案件缺口
背景：DEC-003 人为制造遗漏，会把模型被要求答差误当作案件弱点；原三档答辩评价不能区分材料不足与漏读已有材料。
决策：双方在各自可见材料范围内充分论证；以材料缺口、论证缺口、角色执行失误分别复盘。执行失误先纠正并重跑，技术失败不计作实体攻防成果。默认自动演练，用户参与为显式选择。
理由与影响：自动对抗应揭示现有材料与论证的承压情况，不能通过降低一方能力制造结论。本决策替代 DEC-003；DEC-004 的“仅行动项”范围扩展为保留实际庭审记录、争点复盘及补强动作，确保结论可回查。
[DEC-007] - 2026-09-18 - 将技能开发文档一并版本化
背景：用户要求提交迭代，同时维护技能内部决策、任务和变更记录，并在任务源列出后续升级方向；仓库默认忽略 TASKS.md 与 DECISIONS.md。
决策：仅为本技能两份文档添加精确 Git 忽略例外，与 CHANGELOG.md 一起随源码维护。TASKS.md 保存当前状态、验收摘要与后续任务；DECISIONS.md 保存重要取舍及替代关系；CHANGELOG.md 保存已交付变化。含本机路径的旧验证流水留在忽略的本地 archive 中，真实案卷和运行目录不入库。
理由与影响：协作者可从同一版本恢复开发背景；后续方向明确为 DRAFT，不混入已实现能力。既往候选绑定的验证记录只证明当时产物，不冒称覆盖后续全部文档修订。本次授权为本地 Git 提交，不包含推送或渠道发布。
重新评估条件：发布渠道需要精简开发文档时，在打包层定义范围，不删除源码中的任务与决策历史。
[DEC-008] - 2026-09-19 - 程序方案先于角色轮流发言
状态：程序区分保留；当前默认主线及扩展顺序由DEC-010调整。
背景：用户要求参照真实模拟法庭完善方法；研究发现 Jessup、AMTA、Vis 与国内赛事的训练对象和简化规则不同，v1.1.0 的通用三角色往返不足以说明程序完整性。
决策：默认以现有案卷做证据审理式核心争点预演；法官问答式论辩与指定赛事另选程序方案。正式发言按主张、质疑、问题、回应和主持处理区分，待答事项由公开事件派生。保持现有三角色工具边界，明确证人、鉴定人和刑事被告人未独立参与时的省略，不用代理角色冒充。
理由与影响：借鉴可迁移的训练机制，同时避免移植外国证据规则或赛事事实发挥例外。研究来源与适用范围见 references/research-methods.md；程序框架见 references/procedure-profiles.md。真实法源仍在个案中核验。
重新评估条件：获得完整庭审或指定赛事需求，并具备角色、程序与评测材料后，按 Task-017／Task-013 扩展协议；不要仅改名称就宣称适配。
[DEC-009] - 2026-09-19 - 连续讨论不依赖角色实例持续在线
背景：不同宿主的消息、续接、上下文和权限能力不同；任务返回式 Subagent 不宜被要求常驻等待其他角色。
决策：延续 DEC-005 的书记员中转，以逻辑角色和公开记录维持讨论；有干净实例则续接，否则逐回合冷启动。每次只做一个主要程序动作，主控入卷后派发下一步。角色共享完整公开脉络，保留本方私有准备；撤销可见性或角色换边时不复用受污染上下文。history 与笔录从原派发派生公开 issue／stage，不传播私有 prompt。
理由与影响：单个可用子任务席位也能顺序推进；群聊只作可选传输层。信息送达、公平回应机会与材料可见性分别检查，文件协议不冒充物理隔离。工具保持发言 schema_version=1，旧事件不迁移；新增历史元数据不会改变已提交正文。
重新评估条件：实测显示长案卷成本、实时打断或跨机器并行无法在当前模型下满足时，再设计增量与服务化，不能以方法文档代替 Runtime 兼容性测试。
[DEC-010] - 2026-09-19 - 通用民事闭环先行，独立参与人扩展暂缓
背景：用户明确当前目标是先让原告、被告、法官加书记员的普通民事流程跑通，再验证不同Agent Runtime；证人、鉴定人等不在当前范围。此前将Task-017列为近期优先项超出了这一推进顺序。
决策：以references/civil-hearing.md的通用民事训练闭环作为默认主线及跨Runtime共同基准。主Agent兼任书记员，负责调度、记录和传递，不增加第四个实体论辩实例。保留三角色现有协议；将Task-017暂缓，Task-011前移，先用同一合成材料在真实宿主复现。
理由与影响：先固定流程和验收目标，才能辨别Runtime适配问题；更换案卷、扩大角色和开发专门程序会同时改变多个条件。训练流程完成与案件事实证明、全部现实法定环节完备分别判断，材料存在缺口不自动等于流程没跑通。本决策调整DEC-008的默认范围与迭代顺序，保留其程序边界。
重新评估条件：通用闭环经Runtime实测后，用户明确要求证人、鉴定人或专门案由，再恢复对应扩展任务；不因发现研究方向自行扩大本轮范围。
[DEC-011] - 2026-09-20 - Runtime兼容性按能力与完整闭环分级验收
背景：Claude Code实测中，最小模型、单Agent、Write和四发言顺序闭环均可完成，但完整候选长任务两次停滞且没有书记员产物；Gemini CLI能解析参数，却未取得最小模型响应。只执行完整任务会混淆入口、模型路由、工具调用、编排和Skill遵循问题，只执行短探针又会高估兼容程度。
决策：新Runtime依次通过命令入口、模型响应、子任务、持久化、四发言短闭环与完整民事闭环六级门禁。前一级阻塞时不启动后一级；分别记录PASS、带发现通过、阻塞、未运行和未验证。四发言短闭环只证明顺序编排与落盘；必须使用完整候选、书记员正式事件、civil-hearing七环节和三项交付并经独立复核，才能称该候选在该Runtime完成闭环。
理由与影响：分级结果能定位Runtime故障，不把登录、路由或无输出误判为庭审协议失败，也不把Agent能返回固定短答扩大为领域正确性。短闭环仍需语义复核；发现事实扩大、角色越界或未真正回应时保留为问题，不能因调用顺序正确而忽略。
重新评估条件：若多个Runtime稳定提供统一的任务状态、结果持久化和取消语义，可合并部分探针；完整闭环及语义复核仍不得由能力声明或帮助文档替代。