Repository navigation
docs: sample report demonstrates the #215 fix (13 of 13), drops the stale limitation - #233
Conversation
Replaces the stale 'known defect, tracked as #215' limitation, which #220 made untrue, with a check: re-upload the T&E file, where every row now collides, and require status error, an unchanged registry record and an unchanged table. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011T6Wqm1jLdq3ZEfuKdp9aM
…f 13) Re-run on a fresh PostgreSQL 16 database at code version f25c94f. The report no longer lists the #215 re-upload defect as a known limitation, since #220 fixed it; check 13 now demonstrates the fix. Run against the pre-#220 loader, check 13 fails with the #215 symptom (registry 6 loaded / 4 failed replaced by 0 / 10, status ok), and the audit check fails too (3 entries for 2 loads). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011T6Wqm1jLdq3ZEfuKdp9aM
|
CI: Not this PR's. This PR changes only A fix already exists: #231 (+3 lines, CI green, mergeable) and #232 (+4 lines, still running) are two competing drafts of the same one-file change to Generated by Claude Code |
main merged #224, #233 and others after the previous merge and regenerated docs/TEST_CASES.md, which conflicts with this branch's regeneration. The file is generated and CI gates on it (`test_catalogue.py --check`), so it is regenerated, not merged by hand. It is the only conflict. Verified on the merged tree: this branch's 16 runtime-role tests pass; free tier 290 passed, 0 failed, 0 skipped; lint, health and the catalogue check clean. The rest of main's tests are covered by main's own CI. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011T6WqjTEDRRQGLEYPPFVXx
What
The sample Migration Verification Report (merged in #216) listed the T&E re-upload defect (#215) as a known limitation. #220 fixed that, so the line was untrue for current
main. This replaces the limitation with a check that demonstrates the fix, and regenerates the report at a clean code version.Refs #59 (stays open: whether the sample meets "a Defence buyer could review it" is the product owner's call).
Changes
scripts/sample_verification_run.py: new check 13. Re-upload the T&E file, where every row now collides on the unique name, and require statuserror, an unchanged registry record (same id, 6 loaded, 4 failed) and an unchanged table (6 rows). Check numbering 1-12 is unchanged. Check 11 (audit) now also states that fully failed uploads leave no audit entry.docs/samples/*: regenerated from a real run on a fresh PostgreSQL 16 database at code versionf25c94f(clean working tree). 13 of 13 pass.The new check can fail (tested)
I temporarily reverse-applied #220's change to
api/services/te_loader.pyand re-ran on a fresh database. On the pre-fix loader:status ok, registry[3, 0, 10]vs original[1, 6, 4], table still 6 rows (the #215 symptom)The script exited 1. The loader change was reverted before committing; this PR does not touch
api/.Not run
CI (draft PR until checks report). No tests changed, so the test catalogue is unaffected.
Generated by Claude Code