Facilitate and recover

Skills and Canvas

• The three Java skills are repository-bundled; impeccable is App-bundled. Invoke it with /impeccable. Demonstrate loading guidance, not reinstalling the workshop’s pinned copies.
• Follow the Canvas chapter: open the running shop and focus on one observed UI issue with Pick & polish. No instruction-file editing exercise is needed.
• Use three named task sessions: Cart: quantity bug, Cart: item removal (including Canvas) and Cart: query optimization. Merge and verify each task’s PR before starting the next from updated main; name sessions only after their first prompt. Participants create sessions in the App UI, without changing agent instructions.
• Confirm this worktree owns the running shop before refreshing UI edits; a matching URL is not enough. If ownership is unknown or different, use the human-run server handoff rather than touching another checkout’s app.
• Keep the shop running during same-worktree edits. DevTools reloads compiled backend changes; Maven tests compile Java and copy resources. After approved UI edits, Copilot runs ./mvnw compile, reloads the existing Browser canvas and verifies the visible change; no manual refresh is needed. An automatic restart resets cart data; static-resource updates normally do not. Stop/start manually when switching the running app to another worktree or for recovery.

Review and five-subagent checkout

• Approve a read-only independent critic for rubber ducking without editing the verification checkout’s AGENTS.md. Use an actual critic, not a main-agent reread. On the normal path, merge and verify accepted corrections through a follow-up PR before checkout; local recovery keeps the checked local branch.
• Start a fresh Cart: mock checkout session using New worktree from verified main, including merged critique corrections. The App creates the feature branch. If using local recovery, explicitly select and verify the recorded reviewed local base instead.
• Prepare the checkout plan in Plan mode. Approve the contract, plan, file ownership and local handoffs, then return to Interactive without implementing. The /orchestrate prompt creates exactly five coordinated child sessions, each with its own worktree and branch. No /fleet, nested agents or custom profiles. The starter instructions already provide this scoped allowance; no AGENTS.md edit is needed.
• Approve five-way concurrency after a machine-load check. Start backend, UI, HTTP tests, resilience tests and a read-only reviewer together from the same reviewed commit. Agree on HTTP behavior, test setup/probes and exclusive fixture ownership first. Do not wait for backend implementation before starting the others; record actual overlap or the concurrency limitation.
• Four writers provide local commits; the reviewer provides findings tied to commits, including the final integrated head. The orchestrator owns integration, Maven and preview. Preserve all worktrees; no child publishing, merging, shops, Maven runs or nested agents.
• Check all earlier reviewed tests, boundary cases and new checkout tests, including CheckoutContractTest and CheckoutResilienceTest. Verify rollback, immutable receipts, concurrent duplicate requests and replay after new cart items. Wait for DevTools to load compiled changes, then place an order in the Browser canvas.
• After final review, use Create PR in Cart: mock checkout, then reuse Agent Merge. Keep Merge pull request off while reviewing repairs; authorize this checkout PR’s merge separately once checks and approvals pass. Have the same reviewer recheck repairs before merge approval; record later repair/review limitations. Workers never publish or merge. Verify exact merged main and that the shop serves its compiled code from the verified directory; change the running server’s worktree only if needed.

Evidence and privacy

Confirm /chronicle tips is available in your build. Focus on token efficiency, agent turnaround and output quality; cost-tips is an optional drill-down. History may span repositories or still be indexing. Never project unrelated private work, invent missing usage figures or treat a later filter as undoing earlier access.

For the final review, compare the recorded starter and verified result commits, keeping unfinished edits separate. Corrections need a new approved feature branch and reviewed PR; leave the verification checkout unchanged. Keep private Chronicle output out of the handoff.

Record App actions only when their actual responses are available. Shop screenshots and saved HTTP captures do not prove an App interaction. Run newcomer and experienced pilots, including navigation and recovery.

Interrupted sessions

Read the actual partial handoff first: source directory/revision, unfinished files, executed outcomes and owned helpers. Confirm cleanup before starting another preview. A query error with no detailed cause is not proof of an authentication failure. After a bounded retry following recovery, stop if the same failure repeats; do not create a retry or replacement-agent loop.

If the participant approves a facilitator or single-agent takeover, record the execution-method change. Preserve earlier failures and coverage gaps; delivered code is not proof that the original independent or native App exercise completed.

Expected reference results

The pinned revisions and recorded checks cover the three earlier tickets, not checkout. These historical pins also predate current-starter input and keyboard hardening; their counts and captures describe those exact revisions, not today’s main. The table uses historical reference tests. In the normal workshop, participants generate CartContractTest, RemoveContractTest and QueryContractTest; their counts and failures vary. The current learner starter contains no ready-made exercise tests.

Maintainer test snapshots live at workshop/tools/copilot-workshop/reference-tests/ in this repository, excluded from the published site. The pinned historical checkpoints below retain their own teaching/ classes for reproducing these recorded counts. Use those files only in a separate reference checkout; never replace reviewed learner tests. Boundary and checkout tests add cases beyond the historical 12.

Recover without losing work

Use a new directory, never the participant’s project. This quantity-fix example checks out the full pinned commit, not a movable tag:

git clone --no-checkout https://github.com/jdubois/github-copilot-app-java-workshop.git cart-reference-bugfix
cd cart-reference-bugfix
git switch -c reference-work 8291261524b5e20ce86c111abe909877d8510776
git rev-parse HEAD

Confirm the printed SHA matches. For another checkpoint, use its full SHA below and a fresh directory name. If the commit is unavailable, stop.

1. Connect a new App session to the reference copy. Check its directory and starting commit; activate any required teaching tests there and run the matching checks.
2. Use that reference session only for the blocked task, committing reviewed results. For removal recovery, complete Canvas there too. Do not use the reference clone as the next task’s base.
3. For performance recovery, restore any accepted Canvas UI changes, check startup paths for this copy, and activate all three teaching classes unchanged. Confirm all 12 supplied tests pass before parallel work.
4. To resume GitHub delivery, apply the reviewed reference changes and any accepted Canvas work in a new worktree based on the participant’s own main. Review the complete diff and rerun tests, then deliver those recovery changes through a reviewed PR. If GitHub is blocked, use the linked local recovery instead.

Do not push this clone: its origin is the template, not the personal repository. Template-created repositories have independent history; changing the remote alone does not make reference commits mergeable. Never merge unrelated histories, overwrite personal main or replace an existing handoff branch.

Stop the old shop in its owning terminal before starting the reference copy. Record that a reference solution was used. Reference copies do not include the participant’s Canvas changes, new boundary tests or checkout.

These are one reference history in the template repository, not separate repositories or archives. Earlier v1 checkpoints remain unchanged.

The capture manifest pins source revisions, image/response hashes, runtime identities and the capture JVM version, which differs from the Java 21 compilation target. Saved MCP responses were captured using HTTP JSON-RPC, not through the App.

Code, skills, test CI and this handbook live in this repository. Run its maintainer gate, python3 tools/verify-checkpoints.py, from the repository root. For handbook builds and reference captures, change into workshop/ first:

cd workshop
CAPTURE_CHANNEL=chrome python3 tools/copilot-workshop/capture-all.py --port 18767
bundle exec jekyll build --destination tools/copilot-workshop/.build/site
python3 -m unittest discover -s tools/copilot-workshop -p 'test_*.py'
python3 tools/copilot-workshop/check-site.py --remote

The local gate checks matched request IDs/runtime identities, eight distinct products, €115 totals and the 9-to-1 SELECT change. --remote also checks live annotated tags against the pins; local success does not establish remote state or a successful website workflow. Checkpoint tags are protected against updates and deletion.