feat(lists): add Queries + Parameters count columns to list tables

[SoundMindsAI]

Summary

Adds a count column to two list tables, surfacing at-a-glance metadata operators previously had to click into each row to see:

• /query-sets gains a Queries column (query_count) — how many queries are in each benchmark set.
• /templates gains a Parameters column (param_count) — how many declared params each template exposes, i.e. its tuning surface (0 = non-tunable; 6–8 = rich search space).

Both are additive int fields on the existing list-summary schemas. No migration, no new product surface.

Why two different implementations

• query_count counts child queries rows, so it uses a new batched GROUP BY aggregate (repo.count_queries_for_sets) — one query per page, NOT per-row. This is the same no-N+1 pattern repo.count_trials_for_studies established for the studies-list trial_count field (feat_studies_convergence_visibility, PR docs(research): complementary-architecture one-pager (three-layer handoff) #421). QuerySetSummary had previously omitted the count specifically "to avoid N+1 counts at list time"; the batched aggregate removes that objection.
• param_count is len(declared_params) — free, because declared_params is a JSONB column already loaded on the template row (not a child relationship). No extra query, no N+1.

A subtle bug caught by mypy during implementation: the aggregate column is labeled query_count, NOT count — SQLAlchemy Row objects are tuple-like and expose a built-in .count() method, so row.count would resolve to the bound method rather than the labeled column. Commented inline.

Generated artifacts + guides

• Regenerated ui/openapi.json + ui/src/lib/types.ts via scripts/regen-generated-artifacts.sh, so the frontend types pick up both new fields. The generated-artifacts-fresh CI gate (shipped PR infra(freshness-gate): CI gates for generated artifacts (copy-docs + openapi.json + types.ts) #433) validates the snapshot on this PR.
• Regenerated in-app walkthrough guides 03 (create_query_template) + 04 (create_query_set) against a populated stack — the list-view screenshots now show the new PARAMETERS (values 1–3 across 7 templates) and QUERIES (5 per set across 5 sets) columns with real data. Walkthrough .webm videos promoted to match.

Test coverage

Layer	File	Cases
Backend integration	backend/tests/integration/test_list_count_fields.py	5 (query_count: 3/0/per-set; param_count: 3/0 — real Postgres)
Backend contract	backend/tests/contract/test_list_count_fields_contract.py	2 (both fields integer + required in OpenAPI)
UI vitest	ui/src/__tests__/components/common/list-count-columns.test.tsx	7 (both columns: exists, value, zero, thousands-separator)

74 related existing backend tests + 1032 vitest still green; no exact-shape assertion broke.

Test plan

• New backend tests (7) pass against real Postgres in the one-shot container
• pnpm --dir ui test → 1032/1032; pnpm typecheck clean; pnpm build OK
• make lint && make typecheck clean; ruff format --check clean
• Freshness gate: canonical regen leaves git status clean (openapi.json + types.ts current)
• Guides 03 + 04 regenerated on a populated stack (screenshots show new columns)
• CI green (generated-artifacts-fresh + full suite)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces list-summary count fields to optimize performance and surface metrics at a glance. Specifically, it adds a query_count field to QuerySetSummary (resolved via a single batched GROUP BY query to avoid N+1 queries) and a param_count field to QueryTemplateSummary (derived from the already-loaded declared_params JSONB column). Corresponding columns ("Queries" and "Parameters") are added to the frontend tables, accompanied by comprehensive contract, integration, and frontend tests. A review comment suggests using a fallback default dictionary when calculating param_count to prevent a potential TypeError if declared_params is None.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

If row.declared_params is None (which can happen if the JSONB column contains a NULL value in legacy database rows), calling len() directly will raise a TypeError: object of type 'NoneType' has no len(). To prevent potential 500 Internal Server Errors on the list endpoint, it is safer to use a fallback default dictionary.

Suggested change

	param_count=len(row.declared_params),
	param_count=len(row.declared_params or {}),

[SoundMindsAI]

Review adjudication (Gemini Code Assist)

Gemini Code Assist (1 finding)

#	Sev	Location	Verdict	Notes
1	Medium	backend/app/api/v1/query_templates.py:116	Rejected	len(row.declared_params or {}) guards against a NULL declared_params — but that state is unreachable. The column is nullable=False in both the ORM model (backend/app/db/models/query_template.py:38 — mapped_column(JSONB, nullable=False)) and the creating migration (migrations/versions/0003_study_lifecycle_schema.py:56 — sa.Column("declared_params", JSONB(), nullable=False)), and no later migration relaxes it (the column appears in exactly one migration). Postgres rejects a NULL at insert time, so row.declared_params is None cannot occur for a persisted row. Adding or {} would be a defensive fallback against an impossible state (contra the Bug Fix Protocol's "don't add defensive fallbacks that mask the real problem") and inconsistent with the sibling NOT-NULL _summary fields (row.name, row.engine_type, row.version), all accessed without guards. If a future migration ever relaxes the constraint, that migration is the right place to revisit this — not a speculative guard now.

Outcomes

• Applied fixes (0): none
• Rejected with cited counter-evidence (1): finding docs: reorganize into numbered IA, add pipeline skills and feature templates #1 (unreachable NULL branch — declared_params NOT NULL in model + migration 0003)
• Deferred (0): none

All 17 CI checks green (including generated-artifacts-fresh, which validated the regenerated ui/openapi.json + ui/src/lib/types.ts). Ready for human review + merge.

[SoundMindsAI]

Final cross-model review (GPT-5.5) — adjudication

GPT-5.5 returned 2 findings, both rejected as false positives caused by the review input excluding the (large, bot-generated) ui/src/lib/types.ts from the diff for brevity:

#	Sev	Location	Verdict	Notes
1	High	query-sets-table.column-config.tsx:43	Rejected (false positive)	"column reads query_count but types.ts not updated." It IS updated — ui/src/lib/types.ts carries QuerySetSummary.query_count (committed in 1a817813, +23 lines). Proof: the CI frontend (… tsc …) job passed green, which is impossible if the field were missing (row.original.query_count would be a hard tsc error). generated-artifacts-fresh also green (types.ts matches the openapi.json snapshot). GPT-5.5 couldn't see types.ts because it was excluded from the diff input.
2	High	templates-table.column-config.tsx:59	Rejected (false positive)	Same cause + same counter-evidence for QueryTemplateSummary.param_count. tsc + generated-artifacts-fresh both green.

Outcomes (all reviews)

• Applied fixes (0)
• Rejected with cited counter-evidence (3): Gemini docs: reorganize into numbered IA, add pipeline skills and feature templates #1 (unreachable NULL guard — declared_params NOT NULL in model + migration 0003); GPT-5.5 docs: reorganize into numbered IA, add pipeline skills and feature templates #1 + docs: MVP1 architecture + 12 feature specs + GPT-5.5 review fixes #2 (types.ts excluded from the review diff; field present + tsc green).
• Deferred (0)

All 17 CI checks green. Ready for human review + merge.