Checkpoint Lab — GitHub Projects, Roadmaps, Custom Fields, Views, Automation, and Planning

1. Checkpoint mission and acceptance evidence

Your evidence package should contain: repository/Project identities, issue/PR URLs, Project number, field list, item inventory, three named saved views, one built-in workflow configuration, two written predictions and their verification, one injected inconsistency with diagnosis/repair, and a short operating policy. Screenshots may supplement—but not replace—structured evidence.

2. Fresh-resource preflight

gh auth status --active --hostname github.com
OWNER=$(gh api user --jq .login)
REPO="atlas-c06-checkpoint"
PROJECT_TITLE="Atlas C06 Checkpoint"

gh repo view "$OWNER/$REPO" >/dev/null 2>&1 && {
  echo "STOP: repository collision" >&2; exit 2;
}

gh project list --owner "$OWNER" --format json

3. Create the repository and four source records

gh repo create "$OWNER/$REPO" --public --add-readme --clone
cd "$REPO"
DEFAULT_BRANCH=$(git branch --show-current)

I1=$(gh issue create --title "Release: verify database rollback" --body "Checkpoint issue 1")
I2=$(gh issue create --title "Bug: readiness probe message unclear" --body "Checkpoint issue 2")
I3=$(gh issue create --title "Docs: publish operator upgrade note" --body "Checkpoint issue 3")

git switch -c docs/checkpoint-release-note
printf '
Checkpoint release note.
' >> README.md
git add README.md
git commit -m "docs: checkpoint release note"
git push -u origin docs/checkpoint-release-note
PR=$(gh pr create --base "$DEFAULT_BRANCH" --head docs/checkpoint-release-note   --title "docs: checkpoint release note" --body "Chapter 06 checkpoint PR")

printf '%s
%s
%s
%s
' "$I1" "$I2" "$I3" "$PR"

4. Create, discover, and link the Project

PROJECT=$(gh project create --owner "$OWNER" --title "$PROJECT_TITLE"   --format json --jq '.number')
test -n "$PROJECT"
gh project link "$PROJECT" --owner "$OWNER" --repo "$REPO"

gh project view "$PROJECT" --owner "$OWNER" --format json
gh api -H "Accept: application/vnd.github+json"   -H "X-GitHub-Api-Version: 2026-03-10"   "/users/$OWNER/projectsV2/$PROJECT"   --jq '{number,title,state,public}'

5. Add items and planning fields

for URL in "$I1" "$I2" "$I3" "$PR"; do
  gh project item-add "$PROJECT" --owner "$OWNER" --url "$URL"
done

gh project field-create "$PROJECT" --owner "$OWNER"   --name Priority --data-type SINGLE_SELECT   --single-select-options "P0,P1,P2"

gh project item-edit "$PROJECT" --owner "$OWNER" --url "$I1" --field Priority --value P0
gh project item-edit "$PROJECT" --owner "$OWNER" --url "$I2" --field Priority --value P1
gh project item-edit "$PROJECT" --owner "$OWNER" --url "$I3" --field Priority --value P2
gh project item-edit "$PROJECT" --owner "$OWNER" --url "$PR"  --field Priority --value P1

In the web UI create an Iteration field with a one-week lab cadence, then assign I1/I2/PR to the current iteration and I3 to the next iteration. Keep Status values explicit: I1 Todo, I2 In Progress, I3 Todo, PR In Progress.

6. Create three purpose-specific views

• Release inventory (Table): show Title, Status, Priority, Iteration, Assignees, Repository; sort Priority then Iteration.
• Flow (Board): group by Status; filter out nothing except archived items.
• Horizon (Roadmap): use Iteration as the time basis; display Priority; ensure unscheduled work would be detectable via a companion filter/view.

Record each saved view name and filter. The acceptance criterion is not “three tabs exist”; each view must answer a different operational question.

7. Configure one source-driven workflow

In Project Workflows, verify/configure “issue or pull request closed → Status Done”. Keep reverse source mutation disabled for the checkpoint. Capture the workflow configuration before testing it.

8. Write two predictions before mutation

1. P1: closing I3 will change the issue state to CLOSED and, through the built-in workflow, change only that Project item Status to Done; its Priority/Iteration should remain unchanged.
2. P2: changing I2 Project Status from In Progress to Todo will not alter the issue open/closed state because no reverse-close workflow is enabled.

