[loopx-agent]

Required vocabulary scans repeatedly rebuild Python scope environments for queries that cannot produce evidence. Reuse a bounded census of parsed field names across literal and production scans, retaining registered returns, qualified enums/builders, syntax failures and unknown evidence. The existing analyzer and native 120-second budget remain in place.

The parser's return annotation now states its actual ast.Module result, so normal import-following type checks also cover the inventory dependency. Runtime parsing, failure logic and vocabulary scope are unchanged. No Core authority, context/capture format, option or persistent cache is added.

Validation at 1dc6cb85d1203eeea1236d70c3127782fd375379, against main a36e01c32b0a290a96466c766629a0b01850f823:

• 142 production/binding/inventory tests pass, including escaped and normalized names, syntax errors, source changes under forced hash collisions, registered outputs without a field mention and unknown returns.
• Same 1,769 SourceFiles under the immutable baseline analyzer and final analyzer: all 137 production observations across 53 nonempty cases match, including unknowns. Both corpus arms have zero nonempty literal observations; targeted tests cover positive literal behavior.
• One matched component sample uses 22.8 → 19.7 seconds of process CPU, with elapsed time 23.9 → 21.7 seconds. Peak self RSS is 783,384,576 → 774,438,912 bytes in this sample; a prior sample increased by about 9 MiB. Memory and wall-time effects vary, so this does not establish a stable memory saving, p95, whole-command or end-to-end cost benefit. Earlier contended runs and timeouts remain retained.
• An unsafe field-only shortcut is rejected by the native checker for four missing declared producer sites. The scanner body is unchanged from that sensitivity check. Its initial wrapper-wording diagnostic and subsequent captured-result assessment remain retained.
• Ruff, configured mypy with a fresh cache (17 files), and uv run --extra test mypy loopx/semantics/python_production.py loopx/semantics/inventory.py (2 targets) pass. Before the final annotation repair, the latter exposed one inventory error; the immutable baseline analyzer reproduces that error plus the 11 already-repaired scanner errors. No failed run is relabeled.
• Changed-scope documentation remains identical to the governance-checked source; final public-file checks are clean. Vocabulary advisory finds no supported new carriers and retains its documented coverage limits.

Standard native premerge passes: 6 direct checks and all 5 selected checks, no warnings, skips or tracked side effects. Full vocabulary scanning passes in 50.659 seconds within the unchanged 120-second limit. Exact-scope author quality matches the final head; merge review/readiness and authority remain separate.

The original 64a60ba test/native results remain historical evidence for that head. #7696 includes these exact shared commits for its own combination validation. Neither proposal qualifies another head automatically. CI has not been queried or triggered, and no merge is performed. The unified work-contract cutover and long-horizon outcome/full-cost acceptance remain open.

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

建议通过当前 head 64a60ba185895d022c5d1b9c933c67cee6cb70c1：优化保留完整 producer/unknown 证据，正反例和原预算下的 native 检查均已独立验证。

动机 / Motivation

维护者执行全仓 vocabulary 检查时，同一个 Python 模块会被多个词汇重复分析，必需检查因而消耗更多 CPU 和等待时间。 旧版即使模块没有相关字段、注册 return、enum 或 builder，也会构建局部分析环境；本次先复用已解析的名称事实，只跳过确实不可能产生相关输出的模块。 冻结相同扫描输入后，四次 base/head 对照的完整结果一致，204 条 production 及其中 59 条 unknown 全部保留，head 的实测扫描耗时和 Python CPU 较低。 本次不修改词汇定义、扫描范围、unknown 分类、原 120 秒门槛、产品运行时或任何 Goal 的执行权限，也不宣称长期 p95 或模型效果收益。 完整 native check 本轮单次为 base 50.52 s、head 58.84 s，尚未证明端到端 wall 加速；长期 p95、更多机器及大文件内存仍需现有性能诊断 owner 验证。

改动思路 / Approach

优化留在既有 Python 静态分析 owner，复用其 AST、qualified bindings 和注册 producer 规则，既避免重复决策 owner，也保留不能由字段名独自决定的输出证据。 本 PR 交付完整扫描的局部成本优化、回归负例及按需修复指导；TypeScript 语义、registry、实时产品控制面和跨会话持久化不变。

关键在于“没有相关字段”不能单独推出“没有 producer”。函数先解析源码并建立 qualified enum/builder bindings，保留注册 return，再判断是否可以省去局部环境构建。共享 helper 只缓存完整源码推导出的名称集合，不执行待检查源码，也不创建第二份 AST 或手工同步的状态。语法错误仍在证明缺席之前报错，unknown 不会因优化消失。

