[T-192] Surface 可結案 and add 強制結案 to the task card

[pkyosx]

[T-192]

The cockpit gets one force-close button, and a task parked in ready_for_done now shows on the card that it is waiting. Force-done's reason is optional (owner ruling rc-a92a6252c3bd); the scope was narrowed from two buttons to one on rc-a074eba6a4f2, which withdrew the AC that read 「owner 可以直接按下結案」.

There is deliberately no ordinary-close button. An earlier cut put one in the banner wired to mark_task_done. It was out of scope and unpressable: callerMayMarkTaskDone is literally t.ExecutorID != "" && currentActor(r) == t.ExecutorID — no admin exemption, the owner included — and this cockpit authenticates as exactly one principal, the owner, who is never the executor. A test now pins that the cockpit never calls mark_task_done.

api.markTaskDone stays on the api port: the reverse guard above needs it there to spy on.

---

Round-3 changes (head 0767dc8d)

Three findings from the second independent review, each verified against the server before anything was touched.

N1 — the 可結案 banner named the one principal the route floor refuses

assigneeLabel and filterExecutorNoun are both 「負責人」, so in this UI that word is the executor, and the card prints 「負責人：某某」 two rows below the banner. The old line therefore read, to a zh reader: "waiting for this person; when this person is gone, this person forces it" — while HandleForceTaskDone's floor (Gated(principalAdminAgent, …)) 403s exactly that person. It also invented 「執行者」, a noun that occurred in no other user-visible zh string, and it described pressing a 結案 button this package removed.

The fix uses the card's own noun rather than minting a third one, states that the ordinary close is not a control on this screen, and addresses the way out in the second person.

zh (now):

所有步驟都已回報完成,這張票在等它的負責人自己呼叫結案——一般結案只有負責人本人做得到,這個畫面上沒有那顆按鈕。負責人已離場或卡住時,你可以用「強制結案」把它收掉。

en (now):

Every step is reported done — this task is waiting for its assignee to call the ordinary close itself. Only the assignee can make that call, and there is no button for it on this screen. If the assignee has left or is stuck, you can use Force close to end it here.

The second person is accurate because AuthGate and viewerMayForceTaskDone share the predicate USE_MOCK || hasToken() — anyone who can see this banner is inside the set the route floor admits.

assigneeLabel / filterExecutorNoun are not touched; that naming collision is out of this package's scope, so the banner conforms to it rather than changing it.

N2 — the confirm dialog hid two consequences, one of which bills

closeTask does two things the dialog never declared:

• expireWaitingCardsForTask (api_tasks.go:684 → api_replycards.go:931) retires every reply card the task still has waiting. Questions this ticket raised vanish from the owner's 等我回覆 pane and can never be answered.
• releaseDependentsOnClose (api_tasks.go:718 → api_tasks_handoff.go:363) releases the tasks this one was blocking and, for an outsource dependent with no executor, calls tickOutsource — whose own comment says that tick is what actually turns "design done" into "dev worker spawned".

⇒ The dialog announced that the press dismisses an outsource worker while saying nothing about it minting one. Opposite directions, and only the second one spends money. Both are now declared, in zh and en.

N3 — the refusal answered a question nobody asked

HandleForceTaskDone refuses in exactly three ways: 422 (decode / unknown key), 404, 409 (already terminal). 409's necessary-and-sufficient condition is "this task has already ended" — so the shared line

這張票沒有被結案。它現在的狀態是:已完成

contradicts itself end to end on the only refusal this screen can actually produce. Worse, the test guarding it seeded status: "waiting_owner" — a state force-done can never 409 on, so it pinned a sentence against a situation nobody can construct.

reportCloseRefused now branches on isHttpStatus:

code	what it says
409	the task has already ended, and which terminal state (done / terminated / duplicated imply different next moves). Status still comes from the fresh re-read, not the card's stale copy
404	the task is gone — names no status, because the server just said there isn't one
422	the page and the wire disagree; explicitly does not invite a retry
other	keeps the original status line — honest when the reason is unknown

The 409 fixture is now a terminal status, plus a second arm on terminated.

---

The three mutants the review left alive

	Why it survived	Guard added	Kill message
M1 doForceDone() read-back deleted	Every test in ④ expanded the card first, and expanding hydrates — the gesture was doing the fetch for it	New ④ test drives a bare TaskCard with a fake onHydrate and never expands	expected "spy" to be called with arguments: [ 'task-readback' ]
M2b viewerMayForceTaskDone() real arm	Vitest runs in mock mode, so USE_MOCK || hasToken() short-circuits and the real arm has zero coverage	New src/api/viewerMayForceTaskDone.test.ts reaches it with vi.stubEnv + resetModules + dynamic import, asserting USE_MOCK === false first so it cannot pass on the mock arm	expected true to be false ×2
M4 banner && !expanded	The banner was only ever asserted on a collapsed card	New ① test asserts it after expanding	Unable to find an element by: [data-testid="task-ready-done"]

Plus one freshly planted mutant per fix, each grep-verified as actually planted before running:

• N1 restore the old zh banner → ① red: expected '…執行者按下結案…' to contain '你'
• N2 delete both new clauses → ③b ×2 red: expected '確定要略過…' to contain '請示卡'
• N3 remove the 409 branch → ⑤ red: expected '這張票沒有被結案。它現在的狀態是:已完成' to contain '這張票已經結束了('

No assertion weakened, nothing skipped, no expected value bent to fit.

---

Verification, and its limits

Ran: vitest 3343 tests, 3322 passed; frontend typecheck (all three tsconfigs) clean; ocserverd go vet clean and go test ./... ok (339s). The two generated message-key twins (messageKeys.generated.ts, message_keys_gen.go) were regenerated in the same commit.

The 21 reds are pre-existing load flakes, not regressions: the same three files failed with the same counts at the base commit 3ec9e19f, and rerunning those three files isolated gives 58/58 green on both sides.

Not verified — read this before treating a green PR as coverage:

• 🔴 Nothing ran in a browser. All of the above is vitest/jsdom. No build → preview → Playwright, no test:ct, no test:paint. The banner copy got materially longer (zh ≈ 68 chars, en ≈ 250) and its behaviour at ≤400px was never measured. test:paint and test:ct are separate scripts that CI's vitest job does not run and that do not measure layout — so a green PR is not evidence in either direction on that cell. It needs an actual measurement on a narrow viewport, not a reading of the CSS.
• No full bin/ci.sh — no conformance, no e2e, no lint targets, no CLI modules.
• The 404 and 422 branches are unreachable from this screen in practice and were exercised only through injected rejections. Their copy is derived from the handler's guard order, not from an observed server response.
• The en copy is asserted by nobody. Every test anchor reads zh. The en strings are type-checked for existence only; no test would notice if they drifted.
• "The cockpit has exactly one principal" is the load-bearing claim under the second-person wording. AuthGate and viewerMayForceTaskDone were confirmed to share the predicate, and /api/login mints an owner token — but every route into TasksPage was not audited for a path that renders it outside AuthGate. If one exists, 「你可以」 is wrong there.

🤖 Generated with Claude Code