qa(checklist): write-feedback acceptance[1] states the record-level vs singleton / named-automation boundary (#26185)

<!-- claude-projects-attribution: {"github_login":"os-steve"} -->
_Requested by **Steve** · [project
thread](https://claude.ai/code/project/chan_01FdL1XeUyvVNxLreh3F4Qi9?thread=cmsg_01FdL1XeUyvVNxLreh3F4Qi9VKYMfHJzAPdSSUmVdsTS15)_
Fixes #25849
Clause-②: no
Metadata-protocol: none

The fifth line of the card: `ux-conventions.write-feedback`
acceptance[1] reworded to the maintainer's ruling, comment 6417978207 on
the card, letter **C**. Wave anchor: #25807 (linked only; it stays
open). The other four lines of the card landed in #26109; the ui half of
the ruling is its own card #26172, which this PR does not wait for: the
clause defines the test, the ui card makes the console pass it.

Docs only: one ledger file, one item. Nothing under `packages/`, `ui/`
or any governed surface moves, so the PR carries `skip-changeset`.

## What changed

`docs/qa/platform-checklist/areas/ux-conventions.json`, item
`ux-conventions.write-feedback` only:

- acceptance[1] `clause` states the boundary the ruling draws: a
record-level write names the record (title / display name) or the count;
a singleton page (settings) and a named automation are their own subject
and pass as they are; a bare Success / Done or a machine name still
fails.
- acceptance[1] `verify` is a two-step, decidable test: classify the row
first (record-level, or singleton / named automation), then score it by
that class's test. A record-level row that names only the object ("Task
created successfully") scores FAIL and cites #26172.
- `revision` 5 → 6; one `history` row citing the card, the ruling
comment 6417978207 and QA run #25817 (`ref` is the card, as the
revision-5 row of the same card is).

### Before (origin/main c7aa9cd)

```text
clause: success feedback names what changed — the record, item or count — rather than a bare 'Success' or a machine name

verify: read the captured text: it names the subject (record title, invitee email, package label, 'N created · M skipped'); a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row
```

### After (fa4e25d)

```text
clause: success feedback names its subject: a record-level write names the record or item (its title, label or display name) or the count; a singleton page (settings) and a named automation (e.g. Flow "X" completed) are their own subject and pass as they are; a bare 'Success' / 'Done' or a machine name never passes

verify: two steps per row. First classify the write: record-level (a record create, edit or delete, the import, the approval decision, a record or param action, a Studio item) or singleton / named automation (the settings save, a named Flow run). Then score it by that class's test. Record-level: PASS when the captured text names the record or item (record title or display name, invitee email, package or item label, e.g. 'Approved "EXP-2001"') or the count ('N created · M skipped', '1 row saved'); text that names only the object ('Task created successfully') scores FAIL — the console's record create and edit toasts read that way until ui card #26172 lands, so those rows are expected FAILs that cite it. Singleton / named automation: PASS when the text names that page or automation ('Settings saved', 'Flow "Reassign Task" completed'). In either class a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row
```

## Verification

- Scripted span edit (each anchor hit exactly once); a value comparison
proves the new document equals the old one plus the four declared
operations, the other two items of the file value-equal, and the bytes
outside the edited spans unchanged (`git diff`: +9 / −3).
- `pnpm check:platform-checklist` at fa4e25d: exit 0, `OK — 16 areas,
329 items (324 active, 1 planned)`.
- `dispatch-gates --commands` derives 13 families for this diff; all 13
run at fa4e25d, every one exit 0; `--ran` reconciliation: 13 derived,
13 run, 0 NOT-MEASURED, 0 UNRUN.

## Acceptance notes

- The record-level class keeps the original clause's "item" (Studio rows
are named by the item label) so the Studio autosave / publish / discard
variants still have a class; the ruling's own words name records,
settings and named automations only.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01LxjRCZExSRaXN87XaS2A33)_

Co-authored-by: Claude <noreply@anthropic.com>

Author: objectstack-fleet[bot]

docs/qa/platform-checklist/areas/ux-conventions.json

@@ -9,7 +9,7 @@
       "title": "Every user-initiated write answers visibly — success names what changed, a refusal says why, and a no-op claims nothing",
       "since": "v17.7",
       "status": "active",
-      "revision": 5,
+      "revision": 6,
       "priority": "P1",
       "surface": "browser",
       "personas": [
@@ -60,9 +60,9 @@
           "evidence": "per-variant table: variant · landed (y/n, request status) · feedback text verbatim or 'none' · screenshot"
         },
         {
-          "clause": "success feedback names what changed — the record, item or count — rather than a bare 'Success' or a machine name",
+          "clause": "success feedback names its subject: a record-level write names the record or item (its title, label or display name) or the count; a singleton page (settings) and a named automation (e.g. Flow \"X\" completed) are their own subject and pass as they are; a bare 'Success' / 'Done' or a machine name never passes",
           "oracle": "screenshot",
-          "verify": "read the captured text: it names the subject (record title, invitee email, package label, 'N created · M skipped'); a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row",
+          "verify": "two steps per row. First classify the write: record-level (a record create, edit or delete, the import, the approval decision, a record or param action, a Studio item) or singleton / named automation (the settings save, a named Flow run). Then score it by that class's test. Record-level: PASS when the captured text names the record or item (record title or display name, invitee email, package or item label, e.g. 'Approved \"EXP-2001\"') or the count ('N created · M skipped', '1 row saved'); text that names only the object ('Task created successfully') scores FAIL — the console's record create and edit toasts read that way until ui card #26172 lands, so those rows are expected FAILs that cite it. Singleton / named automation: PASS when the text names that page or automation ('Settings saved', 'Flow \"Reassign Task\" completed'). In either class a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row",
           "evidence": "the verbatim feedback strings"
         },
         {
@@ -135,6 +135,12 @@
           "date": "2026-10-26",
           "change": "knownGaps[1] and [3], variants[6] and [10], steps[3] and [5] and acceptance[5].verify corrected (checklist-accuracy findings of QA run #25817, release-18.2.0-manual-set at 6679644a, objectui pin b41ed7f68956; wave anchor #25807). Import Undo works in both create and update modes, so 'no stock surface offers Undo' is stale and acceptance[5] is scored on the import instead of blocked(fixture). Discard draft is now an in-app dialog. The approvals route has no drawer: a request opens on its record page. The console offers a member no inline edit, selection or drag, so the member's refusal row is Mark Done. Not applied: the run asked for a ruling on object-only success strings ('Task created successfully', 'Settings saved', Flow \"Reassign Task\" completed) under acceptance[1]; that is a maintainer decision, so acceptance[1] is unchanged and the question goes to the seat",
           "ref": "#25849"
+        },
+        {
+          "revision": 6,
+          "date": "2026-10-26",
+          "change": "acceptance[1] clause and verify reworded to the maintainer's ruling on the object-only success strings QA run #25817 (release-18.2.0-manual-set at 6679644a, objectui pin b41ed7f68956) asked about: ruling comment 6417978207 on #25849, letter C — a record-level write names the record (its title) or the count; a singleton page (settings) and a named automation (Flow \"X\" completed) are their own subject and pass as they are, and the clause states that boundary. verify now classifies each row (record-level, or singleton / named automation) before scoring it by that class's test. Not loosened: a generic 'Success' / 'Done' or a machine name still FAILS, and a record-level toast that names only the object ('Task created successfully') is an expected FAIL until the ui card #26172 lands. The 2026-10-07 instruction the clause rests on (every write has feedback; no machine names) is unchanged in meaning",
+          "ref": "#25849"
         }
       ]
     },