refactor(semantics): compute the registry I/O census on demand

[huangruiteng]

The tracked project-registry I/O census contains generated call coordinates, so ordinary source edits force snapshot updates and create merge conflicts. Compute that census from the current tracked product tree in the existing semantic premerge check, and keep only the nine reviewed direct-I/O classifications under version control.

• Remove the generated manifest and ignore its former path. Preserve the v1 report shape and the existing Python/TypeScript scanner coverage.
• Store reviewed classifications by site identity without coordinates. Unclassified direct I/O, stale classifications and invalid labels remain failures; an exported report cannot grant a classification.
• The generator now prints JSON without writes by default. Optional --output exports and explicit --output ... --check remain available; --check alone is rejected. Exclude the legacy report from both source and wheel distributions.
• Update the existing census tests, premerge guidance, developer documentation and the bilingual Goal-instance RFC checkpoint.

Validation:

• On the latest main baseline (896fec6a52), the derived report exactly matches all 303 previous census rows, including classifications and coordinates.
• 62 relevant census, binding-inventory, semantic-inventory and codec/M0 tests passed after the main rebase. Negative cases cover unclassified/stale/invalid policy, poisoned reports, moved calls and read-only export checks.
• The full semantic drift smoke passed; the changed-source advisory reported no supported new vocabulary carriers. Ruff and diff checks passed.
• Canary premerge passed 14 selected checks plus 5 direct checks before the latest-main rebase and a local variable rename; the final integration was rechecked with the 62 tests and full semantic smoke above.
• Built wheel and sdist with an intentionally malformed legacy report present locally: both excluded it and retained the reviewed classifications. The initial build lacked the required Chat bundle; building it and retrying succeeded.
• Mypy is not green: a focused base/head comparison has the same six existing diagnostics; the dependency-following run also fails. No repository-wide typecheck or full pytest pass is claimed. Remote CI and exact-head review remain pending.

This is source-checkout validation tooling. Registry codec behavior and the frontend/Lark/product CLI journeys are unchanged. The existing Python AST provider remains the owner; no new capability, classification vocabulary or parallel control-plane decision owner is introduced. The related refactor separates reviewed policy from derived observations and retires report-backed classification authority.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @huangruiteng.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; xhigh

动机

维护注册表读写规则的开发者。 以前只移动代码行也要重新生成并提交整份读写清单；现在直接扫描当前受 Git 跟踪的源码，只提交需要人工判断的例外分类。

303 个源码调用点与变更前提交的清单逐项一致，新直接写入仍被拒绝，默认生成命令只输出 JSON。 这是开发验证工作流调整，不证明整个实例恢复 RFC、安装采用、扫描完备性的形式化证明或长期效率收益。

改动思路

继续复用原 Python/TypeScript scanner，把易变坐标从持久清单移到派生报告，九项人工例外由一个独立策略文件拥有。 本 PR 交付完整的源码扫描、分类、报告和打包边界；不启用实例迁移或新增产品入口。

这次不是删除审查依据：源码调用点是可派生数据，例外是否允许仍是人工判断。报告与人工分类分开，避免每次改行号同步大文件，也防止旧报告自行授予分类。Python 保留在现有 AST 扫描 provider，TypeScript scanner 沿用；没有新通用控制面规则。

具体改动

审查 head：3803009793ef83836ec90905991f8d89d4920e25。固定规格：docs/architecture/rfcs/goal-instance-identity-and-orphan-recovery-v0.md，变更前版本 896fec6a52e29390994976569bf4af5e29190734。

Strict codec is exhaustive：Static writer inventory plus Python/TS conformance; no direct project-registry write bypass. → implemented；M0：Codec census prerequisite does not activate instance lifecycle enforcement. → implemented。

关键代码讲解

• build_project_registry_io_manifest：当前源码扫描配合人工分类，生成相同 v1 派生报告。
• load_project_registry_io_classifications：只从独立策略读取字符串分类，导出报告无策略权。
• validate_project_registry_io_manifest：校验新直接调用、失效和非法分类；可比较显式导出。
• main：默认 stdout；显式输出/只读比较，裸 --check 明确拒绝。

完整14文件 +271/-2549：原 v1 快照2449行删除，新增9项分类；generator、semantic smoke、canary reason、两份架构 checkpoint、开发指引、忽略/打包规则及两组测试一起更新。源枚举、排除项和分类词汇未重写。默认无文件写入，显式报告可以比较，裸 --check 的迁移提示明确。

对主干的风险

独立比较变更前提交清单和当前实际扫描，303项完整行（含坐标）逐项相同，9项人工分类一致。真实 generator 与 semantic smoke 在隔离 Git 源树中拒绝新增直接 writer，即使残留报告伪造已分类；移除新增 writer 后恢复303项。默认 stdout、显式 output/check、stale report 不写入和裸 --check 拒绝通过。真正构建 wheel/sdist 后，残留无效旧报告均被排除，9项分类均在包内。

62项聚焦测试、Ruff、advisory 后全树 semantic smoke，以及 native canary 5直接/14选择检查通过。focused mypy 仍有6项既有 AST/排序诊断；同命令对 immutable base/head 的完整诊断仅归一化行号后相同，未放宽断言。首次 build 因该 worktree 的旧 Chat assets 与源码不符拒绝，按仓库正常重建后打包通过；临时 fixture 的依赖和字段/产物枚举错误属于评审 harness，已保留和修正。没有读取 CI，也不宣称全部 pytest、动态扫描形式化完备或安装采用。

我的整体评价

