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

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"
         }
       ]
     },