Testing & Verification

The Testing page is your quality gate. Every piece of work that Autopilot completes lands here for human review before it can be marked as done. Think of it as a pull request review experience purpose-built for AI-generated changes: you see what changed, why it changed, how to test it, and whether it actually deployed successfully. Nothing ships without a human saying "yes, this is right."

Why Testing Matters

Autopilot is powerful, but AI-generated code deserves the same scrutiny as any other contribution. The Testing page exists because trust is earned, not assumed.

• Every Autopilot-completed action item routes to Testing automatically — no manual triage needed.
• Items are held in "Pending Review" status until a human verifies them. They cannot be marked as done without verification.
• If your project has deployment monitoring enabled, the Verify button is gated: you cannot verify an item until its code has been successfully deployed. This prevents verifying code that has not actually been built and shipped.
• The full context of what was done — completion summary, testing notes, commits, pull requests, and implementation details — is shown inline so you never need to leave the page.
• If something is wrong, you can request changes with a note. The item is re-queued for Autopilot with your feedback attached, creating a tight feedback loop.

1. Finding the Testing Page

The Testing page is accessible from your project sidebar.

Step 1 — Open your project

Navigate to any project from the dashboard or sidebar. The project must have at least one action item that has been completed by Autopilot.

Step 2 — Click "Testing" in the sidebar

In the project sidebar navigation, click "Testing". This page shows all action items that are awaiting verification or have been recently verified.

Step 3 — Adjust the time range

Use the time range buttons (7d, 14d, 30d, 90d, All) at the top to control how far back you want to see. Items are grouped by date in a timeline view.

What You See for Each Item

Each testing brief gives you everything you need to make a verification decision without switching tools.

• Title and type badge (feature, bug, improvement, task) — what this change is about.
• Status badges — "Pending Review" for items awaiting your verdict, "Verified" for items you have approved, and the green "Deployed" badge showing when and where the code went live.
• Deployed badge — a green badge appears when the item's code has been successfully deployed. Click it to see the full deployment audit trail: which targets it deployed to, timestamps, commit SHAs, and whether any subsequent deployments failed. If a deployment failed after a success, the badge turns amber as a warning.
• Completion summary — a short, human-readable description of what was done. Written like a changelog entry.
• Testing notes — step-by-step instructions for manually testing this change. Follow these to verify the work.
• Implementation details — expandable section showing commits, pull requests, affected files, and detailed implementation notes from Autopilot.
• Session link — jump to the originating AI session to understand the full conversation context behind this change.

2. Verifying an Item

When you are satisfied that the change is correct, verify it to mark it as done.

Step 1 — Review the testing notes

Read the testing notes provided by Autopilot. These are step-by-step instructions for manually verifying the change. Follow them in your browser or local environment.

Step 2 — Check the deployed badge

If your project has deployment monitoring enabled, look for the green "Deployed" badge. This confirms the code has been built and shipped successfully. If the badge is not present, the Verify button will be disabled with a tooltip explaining that deployment is required first.

Step 3 — Click Verify

Click the green "Verify" button. The item is marked as done, the original creator is notified, a verification event is injected into the originating session for traceability, and the item becomes visible in the project Changelog.

The deployment gate is a safety feature: it prevents you from verifying code that has not actually been deployed. If you need to bypass this (e.g., for non-deployed changes), use the "Mark as Deployed" escape hatch on the action item detail page.

3. Requesting Changes

If the change is not right, send it back to Autopilot with feedback.

Step 1 — Click "Request Changes"

Click the amber "Request Changes" button on the item. A text area expands where you can describe what needs to be fixed.

Step 2 — Describe the issue

Write a clear description of what is wrong or what needs to change. Be specific — this feedback is attached directly to the action item when it is re-queued for Autopilot.

Step 3 — Submit

Click "Re-queue". The item is sent back to Autopilot with your feedback as context. Autopilot will attempt the fix again, and the item will return to Testing when complete. The attempt count is tracked so you can see how many iterations an item has been through.

Tidying a Brief: Defer, Move to Follow-up, Dismiss

Sometimes a brief is finished except for one child that you do not want to verify right now — it might be future work, or a deliberately-deferred "V2". Rather than letting it hold the whole brief open on the Testing page, each child row has three controls beyond verify:

• Defer (pause icon) — park the child for later. It drops off the Testing page into the Deferred lane and stops holding the brief open, but it is kept and reversible (Resume it anytime). Use this when the work still belongs to this feature.
• Move to follow-up (branch icon) — extract the child into its own standalone follow-up item, with a "derived from" link back to the brief. The brief completes and stays completed; resuming the follow-up later won't reopen it. Use this when the work is genuinely separate future work (e.g. a deferred V2).
• Dismiss (✕) — drop the child entirely (won't do).

Once every child of a brief is verified, dismissed, or deferred, the brief auto-completes and leaves the Testing page — keeping the board down to just what genuinely needs your attention.

The Deployed Badge

The Deployed badge is a visual indicator that the code behind an action item has been successfully built and shipped.

• Green badge — the code deployed successfully and no subsequent deployment has failed. Everything is healthy.
• Amber badge — the code deployed successfully at some point, but a later deployment for the same item failed. The original deployment data is preserved, but the amber color signals that something may need attention.
• Click the badge — a popover appears showing the full deployment audit trail: every deployment event (succeeded, failed, retried) with timestamps, target names (e.g., "Staging", "Production"), platforms (Vercel, Netlify, etc.), and commit SHAs.
• "Mark as healthy" — if the amber state is a false alarm (e.g., the issue was fixed outside the normal pipeline), click "Mark as healthy" in the popover to reset the badge to green.
• The badge appears everywhere action items are shown: the Testing page, Autopilot page, action item list, action item cards, and action item detail view.

Understanding the Workflow

The testing workflow is designed to be a tight loop between Autopilot and human reviewers.

• Autopilot picks up an action item and implements it (writes code, creates commits, opens PRs).
• When done, it marks the item as "completed" with testing notes, a completion summary, and affected files.
• If the project requires verification (most do), the item is automatically routed to "Pending Review" status.
• If deployment monitoring is configured, DevSpec waits for the deployment to succeed before enabling the Verify button.
• A tester opens the Testing page, reviews the brief, follows the testing notes, and either verifies or requests changes.
• If changes are requested, the item goes back to Autopilot with feedback — creating a human-in-the-loop refinement cycle.
• Once verified, the item is marked as done, the original session is updated with the verification event, and the item appears in the project Changelog as a verified entry.