Loop 068
The evidence-first feature loop
An AI coding-agent workflow for grounding one small feature change in current code, APIs, data contracts, and tests before implementation and user-path verification.
Ready-to-use prompt
Copy the loop
Implement one bounded feature slice in [repository]. Read project instructions, the current implementation, relevant services, types, UI, tests, and architecture notes before editing. Report the evidence, risks, affected files, persistence impact, and validation plan; stop for approval if inspection materially changes scope or reveals destructive, production, or silent-persistence behavior. Make the smallest change, preserve unknown data and unrelated work, run relevant checks, and manually verify user-facing states. Stop after this slice and return evidence, limitations, and the next recommended slice.
Verify / stop
One feature slice works and its assumptions are proven by current evidence.
The implementation matches observed APIs and data contracts, repository checks pass or have documented pre-existing failures, and the relevant user path is manually verified when one exists.
Context and guidanceWhen to use it, steps, safety notes, and related loops
Use this when
Use this when a larger feature can be divided into small engineering slices and guessing about APIs, persistence, or user-visible behavior would create avoidable risk.
How to run it
- Read the project instructions and inspect the current implementation, dependencies, contracts, tests, and relevant architecture notes.
- State the evidence, risks, files in scope, user-visible behavior, persistence impact, and validation plan for one small slice.
- Stop for approval if inspection invalidates the approach or reveals a material scope, production, destructive, or silent-persistence change.
- Implement only the supported slice while preserving unknown fields, round-trip behavior, and unrelated work.
- Run the relevant repository checks and manually verify loading, error, stale, save, and cleanup states where applicable.
- Stop after the slice and return the evidence, changed behavior, limitations, and next recommended slice.
Why it works
Inspecting real contracts before coding prevents plausible but invented APIs or data behavior from shaping the implementation. Limiting each pass to one feature slice keeps review, verification, and persistence effects understandable.
Implementation note
Do not silently save user data, invent endpoints or data shapes, hide unavailable checks, or continue into another feature slice without approval. Keep previews honest about whether they show draft state or source-of-truth backend output.
Contributor playbookBoundaries, required outputs, implementation guidance, and reviewer handoff
Do not use this when
- Do not use this loop to conceal a large feature behind an artificially small label.
- Do not implement when inspection shows that acceptance criteria or required infrastructure materially differ from the supplied task.
Required outputs
- Current implementation and contract findings, files changed, behavior changed, persistence impact, validation results, limitations, and one recommended next slice.
- For preview, download, or generation features, an explicit account of whether output reflects draft state or saved backend state.
Match the method to the artifact
- Preserve unknown runtime fields and round-trip mapper behavior.
- Avoid speculative abstractions, unrelated refactors, silent autosave, and destructive side effects.
- Use an explicit Save or Save and generate action when generation depends on persisted state.
- For user-facing workflows, check loading, error, stale, save and load behavior, and resource cleanup.
Reviewer handoff
- Confirm that the implementation is supported by direct repository evidence and that only one bounded slice was attempted.
- Distinguish unavailable checks and pre-existing failures from evidence that the slice passed.