Gate the alignment pass in Workflow, Review, PR format, and readiness

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: MariusStorhaug

src/docs/Ways-of-Working/Definition-of-Ready-and-Done.md

@@ -31,6 +31,7 @@ A pull request is ready for review when:
 - Native dependencies are current and every prerequisite the change relies on has landed; the pull request is not used to bypass a blocked-by edge.
 - All required checks are green — not just tests that pass locally. CI is complete, not in progress.
 - The automated review loop has converged — a clean [Copilot round](Contribution-Workflow.md#the-copilot-review-loop) with no unresolved review threads.
+- The [standards and framework alignment pass](Workflow-Stages/Implement.md#5-standards-and-framework-alignment-pass) has run against the finished change, its result covers every changed surface in the pull request, and every exception links a follow-up issue.
 - The title, release-note description, and exactly one change-type label are finalized. See [PR Format](PR-Format.md).
 
 If any item is open, the pull request stays a draft. Marking it ready with known-open work shifts the author's unfinished job onto reviewers — the opposite of what the signal means.

src/docs/Ways-of-Working/PR-Format.md

@@ -120,6 +120,14 @@ The **Technical details** block is for reviewers and maintainers. Include intern
 - Implementation approach and design decisions.
 - Backward compatibility notes for developers.
 - **Implementation plan progress** — cross-reference the closing Task or Bug's plan. Which plan steps does this PR complete? Which were moved to follow-up delivery issues?
+- **Standards and framework alignment** — the result of the [alignment pass](Workflow-Stages/Implement.md#5-standards-and-framework-alignment-pass), as one row per changed surface. The stage procedure owns when and how the pass is run; this block only carries its evidence.
+
+    | Changed surface | Standards checked | Framework docs checked | Result |
+    | --- | --- | --- | --- |
+    | `src/**` (PowerShell) | Naming, Functions | Module source layout | Aligned |
+    | `.github/workflows/**` | GitHub Actions | Reusable workflow contract | Exception — Owner/Repo#123 |
+
+    A result is `Aligned`, `Fixed in this PR`, or `Exception` with a link to the follow-up issue that carries it.
 
 The **Relevant issues (or links)** block is required and uses fully qualified references (`Owner/Repo#N`) so links work across repositories.
 

src/docs/Ways-of-Working/Workflow-Stages/Review.md

@@ -33,6 +33,7 @@ Check each dimension per [Review Etiquette](../Review-Etiquette.md):
 - **Taste** — readability, naming, structure, tests that exercise behaviour.
 - **Security** — input validation, no secrets in logs, SHA-pinned actions, least privilege. Escalate a deep pass to [Security Review](Security-Review.md).
 - **Documentation** — updated where user-facing behaviour changed.
+- **Standards and framework alignment** — the pull request records the author's [alignment pass](Implement.md#5-standards-and-framework-alignment-pass), the result covers every changed surface, and each exception links a real follow-up issue. Spot-check at least one row against the canonical standard or framework page rather than trusting the summary; a missing or hollow pass is a blocking finding.
 - **Tests** — new behaviour has tests; bugs get regression tests.
 
 ### 4. Post the review
@@ -55,6 +56,7 @@ An approval co-signs the change, so approve once the blocking concerns are resol
 ## Where this connects
 
 - [Review Etiquette](../Review-Etiquette.md) — tone, severity, and how to disagree well.
+- [Implement](Implement.md#5-standards-and-framework-alignment-pass) — the author-side alignment pass this stage verifies.
 - [PR Format](../PR-Format.md) — delivery-leaf closure and contextual aggregate links.
 - [Branching and Merging](../Branching-and-Merging.md) — who approves and how a change lands.
 - [Security Review](Security-Review.md) — the specialized security path.

src/docs/Ways-of-Working/Workflow.md

@@ -111,7 +111,8 @@ Execute one ready, unblocked Task or Bug. For repository delivery:
 3. **Implement** — work through the implementation plan. One logical change per commit. Update the issue as each plan step completes.
 4. **Test locally** — don't push known failures to CI. Push work as far inward as it can go.
 5. **Self-review with automation** — run the [Copilot review loop](Contribution-Workflow.md#the-copilot-review-loop) until it reports a clean round, fixing in-scope feedback and filing follow-up issues for the rest.
-6. **Ready and auto-merge** — when the change meets the [Definition of Ready for Review](Definition-of-Ready-and-Done.md#definition-of-ready-for-review), finalize the pull request per [PR Format](PR-Format.md), mark it ready, and enable auto-merge.
+6. **Standards and framework alignment pass** — once the change is complete, reconcile it against process, the applicable [Coding Standards](../Coding-Standards/index.md) chapters, and the repository's framework documentation, and record the result in the pull request. See [Implement](Workflow-Stages/Implement.md#5-standards-and-framework-alignment-pass).
+7. **Ready and auto-merge** — when the change meets the [Definition of Ready for Review](Definition-of-Ready-and-Done.md#definition-of-ready-for-review), finalize the pull request per [PR Format](PR-Format.md), mark it ready, and enable auto-merge.
 
 An audited operational Task follows its [operational completion path](Issues/Types/Task.md#operational-delivery) instead of creating a branch or pull request.