QA run · tier2c:browser-2 (18/18) · e4e5c6e3 · 2026-08-18 · 10 PASS / 4 PARTIAL / 4 FAIL #9467

Tier-2C — the final round of the platform-checklist QA wave (#9296). Scope: the last 18 unpinned P0/P1 items on the browser / mixed surfaces. All 18 consulted; every unpinned P0/P1 item in the ledger now has a verdict.

Environment fingerprint

Scope and per-item revision

10 PASS / 4 PARTIAL / 4 FAIL.

Per-clause verdicts

1 · identity-auth.session-list-revoke rev 1 — PASS

2 · identity-auth.api-key-ui-lifecycle rev 1 — PASS

3 · identity-auth.self-service-profile-password rev 1 — PARTIAL

Also observed (c6-adjacent, no clause): the profile card renders "Email cannot be changed." with the email input disabled.

4 · identity-auth.org-membership-team-management rev 2 — PASS

5 · integration-system.job-scheduled-run rev 2 — PARTIAL

6 · integration-system.notify-inbox-delivery rev 2 — PASS

7 · integration-system.datasource-credential-refusal-matrix rev 1 — FAIL (P0)

Note on encryptionKey (turso): write-accepted + read-redacted on both doors — the correct expectation per #8081 scope item 4, not a write-refusal failure. Separately observed and not a clause failure: the still-writable encryptionKey is stored in cleartext in sys_metadata, which the ordinary data API serves — but that path is admin-gated (PERMISSION_DENIED for a member, UNAUTHENTICATED for anonymous) and is exactly the "stays stored" behaviour datasource-credential-redaction.ts documents.

8 · dashboards.strict-widget-rejects-stray-keys rev 2 — FAIL

9 · dashboards.chart-type-matrix rev 3 — PARTIAL (matrix: 16 of 20 variants verified)

Ground truth first (/api/v1/data): 11 tasks · 5 distinct statuses · 4 distinct priorities · 2 month buckets · 5 projects across 3 accounts.

Enum re-read as the item's step 0 requires: ChartTypeSchema has exactly 20 members — the variants list is current.

10 · dashboards.global-filters-rescope rev 2 — FAIL

11 · i18n.notification-localized-and-clears rev 3 — FAIL

12 · i18n.surface-matrix rev 3 — PARTIAL

Expectations grounded first in GET /api/v1/i18n/translations/zh-CN (134,700 bytes; top-level groups objects, globalActions, dashboards, pages, messages, apps, metadataForms, settingsCommon, settings).

13 · i18n.strict-translation-key-rejection rev 1 — PASS

14 · search.pinyin-flag-both-sides rev 2 — PASS

15 · search.console-global-search rev 3 — PASS

A distinct defect surfaced while running this item and fails none of its clauses (the console always scopes its query): the unscoped documented route answers 400 — see R-4.

16 · automation.flow-run-step-nesting rev 2 — PASS

17 · automation.flow-error-handling rev 2 — PASS

18 · cli.scaffold-console-first-paint rev 1 — PASS

Honest caveat on c3: the scaffold registers no app of its own (GET /meta/app = setup, account), so its starter object qa_console_first_pai_note has no dedicated nav entry — a newcomer reaches it through the Setup app's object route or Studio.

Reproduction rules

R-1 — Runtime-authored / org-overlaid dashboard metadata is accepted with a 200 receipt and served by no read door (P1)

Fails dashboards.strict-widget-rejects-stray-keys c5 and dashboards.global-filters-rescope c6; blocks dashboards.chart-type-matrix c0/c4/c7. Same shape as the Tier-2B view finding (R-2 in #9453), now evidenced on dashboard.

pnpm -C examples/app-showcase exec objectstack dev --ui --seed-admin -p 3193 -d file:/tmp/qa-wave/t2c-C.db
POST /api/v1/auth/sign-in/email  {"email":"admin@objectos.ai","password":"admin123"}

PUT /api/v1/meta/dashboard/qa_repro2
{"name":"qa_repro2","label":"QA Repro 2",
 "widgets":[{"id":"w1","title":"Tasks","type":"metric",
             "dataset":"showcase_task_metrics","values":["task_count"]}]}

• expected: the dashboard is served back and renders.
• actual: the save returns {"success":true,"version":"sha256:15b715a1…","seq":1,"state":"active","message":"Saved dashboard 'qa_repro2' (org=org_msy16t4w8wiz56vr, state=active) [seq=1]"} and then
  • GET /api/v1/meta/dashboard/qa_repro2 → {"type":"dashboard","name":"qa_repro2","lock":"none","editable":true,"deletable":true,"resettable":false} — the envelope without the item key;
  • GET /api/v1/meta/dashboard → 4 items (showcase_chart_gallery, showcase_ops_dashboard, showcase_revenue_pulse, system_overview), the authored name absent;
  • browser /_console/apps/com.example.showcase/dashboard/qa_repro2 → "Dashboard Not Found — The dashboard "qa_repro2" could not be found. It may have been removed or renamed."

Overlay variant (same defect, drives c6): re-PUT the shipped showcase_revenue_pulse document with widgets[kpi_new_accounts].filterBindings.dateRange changed to "created_at" and widgets[kpi_invoices].filterBindings = {region:false}. The save answers {"success":true,"seq":6,"message":"Saved customization overlay (org=…, state=active) — type=dashboard, name=showcase_revenue_pulse"}, and then the re-read still returns the code values ({dateRange:"signed_on", region:"sales_region"}, and no filterBindings at all on kpi_invoices), and the reloaded dashboard still queries signed_on.

Controls and trap rulings (all measured):

• Positive control, same door: GET /api/v1/meta/dashboard/showcase_chart_gallery returns {type, name, item:{…18 widgets…}} — the read door works; it simply does not resolve org-scoped runtime-authored rows.
• Storage control: the rows are stored — sys_metadata holds 3 type=dashboard rows, state=active, organization_id=org_msy0avxsf5eiqdj6.
• Org confound ruled out: exactly 1 sys_organization row and it is the session's active org (get-full-organization.id = the id in the save receipt).
• Reproduced: 4 saves across 3 names on instance A, plus a 5th on a fresh boot with a fresh DB and a different org id (instance C) — deterministic, schema-driven, not state-dependent.
• automation-input: not applicable — pure curl + direct navigation; no clicks in the write path.
• hydration-race: the browser leg settled 6 s and was screenshot-confirmed before any DOM read.
• stale-console-bundle: the console stamp equals the .objectui-sha pin, and the same bundle renders the shipped dashboards correctly in the same session.

Likely owner: framework metadata read path (the same layer as #9453's view finding), not objectui — the API read door is already wrong before the console is involved.

R-2 — (withheld)

integration-system.datasource-credential-refusal-matrix clause c7 — access-control finding — detail withheld pending maintainer; held by the runner. Already filed as #9391; independently re-confirmed this round. No reproduction published.

R-3 — The notification deep link does not reach the record (P1)

Fails i18n.notification-localized-and-clears c1.

pnpm -C examples/app-showcase exec objectstack dev --ui --seed-admin -p 3191 -d file:/tmp/qa-wave/t2c-A.db
POST /api/v1/auth/sign-up/email {"email":"bravo@qa.example","password":"QaWave!2026","name":"QA bravo"}
as admin: PATCH /api/v1/data/showcase_task/<id> {"assignee":"<bravo user id>"}
   → flow showcase_task_assigned_notify fires; the row's actionUrl is "/showcase_task/<id>"
sign in as bravo in the console → open the bell (button aria-label 打开消息中心 / "Open message center")
→ click the notification entry INSIDE the popover (ref-target the entry's own <button> ancestor)

• expected: navigation to the task's record page.
• actual: navigation to /_console/apps/showcase_app/page/showcase_capability_map — the app's landing page. Direct navigation to the authored shape /_console/showcase_task/<id> lands on the same page.
• Positive control: /_console/apps/showcase_app/showcase_task/record/<id> renders the record page correctly, and in zh-CN (状态 评审中; sections 概览/排期/详细信息; labels 项目/负责人/优先级/截止日期/进度) — so the detail page and its localization are fine; only the deep link is.

Traps ruled out: automation-input — the first attempt was an artifact (a bare text match hit the home page's "Needs your attention" card, not the popover) and was discarded; the recorded run used a ref-targeted click on the popover entry's own <button> ancestor, and that same click provably ran the handler because POST /api/v1/notifications/read fired from it. hydration-race — 7 s settle, screenshot before DOM. shared-browser-tab — own context, absolute origin. wrong-panel — the DOM chain was scoped inside [data-radix-popper-content-wrapper]. Reproduced twice (popover click + direct navigation).

Two candidate homes, for triage not for me to decide: the showcase fixture authors actionUrl: '/showcase_task/{record.id}' (examples/app-showcase/src/automation/flows/index.ts), and the console resolves an app-relative actionUrl to the app root rather than to /apps/<app>/<object>/record/<id>.

R-4 — GET /api/v1/search (unscoped) is 400 whenever pinyin recall is on and a federated object is registered (P1)

Surfaced under search.console-global-search; fails none of its clauses — the console always sends an objects= allowlist that excludes the offending object, so the palette and /search page are unaffected. It bites any caller using the bare documented route.

pnpm -C examples/app-showcase exec objectstack dev --ui --seed-admin -p 3191 -d file:/tmp/qa-wave/t2c-A.db
GET /api/v1/search?q=INV-1003        (admin bearer)

• expected: 200 with hits.
• actual: 400 {"code":"INVALID_FILTER","error":"Filter on '__search' names a column that object 'showcase_ext_customer' has no column for, so the predicate never ran. A filter on a field that does not exist can only match zero records, so the query was refused instead of answered with an empty list. …"}

Isolation and controls:

• Reproduced twice on distinct terms (INV-1003, Warehouse).
• Flag discriminator: the identical request on a boot with OS_SEARCH_PINYIN_ENABLED=false returns 200 with hits. The pinyin search-companion ORs {__search:{$contains:term}} for every searchable object; showcase_ext_customer (external datasource) has no __search column, and the fail-closed filter guard refuses the whole query rather than skipping that object.
• Culprit isolated: POST /data/showcase_ext_customer/query {"search":"INV"} reproduces the same 400 alone, while POST /data/showcase_invoice/query {"search":"INV-1003"} returns 200 with rows.
• This is the stock configuration — the showcase declares supportedLocales: ['en','zh-CN'], so pinyin defaults ON.
• automation-input not applicable (pure curl).

Checklist-accuracy findings

• CF-1 · i18n.surface-matrix rev 3 step s6 and its _views.emptyState knownGap are stale. They instruct the runner to record the emptyState variant as blocked(fixture) citing showcase: no view authors an emptyState, so the objects._views.<view>.emptyState translation surface has no fixture to test #7714 because "no view in examples/app-showcase authors an emptyState at all". At this pin examples/app-showcase/src/ui/views/task.view.ts does author one on the filtered urgent view (its comment block explicitly cites showcase: no view authors an emptyState, so the objects._views.<view>.emptyState translation surface has no fixture to test #7714), and the zh-CN bundle carries objects.showcase_task._views.urgent.emptyState.{title,message}. Driven this round: with the two urgent rows demoted, the view renders 暂无紧急任务 / 当前没有需要立即处理的事项。任务优先级调整为「紧急」后会出现在这里。 The variant is runnable — remove the waiver and bump revision.
• CF-2 · i18n.surface-matrix c10's premise is wrong, and it nearly produced a false resolver FAIL. The clause asserts the feed/audit verb "localizes on the zh-CN session". It does not, and cannot: packages/plugins/plugin-audit/src/audit-writers.ts:1393 renders the summary once at write time via resolveWriteLocale(tenantId, userId) and stores the string, with an EN hardcoded fallback. Switching only the browser session locale changes nothing — a write performed from the zh session still produced Updated Task "Warehouse schema". Flipping the tenant setting (PUT /api/settings/localization {"values":{"locale":"zh-CN"}}) and writing again produced 更新了 任务 "Warehouse schema". Re-word the clause around the write locale.
• CF-3 · i18n.strict-translation-key-rejection step s3 names both bundle-door functions as if they share an entry point. defineTranslationBundle is on the package root (@objectstack/spec); defineTranslation is not — it resolves only through the @objectstack/spec/system subpath. A scratch script importing both from the root gets defineTranslation is not a function and reads exactly like a missing guard.
• CF-4 · search.pinyin-flag-both-sides c2 over-specifies the OFF-side expectation. It says 'zhangwei' must no longer return 张伟 with the flag off. On the stock fixture it still does — via the source column email = zhangwei@huaning.example, and likewise huaning on the account via website/billing_email. The initials forms (zw, hnkj, wf) do go to zero, which is the real discriminator. Re-target the clause at the initials, or add a pinyin-only term with no source-column spelling.
• CF-5 · automation.flow-error-handling step s4 prescribes an api-triggered probe, whose failure c6 then cannot observe. The ERROR line exists precisely because "no caller holds this result" — for a manually/api-triggered run the caller does hold it (the trigger response carries the error), so no ERROR line is written and the log stays clean. Score c6 from a trigger-fired specimen (this round used showcase_declarative_connector_ping and showcase_task_completed_rest_ping), or have the probe fire from a record-change trigger.
• CF-6 · cli.scaffold-console-first-paint fixture note "no seeded admin unless one is requested" is stale. At this pin bare objectstack dev seeds one automatically on an empty DB and prints 🔑 Dev admin: admin@objectos.ai / admin123 in the banner, and the console login page repeats it. c3's open question ("is there any identity a newcomer can sign in with?") has a definite answer: yes.
• CF-7 · identity-auth.session-list-revoke c4 describes revoke_reason as a closed vocabulary. It names {idle_timeout, absolute_max, concurrent_cap, admin}, but sys-session.object.ts:154 declares free text whose description lists those only as examples ("…, …"). The observed value after revoke-other-sessions is user_revoked — legitimate, not a violation. Soften the clause or declare the select.
• CF-8 · Correction to the wave's standing bearer-token fact (tracking: full platform-checklist regression against main @ e4e5c6e3 — five-round orchestration #9296 briefing / QA run · tier2b:browser-1 (21/21) · e4e5c6e3 · 2026-08-18 · 7 PASS / 12 PARTIAL / 2 FAIL #9453 item 1). "The console authenticates by bearer token in localStorage, not by cookie" is true for the data client but incomplete: a real form sign-in also sets a better-auth.session_token cookie, and at least one route family requires it. Driving with a localStorage token alone made POST /api/v1/storage/upload/presigned answer 401 AUTH_REQUIRED while GET /auth/get-session on the same page returned 200 — a convincing fake "avatar upload is broken". With a real form sign-in the whole chain is 200. Runners driving any storage/upload surface must sign in through the form.

Fixture gaps

• FG-1 — No passwordless/SSO-only user on stock showcase → self-service-profile-password c5 stays blocked. (Restates the item's own knownGap; unchanged at this pin.)
• FG-2 — Job probes are unauthorable at runtime. job is allowRuntimeCreate=false, allowOrgOverride=false, so the interval/once/failing/timing-out/disabled/handler-missing scratch jobs job-scheduled-run prescribes need source + redeploy. Four of its six clauses (c0 cron arm, c2, c3, c4) are blocked on this alone. Candidate: ship the specimens in examples/app-showcase/src/automation/jobs/ behind an env flag.
• FG-3 — No dataset-sourced dashboard filter anywhere in the showcase. Both revenue-pulse and ops-dashboard declare static inline options arrays, so global-filters-rescope c8's server-GROUP-BY half has nothing to observe (opening the select fires 0 requests). One filter sourced from a dataset would close it.
• FG-4 — The two translated _actions on showcase_task (showcase_recalc_estimate, showcase_recalc_selection) are not surfaced on the list row menu, the list toolbar, or the record page, so i18n.surface-matrix c5 (action confirm/success copy) has no reachable specimen. Either surface one of them, or add an _actions translation for an action that is reachable (Mark Done / Reassign… / Log Time / Archive are all EN with no bundle entry).
• FG-5 — No turso driver in the tree (@objectstack/driver-turso not installed), so datasource-credential-refusal-matrix c6's live connect probe after the mask round-trip had to fall back to a stored-row oracle.
• FG-6 — The showcase app declares no apps.showcase_app translation entry, so the nav labels variant of i18n.surface-matrix is only demonstrable on the platform setup/account apps. Correct as fallback behaviour, but it means the app-authored nav surface is untested.
• FG-7 — No seeded persona owns any showcase_invoice row, so a member bound to contributor sees 0 of 12 rather than a partial slice. console-global-search c5 still passes (invisible row absent, no leaked count, object provably searched), but a sharper "sees 11, not INV-1003" contrast needs one seeded invoice owned by a signup-able persona.

Derived observations (no clause failed)

• translation has the mirror-image asymmetry of R-1, and it is benign: a runtime-authored translation is served by the i18n resolver (/i18n/translations/:locale and /i18n/labels/:object/:locale both returned the authored values) but not by GET /meta/translation/<name> or the /meta/translation listing, which return RESOURCE_NOT_FOUND / 0 items. Worth a look alongside R-1 since both are org-scoped runtime metadata read paths.
• Boot diagnostics carry the known Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686 autonumber tenancy split (showcase_field_zoo.f_autonumber, organizationCount: 0) — WARN level, already filed, fails no clause here.

Close-out inputs for the PM

Per this round's brief the run record carries qa-run + tests only; defect extraction is the PM's close-out duty. Cards this round warrants:

1. R-1 — runtime-authored/org-overlaid dashboard metadata never served. Very likely the same root cause as QA run · tier2b:browser-1 (21/21) · e4e5c6e3 · 2026-08-18 · 7 PASS / 12 PARTIAL / 2 FAIL #9453's R-2 (view); consider one card covering both metadata types.
2. R-3 — notification deep link does not reach the record.
3. R-4 — unscoped GET /api/v1/search 400s whenever pinyin recall is on and a federated object is registered.
4. R-2 — already filed as The datasource-admin HTTP family is reachable unauthenticated, read and write — mounts outside the enforceAuth seam #9391; nothing to extract, nothing published here.

CF-1…CF-8 and FG-1…FG-7 close out through this wave's anchor card (#9296), not as separate cards.

Wave anchor: #9296.