Set up interfaces and contracts

The required setup is: a local Git repository has a GitHub remote named origin, authentication works, and direct pushes to the base branch are avoided. Confirm it before copying code. The contract separates input from output: local commits on improve-evaluation plus the repository's pull-request rules goes in, and a remote feature branch and a reviewable proposal into main comes out. If either side is ambiguous, later debugging will chase the wrong layer.

The input contract is local commits on improve-evaluation plus the repository's pull-request rules. The visible result is a remote feature branch and a reviewable proposal into main.

git switch -c improve-evaluation
python -m pytest
git add train.py tests/test_train.py
git commit -m "Test held-out evaluation"
git push -u origin improve-evaluation
git status -sb

Expected evidence:

2 passed in 0.08s
branch 'improve-evaluation' set up to track 'origin/improve-evaluation'.

1. git switch -c creates and checks out a local feature branch.
2. pytest supplies evidence before publication; a successful push is not proof that code works.
3. git push -u origin ... sends commits and records the upstream branch.
4. the pull request is created on GitHub after the branch exists; pushing does not merge it.

These lines form one chain: local commits on improve-evaluation plus the repository's pull-request rules becomes a remote feature branch and a reviewable proposal into main. Change only one input first. When several values change together, you cannot tell which change caused the new behavior.

• First failure: remote origin already exists means inspect git remote -v instead of adding a duplicate. Re-run the smallest command that proves the repair.
• Second failure: a rejected non-fast-forward push usually means the remote branch moved; fetch and reconcile rather than force-pushing shared history. Preserve the failing input as a test when it represents a realistic mistake.
• Misleading success: a red required check must be opened and read; rerunning without a code or infrastructure reason hides the actual failure. A clean-looking final line cannot cancel contradictory intermediate evidence.

When debugging, copy the exact error text and inspect names, paths, shapes, types, and versions. Explain the cause in one sentence before changing code. That discipline prevents a guessed repair from creating a second defect.

Treat public repositories as public from the first push. Use least-privilege tokens, branch protection, required review, and environment-scoped deployment secrets. Never paste credentials into an issue or workflow log.

For the current setup step, save the smallest useful evidence: the relevant command, its output, and the input that produced it. Do not use a screenshot as the only record when text can be copied and searched. Keep generated artifacts separate from source inputs so rerunning the example does not destroy the evidence it is meant to evaluate.

Read every command or statement before running it. The examples deliberately expose intermediate state so a surprising result has somewhere concrete to point.

Return to your opening prediction. Mark it correct or rewrite it with the condition you missed. Then explain the difference between a successful execution and a trustworthy result for this specific example.