✨ - Automatically label issues by accumulated active duration #812

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

Add an automatically maintained duration-label family so issue lists show how long an issue has been active. Related feature: #810 (Project Start date / End date). This issue owns the active-time counter, label catalog, and periodic synchronization; it shares lifecycle timing with #810.

Label catalog

• <1 h for the first hour.
• 1 h, 2 h, ... 23 h.
• 1 d, 2 d, ... 30 d.
• 1 m, 2 m, ... 11 m (m means calendar month).
• 1 y, 2 y, 3 y, ... for completed calendar years. Provision reached year buckets on demand instead of attempting to create an infinite catalog.

Use a single space between the number and unit. Descriptions must explain the metric, unit, and bucket range; use a consistent visual family. Each tracked issue should have exactly one duration label after successful reconciliation. Replace the previous bucket rather than accumulating labels. Round down: 3 h 45 min displays 3 h; 24 hours displays 1 d. Select the largest completed unit.

Active-time semantics

Text flow: start -> count while open -> close and freeze -> reopen and resume -> close with the new accumulated total. This measures elapsed active lifetime, including waits, rather than person-hours. An issue that never started receives no duration label.

Acceptance criteria

• Maintain UTC timestamps with time-of-day precision and durable accumulated intervals. Date-only Project fields and existing labels are not authoritative timing sources.
• Match the catalog, rounding, one-label rule, and transitions above. Example: 3 h active -> 10 d closed -> 2 h active -> final label 5 h.
• Define deterministic UTC calendar-month/year thresholds for accumulated active time, including a documented calendar anchor, paused intervals, short months, end-of-month clamping, leap years, and the 30 d / 1 m boundary. Do not silently approximate a month as 30 days.
• Update on start, close, and reopen, and refresh active issues approximately hourly even without new issue activity. A delayed scheduled run computes the correct current bucket without replaying every missed bucket. Re-running a closed issue must not increase its duration.
• Duplicate/reordered events, repeated label callbacks, overlapping scheduled/event runs, and retries neither double-count intervals nor restore stale labels after a later transition. Re-read native state and verify final mutations.
• Provision labels idempotently; adopt compatible existing labels safely and report naming/ownership conflicts. Remove only managed duration labels, preserving all other labels and metadata.
• Track elapsed duration independently of successful Project membership/field writes. Share verified lifecycle timestamps with ✨ - Automatically track issue Start date and End date in GitHub Projects #810 while preserving the separate meaning of active accumulated duration and first-start/latest-end dates.
• Missing or ambiguous history is reported explicitly; never invent a start from issue creation time, run time, or date-only fields. Do not bulk backfill historical issues in this iteration.
• Permission errors, cancellation, provider failures, rate limits, and partial label changes preserve confirmed timing facts and allow bounded, idempotent recovery. Keep existing issue admission, deployment, and branch ownership rules intact.
• Duration maintenance makes no AI calls and posts no per-hour issue comments.

Current limitations or challenges

#810 captures lifecycle dates in GitHub Projects, but dates do not expose a duration badge in issue lists or provide hour-level precision. Calculating latest close minus first start also includes time spent closed after reopening. Event-only label updates become stale when an issue remains open without activity. Existing lifecycle/progress labels do not represent accumulated active duration.

Expected impact

Make active issue age and final elapsed duration visible and filterable directly in GitHub issue lists. Maintainers can spot work that has stayed active for hours, days, or months without opening each issue or computing timestamps. Closing preserves the final duration, while reopening resumes the same accumulated counter without counting the closed gap.

Alternatives considered

Manual duration labels become stale and require repeated edits. Project date fields remain useful and are covered by #810, but are insufficient for hourly badges and accumulated intervals. Several simultaneous hour/day/month labels add noise; use one current bucket. A broad estimated-size label measures a different property.

Version of copilot

Current development version

Additional context or comments

Scope and design decisions

Treat this as a feature request for the normal pre-branch SDD gate. Recommended rollout: explicit repository opt-in, initially disabled; fixed UTC timing and closed-gap exclusion; a bounded, paginated hourly scheduler with resumable processing and no broad read/model pipeline. A manual refresh/recovery route should use the same reconciliation. Define exact public input names, limits, permissions, year-label provisioning, scheduler ownership, concurrency, and missing-history recovery in the SDD before implementation. Calendar anchors for accumulated intervals require an explicit decision.

Persist versioned timing state durably; labels are a derived projection. Keep transition/bucket decisions in pure policy, orchestration in application use cases with narrow semantic ports, and GitHub/timestamp mapping and credentials in adapters/composition. Prevent forged issue-body markers or hand-edited labels from authorizing timing mutations. Check existing architecture/import/workflow contracts. Do not broaden the native-close route into branch management or a full AI runtime.

User and operator feedback

Keep the issue list badge simple (3 h). Descriptions and documentation explain m, rounding, closed gaps, and approximate refresh timing. Use existing localized Job Summaries with direct issue/run links and bounded counts: Pending: refreshing active issue durations; Complete: 12 updated, 38 unchanged; no action required; Skipped: duration tracking is disabled; Action required: start history is unavailable; review tracking state; Partial: timing retained; label update unverified; retry reconciliation. Use textual states and avoid repeated notifications.

Verification budget and deliverables

Proposed additional floor: 32 distinct cases: 10 bucket/calendar/rounding/configuration cases; 10 lifecycle/interval/replay/race cases; 6 label-adapter/provisioning/permission/partial-failure cases; 4 scheduler/pagination/migration/security integration cases; and 2 localized summary/link cases. Keep repository coverage/architecture gates and use deterministic clocks/provider fakes. Manually verify the issue-list label and start -> close -> reopen -> close flow, including a delayed refresh.

Update the managed issue lifecycle SDD and catalog evidence, setup/configuration and scheduling documentation, issue lifecycle/closure/reopening guides, and troubleshooting/rollout/rollback guidance. Disabling tracking stops future updates while retaining final labels and timing state; re-enabling must reconcile actual event history without charging closed time. Run required validators and regenerate catalog/Graphify artifacts when implementation changes them.

Reference: GitHub scheduled workflow behavior and possible delays. Related: #810.