diff-integrity.json

{
  "maxRemovedFraction": 0.25,
  "minRemovedCases": 3,
  "perFileMaxRemovedFraction": 0.5,
  "perFileMinRemovedCases": 3,
  "approvedReductions": [
    {
      "path": "tests/ward-pull-vocabulary.dom.test.tsx",
      "before": 16,
      "after": 15,
      "reason": "Deliberate retirement of the one case rendering <WardModeWorkspace mode=\"exceptions\" />, a mode MERGE 01 turned into a redirect. Its two halves went different ways and both were checked before the case was dropped. The vocabulary rule itself (\"Bed pull expired\", never \"Bed hold expired\") was carried onto the live DelaysScreen in 43c56d6c5, with a control proving the mutation fails that one test by name; re-asserting it here would be a second copy of a live pin. The other half asserted the action label \"Reconfirm or release bed pull\", and DelaysScreen offers no per-item action at all by design - its own footer reads \"Nothing on this screen decides anything\" - so there is no control whose wording could be wrong, and pinning the absence of one would fight the next redesign. Whether that lost capability should return is an owner question, flagged to Ward Lead rather than settled by choosing an assertion. NOTE: 1 case of 16 is below this file's own perFileMinRemovedCases floor of 3, so check:diff-integrity would never have demanded this entry - it is recorded because a retirement that leaves no trace is indistinguishable from a deletion nobody noticed, which is the failure this array exists to prevent.",
      "approvedOn": "2026-09-05"
    },
    {
      "path": "tests/ward-capacity-view.dom.test.tsx",
      "before": 7,
      "after": 4,
      "reason": "7 -> 4 as the gate measures it against the merge base; 13 -> 4 across the whole programme, which is the history the rest of this reason tells. NOTE: the previous version of this entry said before=13, and isApproved() matches on EXACT before AND after - so it matched nothing and the gate was passing on the per-file threshold (3 of 7 removed = 0.43, under the 0.5 ceiling) while appearing to be approved. Corrected 2026-09-06 after reading the gate rather than trusting its OK line. AND THE CORRECTION DOES NOT MAKE THIS ENTRY LOAD-BEARING - measured, not assumed: with the entry deliberately mismatched (after=99) and the ceiling untouched, check:diff-integrity prints the same 'OK  7 -> 4' and the same PASS. At 3 removed of 7 the reduction is under the per-file ceiling, so the gate never demands an approval here at all. This entry is a RECORD, exactly as the ward-pull-vocabulary entry above says of itself - a retirement that leaves no trace is indistinguishable from a deletion nobody noticed, which is the failure this array exists to prevent. The numbers are made exact so that it WOULD carry the file if the ceiling were ever crossed, and so no reader is told this was gate-approved when it was merely under threshold. 13 -> 5, across three commits on 2026-09-05 and 2026-09-06. Every retirement was justified by a mutation or by an owner ruling, never by the subject having merely moved. RETIRED, subject moved to ward-screen.tsx at /ward/[unitId] and proved guarded there by mutation: the Confirmed/Expected breakdown replacing the old Potential lump (Confirmed chip reading the Expected field turns 3 ward-screen cases red); the reconciliation identity and its floor (Held chip pointed at capacity.blocked turns 2 red) - note this narrows coverage, since the retired case looped every unit on one board while WardScreen is one ward per route over five rendered units, accepted because no board can check them all at once any more; and a leave bed never folded into Ready plus its fixture assumption (Ready as available+leaveUsable turns 2 red, and the one usable leave bed is on a rendered unit so the mutation was live not inert). RETIRED because the property is now obeyed and guarded on the live capacity screen: the two zero-as-words cases, since capacity-screen.tsx renders a zero ready count as the word and ward-capacity-screen.dom.test.tsx asserts that claim for every row including both directions on the absence. RETIRED ON THE OWNER'S OWN RULING: the six-figure headline that never shows a sum - he was given the recommendation to leave the strip out and took it; the guard protected a structure that no longer exists, and its reasoning is preserved in the file for whoever ever brings a summary strip back. RE-POINTED rather than retired: 'a expected release must never soften Available now' moved to ward-bed-release.dom.test.tsx, and it was a live hole - rendering Ready as available minus expectedToday left 714 tests green across all 41 files that could catch it while two rendered wards genuinely changed from Ready 2 to Ready 1. The five that remain are four live cases against CapacityScreen (Mental Health Act authorisation on the network view, the coordinator's capacity-refresh control, the excluded-beyond-horizon count, and the split fixture assumption) and ONE STILL POINTED AT THE DEAD MODE ON PURPOSE, so the reachability guard keeps reporting this file: a ward's sex mix and specialling headroom as FIGURES on a network view. The sex-mix SIGNAL is built and guarded separately - the screen now says a ward's records are mid-update when its recorded total and occupancy disagree - but whether the underlying figures belong on a network view is a question the owner has not been asked, and building it would answer it on his behalf. Source hashes d86f1549 (ward-screen.tsx), 9e27492d and 83d3160e (capacity-derivations.ts) and 3e379533 (capacity-screen.tsx) before and after the mutations cited. NOTE ON THE PAIR: 13 -> 5 is the CUMULATIVE reduction across three commits, which is what a reviewer needs to see; any single diff the gate computes matches neither end, and all three steps are under the 50% per-file ceiling so it consults no approval at all. This entry is a record, not a gate condition. RETIRED 2026-09-06, the LAST case in the repository rendering a dead WardModeWorkspace mode: \"shows sex mix and specialling capacity per unit row - both directions\". Two things justify it and neither is that the guard was inconvenient. (1) The sex-mix half stopped being an open question: Ward Lead ruled this screen carries the sex-mix SIGNAL and never the FIGURE - RELEASE_BED raises occupancy without being able to say which sex left, so the honest statement is \"this ward's bed records are mid-update\" - and that ruling is BUILT at b98103167 with ward-capacity-sexmix-release.dom.test.tsx guarding the OPPOSITE of what this case demanded, that no sex-mix figure reaches the screen. A case cannot be re-pointed into a screen a ruling has just cleared. (2) Both underlying clinical properties were proved guarded by MUTATION rather than by grep, because a file list containing the word is not evidence: disabling the specialling gate in ward-flow-reducer.ts (if (false && movement.specialling && ...)) turns 5 cases red across 4 files, among them \"refuses the second one-to-one pull, and names specialling rather than 'no bed'\", source hash cf9a0868 identical either side; blinding the sex-mix occupancy in ward-eligibility.ts (sameSexOccupants = 0) turns a long list red across the eligibility and reducer suites, source hash 10a42eda identical either side. The reachability guard itself was then proved still able to fail: reintroducing a dead-mode render turns it red naming exactly that entry, source hash 000ab6ec identical either side. WHAT THIS COSTS, STATED RATHER THAN GLOSSED: a red case forces a question to be answered and a JSON entry does not. Whether a coordinator should see specialling headroom as a NETWORK FIGURE is still an open product question nobody has ruled on, and retiring this removes the thing that kept asking it. It is recorded here, in the test file's retirement note, and in the message that carried it to Ward Lead - three places, because the guard that used to ask is gone. Retired anyway because a permanently red gate is the worse hazard: it stood over a screen no coordinator can open, so it protected nothing, and a gate everybody knows is red is a gate nobody reads when it goes red for a new reason.",
      "approvedOn": "2026-09-06"
    },
    {
      "path": "tests/sources-mode.dom.test.tsx",
      "before": 28,
      "after": 24,
      "reason": "The four `Sources home` cases rendered SourcesHomeClient, the component this change deletes: /sources joined consolidatedModeHomePaths, so its bare path now forwards to the shared home at /?mode=sources instead of rendering a four-card home of its own. Coverage was RE-POINTED, not dropped, and each of the four was checked to a live pin before it was removed. (1) The hero-copy case asserted the title and subtitle, which came from sharedHomePresentation.sources and are asserted against that same source by tests/shared-home-empty-state.dom.test.tsx and tests/ui-copy.test.ts; the shared home renders them for Sources through the identical lookup. (2) The composer-slot case is obsolete rather than moved: it existed because /sources was registered in standaloneModeHomePaths with a hero placement while rendering the catalogue, which mounts no slot, so the shell portalled its search field at a host that did not exist. This change removes /sources from that list, so no hero slot is claimed at that path and there is nothing left to assert. (3) The four-destination case is pinned better than it was: the same four hrefs are the Sources entry of modeSecondaryNavigationRegistry, walked by tests/route-reachability.test.ts's builderTargets and by the mode-nav contract, so they are now proved reachable from the registry that actually renders them rather than from a card list that duplicated it. (4) The suggested-search case moved into the retargeted /sources describe in tests/consolidated-mode-home-redirect.test.ts, which asserts appModeHomeHref('sources', {query, run}) resolves to /sources/search and that the bare path never renders. The user-visible route into the catalogue that the cards used to provide is now the shared home's ShowAllChip, pinned by a new case in tests/ui-sources.spec.ts. NOTE: 4 of 28 is 14%, well under this file's 50% per-file ceiling and the 25% aggregate, so check:diff-integrity would never have demanded this entry \u2014 measured, not assumed: the gate prints `OK  tests/sources-mode.dom.test.tsx  28 -> 24` and PASS with or without it. It is a record, on the convention the two entries above set for themselves: a retirement that leaves no trace is indistinguishable from a deletion nobody noticed, which is the failure this array exists to prevent. The numbers are exact so it would carry the file if the ceiling were ever crossed, and so no reader is told this was gate-approved when it was merely under threshold.",
      "approvedOn": "2026-09-06"
    },
    {
      "path": "tests/document-cover-route.test.ts",
      "before": 6,
      "after": 0,
      "reason": "Deliberate retirement of /api/documents/[id]/cover test suite under #HDAP8N. The answer source drawer stopped rendering a front-page thumbnail, leaving useDocumentCoverImageId and this route without product consumers. Both the route and client hook were pruned along with this test suite.",
      "approvedOn": "2026-09-06"
    },
    {
      "path": "tests/use-document-cover.dom.test.tsx",
      "before": 9,
      "after": 0,
      "reason": "Deliberate retirement of useDocumentCoverImageId hook test suite under #HDAP8N. The answer source drawer stopped rendering a front-page thumbnail, leaving useDocumentCoverImageId without product consumers. Hook, route, and DOM tests were retired together.",
      "approvedOn": "2026-09-06"
    },
    {
      "path": "tests/ui-ward-morning.spec.ts",
      "before": 2,
      "after": 1,
      "reason": "MERGE 02 (owner-approved 2026-09-05) folded the morning bed-state board into CapacityScreen and turned /mockups/ward-flow/morning into a real HTTP redirect to /capacity, removing the rail's 'Morning bed state' entry at the same time. RETARGETED, not dropped: the render-and-rail test now proves the redirect lands on the real Capacity page and that the rail can leave and return to it, in place of a headline and a link label that no longer exist. RETIRED: the print test, because CapacityScreen carries no print media rule and no per-site print testid at all - capacity.module.css has none - so there is no real print output left to assert against; inventing print assertions for a screen that renders none would fabricate coverage rather than describe it. The underlying MorningPage component and its print CSS are not left unguarded: tests/ward-morning-page.dom.test.tsx still renders MorningPage directly (not via a route) and covers its print label/note and per-site figure grids at the component level (named in morning-page.tsx's own doc comment as still passing all 20 cases), and tests/ward-morning-print.test.ts still guards the CSS text. Only the real-Chromium, real-PDF-page-count proof this browser test gave (page.pdf() measured with pdf-parse) is lost, because no route can mount the component that behaviour belongs to any more. NOTE: 1 of 2 is exactly this file's own perFileMaxRemovedFraction ceiling of 0.5, and the file's case count is below its perFileMinRemovedCases floor of 3, so check:diff-integrity would never have demanded this entry on the per-file rule either - it is recorded on the same convention the entries above set for themselves: a retirement that leaves no trace is indistinguishable from a deletion nobody noticed.",
      "approvedOn": "2026-09-06"
    }
  ]
}