| name | transaction-boundary-checker |
| description | Enforce one intended user action to one intended undo commit by auditing write timelines and transaction boundaries. Use when requests mention undo split/missing commits or transaction regressions. |
Skill: transaction-boundary-checker
Trigger Signals
Use this skill when requests include:
- "undo/redo split"
- "multiple commits"
- "transaction"
- "one action one commit"
Do Not Use When
- Request has no model mutations.
- Request is read-only query optimization.
Required Inputs
- Action flow under investigation.
- Mutating APIs/features in scope.
- Rule source:
docs/ai/framework/rules/data-flow-and-transactions.md
Preflight
- Map each write call in the action path.
- Mark where transaction starts/ends today.
- Capture current expected undo behavior from docs or user note.
Deterministic Procedure
- Build mutation timeline for one user action.
- Detect violations:
- writes before
startTransaction
- writes after
endTransaction
- accidental nested action splits
- Move boundaries to match intended action unit.
- Keep mutation operations inside app/common API boundary.
- Ensure session-driven actions do not fragment commits unintentionally.
Validation Matrix
- One intended user action => one intended commit.
- Undo reverses full action, not partial slices.
- Redo restores full action.
Required Output Format
Write Timeline
- ordered list of writes per action
Boundary Fix
- old boundary vs new boundary
Validation
- manual/automated undo-redo checks
Residual Risks
- edge cases not covered yet
Guardrails
- Do not add transaction wrappers in random UI handlers.
- Prefer central mutation APIs for boundary ownership.
- Local commits may close completed, validated steps/stages; never push unless
the user explicitly requests the remote operation. Follow
docs/ai/workflows/git-commit-push-policy.md.
Failure Policy
If action unit is ambiguous:
- keep behavior stable
- provide 2 boundary options with concrete undo outcomes
