## Fictional but realistic example

Suppose a function on a abstract datatypes.
Let's consider a specific development strategy obtained after design phase
1. Implement the most complicated case/constructor of the datatype (usually it enables you to tackle the most complicated part of the design) (I count test and docstring here) you might have done it in peer-programing (the same for the other step) and discussing with experts in the code that you will have to touch (the same for the other steps)
2. Then tackle other some other cases which do not require modifying the current design
3. At some point you realize that you can refactor, so you do it
4. you then attack another bench of cases but one of them requires changing the whole design. You do it, rewrite the previously written cases with this new design
5. you continue and in another case, you realize that you need to add stuff in the test helper library to write its test, you do it. Maybe you need to make this in a separate MR with another reviewer outside of your team. It is done you rebase your work on top of this.
6 .... x. previous steps can repeat

## Incremantal development and breakdown motivations

To prepare the development itself in a more incremental manner, I consider three more criteria for quality/safety purposes to plan the development into MRs:
- Limits the number of commits in master corresponding to design choice that are modified few commits later in development for the same function.
(design choice -- due to redesign when adding cases in development plan of previous section in point 4 that might reappear in 6...x points)
- Quality control of the development in the main project: fixing from reviews people involved in the main project (where project designate the whole project to which this specific development belongs). The history of the branch is then rewritten:
- by reviews when the MR is in Draft or Wip status
- peer-programing session with expert (almost code owner) of a specific files/components
- dedicated review meeting
- Quality control for the integration into the whole code base:
- Engineers non-involved in the main project but with expertise on the modified component, then the review is more alike an audit (very comon for most development)
- Engineers experts in potentially impacted components (depending and only when required).

Taking these criteria into account, the development breakdown from last section becomes the following development plan and MRs:
- One MRs by set of cases (constructors of the datatype) begining by the one where point 1 belongs,
- One for the last refactoring, and
- eventually one dedicated to exposition the functions and change impacting other components

It has a lot of inconvenient: making invisible a lot of works, provokes a lot of rebasing works, sometimes merged MRs from other projects can add new cases in your datatypes or new implicit invariants....
It is not perfect but handles the 3 quality/safety criteria that I have.

## Question
How in one PR per day paradigm I can ensure the 3 above criteria?