diff --git a/06-canvases/README.md b/06-canvases/README.md
index d99f119..9d5a352 100644
--- a/06-canvases/README.md
+++ b/06-canvases/README.md
@@ -110,7 +110,7 @@ Before building your own canvas, try one from the community. [Awesome GitHub Cop
     ![Review panel + menu with Canvas open and Repository Issues Kanban highlighted](assets/app-open-repo-issues-canvas.webp)
 
 1. The board loads issues from the current repository and organizes them by status.
-1. Drag an issue between columns and notice how the canvas keeps state visible without scrolling through chat.
+1. Drag an issue between columns and notice how the canvas keeps state visible without scrolling through chat. When you move an issue to **Plan**, the canvas asks the agent to plan that issue in a background agent. The agent reads the issue and the code but does not edit files. When the plan is ready, the card moves to **Ready**. Each card that you move to **Plan** starts a new agent run, so move only one card there.
 
 Take a minute to move items around. This is the interaction model you will build on in Exercise 2.
 
@@ -136,8 +136,8 @@ Start with a small canvas that works like a shared checklist. You and the agent
 1. When the canvas opens, confirm that it has the proposal, checklist, and notes sections.
 1. Enter a short feature proposal.
 1. Mark **Plan** complete and add a next decision.
-1. Ask the agent to summarize the current board state. Confirm that its answer matches your updates.
-1. Open the **Changes** tab in the review panel and confirm that it lists no changed files. Creating a user-scoped canvas does not change repository files.
+1. Submit the prompt `Summarize the current Session Board state.` Confirm that the agent's answer matches your updates.
+1. In the review panel, open the **Changes** tab and confirm that it lists no changed files. If the tab is not open, select **+** (**Add tab**), then **Changes**. Creating a user-scoped canvas does not change repository files.
 
 **Expected Output:** The feature proposal, checklist, and notes remain visible on the board. You and the agent can both read and update them, but the board does not run tests or edit the app.
 
@@ -161,11 +161,13 @@ Exercise 2 showed how you and the agent can read and update the same proposal, c
 
     Top: horizontal progress rail = Propose -> Plan -> Baseline -> Implement -> Validate. No Approve stage. Approval happens in the chat's Plan tab. Green = evidence-backed done, neutral = current, red = failed/blocked.
 
-    Feature proposal: text input + one Generate plan button. Switches session to plan mode, fires prompt without waiting ("Working..." status), agent inspects code + writes plan as usual, presents for approval in Plan tab (never call exit_plan_mode/ask_user elsewhere). Don't render plan text on canvas. Show only a small status pill (Working/Review/Approved/Changes requested) polled from exit_plan_mode events. No edit/approve controls on the canvas itself.
+    Feature proposal: text input + one Generate plan button. Switches session to plan mode, fires prompt without waiting ("Working" status), agent inspects code + writes plan as usual, presents for approval in Plan tab (never call exit_plan_mode/ask_user elsewhere). Don't render plan text on canvas. Show only a small status pill (Working/Review/Approved/Changes requested) polled from exit_plan_mode events. No edit/approve controls on the canvas itself.
 
-    Checklist: baseline test, baseline build, implement approved plan, review diff, browser validation (when required), screenshots (when required), final test, final build.
+    Checklist: baseline test, baseline build, implement approved plan, review diff, browser validation, screenshots (optional), final test, final build.
 
-    Actions in order: Run baseline (test+build, record totals) -> Implement (approved plan only) -> Browser validation (start/reuse dev server, exercise feature, before/after screenshots) -> Run final checks (test+build) -> Refresh evidence. These 4 must never use plan mode/exit_plan_mode/ask_user (unattended), give each a multi-minute timeout not the ~60s default.
+    Actions in order: Run baseline (test+build, record totals) -> Implement (approved plan only) -> Browser validation (start/reuse dev server, check only the proposed behavior in the app's Browser tab, never start other browsers) -> Run final checks (test+build) -> Refresh evidence. These 4 must never use plan mode/exit_plan_mode/ask_user (unattended), give each a multi-minute timeout not the ~60s default. Return the session to interactive mode when each action ends. An action is done when its evidence is recorded; never require a matching chat reply.
+
+    Never block on tooling: screenshots are optional, count only PNG files actually saved. Browser checks the Browser tab can't run (e.g. real keyboard input) are notes, not failures. Run final checks is available after Implement even if Browser validation failed.
 
     Evidence: read-only, agent-posted only, no learner notes. Dense one-liners: baseline pass/fail pill, final pass/fail pill + total delta, browser summary + screenshot count, diff summary (files changed), blockers. Truncate long text. Green only if tests pass and final total >= baseline. Before any evidence: "Run a check or capture browser evidence to record it here."
 
@@ -183,13 +185,17 @@ Exercise 2 showed how you and the agent can read and update the same proposal, c
     | "never call exit_plan_mode/ask_user elsewhere" | Plan approval should only happen in the session's **Plan** tab, not through a canvas popup |
     | "polled from exit_plan_mode events" | The canvas checks the plan's approval status periodically instead of you having to refresh it |
     | "give each a multi-minute timeout" | Test, build, and browser actions can take longer than a typical quick response, so don't let the canvas give up early |
+    | "Never block on tooling" | If the agent cannot save a screenshot or run a browser check, it records a note and the workflow continues |
     | "user scope" | The canvas is saved to your machine across projects, not committed to this repository |
 
     </details>
 
     <img src="assets/app-create-canvas-command.webp" alt="The /create-canvas skill selected in the prompt box typeahead" width="800" />
 
-1. The canvas should open in the right side panel once the agent is done building it.
+1. The canvas should open in the right side panel once the agent is done building it. This can take about 10 minutes.
+
+    > [!TIP]
+    > While you wait, read [What this prompt is asking for, in plain language](#exercise-3-create-a-feature-workbench) above, then expand the agent's tool calls in the chat to see how it builds and tests the canvas. Do not submit other prompts in this session until the canvas opens, because a new prompt can change what the agent is building.
 
     > **Important:** Generated results can differ between runs. Check the expected structure below before you continue. Do not repeatedly regenerate the full canvas.
 
@@ -208,18 +214,36 @@ Exercise 2 showed how you and the agent can read and update the same proposal, c
     <details>
     <summary>Repair prompts (use the one matching what's wrong)</summary>
 
+    **Parts are missing:**
+
     ```text
     Keep the current canvas. Add any missing stages, checklist items, or actions from my original request. Do not redesign parts that already work.
     ```
 
+    **Items show as complete without evidence:**
+
     ```text
     Keep the current canvas. Update checklist and progress state only from recorded action evidence. Do not infer success from chat text.
     ```
 
+    **Actions stop before the work finishes:**
+
     ```text
     Keep the current canvas. Give baseline, implementation, browser validation, and final-check actions enough time to complete npm and browser work. Show loading, success, and error states.
     ```
 
+    **An action stays disabled:**
+
+    ```text
+    Keep the current canvas. Screenshots and browser checks must never block a stage or action. Count only screenshots that are saved as PNG files. Record checks that the Browser tab cannot run as notes, not failures. Let Implement run after a passing baseline, and let Run final checks run after Implement. Do not redesign parts that already work.
+    ```
+
+    **An action shows an error after its work is done, or the session stays in Autopilot mode:**
+
+    ```text
+    Keep the current canvas. Mark an action done when its evidence is recorded. Do not require a matching chat reply. Return the session to interactive mode when each action ends. Do not redesign parts that already work.
+    ```
+
     </details>
 
     If the canvas still does not match after two focused repairs, use the [Markdown fallback](#markdown-fallback) and continue with the validation steps manually.
@@ -230,25 +254,25 @@ Exercise 2 showed how you and the agent can read and update the same proposal, c
     Add a Clear filters control that resets search, genre, and reading status to their default values. Show it only when at least one filter is active.
     ```
 
-    The session switches to **Plan** mode and the agent writes an implementation plan. The canvas stays at **Propose** with the status **Working...**.
+    The session switches to **Plan** mode and the agent writes an implementation plan. The feature status shows **Working** until the plan is ready for review.
 
-    ![Feature Workbench at the Propose stage with the status Working... while the session is in Plan mode](assets/app-feature-workbench-propose.webp)
+    ![Feature Workbench with the Plan stage current and the status Working while the session is in Plan mode](assets/app-feature-workbench-propose.webp)
 
-1. Review the plan in the **Plan** tab. In the **Review plan** box at the bottom of the chat, select **Exit plan mode and I will prompt myself**. Then select the **Feature Workbench** tab to return to the canvas. The **Plan** stage should be complete, and the feature status should show **Approved**.
+1. Review the plan in the **Plan** tab. In the **Review plan** box at the bottom of the chat, select **Exit plan mode and I will prompt myself**. Do not select **Approve and implement this plan**: the agent would start to change the app before you record a baseline. The canvas still records your approval. Then select the **Feature Workbench** tab to return to the canvas. The **Plan** stage should be complete, and the feature status should show **Approved**.
 
     ![Feature Workbench with the Propose and Plan stages complete and the status Approved](assets/app-feature-workbench-plan.webp)
 
-1. Select **Run baseline** on the canvas to record the app's state before any change. In the chat, expand the tool calls for this action (`npm test -- --run` and `npm run build`). Confirm that the test total and build result on the canvas match their output.
+1. Select **Run baseline** on the canvas to record the app's state before any change. The action runs in **Autopilot** mode so that the agent does not stop to ask questions. When it ends, the session returns to **Interactive** mode. In the chat, expand the tool calls for this action. Depending on the generated canvas, they show the `npm test -- --run` and `npm run build` output or a check tool's result with the test totals. Confirm that the test total and build result on the canvas match that output.
 
-    ![Expanded npm test output with 4 passed tests, next to the Feature Workbench Baseline evidence of 4/4 tests and a passing build](assets/app-feature-workbench-baseline.webp)
+    ![Expanded check tool output with 4 total and 4 passed tests, next to the Feature Workbench Baseline evidence of 4/4 tests and a passing build](assets/app-feature-workbench-baseline.webp)
 
     The **Baseline** stage and its two checklist items should show as complete.
 
-1. Select **Implement** to build the feature from the approved plan. When it finishes, the **Implement** stage is complete and the evidence has a **Diff** row. Select the **Changes** pill above the prompt box and confirm that the changes are limited to the approved feature.
+1. Select **Implement** to build the feature from the approved plan. When it finishes, the **Implement** stage is complete and the evidence has a **Diff** row. Select the **Changes** pill above the prompt box and confirm that the changes are limited to the approved feature. Expect changes in `samples/book-app-web` files such as `src/App.tsx`, `src/components/BookFilters.tsx`, `src/styles/app.css`, and the test files.
 
     ![Feature Workbench with the Implement stage complete and a Diff row in the evidence, next to the Changes pill above the prompt box](assets/app-feature-workbench-implement.webp)
 
-1. Select **Browser validation** to have the agent check the feature in the browser. Then check these states yourself:
+1. Select **Browser validation** to have the agent check the feature in the **Browser** tab. This can take several minutes. Then check these states yourself in the app at `http://127.0.0.1:5173`. The agent usually opens it in a **Browser** tab named **Book App Web**. If it does not, select **+** (**Add tab**), then **Browser**, and enter the address.
 
     | State | Expected behavior |
     |---|---|
@@ -258,13 +282,15 @@ Exercise 2 showed how you and the agent can read and update the same proposal, c
     | You select **Clear filters** | Search, genre, and reading status return to their defaults |
     | Filters have been cleared | **Clear filters** is not visible, and the full book list and statistics return |
 
-    ![Feature Workbench with Browser evidence recorded while Browser validation still shows Working..., next to Copilot's report that browser validation passed](assets/app-feature-workbench-browser-validation.webp)
+    ![Feature Workbench with Browser evidence recorded and Browser validation done, next to Copilot's report of the checks that passed and the checks recorded as notes](assets/app-feature-workbench-browser-validation.webp)
 
-    When you finish the checks, select **Background** above the prompt box and stop the dev server. Until the dev server stops, **Browser validation** can keep showing **Working...**, even after Copilot reports the result.
+    When you finish the checks, stop the dev server. If the agent started it in the background, select **Background** above the prompt box and stop it. If the agent started it in a **Terminal** tab, close that tab and select **Close terminal**.
 
 1. Select **Run final checks**. Confirm that the tests and build pass, and that the final test total is at least the baseline total. The total can go up if the implementation added tests.
 
-    ![Feature Workbench with all five stages complete, and evidence that shows 4 baseline tests and 9 final tests](assets/app-feature-workbench-validate.webp)
+    ![Feature Workbench with all five stages complete, and evidence that shows 4 baseline tests and 14 final tests](assets/app-feature-workbench-validate.webp)
+
+**Expected Output:** All five stages are complete, and the evidence shows passing baseline and final checks, the browser result, and the changed files. Your test totals and file list can differ from the images, because the agent writes its own tests.
 
 <a id="markdown-fallback"></a>
 
@@ -330,6 +356,22 @@ Compare the canvas with the expected structure in the exercise. Then use the one
 
 Answer the **Review plan** box at the bottom of the chat. Then select **Refresh evidence** on the canvas.
 
+### An action button stays disabled
+
+The canvas enables each action only after the previous step has evidence. If **Implement** or **Run final checks** stays disabled because a screenshot or browser check could not run, use the **An action stays disabled** repair prompt in Exercise 3.
+
+### An action shows an error, but its stage is complete
+
+Some generated canvases show an error such as "No correlated agent response was saved" after the agent records the evidence. Use the **An action shows an error after its work is done** repair prompt in Exercise 3.
+
+### The session stays in Autopilot mode
+
+Canvas actions run in **Autopilot** mode. If the session does not return to **Interactive** mode after an action, change the mode in the prompt box. To fix the canvas for later actions, use the **An action shows an error after its work is done, or the session stays in Autopilot mode** repair prompt in Exercise 3.
+
+### More than one Feature Workbench tab opens
+
+The agent can open extra copies of the canvas while it tests the canvas. A copy can show **Load failed**, or it can open in a **Browser** tab. Close the extra tabs and keep the tab that has the canvas icon and shows your proposal and evidence.
+
 ### The Terminal or Browser tab is missing
 
 If the review panel is hidden, select **View** > **Toggle Review Panel**. In the review panel, select **+**, then **Terminal** or **Browser**. If the tab is still missing, update the app to the latest version.
diff --git a/06-canvases/assets/app-create-canvas-screenshot.webp b/06-canvases/assets/app-create-canvas-screenshot.webp
index 190c028..0c47472 100644
Binary files a/06-canvases/assets/app-create-canvas-screenshot.webp and b/06-canvases/assets/app-create-canvas-screenshot.webp differ
diff --git a/06-canvases/assets/app-feature-workbench-baseline.webp b/06-canvases/assets/app-feature-workbench-baseline.webp
index cc6bb91..4265198 100644
Binary files a/06-canvases/assets/app-feature-workbench-baseline.webp and b/06-canvases/assets/app-feature-workbench-baseline.webp differ
diff --git a/06-canvases/assets/app-feature-workbench-browser-validation.webp b/06-canvases/assets/app-feature-workbench-browser-validation.webp
index 7dca6bf..9c16305 100644
Binary files a/06-canvases/assets/app-feature-workbench-browser-validation.webp and b/06-canvases/assets/app-feature-workbench-browser-validation.webp differ
diff --git a/06-canvases/assets/app-feature-workbench-implement.webp b/06-canvases/assets/app-feature-workbench-implement.webp
index 54e5be2..472736a 100644
Binary files a/06-canvases/assets/app-feature-workbench-implement.webp and b/06-canvases/assets/app-feature-workbench-implement.webp differ
diff --git a/06-canvases/assets/app-feature-workbench-plan.webp b/06-canvases/assets/app-feature-workbench-plan.webp
index 67cc3d5..cb39b7d 100644
Binary files a/06-canvases/assets/app-feature-workbench-plan.webp and b/06-canvases/assets/app-feature-workbench-plan.webp differ
diff --git a/06-canvases/assets/app-feature-workbench-propose.webp b/06-canvases/assets/app-feature-workbench-propose.webp
index 04b32c1..b720829 100644
Binary files a/06-canvases/assets/app-feature-workbench-propose.webp and b/06-canvases/assets/app-feature-workbench-propose.webp differ
diff --git a/06-canvases/assets/app-feature-workbench-validate.webp b/06-canvases/assets/app-feature-workbench-validate.webp
index cf1a813..0cf5397 100644
Binary files a/06-canvases/assets/app-feature-workbench-validate.webp and b/06-canvases/assets/app-feature-workbench-validate.webp differ
diff --git a/appendices/troubleshooting-reference.md b/appendices/troubleshooting-reference.md
index 1a48691..b85ea74 100644
--- a/appendices/troubleshooting-reference.md
+++ b/appendices/troubleshooting-reference.md
@@ -93,6 +93,8 @@ Related chapter: [06 Canvases](../06-canvases/)
 | Canvas does not open | `/create-canvas` missing, or extension syntax, dependency, or reload issue | Retry `/create-canvas`, or keep the same board as markdown in the session |
 | Canvas state looks stale | Stored state and visible UI are out of sync | Refresh the canvas or rerun the action that updates state |
 | Agent action fails | Capability name or input schema mismatch | Check the action name, required fields, and stored state |
+| Workbench action stays disabled | A screenshot or browser check could not run and the canvas treats it as required | Use the **An action stays disabled** repair prompt in Exercise 3 |
+| Action shows an error after evidence is recorded | The canvas waits for a matching chat reply | Use the **An action shows an error after its work is done** repair prompt in Exercise 3 |
 | Canvas contains private content | Shared surface was used like private notes | Remove secrets, private repository details, and customer data from the canvas |
 
 ## Chapter 07: Automations