Workshop Section: 1 — Measure the Fixed Session Tax
Objective: Identify what a programmatic invocation pays for before it starts working, and design a baseline experiment that could prove it.

Starting State

You are handed the following lane description. Nothing has been measured.

LANE: nightly-dependency-audit
Runs:        1 invocation per repository per night, 240 repositories
Invocation:  copilot -p "$PROMPT" --allow-all-tools
Working dir: /home/automation/workspaces/monorepo-parent/<repo>
Discovered:  AGENTS.md at the monorepo parent (human onboarding guide, long)
             .github/copilot-instructions.md in each repository (short, mechanical)
             3 MCP servers configured at user scope (issue tracker, wiki, code search)
             2 skills installed at user scope
Model:       not specified
Effort:      not specified
Memory:      not specified
Output:      plain text captured to a log file
Task:        list dependencies with known advisories and open one issue per finding

Steps

1. (3 min) List every contributor to this lane's session tax. For each, mark it REQUIRED, OPTIONAL, or UNKNOWN for this task, and name the instrument you would use to inspect it.
2. (3 min) List every unbounded or unspecified element that could change cost from night to night.
3. (4 min) Write a baseline experiment for one single factor. Specify: probe prompt, pinned configuration, number of repetitions, recorded fields, and the one variable that changes between arms.

Expected Result

A one-page inventory plus a baseline experiment that a colleague could run without asking you a question.

Answer Key

Session-tax contributors

Unbounded or unspecified elements

• No --model, so the lane inherits a default that can change without review.
• No --effort, so reasoning depth is unpinned.
• --allow-all-tools grants full tool permission; there is no visibility restriction at all.
• No --max-ai-credits, so a single pathological repository has no per-run ceiling.
• No --no-ask-user, so an unattended run can stall waiting for input.
• Working directory sits under a parent that carries a long human-oriented instruction file.
• Advisory output size per repository is unbounded.
• Plain-text output makes per-run accounting hard; --output-format=json would be machine-readable.

Baseline experiment (example)

• Probe prompt: Reply with the single word OK.
• Pinned: one model, --effort low, one working directory, fresh session per run, --no-ask-user, --output-format=json. Do not add -s — it prints only the agent response and suppresses the stats you are trying to measure.
• Arms: (A) current discovery as-is; (B) identical, plus --disable-builtin-mcps.
• Repetitions: at least 5 runs per arm; report median and range.
• Recorded fields: AI credits, input/cached-input/output tokens, latency, outcome, exit status.
• Second experiment, run separately: repeat the same design with --no-custom-instructions as the single variable. One arm, one variable — never both in the same comparison.
• Follow-up arm: repeat with 3 representative real repositories to check quality parity before adopting arm B.

Success Criteria

• ✅ Every contributor is classified REQUIRED, OPTIONAL, or UNKNOWN with a named instrument
• ✅ At least four unbounded or unspecified elements are identified, including the missing model pin
• ✅ The baseline experiment changes exactly one variable and specifies repetitions
• ✅ The plan includes a real-task quality check, not only the trivial probe
• ✅ No token or credit figure is invented from memory

Workshop Section: 2 — Lane Profiles
Objective: Build least-context, least-tool, least-permission profiles and state the evidence required before adopting each reduction.

Starting State

Use the Lane Profile Worksheet (templates/lane-profile-worksheet.md, printable copy in Appendix B). Your fleet has three lanes:

Steps

1. (9 min) Complete one worksheet per lane. Fill every field; write UNKNOWN — measure rather than guessing.
2. (3 min) For each reduction you propose (fewer tools, no MCP servers, no custom instructions, lighter model, lower effort), write the evidence you would require before adopting it in production.
3. (3 min) Identify the one field in each lane most likely to cause a silent failure if you get it wrong.

Expected Result

Three completed worksheets where every restriction is enforced by a flag, not by prompt wording.

Answer Key

Lane A — Repository audit (read-only)

Lane B — Bounded test fix

