Recommendations for profiles and routes
Define verification rules in the profile and routes so agents check the agreed result and report the limits of their evidence.
Give this page to an agent when configuring a profile. Apply the recommendations to your project's tasks. A successful stage outcome alone does not prove that every requirement was checked.
| What to define | Where to configure it |
|---|---|
| Check commands and environment diagnostics | In the project profile. |
| Rules for reviews, audits and browser checks | In stage instructions. |
| Report format, outcomes and return destination | In route instructions and transitions. |
Choose scenarios based on the task's requirements and risks. The new feature example covers saved settings, empty selections, ON/OFF modes and overlapping parameters.
Reviewer rules
The following rules are recommended for review, audit and browser stages. Put them in the specific route's instructions and transitions: a successful outcome alone does not let the engine prove that all requirements were checked. See when profile changes take effect for applying edits.
- On any pass, a new reproducible defect that violates an agreed requirement can block acceptance. Identify the criterion it violates.
- On a repeat pass, first check earlier findings, fixes and their effects. This order does not exclude new evidence of a requirement violation.
- “Missed on the previous pass” does not mean “existed before the task” and is not a reason to defer a defect. Establish prior existence against the task's baseline revision, rather than the previous verdict.
- Keep scope boundaries: do not block on taste, expand the task or reopen a closed finding without new evidence.
- Time limits, attempt limits and lack of progress constrain further work. They do not turn open blockers into success. List remaining work when stopping.
For every blocker, require a reproduction scenario, expected and actual behavior, evidence and a return destination — the stage able to fix the cause.
If a mandatory check is unavailable, list the unconfirmed criteria and the reason. This does not prove an implementation defect, but it prevents claiming full acceptance. Use the route's configured return or stop for a human decision: for example, failed owned by environment or human, or skipped with a human stop where the route provides one. See node fields for outcomes and transitions, and acceptance evidence for the report format.
Check environment readiness
Distinguish three levels of verification for the task:
| Level | What to check | What the result proves |
|---|---|---|
| Availability | The container is running and the required HTTP address responds. | A process or application entry point is accessible. |
| Required processes and connections | Queues, workers, the scheduler and external integrations needed by the task perform their work. | Required parts operate; a list of running processes alone is insufficient. |
| User scenario | A normal launch takes the user's action through to the expected result without manually executing each intermediate step. | The required chain operates autonomously from end to end. |
Dependencies and how to check them belong to the project. The engine calls the profile's check; an HTTP response does not tell it that all queues and integrations work.
Manually advancing the chain is valid for diagnosis, such as checking one stage or handler. This alone does not prove autonomous operation. If the task requires it, run a separate end-to-end scenario with the normal processes. Report manual interventions, process and queue results, and what remains unconfirmed. Unavailable mandatory parts of the environment require the route's configured return or stop for a human decision. See the acceptance report format.
Acceptance evidence
An individual node's done is a stage result under its contract. It does not by itself prove completion of the whole task. Before acceptance, the human needs requirement coverage, unchecked items, open defects and limits of the evidence.
A compact report can use “requirement → scenario → result → evidence → limitation”. For example, for a task involving a filter and background processing:
| Requirement | Scenario | Result | Evidence | Limitation |
|---|---|---|---|---|
| Preserve behavior without the filter | Compare the baseline and OFF | Confirmed | Results compared before and after the change | Prepared data only |
| Background processing completes the work | Normal launch through to the result | Not checked | Only a log of manually executed stages is available | Normal queue and worker operation unverified |
In a real report, link to artifacts from the specific run. List open defects and return details separately. This is a recommended report format for route instructions, not a promise of automatic coverage validation by the engine.
Do not present an unchecked mandatory criterion as fulfilled. An exception or deferral requires an explicit human decision recorded in the task and acceptance decision. Until then, use the route's configured return or stop. After fixes, repeat affected checks and the necessary checks of existing behavior.
Apply the recommendations
Configure commands and environment checks in the profile. Put reviewer instructions, the report format and transitions in the route. A profile can use profile_route_node_evidence_check for automated evidence checks; requirement coverage and evidence validity still need assessment.
Run the standard profile checks, then validate and publish the route. Account for when changes take effect: publishing a new revision does not change the route pinned in an existing attempt.