Picking the Next Task

Use this checklist when choosing the next implementation task for Lapis Notes.

Default Rule

Prefer the earliest incomplete release-critical item linked from Complete Daily-Use App.

Do not widen the release by default. If a task does not clearly support that milestone, treat it as deferred or document it separately as follow-up work.

Selection Order

Finish the earliest incomplete item in the release-critical sequence.
If that item is blocked, choose the next unblocked item that is explicitly listed as depending only on already-complete work.
If no release-critical issue is ready, pick the smallest enabling task that removes a documented blocker for the current sequence.
Only pick speculative or deferred work when the release-critical path is intentionally paused in the roadmap.

Required Inputs Before Starting

Read SUMMARY.md.
Read the owning package page and shared contract page for the area you will change.
Read Complete Daily-Use App if the item is release-critical.

Scope-Control Rules

Start from the roadmap item and spec page, not from an unrelated nearby idea.
If implementation uncovers adjacent work that is not required by the current acceptance criteria, document separate follow-up work instead of silently expanding scope.
Prefer fixes that strengthen the current milestone over work that adds new platform or feature surface area.
Update tests for user-visible behavior changes.
Update the spec when behavior, ownership, boot flow, or validation expectations change.

Completion Rules

Do not stop at planning if the selected item has implementable acceptance criteria.
Run the narrowest relevant pnpm check:all path for the touched packages before committing.
Run pnpm test:smoke before committing only when the change can affect the running workspace or desktop app (see AGENTS.md → Validation Before Commit).
Record what changed, what did not change, and any follow-up work in the commit message or handoff notes when appropriate.