APPROVE，未发现该有界源码提案的阻塞问题。继续复用原 Python/TypeScript scanner，把易变坐标从持久清单移到派生报告，九项人工例外由一个独立策略文件拥有。 本 PR 交付完整的源码扫描、分类、报告和打包边界；不启用实例迁移或新增产品入口。 相关收敛已经应用：删除派生坐标的第二份持久状态，保留唯一人工分类和原 scanner。开发者少一个反复生成/提交步骤，例外审查仍明确；长期耗时和模型采用收益未实测。

English verdict: APPROVE - head 3803009; on-demand census preserves all303 immutable baseline rows and9 reviewed exceptions; real poison/new-writer rejection, wheel/sdist,62 tests and risk checks pass. Six independently unchanged baseline mypy diagnostics retained.

[loopx-agent]

refactor(semantics): 按需计算 registry I/O 普查（解冲突后复审）

复审对象为解冲突后的最新 head，commit_id 精确对齐本次推送的 merge 提交
4c65c97723bbc083232b1e25059f07746e9a67d7。此前该 PR 落后主干 221 个提交且冲突，
本次由我同步最新主干并解决冲突后重新取证，不改动原作者意图与改动范围。

动机

受版本控制的 project_registry_io_manifest_v1.json 里含有生成的调用坐标（文件、行列、
site 名），因此任何普通源码移位都会让快照失效，产生无意义的大 diff 与合并冲突，并让
“快照即权威”成为隐患——导出的报告反过来可能给位点赋予分类。此次重构把普查改为从当前
tracked 源码即时派生，只把经人工审阅的直接 I/O 分类纳入版本控制，从机制上消除快照抖动，
同时保留原有 codec 边界的守护。

改动思路

普查的所有权收敛为“派生观测 + 人工策略”两层：调用坐标与 codec 位点由
build_project_registry_io_manifest 从 tracked 源码即时计算，不再是仓库权威；只把九个
经审阅的直接 I/O 位点（以不含坐标的稳定身份为键）保存在
project_registry_io_classifications_v1.json。校验器 validate_project_registry_io_manifest
允许省略 manifest（直接校验当前源码），并要求：未分类的直接 I/O、失效分类和非法标签
一律失败，报告导出不得充当分类来源。生成脚本默认只打印 JSON，--output 才落盘，
单独的 --check 被拒绝。冲突解决原则是保留本次重构的主旨：主干上被重新生成的
manifest 仍应被删除，而不是让快照复活。

具体改动

loopx/semantics/project_registry_io.py 用 DIRECT_IO_CLASSIFICATIONS_PATH 取代
PROJECT_REGISTRY_IO_MANIFEST，新增 load_project_registry_io_classifications 并在
build_project_registry_io_manifest / validate_project_registry_io_manifest 中默认加载策略；
校验新增“失效分类（stale）”与“非法标签”两类错误，且未分类直接 I/O 继续失败。
scripts/generate_project_registry_io_manifest.py 改为默认打印、可选导出、--check 需配合
--output；examples/semantic-vocabulary-drift-smoke.py 改为直接调用无参校验并在失败信息里
指向策略文件；loopx/canary/planner.py 更新了该检查的失败原因文案。
project_registry_io_manifest_v1.json 整份删除（2457 行）并在 .gitignore 忽略；
MANIFEST.in 与 pyproject.toml 的 exclude-package-data 把它排除出源码与 wheel 分发，
同时分类文件仍通过已有的 "loopx.semantics" = ["*.json"] 打进包。文档侧更新了
docs/development/testing-and-quality.md 与双语 Goal-instance RFC，测试侧重写了
tests/architecture/test_project_registry_io_census.py 并简化了
test_goal_instance_binding_inventory.py。

冲突只有一处：project_registry_io_manifest_v1.json 被本分支删除、却被主干再次修改
（主干把新文件的坐标重新生成进去）。这正是本 PR 要消灭的抖动脉冲，因此解决方式为保留
删除（git rm），不保留主干重新生成的快照；其余文件均自动合并。解冲突后净 diff 相对
主干恰为原 PR 的 14 个文件。

对主干的风险

风险面窄且方向是“减少漂移”。改动只影响普查的所有权与校验入口，不改变 registry codec
行为、前端/Lark/产品 CLI 旅程，也未引入新的能力、分类词汇或并行的控制面决策所有者；
Python AST provider 仍是既有的所有者。需要如实说明的残余风险：一是本次验证以本机真实
测试与构建取证，安装态/托管 CI 未核对；二是主干上继承的红灯 lane 与本 PR 无关——我在
未改动的 origin/main 上复现了同样的两处失败：模块数预算把上限钉在 147 而当前树只有
146 个顶层模块，以及 loopx/capabilities/benchmark_toolkit/integrity.py 出现第二个裸
digest 形状所有者，二者均非本改动引入；三是我的 mypy 运行（uv run --no-sync mypy）
在配置的 19 个文件上零报错，本 PR 触及的 loopx/semantics 与 loopx/canary 不在 mypy
目标集内，因此未对它们声明 mypy 结论。合并权限保留在维护者手中，我以管理员身份合并仅
用于绕开依赖主干继承红灯的 merge-gate。

我的整体评价

这是一次方向正确、边界清晰的结构性重构：把 registry I/O 普查从“受版本控制的生成快照”
改为“按需派生观测 + 受版本控制的人工策略”，在不削弱 codec 边界与失败语义的前提下消除
了快照抖动与合并冲突。冲突解决忠实于 PR 主旨——删除被重新生成的快照而非让它复活。
本机取证：test_project_registry_io_census.py 15 项全过，含“无签入快照时当前树仍有效”；
相关 architecture/canary 共 1512 项中仅 2 项失败且已在纯主干复现为继承红灯；307 项
语义/契约子集全过；semantic-vocabulary-drift smoke 输出 ok；ruff 全过，mypy 目标集零报错；
实际构建的 sdist 与 wheel 均排除旧 manifest 且保留分类文件。综合判断可以合并。

English verdict: APPROVE