docs(phase-6): add scope alignment review and implementation scope gates

Add scope-alignment-review-notes.md documenting the review of all 8 research
plans against jahow's actual PR #136 acceptance requirements. The review
confirms research scope is appropriate (broad research informs good design
choices) while adding implementation scope gates to prevent research findings
from expanding work beyond jahow's requirements.

Changes:
- New: scope-alignment-review-notes.md (two-part assessment)
- Plan 06: Added 'Implementation Scope Gate' section and success criterion
- Plan 08: Added 'Implementation Scope Gate' section and success criterion
- research-strategy.md: Added 'Implementation Scope Principle' section

Key principle: Research broadly, implement minimally.

Author: Sam-Bolling

docs/research/phase-6/research-plans/06-endpoint-decoupling-architecture.md

@@ -64,6 +64,24 @@ This is the critical synthesis plan. It cannot begin until Plans 02–05 are com
 4. **One-way dependency (Constraint 4):** After refactoring, removing the entire `src/ogc-api/csapi/` directory must leave core fully functional — zero type errors, zero test failures, zero import resolution errors. This is the litmus test for every design choice.
 5. **CI compliance:** Prettier, TypeScript typecheck, ESLint, browser tests, and Node.js tests must all pass.
 
+### Implementation Scope Gate
+
+> **Research broadly, implement minimally.**
+>
+> Plans 04 and 05 provide industry best practices and architectural theory to *inform* design decisions. However, every design decision produced by this plan must pass the **minimum-change test:**
+>
+> **"Does this change directly serve jahow's two requirements (CSAPI out of root index.ts, non-CSAPI code stops importing CSAPI), or are we adding work he didn't request?"**
+>
+> If a design choice is informed by industry best practice but increases the implementation scope beyond what jahow requires, prefer the simpler approach that still satisfies all boundary conditions. Use the industry research to *validate* that the simpler approach is sound — not to justify a more complex one.
+>
+> Specifically:
+> - Do NOT introduce adapter interfaces, factory patterns, or data record types unless they are strictly necessary to satisfy the boundary conditions. If the existing code can be relocated without restructuring, that is preferred.
+> - Do NOT refactor `CSAPIQueryBuilder`'s constructor signature unless the current signature violates a boundary condition.
+> - Do NOT suggest changes to EDR or other upstream modules — that is not our scope.
+> - If a design decision is a close call, document both options and flag it for jahow's input rather than over-engineering a solution.
+>
+> See: [Scope Alignment Review Notes](scope-alignment-review-notes.md)
+
 ### Excluded From Scope
 
 - **Plugin registration, mixin injection, decorator patterns:** Excluded — these require core to reference the sub-module (violates constraints 3 and 4).
@@ -368,6 +386,7 @@ This research is complete when:
 - [ ] Post-refactoring verification checklist is complete
 - [ ] The "litmus test" is explicitly verified: removing `src/ogc-api/csapi/` leaves core functional
 - [ ] Deliverable document is complete and follows the findings report template
+- [ ] **Implementation scope gate applied:** Every design decision passes the minimum-change test — no changes beyond what jahow's requirements demand
 - [ ] Findings are cross-referenced with Plan 08 and provide everything Plan 08 needs to produce the changelist
 
 ---

docs/research/phase-6/research-plans/08-file-level-changelist-and-commit-strategy.md

@@ -64,6 +64,27 @@ This plan is also uniquely positioned: it must account for the *existing* 13-com
 5. **CI compliance (Constraint 5):** Every commit in the final sequence must individually pass all 5 CI checks: `npm run format:check`, `npm run typecheck`, `npm run lint`, `npm run test:browser`, `npm run test:node`. If this is impractical for intermediate commits, the plan must document which commits are allowed to be squashed.
 6. **PR #136 compatibility:** The changelist must be applicable to the `clean-pr` branch, which has 13 commits above `upstream/main` (`53a6449`). The strategy must define how refactoring changes integrate with those 13 commits — amend, rebase, or extend.
 
+### Implementation Scope Gate
+
+> **Research broadly, implement minimally.**
+>
+> This plan translates research findings into the concrete changelist. Every file operation in the changelist must pass the **minimum-change test:**
+>
+> **"Does this file change directly serve jahow's two requirements (CSAPI out of root index.ts, non-CSAPI code stops importing CSAPI), or are we adding work he didn't request?"**
+>
+> The changelist must contain ONLY:
+> - Changes required to satisfy jahow's two bullet points
+> - Changes that are direct consequences of those requirements (e.g., moving a method because its imports violate the constraints)
+> - Changes required to pass CI (formatting, linting)
+>
+> The changelist must NOT contain:
+> - "While we're at it" improvements (refactoring code that isn't affected by the boundary conditions)
+> - New abstractions or patterns inspired by research but not required by the constraints
+> - Changes to modules outside our scope (EDR, other upstream code)
+> - Documentation files beyond what's needed for the PR
+>
+> See: [Scope Alignment Review Notes](scope-alignment-review-notes.md)
+
 ### Excluded From Scope
 
 - **Architectural decision-making:** All architectural decisions are made in Plans 01–06. Plan 08 does not revisit them — it translates them into file operations. If a decision is ambiguous, this plan flags it as an open question for Plan 06 rather than resolving it.
@@ -313,6 +334,7 @@ This research is complete when:
 - [ ] The changelist accounts for formatting (Plan 07's output) and places it correctly in the commit sequence
 - [ ] No file affected by the refactoring is missing from the changelist (completeness verified by walking through constraints)
 - [ ] A developer can execute the spec mechanically — zero ambiguities, zero decisions left to make
+- [ ] **Implementation scope gate applied:** Every file operation passes the minimum-change test — no changes beyond what jahow's requirements demand
 - [ ] Deliverable document is complete and follows the findings report template
 - [ ] The deliverable document IS the implementation spec — it bridges research and action