Report what the purge will do, and re-run the acceptance suites - #217
Merged
Conversation
The report ran on production and printed `alerts_retracted=0`. Applying it a minute later retracted six. The count was only ever taken while deleting, so `report` — whose whole job is to say what `=1` will do — reported zero however many alerts the store held. Counted in both modes now, as `alerts_to_retract`, and the log line says `alerts=N` either way. The connections list also says `none` rather than trailing off into nothing when there is nothing to remove. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Emptying production put it in the state every deployment starts in and the one nobody had ever run: a corpus with nothing in it. Discovery answers, the index over nothing still reads current, and the answer is "your thought stays in the search" rather than anything that reads as a failure. Measured, then pinned. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The readiness doc's local origin used `--db :memory:`, which the PostgreSQL-only factory now refuses outright — the first command anyone following that section would type. It said 682 tests where there are 712, and did not say that `:ephemeral:` needs a PostgreSQL server reachable, which is the thing that actually stops a newcomer. All three acceptance suites re-run on current main against a local guest-enabled origin, each matching its recorded baseline: oauth_smoke 27/27, onboarding probe 9/9 required (17/17 total), A/B/C 36/36 — including A ranking above C, the subject-bound result_id, intro to relay, and a revoked bearer refused on /mcp. The frozen evidence copy of the A/B/C harness is untouched; the run used a copy with `authorship` added, exactly as that section prescribes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Parshkov
changed the title
docs/STATUS.md said leftover acceptance rows were listed for owner deletion and 'not deleted by an agent'. An agent did delete them, on the owner's instruction, so the line is marked superseded with what was removed, what was kept, and the backup that should have been taken and was not. GitHub sign-in was configured on production today. Verified as far as it can be without a human at the consent screen: both providers offered, 302 to GitHub's authorize endpoint with the exact registered callback and read:user user:email, and GitHub answering with its own sign-in page rather than the redirect_uri or client-credentials error a misconfigured OAuth App produces. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Three things, all found by running what was shipped rather than by reading it.
1. The report lied by omission
RESONANCE_PURGE_CORPUS=reportprinted on production:Applying it a minute later retracted six. The count was only taken on the deleting branch, so
report— whose entire job is to say what=1will do — reported zero however many alerts the store held.Counted in both modes now (
alerts_to_retract); the log line saysalerts=Neither way, and the connections list printsnonerather than trailing off into whitespace.2. Nobody had run the product on an empty corpus
Emptying production put it in the state every deployment starts in — and the one never exercised. Measured: discovery answers, an index over nothing still reads
index_current, and the answer is "Nobody yet. Your thought stays in the search, and everyone who arrives later is compared with it." — not an error and not something that reads as failure. Pinned byTheFirstPersonInAnEmptyWorldTests.3. The readiness doc no longer ran
ops/TEST_READINESS.mdtold you to start the local origin with--db :memory:, which the PostgreSQL-only factory refuses outright — the first command anyone following that section would type. It claimed 682 tests where there are 712, and never said that:ephemeral:needs a reachable PostgreSQL server, which is the thing that actually stops a newcomer. Fixed, with the container invocation spelled out.Evidence
All three acceptance suites re-run on this branch against a local guest-enabled origin, each matching its recorded baseline (last taken at
85eeaba):ops/oauth_smoke.py … --auto-consentops/hosted_onboarding_probe.py --smoke --refresh --revoke/mcpInside the A/B/C run, the product's actual claims:
A ranks above C(rank 0 vs rank 14 — structure beating shared vocabulary), a subject-boundresult_idC cannot read, intro → accept → relay, a revoked thought gone from a fresh discovery immediately, and a revoked bearer refused on/mcp.The frozen evidence copy of the A/B/C harness is untouched — the run used a copy with
authorshipadded, exactly as that section prescribes.Checklist
benchmark/gold is unedited.:memory:command, and the acceptance figures.🤖 Generated with Claude Code