This issue is staged for the repository's GitHub tracker cutover. Existing task instructions remain authoritative until the verified handoff.
What
Decide whether to adopt two specific, unadopted design ideas surfaced by comparing this project's own task lifecycle against mco-org/squad, an MIT-licensed CLI-based multi-agent coordination tool: a human-facing presentation of already-detected orphaned tasks, and roles or teams defined as overridable files rather than a fixed enum.
Why
A comparison against that tool found this project's own task lifecycle to already be ahead of it in the area most likely to have been behind: task-state granularity and stale-lease handling. The comparison's one initially promising suggestion, an "orphan task report," turned out on closer inspection to already be mostly built: this project already detects and reaps tasks whose target session has died, and deliberately excludes a task awaiting review from that reaping because the reviewer, not the original target, is the pending actor at that point. What remains genuinely unadopted is only the human-facing presentation of that existing detection, not the detection itself. Separately, that tool's approach to roles and teams, plain files with a fallback to a small built-in set, rather than a fixed set of options requiring a code change to extend, is a genuinely unadopted idea with no current equivalent here.
Scope
This is a decision record, not an implementation. In scope: deciding whether either idea is worth building, scoped correctly against what already exists (the presentation, not the detection, for the first one). Out of scope until decided: any code change.
Done when
A decision is recorded on each of the two ideas separately: build (with a corrected scope statement for the first), decline, or defer with a stated reason.
Validation
Review each decision against this project's own existing orphan-detection mechanism and its actual test coverage, the realistic cost of a files-based roles/teams system versus the current fixed set, and whether either benefit justifies the added surface.
Dependencies and decisions
The first idea's scope must be read against this project's own existing orphan-detection mechanism before any implementation decision, or it will be built to solve a problem that is already solved.
Links
The publicly available mco-org/squad repository this comparison was made against. src-tauri/src/mcp.rs:1693 (reconcile_abandoned, this project's own existing orphan-detection mechanism).
This issue is staged for the repository's GitHub tracker cutover. Existing task instructions remain authoritative until the verified handoff.
What
Decide whether to adopt two specific, unadopted design ideas surfaced by comparing this project's own task lifecycle against
mco-org/squad, an MIT-licensed CLI-based multi-agent coordination tool: a human-facing presentation of already-detected orphaned tasks, and roles or teams defined as overridable files rather than a fixed enum.Why
A comparison against that tool found this project's own task lifecycle to already be ahead of it in the area most likely to have been behind: task-state granularity and stale-lease handling. The comparison's one initially promising suggestion, an "orphan task report," turned out on closer inspection to already be mostly built: this project already detects and reaps tasks whose target session has died, and deliberately excludes a task awaiting review from that reaping because the reviewer, not the original target, is the pending actor at that point. What remains genuinely unadopted is only the human-facing presentation of that existing detection, not the detection itself. Separately, that tool's approach to roles and teams, plain files with a fallback to a small built-in set, rather than a fixed set of options requiring a code change to extend, is a genuinely unadopted idea with no current equivalent here.
Scope
This is a decision record, not an implementation. In scope: deciding whether either idea is worth building, scoped correctly against what already exists (the presentation, not the detection, for the first one). Out of scope until decided: any code change.
Done when
A decision is recorded on each of the two ideas separately: build (with a corrected scope statement for the first), decline, or defer with a stated reason.
Validation
Review each decision against this project's own existing orphan-detection mechanism and its actual test coverage, the realistic cost of a files-based roles/teams system versus the current fixed set, and whether either benefit justifies the added surface.
Dependencies and decisions
The first idea's scope must be read against this project's own existing orphan-detection mechanism before any implementation decision, or it will be built to solve a problem that is already solved.
Links
The publicly available
mco-org/squadrepository this comparison was made against.src-tauri/src/mcp.rs:1693(reconcile_abandoned, this project's own existing orphan-detection mechanism).