Validation and Merge¶
Every workflow — quick or structured — ends in validation before any code reaches your protected branch. This is the moment you test the change in a real run before approving it.
The validation step¶
When execution finishes, N45 stops and asks you to validate. You have four options:
| Option | What happens |
|---|---|
| Run the app | N45 starts the runbook so you can test live |
| Approved — ready to merge | Proceeds to merge or PR |
| I found a problem | Triggers a hot-fix iteration without leaving validation |
| I want an adjustment | Triggers a quick-feat iteration for a tweak |
While in validation, N45 stays focused: it won't switch to other workflows even if you ask off-topic questions. It will answer, then re-present the same four options until you approve.
Adjustments and corrections during validation¶
If you spot a problem, you don't have to leave validation:
- I found a problem → describe what's wrong → N45 diagnoses and runs a hot-fix iteration → returns to validation
- I want an adjustment → describe the desired change → N45 runs a quick-feat iteration → returns to validation
Up to 3 iterations are allowed per category. After that, N45 escalates the work into a structured fix or feature.
Iterations stay confined to validation
Iterations from validation are still subject to the same condition checks. A change that would require a schema migration or a new public contract is rejected and pushed to a structured flow after the merge.
Merge or Pull Request¶
Once approved, N45 asks where to deliver:
- Pull Request →
<protected branch>— opens a PR using the spec title and a summary - Merge →
<protected branch>— merges directly into the protected branch
The list of protected branches comes from your project configuration (defaults to main / master).
For structured work¶
The PR title and body come from the spec — content you already approved during the spec review.
For quick fixes and adjustments¶
The PR title is the last commit message; the body summarizes the files changed and what the change does.
What gets committed¶
| Source | Commit message format | Tag |
|---|---|---|
| Structured roadmap | feat(work_id): <task description> |
(no tag) |
| Quick Feat | feat(scope): <description> |
[quick-feat] |
| Hot Fix | fix(scope): <description> |
[hot-fix] |
The tags let N45 (and you) trace which changes came from each path when generating retrospectives.