Acceptance First

Own executable examples and small implementation increments for one agreed workflow, not independent review or delivery acceptance. Use directly for matching requests or inline through an authorized handoff. Read validation when changing or validating this package.

1. Bound the workflow

Reuse applicable project guidance and relevant context/authority pointers once per context, including directory/runtime restrictions. Check decision/effect authority, safety, verification/review, documentation and continuation responsibilities. Direct and bounded use accept equivalent layouts. Missing/conflicting common guidance blocks dependent work: name the gap and recommend explicit setup/reconciliation without starting it or inventing policy. Conditional gaps block only that capability.

Identify the agreed workflow, acceptance IDs, exclusions, affected components/callers, material integration boundaries and protected work. Inspect supplied readiness and existing checks against current source, dirty content, configuration and environment; reuse current evidence. Bound owned implementation/test effects. Plan-only requests return an example/check plan.

Use compatible implementation-preflight before Git writes, or inspect a current supplied result for the same scope/state; outside Git retain a before/after manifest. Actual meaning/decision-record changes use discovered domain-modeling; reading definitions alone needs no invocation. Missing/incompatible companions block their dependent route.

Only delegated work or recorded acceptance correction loads Work On's documented conditional coordination/repair library, without invoking delivery. Retain root ownership/bounds and checkpoint/lineage/spent cycles; method switches/resume reset nothing. An old universal-contract-only package blocks that route, not ordinary development.

Complete when: agreement, scope, ownership, deciding inputs and checks are actionable, or specific affected blockers preserve work.

2. Translate commitments into executable examples

Map every in-scope acceptance criterion to representative setup/input, action and externally observable outcome: returned data, persisted state, failure, side effects or workflow transition. Include relevant rejection/recovery paths and cross-component risks. Use the smallest real boundary that can demonstrate the commitment; reuse adequate existing checks. The lead chooses routine harnesses and seams, not the maintainer.