Files
Project-SDE-WP-Suite/docs/reference/baseline
Matt Mabrey b2a083ac7c T11.6: retire the per-browser Usage report (CR-019)
Removes the old "Usage logs" card from admin.html/admin.js (the
usage-admin panel + loadUsage(), D5/T7.10) now that T11.5's real,
server-side Activity & usage card exists and reads real per-user data
instead of per-browser localStorage.

wp-usage.js is deleted outright, along with its three <script> includes
(admin.html, wp-creation-index.html, work-package-suite.html) - it had
no reader left once the panel above it was removed (the "download the
full event log" button lived only in that panel), and per the original
CR-019 decision record it was never reliably tied to a real identity,
so it was never a candidate data source for the new report either.

Its two call sites (wp-creation-app.js, work-package-suite-app.js) keep
a local track() function as a documented no-op rather than having each
of their ~45 individual track('event', ...) call sites deleted one at a
time - that would be a much larger, riskier diff for the same outcome
(no data is recorded either way), and each call site still marks what
was worth recording if usage analytics are ever rebuilt server-side.
work-package-suite-app.js's dwell-timer plumbing (_stepEnter /
trackStepDwell), which only ever fed track(), was left in place for the
same reason: inert, not broken.

Also removes tests/usage_check.py, which tested exactly the retired
feature, and updates its line in docs/reference/file-map.md to point at
the 2026-09-17 decision record instead.

Verified:
  - grep across the whole repo for WPUsage / wp-usage.js / usage-admin /
    usage_check: no live references remain, only explanatory comments
    and planning docs (decisions-2026-09-17.md, wave-11.md) that
    describe the removal itself
  - node --check on all three touched .js files: no syntax errors
  - full backend smoke test (27/27) and seed_demo.py still pass
  - tests/baseline_shots.py --pages admin,creator,sop at 390px/1440px,
    run locally: all three pages render with no new JS errors (the one
    "beforeunload" log line on sop/creator at 1440px is pre-existing
    harness noise from wp-autosave.js's unsaved-work guard, unrelated
    to this change) and no horizontal overflow; refreshed baseline
    screenshots committed alongside this change
2026-09-23 14:46:32 -07:00
..

Baseline — August 14, 2026

Task: T0.2 · Branch: feat/wp-suite-r2-implementation · commit before wave 1

The before images every later PR compares against, and the record of which rendering defects were confirmed present at the start.

Screenshots

14 images, <page>-<width>.png, at 390px and 1440px. The plan says 12 (6 pages × 2); there are 7 pages, so there are 14 — see file-map.md D1.

Page 390px 1440px
login login-390.png login-1440.png
launcher launcher-390.png launcher-1440.png
SOP wizard sop-390.png sop-1440.png
creator creator-390.png creator-1440.png
admin admin-390.png admin-1440.png
field view field-390.png field-1440.png
directory/users users-390.png users-1440.png

Regenerate, or capture the "after" half of a comparison:

python tests/baseline_shots.py                                  # -> here
python tests/baseline_shots.py --out /tmp/after --label after

390px is captured with Chrome's mobile flag set, not as a narrow desktop window. Every page declares width=device-width, so this is the layout a field tablet actually gets. The script asserts the width it asked for is the width the page saw.

Two pages are not byte-stable — do not diff them blindly

Found at T1.5. Capturing twice with no code change at all produces different bytes for admin and users at both widths. login, launcher, sop, creator and field are stable. The console pages render live timestamps, so a byte comparison of them reports a change on every run.

A task whose done-when is "no layout change at 1440px" therefore cannot use a byte diff on those two. Run the capture twice before drawing any conclusion, or compare a page that is stable. Four of the "changes" in this document's own history were this, not code.

F1F6: all six reproduce

Measured in a browser by tests/f_items.py, not read from source. Re-run any time:

python tests/f_items.py            # all six
python tests/f_items.py F2 F5      # a subset, after one task

Each probe reports REPRODUCES, FIXED or INCONCLUSIVE — never a silent pass. The same script is the regression check for waves 13: an item is done when its probe flips to FIXED.

Item Verdict Measured Evidence
F1 REPRODUCES Picked "Job A" in the launcher picker: hero became Job A, app bar stayed Select a project, wp_active_project=projA, no reload. launcher-1440.png
F2 REPRODUCES Field view at 390px: Sign out occupies x 382432 against a 390px viewport — cut in half. Bar is 424px of content in 374px, ~3 rows tall. field-390.png, launcher-390.png
F3 REPRODUCES SOP header with the real long name: injected chrome paints over the logo by 106×32px at 1024px and 41×32px at 1440px; .header-left collapses to clientWidth 0. f-evidence/F3-sop-header-*-longname.png
F4 REPRODUCES Standalone creator: comments drawer overlaps the header by 380×91px once open. creator-1440.png
F5 REPRODUCES 5 of 5 enabled wizard inputs compute to rgb(244,244,244) fill with rgb(224,224,224) border — the #f4f4f4/#e0e0e0 the review named. sop-1440.png
F6 REPRODUCES Creator is 11 cards in a single 5,017px scroll, 0 sectioning controls, 3 jump links. Review said ~4,700px; it has grown. creator-1440.png

Notes that change how a fix gets verified

  • F1 is only visible if localStorage is not primed first. Setting both wp_active_project and wp_active_project_obj before load makes the two sources agree and hides the defect. The probe clears storage and drives the real picker.
  • F3 is only visible with a genuinely long project name, and it has to be long in the database — any page reached with ?project= re-pulls the project from the server and overwrites a name faked in localStorage. The probe seeds Micron EUV Cleanroom Enable 2667008 as a real project.
  • F3 cannot be measured by comparing .header-left to the chrome. Under the long name .header-left (flex:1; min-width:0) collapses to zero width, so that comparison reports a tidy zero gap while the chrome is painting across the logo. The probe measures against .logo, which is flex-shrink:0 and therefore the one box in the bar whose position means something. A fix that leaves .header-left collapsed has not fixed F3.
  • F5 must ignore genuinely disabled inputs, or the fix looks done while real fields stay grey. The probe counts only enabled, visible, non-hidden fields.

Horizontal overflow, measured at capture time

documentElement.scrollWidth against clientWidth. Recorded because four pages overflow at 390px and one also overflows at desk width, which no F item covers.

Page 390px viewport 1440px viewport
launcher 425px content
SOP wizard 429px content
creator 485px content 1551px content
field view 432px content
login, admin, users fits fits

The 1440px creator overflow is logged as BL-001. The 390px ones are F2 and its neighbourhood, resolved properly by B1 in wave 2.