具体改动 / Changes

3 个文件共 79 行增加、27 行删除：既有 Python 分析器 43/27，针对性测试增加 35 行，按需读取的 self-repair reference 增加一行。其余类型注解、cast 和变量改名没有改变执行分支；没有修改 registry、词汇枚举、扫描路径或 TypeScript 语义 owner。

关键代码讲解

1. _field_mentions 复用现有 parser，收集 AST name、attribute、字符串 key 和 keyword，因此 escaped key、NFKC 标识符能被识别。缓存以完整不可变 SourceFile 为 key，容量 4096 条；源码变动和 hash collision 不会借用旧文件的结果。
2. python_literal_uses 先使用上述解析事实排除缺席字段，再进入原来的 literal/比较操作扫描；保留非法语法报错及既有输出语义。
3. scan_python_production 只有字段、registered return、qualified enum 和 builder 全部不适用时才提前返回。存在任一输出形式就继续原分析，包含值尚不确定的 return，避免用更快的“空结果”冒充覆盖。

采用变更前已接受的 docs/architecture/rfcs/semantic-vocabulary-convergence-v0.md，固定 revision a36e01c32b0a290a96466c766629a0b01850f823。I2 的 bounded grammar 与 unknown 保留、I7 的确定性/受控源码检查、I8 的完整扫描覆盖均 implemented；I11 的真实输出角色、I12 的 producer liveness、I13 的 closedness 仍由原 owner 强制，已用独立语法反例、完整扫描和故意破坏的 native 负例验证。未把 RFC 后续成熟度或模型采用提升为本 PR 已完成结果。

对主干的风险 / Risks

最危险的捷径是只看字段名就跳过：即便普通 literal 测试通过，注册 scalar return、enum、builder 或 unknown 仍可能丢失。独立故意加入此错误规则后，原 native checker 明确拒绝 4 个 turn_result_kind executor producer site；正确实现保留这些 site。PASS 四个 architecture 模块共 228 项测试，覆盖 escaped/NFKC、字段缺席时的四种输出、语法错误、同路径源码变化与 hash collision。

冻结相同官方扫描输入（1769 个 Python/TypeScript source，含 1389 个 Python），固定 registry 与 TypeScript source/runtime，在独立 Python 3.14.8 进程按 ABBA 顺序运行。每个完整 site/line/form/value/unresolved/blocker 结果逐项相同，204 条 production、59 条 unknown、6 个非空 producer query 保留。当前 corpus 的 literal union 为 0，不能拿这个空集证明正例语法，正例由前述针对性测试补足。

次序 / analyzer	扫描阶段 elapsed	Python self CPU	Python peak RSS
base-1	44.46 s	15.36 s	765 MiB
head-1	27.15 s	8.47 s	787 MiB
head-2	22.94 s	8.89 s	768 MiB
base-2	36.25 s	16.51 s	770 MiB

这组测量显示本机该 workload 的成本降低；不是 p95，也不包含子进程内存。child CPU 单独记录，未把 Python 等待当成 Node CPU。使用原生 performance-diagnosis plan/inspect 对自有进程生成并读回 Pyinstrument profile，观察与减少重复扫描相符；profile 的 instrumented wall 不作为上表数据。另只关闭 absence 优化、强制完整扫描的同 head 控制仍得到全部相同结果，扫描 32.06 s、self CPU 17.40 s，进一步检查成本归因。

PASS 原标准 premerge 的 6 direct + 5 selected，没有提高 120 秒 native 门槛；完整 native check 的单次 wall 为基线 50.52 s、head 58.84 s，均通过，但这对完整入口结果并不证明整体加速。组件 CPU 与完整门禁耗时分别保留，不能只挑更快的观测。此前其他精确 head/环境的超时记录仍保留，本次没有据此宣称旧根因已修复。补充测试首次因重复加载 conftest 在收集前失败，改用正常自动发现后 148 项通过；所有失败记录保留，产品代码、断言与预算未改。未查询或等待远端 CI。

语义与 CI 对齐

这是 local_only 的实现优化，复用现有 AST、producer 和 unknown 词汇。必需全仓 check 仍是原有强制门禁；新增 repair pattern 是按需指导，要求完整输入/输出、CPU/内存、原预算与失败记录，未创建新的执行或审批权力。缓存仅按条目数有界，不能宣称字节级内存上限；本轮 head 峰值约 768–787 MiB，base 约 765–770 MiB，应保留这项成本。

我的整体评价 / Verdict

