{info.description}
`. Every neighbouring action in `player-context-menu` uses the registered form; protect is the lone ad-hoc holdout. ### Assumptions - No caller outside the SPA and `test/teams.protect.spec.mjs` posts to `/protect`. Checked: `grep -rn "post_protect\|/protect"` over `.mjs`/`.js`/`.md` excluding `node_modules` and `dist`; `scripts/reset-protected-designation.mjs` writes the database directly and never calls the route. - The pause guard needs no per-route work. Checked: `api/routes/teams/index.mjs` mounts `require_league_not_paused` on `/:teamId` above every sub-router; `POST` is not in `SAFE_HTTP_METHODS` and `/protect` does not match `PAUSE_ROUTE_PATH`. - `roster.practice` includes `PSP` and `PSDP`, so the already-protected branch is live code. Checked behaviorally, not by reading: an existing passing spec seeds a player at `PSP` and asserts that exact error. - No cap exists on how many players may be protected, and protection is capacity-neutral. Checked: `practice_signed` spans `PS`+`PSP` and `practice_drafted` spans `PSD`+`PSDP`, `availablePracticeSpace` counts the former, drafted practice squad is explicitly unlimited, and no such column exists in `db/schema.postgres.sql`. - Nothing depends on one `PRACTICE_PROTECTED` row per request or on `occurred_at` ordering within a batch. Checked: `walk-transactions.mjs` keys its events on `(tid, pid)` so same-timestamp rows for different players cannot collide, and these events only decorate an already-open holding. - The client cannot import `libs-server`. Checked: `webpack/webpack.config.base.mjs` aliases only `@views`, `@pages`, `@core`, `@components`, `@styles`, `@layouts`, and no `#libs-server` specifier appears anywhere under `app/`. This is why the shared predicate must live in `libs-shared`. - `#libs-shared/` is precisely what the registered branch exists to avoid.
- `Protect Selected` uses `Button`'s existing `count` prop rather than string-building the number.
- `is_team_manager` must be threaded to both practice squad row sets; today it reaches active rows only.
### Notification
One `sendNotifications` call. Single-pid wording stays byte-identical to today. Multi-pid reads `Team Name (ABC) has designated 3 players as protected practice squad members: First Last (WR), First Last (RB), First Last (TE).` — the plural form applies at two or more, and names follow request-array order.
**The enumeration is capped by RENDERED LENGTH, not by player count.** Drafted practice squad is unlimited, `send-discord-message.mjs` has no length guard or chunking, and it returns `is_sent: false` on a refusal which `send-notifications.mjs` discards, so an over-long message fails invisibly. Build the enumerated string and fall back to a count-only form only above 1900 characters.
A count threshold was considered and rejected: Discord's limit is 2000 characters and a name entry runs about 28, so a twelve-player batch lands near 400 — a fifth of the ceiling. Any count cap low enough to feel safe fires on this feature's own headline case, the rookie draft class, and silently drops the enumeration for exactly the scenario the feature exists to serve.
No general name-formatting helper is introduced. Twenty-five inline `${first_name} ${last_name} (${primary_position})` builds exist across `api/` and `libs-server/`; a local `.map().join(', ')` inside the new module is right-sized. Note `format_player_name` is taken and is a matching normalizer, not a display formatter.
### Failure shape
All-or-nothing, with the 400 carrying `{ error: ' ` cannot do; and protect is the last ad-hoc holdout among its own neighbours.
- Changes:
- New component taking `{ player_maps }`, registered under `id: 'PROTECT'` in the switch.
- Context menu dispatches `protect_players({ pids: [pid] })` through the registered dialog.
- Verify: against a local `NODE_ENV=test` API on 8082 (not `dev:live`), the row menu confirmation renders one name and the toolbar confirmation renders every selected name.
- [x] **Add the opt-in checkbox to the roster row**
- File: `app/views/components/player-roster/player-roster.js`
- Purpose: per-row selection without affecting the active, reserve, waiver or cutlist tables that share this component.
- Changes:
- Render a leading checkbox cell only when `on_toggle_checked` is supplied, checked from `is_checked`. Named `is_checked`, not `is_selected`, because the component already destructures a differently-typed `selected`.
- Add a `PlayerRoster.propTypes` block — the file declares none today — covering both new props.
- Verify: `grep -n "propTypes" app/views/components/player-roster/player-roster.js` shows the new block, and against the local 8082 API the active roster and reserve tables render with no leading cell and no column misalignment. Do NOT cite `test/app.connected-component-props.spec.mjs` as the gate — its own header records that it deliberately rejects the general undeclared-prop assertion and narrows to spelling drift against connect mappers and to `Button` props, so ownProps from a parent JSX site pass it identically before and after.
- [x] **Add the header action slot to the players table**
- File: `app/views/components/dashboard-players-table/dashboard-players-table.js`
- Purpose: somewhere for the buttons, and an aligned leading header cell when rows carry a checkbox.
- Changes: one new prop `header_action` rendered in the dense `Toolbar` after `summary`; derive `show_selection` from it internally, mirroring `showReorder`; add the `propTypes` entry.
- Verify: against the local 8082 API, header and body cells align in both practice squad tables and are unchanged in every other table on the team page.
- [x] **Add the eligibility selector**
- File: `app/core/selectors.js`
- Purpose: `Protect All` and the `(N)` count need the eligible SET at the parent, which `getPlayerStatus` cannot provide from inside a `createSelector`.
- Changes:
- Add `get_protect_eligible_practice_squad_pids` returning the pids whose ineligibility reason is `null`, consuming the shared predicate.
- **Filter `processed` poaches.** `get_poaches_for_current_league` is the raw map and retains them, which is why `get_poach_players_for_current_league` deletes them by hand. Reading the raw map hides checkboxes for players the server would protect.
- Verify: a spec or console check seeding one poach with `processed` set and one without shows the processed player's pid present in the returned set and the unprocessed player's pid absent.
- [x] **Wire selection state and the buttons into the team page**
- Files: `app/views/components/league-team/league-team.js`, `app/views/components/league-team/index.js`
- Purpose: the feature surface.
- Changes:
- `index.js`: consume `get_protect_eligible_practice_squad_pids`, and add `protect_players` and the confirmation action to `map_dispatch_to_props`, which currently maps only `load_team_players` — without this neither button can fire.
- `league-team.js`: one `selected_pids` Set; each toolbar filters it to its own rows. Checkboxes render only when `is_team_manager && current_season.is_regular_season` and only on eligible rows.
- Thread `is_team_manager` to both practice squad row sets; it currently reaches active rows only.
- Signed table `header_action`: `Protect Selected`, using `Button`'s `count` prop, disabled at zero.
- Drafted table `header_action`: the same plus `Protect All`, hidden when nothing is eligible. Build its pid list from the full sorted drafted list, NOT the collapse-sliced display binding — a manager with the list collapsed still means every eligible drafted player.
- Clear selection by intersecting with currently-eligible pids on render.
- Declare every new prop in `propTypes`.
- Verify: against the local 8082 API, with the drafted list collapsed, `Protect All` protects players hidden by the collapse; the checkboxes do not appear when viewing another manager's team; and a failed batch leaves the selection intact rather than silently discarding it.
### Testing and Validation
- [x] **Add the multi-player happy path**
- File: `test/teams.protect.spec.mjs`
- Purpose: prove a batch spanning both practice squad slot types writes every row.
- Changes: protect one `PS` and one `PSD` player in one request; assert a two-element response, both slots moved, and two `PRACTICE_PROTECTED` rows read directly. Do not reach for `checkLastTransaction` — it reads a single newest row globally and cannot see a two-row batch.
- Verify: `yarn test:isolated --grep "protect"` passes.
- [x] **Add the validate-before-write ordering case**
- File: `test/teams.protect.spec.mjs`
- Purpose: prove no pid is written when any pid in the batch is invalid. Named for what it proves. A prior draft called this the rollback test and specified removing the `db.transaction` wrapper as its control, which cannot fire — with validation ahead of all writes, nothing is written either way and the check stays green in both states.
- Changes:
- Submit three pids with the invalid one **LAST**, assert 400 and that the body carries the failing `pid`, then re-read every one of the three via `getRoster` and assert each slot unchanged, and assert the team's `transactions` row count unchanged.
- Invalid-last is the discriminating permutation; invalid-first passes even under a write-as-you-go implementation, which is why the earlier draft's ordering proved nothing.
- **What this proves, stated narrowly:** the `getRoster` re-reads are wired and can fail. It does NOT prove a realistic write-as-you-go implementation would be caught, because a realistic one writes on `trx` and the rollback hides it. Do not let a later reader upgrade this claim.
- Verify: `yarn test:isolated --grep "protect"` passes; then prove the assertions can fail by temporarily issuing the first pid's slot update on bare `db(...)` **at the top of the module function, before any transaction is opened**, and confirming this case goes red while the happy paths stay green (the control is idempotent there — the real code writes the same slot value moments later). Restore afterwards.
- The bare-`db` and before-any-transaction wording are both load-bearing. Two earlier controls for this item were vacuous: removing the `db.transaction` wrapper (nothing is written either way under validate-before-write), and moving the update into the validation loop (it then runs on `trx` and rolls back). A bare `db(...)` issued anywhere inside `run(trx)` does not go red either — it queues for a second pooled connection while the first is held and HANGS, which reads as infrastructure flake rather than as a firing control.
- [x] **Add the transaction-participation case**
- File: `test/teams.protect.spec.mjs` or a sibling spec
- Purpose: this is the real control for the `db.transaction` wrapper, and it is the ONLY item that tests the thing the design most depends on — that every statement inside the module writes on `trx` rather than bare `db`. A statement written on bare `db` is not undone by an outer rollback.
- Changes:
- Open a transaction in the spec, call `submit_practice_squad_protection` with it as `provided_trx` for a valid multi-pid batch, then throw to abort it.
- Catch, then assert no slot moved via `getRoster` and no `PRACTICE_PROTECTED` row exists for those pids.
- Verify: `yarn test:isolated --grep "protect"` passes; then prove it discriminates by temporarily switching one inner statement from `trx(...)` to `db(...)` and confirming the case goes red or hangs. Either outcome is the control firing; restore afterwards.
- [x] **Add the batch-shape and pause error cases**
- File: `test/teams.protect.spec.mjs`
- Purpose: cover the new body contract and close a standing coverage gap.
- Changes:
- Missing `pids`, non-array, empty array, duplicate pids; rename the existing `missing pid` case.
- Assert the 400 body carries `pid` alongside the unchanged `error` string.
- One 423 case with the batch body against a paused league — no spec covers this route's pause behavior today.
- Keep and adapt the remaining existing cases.
- Verify: `yarn test:isolated --grep "protect"` passes with every listed case present.
- [x] **Unit-test the notification message builder**
- File: `test/teams.protect.spec.mjs` or a sibling spec
- Purpose: the wording cannot be observed anywhere but production, since `send-notifications.mjs` no-ops outside it.
- Changes: assert the one-player string is byte-identical to today's sentence, the three-player string matches the enumerated form, and that a twelve-player batch STILL enumerates every name — the headline rookie-draft-class case must not silently degrade.
- Separately assert the length fallback by building a batch whose rendered message exceeds 1900 characters, and confirm it produces the count-only form.
- Verify: `yarn test:isolated --grep "protect"` passes; the twelve-player assertion fails if a count-based cap is reintroduced, and the length assertion fails if the fallback is removed.
- [x] **Run the full gate set and commit atomically**
- Purpose: the contract break means server and bundle must not be separable in history.
- Changes: none — verification and commit.
- Verify: `yarn lint`, `yarn check:types`, `yarn check:test-collection`, `yarn check:cluster` and `yarn test:isolated` all pass; `git show --stat HEAD` shows route, module, client and specs in one commit.
- [x] **Deploy with the full path and note the window** — landed 2026-09-08. Production reached `437170259` with API and bundle in agreement; bulletin #734 resolved and #733 updated.
- Purpose: the API reloads before the bundle ships, so old bundles hit the new contract in between.
- Changes: none — a deploy step.
- Verify: host manifest, both host HEADs and the served `index.html` all named `437170259`; `Protect Selected`, `Protect All` and `Designate Protected` all present in the deployed chunks against a positive and a negative control; sourcemaps 404.
- The window was NOT the planned few minutes. A sibling ran a backend-only `yarn deploy` that moved both hosts to `437170259` while `dist/build-manifest` still named `0812a0a97`, so the new `{pids}` API served old `{pid}` bundles for roughly 25 minutes until this deploy's rsync closed it. Recorded on bulletin #733.
- [x] **Verify the client in a browser** — done 2026-09-08 against a seeded `NODE_ENV=test` API on 8082 with webpack-dev-server on a free port, never `dev:live`. All confirmed: both practice squad tables align header to body; every other table keeps its unchanged nine-cell shape; `Protect Selected` shows its count and is disabled at zero; `Protect All` appears only on the drafted table; `Protect All` with the list COLLAPSED to two visible rows opened the dialog naming all five and protected all five, including the three the collapse was hiding; the row menu `Designate Protected` opens the same registered `PROTECT` dialog with one name and singular copy; a batch rejected 400 left every player unprotected and the selection intact; checkboxes are absent on another manager's team.
- A player with a PROCESSED poach keeps his checkbox, and one with a PENDING poach does not. This is the behaviour with no unit test, since `app/core/selectors.js` is not importable from a spec, and the pending case is the control proving the processed case is not vacuous.
- Not covered: the out-of-season guard, which needs a clock this harness cannot move. `get_protect_eligible_practice_squad_pids` returns an empty set before anything else when `is_regular_season` is false, and the another-manager case measured here shows an empty eligible set does produce exactly the unchanged nine-cell table.
The browser verification found one real defect, fixed in `0be0549c8`: `PlayerRoster` gated the leading checkbox cell on `on_toggle_checked`, which is supplied only for an ELIGIBLE player, so an ineligible row omitted the cell and every column in it sat one checkbox-width left of the header. It is reached the moment a manager protects part of a practice squad. The fix is pushed and CI-green but undeployed, because `preflight:deploy` requires acknowledging twelve other sessions' commits — carried by [[███████████████████████-████████-█████-████████-█████████-██████]].
### Knowledge Base Updates
- [x] **File the follow-up task for the processed-poach defect in the row menu** — [[user:task/league/fix-processed-poach-hides-protect-menu-item.md]]. NOTE: the stated verify (`base relation forward ... --json`) is NOT a working oracle here — it reports `forward: 0` even for the pre-existing `relates [[user:repository/active/league]]` edge. The edge is confirmed in this entity's frontmatter instead.
- Purpose: `status.eligible.protect` reads the unfiltered poach map and over-restricts the context menu. It predates this work and is out of scope, but leaving it only in prose makes this task un-self-describing.
- Changes: create a task in `task/league/` for the fix and add a `relates` edge to it on this task.
- Verify: `base relation forward user:task/league/add-batch-practice-squad-protection.md --json` shows the new edge.