# Checkpoints

Use these checkpoint rules for Da Vinci.

## Execution Policy

Treat checkpoints as internal execution guards, not approval steps.

Default handling:

- `PASS`: continue automatically
- `WARN`: record the issue and continue automatically
- `BLOCK`: stop only when the blocker cannot be resolved from existing artifacts, local context, or the current codebase

Do not pause the workflow just because a checkpoint ran.

## `discovery checkpoint`

Run after `brainstorm.md`, `project-inventory.md`, or `design-brief.md`.

Check:

- the active mode is correct
- the starting material is stable enough to write specs
- product form factor and visual direction are known, inferred, or explicitly deferred
- candidate pages or current pages are clear enough to move into `page-map.md`
- open questions are explicitly tracked

Result meanings:

- `PASS`: move into formal proposal/spec work
- `WARN`: continue, but the foundation is still soft
- `BLOCK`: do not produce downstream artifacts yet

## `spec checkpoint`

Run after the core requirements and page scope are defined and before Pencil design is treated as final.

Check:

- page scope is complete
- user flows are named
- important states are present
- acceptance conditions are testable
- risky areas are called out early

Result meanings:

- `PASS`: safe to continue into final design and task planning
- `WARN`: continue, but update artifacts soon
- `BLOCK`: update source artifacts before moving on

## `design checkpoint`

Run after Pencil pages exist and before implementation tasks are locked.

Check:

- each required page exists in Pencil
- important sections exist
- key states are represented or explicitly deferred
- major layout strategy matches the design artifact
- Pencil names and artifact names are aligned enough to implement from

Result meanings:

- `PASS`: safe to generate implementation tasks
- `WARN`: minor design gaps exist
- `BLOCK`: design is not ready to drive implementation

## `mapping checkpoint`

Run after `design-registry.md` and `pencil-bindings.md`.

Check:

- the correct `.pen` source is identified
- each implementation page has a Pencil page or an explicit exception
- shared layouts and shared regions are bound clearly enough to implement from
- route names and Pencil names are traceable
- missing bindings are called out before implementation

Result meanings:

- `PASS`: safe to generate implementation tasks
- `WARN`: some bindings are weak, but implementation can continue carefully
- `BLOCK`: implementation would guess too much without fixing bindings

## `task checkpoint`

Run before implementation starts.

Check:

- top-level task groups exist
- tasks cover page structure from Pencil
- tasks cover behavior from specs
- tasks cover integration and verification work
- tasks are ordered by dependency

Result meanings:

- `PASS`: safe to start implementation
- `WARN`: implementation can start, but task quality is weak
- `BLOCK`: rewrite tasks before implementation

## `execution checkpoint`

Run after each top-level task group during implementation.

Check:

- completed code still matches spec behavior
- completed code still matches Pencil-backed structure
- no major scope drift appeared
- next task group is still valid

Result meanings:

- `PASS`: continue
- `WARN`: continue, but record the issue
- `BLOCK`: update artifacts before continuing

## Reporting Format

Use this reporting shape:

```md
## Checkpoint
- Type:
- Status:

## Findings
- Key point 1
- Key point 2

## Next Step
- Continue or update artifacts
```

Do not create separate review artifacts unless the project explicitly requires them.