Issue-to-review workflow

issue contract
    ↓
repository setup
    ↓
proposed change
    ↓
test evidence
    ↓
human decision

Keep the same issue and acceptance criteria at every step.

Access policy

The lab requires:

• approved Copilot cloud agent access;
• a training repository with synthetic data;
• a named reviewer;
• an issue with a file scope and stop condition.

If any requirement is missing, stop the lab. Do not bypass policy.

The fixed issue

Reject blank task titles

Allowed files:

• src/app.js
• tests/app.test.js

Required command:

npm test

No dependency changes. No unrelated refactor.

Checkpoint 1: Issue contract

The reviewer must answer:

• Which behavior changes?
• Which behavior stays the same?
• Which files may change?
• What proves completion?
• What is out of scope?

Do not assign the issue until every answer is clear.

Repository instructions

Tell the agent how to work in this repository:

• project shape;
• coding conventions;
• allowed file scope;
• test command;
• prohibited changes.

Instructions support the issue. They do not repair a vague issue.

Copilot setup steps

The workflow file belongs at:

.github/workflows/copilot-setup-steps.yml

It uses one job named:

copilot-setup-steps

Review permissions, commands, and secrets before merging it to the default branch.

Checkpoint 2: Setup

Record:

• baseline test result;
• repository instructions location;
• setup workflow location;
• allowed files;
• reviewer and stop condition.

Stop when you cannot explain the baseline test result or setup requires unapproved access.

Start the session

• assign the fixed issue through an entry point allowed by repository policy;
• watch the session log;
• steer only within the issue;
• stop on scope drift.

Checkpoint 3: Proposed change

Inspect before running tests:

• changed files;
• validation behavior;
• response shape;
• valid request behavior;
• dependency and configuration changes.

A small diff can still be wrong.

The expected behavior

if (typeof title !== "string" || title.trim() === "") {
  return res.status(400).json({ error: "title is required" });
}

The code may differ, but it must preserve the required behavior and constraints.

Checkpoint 4: Tests

Required cases:

Run the full supplied suite and record the command output.

Keep review feedback within the issue

Good:

The whitespace case is missing. Add a focused test in tests/app.test.js.
Keep the current response shape and do not change other endpoints.
Run npm test and report the result.

Bad:

Clean up the API while you are there.

Checkpoint 5: Human decision

Choose:

• approve when criteria, scope, and tests pass;
• request changes when a correction within the issue remains;
• pause when access, test output, or ownership is unresolved.

The agent does not make this decision.

Stop conditions

Stop the lab when:

• the requested files expand;
• a new dependency appears;
• credentials or unapproved data are requested;
• repeated test failures have no recovery plan;
• the issue changes during implementation;
• the reviewer is no longer available.

Trainer demo recovery

The solution folder contains:

• the final issue contract;
• reviewed setup workflow;
• proposed diff;
• runnable solution project;
• test output;
• completed human decision.

Use it only when the trainer demo is delayed. Learners still need a live
cloud-agent run for lab completion.