这是 justified_increment：局部扫描 CPU 成本降低，正确性与原门禁保持，规模与问题相称。long_horizon 的证据/约束及维护者的完整诊断体验保持；完整 native 入口的总耗时收益仍未证明，原有未知并未被归零。已检查静态检查入口、三个文件的完整 diff 及 repair-patterns 加载位置；没有渲染页面、布局或 disclosure 变化，无需截图。

同域重构已复用现有事实 owner，更多 cache 改造或跨语言迁移没有当前必要。完整结果、真实 native 门禁和能失败的反例共同支撑判断；长期 p95、其他机器/大文件内存、模型采用与完整成本净收益仍未验证。代码审评结论不授予合并、安装或升级权限，仍需独立 exact-head merge readiness。

English verdict: APPROVE — complete semantic parity and original-budget native validation support the local optimization; memory costs and performance limits are disclosed.

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

建议通过当前 head 1dc6cb85d1203eeea1236d70c3127782fd375379：优化保留完整 producer/unknown 证据，正反例和原预算下的 native 检查均已独立验证。

动机 / Motivation

维护者执行全仓 vocabulary 检查时，同一个 Python 模块会被多个词汇重复分析，必需检查因而消耗更多 CPU 和等待时间。 旧版即使模块没有相关字段、注册 return、enum 或 builder，也会构建局部分析环境；本次先复用已解析的名称事实，只跳过确实不可能产生相关输出的模块。 前一 head 64a60ba 的冻结 ABBA 比较保留全部 204 条 production 与 59 条 unknown，并显示扫描组件 CPU 降低；当前 1dc6cb8 已重新核验完整输出、类型、相关测试与 native 门禁，旧批准未沿用。 本次不修改词汇定义、扫描范围、unknown 分类、原 120 秒门槛、产品运行时或任何 Goal 的执行权限，也不宣称长期 p95 或模型效果收益。 前一完整 native 单次为 base 50.52 s、64a head 58.84 s，当前 1dc head 为 66.20 s，均未超原门槛；整体入口加速、长期 p95 和大文件内存仍未资格化。

改动思路 / Approach

优化留在既有 Python 静态分析 owner，复用其 AST、qualified bindings 和注册 producer 规则，既避免重复决策 owner，也保留不能由字段名独自决定的输出证据。 本 PR 交付完整扫描的局部成本优化、回归负例及按需修复指导；TypeScript 语义、registry、实时产品控制面和跨会话持久化不变。

关键在于“没有相关字段”不能单独推出“没有 producer”。函数先解析源码并建立 qualified enum/builder bindings，保留注册 return，再判断是否可以省去局部环境构建。共享 helper 只缓存完整源码推导出的名称集合，不执行待检查源码，也不创建第二份 AST 或手工同步的状态。语法错误仍在证明缺席之前报错，unknown 不会因优化消失。

具体改动 / Changes

4 个文件共 80 行增加、28 行删除：既有 Python 分析器 43/27，inventory parser 的返回标注 1/1，针对性测试增加 35 行，按需读取的 self-repair reference 增加一行。其余类型注解、cast 和变量改名没有改变执行分支；没有修改 registry、词汇枚举、扫描路径或 TypeScript 语义 owner。

关键代码讲解

1. _field_mentions 复用现有 parser，收集 AST name、attribute、字符串 key 和 keyword，因此 escaped key、NFKC 标识符能被识别。缓存以完整不可变 SourceFile 为 key，容量 4096 条；源码变动和 hash collision 不会借用旧文件的结果。

2. python_literal_uses 先使用上述解析事实排除缺席字段，再进入原来的 literal/比较操作扫描；保留非法语法报错及既有输出语义。

3. scan_python_production 只有字段、registered return、qualified enum 和 builder 全部不适用时才提前返回。存在任一输出形式就继续原分析，包含值尚不确定的 return，避免用更快的“空结果”冒充覆盖。

4. parse_python 把返回类型从宽泛的 AST 修正为实际的 Module，供已有 .body consumer 正常 typecheck。函数仍调用默认 exec 模式的 ast.parse，源码、异常包装、缓存策略和权限逻辑都没有变化。

采用变更前已接受的 docs/architecture/rfcs/semantic-vocabulary-convergence-v0.md，固定 revision a36e01c32b0a290a96466c766629a0b01850f823。I2 的 bounded grammar 与 unknown 保留、I7 的确定性/受控源码检查、I8 的完整扫描覆盖均 implemented；I11 的真实输出角色、I12 的 producer liveness、I13 的 closedness 仍由原 owner 强制，已用独立语法反例、完整扫描和故意破坏的 native 负例验证。未把 RFC 后续成熟度或模型采用提升为本 PR 已完成结果。

