QA run · re-verify the 2026-08-18 FAILs on 17.1.0 · 6/6 fixed · 19f98fa1 · 2026-08-20

[os-elon]

A post-release regression re-verification, not a new sweep. Every fail recorded by the 2026-08-18 browser wave (#9453 Tier-2B, #9467 Tier-2C, subject e4e5c6e3) was re-driven against the released 17.1.0 build. All six are fixed. No fail found.

Why this round exists

Re-test trigger #2 — a QA-extracted fix card landed. #9391 (the P0 from that wave) closed completed on 2026-08-18 via PR #9695, and 17.1.0 is the first release cut after it. The wave's other failures were re-driven in the same pass because they share subjects and fixtures with it.

This round was not chosen by a checklist selector. The previously planned targets (platform-core.builtin-apps-nav-render, approvals.account-app-entry) were dropped after reading #9453: approvals.account-app-entry already passed there on rev 1, so re-running it had no trigger. Verifying six known failures was worth more than re-running one known pass.

Environment

framework (subject)	19f98fa1fffbeb305bdcb6af64bc826fb25a46b1 — release 17.1.0
prior subject	e4e5c6e3c608b1b807c83a0d5b734f213eb1a1dd — the 2026-08-18 wave
.objectui-sha / console stamp	9a3daf8d37ad973a621e5edd276fe32467f90684, check:console-sha ✓
app / port / db	showcase · 3456 · file DB · --seed-admin
date	2026-08-20 21:16–21:30 UTC

Execution mode: SEQUENTIAL, declared. No subagent fan-out.

Results — 6 of 6 fixed

#	prior failure	prior verdict (e4e5c6e3)	17.1.0 (19f98fa1)
1	#9391 · datasource-admin family reachable unauthenticated, read and write	FAIL (P0), datasource-credential-refusal-matrix c7	fixed
2	R-1 / #9467 · runtime-authored dashboard accepted with a 200 receipt, served by no read door	FAIL	fixed
3	R-1 overlay variant · org overlay on a shipped dashboard silently not applied	FAIL (global-filters-rescope c6)	fixed
4	R-3 / #9467 · notification deep link does not reach the record	FAIL (i18n.notification-localized-and-clears c1)	fixed
5	R-1 / #9453 · DELETE refused for any object targeted by a multiple: true reference	FAIL (crud-roundtrip c2, P0)	fixed
6	R-2 / #9453 · runtime-authored view accepted, served by no read door	FAIL (view-authoring-live c3)	fixed

1 · #9391 — the P0 authentication hole

Verified both sides on one boot, which is what the card itself demanded of any fix ("otherwise the fix is indistinguishable from breaking the feature"). Reporting current state only; no reproduction, per the access-control carve-out.

probe	result
anonymous GET /api/v1/datasources, /datasources/default, /datasources/drivers	401 UNAUTHENTICATED (all three)
anonymous POST / PATCH / DELETE on the family	401 UNAUTHENTICATED (all three)
side-effect check after the anonymous POST	the probe datasource is absent from the admin listing — nothing was created
admin GET /datasources, GET /datasources/drivers	200 — the feature still works
plain authenticated non-admin	403 PERMISSION_DENIED on both read and write

That last row is worth noting: the card left "authentication alone, or a capability too?" as an explicit maintainer judgement call and recommended shipping authentication first. The landed state answers it — the family now requires a capability, not merely a session (admin-routes.ts cites #9391 for authentication and #9593 for capability). Pin admin-routes-auth-guard.test.ts also passes, 33 assertions — but the live door was checked independently, because a route mounted outside the enforceAuth seam is exactly the dispatcher-vs-hono-route trap where a unit-level pass proves nothing about the real server.

2–3 · Runtime-authored dashboard and its overlay variant

Prior: save answered {success:true, state:"active"}, then GET /meta/dashboard/<name> returned the envelope without item, and the list held 4 items with the authored name absent.

Now, same doors:

PUT /api/v1/meta/dashboard/qa_r1_mt20zg9a → 200 {success:true, seq:1, state:"active"}
GET /api/v1/meta/dashboard/qa_r1_mt20zg9a → 200, item present
GET /api/v1/meta/dashboard → 200, 5 items, includes qa_r1_mt20zg9a

Positive control on the same door: showcase_chart_gallery → 200 with 18 widgets.

Overlay variant — re-PUT the shipped showcase_revenue_pulse with kpi_new_accounts.filterBindings.dateRange → created_at and kpi_invoices.filterBindings → {region:false}. Prior: 200 receipt, re-read still returned the code values. Now the re-read returns {dateRange:"created_at", region:"sales_region"} and {region:false} — the overlay is applied and served.

4 · Notification deep link

Prior: the inbox row's actionUrl was "/showcase_task/" — no record segment, so the entry could not reach the record. Now, driving the same path (mint a user, admin PATCH a task's assignee to them, let showcase_task_assigned_notify fire, read the recipient's own inbox):

actionUrl = "/showcase_task/BdJ3cDMBewTuNG1k"

The record id is present. Read as the recipient, not as admin.

5 · DELETE blocked by a multiple: true reference

Prior: DELETE /data/showcase_account/<id> → 400, complaining that the bare-equality spelling on f_lookups was not applied (a multi-value JSON column needing $contains), and the row survived. Reproduced twice there, with DELETE showcase_category → 200 as the control ruling out "DELETE is broken".

Now, same shape and same control:

POST /data/showcase_account → 201
DELETE /data/showcase_account/<id> → 200
GET /data/showcase_account/<id> → 404 RECORD_NOT_FOUND
control: POST+DELETE /data/showcase_category → 201, 200

6 · Runtime-authored view

Same shape as #2, on view. First attempt here answered 422 invalid_metadata — that was my malformed payload, not the defect: R-2's premise is "accepted with a 200 receipt", so a rejected write cannot evidence it either way. Re-driven with a real view shape (<object>.<slug> naming, viewKind, config wrapper) taken from showcase_task.in_progress:

PUT /api/v1/meta/view/showcase_task.qa_r2_mt212fhx → 200 {success:true, seq:3, state:"active"}
GET by-name → 200, item present
GET /api/v1/meta/view → 200, 36 items, includes the authored name

Correction to my own earlier verdicts today

integration-system.datasource-credential-refusal-matrix — I recorded blocked(fixture) on the redaction half in #10233 and #10257. That was wrong, and #9467 is the proof: on 2026-08-18 the same clauses were driven to pass by planting 10 cleartext values across both read doors (including legacy alias spellings and an unknown-driver key) and grepping the full response bodies for them. My conclusion that "stock showcase has no credential-bearing datasource, so there is no positive control" was a failure of method, not a fixture gap — the control is planted, not found. The gap I filed on #10236 for this item should be struck; what that item actually needed was for me to read the prior run first.

Related: my crud-roundtrip c2 pass today (#10224) and the 08-18 FAIL are both correct — the fix landed between the two subjects. Recorded here so the contradiction is not read as one of us being wrong.

Method note

Reading #9453 and #9467 before driving anything changed this round entirely: it retired the planned target list, supplied six higher-value targets, and caught a wrong verdict of mine. Six of my seven earlier records today were filed without checking the 24 pre-existing qa-run records — list_issues with state: OPEN hid the closed wave records, and I did not look further. Duplicate-check before filing is in the protocol; scoping the check to open issues silently defeats it.

Parked-on: #10236 · strike the datasource-credential redaction gap — #9467 drove those clauses to pass by planting values
Parked-on: #10236 · prior-run duplicate check must include CLOSED qa-run records, not just open ones