Lane C — Release-note synthesis

Evidence required before adopting any reduction

• A baseline and a reduced arm measured on the same representative task mix.
• Durable acceptance and human correction time compared, not just tokens or credits.
• A canary lane, a rollback trigger, and an owner (Lab 6).

Success Criteria

• ✅ All three worksheets have every field completed or explicitly marked UNKNOWN — measure
• ✅ Every read-only claim is enforced by a visibility or permission flag
• ✅ Each proposed reduction has named evidence attached
• ✅ Lane B specifies an escalation rule that lives in code, not in operator habit
• ✅ Each lane names its most likely silent-failure field

Workshop Section: 3 — Isolation, Worktrees, and Concurrent Ownership
Objective: Find inheritance and ownership defects that cause duplicate or misconfigured spend.

Starting State

WATCHER 1: "failing-tests"   — scans all repositories every 10 minutes for failing tests
WATCHER 2: "flaky-tests"     — scans the same repositories every 15 minutes for flaky tests
Both watchers:
  - run as the same automation identity
  - share one checkout at /srv/agents/workspace
  - build the prompt, then invoke Copilot CLI with --allow-all
  - delete the queue item as soon as the CLI exits with status 0
  - have no attempt limit per target
  - were recently moved from /srv/monorepo/tools to /srv/agents to "reduce inherited context"

Steps

1. (4 min) List every defect you can find. Group them as inheritance, ownership, isolation, or landing defects.
2. (3 min) For each ownership defect, specify the fingerprint, lease, and dedupe rule that fixes it.
3. (3 min) Specify the verification step that proves the move to /srv/agents did not silently remove needed configuration.

Expected Result

A defect list with a concrete fix for each, including one verification command.

Answer Key

Success Criteria

• ✅ At least six defects identified and categorized
• ✅ A fingerprint, lease, and dedupe rule specified for the overlap
• ✅ Per-worker workspace isolation with cleanup specified
• ✅ The verification step names running the inventory from the harness's actual working directory
• ✅ The premature acknowledgment defect is identified as a landing problem, not a cost problem

Workshop Section: 4 — Pre-Spend Gates, Cache Correctness, and Prompt Budgets
Objective: Find cache-key omissions and name the specific wrong result each one can produce.

Starting State

Use the Cache-Key Review Worksheet (templates/cache-key-review-worksheet.md, printable copy in Appendix B). A team ships this cache to avoid re-scoring unchanged files:

CACHE DESIGN v1
  key            = sha256(file_contents)
  value          = { score: int, rationale: string }
  ttl            = none
  negative cache = yes, failures cached like successes
  bypass         = none
  provenance     = none
  invalidation   = manual, by deleting the cache directory
NOTES
  - The scoring rubric lives in prompts/rubric.md and is edited about twice a month
  - The lane recently changed from a lighter model to a mid-tier model
  - Reasoning effort was raised from low to high last week
  - Some entries were written before the team added a "severity" field to the value

Steps

1. (6 min) List every missing key component and, for each, the specific wrong outcome it can produce.
2. (5 min) Rewrite the cache design: key components, value schema, provenance, TTL, invalidation, negative-result policy, and bypass.
3. (4 min) Decide what the system should do when it encounters an entry written before the schema change.

Expected Result

A corrected cache design that a reviewer could approve without further questions.

Answer Key

Corrected design (example)

CACHE DESIGN v2
  key = sha256(
          rendered_prompt          # includes rubric and template text
        + rubric_version
        + model_id
        + reasoning_effort
        + context_tier
        + tool_visibility_set
        + tool_permission_set
        + mcp_config_hash
        + input_state_hash        # file contents plus relevant neighbors/config
        + harness_version
        + cli_version )
  value       = { schema_version, score, severity, rationale, produced_at, run_id }
  provenance  = { key_components, lane, profile_hash, accepted_later: bool }
  ttl         = 30 days, plus immediate invalidation on any profile change
  negative    = cache deterministic refusals only; never cache service_unavailable
  bypass      = harness --no-cache flag (your runner, not a Copilot CLI option), logged every time it is used
  migration   = entry missing any key component or schema_version -> treat as MISS

