docs(governance): add roadmap merge gate to contributing and PR template

.github/pull_request_template.md

@@ -9,6 +9,19 @@
 
 Closes #
 
+## Roadmap alignment
+
+<!-- MERGE GATE. Every PR must advance a workstream in the roadmap
+     (PARTHA_Market_Fit_Product_&_Engineering_Roadmap.html) toward a §28
+     market-fit exit criterion, with accepted evidence. If this PR does not
+     move a §28 criterion, it is out of scope and should not be merged.
+     Breadth additions (new surfaces, new languages) that do not deepen the
+     existing moat need explicit owner justification in "Scope changes". -->
+
+- Roadmap §23 workstream this advances:
+- §28 market-fit criterion this moves toward:
+- Accepted evidence it is real (test/usage/repo state, not intent):
+
 ## What changed
 
 <!-- The main changes, by area (backend, frontend, docs, infra). -->
@@ -53,6 +66,7 @@ Closes #
 - [ ] The branch was created from an up-to-date `upstream/dev`
 - [ ] The branch is rebased on the latest `upstream/dev`
 - [ ] This PR addresses one clearly scoped issue
+- [ ] This PR advances a §23 workstream toward a §28 market-fit criterion (Roadmap alignment filled)
 - [ ] Every acceptance criterion I claim as complete is actually complete
 - [ ] Relevant tests pass
 - [ ] Documentation is updated for any user-visible change

CONTRIBUTING.md

@@ -8,6 +8,29 @@ PARTHA is a self-hosted Repository Intelligence Platform. One architectural rule
 
 Throughout this document, **must** and **must not** are requirements, **should** is a strong expectation, and **may** is permission.
 
+## 0. Strategy alignment (merge gate)
+
+PARTHA's direction is set by a single source of truth: the roadmap document
+`PARTHA_Market_Fit_Product_&_Engineering_Roadmap.html` (the local strategy file;
+ask the maintainer if you cannot see it). It defines the capability sequencing,
+gates, rejected paths (§27), and market-fit exit criteria (§28).
+
+A pull request is **in scope only if it advances one of the §23 workstreams
+toward a §28 market-fit exit criterion, with accepted evidence.** A "quick
+useful surface" or breadth addition that does not move a §28 criterion is
+**out of scope** and should not be proposed or merged. The encouraged default
+is to *deepen the existing moat* (versioned evidence, history and drift,
+governed team memory, workflow outcomes); new surfaces or languages are the
+discouraged direction and need explicit owner justification.
+
+You must fill the **Roadmap alignment** section of the pull request template
+on every pull request — naming the §23 workstream, the §28 criterion, and the
+accepted evidence. A pull request that cannot fill it is, by definition, out
+of scope and will be sent back.
+
+Editing the roadmap itself is a strategy-sensitive change reserved to the
+maintainer; do not treat roadmap content as something you may revise.
+
 ---
 
 ## 1. Setup