Running the full suite at master 55900e2d with deploy/ as the web root — exactly as
deploy/dev/tests/playwright.config.js serves it — the single largest cause of failure is
requests for fixture databases the repository does not contain.
deploy/buildings/Duplex_extracted.db does not exist, and 112 failing requests want it.
The suite's /buildings/* URLs resolve to deploy/buildings/, which ships Duplex_library.db
but no Duplex extract (verified via the GitHub contents API at 55900e2d, and still true at
current master 5b48490, 2026-09-08). Full-suite result at 55900e2d, workers=1:
196 failed / 269 passed / 11 skipped, with this one file accounting for more failures than
any other cause.
Two more of the same kind: boq_charts.html and the 23-rate-templates/05-charts specs
fetch buildings/Duplex_meta.db (absent everywhere in the repo — 7 failures render as
"No data."), and the viewer requests SampleHouse_meta.db (also absent; Hospital_meta.db
ships as a 0-byte file).
The two fixture sets diverge, which makes several specs unpassable from either side.
deploy/buildings/ (13 models incl. SampleHouse_library.db) and deploy/dev/buildings/
(9 models incl. Duplex_extracted.db) each contain files the other lacks, while specs split
between /buildings/… and /dev/buildings/… URLs. A spec whose fixture is in the other
set fails as a 404 that reads like an app defect.
Suggested fix: add the Duplex extract (or point those URLs at dev/buildings/), add or
remove the two _meta.db references, and consider unifying the two buildings/ directories —
one canonical fixture set would eliminate this class of failure outright.
For what it's worth: after tracing every failure cluster individually, we found at most one
plausible behavioural defect in the app itself at this SHA — nearly everything red traces to
missing inputs like these, external dependencies, or stale selectors. The app is in much
better shape than its suite makes it look.
Running the full suite at master
55900e2dwithdeploy/as the web root — exactly asdeploy/dev/tests/playwright.config.jsserves it — the single largest cause of failure isrequests for fixture databases the repository does not contain.
deploy/buildings/Duplex_extracted.dbdoes not exist, and 112 failing requests want it.The suite's
/buildings/*URLs resolve todeploy/buildings/, which shipsDuplex_library.dbbut no Duplex extract (verified via the GitHub contents API at
55900e2d, and still true atcurrent master
5b48490, 2026-09-08). Full-suite result at55900e2d, workers=1:196 failed / 269 passed / 11 skipped, with this one file accounting for more failures than
any other cause.
Two more of the same kind:
boq_charts.htmland the23-rate-templates/05-chartsspecsfetch
buildings/Duplex_meta.db(absent everywhere in the repo — 7 failures render as"No data."), and the viewer requests
SampleHouse_meta.db(also absent;Hospital_meta.dbships as a 0-byte file).
The two fixture sets diverge, which makes several specs unpassable from either side.
deploy/buildings/(13 models incl.SampleHouse_library.db) anddeploy/dev/buildings/(9 models incl.
Duplex_extracted.db) each contain files the other lacks, while specs splitbetween
/buildings/…and/dev/buildings/…URLs. A spec whose fixture is in the otherset fails as a 404 that reads like an app defect.
Suggested fix: add the Duplex extract (or point those URLs at
dev/buildings/), add orremove the two
_meta.dbreferences, and consider unifying the twobuildings/directories —one canonical fixture set would eliminate this class of failure outright.
For what it's worth: after tracing every failure cluster individually, we found at most one
plausible behavioural defect in the app itself at this SHA — nearly everything red traces to
missing inputs like these, external dependencies, or stale selectors. The app is in much
better shape than its suite makes it look.