Repository navigation
decision_context: single-source the successful-read status set - #8631
2430468136 wants to merge 1 commit into
Conversation
freshness._SUCCESS_STATUSES decides which scan/attempt statuses count as a successful read (completed / no_change). The same two-member set was restated across seven sites: capture bound it as _READ_SUCCESS_STATUSES and inlined it once, assembler inlined it four times with no name at all. Both consumers already import from freshness, so borrowing the owner object adds no import edge and cannot cycle. Every site now references the owner and the restated name is retired; the distinct failure set and the four-member scan vocabulary are left untouched. The by-name semantic inventory cannot see this: the owner and the retired capture name are private _-bindings it does not catalogue, they differ by name, and four sites had no name to key on. The new guard keys on the folded value -- a whole-tree census, identity for both consumers, retirement, and behavioural parity through the owner's source_freshness_row gate. Refs loopx-project#4447. Signed-off-by: psychologister <230141834+psychologister@users.noreply.github.com>
Codex Review Summary: ❌ FailedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
loopx-agent
left a comment
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max
评审提交：bfb2ce19d39f48aae9e22a09c6a3128a3f773e98。
[P2] 全仓同值检查会把有序报表键误判为重复的成功判定。 扫描范围
动机 / Motivation
维护 Decision Context 报表和执行架构测试的开发者，以及依赖 source coverage 与 capture freshness 的操作者。 当前改动成功复用原运行时定义。无语义改动的报表分组暴露了新增的全仓失败条件。 只把现有 status_counts 的四个显示键分组，顺序和计数原样保留。三个真实 prepare-evidence 调用仍成功并给出相同结果，但新增架构测试退出 1，把 assembler.py:176 的有序数据当成第二处成功判定。 本机以真实 CLI、文件和 SQLite 验证合成数据。未验证所有外部 provider 或远端 CI；本轮未查询 CI。
把新增硬规则收回已知判定槽位。 词表收敛 RFC 将同值发现作为 advisory；状态成员相同只能供调查，不能证明同一状态槽。 核验项：successful_read_consumers_keep_observable_semantics, same_value_without_same_slot_remains_advisory。
改动思路 / Approach
运行时借用 freshness 的现有不可变集合，不需要第二个类型、provider 或 import edge。语义相同的判断可以同源；报表顺序需保留。 运行时复用限制在 Decision Context 的既有状态判定；报表的有序键和其他领域的同值字面量由自己的用途决定。 把真正的 membership 统一到 freshness 是合适的。硬检查可以直接绑定这两个已知消费者及其状态判断。
具体改动 / Changes
- freshness owner 仍使用原集合，capture 和 assembler 复用。同一真实 CLI、local-file provider 和独立 SQLite spool 对照：completed 与 no_change 保持完整覆盖和读取时间；文件缺失时组装为 unavailable，采集为 provider_failed，不更新最近成功时间和游标，失败计数从 0 增为 1。关闭采集时不建 spool；capture-status 保持只读。PR 基点 36 项通过，当前提交 63 项通过。
- 新架构规则 会把 set、list 和 tuple 折叠为同一个集合。将 _source_coverage 的报表顺序写成 (*("completed", "no_change"), "failed", "unavailable")，然后运行真实 prepare-evidence 和新增 pytest：只把现有 status_counts 的四个显示键分组，顺序和计数原样保留。三个真实 prepare-evidence 调用仍成功并给出相同结果，但新增架构测试退出 1，把 assembler.py:176 的有序数据当成第二处成功判定。
对主干的风险 / Risks
当前提交在既有运行时用例中无回归。风险来自新测试的失败范围；它同时检查状态判定与显示数据。现有失败集合、全扫描状态和旧 spool 迁移没有随这两处 Python 文件改写。即使按现有四个状态分组且一个键也没有增删，原有常规架构验证仍会被拦。Ruff、差异、DCO、双语 RFC 和合入模拟通过。
我的整体评价 / Verdict
请求修改。仓库检查把能正常工作的有序报表数据误当成重复定义。 把阻断测试限制在已知的成功状态绑定和 membership 判断，保留捕获真正重复判定的正例，并加上有序报表列表的反例。全仓同值候选可以继续作为 advisory 输出。
English verdict: REQUEST_CHANGES. Head bfb2ce1. The shared runtime predicate preserves capture and coverage. The new whole-package assertion rejects an order-preserving status_counts grouping although all three real prepare-evidence outputs match. Restrict blocking checks to known successful-read decisions and allow ordered report data.
| @pytest.fixture(scope="module") | ||
| def tree_offenders() -> dict[str, list[int]]: | ||
| offenders: dict[str, list[int]] = {} | ||
| for path in sorted(PACKAGE_ROOT.rglob("*.py")): |
There was a problem hiding this comment.
[P2] 只在已知的成功判定位置阻止重述。 将 _source_coverage 的报表顺序写成 (*("completed", "no_change"), "failed", "unavailable") 后，真实 prepare-evidence 的键顺序、计数、覆盖和 freshness 保持一致，新增测试却退出 1，报 assembler.py:176。请把硬检查限定到状态判定，保留有序报表数据的反例。
What
The successful-read status set
{completed, no_change}was restated across seven sites indecision_context:capture.pybound it as_READ_SUCCESS_STATUSESand inlined it once;assembler.pyinlined it four times with no name at all. Every site now references the single ownerfreshness._SUCCESS_STATUSES; the restated name is retired.Why
Both consumers already import from
freshness, so borrowing the owner object adds no import edge and cannot cycle (freshnessimports only.sources). The distinct failure set (_READ_FAILURE_STATUSES) and the four-member scan vocabulary (sources._SCAN_STATUSES) are different concepts and are left untouched.The by-name inventory cannot see this: the owner and the retired capture name are private
_-bindings it does not catalogue, they differ by name, and four of the seven sites had no name to key on.Guard
New
tests/architecture/test_decision_context_success_status_owner.pykeys on the folded value: whole-tree census (only the owner states the set), identity for both consumers, retirement, the failure/vocabulary neighbours are different sets, and behavioural parity through the owner'ssource_freshness_rowgate (a success attempt does not alert; a failed attempt alerts with its status). Poison-proven across set / frozenset / list / tuple / renamed / nested forms.Tests
Architecture guard (27 cases) + decision_context behavior suite (193 tests) pass locally. Full architecture suite: failure set byte-identical to the clean base tree (96 = 96, of which 94 are the missing npm/TypeScript dev-dependency environment cause) -- net regression 0.