Product
The loop
Move from a clear goal to code backed by evidence.
Define the outcome
Begin with a goal that describes the behavior you need. Add observable acceptance criteria: the paths that must work, failure cases that must be handled and constraints that must remain true. A task list explains the work; criteria explain how to judge the result.
Think: establish the plan
Asondy’s goal protocol scopes the work before implementation. Complex goals can be divided into contracts with clear ownership, dependencies and proof requirements. Review the plan when a decision changes the scope or needs your judgment.
Execute: implement within the scope
Workers carry out the agreed work and record evidence as they go. Where the workflow uses parallel workers, isolated worktrees and draft pull requests keep changes reviewable. Guards evaluate supported tool actions and delivery gates throughout the work.
Verify: challenge the result
Verification compares the implementation against the acceptance criteria. An independent reviewer reruns the relevant checks; a critic can probe the claims and missing cases. A successful command is useful evidence only when it demonstrates the behavior the criterion asks for.
When a check blocks progress
Read the failed condition, correct the cause and rerun the relevant check. If the request itself is ambiguous, resolve the criterion rather than weakening the evidence to make the result pass. New changes can invalidate earlier results.
Finish with reviewable evidence
The completion record should connect each criterion to its proof and identify unresolved limitations. Asondy’s gates support this process, but the enabled checks define their coverage. Repository permissions and human approval still govern the actions that require them.
See Verification for verdicts and revision-specific evidence.