chore: simplify PR intake to a light-touch model

.github/pull_request_template.md

@@ -1,47 +1,19 @@
-## Linked issue
-
-- Closes #
-- Related #
-
-## Existing related work reviewed
-
-- Issues/PRs reviewed:
-- If none found, write: None found after search
-
-## Overlap assessment
-
-- Classification:
-- Overlapping items:
-- Why this is not duplicate/superseded:
-
-## Why this PR should proceed
-
-- 
-
 ## Summary
 
 - What changed:
 - Why:
 
-## Validation
-
-- [ ] Tests added/updated (or not applicable)
-- [ ] Validation steps documented
-- [ ] Evidence attached (logs/screenshots/output as relevant)
-
-## Documentation
+## Linked issue (if applicable)
 
-- [ ] Docs updated in this PR (or not applicable)
-- [ ] Any setup/workflow changes reflected in repo docs
+- Closes #
 
-## Scope check
+## Validation
 
-- [ ] No unrelated refactors
-- [ ] Implemented from a feature branch
-- [ ] Change is deliverable without upstream `OSeMOSYS/MUIO` dependency
-- [ ] Base repo/branch is `EAPD-DRB/MUIOGO:main` (not upstream)
+- [ ] Tests added/updated (or not applicable)
+- [ ] Manual verification steps documented, with evidence where relevant
 
-## Exception rationale
+## Checklist
 
-- Only for narrow docs/typo PRs that do not use a linked issue.
-- Leave blank otherwise.
+- [ ] Change is scoped — no unrelated refactors
+- [ ] Branched from `main`; PR targets `EAPD-DRB/MUIOGO:main`
+- [ ] Docs updated for any setup, workflow, or architecture change

CONTRIBUTING.md

@@ -7,9 +7,8 @@ Thanks for contributing.
 1. Read `README.md`, `docs/GSoC-2026.md`, `SUPPORT.md`, `docs/ARCHITECTURE.md`, and `docs/DOCS_POLICY.md`
 2. Search existing issues and PRs before proposing implementation work
 3. Create or reuse an issue before starting implementation work
-4. Fill in the issue's required related-work fields so overlap is explicit
-5. Create a feature branch from `main`
-6. Confirm acceptance criteria in the issue so review can be objective
+4. Create a feature branch from `main`
+5. Confirm acceptance criteria in the issue so review can be objective
 
 ## Scope and repository boundaries
 
@@ -33,36 +32,13 @@ Current tracks:
 - `Track: Integration`
 - `Track: Stability`
 
-## Intake requirements
+## Issues and PRs
 
-Most implementation work must start from an issue.
-
-The issue must document:
-- `Related issues reviewed`
-- `Related PRs reviewed`
-- `Overlap classification`
-- `Why this issue is still needed`
-- `Proposed track`
-
-If you found no relevant existing work, write `None found after search`.
-
-If overlapping work exists, explain why your issue is still needed and classify the overlap as one of:
-- `none`
-- `duplicate`
-- `alternative approach`
-- `complementary follow-up`
-- `narrower fix`
-- `superseding`
-
-If no overlap exists, a short current justification is enough.
-
-PRs should document:
-- linked issue
-- related work reviewed
-- overlap assessment
-- why the PR should proceed
-
-The `pr-intake` workflow is advisory. If required structure is missing, it may apply the `needs-intake-fix` label so maintainers can follow up.
+- Search existing issues and PRs first so we avoid duplicate work.
+- For anything beyond a small fix, open an issue before implementation so scope and acceptance criteria are clear.
+- Link the issue from your PR (`Closes #123`).
+- Keep each PR scoped to one issue, or a tightly related set.
+- If you find related work, link it so any overlap is visible — a quick reference is enough.
 
 ## Workflow
 
@@ -103,23 +79,7 @@ Post updates when one of these events occurs:
 - No unrelated refactors in the same PR
 - PR target is `EAPD-DRB/MUIOGO:main` (not upstream `OSeMOSYS/MUIO`)
 
