[Birfy]

Owner: Dev3
Reviewer: Reviewer

Fixes #987

Tip SHA: 211080c

Reproduce

On 0553ba1e, in Settings → Bot Social → Share with a friend (plugins/social/client.js, ShareWithFriend):

• one status slot, note (:3152), takes a failed list read (:3169) and a failed Share click (:3200) alike, and a successful share writes { tone: 'ok' } (:3195);
• the retry button is keyed on the tone only (:3226-3228): after a failed share the card offers Try again, whose onClick calls load() — the friend-list reader, never the share;
• load() clears any error note when it succeeds (:3164 previous?.tone === 'error' ? null : previous), so pressing that button both fails to retry the share and wipes the share's message;
• the empty state is gated the same way (:3209 note?.tone !== 'error'), so a share error suppresses "No friends left to share with" for a list it had nothing to do with.

Both halves are Reviewer's non-blocking on #985: the note has no source.

What changed

• plugins/social/client.js: the note carries a source. A failed read writes { tone: 'error', source: 'list' }, a failed share writes source: 'share', a successful share { tone: 'ok', source: 'share' }. load() now clears only source === 'list'; the retry button is drawn only for a list error; the empty sentence is suppressed only by a list error. Nothing else in the panel was touched — row keys (friendKey), the 5 s poll, the [bot?.id] reset and The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984's read epoch/seq are byte-identical to main (the diff is the six lines around note).
• plugins/social/test/social.test.js: three cases on the existing sharingHost stateful renderer from The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984: (1) a failed share keeps its own message, draws no list retry, and a later successful poll does not clear it; (2) a failed read still offers the retry, the retry re-reads, and success clears that error; (3) a share error does not suppress the empty sentence, a list error does.
• docs/subsystems/social.md: the note-source rule next to the share-with-a-friend paragraph.
• changelog.d/987-share-error-not-list-error.fixed.md.
• No core/ file changed, so patches/ds-bot/ is untouched (no generate/check to redo); plugins/social/client.js is hand-written here, not a generated bundle.

What I ran

• cd plugins/social && node --import ./test/resolve.mjs --test --test-name-pattern="987|984" test/social.test.js → 7/7 (3 new, 4 The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984 guards).
• Full plugins/social suite (npm test, DSH_HARNESS set) → 423 tests, 423 pass, 0 fail, 0 skipped.
• node .github/scripts/changelog.mjs check → 67 fragments well formed.
• Four knives, each restored afterwards, all exactly as expected: retry keyed on tone → not ok 1 (2/3); load() clearing any error → not ok 1 + not ok 3 (1/3); empty gate back on tone → not ok 3 (2/3); dropping source: 'list' from the read failure → not ok 2 + not ok 3 (1/3).
• arch-docs, testing-layers and ds-bot-patches check need git/origin, so they run in CI's package job on this tip; plugins/social/client.js is a file the doc check maps to docs/subsystems/social.md, which this PR updates.

Red without the source change

Pristine 0553ba1e with only the three test cases added:

• --test-name-pattern="987" → 3 tests, 1 pass, 2 fail: not ok 1 (a failed share still offers share-list-retry and the next successful read wipes its message) and not ok 3 (a share error still suppresses the empty sentence). not ok 2 stays green on main by design — it pins the behaviour the list error already had, which is what acceptance 2 asks for.

Not run

• No browser/self-test pass: this is a note slot in one settings panel, and the stateful renderer drives the real component through mount/click/poll. The live-e2e suite does not cover the Sharing panel.
• Nothing ran against a real Bot Social server; social/share-with-friend is rejected by the fake host in the test, which is the failure shape in the issue.

Risk

• A share error now stays until the next share. A successful poll no longer clears it, which is the point, but it also means a stale share error survives a poll that fixed the underlying condition; the owner clears it by sharing again or leaving the panel (the component state resets on [bot?.id], untouched).
• source is component state, not persisted, so there is no migration and no old record to read.
• Two errors still share one slot: a failed read after a failed share replaces the share message rather than showing both. That keeps the panel one line high, as before; the issue asked that the retry and the clearance stop speaking for each other, not that two messages show at once.

[Birfy]

Verdict: PASS at 211080c
Written-by: Reviewer

#987 is the source split the two non-blocking notes on #985 asked for, and nothing else: four files, and in plugins/social/client.js only the note around the two writers plus its two readers. The list read failed / share failed / share ok paths now say which one they are, load() settles the list only, the retry belongs to the list, and the empty sentence is suppressed by a list error alone.

Ran them on the tip 211080c2 and on pristine 0553ba1e in this checkout (no git, so nothing from package was re-run here; it is green on the tip):

$ cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js"
1..423
# pass 423   # fail 0   # skipped 0

$ cp <tip>/plugins/social/test/social.test.js <pristine 0553ba1e>/plugins/social/test/
$ ... --test --test-name-pattern="987" test/social.test.js
not ok 1 - #987: a failed share keeps its own error and offers no list retry
ok     2 - #987: a failed list read still offers a retry that re-reads and clears its own error
not ok 3 - #987: the empty sentence is suppressed by a list error, not by a share error
# pass 1   # fail 2

The red is the shape the issue asks for: 1 is the shared slot (share failure offered the list's retry, and the next successful read wiped it), 3 is a share error suppressing "No friends left". 2 is green on 055ba1e by design — it pins the list read's existing retry, which acceptance 2 wants kept.

Three knives, each restored and checked byte-identical afterwards:

• retry back to note.tone === 'error' → not ok 1 (2/3) — the retry gate is pinned;
• load() back to previous?.tone === 'error' → not ok 1 + not ok 3 (1/3) — the clearance is pinned;
• empty gate back to note?.tone !== 'error' → not ok 3 (2/3) — the empty sentence's owner is pinned.

So each of the three changed predicates has a case that goes red on its own. The panel.poll() step is not vacuous either: the second knife changes only the clear predicate and test 1 goes red, which means that poll's social/share-friends really resolved and really reached setNote. node .github/scripts/changelog.mjs check → 67 fragments well formed. Tip checks: 12 green, enqueue-guard only (this comment), one judge duplicate cancelled.

Two non-blocking notes, neither holds this tip:

1. source: 'share' is decorative. Both predicates ask for 'list' positively (previous?.source === 'list', note.source === 'list'), so a note written with no source at all — or a fourth source someone adds later — is treated as a share note and silently gets no retry and no clearing. That is the safe direction today, and only these two writers exist. If a third source ever lands, make it kind: 'list' | 'share' | … and keep "no retry" as the default rather than deriving it from !== 'list'.
2. One slot, the other direction. The author's Risk names "a failed read after a failed share replaces the share message". The reverse is the one I'd watch: a list error is the only thing that carries Try again, and a failed share click replaces it (and share() clears the note at click start, :3187), so the card can end up with a share error, no retry, and a still-stale list until the panel is remounted. That trade is unchanged from before this PR and the issue explicitly asked only that the two stop speaking for each other, so it is not worth a new tip now — a later one could keep the list error sticky underneath.