feat(docs): define inactivity closure policies for issues and PRs

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 title: Contributing
 description: Guidelines for contributing code, documentation, and improvements to the HVE Core project
 author: HVE Core Team
-ms.date: 2025-11-05
+ms.date: 2026-02-07
 ms.topic: guide
 keywords:
   - contributing
@@ -60,6 +60,10 @@ We strongly recommend using the provided DevContainer, which comes pre-configure
   - [Suggesting Enhancements](#suggesting-enhancements)
   - [Your First Code Contribution](#your-first-code-contribution)
   - [Improving The Documentation](#improving-the-documentation)
+- [Pull Request Inactivity Policy](#pull-request-inactivity-policy)
+  - [Active Pull Requests](#active-pull-requests)
+  - [Draft Pull Requests](#draft-pull-requests)
+  - [Exemptions](#exemptions)
 - [Style Guides](#style-guides)
   - [Local Development Setup](#local-development-setup)
   - [Coding Conventions](#coding-conventions)
@@ -171,6 +175,45 @@ This project also includes a Dev Container for development work, and using that
 
 If you see issues with the documentation, please follow the [your first code contribution](#your-first-code-contribution) guidance.
 
+## Pull Request Inactivity Policy
+
+Pull requests that remain inactive accumulate merge conflicts and delay feedback loops. This section defines closure timelines for inactive PRs. Automation that enforces this policy is a separate effort that references these thresholds.
+
+For issue and discussion inactivity policy, see [Inactivity Closure Policy](./GOVERNANCE.md#inactivity-closure-policy) in GOVERNANCE.md.
+
+### Active Pull Requests
+
+The inactivity clock runs only when the PR is waiting on the author. Reviewer-side delays do not count against the author.
+
+| Stage  | Trigger                                                           | Label                 | Action                  |
+|:-------|:------------------------------------------------------------------|:----------------------|:------------------------|
+| Active | Author activity within the past 14 days while `waiting-on-author` | (none)                | Normal review cycle     |
+| Paused | PR is labeled `waiting-on-reviewer`                               | `waiting-on-reviewer` | Inactivity clock paused |
+| Stale  | 14 days without author activity while `waiting-on-author`         | `stale`               | Reminder comment posted |
+| Closed | 7 days after `stale` label without author activity                | `closed-stale`        | PR closed with summary  |
+
+Label usage:
+
+- `waiting-on-author` is applied when the reviewer requests changes or the author needs to resolve conflicts. The inactivity clock starts.
+- `waiting-on-reviewer` is applied when the author has addressed feedback and awaits re-review. The inactivity clock pauses.
+
+### Draft Pull Requests
+
+Draft PRs are fully exempt from inactivity closure. Converting a draft to "ready for review" starts the normal active PR lifecycle.
+
+### Exemptions
+
+The following conditions prevent automatic closure of a pull request:
+
+- PR is in draft state
+- PR is labeled `do-not-close`
+- PR is labeled `waiting-on-reviewer`
+
+Reopening rules:
+
+- Authors can reopen a stale-closed PR at any time with updated changes
+- Reopening removes the `stale` label and resets the inactivity clock
+
 ## Style Guides
 
 This project uses automated linters to ensure code quality and consistency. These linters can be run locally using the npm scripts described in the [Build and Validation Requirements](#build-and-validation-requirements) section.

GOVERNANCE.md

@@ -2,7 +2,7 @@
 title: Governance
 description: Project governance model, roles, decision-making processes, and contribution authority for HVE Core
 author: HVE Core Team
-ms.date: 2026-01-21
+ms.date: 2026-02-07
 ms.topic: reference
 keywords:
   - governance
@@ -154,6 +154,36 @@ When contributors disagree on technical or process matters:
 
 Code of conduct violations follow the process defined in [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md).
 
+## Inactivity Closure Policy
+
+Open issues and discussions that remain inactive create noise for contributors and maintainers. This section defines the lifecycle policy for closing inactive items. Automation that enforces this policy (stale bot, scheduled workflows) is a separate effort that references these thresholds.
+
+For pull request inactivity policy, see [Pull Request Inactivity Policy](./CONTRIBUTING.md#pull-request-inactivity-policy) in CONTRIBUTING.md.
+
+### Issues
+
+Issue inactivity follows a three-stage lifecycle:
+
+| Stage        | Trigger                                      | Label          | Action                        |
+|:-------------|:---------------------------------------------|:---------------|:------------------------------|
+| Active       | Any activity within the past 60 days         | (none)         | Normal lifecycle              |
+| Stale        | 60 days without activity                     | `stale`        | Warning comment posted        |
+| Closed-stale | 14 days after `stale` label without activity | `closed-stale` | Issue closed as `not_planned` |
+
+Exemptions that prevent automatic closure:
+
+* Issues labeled `pinned`, `security`, or `do-not-close`
+* Issues assigned to any milestone
+
+Reopening rules:
+
+* Any participant can reopen a stale-closed issue with additional context
+* Reopening removes the `stale` label and resets the inactivity clock
+
+### Discussions
+
+The same 60-day warning and 14-day closure thresholds apply to GitHub Discussions in principle. The same exemptions that prevent automatic closure for issues (pinned, security, do-not-close, or assigned to a milestone) and the same reopening behavior (reopening clears any stale status and resets the inactivity clock) apply to Discussions. Because current automation tooling (actions/stale) does not support Discussions, enforcement is manual through periodic triage until dedicated tooling is implemented.
+
 ## Access Continuity
 
 Project continuity is ensured through Microsoft stewardship: