feat(tasks): add explicit collaborators, dependencies and scoped execution context #621

Problem and authorization

The requester explicitly asks to develop phase three and open an Issue and PR. Phase one (#617/#618) added relay handoff snapshots; phase 2a (#619/#620) added versioned project task briefings. The remaining phase-three gap is explicit collaborators/responsibilities and task relationships, including relevant state and delivery evidence.

Scope

Project goal work items are the existing executable task spine. Add bounded explicit participants (contributor/reviewer plus responsibility) and same-project predecessor task IDs. Support fan-in from parallel upstream tasks and direct downstream references, without silently treating a job title as task responsibility. Use existing sessions, human acceptance, goal state/events and task-briefing persistence. This is not the employee-review dispatch from phase 2b, a new task store, cross-task memory, automatic scheduling or a live agent chat room (#452).

Acceptance criteria

• Edit participants/responsibilities and dependencies in the project task drawer. Validate exact fields, existing employees, bounded lists, duplicates, self/missing references and cycles; prevent deleting a still-referenced task without explicitly editing dependencies.
• Project/task views show collaborators, direct upstream readiness and source references, and direct downstream tasks. Independent tasks have empty relationships. Scope projections to the current project, task and declared relations.
• Before bound task execution, refresh authoritative upstream state. A mere completed turn is not accepted work: executed predecessors require a current human acceptance of the latest eligible delivery; a manual task can be ready through an explicitly recorded manual done state. Missing/unavailable evidence blocks execution.
• Preserve optional legacy records; configured collaboration tasks cannot bypass dependency checks by omitting the new briefing request. No automatic dispatch of additional participants, permission/budget transfer or implicit approval.
• Inject and persist the same bounded collaboration context in the task briefing, with explicit roles, source identities, completion/delivery digest references and filtered public excerpts. Preserve unified budgets; reject oversize required context rather than silently losing responsibilities.
• Refresh current UI through existing goal/turn events, reconnection and explicit refresh. Execution snapshots remain fixed; later executions/retries/approval resumes revalidate their bindings and dependency readiness. No invisible mutation of an in-flight model's input.
• Human acceptance can inspect the execution-time collaboration snapshot; current project state remains separately projected. Historical snapshots without collaboration remain readable.

Implementation and dependencies

Stack on #620 until the first two PRs merge. Shared goal/collaboration contracts and graph validation; bounded server projection with acceptance checks; execution/briefing storage validation; task editor and relation views; packaging, localization, design and changelog updates.

Validation

Contract/DAG and readiness tests; API round trips, isolation and bypass prevention; controlled-driver snapshot equality, upstream failure/new-attempt handling, restart/retry and budgets; IPC/renderer regressions; real local control-plane browser flow at desktop and narrow widths; repository checks and truthful CI/limitations ledger. No invented coverage or live-provider quality claims.

Risks and rollback

New optional work-item and briefing fields require matching current readers. Deploy server/IPC/renderer together, retain workspace backups for downgrades and do not erase historical evidence. Dependency references share only task-bound public delivery material, not unrelated personal history or resource grants. Revert code and use pre-upgrade/separate workspace data if reverting to older strict readers.