Old-schema entries: treat as a miss and re-run. Never infer a missing field, and never serve a value whose schema version is unknown.

Success Criteria

• ✅ At least eight missing components identified
• ✅ The rendered-prompt/rubric omission is identified as the highest-severity defect
• ✅ The corrected key includes model, effort, context tier, tool sets, and versions
• ✅ Negative caching distinguishes deterministic refusals from transient failures
• ✅ Missing or unknown key components are treated as a cache miss

Workshop Section: 5 — Runtime Governance
Objective: Map real run results to outcomes, retry behavior, breaker counting, and queue action.

Starting State

Use the Failure Taxonomy and Breaker Worksheet (templates/failure-taxonomy-worksheet.md, printable copy in Appendix B). Today the dispatcher has exactly two outcomes: ok (exit status 0) and failed (anything else). Failures are retried immediately up to 10 times, and 5 consecutive failures trip a breaker that parks the lane for 7 hours.

Steps

1. (8 min) Classify each of the nine run results below: outcome name, retry behavior, whether it counts toward the breaker, and queue action.
2. (4 min) Identify which current behaviors cause a retry storm, a breaker misfire, or silent work loss.
3. (3 min) Propose the backoff schedule, park window, breaker rule (including how long the breaker stays open), and dead-letter policy you would ship instead.

Run results to classify

1. The test named in the work item already passes before any model call.
2. The model edited a file, but the deterministic test still fails.
3. The CLI returned a permission error because the lane denies write and the task requires it.
4. The prompt assembler found the diff exceeds the lane's input budget.
5. The service returned a transient network error after 40 seconds.
6. The harness budget module refused the call before it was made: the lane's window envelope was already spent.
7. The lane profile references a model name the CLI does not recognize.
8. The run succeeded and the report was written, but the consumer directory does not exist.
9. The run started, consumed nearly all of its per-run --max-ai-credits cap, and stopped mid-task without producing a usable result.

Answer Key

Current behaviors that break

• Retry storm: immediate retries with no backoff, plus retrying policy_denied, context_too_large, and invalid_config, which can never succeed on retry.
• Most expensive retry storm: retrying run_cap_exhausted unchanged — every attempt pays close to the whole cap and lands nothing.
• Breaker misfire: counting every non-zero exit toward the streak lets routing, budget, and configuration errors trip the breaker and take down a healthy lane.
• Silent work loss: treating exit status 0 as success acknowledges case 8, where nothing landed.
• Attempt-ledger corruption: counting case 6 as an attempt eventually dead-letters work that was never actually tried.
• Throughput loss: a 7-hour park is far longer than most incidents last.

Recommended replacement

• Backoff: 10m → 20m → 40m with jitter, capped at 40m; maximum 3 attempts per fingerprint.
• Park on budget_refused for a fixed window (30 minutes is a reasonable start); log one summary line, not one line per item; leave the attempt counter untouched.
• On run_cap_exhausted: record the spend against the lane, increment the attempt counter, and block further attempts on that fingerprint until the work item is decomposed or the cap is changed by a named owner.
• Breaker: 5 consecutive model_failure outcomes only; open for 20 minutes, then half-open with exactly one probe item — close on success, reopen for another 20 minutes on failure; alert the lane owner on every trip.
• Dead-letter after the attempt cap with last outcome, profile hash, and transcript pointer retained.

Success Criteria

• ✅ All nine results classified with outcome, retry, breaker, and queue action
• ✅ already_green and context_too_large are excluded from breaker counting
• ✅ Case 6 and case 9 are given different outcomes, and only case 9 records spend and increments the attempt counter
• ✅ Case 8 is retained rather than acknowledged
• ✅ Retry storm, breaker misfire, and silent work loss are each identified with a cause
• ✅ The proposed backoff, park window, breaker rule (including open duration), and dead-letter policy are specific

