chore: enhance planning and management instructions with PR slicing strategies and multi-PR protocols

.github/agents/Management.agent.md

@@ -39,7 +39,7 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
     -   **Identify Goal**: Understand the user's request.
     -   **STOP**: Do not look at the code. Do not run `list_dir`. No code is to be changed or implemented until there is a fundamentally sound plan of action that has been approved by the user.
     -   **Action**: Immediately call `Planning` subagent.
-        -   *Prompt*: "Research the necessary files for '{user_request}' and write a comprehensive plan detailing as many specifics as possible to `docs/plans/current_spec.md`. Be an artist with directions and discriptions. Include file names, function names, and component names wherever possible. Break the plan into phases based on the least amount of requests. Review and suggest updaetes to `.gitignore`, `codecov.yml`, `.dockerignore`, and `Dockerfile` if necessary. Return only when the plan is complete."
+        -   *Prompt*: "Research the necessary files for '{user_request}' and write a comprehensive plan detailing as many specifics as possible to `docs/plans/current_spec.md`. Be an artist with directions and discriptions. Include file names, function names, and component names wherever possible. Break the plan into phases based on the least amount of requests. Include a PR Slicing Strategy section that decides whether to split work into multiple PRs and, when split, defines PR-1/PR-2/PR-3 scope, dependencies, and acceptance criteria. Review and suggest updaetes to `.gitignore`, `codecov.yml`, `.dockerignore`, and `Dockerfile` if necessary. Return only when the plan is complete."
     - **Task Specifics**:
         - If the task is to just run tests or audits, there is no need for a plan. Directly call `QA_Security` to perform the tests and write the report. If issues are found, return to `Planning` for a remediation plan and delegate the fixes to the corresponding subagents.
 
@@ -55,8 +55,14 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
     -   **Ask**: "Plan created. Shall I authorize the construction?"
 
 4. **Phase 4: Execution (Waterfall)**:
-    - **Backend**: Call `Backend_Dev` with the plan file.
-    - **Frontend**: Call `Frontend_Dev` with the plan file.
+        - **Single-PR or Multi-PR Decision**: Read the PR Slicing Strategy in `docs/plans/current_spec.md`.
+        - **If single PR**:
+            - **Backend**: Call `Backend_Dev` with the plan file.
+            - **Frontend**: Call `Frontend_Dev` with the plan file.
+        - **If multi-PR**:
+            - Execute in PR slices, one slice at a time, in dependency order.
+            - Require each slice to pass review + QA gates before starting the next slice.
+            - Keep every slice deployable and independently testable.
 
 5. **Phase 5: Review**:
     - **Supervisor**: Call `Supervisor` to review the implementation against the plan. Provide feedback and ensure alignment with best practices.
@@ -68,6 +74,7 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
     - **Docs**: Call `Docs_Writer`.
     - **Manual Testing**: create a new test plan in `docs/issues/*.md` for tracking manual testing focused on finding potential bugs of the implemented features.
     - **Final Report**: Summarize the successful subagent runs.
+    - **PR Roadmap**: If split mode was used, include a concise roadmap of completed and remaining PR slices.
 
 **Mandatory Commit Message**: When you reach a stopping point, provide a copy and paste code block commit message at the END of the response on format laid out in `.github/instructions/commit-message.instructions.md`
         - **STRICT RULES**:

.github/agents/Planning.agent.md

@@ -37,12 +37,18 @@ You are a PRINCIPAL ARCHITECT responsible for technical planning and system desi
    - Specify database schema changes
    - Document component interactions and data flow
    - Identify potential risks and mitigation strategies
+   - Determine PR sizing and whether to split the work into multiple PRs for safer and faster review
 
 3. **Documentation**:
    - Write plan to `docs/plans/current_spec.md`
    - Include acceptance criteria
    - Break down into implementable tasks using examples, diagrams, and tables
    - Estimate complexity for each component
