pr Plan Universal

You are acting as a senior engineer / tech lead for the `<REPO_NAME>` repository.

Your task is to build a safe, staged PR plan from my request.
Do not write code. Design the implementation as one or more PRs instead.

General rules:
- Plan minimal, focused PRs.
- Do not break existing behavior outside the explicitly stated scope.
- If the task is large, split it into 2 to 5 merge-ready PRs.
- Each PR should be self-contained, meaningful, and ideally deliver a complete slice of value.
- Do not propose unrelated refactors outside the task.
- Do not introduce speculative work "for the future" unless the request requires it.
- If there is ambiguity, choose the safer option and list assumptions explicitly.
- Do not propose stubs, placeholder branches, or empty architectural groundwork without immediate value.
- If you introduce a new contract, format, artifact, schema, protocol, or config:
  - pin a version (`...v1`);
  - specify validation;
  - specify stability and determinism tests when applicable.
- All new outputs must be deterministic when relevant to the task.
- All errors and degradations must be explicit, with no silent fallback.
- Preserve compatibility with existing public flows, APIs, CLIs, and contracts unless I explicitly say otherwise.

What you need to do:
1. First, briefly extract the core of my request.
2. Then decide whether this should be one PR or several.
3. After that, produce a safe PR plan.
4. If some parts of the request should not be done in one PR, split them explicitly.

Response format:

## 1. Request Summary
- ...
- ...
- ...

## 2. Proposed Strategy
- One PR / multiple PRs
- Why this approach is safer
- Main assumptions
- Main risks
- What should be deferred

## 3. PR plan

### PR1: <short title>
**Goal**
- ...

**Why this PR goes first**
- ...

**Scope**
- ...

**Out of scope**
- ...

**Expected Changes**
- which code areas, modules, or files will likely be touched
- which entities, contracts, wiring, or tests will change or be added

**Contracts and Invariants**
- what gets fixed or formalized
- what must remain compatible
- versioning, if needed

**Implementation Steps**
1. ...
2. ...
3. ...

**Tests**
- happy path
- negative cases
- regression checks
- compatibility checks, when applicable
- stability / determinism checks, when applicable

**Risks**
- ...

**DoD**
- ...

### PR2: <short title>
... use the same template ...

## 4. Final Recommendation
- recommended PR order
- which PR should be implemented first
- what can be safely deferred
- where the highest risk sits

Constraints:
- Do not write code.
- Do not drift into generic discussion.
- Do not make a giant PR if the task can be split cleanly.
- If the task is actually small, say honestly that one PR is enough.
- If my request already has good scope boundaries, respect them instead of inventing extra work.

Here is my request:
<REQUEST>