Workshop Section: 6 — Durable Landing, Telemetry, Canary Rollout, and Capstone
Objective: Produce a canary-ready plan for one real lane, with a quality gate, a rollback trigger, and an owner.

Starting State

Each group picks one anonymized real lane from a member's environment (or Lane A, B, or C from Lab 2 if no real lane is available). You will need your Lab 1–5 outputs.

Steps

1. (6 min) Complete the Fleet Lane Optimization Checklist section of the canary scorecard (templates/canary-scorecard.md, printable copy in Appendix B) for that lane: profile, gates, governance, landing, telemetry.
2. (4 min) Complete the Canary Scorecard: the single variable you will change, the baseline you will capture, the quality-parity gate, the cost metric, the rollback trigger, and the owner.
3. (2 min) Each group reports one line: "Our canary lane is X, our single variable is Y, and we roll back if Z."

Expected Result

One completed scorecard per group, ready to take back to a real backlog.

Answer Key — Model Response

A complete scorecard names all of the following:

• Canary lane: highest volume with the lowest blast radius and a clear acceptance signal.
• Single variable: exactly one profile element (for example, disabling two MCP servers that the audit lane never uses).
• Baseline: median and range for credits, latency, retries, and durable acceptance over a stated window before the change.
• Quality-parity gate: durable acceptance and human correction time must not regress beyond an agreed tolerance.
• Cost metric: full cost per durable accepted outcome — not tokens saved.
• Adversarial review: integration seams, cache-key completeness, flag spelling, exit-code blast radius.
• Rollback trigger: a specific, pre-agreed threshold and a named person allowed to pull it without a meeting.
• Deployment verification: restart the worker and confirm the new behavior in live logs.

Success Criteria

• ✅ The checklist is complete for one specific lane, with unknowns marked UNKNOWN — measure
• ✅ Exactly one variable is changed in the canary
• ✅ A quality-parity gate is stated in measurable terms
• ✅ The cost metric is full cost per durable accepted outcome
• ✅ A rollback trigger and a named owner are recorded
• ✅ Deployment verification in live logs is included

Optional. Not required for any learning objective. This appendix spends AI credits.

⚠️ Safety and Scope

Important: Command syntax reflects GitHub documentation verified on 2026-08-12 and copilot help output from CLI v1.0.79. Verify option spellings and values against copilot help for your installed version before running. An unknown option is rejected — the CLI prints error: unknown option '<flag>' and exits non-zero without making a model call. The fail-open risk is a valid flag carrying a wrong or unverified value, which parses cleanly and silently restricts nothing.

Shell note: Commands are given PowerShell-first (Windows), with a bash alternative under each step. Run one or the other consistently — do not mix them in a single run. In PowerShell, output is captured with | Set-Content -Encoding utf8 rather than > so the file encoding is predictable.

Prerequisites Check

Step 1 — Version (proves the CLI is installed; it does not prove authentication)

copilot --version

copilot --version

Step 2 — Authentication (a separate check)

CLI v1.0.79 exposes no non-interactive "auth status" subcommand, so authentication is confirmed either by an interactive login or by the first real run in Exercise A2 failing or succeeding. If you have not authenticated on this machine, do it now:

copilot login

copilot login

Automation-style alternative: export a supported token instead of logging in. The CLI reads COPILOT_GITHUB_TOKEN, then GH_TOKEN, then GITHUB_TOKEN. Never paste a token into a command line that will be captured in a transcript or shell history.

Step 3 — Sandbox repository and clean tree

Set-Location <PATH-TO-YOUR-SANDBOX-REPOSITORY>
git status

cd <PATH-TO-YOUR-SANDBOX-REPOSITORY>
git status

Step 4 — Scratch directory for outputs

New-Item -ItemType Directory -Force -Path .\.module4-probe | Out-Null

mkdir -p ./.module4-probe

