Pinet/RALPH task tracker reports stale cross-repo/read-only work as no commits/no PR

[tmustier]

Summary

RALPH/Pinet worker-status reporting can surface stale or misleading task rows such as #123 → no commits, no PR ⚠️ after the underlying work is already merged, closed, or was never implementation work in the first place.

This creates false-positive broker action: the broker may spin up fresh workers for already-complete or intentionally read-only work.

Observed behavior

During a RALPH cycle, the worker-status feed reported multiple old assignments as needing attention. RCA showed three distinct tracker failure modes:

1. Cross-repo issue-number collision

   • task_assignments stores only issue_number, not repo / owner / repo root.
   • resolveTaskAssignments(...) resolves issue/PR state from process.cwd().
   • If a handoff was for another repo, the tracker checks the wrong GitHub repository and can keep reporting no commits, no PR.

2. Read-only / QA / merge-only handoffs parsed as implementation assignments

   • Broker messages like “review PR #N against issue #M”, “merge PR #N”, or “do not mutate files” still get parsed by extractTaskAssignmentsFromMessage(...) as tracked implementation work.
   • The status formatter then describes them as missing commits/PRs even though commits/PRs are explicitly not expected.

3. Terminal rows remain noisy

   • Merged/completed assignments can remain visible in the worker-status report instead of being archived/suppressed after terminal acknowledgement.

Why this matters

The broker uses RALPH status as an operational signal. A misleading no commits, no PR row can cause unnecessary reassignment, duplicate workers, and confusion around already-merged/closed tasks.

Likely affected code

• slack-bridge/task-assignments.ts
  • assignment parsing
  • status resolution
  • report formatting
• slack-bridge/ralph-loop.ts
  • resolving/reporting tracked assignments
• broker-core/schema.ts
  • task_assignments schema currently lacks repo/task-kind fields

Expected behavior

Worker-status reporting should distinguish implementation work from review/QA/merge/interactive work, and should resolve GitHub state against the correct repository.

Suggested acceptance criteria:

• task_assignments records repo identity, e.g. repo_owner, repo_name, and/or repo_root captured at delegation time.
• Assignment parsing captures task kind or intent, at least: implementation, review, qa, merge, interactive, unknown.
• Read-only/QA/merge-only assignments are not formatted as no commits, no PR.
• Closed/merged terminal rows are suppressed or aged out from the recurring RALPH worker-status feed.
• interactive-session/human-gated issues are not auto-routed as implementation work without explicit new maintainer approval.
• Cross-repo issue-number collisions are covered by tests.
• Existing DB rows migrate safely, defaulting old rows to repo_unknown / kind_unknown rather than silently resolving in the wrong cwd.

Notes

Sanitized RCA came from a real broker incident. The important reproducible detail is structural: the tracker had stale rows keyed only by issue number and resolved them from the current broker cwd, while source messages referred to different repos and/or read-only work.