A tracked task lives in one session, so qm answers questions about it confidently and wrongly from anywhere else

[ianTPE]

A tracked task lives in one session, so qm answers questions about it confidently and wrongly from anywhere else

qm accepted a chase-and-report task in a channel thread. Forty-two minutes after
it had reacted 👍 to the answer arriving in that thread, the requester asked
about it in DM and qm stated, with specifics and no hedge, that no answer had
come. Both conversations are qm's own; they are just different sessions.

The result: the person who had answered was implicitly reported as
unresponsive, and had to come back and defend themselves. That is a worse
outcome than qm simply not knowing, because the wrong answer was delivered with
confidence and detail.

(Test scenario on my own deployment, translated. Ids and timings verbatim.)

The two sessions

a11e5cb2-…  type=channel  scope=channel:C0BQGNCH5M4  thread_ref=ch:C0BQGNCH5M4:1786889594.597359
            title: "Chase John 勞健保加保 status, report back"

282b41a2-…  type=dm       scope=personal:founder@…   thread_ref=dm:D0BP1SJN6SE
            title: "Pick assistant voice: lowkey, Editor, or Right Hand"

The task, the commitment, the scheduled report and the answer all live in the
first. The question was asked in the second.

Sequence

• 22:13 (channel) founder asks qm to chase admin and report back in an hour.
  qm posts the question in-thread and commits to reporting.

• 23:15 (channel) qm reports on schedule: no reply yet. Correct at that moment.

• 23:26 (channel) admin answers in-thread. The run is handled, and returns
  {"status":"react","reactions":["+1"]} — qm acknowledged it. (Why it only
  reacted is a separate report.)

• 00:08 (DM) founder asks whether admin replied. qm answers:

  還沒 — Admin 到現在都沒回。

  狀況是：昨天 14:13（台北時間 22:13）已在 #team-人事 串上 @Admin 問了，14:17 又私訊他提醒一次，一小時後的回報排程也跑過了，但串上和私訊都沒有他的任何回覆。John 今天就報到，加保狀態等於還是未知。

  ("Not yet — Admin still hasn't replied. … asked in-thread at 14:13, DM'd him
  again at 14:17, the hourly report fired, but there is no reply from him
  either in the thread or in DM. John starts today, so the status is unknown.")

• 00:13 (channel) admin: "Didn't I reply? Why are you saying I didn't?"

The DM answer is not vague. It reconstructs the timeline accurately up to 23:15
and then asserts a specific negative — no reply in the thread — about a thread
whose latest message qm had already processed and reacted to.

What I think is actually wrong

It isn't that the DM session lacked the data. It's that nothing in the system
distinguishes "I have checked and there is no answer" from "this session cannot
see that thread." Both render as the same confident sentence.

Two properties combine:

• The commitment is session-local. qm promised a report; that promise, its
  deadline and its resolution state are all inside the channel session. Nothing
  represents "there is an open task, owned by qm, for this person" at a level
  above the session, so no other session can consult it.
• Reading from the wrong session is not detectable at answer time. The DM
  turn had enough context to reconstruct events up to 23:15 — presumably from
  the earlier report or the directory — which made the gap invisible. Partial
  knowledge is more dangerous here than none, because it produced a plausible,
  detailed, wrong answer instead of "let me check."

This is the failure mode that matters most for the feature's premise. The pitch
for asking qm to chase someone is that the requester can stop tracking it. If
the answer to "did they reply?" depends on which conversation you happen to ask
in, the requester has to track that instead, which is worse than tracking the
original task.

Suggestions

The narrow fix: when a session is asked about work it does not own, it should
either resolve the owning session's current state or say it cannot see it.
Answering a question about a tracked commitment should never fall back to
inference from whatever context happens to be in the current session.

The broader one: an outstanding hand-off — qm asked X on behalf of Y, due at T,
unresolved — looks like it wants to be a durable record of its own, readable
from any session, rather than an emergent property of one thread's transcript.
That would also give the scheduled report something to reconcile against, and
would make "is this still open?" answerable without replaying a conversation.

Related: the reason qm never volunteered the answer once it arrived is a
separate defect in the ambient reply gate, filed as #607. They
compound — the first stops the update from being pushed, this one stops it from
being pulled — but they're independently fixable.

Happy to supply the full transcript, run rows and session records, or to test a
branch against a live deployment.

[yzxcj797]

Agreed with the framing — the failure isn't missing data, it's that the DM session had no way to know what it couldn't see, so a scoped-visibility gap rendered as a confident negative. Two structural observations from the code that narrow where a fix can land:

1. The mechanism is general, not task-specific. The channel session's entries (the 23:26 answer, qm's reaction) live under the channel scope; the DM session's context assembly has no path to them — by design, that's what scopes are for. So any fix that "shares" the entries would break the scope model. The tractable version is the reporter's own hedge suggestion generalized: when a session is asked about events in a different conversation it cannot read, the answer's epistemics should change, and the only component that can drive that is context assembly — the system prompt (or memory recall) can carry a cheap standing fact: tracked tasks exist whose transcripts live outside this session; a negative about another thread requires having read that thread's tail in this turn. That's a prompt-level contract, not a data-plumbing change, and it directly targets "checked-and-no vs cannot-see".

2. There's already a seam for the task-shaped half. The scheduled report at 23:15 fired from the channel session — the task's existence is durable even though its transcript isn't. If task records (title, owning session, last outcome) were recallable as memory-scope facts into other sessions, the DM answer would have had "a chase task exists, its thread is ch:C0BQ…, last recorded outcome: <scheduled-report result at 23:15>" — which is stale but honest, and the model would hedge against a 45-minute gap instead of asserting a negative. That's the memory-policy plumbing (#559's scope machinery is adjacent), not a cross-scope transcript grant.

The honest sequence I'd suggest to the maintainers: (1) is small and prevents the confident-negative failure class everywhere; (2) is the real fix for tracked tasks specifically but needs a decision about which task fields are cross-session-visible. Together they'd have turned the DM answer into "the chase ran and reported no reply as of 23:15; the thread may have moved since — I can't read it from here", which is the correct answer to have given.

Happy to implement (1) as a scoped prompt contract with regression tests if the maintainers want it; (2) I'd want their call on visibility first.