Repository navigation
chore(diagnostics): delete the dated reasoning fidelity and continuation-repair diagnostics - #238
Merged
Merged
Conversation
Owner decision of 2026-10-04, like the live recovery diagnostic deleted with #235. The diagnostic was the fork side of one sealed study (run reasoning-fidelity-20260907): four test files of internal/service under the reasoning_fidelity build tag (the live test, the control test, the response parser with its fixtures, and the support file with the frozen gateway helper). No CI step compiled them since #235 removed the only command that built with that tag. Nothing outside the four files used what they declared, every production function they called has other callers, and no file carries the build tag now. The continuation-repair live test keeps its refusal to start while SUB2API_REASONING_FIDELITY_LIVE is set; it belongs to a sealed study of its own and is not changed. .downstream/upstream-review-v0.2.13.md says what was deleted and when, and states that the vet run and the two offline tests that covered only those files went with them. The history documents of earlier versions and the pinned upstream-risk.json still list the four paths. Checked: go build ./..., go vet -tags unit ./internal/service, test_upstream_automation_contract.py (16 tests), git diff --check, and a search of the tree for the build tag and the deleted names. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…gnostic The entry for the deleted reasoning fidelity diagnostic dated the deletion "after v0.2.13-codexrip.1, whose tree still holds it". That names the wrong boundary. v0.2.13-codexrip.2 (bc67df3, the commit this branch is cut from) and v0.2.13-codexrip.3 (c29da30, main since #237) hold the four files as well, so a reader would take .2 for the first release without them. The sentence now names the three releases whose trees hold the diagnostic and gives the boundary by the merge instead of by a release number: the first release tagged after this change merged is the first without it. That stays true if another release is tagged before the merge. Checked: git ls-tree of the three tags (four files each), git ls-remote for the tags and main, git diff --check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…g-fidelity-diagnostic
…g-fidelity-diagnostic
…c without a list Releases keep being tagged while this change waits; the sentence no longer enumerates them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner decision of 2026-10-04, like the reasoning fidelity diagnostic this branch already deletes. The diagnostic was the fork side of one sealed study (run responses-continuation-repair-20260909, in two rounds): two test files of internal/handler under the continuation_repair_live build tag, namely the live test with its three offline tests and the support file with the fixture that built the OpenAI gateway handler with its gateway and Ops services over in-memory stores from a frozen snapshot. No CI step ever built with that tag. Nothing outside the two files used what they declared, every production function they called has other callers, and no file carries the build tag now, so no production code changes. The live test was also the last code that named an environment switch of the dated studies: besides its own, it refused to start while the switch of the fidelity study or of the namespace round-trip study was set. The fork side of that study had left the tree with #206. .downstream/upstream-review-v0.2.13.md: the fidelity entry no longer says that the continuation-repair live test keeps its refusal, a new entry says what this change deletes and what stays (the Ops continuation diagnostic and the ordinary unit tests), and the note on the pinned upstream-risk.json counts the two paths. The history documents of earlier versions and upstream-risk.json still list them. Checked: go build -p 2 ./..., go vet -p 2 -tags unit ./internal/handler, test_upstream_automation_contract.py (16 tests), git diff --check, and a search of the tree for the build tag, the deleted names and the environment switches. No test was run: the two files were the only ones compiled under the tag. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HTExplicit
changed the title
…g-fidelity-diagnostic
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deletes the last dated one-shot diagnostics from the repository, on the owner's decisions of 2026-10-04. The reasoning replay/recovery diagnostic went with #235.
What is removed
reasoning-fidelity-20260907):backend/internal/service/reasoning_fidelity_control_test.go,reasoning_fidelity_live_test.go,reasoning_fidelity_parse_test.goandreasoning_fidelity_support_test.go(2,124 lines, build tagreasoning_fidelity).responses-continuation-repair-20260909, two rounds):backend/internal/handler/continuation_repair_live_test.goandcontinuation_repair_live_support_test.go(1,953 lines, build tagcontinuation_repair_live).Nothing else used them: no other file carries either tag, no workflow, script or Makefile list names them, and every production function they called has other callers, so no production code changed.
.downstream/upstream-review-v0.2.13.mdrecords both deletions. The ordinary unit testsopenai_compat_reasoning_fidelity_test.goandopenai_namespace_roundtrip_test.goonly share words with the studies and are untouched.Not a release
Test-only files under build tags that no build uses; there is no runtime change, so no image is built for this.
Verification
go build ./...,go vet -tags unit ./internal/serviceandgo vet -tags unit ./internal/handlerpass on the tree without the six files..github/scripts/test_upstream_automation_contract.pypasses.Not run locally: any Go test (the only tests this touches are the deleted ones), other vet tags, frontend checks.
🤖 Generated with Claude Code