✨ - Automatically track issue Start date and End date in GitHub Projects #810

Is there an existing issue or feature request for this?

• I have searched the existing issues and feature requests.

What area does this improvement affect?

New Feature

What actions does this improvement affect?

Issue

Description of the idea or improvement

Automatically maintain the actual work dates of an issue in its configured GitHub Projects. Start tracking when an authorized maintainer applies in-progress, including time spent in the SDD gate, rather than waiting for branch readiness. Record the end date when the issue is natively closed, whether manually or through a merged linked PR.

Proposed behavior

The table describes one work interval: start -> close -> reopen -> close again. Reopening retains the first start and removes the obsolete end until work closes again. Dates use YYYY-MM-DD in UTC; they do not include a time of day.

Acceptance criteria

• Applying in-progress to an eligible issue with an empty Start date writes the event's date, independently of SDD completion or branch creation.
• Existing Start date values survive label removal/reapplication, unrelated edits, duplicate deliveries, and workflow retries.
• Both manual closure and merge-driven native closure set End date from the verified current closure timestamp, rather than the workflow execution date. Closure reasons remain distinguishable; an end date alone must not imply successful completion.
• Reopening clears End date while retaining Start date; closing again records the new closure date.
• Closing an issue that never started does not fabricate Start date.
• Duplicate, delayed, or out-of-order events cannot overwrite the current lifecycle's dates. Re-read native issue identity/state before writing and verify the resulting Project values.
• Synchronize each configured Project independently. Partial failures retain successful writes, identify the affected Project, and provide a safe retry without resetting dates.
• Missing fields, incompatible field types, inaccessible Projects, or insufficient permissions produce actionable diagnostics without creating duplicate items or damaging other metadata.
• Existing issue admission, branch ownership, completion, and deployment rules remain in force.

Current limitations or challenges

Copilot already handles issue label, closed, and reopened events and updates Project Status/single-select fields, but it does not currently synchronize date fields. Maintainers must enter dates manually, which leaves incomplete timelines and makes elapsed-work reporting unreliable. Using the workflow run date would also produce incorrect results when an event is delayed or retried.

Expected impact

Keep actual work timelines up to date without manual maintenance. For example, an issue started on 2026-10-30 and closed on 2026-11-02 should show those dates even if synchronization is retried later. If reopened, it retains the original start and has no end until it closes again. This supports Project roadmap views and cycle-time reporting.

Alternatives considered

Manual entry requires repeated maintenance. A separate GitHub Actions workflow could update dates, but would duplicate lifecycle, permission, and replay handling already owned by Copilot. Extend the existing lifecycle and Project adapters instead.

Version of copilot

Current development version

Additional context or comments

Implementation scope and configuration

This is a feature request, not an implementation-ready SDD. During the normal pre-branch SDD gate, define opt-in date tracking and the bounded field mapping contract. Recommended defaults are existing Date fields named Start date and End date, disabled until explicitly configured so planned dates are not silently repurposed. An alternative should allow explicit names for actual-start/actual-end fields. Validate distinct fields and their Date types; do not create fields or backfill historical issues automatically in this iteration. Preserve original event timestamps across retries.

Keep date decisions in pure policy, lifecycle coordination in application use cases with narrow semantic ports, and GraphQL/credentials in provider adapters. The native-close route currently has intentionally limited mutation capabilities: extend them explicitly for dates, without granting branch, close/reopen, or comment-creation authority. No AI call should be needed for date synchronization.

User and operator feedback

Use existing localized Job Summaries with direct issue/Project links and no new per-event issue comments. Representative states: Pending: synchronizing issue dates; Complete: Start date recorded; no action required; Skipped: date tracking is disabled; Action required: End date field is missing; configure a Date field and retry; Partial: one Project updated; another could not be verified; successful dates were retained. A reopen during synchronization must stop stale closure writes.

Verification and documentation

Proposed additional test floor: 24 distinct cases: 6 policy/configuration/date-boundary cases; 8 lifecycle/replay/reopen/race cases; 5 adapter/field/permission/partial-failure cases; 3 entrypoint/integration/compatibility cases; and 2 localized summary/link cases. Keep existing coverage and architecture gates, use deterministic clocks and provider fakes, and capture one manual Project-table acceptance showing start, close, reopen, and reclose.

Update specs/managed-issue-and-branch-lifecycle.md, affected catalog evidence, user date-tracking/configuration documentation, and docs/issues/notifications-and-auto-close.mdx together with implementation. Define rollout/recovery and clarify that disabling tracking stops future writes while retaining recorded dates. Run the repository's required checks, specification validation/catalog generation when applicable, and Graphify update after code changes.

Evidence: .github/workflows/copilot_issue.yml, src/data/repository/project/project_board_field_update.ts, and the managed-issue-lifecycle capability in specs/catalog.json.

GitHub reference: Using the API to manage Projects.