@propriety/court-calendar 1.0.171 → 1.0.173

package/.claude/skills/gen-test/SKILL.md

@@ -5,6 +5,23 @@ description: Generate Vitest + React Testing Library tests for a court-calendar
 
 Generate tests for the `@propriety/court-calendar` library targeting the file or subject passed as $ARGUMENTS.
 
+## The bar — read before writing a single test
+
+**More tests is not better.** A PR has been rejected in this codebase family for carrying too many
+machine-generated tests. Your job is the *fewest* tests that would actually catch a regression, not
+broad coverage of every prop permutation.
+
+- **If you cannot name the bug a test would catch, do not write it.**
+- Every test carries a comment saying **what failure it catches and why that failure is plausible** —
+  not a restatement of the assertion. A group of cases sharing one rationale carries it on the
+  `describe`.
+- Never write: a test asserting on the **text of a file** · a test of an internal helper when the
+  behaviour is reachable by rendering the component · a test restating its neighbour with different
+  props and the same failure mode · a test that a constant equals itself · a test written for coverage.
+- Do keep the negative case of any guard protecting a destructive action or a permission.
+
+Report how many tests you wrote and why each earns its place.
+
 ## Project Test Conventions
 - Test files live in `src/__tests__/` named `<subject>.test.ts(x)`
 - Shared fixtures: `src/__tests__/fixtures.ts` — read this first for reusable test data

package/CLAUDE.md

@@ -38,4 +38,10 @@ Context is at `src/context/ReferenceDataContext.tsx` and provides: `allUsers`, `
 
 - **Formatter/Linter**: Biome — not Prettier or ESLint
 - **Tests**: Vitest + @testing-library/react. Files: `src/__tests__/`, fixtures: `src/__tests__/fixtures.ts`
+- **Tests must earn their place**: more tests is not better — a PR has been rejected in this codebase
+  family for machine-generated test bloat. Cover the behaviour that changed with the fewest tests
+  that would catch a regression, and give each a comment saying what failure it catches and why that
+  failure is plausible. If you cannot name the bug, do not write the test. Never assert on the text
+  of a file, a private helper's internals, or a constant equalling itself. `/test-audit` applies this
+  retroactively.
 - **Pre-commit**: Husky runs on commit — run `npx biome format --write` before staging

package/README.md

@@ -480,7 +480,7 @@ Publishing is automated via GitHub Actions (`.github/workflows/publish.yml`).
 ## Known limitations
 
 - **Port 8000 only:** The backend API enforces CORS that only allows requests from `localhost:8000`. Applies to the dev server and any locally running consumer.
-- **Cache is not invalidated on external changes:** If another user modifies a court date, the change won't appear until the local cache expires (1 minute for dates, 2 minutes for cases).
+- **Cache is not invalidated on external changes:** If another user *modifies* a court date, the change won't appear until the local cache expires (1 minute for dates, 2 minutes for cases). A *deletion* does propagate: the poll drops any in-window date the server stops returning, and a save answered with 404 removes the row immediately — which matters because polling is suspended while a modal is open.
 - **No pagination for court dates:** `getAllDates` fetches every court date in a single request.
 - **Single API key:** No built-in token refresh or rotation.
 - **No error UI for API failures:** Network errors are logged to the console but not surfaced to the user (except for bootstrap errors, which show a brief snackbar).

package/dist/__tests__/hooks/UseCourtDatesDeletion.test.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Tests for how useCourtDates reconciles a date that no longer exists server-side.
+ *
+ * On 2026-08-24 court date 499 was deleted at 13:41. At 15:31 a user still saw it in the
+ * table view, clicked save on it twice, and got HTTP 404 both times. The calendar had polled
+ * for it about twenty-two times in between and every response correctly omitted the row.
+ *
+ * The reason it survived: the merge was a union — `[...fresh, ...prev.filter(notInFresh)]`.
+ * A deletion *is* an absence, so that expression cannot represent one; each poll re-added the
+ * row it had just been told about. The union was there for a reason (loadRange merges
+ * out-of-window months into the same array and a plain replacement would wipe them), which is
+ * why both directions are pinned here.
+ */
+export {};

package/dist/helpers/api/apiFailures.d.ts

@@ -1,20 +1,4 @@
-/**
- * A cross-cutting sink for API failures, so a request the server rejected always reaches the
- * screen instead of only the console.
- *
- * Every helper in this folder reports failure by returning `false`/`null` and writing a
- * `console.error` — which is why a delete the server refused looked identical to one that
- * worked. Rather than change each helper's signature (and every call site, and every
- * `.then(ok => …)` that depends on the boolean), each failing branch now *also* publishes an
- * `ApiFailure` here. `ApiFailureReporter` subscribes on mount and renders whatever arrives.
- *
- * A module-level bus rather than React context because these fire from plain async functions
- * that have no access to a provider — the same reason crash reporters are built this way.
- *
- * NOTE: nothing published here may contain the API key. The report is written to be pasted
- * into a chat or ticket, so it carries the request *shape* (method, URL, status, response
- * body) but never a credential.
- */
+import { DateType } from '../../types';
 export interface ApiFailure {
     /** What the user was trying to do, in their words: "Delete court date". */
     operation: string;
@@ -29,6 +13,15 @@ export interface ApiFailure {
     /** Raw response body (or the thrown error's message), truncated. For the tech team. */
     body?: string;
     at: Date;
+    /**
+     * Which record the request was about, in machine-readable form. `subject` is the same thing
+     * for a human to read; this is what lets a subscriber *act* on the failure — a 404 on a save
+     * means the row is gone server-side and should leave the screen.
+     */
+    record?: {
+        id: number;
+        dateType?: DateType;
+    };
 }
 type Listener = (failure: ApiFailure) => void;
 /** Subscribe to API failures. Returns an unsubscribe function suitable for a `useEffect`. */
@@ -36,7 +29,10 @@ export declare function onApiFailure(listener: Listener): () => void;
 /** Publish a failure to every subscriber. A throwing listener must not break the others. */
 export declare function publishApiFailure(failure: ApiFailure): void;
 /** Log and publish a non-2xx response. */
-export declare function reportHttpFailure(operation: string, method: string, url: string, res: Response, subject?: string): Promise<void>;
+export declare function reportHttpFailure(operation: string, method: string, url: string, res: Response, subject?: string, record?: {
+    id: number;
+    dateType?: DateType;
+}): Promise<void>;
 /**
  * Log and publish a request that never completed.
  *

package/dist/hooks/UseCourtDates.d.ts

@@ -8,7 +8,8 @@ import { CourtDate } from '../types';
  * restoring from cache.
  *
  * Optimistic updates are applied immediately to both React state and the cache;
- * chair-assignment changes are rolled back if the API call fails.
+ * chair-assignment changes are rolled back if the API call fails. A date the server
+ * reports as gone — absent from a refetch, or answering a save with 404 — is removed.
  *
  * @param apiKey               API key forwarded to court-date helpers.
  * @param activeUser           Current user ID, forwarded to `updateCourtDate`.