Confirm you are in a sandbox repository you own with a clean working tree before continuing.

Setup Checkpoint

• ✅ copilot --version prints a version (installation confirmed)
• ✅ You have either completed copilot login or exported a supported token (authentication addressed separately from version)
• ✅ You are inside a non-production sandbox repository you own, and git status shows a clean tree
• ✅ You have spend authorization and know your credit cap for this exercise
• ✅ The scratch directory ./.module4-probe exists

Exercise A1 — Establish the Zero-Cost Inventory (8 min)

Objective: See exactly what this working directory would contribute to a session, without making a model call.

1. Run the inventory from the directory your automation would use:

   copilot plugins list
   

   copilot plugins list
   

2. Capture a machine-readable copy:

   copilot plugins list --json | Set-Content -Encoding utf8 .\.module4-probe\inventory-before.json
   

   copilot plugins list --json > ./.module4-probe/inventory-before.json
   

3. Inspect only MCP servers and instruction sources:

   copilot plugins list --kind mcp --kind instruction
   

   copilot plugins list --kind mcp --kind instruction
   

Expected result: A grouped listing by kind and configuration scope. copilot plugins list performs discovery and does not make a model call. If you cannot run it, use the Backup Path: Sample Inventory Output section earlier in this guide — the sample is illustrative and synthetic.

Checkpoint: You can name every MCP server, skill, plugin, and instruction source this directory would contribute — and identify at least one your automation would not need.

Note: Custom agents and session-scoped hooks are not covered by copilot plugins list; they require a live session. Do not treat this inventory as complete evidence of everything a session loads.

Success criteria

• ✅ Inventory captured to inventory-before.json
• ✅ At least one discovered resource identified as unnecessary for a hypothetical audit lane
• ✅ No model call was made in this exercise

Exercise A2 — Run a Bounded Baseline Probe (12 min)

Objective: Measure a minimal invocation with everything pinned and bounded.

Warning: This step spends AI credits. The cap is set to 40: CLI v1.0.79 rejects anything below 30, and GitHub's documentation advises setting session limits above 30 because most model calls cost more than 20 AI credits. Do not raise it if the run stops — a stop is the control working.

Note: -s (--silent) is deliberately omitted. It prints only the agent response and suppresses run stats, which is the opposite of what a measurement probe needs. Add it only in a production lane where you have proven the JSONL channel carries the fields you depend on.

