[WebTigers]

Found by the paradigm scanner in PR #364. The updates history was the one admin grid not following the client/server contract — the controller handed the view recent(15) and the view looped it into <tr> rows, where WEBSERVICES.md §5 says list/table data is fetched from /api.

There was a real gap behind the consistency argument

Dev has 24 history rows. The screen could only ever show 15. Nine update runs existed that nobody could reach — no paging, no search, no way to ask "what happened last month?". The paradigm violation was the symptom; this was the damage.

Converted to the house pattern, not a variant

Followed Cms_Service_Page::datatable and the Access user grid:

Piece	Does
Tiger_Model_UpdateHistory::datatable()	owns the query — search, sort, paging, both counts
System_Service_Updates::datatable()	_dtParams() → finder → _dtResponse()
System_UpdatesController	renders the shell, sets useDataTables
the view	an empty <table>; init lives in the module's JS asset

A service never builds a predicate (AGENTS.md), so the finder is named and on the model. Rows are structured data only, never HTML — there's an assertion for that. This screen already loaded an external JS asset, so the grid init went there rather than adding an inline <script>.

The per-run step log became a DataTables child row, which is how DT expresses "detail under this row" — the old sibling <tr class="collapse"> has no equivalent. The log travels with the row payload, so expanding costs no second round trip.

history() is kept, and now says why

It was previously unwired from any UI. It survives because it's the plain read an API/MCP caller wants without DataTables semantics, and history is a READ_VERB — so a read-only token can reach it. The admin grid uses datatable().

Tests

Three service tests — the DataTables envelope with structured-rows-only (asserting no markup is built server-side), search narrowing recordsFiltered without moving the total, and a plain admin being denied — plus a new controller test.

The controller test asserts useDataTables, and that one earns its keep: without the flag the assets never load, the grid renders empty, and the page's JS dies after the failed init — silently, behind a 200, with nothing a casual look would catch. Mutation-checked: removing the flag fails it. A second test guards against a history view-var reappearing.

Verified in a browser

Signed in on tiger-dev as a superadmin: all 24 rows reachable and sortable, the child-row log expands with the full step list, 0 console errors.

And the scanner that filed this ticket now reports rendered_rows = 0.

Full unit suite green (1195 tests).

🤖 Generated with Claude Code

https://claude.ai/code/session_013vdyTeoDrGE4hKxt53TsE8