# Ticket: Optimize SD Qualifier campaign detail large-ledger loading

Status: complete
Type: ticket
Updated: 2026-08-13
Next Action: none; monitor normal operator use for any campaign-detail regression
Parent: work/wp/active/wp-build-standalone-pi-sd-qualification-operator-application.md
Target: `jong@srv-rpi00.local:/home/jong/dev/sdq-independent-ab-20260813`
Work Route: `ts:work2` on the existing combined Pi work/production target

## Problem

Opening campaign `8c7a2b1a-7e67-48ac-8895-7999d76c4c2a` takes roughly
15 seconds in the operator browser. Direct production profiling reproduces
9.0–11.6 seconds inside Django before browser parsing, with 252 queries and an
11,788,650-byte HTML response.

The requested Overview is only 5.5 KiB, but the server also renders inactive
panels: Qualification is 4.25 MiB, Results is 6.47 MiB, and Activity is
0.89 MiB. The campaign contains 187 runs, 12,953 evidence rows (10,759 status
observations), 1,690 events, and 118 notifications. The view also issues 191
repeated authorization-envelope queries. Reported database execution is only
about 0.67 seconds; model hydration, template rendering, transfer, and browser
parsing dominate.

This path predates and is independent of the dashboard SSE route. Navigating
away from the dashboard closes its EventSource.

## Expected Behavior

Opening a campaign should render only the selected section and its shared
campaign summary. Large evidence, run-history, notification, and event sets
must be bounded and navigable without losing immutable records or changing any
operator authorization or action semantics.

Plan:

1. Select and prefetch only the relations needed by the requested campaign
   section.
2. Render only the active section instead of sending hidden inactive panels.
3. Paginate immutable evidence and audit events; bound the inline run-history
   summary while preserving access to the complete evidence set.
4. Eliminate per-run duplicate authorization-envelope queries.
5. Add regression and large-ledger performance-contract tests, build an exact
   ARM64 image, deploy only the web service, and verify the live first campaign
   through the Front Door on desktop and mobile.

## Acceptance Criteria

- [x] Overview, setup, qualification, results, and activity remain reachable
      through their existing links, and only the selected panel is rendered.
- [x] Overview preserves authoritative status, progress, supervisor warning,
      coordinator controls, closeout behavior, navigation, and no-JavaScript
      operation.
- [x] Results and activity expose bounded pages with stable ordering and links
      that retain `section=`; every immutable evidence record and audit event
      remains reachable.
- [x] Qualification shows bounded recent run history and evidence summaries;
      authorization state is computed without one query per run.
- [x] A representative large-ledger test prevents inactive history from being
      rendered on Overview and enforces bounded query/payload behavior.
- [x] The production campaign Overview is under 1 second server-side and under
      2 seconds through the authenticated browser, with a response under
      250 KiB.
- [x] Work2 deploys only the SD Qualifier web container; database, workers,
      controller infrastructure, firmware, media, and campaign state remain
      untouched, with the prior image retained for rollback.

## Verification

- Focused Django view, pagination, authorization, and query-count tests.
- Exact-image focused suite and production-shaped large-ledger benchmark.
- Authenticated Playwright navigation of every section, pagination, controls,
  desktop/mobile layout, console/network state, and first-campaign timing.
- Front Door health, image/source identity, unchanged non-web container IDs,
  and rollback-image verification.

Completed 2026-08-13:

- App commit `bc9da078b3216243de069961832b9ad0e98ca9e4` adds section-scoped
  loading, 20-run qualification pages, 100-row evidence and audit pages, and
  large-ledger performance/query contracts.
- The final exact ARM64 image passed 62 affected Django tests in 74.487 seconds.
- Production-shaped Django profiling measured Overview at 0.610 seconds and
  12,031 bytes with 18 queries; qualification, results, and activity were
  0.743, 0.722, and 0.690 seconds respectively.
- Authenticated Front Door verification opened the first campaign in 0.847
  seconds wall time (0.775 seconds to response) with a 12,055-byte body.
  Setup, qualification, results, and activity loaded in 0.738, 1.343, 0.786,
  and 0.894 seconds. Pagination reported 10 run pages, 130 evidence pages, and
  17 audit pages. Desktop and 412-pixel mobile checks had no horizontal
  overflow.
- Deployed release `campaign-detail-performance-bc9da07` to web only. Post-deploy
  image/source identity and health passed, all five non-web container IDs were
  unchanged, and the prior `dashboard-sse-9fdf910` image/override remains the
  rollback path. No application exception or HTTP 500 appeared in web logs.
