Follow-up from the issue-reconcile CoS task shipped in #2242 (design record: docs/plans/2026-07-06-issue-reconcile.md).
The v1 deterministic zombie scan in server/services/issueReconcile.js is GitHub-only — it resolves the repo via getOriginInfo().isGithub and queries gh issue/pr list, returning null (park/skip) on any non-GitHub remote. So enabling issue-reconcile on a GitLab- or JIRA-tracked app is currently a no-op.
Task: add tracker siblings so the zombie-heal covers every forge the claim flow already supports:
- GitLab — mirror the scan over
glab (open + in-progress-labeled issues; merged MRs referencing them by Refs #<iid> / source branch claim/issue-<iid>; live-claim guard over local/remote/CoS refs, same for-each-ref scan). The coordinator prompt already has GitLab-flavored hybrid mechanics in claim-issue-gitlab to draw from.
- JIRA — the "zombie" analog is a ticket left In Review (or Done) with remaining scope and no live claim. Detect via the PortOS JIRA API (
my-sprint-tickets + ticket status + linked MR/PR), and heal by recording remaining scope + filing a follow-up ticket (POST /api/jira/instances/:id/tickets) — JIRA has no in-progress label to release, so the mechanic differs (status-based, not label-based).
Routing: decide whether issue-reconcile should resolve the app's tracker (like the claim-work router: plan/github/gitlab/jira) and delegate to a per-tracker scan + coordinator prompt, or stay three separate task types. The claim-work → claim-issue{,-gitlab,-jira} router in cosTaskGenerator.js is the precedent.
Keep the pure-classifier + convergence-signature shape from issueReconcile.js (classifyIssue / zombieSignature) so each tracker sibling stays unit-testable without live API calls.
Follow-up from the
issue-reconcileCoS task shipped in #2242 (design record:docs/plans/2026-07-06-issue-reconcile.md).The v1 deterministic zombie scan in
server/services/issueReconcile.jsis GitHub-only — it resolves the repo viagetOriginInfo().isGithuband queriesgh issue/pr list, returningnull(park/skip) on any non-GitHub remote. So enablingissue-reconcileon a GitLab- or JIRA-tracked app is currently a no-op.Task: add tracker siblings so the zombie-heal covers every forge the claim flow already supports:
glab(open +in-progress-labeled issues; merged MRs referencing them byRefs #<iid>/ source branchclaim/issue-<iid>; live-claim guard over local/remote/CoS refs, samefor-each-refscan). The coordinator prompt already has GitLab-flavored hybrid mechanics inclaim-issue-gitlabto draw from.my-sprint-tickets+ ticket status + linked MR/PR), and heal by recording remaining scope + filing a follow-up ticket (POST /api/jira/instances/:id/tickets) — JIRA has noin-progresslabel to release, so the mechanic differs (status-based, not label-based).Routing: decide whether
issue-reconcileshould resolve the app's tracker (like theclaim-workrouter: plan/github/gitlab/jira) and delegate to a per-tracker scan + coordinator prompt, or stay three separate task types. Theclaim-work→claim-issue{,-gitlab,-jira}router incosTaskGenerator.jsis the precedent.Keep the pure-classifier + convergence-signature shape from
issueReconcile.js(classifyIssue/zombieSignature) so each tracker sibling stays unit-testable without live API calls.