PRs merged but issues not closed and roadmap not updated

[MScottAdams]

Problem

When PRs are merged, the associated GitHub issues are sometimes left open and ROADMAP.md is not updated to reflect completion. This was discovered during the 2026-04-03 roadmap refresh where 21 issues were found closed on GitHub but still listed as open in the roadmap, and 3 more (#104, #137, #145) were completed via merged PRs but never closed on GitHub at all.

Impact

• Roadmap drifts from reality — completed work still appears as open
• Stale issue count inflates perceived backlog
• Roadmap refresh passes become unnecessarily large cleanup exercises

Root Cause Investigation Needed

• Are PRs not using closing keywords (e.g. \Closes #N) in the PR body?
• Is GitHub's auto-close-on-merge not triggering for some reason (e.g. squash merge losing keywords, PR targeting wrong branch)?
• Is the ROADMAP.md update step missing from the merge/post-merge workflow?
• Is there a gap in AGENTS.md or the PR template checklist that should enforce this?

Acceptance Criteria

• Root cause identified and documented
• Fix applied (could be process, tooling, or both)
• PR template or review cycle skill updated if needed
• ROADMAP.md convention (update on merge) is enforceable, not just advisory

[MScottAdams]

Roadmap Refresh Analysis (2026-04-03)

Category: Process / workflow gap

Summary: When PRs are merged, associated issues are sometimes left open and ROADMAP.md isn't updated. Discovered during 2026-04-03 roadmap refresh: 21 stale roadmap entries, 3 issues (#104, #137, #145) completed but never closed on GitHub.

Relationship to existing issues:

• refactor: migrate project-scope behavioral rules to AGENTS.md/CONVENTIONS.md for platform-agnostic coverage #114 (Phase 2) — documenting global Warp rules and conventions; overlaps with codifying the merge checklist
• Change lifecycle gate skipped when user gives broad 'proceed' instruction on multi-file changes #123 (completed) — strengthened /deft:change gate and PR template; this is the post-merge counterpart
• Greptile: add review-cycle pre-flight check and recommended settings doc #166 (Phase 1) — Greptile re-review config; both address the PR lifecycle pipeline

Scope: Medium — root cause investigation (closing keywords, squash merge behavior, ROADMAP convention), then PR template + AGENTS.md + review cycle skill updates

Recommendation: Phase 1 Cleanup — process bug that causes roadmap drift on every merge; compounds over time

[MScottAdams]

Root Cause Finding: Spec tasks added as [pending] in the same PR that implements them

Discovery: During the 2026-04-03 roadmap refresh, 5 spec tasks were found still marked [pending] despite their issues being closed and work merged:

• t1.3.1 (directive/run bootstrap goes in a loop #91/bug(run): strategy selection infinite loop when strategies/ directory is empty or unresolvable #92) — added in PR fix(cli): resolve command chaining loop and strategy selection hang (#92, #117) #120, which also fixed the bug
• t1.6.1 (Warp not always enforcing Deft testing protocols #68), t1.6.2 (Change lifecycle gate skipped when user gives broad 'proceed' instruction on multi-file changes #123), t1.6.3 (Branching requirement is too prescriptive for single-author projects #138), t1.6.4 (Agent skips vbrief source step and writes SPECIFICATION.md directly #139) — all added in commit aa0602f, which also implemented all 4 fixes

Pattern: When an agent PR both adds spec tasks to SPECIFICATION.md AND implements the work in the same commit, the tasks are written as [pending] to satisfy the 'SPECIFICATION.md has task coverage' prerequisite, but never flipped to [completed] before merge. The agent treats 'add task' as sufficient and forgets the status update.

This is the same class of problem as the issue/roadmap disconnect — post-merge housekeeping is missing.

Proposed fix locations:

1. deft-review-cycle Phase 1 audit — add a check: scan SPECIFICATION.md for [pending] tasks whose acceptance criteria are satisfied by the PR diff; flag them for status flip before merge
2. deft-build skill — add a pre-commit rule: if you added a spec task and implemented it in the same branch, the task MUST be [completed] before committing
3. AGENTS.md Development Process — add to 'Before committing': verify any spec tasks touched in this branch have correct status