1. Run the baseline probe:

   copilot -p "Reply with the single word OK." `
     --no-ask-user `
     --model claude-haiku-4.5 `
     --max-ai-credits 40 `
     --output-format=json `
     --share .\.module4-probe\baseline-transcript.md |
     Set-Content -Encoding utf8 .\.module4-probe\baseline.jsonl
   

   copilot -p "Reply with the single word OK." \
     --no-ask-user \
     --model claude-haiku-4.5 \
     --max-ai-credits 40 \
     --output-format=json \
     --share ./.module4-probe/baseline-transcript.md \
     > ./.module4-probe/baseline.jsonl
   

2. Inspect the JSONL output:

   Get-Content .\.module4-probe\baseline.jsonl -TotalCount 5
   

   head -n 5 ./.module4-probe/baseline.jsonl
   

3. Inspect the transcript:

   Get-Content .\.module4-probe\baseline-transcript.md -TotalCount 40
   

   head -n 40 ./.module4-probe/baseline-transcript.md
   

4. Record what your version actually reports: which fields exist, and whether any of them expose per-call cost.

Expected result: A completed run, a JSONL file, and a Markdown transcript.

Checkpoint: You can state, from evidence rather than assumption, which usage fields your installed CLI emits.

Note: --model values change over time and differ by plan and host. If the model string above is not available in your environment, substitute a lightweight model you know is available and record the substitution. Treat an unrecognized model name as a configuration error to fix — do not assume the CLI substitutes another model for you; that behavior is unverified and sits in the workshop's claim ledger.

Success criteria

• ✅ The run completed within the credit cap
• ✅ baseline.jsonl exists and was inspected
• ✅ A transcript was written locally (not to a gist)
• ✅ You recorded which usage fields are present, rather than assuming

Exercise A3 — Run a Single-Variable Comparison (12 min)

Objective: Change exactly one factor and observe the difference.

The only difference between this arm and Exercise A2 is --disable-builtin-mcps. Everything else — prompt, model, credit cap, and output format — stays identical, which is what makes the two runs comparable.

1. Run the same probe with built-in MCP servers disabled:

   copilot -p "Reply with the single word OK." `
     --no-ask-user `
     --model claude-haiku-4.5 `
     --max-ai-credits 40 `
     --disable-builtin-mcps `
     --output-format=json `
     --share .\.module4-probe\reduced-transcript.md |
     Set-Content -Encoding utf8 .\.module4-probe\reduced.jsonl
   

   copilot -p "Reply with the single word OK." \
     --no-ask-user \
     --model claude-haiku-4.5 \
     --max-ai-credits 40 \
     --disable-builtin-mcps \
     --output-format=json \
     --share ./.module4-probe/reduced-transcript.md \
     > ./.module4-probe/reduced.jsonl
   

2. Compare the first 60 lines of each transcript. Write both extracts to files first — no process substitution, so the same approach works in both shells:

   Get-Content .\.module4-probe\baseline-transcript.md -TotalCount 60 |
     Set-Content -Encoding utf8 .\.module4-probe\baseline-head.txt
   Get-Content .\.module4-probe\reduced-transcript.md -TotalCount 60 |
     Set-Content -Encoding utf8 .\.module4-probe\reduced-head.txt
   Compare-Object (Get-Content .\.module4-probe\baseline-head.txt) (Get-Content .\.module4-probe\reduced-head.txt)
   

   head -n 60 ./.module4-probe/baseline-transcript.md > ./.module4-probe/baseline-head.txt
   head -n 60 ./.module4-probe/reduced-transcript.md > ./.module4-probe/reduced-head.txt
   diff ./.module4-probe/baseline-head.txt ./.module4-probe/reduced-head.txt
   

3. Record credits, latency, and any visible context differences for both arms.

Expected result: Two runs that differ by exactly one configuration element.

Checkpoint: You can state what changed between arms and what you still cannot see from this evidence.

Important: This comparison measures session tax on a trivial prompt only, and one run per arm is an anecdote — the workshop's baseline design calls for repetitions with median and range. It is not evidence that the reduced profile solves real tasks. Adopting it in production requires the quality-parity gate from Lab 6.

Note: Testing a second reduction (for example --no-custom-instructions) requires another arm run separately. Changing two things at once produces a result nobody can attribute — that is the defect this exercise exists to prevent. If time allows and you have spend authorization, run it as an additional arm and record it separately; otherwise write it down as a follow-up.

Success criteria

• ✅ Exactly one factor changed between the A2 and A3 arms
• ✅ Both runs used identical model, cap, and output format
• ✅ Both runs stayed within their credit caps
• ✅ Differences recorded as observations, not conclusions
• ✅ You stated explicitly what this evidence does not prove

Exercise A4 — Verify a Permission Restriction Empirically (8 min)

Objective: Prove that a restriction you configured is actually in effect — using permission denial, which uses identifiers the CLI itself documents.

The run below keeps the same model, cap, and output format as A2 and A3 so its output is comparable with them. Reasoning effort remains a lane-profile decision, but this probe does not set it because support varies by model.

1. Ask the agent to describe its tools while write and shell are denied:

   copilot -p "List the names of the tools you can use. Do not use any tool to answer." `
     --no-ask-user `
     --model claude-haiku-4.5 `
     --max-ai-credits 40 `
     --deny-tool 'write' --deny-tool 'shell' `
     --output-format=json `
     --share .\.module4-probe\exclusion-transcript.md |
     Set-Content -Encoding utf8 .\.module4-probe\exclusion.jsonl
   

   copilot -p "List the names of the tools you can use. Do not use any tool to answer." \
     --no-ask-user \
     --model claude-haiku-4.5 \
     --max-ai-credits 40 \
     --deny-tool 'write' --deny-tool 'shell' \
     --output-format=json \
     --share ./.module4-probe/exclusion-transcript.md \
     > ./.module4-probe/exclusion.jsonl
   

2. Compare the response and transcript against your intent.

3. Optional, visibility layer: if you want to test --available-tools, first discover the tool names your installed version actually uses (from this run's output or an interactive session), then add --available-tools '<NAME>,<NAME>' with those exact names. Do not copy a tool list from a slide or another product — an unmatched name parses fine and restricts nothing.

Expected result: Evidence about which tools the model reports as available under your restriction.

Checkpoint: You have first-hand evidence rather than a belief about your restriction.

Important: A model's self-report is corroborating evidence, not proof. The authoritative check is the enforcement behavior itself: a denied tool cannot run, and deny always wins over allow, --allow-all, and saved approvals. Treat any mismatch between intent and observation as a configuration bug to investigate, and verify option spelling and values with copilot help.

Success criteria

• ✅ The run completed within its credit cap
• ✅ The run used the same model, effort, cap, and output format as A2 and A3
• ✅ You compared the observed tool list against your intended restriction
• ✅ Any tool name you used with --available-tools came from your own environment, not from a copied list
• ✅ Any mismatch was recorded as a follow-up, not explained away

Exercise A5 — Record Findings and Stop (5 min)

1. Write four lines in your notes:
   • What the inventory showed that you did not expect.
   • What the baseline arm cost and how long it took.
   • What changed in the reduced arm.
   • What you still cannot determine without a real-task comparison.
2. Add any documentation mismatch you found to your team's verification backlog.
3. Stop here. Do not extend these probes into real work in this session.

Success criteria

• ✅ Four findings recorded
• ✅ At least one open verification question written down
• ✅ No further paid runs started

Appendix A Cleanup

1. Remove local transcripts and outputs:

   Remove-Item -Recurse -Force .\.module4-probe
   

   rm -rf ./.module4-probe
   

2. Confirm no repository changes were made:

   git status
   

   git status
   

3. Check for stray Git worktrees. These exercises do not create any, but a killed run in your own automation can, and worktrees are shared Git state that outlives the process:

   git worktree list
   Get-ChildItem -Directory -Filter "*.worktrees" -Path .. -ErrorAction SilentlyContinue
   

   git worktree list
   ls -d ../*.worktrees 2>/dev/null
   

   If an abandoned worktree appears, remove it and prune the metadata (add --force only when you are certain no process is using it):

   git worktree remove <PATH-TO-WORKTREE>
   git worktree prune
   

   git worktree remove <PATH-TO-WORKTREE>
   git worktree prune
   

4. Confirm no session artifacts were published externally (you did not run --share-gist).

5. Confirm your total spend against your authorized cap.

Cleanup success criteria

• ✅ ./.module4-probe removed
• ✅ git status shows a clean working tree
• ✅ git worktree list shows only the worktrees you expect
• ✅ No gist or external share was created
• ✅ Spend reconciled against the cap you agreed before starting

Appendix A Troubleshooting

Why this appendix exists: the published site renders this lab guide but does not publish the templates/ folder. The four worksheets are therefore reproduced here in full so that every learner — including anyone reading the published lab without repository access — can print or copy them. The files in templates/ remain the editable sources; the copies below must be kept identical to them.

Note: Appendix B is reference material. It adds no time to the 77-minute core lab total or to the optional 45-minute Appendix A.

B1 — Lane Profile Worksheet

Used in: Lab 2 — one copy per lane. Source file: templates/lane-profile-worksheet.md.

Complete one worksheet per lane. Write UNKNOWN — measure rather than guessing. Every restriction must be enforced by a flag or harness control, never by prompt wording alone.

Lane name: ___________________________________

Owner: ___________________________________ Review date: _______________

Verified against Copilot CLI docs on: _______________

1. Purpose

2. Model and Reasoning

3. Tools and Permissions

Visibility (--available-tools / --excluded-tools) controls what the model can choose from, and its values are version- and configuration-specific — verify the tool names in your own environment. Permission (--allow-tool / --deny-tool) controls what may run. Deny always wins, and it is the enforcement layer for any "must not modify" rule.

Read-only claim check: Is every "must not modify" statement enforced by a flag? ☐ Yes ☐ No

4. Context Sources

5. Spend and Fan-Out Controls

6. Isolation

7. Output and Interaction Contract

8. Reduction Log

Record every reduction from the current profile and the evidence required before adoption.

9. Sign-Off

Reviewer: ___________________________________ Date: _______________

B2 — Cache-Key Review Worksheet

Used in: Lab 4 — one copy per cache. Source file: templates/cache-key-review-worksheet.md.

A cache that omits an input which can change the answer will confidently serve a wrong result, and the failure looks like a saving in cost reporting. Review every cache in front of a paid call with this worksheet.

Cache name: ___________________________________

Lane(s) served: ___________________________________

Reviewer: ___________________________________ Date: _______________

1. Key Completeness

Highest-severity omission found: ___________________________________

2. Value and Provenance

3. Lifecycle Policy

4. Gate Ladder Placement

Where does this cache sit relative to the other pre-spend gates?

Is any gate optimistic (assumes done when uncertain)? ☐ Yes ☐ No — if yes, fix it to fail toward spending.

5. Prompt Budget Review (same input path)

6. Corrected Design

CACHE DESIGN v__
  key         =
  value       =
  provenance  =
  ttl         =
  negative    =
  bypass      =
  migration   =

7. Sign-Off

B3 — Failure Taxonomy and Breaker Worksheet

Used in: Lab 5 — one copy per lane. Source file: templates/failure-taxonomy-worksheet.md.

Most dispatcher defects come from one mistake: treating every non-success as "the model failed." Use this worksheet to classify outcomes and to size retries, parking, breakers, and dead-lettering.

Lane name: ___________________________________

Owner: ___________________________________ Date: _______________

1. Outcome Map

Fill one row per outcome your dispatcher can produce. The first ten are the recommended baseline set. Note that a pre-spend refusal and a post-spend cap exhaustion are different outcomes with different consequences.

Spend accounting check: does every run_cap_exhausted outcome record the credits actually consumed against the lane? ☐ Yes ☐ No

2. Retry and Backoff Design

3. Breaker Design

Check: Could a routing, policy, budget, cap-exhaustion, configuration, or already-done outcome trip this breaker? ☐ Yes ☐ No If yes, the breaker will punish the model for the dispatcher's mistakes — fix before shipping.

4. Dead-Letter Policy

Rule: an item that exhausts its attempts is moved, never deleted. Confirm ☐

5. Layered Budget Check

Honest accounting check: when one task fans out into N model calls, does the ledger record N? ☐ Yes ☐ No

6. Failure-Mode Review

B4 — Fleet Lane Optimization Checklist and Canary Scorecard

Used in: Lab 6 capstone — one copy per lane. Source file: templates/canary-scorecard.md.

Use Part 1 to confirm a lane is ready to change. Use Part 2 to run the change like a production deployment.

Lane name: ___________________________________

Owner: ___________________________________ Date: _______________

Part 1 — Fleet Lane Optimization Checklist

1.1 Measurement

1.2 Lane Profile

1.3 Isolation and Ownership

1.4 Pre-Spend Gates

1.5 Runtime Governance

1.6 Landing and Telemetry

Part 2 — Canary Scorecard

2.1 Change Definition

2.2 Baseline (before the change)

2.3 Canary Result (after the change)

2.4 Gates

2.5 Rollback

2.6 Expansion

Report line: "Our canary lane is __________, our single variable is __________, and we roll back if __________."