Session M7-04 lab: Build a planning canvas and reconcile stale state¶

Duration: 2 hours

Difficulty: Intermediate

Deliverable: A project-scoped planning canvas that detects and reconciles a real GitHub state change

Deliverables¶

The generated and reviewed canvas extension
The live planning canvas
One controlled GitHub state change
Links from the canvas to the live GitHub issues

Lab outcome¶

Create and review a planning canvas with the official /create-canvas skill. Load live issue state through GitHub MCP. Then make a controlled change in GitHub so you can detect stale canvas data and refresh it.

Part	Work	Time
1	Check canvas and MCP capabilities	15 min
2	Define the minimum canvas requirements	20 min
3	Create and simplify the canvas	30 min
4	Load and operate live issue state	25 min
5	Create and detect state drift	15 min
6	Reconcile and record ownership	15 min

Preflight¶

Complete the track capability setup.

Check GitHub Copilot access before starting. Stop if access is unavailable.

Part 1: Check canvas and MCP capabilities (15 minutes)¶

Open a GitHub Copilot app session for the training repository.
Type / and check that /create-canvas appears.
Open Customize → Canvas and inspect installed canvases.
Open Customize → MCP → Installed and check GitHub MCP.
Ask Copilot to retrieve the Session M7-03 parent issue and child issues.

/create-canvas is a built-in app skill. Do not install a community replacement. Stop if the skill or GitHub reads are unavailable.

Use a fresh GitHub MCP read as the authoritative issue list. Start from the live Session M7-03 parent issue and follow its child links. Do not reconstruct the set from chat history or a separate Markdown file.

Part 2: Define the minimum canvas requirements (20 minutes)¶

Complete starter/canvas-requirements.md.

The canvas must answer:

What outcome are we delivering?
Which issues are planned, active, blocked, or ready for review?
Who owns the next action?
Which dependency or risk needs attention?
When did GitHub state last refresh?

Allow only these actions:

refresh issue state from GitHub;
change planning status in the canvas;
record a risk or decision;
assign the next planning action.

The canvas must not close issues, change assignees, or publish comments.

Checkpoint: Every field and action supports a named planning decision.

Part 3: Create and simplify the canvas (30 minutes)¶

Run:

/create-canvas

Create a project-scoped delivery-planning canvas from
@starter/canvas-requirements.md. Store it under .github/extensions. It must show
the parent outcome, child issues, planning status, GitHub state, owner, dependency,
risk, next action, and last refresh. It may read GitHub state but must not write
to GitHub.

The agent should create the extension and open it in the side panel.

Review:

the files created under .github/extensions;
the visible fields and actions;
the capabilities exposed to Copilot;
any package or dependency added by the extension.

Inspect the generated files and ask Copilot for specific changes. Do not hand-edit extension code; this is a no-code review.

Ask Copilot to remove generated state or actions that exceed the approved requirements.

Checkpoint: The canvas is smaller after review and contains no GitHub write action.

Part 4: Load and operate live issue state (25 minutes)¶

Ask Copilot to retrieve the Session M7-03 issues through GitHub MCP and load:

issue number and title;
GitHub state;
planning status;
owner or ownership gap;
dependency;
next action;
retrieval time.

Then:

change one planning status through the visible canvas controls;
ask Copilot to change another planning status through a canvas capability;
add one risk with an owner;
add one decision with a reason;
ask Copilot for a current canvas summary.

Compare the visible state with Copilot's summary.

Part 5: Create and detect state drift (15 minutes)¶

Choose one child issue. Through GitHub MCP, preview this comment:

Planning update: waiting for a product-owner decision on the public status
vocabulary. Do not start implementation until the decision brief is updated.

Approve the comment, then retrieve the issue in a fresh request.

Do not refresh the canvas yet. Ask Copilot to compare:

the current visible canvas;
the fresh GitHub issue;
the canvas's last-refresh time.

Identify what changed in GitHub but has not yet appeared in the canvas.

Part 6: Reconcile and record ownership (15 minutes)¶

Use the canvas refresh action or ask Copilot to call the approved refresh capability.

Check that:

the issue's planning status reflects the new blocker;
the next action names the product-owner decision;
the GitHub state and planning state remain distinct;
the last-refresh time changed.

In the live canvas, record who owns it, how to refresh it, and how to recover after an interruption. Also record when to retire it and the next safe action. Check that it links the four status-visibility issues for Session M7-05. Keep any optional fifth issue linked for context, but outside those workstreams.

Run /context. If the creation thread is crowded, start a fresh session and retrieve the live GitHub issues and open the canvas. Then run:

/rubber-duck Critique the live planning canvas against the linked GitHub issues.
Find stale source claims, mixed GitHub and planning states, unsafe actions, and
missing ownership.

Apply useful findings directly to the canvas.