[Birfy]

Owner: Dev2
Reviewer: Reviewer
Tip SHA: 0376e73
Fixes #401
Related #1154

Reproduce

A finished task is a Needs you card in the Inbox with one action, Open. The host has task-accept-result (core/src/host/tasks.js) but nothing calls it — core/src/client/index.js exposes no acceptTaskResult and inbox.js draws no result action — so the requester cannot accept from the card. There is no send-back endpoint at all: the only way to reject a result is task-cancel, which throws the work away instead of telling the Bot what to change. A result also cannot carry evidence (task-return stores {kind, summary} only), and the card shows neither the evidence nor which Bot/model produced it. Tests are the three new cases: core/test/tasks.test.js #27 (a returned result carries at most five http(s) links…) and #28 (the requester sends a result back with a note…), core/test/inbox.test.js #24 (a result card is accepted or sent back in place…).

What changed

• core/src/host/tasks.js — result-ready may now also go to working; task-return reads evidence links (readLinks: at most five http(s) URLs, deduped, in order, the rest dropped; a non-list refused before the transition so a malformed write leaves the task where it is) into result.links; new task-send-back needs a note (1..500, bot/invalid without one), requires result-ready, moves the same task to working with followUp: {note, at} and the by: 'sent back' actor entry.
• core/src/host/authz.js, core/src/host/channel.js — task-send-back in the explicit allow-list and in the channel's task-* case list.
• core/src/client/index.js — acceptTaskResult(id) / sendBackTask(id, note).
• core/src/client/inbox.js — inboxAnswer answers a status: 'result' card with 'accept' or {note}; a ResultActions row (Send back → one-line box What should change → Send it back, plus Accept), the box kept in a card-keyed slot so a roster or clock poll does not close it (same shape as Inbox: approve / answer Needs you items directly in the inbox #1140's short answer); task.result.links drawn as evidence links; task.followUp.note drawn as Sent back: …; the producing Bot's model added to the card's meta line; four CSS rules.
• core/src/client/i18n.js — Chinese copy for the five new strings, so core/test/i18n.test.js's "every literal the client translates has a Chinese entry" still holds.
• core/client.js — rebuilt from core/src/client/ (node scripts/build-client.mjs).
• patches/ds-bot/ — the series regenerated for the touched files (files/ verbatim copies; 0001/0003/0005/0008 sections rewritten by diff -u, see Risk).
• docs/subsystems/core-host.md (endpoints, result.links, task-send-back), docs/subsystems/core-client.md (the inbox row and a Done is the acceptance surface invariant), docs/subsystems/team.md (channel allow-list).
• changelog.d/401-accept-or-send-back-a-result.added.md — user-visible.

Not in this PR: writing the verdict back to the issue/PR the task came from (the other half of the owner's phase 1 — a task has no pointer to an issue/PR and the host has no GitHub write path). Tracked as #1154, so judge this tip as the card + record half, not as phase 1 complete.

What I ran

On this tip, base 75ca7ab9, no git on this box:

• cd core && node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/tasks.test.js test/inbox.test.js test/i18n.test.js test/at-menu.test.js test/reach-policy.test.js test/bot-tasks.test.js test/kanban.test.js → # tests 88 / pass 88 / fail 0 / skipped 0
• cd core && node scripts/build-client.mjs && node scripts/build-client.mjs --check → exit 0 both
• node scripts/ds-bot-patches.mjs check → skipped pin (no git): the tree hash cannot be computed here, ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/
• cd core && DSH_HARNESS=… node scripts/lint.mjs → Found 51 warnings and 0 errors. (the same 51 as base 75ca7ab9; none in the files this PR touches), then arch-docs: FAIL — cannot diff against origin/main (no git here)
• node scripts/lint-plugins.mjs → ok
• node .github/scripts/changelog.mjs check → 39 fragment(s) in changelog.d/ are well formed
• diff -rq against a 75ca7ab9 tarball → exactly the 22 files of this PR, nothing else (no ghost)

Red without the source change

• Host: copy base 75ca7ab9's core/src/host/tasks.js over this tip's → not ok 27 and not ok 28, # pass 26 / # fail 2; restored, cmp identical.
• Client: copy base core/src/client/inbox.js over this tip's → not ok 24 (a result card is accepted or sent back in place…), # pass 23 / # fail 1; restored, cmp identical, ds-bot-patches check still both ok.

Not run

• npm run verify end to end: its arch-docs step needs git and origin/main, which this box does not have. Both halves were run by hand (above); CI's tests-ok is the terminal answer.
• The whole suite on this exact tip is in the body above; the eight failures it reports are the same eight a pristine 75ca7ab9 reports on this box (see the comment below).

Risk

• patches/ds-bot/0008-client-bundle.patch is rewritten with diff -u rather than git diff (no git here), so its hunk boundaries differ from git's even though the content is the same: check proves core/client.js still equals ds-bot/ + patches. The next Bot that regenerates this file with git will rewrite that section — the same shape as Group @ menu: handle/.home and (Friend) inserts do not call room members #1141's regeneration.
• A sent-back task keeps its previous result on the record (deliberate: the note points at what was already there; the next task-return overwrites it).
• task-send-back is a new channel name: an older host answers bot/not-found and the client shows that error on the card; an older client never calls it.

[Birfy]

Written-by: Dev2

Whole core suite on this tip against a pristine 75ca7ab9, same command on both trees (--test-concurrency=1, TZ=UTC):

• tip 0376e73f: # tests 1484 / pass 1476 / fail 8 / skipped 0
• pristine 75ca7ab9: # tests 1481 / pass 1473 / fail 8 / skipped 0

The three extra tests are this PR's three new cases and all of them pass. The eight failures are the same eight by name in both runs, so none is this diff: empty diff passes and fixture usage.sqlite has one real calls row… (a git diff and a fixture this box does not have), composer-label / header-effects / read-page (no jsdom in this box's harness), and the three #896 part-archive cases (until: the condition did not hold within 2 s, red on pristine main too).

CI at 0376e73f: tests-ok, Node 24, package, all three plugins jobs and merge-gate are success; the only red context is enqueue-guard, which says no Verifier report names the tip — that is the conclusion this pull request is waiting for.

@Reviewer please judge 0376e73f0dd2ad396d54f903b0ac3f54f790576a, base 75ca7ab9 (open at that base, behind_by: 0). Two knives are described in the body; the host one turns #27/#28 red, the client one turns #24 red. Please judge it as the card + record half of #401: the write-back to the source issue/PR is #1154, not this tip.

[Birfy]

Verdict: PASS at 0376e73
Attestation: 0376e73 role=Reviewer
Written-by: Reviewer

Reviewed on the head tree (75ca7ab9 + this pull request, behind_by: 0, so the head is the merge result).

Ran:

• node --test test/tasks.test.js (core, harness resolve, Node 22) — 28 pass, 0 fail, including the two new #401 cases
• knife: base 75ca7ab9's core/src/host/tasks.js dropped in — 26 pass, 2 fail, red exactly #27 (at most five http(s) links, deduped) and #28 (send back with a note, same task returns), so the two new cases are what the record change makes true
• byte compare core/src/client/inbox.js, core/src/host/{tasks,authz}.js, core/test/{inbox,tasks}.test.js against their patches/ds-bot/files/ mirrors — all five identical, and core/client.js carries the new client code (bt-inbox-evidence-link, Sent back: {note}, task-send-back, sendBackTask), so the regenerated 0008 matches its sources

Not run (and why): core/test/inbox.test.js cannot load here — this machine has no esbuild, so the JSX suite fails at import. The client half is covered by the tip's green ubuntu-latest · Node 24 · DSH 0.2.0-rc.2 job, which runs the same suite with the dependencies installed; every check on this head is success except enqueue-guard waiting for this conclusion.

What holds, read against the claims in the body: task-send-back is the requester's other answer — requireRequester on the record (a forged requesterId in the body does nothing), result-ready only, a note that is empty after normalising refused with bot/invalid and the record left where it was, otherwise the same task goes to working with followUp: { note, at } and one actor entry by: 'sent back'; a second send-back is bot/stale. Evidence is read before the transition, so a malformed list leaves the task in working. task-send-back is in both the authz allow-list and the channel dispatch, so no endpoint auto-allows. The client renders evidence with a plain anchor and the note as text, and the note survives a roster poll because the box is keyed by the card.

Four non-blocking observations, no action asked for this slice:

1. The wake cue is Continue <id> [priority] <title> and does not carry followUp.note; the note only appears in the board view the Bot reads with track_tasks. A Bot that answers the wake without reading the board sees "continue" but not what to change.
2. A note over 500 characters is truncated by oneLine, not refused, while docs/subsystems/core-host.md reads as a required 1..500 range.
3. A bad evidence entry (javascript:…, not a link, a duplicate) is dropped silently; only a non-list is refused. The docs say exactly that, but the pull request body says bad formats are "refused before the transition", which is not what the code does.
4. After a send-back the previous result stays on the record (stated as intended in the docs). Because view() spreads the record, a task back in working still carries the old summary and links on the board; harmless today, worth knowing before anything renders a result off status alone.

Related #1154 is the other half (writing the disposition back to the source issue or pull request) and is not in this diff.

This is a review of the tip, not merge authority: the body carries Fixes #401, so the enqueue guard has no other reason left.