-### Narrow docs and typo exception
-
-For small docs or typo-only PRs, a linked issue may be skipped if the PR qualifies for the docs/typo exception.
-
-This exception is narrow. It does not cover:
-- workflows
-- issue or PR templates
-- governance or policy files
-- `CONTRIBUTING.md`
-
-Use the `Exception rationale` section in the PR template when claiming this exception.
-
-Docs-only PRs may still use a linked issue instead of the exception path.
-
-## Transition note
-
-Existing open PRs and older linked issues from before the intake rollout are transitional and may be handled manually while the new intake guidance is phased in.
+Small docs or typo-only PRs do not need a linked issue.
 
 ## Definition of done
 

docs/MAINTAINER_TRIAGE.md

@@ -1,55 +1,17 @@
 # Maintainer Triage Guide
 
-This document defines the contribution-intake workflow introduced for issue-first, overlap-aware implementation work.
+This document defines the triage vocabulary used on the project board — priorities, tracks, and stability lanes. These are maintainer-assigned metadata to organize work; they are not gates on contribution.
 
-## Purpose
+## Priorities
 
-The intake system exists to reduce duplicate work, clarify scope before code is written, and keep review attention on the highest-signal items.
+- `Priority: High` — work on ASAP
+- `Priority: Medium` — important
+- `Priority: Low` — may matter, can wait
 
-Automation checks structure only:
-- linked issue exists
-- required issue sections are present
-- required PR sections are present
-
-If structure is missing, automation may apply the `needs-intake-fix` label to the PR.
-
-Maintainers still decide whether the proposal is correct, useful, or merge-ready.
-
-## What to review on new implementation issues
-
-Confirm that the issue documents:
-- `Related issues reviewed`
-- `Related PRs reviewed`
-- `Overlap classification`
-- `Why this issue is still needed`
-- `Proposed track`
-
-If related-work sections are weak but present, request clarification rather than bypassing the structure.
-
-If the issue is clearly duplicate or superseded, close or consolidate it rather than carrying parallel implementation work.
-
-## Overlap classifications
-
-Use these overlap terms consistently:
-- `none`: no relevant overlapping work found
-- `duplicate`: same problem and same intended fix as an existing issue or PR
-- `alternative approach`: same problem, materially different solution path
-- `complementary follow-up`: separate work that depends on or extends existing work
-- `narrower fix`: intentionally smaller or more targeted than a broader open item
-- `superseding`: intended to replace an older issue or PR as the canonical path
-
-## Handling overlap
-
-- Duplicate: point contributors to the canonical issue or PR and close the duplicate
-- Alternative approach: keep only if there is a real design choice to evaluate
-- Complementary follow-up: keep separate, but explicitly link the dependency chain
-- Narrower fix: allow if the narrower path is more actionable than the broader one
-- Superseding: make the replacement explicit in comments and close the older item when appropriate
+Priority labels sync to the board's `Priority` field automatically (see `.github/workflows/sync-project-priority-from-labels.yml`).
 
 ## Tracks
 
-Tracks are maintainer-assigned triage metadata.
-
 - `Track: Cross-Platform`
   Cross-platform install, startup, path, and runtime compatibility work
 
@@ -64,7 +26,7 @@ Tracks are maintainer-assigned triage metadata.
 
 ## Stability lanes
 
-For now, Stability lanes are an internal triage vocabulary only.
+Internal triage vocabulary for Stability-track work.
 
 - `Safety Guardrails`
   Narrow fixes that make the current synchronous design safer without redesigning execution flow
@@ -75,11 +37,6 @@ For now, Stability lanes are an internal triage vocabulary only.
 - `Supporting Infrastructure`
   Run identity, atomic status tracking, shared metadata safety, and run-level observability work
 
-## Transitional policy
-
-Open PRs that predate the intake rollout are transitional:
-- the new `pr-intake` workflow may run on them
-- maintainers may clean them up manually
-- they are not retroactively required to match the new structure before the rollout is complete
+## Handling duplicates and overlap
 
-Once the queue is cleaned up, new or substantially updated PRs should follow the full intake format. The intake workflow is advisory and does not replace maintainer judgment.
+If an issue or PR clearly duplicates or supersedes existing work, consolidate rather than carrying parallel work: point to the canonical item and close the duplicate, or link the dependency explicitly. Maintainers decide whether a proposal is correct, useful, or merge-ready.