Today's outcome

Build one delivery-readiness canvas in the Copilot app.

Record:

• the approved contract;
• one direct update;
• one agent-requested update;
• one rejected update and recovery;
• one human review decision.

Access policy

The lab requires:

• GitHub Copilot app access;
• the built-in /create-canvas skill;
• approval for the chosen extension scope.

If app access or the skill is missing, stop the lab. If project scope is
unavailable, use user scope. Do not install a replacement or
move data to an unapproved surface.

Choose the right customization

A canvas is useful when people and an agent need to inspect or change the same visible state.

Canvas anatomy

shared state
  ├─ human actions in the interface
  ├─ agent-callable capabilities
  └─ validation before every change

The contract names all four parts before implementation starts.

Worked contract

Authority stays narrow

Safe:

• read the current board;
• update one named item;
• list items flagged for review.

Out of scope:

• deployment;
• external writes;
• credentials;
• hidden data imports;
• broad actions such as "manage the project."

Prepared demo inputs

All names and evidence are synthetic.

Prepared demo sequence

1. Run the local contract tests.
2. Create the canvas from the worked prompt.
3. Move WEB-318 to ready with a visible control.
4. Ask the agent to move API-204 to review.
5. Ask for DOC-101 to move to ready.
6. Show the rejection, add evidence, and retry.

Creation prompt

/create-canvas

Create a delivery-readiness canvas from @prepared-items.json.
Use the contract in @canvas-contract.md.
People can add evidence and update one item.
Copilot can read the board, update one named item, and list review flags.
Reject unknown items or statuses. Require evidence before ready.
Do not connect external systems.

Choose project scope only when .github/extensions is allowed. Otherwise use user
scope.

Visible and agent-requested changes

The same state must change through both paths:

If the response and visible state disagree, stop and inspect the artifact.

Rejection is part of the design

Request:

Move DOC-101 to ready.

Expected:

Rejected: evidence is required before ready.

A safe canvas keeps the state unchanged and explains the rule.

Recovery keeps the rule

1. Add synthetic evidence to DOC-101.
2. Retry the same transition.
3. Check that ready is now accepted.
4. Record before, rejection, correction, and after state.

Keep validation in place when you fix the demo.

Review the generated extension

Check:

• state fields and defaults;
• visible actions;
• agent-callable capabilities;
• dependencies and persisted data;
• owner and reviewer;
• retirement trigger.

Remove anything the contract did not request.

Source of truth

The canvas is a working artifact, not an automatic system of record.

If another system owns the data:

• label the canvas as a projection;
• record refresh or reconciliation rules;
• keep external writes outside this lab.

Peer decision

The reviewer chooses:

• approve when the recorded results match the contract;
• revise when the correction fits the contract;
• pause when access, ownership, data, or behavior is unresolved.