Write your own wording before proceeding. The checkpoint tests whether you can predict resource boundaries, not whether you can repeat the sample.

9. Execute and verify Prediction 1

gh issue close "$I3" --comment "Checkpoint workflow test."
gh issue view "$I3" --json number,state,url

gh project item-list "$PROJECT" --owner "$OWNER" --limit 100   --field Status --field Priority --field Iteration --format json

Confirm the issue is closed and the corresponding planning Status is Done. Confirm Priority and Iteration did not silently change. Then reopen I3 and reset Status to Todo for continued lab use.

10. Execute and verify Prediction 2

gh project item-edit "$PROJECT" --owner "$OWNER" --url "$I2"   --field Status --value Todo

gh issue view "$I2" --json number,state,url
gh project item-list "$PROJECT" --owner "$OWNER" --limit 100   --field Status --field Priority --field Iteration --format json

The Issue should remain OPEN. Restore I2 to In Progress after recording the evidence.

11. Inject one planning inconsistency

Set the PR Project Status to Done while leaving the pull request open. This is intentionally incorrect planning state.

gh project item-edit "$PROJECT" --owner "$OWNER" --url "$PR"   --field Status --value Done

gh pr view "$PR" --json number,state,mergedAt,statusCheckRollup,url

gh project item-list "$PROJECT" --owner "$OWNER" --limit 100   --field Status --field Priority --field Iteration --format json

12. Diagnose and correct the model, not the PR

The authoritative evidence says the PR is open. The mistake is the Project field, so the least destructive correction is to set planning Status back to In Progress. Do not merge/close the PR merely to make the board look consistent.

gh project item-edit "$PROJECT" --owner "$OWNER" --url "$PR"   --field Status --value "In Progress"

gh pr view "$PR" --json number,state,mergedAt,url
gh project item-list "$PROJECT" --owner "$OWNER" --limit 100   --field Status --field Priority --field Iteration --format json

13. Write the Project operating policy

14. Capture machine-readable final evidence

gh project field-list "$PROJECT" --owner "$OWNER" --format json > c06-fields.json
gh project item-list "$PROJECT" --owner "$OWNER" --limit 100   --field Status --field Priority --field Iteration --format json > c06-items.json

gh api -H "Accept: application/vnd.github+json"   -H "X-GitHub-Api-Version: 2026-03-10"   "/users/$OWNER/projectsV2/$PROJECT" > c06-project.json

printf 'Evidence files:
'; ls -lh c06-*.json

Keep these evidence files outside the repository if you plan to delete the lab. They contain synthetic public-lab metadata, not credentials.

15. Verification checklist

• Project owner/title/number verified through CLI/API.
• Four source items visible in the Project and still independently queryable in repository state.
• Priority and Iteration field definitions verified.
• Table, board, and roadmap views have distinct stated purposes.
• Built-in close → Done workflow verified from source event to planning field.
• P1 and P2 predictions recorded before execution and independently checked.
• Injected PR Status inconsistency preserved, diagnosed, and repaired without changing PR source state.
• Operating policy names field ownership and automation direction.

16. Cleanup and rollback

cd ..
printf 'project=%s owner=%s repo=%s/%s
' "$PROJECT" "$OWNER" "$OWNER" "$REPO"

gh project delete "$PROJECT" --owner "$OWNER"
gh repo delete "$OWNER/$REPO" --yes
rm -rf "$REPO"

17. What Chapter 06 adds to the production operating model

Chapter 06 adds a planning layer above disciplined Issues and contribution workflows: shared Project items, explicit field authority, time-boxed planning, purpose-specific views, least-surprise automation, and independent verification against source engineering state. A Project can now help coordinate delivery without becoming a false substitute for Git, pull-request, CI, release, or deployment evidence.

18. Bridge to Chapter 07: Pull Requests

The Project now includes a pull request as a planning item, but Chapter 06 deliberately treated the PR as an external source of engineering truth. Chapter 07 goes inside that resource: draft PRs, linked Issues, base/head change sets, collaboration patterns, and how a proposed change moves from branch topology into reviewable delivery work.

Knowledge check

Authoritative references

• Planning and tracking with Projects
• About iteration fields
• Customizing views
• Built-in Project automations
• Managing access to Projects
• gh project
• gh project item-edit
• gh project item-list
• REST API for Projects
• REST Project endpoints
• REST Project field endpoints
• REST Project item endpoints
• REST API versions