Testing & Verification

The Testing page gathers implementation evidence: what changed, commits and pull requests, affected files, testing notes, acceptance-criterion verdicts, and deployment status. It is a review surface, not a work router and not a separate hardcoded completion policy.

Lifecycle/completion authority is served at devspec://product/implementation-contract. DevSpec may promote lifecycle from recorded evidence where configured, while explicitly authorized verification remains a separate path. Clients should display the state returned by the server rather than assuming one fixed client-side transition.

Finding work to review

Open Testing from the project sidebar. The page shows items with implementation evidence and recent verification activity. Use the time-range filters to narrow the view.

Each brief may include:

• implementation summary and detailed notes;
• testing instructions;
• acceptance criteria and recorded verdicts;
• commits, pull requests, and affected files;
• originating session and immutable requester provenance; and
• deployment audit status when monitoring is connected.

Recording verification

Observe the change through an appropriate layer — tests, deployed behavior, logs, database state, or another configured verifier — and record what was checked and what came back. Code inspection alone is inference, not runtime evidence.

Where a present authorized user chooses the Verify action, DevSpec records that decision and applies the served contract. The UI must not promise a particular done transition independently of the server response.

Deployment monitoring can independently gate verification surfaces until the relevant deployment succeeds. This is deployment safety, not implementation work delivery.

Requesting changes

If the implementation needs more work, record clear feedback and create/reuse the appropriate follow-up request. Do not silently send the item back to an agent.

To implement the correction:

1. a user explicitly requests the named work, or sends a canonical command to an exact connection whose current command_authority authorizes that owner/delegated requester;
2. the agent calls reserve_work_items for the requested ids in order;
3. the agent calls claim_work_item one at a time; and
4. the new implementation and evidence return to Testing.

Internal assignment/reservation rows coordinate the claim only. Controls and explicit owner-scoped automation runs remain separate.

Tidying a brief

• Defer parks a child for later and remains reversible.
• Move to follow-up extracts separate future scope into a linked standalone item.
• Dismiss records a won't-do decision.

The server determines the resulting brief/item lifecycle from the configured contract and recorded evidence. The page should not duplicate that policy in prose.

Deployment badge

• Green — a relevant deployment succeeded and no later known failure supersedes it.
• Amber — a later deployment needs attention.
• Open the badge for target, timestamps, commit SHA, and retry/failure history.

Deployment retries concern deployment operations. If code changes are required, DevSpec records a fix item with evidence and waits for an explicit implementation request; it does not route the fix to a runner.