no-mistakes 评审管线与智能体机制深度解析：会话复用、决策历史、意图一致性与超时证据

no-mistakes 评审管线与智能体机制深度解析会话复用、决策历史、意图一致性与超时证据【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes本文以 no-mistakes 仓库的.agents/skills/pipeline-review-and-agents/SKILL.md为核心骨架系统拆解其内置验证管线intent → rebase → review → test → document → lint → push → pr → ci中与评审循环与智能体相关的全部机制包括评审-修复会话的复用与隔离、人工对 findings 决策的持久化与传播、未认证修复范围的跨轮次溯源、以及围绕智能体调用的超时测量与意图一致性约束。读完本文你将理解该仓库如何用「会话身份隔离 决策历史注入 溯源子句」三重机制防止 AI 评审自我背书并掌握其全部相关配置项、提示词契约与测试回归清单。一、评审循环的会话模型一个修复会话零个评审会话1.1 会话角色的设计动机在 no-mistakes 的管线中Review 步骤负责对 diff 进行 AI 代码评审并在发现缺陷后进入修复fix→ 再评审rereview循环。这个循环中最关键的设计决策在 internal/pipeline/sessions.go 中体现为两个会话角色const ( SessionRoleReviewer SessionRole reviewer // 遗留角色 SessionRoleFixer SessionRole review-fix // 修复者角色 )每次运行per run只保留一个持久的 fixer 会话跨多轮评审-修复复用每一轮评审首次评审和每次完整再评审都以无会话session-free方式运行。这个设计直接回应了一个深层风险再评审rereview的职责是**认证certify**上一轮评审提出的 findings 是否已被修复正确实现。如果再评审复用上一轮评审的会话那么开具修复处方的人就会同时变成认证处方被正确执行的人——等于让评审检查自己开的药方是否被照做形成自我背书self-prescription/certification的闭环。正如源码注释所写a rereview certifies fixes implementing the previous review turns findings, so resuming any review session would seat the prescriber of those fixes as their certifier and degrade the rereview into checking that its own prescription was implemented.跨轮的评审上下文只通过**显式的、经过净化的轮次历史sanitized round history**传递fixer 会话绝不会被借给评审轮次使用其他步骤也不使用会话会话严格按 run 作为键隔离keyed strictly by run。1.2 会话持久化与失败降级RunSessions管理器internal/pipeline/sessions.go的持久化遵循最小元数据原则只保存(run, role, agent, session id)绝不保存提示词prompts或完整对话记录transcripts。这既是为了隐私也是为了防止恢复的会话把过期的评审上下文带进新的轮次。会话复用遵循一组明确的 fail-safe失败安全规则场景行为适配器不支持会话如 session-reuse 不支持的 agent冷启动cold run不报错fixer 会话恢复失败丢弃该会话身份identity以全新 fixer 会话重跑同一轮绝不跳过该轮调用方上下文被取消ctx cancelled不做 fallback 重试配置session_reuse: false全部强制冷启动持久化写入失败降级为冷调用reuse degrades, correctness does not其中resume 失败后丢弃身份并以新会话重跑的实现在RunSessions.Run中internal/pipeline/sessions.go先携带stored会话 ID 尝试a.Run失败后调用rs.forget(role)删除持久化记录再以空SessionRef并标记SessionFallbacktrue重跑同时通过LifecyclePhaseFallback事件通知调用方。SessionRoleReviewer角色之所以保留是为了兼容旧版本写入的持久化行crash recovery 读取历史数据时仍需识别该角色但这些遗留行永远不会被恢复续用。1.3 再评审如何重新框定修复代码再评审的提示词使用fixRoundProvenanceClause将修复轮次的改动重新框定为管线自产代码pipeline-authored code并要求以与作者原始代码相同的对抗性标准author-grade adversarial standard来评审。同一个子句也会在后续某次运行的首次评审中当绑定了持久化的未认证区间uncertified range时被输出。关键语义先前的 findings、修复摘要fix summaries以及同轮次的测试都是声明claims而非证据evidence。这条规则写死在 internal/pipeline/steps/review.go 的提示词构建逻辑与 internal/pipeline/steps/round_history.go 的uncertifiedRoundHistoryPromptSection中Prior findings and fix summaries are claims, not evidence。1.4 会话模型的回归测试仓库通过以下测试锁死该契约详见 internal/pipeline/sessions_test.go、internal/pipeline/steps/review_session_test.go、internal/agent/session_test.goTestReviewLoop_RereviewNeverResumesTheSessionThatPrescribedItsFixes再评审绝不恢复开具处方的那个会话TestReviewStep_RereviewTreatsFixRoundsAsPipelineAuthoredCode再评审把修复轮次代码当管线自产代码评审。二、记录的人工决策decline 的补集存储与跨轮次传播2.1 决策的记录方式当一个带 findings 的门禁轮次gated round被人工以Approve / Skip / Abort解决且未选择任何修复时no-mistakes 会在数据库层记录selected_finding_ids []且selection_source user_declined。这条路径的实现位于 internal/pipeline/executor.go 的recordDeclinedRound与 internal/db/round_decisions.go 的SetStepRoundDeclined。几个严格约束无 findings 的轮次不记录任何决策TestExecutor_GateResolutionWithNoFindingsRecordsNoDecision条件写入绝不可覆盖已存在的选择SetStepRoundDeclined只在尚未记录选择时写入见 internal/db/round_decisions_test.go 的TestSetStepRoundDeclined_NeverOverwritesARecordedSelectiondecline 存储的是选择集的补集而不是独立列表declinedFindingLinesinternal/pipeline/steps/round_history.go根据SelectedFindingIDs推导出未选择的 findings。2.2 补集语义与 auto-fix 的例外补集推导有一个刻意设计的例外自动修复auto-fix选择的补集绝不被当作人工决策。declinedFindingLines只认RoundSelectionSourceUser与RoundSelectionSourceUserDeclined两种来源auto-fix 选择的补集是仍在等待决策的 findings会以auto_fix_left_unselected标签渲染且不附带任何不要重新上报的指令——因为没有人对它们做出过裁决把它们渲染成 declined 会压制一个本应继续等待人类决策的问题Rendering those as declined would suppress a finding nobody has ruled on yet。对应回归测试TestAutoFixComplementIsNeverPresentedAsAUserDecision。2.3 决策历史的三段式提示词roundHistoryPromptSectioninternal/pipeline/steps/round_history.go向 Review / Test / Document / Lint / CI 修复智能体的提示词中注入三段净化的决策历史本步骤此前的轮次this steps rounds—— 最详细含 findings、user_chose_to_fix/user_chose_to_ignore/auto_fix_left_unselected分组本次运行其他步骤的决策OTHER steps decisions该分支上更早运行的决策earlier runs decisions on this branch。第 3 段通过pipeline.BindBranchDecisions绑定到步骤上下文区别于仅用于评审的BindUncertifiedPipelineRange。注意没有任何机制清除分支决策——已完成评审会删除未认证区间这正是不认证区间通道无法向前传递决策的原因但通过一个门禁approving a gate本身就是决策。提示词明确声明已记录的决策优先于用户意图的文字表述A recorded decision SUPERSEDES conflicting user-intent wording。同时这段历史是纯 advisory、fail-open的不阻塞任何步骤不门禁任何提交允许 agent 在代码确实发生实质性变化时重新提出被 decline 的 finding没有回滚检测器reversion detector——assertPipelineHeadContinuity与assertReviewApprovedPushHead只做血缘lineage校验不检测内容回滚。2.4 决策历史在 CI 修复中的注入位置ci_fix.go与其他具备修复能力的步骤一样组装该段落且放在userIntentPromptSection之前原因是本次运行冻结的意图frozen intent总是先于后续某个门禁的决策因此 CI 修复必须能看到更早门禁、本分支更早运行或自身门禁记录的决策对应测试internal/pipeline/steps/ci_decision_history_test.go。而rebase.go仍在不含roundHistoryPromptSection的情况下构建提示词rebase 修复不接收决策历史。2.5 预算与净化为避免提示词膨胀决策历史段落实行严格的字节预算internal/pipeline/steps/round_history.go常量值maxDecisionLinesPerSection40 行maxDecisionLineBytes4 KiB / 行maxDecisionSectionBytes16 KiB / 段超出预算时优先丢弃最旧的 finding 行并显式输出省略/截断声明如 N older decision finding(s) omitted for length保证信息透明。三、未认证评审溯源Uncertified Review Provenance3.1 问题场景与持久化时机当评审步骤的 fixer 轮次提交了代码但其再评审未完成时该分支上就存在一段未被认证的修复提交。此时 internal/pipeline/uncertified.go 会持久化按分支划分的未认证区间(from_sha, to_sha)。持久化的触发条件是严格的仅在评审步骤的 fixer 提交时持久化——lint 与 document 步骤的 fixer 提交不会持久化测试TestCommitAgentFixes_LintDoesNotPersistUncertifiedRange、TestCommitAgentFixes_DocumentDoesNotPersistUncertifiedRange持久化逻辑见PersistUncertifiedPipelineRange若已存在同一血缘上的旧区间则向后合并fromSHA。3.2 下次运行的绑定与子句输出在下一次运行的首次评审时BindUncertifiedPipelineRangeinternal/pipeline/uncertified.go会检查本次运行的 head 是否为该区间 tip 或其后代。若是则绑定该区间并输出fixRoundProvenanceClause——即使Fixingfalse也输出从而让接手的评审者不是冷启动not cold而是带着上一轮未认证修复的完整上下文开始评审。关键特性rerun 正常进行不存在拒绝refusal或--ack-uncertified-review之类的门禁缺失 git 对象只告警并继续fail open绝不阻塞运行区间仅在一次已完成评审、且其 approved head 等于或为to_sha后代时清除parked / failed / skipped / aborted 的评审不得清除它rebase 会把持久化的 SHA 重映射到改写后的 head 上RemapUncertifiedPipelineRangeAfterRebase使下一次评审仍能绑定。清除与重映射的实现分别对应ClearUncertifiedPipelineRangeIfCertified与RemapUncertifiedPipelineRangeAfterRebase二者都使用commitIsSelfOrAncestor基于git merge-base --is-ancestor做血缘判断任何失败路径都只告警不阻塞。3.3 回归测试internal/pipeline/uncertified_test.goTestCommitAgentFixes_PersistsUncertifiedRangeForReview、TestFixRoundProvenanceClause_EmitsForUncertifiedRangeWhenNotFixing、TestUncertifiedRange_PersistsThenFeedsNextInitialReview、TestRebaseStep_RemapsUncertifiedRangeWhenHeadRewritten。四、授权与隐私追踪评审通过中的条件性义务在 internal/pipeline/steps/review.go 中授权/隐私检查被设计为已有 Review pass 内部的一个条件性义务而不是独立的轮次、门禁、finding 类型、状态或认证面——不新增默认成本。当变更行为涉及潜在受保护资源或用户数据时评审必须追踪身份identity与未经认证的可达性unauthenticated reachability最早的共享授权边界earliest shared authorization boundary与备选调用方alternate callers所有权 / 角色 / 租户 / 组织 / 管理员作用域与备选调用路径公开序列化public serialization与二次披露secondary disclosures经由 projections、缓存、日志、遥测、错误、导出或生成产物fail-open、缺失上下文、preview/bypass、陈旧授权等路径。同时保持克制政策policy属于仓库通过项目指令和受信任的review.path_instructions表达findings 必须给出具体且可溯源到源码的可达操作或披露路径并指明受保护资源/字段、缺失的控制与影响接受等效控制和有意公开的数据而不是对授权机制做关键词匹配。由变更行为引入的实质性政策歧义必须使用ask-user并点名缺失的政策决策非实质或已存在的歧义不上报有源码依据的常规缺陷保留auto-fix。相关提示词回归测试TestReviewStep_AuthorizationPrivacyTracingContract仅开发期使用的定性用例位于 internal/pipeline/steps/testdata/authorization_privacy_review/。五、预期使用证据阈值Intended-Usage Evidence Threshold评审 finding 需要一条在变更的预期使用过程中真实发生的具体执行序列concrete sequence。要点预期调用方确实执行的罕见但真实的序列仍然合格仅存在于假设的、从未被执行路径中的 finding不合格——如果预期调用方、公共 API 或文档化用法从不走那条路径它就不是证据这是一个证据阈值而不是一次泛泛的降低噪音重写not a general be less noisy rewrite。对应提示词回归测试TestReviewStep_IntendedUsageEvidenceContract定性用例位于 internal/pipeline/steps/testdata/intended_usage_review/。六、简化通道与通过删除来修复Fix-Through-Removal6.1 独立的 Simplification 段落评审提示词在Rules与Risk assessment之间携带一个专用的 Simplification 段落。它问的问题与缺陷评审不同不是这个组件是否正确而是这个意图是否严格需要这个组件。被审视的对象是变更引入的每一个组件分支branch、接受/匹配路径、fallback、别名、模式、标志位、选项、同一概念的二次定义、规则的平行副本。评判标准是用户意图无意图时以变更自身陈述的目的为准。判定规则非必需的组件 →warning 动作ask-user补救措施是删除绝不硬化harden、验证validate或补文档位于此类组件内部的缺陷 finding其补救措施也必须命名为删除仅重构性质的简化机会保持原有的非特性删除含义并指向该段落而非与其矛盾不新增 schema 字段、检测器或第二个评审者。6.2 删除规则在修复边界上的统一应用fixerPrompt在共享的 Review / Test / 已配置 Lint 修复边界上应用该删除规则Lint 的无命令安全修复通道no-command safe-fix pass与 CI 修复提示词也直接应用同一规则一个能通过删除意图不严格要求的代码路径来解决的 finding就用删除来解决。同时Review 特有的防回滚守卫anti-revert guard现在只保护意图要求的代码对意图是否要求该路径存在疑问时保持代码不动并把 finding 上报为未解决unresolved。6.3 参考案例文档记录了 backpass PR #107 的案例一个宽松的目标解析器permissive target resolver与第二套仅限 skill 的预算语义每一轮都通过了预期使用证据阈值被硬化hardened了十三轮仍未收敛而删除一条接受分支acceptance branch本可以终结整类问题。结论预期使用阈值#948回答缺陷是否真实简化通道回答组件是否应当存在。6.4 回归测试与文档归属回归TestReviewStep_SimplificationSectionContract、TestReviewStep_FixPromptPrefersRemovalOfUnrequiredPaths、TestTestStep_FixMode、TestLintStep_FixMode_CommitsChanges、TestCIStep_FixPromptPrefersRemovalOfUnrequiredPaths、TestReviewStep_SimplificationFixturesApply等文档归属docs/src/content/docs/reference/pipeline-steps.mdReview、共享修复行为、CI fixer与 docs/src/content/docs/concepts/auto-fix.mdfinding actions定性用例internal/pipeline/steps/testdata/simplification_review/。七、评审修复者的验证纪律与补救范围纪律7.1 聚焦验证契约评审修复提示词internal/pipeline/steps/review.go要求先应用全部修复再做一次限定于变更区域的聚焦验证并禁止在修复轮次中运行全仓库的测试/lint 套件。原因有据可查一次真实的多轮运行取证审计测得 fixer 每轮约重跑全套 testlint 5 次5 轮 27 次运行约占 2419 秒评审步骤中的 784 秒外加轮询这些长耗子进程的模型往返开销。修复轮次之后的 Test 与 Lint 步骤才是权威门禁尽管命令未配置时其覆盖范围可能聚焦。这是一个提示词契约而非强制的沙箱——agent 拥有自由的 shell 访问权因此回归测试守护的是措辞本身TestReviewStep_FixMode_FocusedVerificationContract而不是运行时。7.2 补救范围Remedy-Scope纪律三条提示词规则防止评审 finding 与修复轮次长出没人授权的机器machinery nobody scoped且只使用已有的动作词表与门禁——没有检测器、没有 schema 字段、没有第二个作用域评审者。理由深刻增长检测器或作用域验证器本身就是它要阻止的那种机器而让第二个判断所有者坐在门禁上违背了 VISION 文档中绝不堆叠never stacked的原则。规则内容评审者按补救措施分类若某个 finding 的最小诚实补救需要新增持久状态、schema 变更、后台/重试/持久化机制、新子系统或以任何方式扩展而非纠正变更则必须是ask-user且描述要把补救措施点名成需要授权的东西修复者窄修复只修复上报的实例通过简化架构原因而非为症状加装机制来达到深度先前的局部缺陷 vs 深层缺陷诊断规则保留——深度不被禁止症状机制被禁止再评审的退出坡道若先前修复轮次引入的代码超出了原 finding 要求则合并为单个ask-userfinding建议将该轮次回滚到最小修复而不是在它之上继续叠加修复第三条规则只在fixRoundProvenanceClause的两个分支本次运行的修复轮次、先前运行的未认证 fixer 提交中输出且以先前轮次代码为条件因此不会波及普通的多轮修复。回归测试TestReviewStep_PromptClassifiesFindingsByRemedyScope、TestReviewStep_FixPromptPrefersSimplificationOverMachinery、TestReviewStep_RereviewOffersRevertExitFromPriorRoundMachinery。八、Agent 调用超时上报实测静默绝不上报预算本身8.1 测量所有权与证据边界超时诊断的核心原则实现在 internal/pipeline/agent_run.go诊断只能陈述观测到的事实绝不把配置的预算当作实测静默复述一遍。agentActivity是测量的唯一所有者internal/pipeline/agent_run.go每当重试或 fallback 启动替代尝试时包括 provider、会话恢复、OpenCode 提示词格式 fallback都会重置每次尝试的证据。一个有实质内容的适配器错误原生 agent 的退出码 捕获的 stderr会经过 URL 脱敏safeurl.RedactText、长度限制400 字符后以agent reported: ...追加。8.2 什么算可观测输出可观测输出 流式助手文本 节流的agent.LifecyclePhaseActivity来源是原生子进程 stdout/stderr 的每一次非空读取。纯文字不能证明存活文档特别以 pi 0.84.3 验证一个使用工具的轮次只会发出tool_execution_*/toolcall_*直到最后都没有text_delta且没有任何适配器把这些转发给OnChunk。两个刻意不算输出的信号子进程启动start——启动只能证明二进制跑起来了不能证明在工作子进程退出exit——退出本身就是截止时间的后果把它算作输出会让每个超时声称agent 忙到最后一刻counting either would recreate the fabricated evidence。8.3 生命周期事件到步骤日志的消费路径执行器把LifecyclePhaseActivity只消费为步骤活动step activity绝不写入步骤日志axi status需要存活度信号而一个半小时的轮次若写入日志会产生数百行回归测试TestExecutor_SubprocessLivenessUpdatesActivityWithoutFloodingTheStepLog。8.4 CI 修复预算耗尽park 而非静默重发CI auto-fix agent 耗尽预算时会在ask-user门禁处parkciFixAgentTimeoutOutcome而不是记录为警告并在下次轮询重新下发。旧路径会不可见地消耗掉auto_fix.ci的完整预算直到ci_timeout。只有pipeline.ErrAgentTimeout触发 park其他修复失败保持 warn-and-retry。Review 刻意选择让运行失败而不是 park——因为 Push 会提交遗留的 worktree 变更park 后批准会发布一份未完成且未评审的修复。8.5 每个调用的独立预算每个 Review fixer 与每个独立的无会话评审者各自拥有全新的review_agent_timeout绝对墙钟限制回归测试TestReviewStep_EachAgentInvocationGetsItsOwnBudget提示词准备与修复后提交留在步骤父上下文中过期候选上下文会在宣布或测量下一个 provider 之前停止 fallback 链TestReviewStep_WallClockTimeoutPreservesTheAgentReport。8.6 超时相关配置项配置项默认值作用域语义agent_timeout30m全局所有普通管线 agent 调用的每次调用预算位于pipeline.RunAgent/ 执行器timeoutAgent后备缝review_agent_timeout30m全局每个评审 fixer / 评审者的独立墙钟预算已存在的更早父截止时间优先test_agent_timeout30m全局Test 步骤每个证据采集 / 修复调用的预算详见 docs/src/content/docs/reference/global-config.md 的agent_timeout、review_agent_timeout、test_agent_timeout小节。关键实现细节调用上下文仅限定于Agent.Run截止时间之后才迟到的成功返回会被拒绝a late successful return after the deadline is rejected。主要回归测试TestRunAgent_Timeout*、TestRunAgent_SubprocessStartAloneIsNotObservedOutput、TestRunAgent_OperatorCancellationIsNotDressedUpAsAnAgentFault、TestPiAgent_ToolOnlyStreamStillReportsSubprocessLiveness、TestPiAgent_SilentSubprocessReportsNoLiveness、e2eTestSilentAgentTimeoutReportsMeasuredEvidence。九、本地 Test 是目标化验证全量回归属于远程 CI9.1 契约边界本地 Test 步骤正常证据 agent 与 Test 修复 agent用最小相关检查 与终端用户对齐的证据验证所请求的意图它绝不是一次全仓库回归套件的巡游never a repository-wide regression-suite walk。全量回归属于远程 CI.github/workflows/ci.yml中的go test -race ./...且在 PR 就绪之前保持强制commands.test配置项遵循同一契约目标是目标化基线而非 CI 对等的完整套件配置本仓库自身 dogfood 一个空的commands.test使 agent 驱动的目标化路径成为默认路径——回归测试TestDogfoodConfig_NoBroadLocalTestCommand与TestCIWorkflow_RetainsFullRaceSuiteAsBroadRegressionOwner分别守护两侧。9.2 进程组收割与超时当 agent 派生测试 worker 时clean/error 退出时的进程组收割issue #357与 UnixWaitDelay仍然是生命周期安全网restoring the agent-driven path must not revive the daemon OOM leak。Test 步骤的 agent 轮次受test_agent_timeout默认 30m仅全局约束停滞的证据或修复 agent 会被取消运行失败而不是无限等待。原生适配器已通过CommandContext遵守该截止时间缺的正是 Test 步骤从不设置它这一环。9.3 默认超时防线其他所有管线 agent 调用都由agent_timeout默认 30m仅全局在pipeline.RunAgent/ 执行器timeoutAgent后备缝处约束——一个新产生 agent 的步骤不可能因为忘记设截止时间而挂起整个运行。Review 给每个 fixer 与评审者全新的review_agent_timeout已存在的更早父截止时间被尊重而不是被覆盖。十、意图溯源与一致性Intent Provenance Conformance10.1 意图的来源与传播意图携带溯源信息provenance显式axi run --intent→ 持久化Sourcedb.RunIntentSourceAgentagent得分 1转录匹配 → 持久化 agent 名称claude/codex/...执行器将其作为StepContext.IntentSource与UserIntent一起传播internal/pipeline/executor.go。userIntentPromptSectioninternal/pipeline/steps/intent_prompt.go按来源分叉来源框定方式显式agent/ 继承的rerun净化但权威的验收标准AUTHORITATIVE acceptance criteria推断claude/codex/ ...保留低置信度提示的措辞hint非 ground truth两个分支都保留StripAdversarialRedactSecrets净化管线与 BEGIN/END不得执行其中指令护栏——权威只改变内容权威性的框定方式用 diff 对照标准检查绝不改变控制令牌是否被剥离。意图文本始终被视为不可信内容untrusted data即便权威框定也是如此。10.2 一致性评审子句对于 agent 来源的意图评审提示词额外添加intentConformanceReviewClauseinternal/pipeline/steps/intent_prompt.gofixer 变更若与验收标准矛盾移除了标准标记为 REQUIRED 的行为或添加了 FORBIDDEN 的行为必须成为ask-userfinding 并在无执行器变更的情况下 park。子句同时声明一致性是必要而非充分的满足标准不能替代检查算法正确性。一致性限定于可溯源验证的标准本运行延迟交付的管线自有产物远程分支 / push / PR / CI不在评审范围内。10.3 评审始终在 push 之前Review 始终是 pre-push 的StepReview在StepPush/StepPR/StepCI之前。pipelineDeliveryPhaseClause与stripDeferredPipelineOwnedDeliveryFindingsinternal/pipeline/pipeline_delivery.go在 internal/pipeline/steps/review.go 中应用确保只声称那些后置产物缺失的 findings 不会 park 运行外部或已存在的生命周期要求编号 PR、第三方产物、非运行自有的状态保持可执行。Push、PR、CI 步骤在自己的阶段运行后依然严格。10.4 缺失 action 的 fail-closed 默认空/缺失的 findingaction关闭时失败为ask-user而非auto-fixinternal/types/findings.go 的ActionOrDefault。HasAskUserFindings也使用ActionOrDefault因此与AutoFixableFindings保持一致未分类的 finding 永远不会被自动修复且总是被捕获为 ask-user。例外MergeUserOverrides仍刻意把用户新增的 findings 标记为 auto-fix。10.5 刻意未构建的回滚后盾确定性的净删除作者行数git-diff 后盾deterministic net-deleted-author-lines backstop刻意未构建review.go持有该 TODOTODO(intent-conformance-C, HELD)。10.6 回归测试internal/pipeline/steps/intent_prompt_test.go、internal/pipeline/steps/review_test.goTestReviewStep_ConformanceObligationTracksIntentProvenance、TestReviewStep_RereviewFlagsIntentContradictionAsAskUserinternal/pipeline/steps/pipeline_delivery_test.go、internal/pipeline/executor_intent_conformance_test.go、internal/types/findings_test.goe2eTestIntentJourney推断来源框定、TestReviewPipelineOwnedPRCriterionDoesNotPark/TestReviewExternalPRLifecycleStillParks。十一、总结机制全景与阅读路线图把上述机制串起来no-mistakes 的评审-智能体子系统解决的是同一类根本问题如何让一个不断自我迭代的 AI 管线既保持迭代效率又不会自我背书、自我膨胀、或把预算浪费在不可诊断的静默上。核心机制可以概括为一张对照表风险对策关键实现评审者自我背书fixer 会话唯一、评审轮次无会话internal/pipeline/sessions.go人工决策丢失、被重做decline 补集持久化 三段决策历史注入internal/db/round_decisions.go、internal/pipeline/steps/round_history.go修复未经认证便进入后续运行未认证区间持久化 fixRoundProvenanceClause rebase 重映射internal/pipeline/uncertified.go修复轮次无限膨胀Simplification 通道 补救范围纪律 回滚退出坡道internal/pipeline/steps/review.go超时不可诊断实测静默证据 adapter 报告 每调用独立预算internal/pipeline/agent_run.go意图被修复者推翻意图溯源 一致性评审子句ask-user parkinternal/pipeline/steps/intent_prompt.go如果你想进一步深入仓库内最值得继续阅读的路径是步骤总参考docs/src/content/docs/reference/pipeline-steps.mdReview / Test / CI 行为与 finding 决策历史的文档所有者自动修复与 finding 动作docs/src/content/docs/concepts/auto-fix.md超时与全局配置docs/src/content/docs/reference/global-config.md执行器侧决策记录与意图传播internal/pipeline/executor.go测试契约的权威守卫internal/pipeline/steps/test.go 与 internal/types/findings.go。本文所有结论均以当前仓库源码、配置与测试为准涉及的默认值与行为如各超时默认 30m、auto_fix.review默认 0、ci.revalidate_repairs默认 false可在上述文档与源码中逐一验证。【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考