Frame the evaluation pull request experiment

Success is not “I followed the tutorial.” Success is producing evidence that: remote branch and PR exist; CI status is visible before merge. The accepted input is narrow on purpose: local commits on improve-evaluation plus repository PR rules. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: branch protection / required checks listed before opening the PR. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

git branch --show-current
printf 'goal: PR improve-evaluation -> main after checks\n'

Expected evidence: current branch name. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the pull request from improve-evaluation into main, a decorative win often looks like a clean run that never checks gh pr view shows base=main, head=improve-evaluation, and check summary. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: force-pushing rewritten history on a shared branch or leaking tokens in PR body.

For github-basics, write the claim on a sticky note in this exact shape: “Given local commits on improve-evaluation plus repository PR rules, the evaluation pull request will …”. Fill the ellipsis with the observable part of: remote branch and PR exist; CI status is visible before merge. Tape the baseline beside it: branch protection / required checks listed before opening the PR. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to propose a reviewed evaluation change for merge only after checks pass. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (feature branch improve-evaluation with one commit) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against feature branch improve-evaluation with one commit. Note the metric you will eventually require (gh pr view shows base=main, head=improve-evaluation, and check summary) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is pushing straight to main, or opening a PR with failing checks ignored.

At the experiment brief stage for github-basics, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about feature branch improve-evaluation with one commit that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: branch protection / required checks listed before opening the PR.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to propose a reviewed evaluation change for merge only after checks pass. If you cannot point to a file, command, or assertion that proves that for the evaluation pull request, stay on this page instead of advancing.

GitHub glossary

Next