* fix(mcp): provide bounded access to CREATED sibling task descriptions
Include the task description in the list_related_tasks_kandev projection so a
coordinating agent can read dependency metadata (e.g. a "Depends on:" line)
from a related task — including a CREATED sibling that has no session yet —
without falling back to an unbounded list_tasks_kandev call.
The relation graph is the bound: only parent/children/siblings/blockers are
ever projected, so descriptions never leak from unrelated tasks or across
workspaces. ListSiblings already returns CREATED (unstarted) tasks and loads
their descriptions from storage; only the MCP projection was dropping the
field.
Closes#1772
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(mcp): gate related-task descriptions by caller access
Address PR review: list_related_tasks_kandev ignored caller_task_id and
projected any named task's description, so a caller that learned an unrelated
or cross-workspace task ID could read it. Add ListRelatedForCaller, which
enforces the same relation/workspace read guard the document tools use
(self/ancestor/descendant/sibling/blocker, same workspace) for non-self
targets, and wire the MCP handler through it (access-denied maps to forbidden).
The un-gated ListRelated stays for trusted internal callers (GetTaskContext).
Add tests for the blocker/blocked-by description projection and the caller
access guard (unrelated + cross-workspace denied, relations allowed).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor(mcp): align related-tasks error mapping and empty-caller guard
Address PR review nits: route handleListRelatedTasks errors through
mapHandoffError (logging only non-access-denied errors) for parity with the
document handlers, and make ListRelatedForCaller deny an empty caller against a
non-self target instead of silently delegating to the ungated ListRelated.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Kandev Agent <agent@kandev.dev>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
João Salavisa
9b7fa0ec9c