Repository navigation
test(indexer): retain retrieval efficiency and accuracy evidence for #255 - #256
Conversation
Evidence-only delivery for #255. Preserve v1 FAIL, separate focused v2 result, partial-label accuracy and reproducible raw outputs. Runtime optimization is withheld; production source matches baseline. Prepared in local commit 1a06702788ec834d2fd5eca7ee31877163e9cbb6; published through the owner-authorized GitHub connector with an identical tree. Candidate source/tests retained only as a reproducible patch and Git bundle. Signed-off-by: Codex <codex@openai.com>
Codex Review SummaryThis 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. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2a31244e98
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| assert len(result["bundles"]) == 10 | ||
| assert result["checked_hashes"] == 166 |
There was a problem hiding this comment.
Update the expected verified-hash count for the new bundle
Registering the new campaign adds 33 verified hashes, so validate_inventory(repo) now returns checked_hashes == 199, but the next assertion still expects 166. I reproduced this with PYTHONPATH=src pytest -q tests/test_evidence_inventory.py tests/test_indexer_evaluation_summary.py: test_checked_in_inventory fails despite inventory validation reporting no errors. Update the hash-count expectation alongside the bundle count so the full pytest step in .github/workflows/ci-ready.yml does not fail on this change.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 10e6c0c: expected checked_hashes is now 199. The exact committed tree passes the affected tests (17 passed); inventory validation reports no errors and 199 checked hashes. The report now explicitly identifies the retained 89-pass log as preceding final manifest inclusion, rather than proof of the final tree. A separate post-manifest verification receipt avoids a self-referential log/hash cycle. Frozen benchmark data and the v1 FAIL verdict are unchanged. New-head hosted CI is pending; this reply does not claim a full-suite pass.
…n chronology Correct expected checked hashes to199 after the33-entry manifest was added. Preserve the earlier89-pass log while explicitly recording that it preceded final manifest inclusion; add a post-manifest affected-test receipt. Frozen benchmark observations and verdicts are unchanged. Tree matches locally tested commit e5dec0519994d1a9cb5d7296b8984d8762404c9e; affected tests17passed on that exact committed tree. Published through the owner-authorized GitHub connector. Signed-off-by: Codex <codex@openai.com>
Dong1017
left a comment
There was a problem hiding this comment.
Scoped LGTM for the evidence-only delivery at head 10e6c0cb00323b295468fc1480956dee5b3acf69, against API base / observed main 401ee8a256c21e6c489e7d179e62c70ac08723d3.
The earlier inventory-count finding is cleared: the current assertion expects 199 hashes. I reviewed the runner, fixtures, protocol, supplemental audit, report and changed-path inventory; no production src/ changes are included. No additional blocking finding in this assessed scope.
From the retained observations, I independently recomputed the 20-group primary reduction (58.610526%), CLI-search p95 regression (52.719334%), paired output equality, and the separate 120-pair confirmation point estimates (+9.973407% p50 / -3.210342% p95). They agree with the report. The frozen v1 verdict remains FAIL; v2 does not replace it. The small partial-label held-out result and the post-run delivery audit do not establish an accuracy gain or downstream agent benefit.
All four current-head Ready jobs pass. The inspected Python3.11 log records Ruff success, 2534 passed, 11 skipped and 284 subtests on merge a28cbe8a455214798beb3212bb8df97d6bcb1fe2, combining the stated base and head. The latest per-head policy status succeeds. These changed paths do not select the existing SkillEval workflow; no model execution is implied.
The original measurements remain bound to baseline ab03f3ffb8f2e5bc02c304828c5c41890eef673e and its frozen candidate/corpus, not the newer main corpus. Verification here was source/existing-CI inspection and arithmetic on retained timings; I did not rerun benchmarks, replay compressed case archives, or execute a model/device experiment.
Next for the existing author and #255 acceptance owner: decide whether to merge this evidence/tooling slice; keep runtime promotion and the two tracker objectives separate. This review does not accept the rejected runtime optimization or close #255. COMMENTED is used because the authenticated account is also the PR author; no formal self-approval or merge action.
Summary
Refs #255. This is an evidence-only delivery, not acceptance of an Indexer runtime optimization and not closure of the two-goal tracker.
Results and decision
Full efficiency/accuracy report
Decision: do not promote the runtime candidate. This PR supplies reusable measurement and honest evidence.
Reproduction and provenance
ab03f3ffb8f2e5bc02c304828c5c41890eef673e; 751-file corpus. Later main401ee8a256c21e6c489e7d179e62c70ac08723d3changes corpus/reader metadata behavior; these numbers are not measurements on that newer corpus.6da28494891b21cdc89f632d84d763bc997b7d15, retained only as reproducible patch/bundle.1a06702788ec834d2fd5eca7ee31877163e9cbb6.2a31244e98b3d94b7ceffcde184c6330a5ac5f11; identical tree94f873d304e708f224ca2215c08aa9677fc70f5c, independently read back by Git fetch.Verification and limits
10e6c0cb, while the latest full CI remains to be confirmed.The remaining efficiency acceptance and retrieval accuracy gap stay tracked in #255.