对主干的风险 / Risks

最危险的捷径是只看字段名就跳过：即便普通 literal 测试通过，注册 scalar return、enum、builder 或 unknown 仍可能丢失。独立故意加入此错误规则后，原 native checker 明确拒绝 4 个 turn_result_kind executor producer site；正确实现保留这些 site。PASS 当前六个 architecture 模块共 297 项测试，Ruff 与使用全新 cache 的两个 mypy target 也通过；覆盖 escaped/NFKC、字段缺席时的四种输出、语法错误、同路径源码变化与 hash collision。

以下 ABBA 与 profile 是前一 head 64a60ba185895d022c5d1b9c933c67cee6cb70c1 的实测，保留其原始 revision。64a 到当前 1dc 仅有 parser 返回类型标注变化，其余三个文件逐字相同，scanner 和 parser runtime body 未变。当前 head 又以相同冻结输入复验，全部观测与基线/原 ABBA 一致（本次单样本 elapsed 43.64 s、self CPU 8.58 s）。原 ABBA 冻结相同官方扫描输入（1769 个 Python/TypeScript source，含 1389 个 Python），固定 registry 与 TypeScript source/runtime，采用独立 Python 3.14.8 进程。每个完整 site/line/form/value/unresolved/blocker 结果逐项相同，204 条 production、59 条 unknown、6 个非空 producer query 保留。当前 corpus 的 literal union 为 0，不能拿这个空集证明正例语法，正例由前述针对性测试补足。

次序 / analyzer	扫描阶段 elapsed	Python self CPU	Python peak RSS
base-1	44.46 s	15.36 s	765 MiB
head-1	27.15 s	8.47 s	787 MiB
head-2	22.94 s	8.89 s	768 MiB
base-2	36.25 s	16.51 s	770 MiB

这组测量显示本机该 workload 的成本降低；不是 p95，也不包含子进程内存。child CPU 单独记录，未把 Python 等待当成 Node CPU。使用原生 performance-diagnosis plan/inspect 对自有进程生成并读回 Pyinstrument profile，观察与减少重复扫描相符；profile 的 instrumented wall 不作为上表数据。另在原 64a head 只关闭 absence 优化、强制完整扫描的控制仍得到全部相同结果，扫描 32.06 s、self CPU 17.40 s，进一步检查成本归因。

PASS 当前 exact head 标准 premerge 的 6 direct + 5 selected，0 超时，未提高 120 秒门槛；完整 native check 单次为基线 50.52 s、前一 64a head 58.84 s、本次 1dc head 66.20 s。这些有限观测不证明完整入口稳定加速。组件 CPU 与完整门禁耗时分别保留，不能只挑更快的观测。此前其他精确 head/环境的超时记录仍保留，本次没有据此宣称旧根因已修复。补充测试首次因重复加载 conftest 在收集前失败，改用正常自动发现后 148 项通过；所有失败记录保留，修正测试命令时未改产品代码、断言与预算。未查询或等待远端 CI。

语义与 CI 对齐

这是 local_only 的实现优化，复用现有 AST、producer 和 unknown 词汇。必需全仓 check 仍是原有强制门禁；新增 repair pattern 是按需指导，要求完整输入/输出、CPU/内存、原预算与失败记录，未创建新的执行或审批权力。缓存仅按条目数有界，不能宣称字节级内存上限；原 64a ABBA 的 head 峰值约 768–787 MiB，当前 1dc 单样本约 771 MiB，base 约 765–770 MiB，应保留这项成本。

我的整体评价 / Verdict

这是 justified_increment：局部扫描 CPU 成本降低，正确性与原门禁保持，规模与问题相称。旧 head 批准后出现新提交，已对当前四文件整体重新判定，并复验新增类型边界；旧批准保留为历史，未直接采用。long_horizon 的证据/约束及维护者的完整诊断体验保持；完整 native 入口的总耗时收益仍未证明，原有未知并未被归零。已检查静态检查入口、四个文件的完整 diff 及 repair-patterns 加载位置；没有渲染页面、布局或 disclosure 变化，无需截图。

同域重构已复用现有事实 owner，更多 cache 改造或跨语言迁移没有当前必要。完整结果、真实 native 门禁和能失败的反例共同支撑判断；长期 p95、其他机器/大文件内存、模型采用与完整成本净收益仍未验证。代码审评结论不授予合并、安装或升级权限，仍需独立 exact-head merge readiness。

English verdict: APPROVE — complete semantic parity and original-budget native validation support the local optimization; memory costs and performance limits are disclosed.