fix: work-on-task-assistant states findings, not conclusions

CHANGELOG.md

@@ -8,6 +8,10 @@ Please choose versions by [Semantic Versioning](http://semver.org/).
 * MINOR version when you add functionality in a backwards-compatible manner, and
 * PATCH version when you make backwards-compatible bug fixes.
 
+## Unreleased
+
+- fix: `vault-cli:work-on-task-assistant` no longer states conclusions from evidence it merely grepped, and its report block list is declared closed. Dispatched 2026-10-17 to find a task and its guides, the agent added an unsanctioned `🔬 Independent read-only corroboration` block asserting the router log held "exactly one request" in a window that held 16 (five PIDs across four builds), and that "the absence of any worker-attributable line means the request did not arrive" — the opposite of the truth, since that router sampler-gates successful requests out of the log while always logging failures. The owning session had to re-derive both claims, and taken at face value they would have inverted the diagnosis. A second rule requires any inference to be marked `(inference — unverified)`: a log the agent did not write may be sampled, truncated, or shared by concurrent writers, and its silence rarely means absence.
+
 ## v0.169.4
 
 - fix: `/vault-cli:session-close` no longer emits `⚪ DONE` on a carried-forward `in_progress` anchor. The mode gate deliberately lets a task the operator already resolved this session reach the clean verdicts, but every clean-verdict block in § Closer panel prescribed `⚪ DONE` — which `~/.claude/CLAUDE.md` names an anti-pattern while the anchored task still reads `in_progress`, requiring 🔵 READY / 🟡 WAITING / 🔴 BLOCKED in its place. The two rules are not reconcilable by wording: the command's own § Closer panel says *"verbatim, no rewording"*, so a session reaching mode 1 or 2 with a carried-forward anchor had no legal closer to emit. Closing a session is not the same claim as the task being finished, so the rule now keeps the block's body unchanged and swaps its `⚪ DONE` line for the panel the anchor's own state calls for — 🟡 WAITING with `later (on <trigger>):` when every open item is clock-bound, 🔵 READY when the next step is the operator's. Only the anchor's own status licenses `⚪ DONE`. Measured 2026-10-14 and 2026-10-15: two consecutive runs reached a clean verdict with a carried-forward anchor and had to improvise the panel against this section's verbatim rule, because no block offered one.

agents/work-on-task-assistant.md

@@ -428,6 +428,10 @@ If `JIRA_MCP_AVAILABLE` AND input was a Jira ID:
 Then render the report (output_format below).
 </workflow>
 
+**The block list below is closed.** Render the bracketed blocks that apply and nothing else — never invent a section. Hand back command output inside the block it belongs to, attributed to the command that produced it.
+
+**Findings, not conclusions.** State what a command printed; never what it means. *"The window holds 16 `[req]` lines"* is a finding; *"so the request did not arrive"* is a conclusion, and the session that owns the task draws it. Mark any inference you do state as `(inference — unverified)`. Evidence you grepped is not evidence you can characterize: a log you did not write may be sampled, truncated, or shared by concurrent writers, and its silence rarely means absence. Observed 2026-10-17: dispatched to find a task and its guides, this agent added an unsanctioned `🔬 Independent read-only corroboration` block asserting the router log held *"exactly one request"* in the window (it held 16, from five PIDs across four builds) and that *"the absence of any worker-attributable line means the request did not arrive"* — the opposite of the truth, because that router gates **successful** requests out of the log and always logs failures. The session had to re-derive both claims before it could proceed, and taken at face value they would have produced an inverted diagnosis.
+
 <output_format>
 ```markdown
 📋 Task: <title> [(<jira_id>)]