Product
Workflow
Plan, build and review changes before merging.
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 required checks. 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 check results 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 only supports a pass when it tests the behavior the criterion requires.
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 before deciding which checks must pass. New changes can invalidate earlier results.
Review before completion
The completion record should connect each criterion to its check results 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 tied to the checked revision.