+    - Add a **PR Slicing Strategy** section with:
+       - Decision: single PR or multiple PRs
+       - Trigger reasons (scope, risk, cross-domain changes, review size)
+       - Ordered PR slices (`PR-1`, `PR-2`, ...), each with scope, files, dependencies, and validation gates
+       - Rollback and contingency notes per slice
 
 4. **Handoff**:
    - Once plan is approved, delegate to `Supervisor` agent for review.
@@ -87,6 +93,7 @@ You are a PRINCIPAL ARCHITECT responsible for technical planning and system desi
 - **DETAILED SPECS**: Plans must include specific file paths, function signatures, and API schemas
 - **NO IMPLEMENTATION**: Do not write implementation code, only specifications
 - **CONSIDER EDGE CASES**: Document error handling and edge cases
+- **SLICE FOR SPEED**: Prefer multiple small PRs when it improves review quality, delivery speed, or rollback safety
 </constraints>
 
 ```

.github/instructions/copilot-instructions.md

@@ -123,6 +123,21 @@ Before proposing ANY code change or fix, you must build a mental map of the feat
 - **Beta**: `feature/beta-release` always builds.
 - **History-Rewrite PRs**: If a PR touches files in `scripts/history-rewrite/` or `docs/plans/history_rewrite.md`, the PR description MUST include the history-rewrite checklist from `.github/PULL_REQUEST_TEMPLATE/history-rewrite.md`. This is enforced by CI.
 
+## PR Sizing & Decomposition
+
+- **Default Rule**: Prefer smaller, reviewable PRs over one large PR when work spans multiple domains.
+- **Split into Multiple PRs When**:
+    - The change touches backend + frontend + infrastructure/security in one effort
+    - The estimated diff is large enough to reduce review quality or increase rollback risk
+    - The work can be delivered in independently testable slices without breaking behavior
+    - A foundational refactor is needed before feature delivery
+- **Suggested PR Sequence**:
+    1. Foundation PR (types/contracts/refactors, no behavior change)
+    2. Backend PR (API/model/service changes + tests)
+    3. Frontend PR (UI integration + tests)
+    4. Hardening PR (security/CI/docs/follow-up fixes)
+- **Per-PR Requirement**: Every PR must remain deployable, pass DoD checks, and include a clear dependency note on prior PRs.
+
 ## ✅ Task Completion Protocol (Definition of Done)
 
 Before marking an implementation task as complete, perform the following in order:

.github/instructions/subagent.instructions.md

@@ -23,10 +23,22 @@ runSubagent({
 
 - Validate: `plan_file` exists and contains a `Handoff Contract` JSON.
 - Kickoff: call `Planning` to create the plan if not present.
+- Decide: check if work should be split into multiple PRs (size, risk, cross-domain impact).
 - Run: execute `Backend Dev` then `Frontend Dev` sequentially.
 - Parallel: run `QA and Security`, `DevOps` and `Doc Writer` in parallel for CI / QA checks and documentation.
 - Return: a JSON summary with `subagent_results`, `overall_status`, and aggregated artifacts.
 
+2.1) Multi-PR Slicing Protocol
+
+- If a task is large or high-risk, split into PR slices and execute in order.
+- Each slice must have:
+  - Scope boundary (what is included/excluded)
+  - Dependency on previous slices
+  - Validation gates (tests/scans required for that slice)
+  - Explicit rollback notes
+- Do not start the next slice until the current slice is complete and verified.
+- Keep each slice independently reviewable and deployable.
+
 3) Return Contract that all subagents must return
 
 ```
@@ -43,6 +55,7 @@ runSubagent({
 
 - On a subagent failure, the Management agent must capture `tests.output` and decide to retry (1 retry maximum), or request a revert/rollback.
 - Clearly mark the `status` as `failed`, and include `errors` and `failing_tests` in the `summary`.
+- For multi-PR execution, mark failed slice as blocked and stop downstream slices until resolved.
 
 5) Example: Run a full Feature Implementation