[NewMe505]

Summary

Fixes the graphcalc run's S6, which holds it at merge stop 1. A python product's CI installed only ruff and pytest, never the project, so PR NewMe505/graphcalc#6 failed at collection (No module named 'sympy') while every SCIO check passed in its sandbox venv. SCIO then called the PR "ready for review" without reading its checks, and no SCIO path could get a fix onto a milestone branch paused at the stop. Now:

• the scaffold's CI installs the project;
• every merge stop reads the PR's CI and says "ready" only over green;
• scio upgrade rewrites the old install line;
• the new answer recheck pushes the upgrade commit and reads the CI again.

Closes #75

Plan vs. done

Plan step	Status	Notes
Scaffold CI and Develop block install the project	done	PYTHON_INSTALL = "pip install -e . ruff pytest"; the pyproject gets a setuptools [build-system] and [tool.setuptools.packages.find] (I-140)
Clean-venv proof of the scaffold's own CI steps	done	fresh: 4 passed; the 0.9.0 line: ModuleNotFoundError: No module named 'six'; no build system beside static/: Multiple top-level packages discovered in a flat-layout
The merge stops read the PR's CI	done	GitHubClient.pr_checks/pr_head, scio/product/pr_ci.py wait_for_ci (bounded, fails fast, ignores an older head's checks, a gh failure becomes unread); MilestonePR.ci, ReleaseRecord.pr_ci (optional, so the paused 0.9.0 checkpoint loads) (I-141)
scio upgrade fixes an existing product's install line	done	exact-line rewrite in ci.yml and the README; a changed line is kept; a build system is added only when the pyproject has none (I-142)
recheck at both merge stops	done	pushes the branch once per head (effect push:<branch>:<sha>, never forced), reads that head's CI, asks again (I-142). Milestone stop: the end-to-end test; release stop: red then green in test_github_mode_survives_squash_merged_milestone_prs
Dry run on graphcalc's real milestone/1 (scratch clone)	done	upgrade added the CI and README lines and kept graphcalc's own build system (commit by scio). Its CI steps in a clean venv: 56 passed, 1 skipped, and graphcalc 0.1.0

How graphcalc gets unblocked (after this merges)

1. The SCIO session moves .scio/live-wt to this PR's merge commit.
2. In the graphcalc workspace (product on milestone/1, clean tree): sh scio.sh upgrade --product C:/Users/playa/OneDrive/Desktop/projects/graphcalc-run/graphcalc. That makes one commit authored by scio (GUARDRAILS rule 1 holds).
3. sh scio.sh build --product C:/Users/playa/OneDrive/Desktop/projects/graphcalc-run/graphcalc --gh NewMe505/graphcalc --decision recheck. This pushes milestone/1, PR M3: router and T0 loop end to end #6's CI re-runs, and the stop asks again with the CI result. It waits for the CI inside the command, for up to 15 minutes, so run it in the background or with a long timeout. A Bash tool's default 2-minute timeout would kill it mid-wait; that is recoverable (the push is journaled, and a rerun only reads the CI again), but confusing.
4. Once the stop says "is ready; CI passed": tools/guard_ci_deps.py --ref milestone/1 exits 0, the owner merges PR M3: router and T0 loop end to end #6, then --decision merged.

Checked on a scratch copy of the run's checkpoint DB: scio report --thread build-graphcalc-m1 loads it with this branch's models (exit 0, phase merge_wait), and the PR record has no CI reading, so the stop will offer recheck.

Merge order with #74: both PRs add a section under CHANGELOG's [Unreleased], so whichever merges second needs main merged in first; both entries stay. If #74 merges first, this session merges main into this branch.

Test evidence

set -o pipefail && uv run ruff check . && uv run ruff format --check . && uv run mypy && uv run python -m pytest -n 8 && uv run python scripts/check_docs.py && uv run python -m evals.runner --suite regression --provider fake --trials 5 --min-pass-pow-k 1.0
All checks passed! / 268 files already formatted / Success: no issues found in 134 source files
508 passed, 18 skipped in 433.70s (0:07:13)   (main: 500 passed, 18 skipped; +8 new tests)
docs-check: 0 problem(s)
regression suite, fake, 5 trials: every task pass^5 = 1.00

New regression test on the old code (scratch worktree of origin/main):
test_a_red_ci_is_never_called_ready_and_recheck_pushes_the_upgrade_made_at_the_stop
  -> AttributeError: 'MilestonePR' object has no attribute 'ci'  (and the old question said "is ready")

Docs updated

• README (--decision recheck, what scio upgrade now fixes)
• docs/ARCHITECTURE.md (no graph change: merge_wait already looped on itself)
• ADR (none: a fix within ADR 0007's human stop)
• CHANGELOG [Unreleased]
• Docstrings for changed public APIs
• N/A: no user-facing or architectural change

Continuous improvement

• Issue ledger updated for every problem hit (ids: I-140, I-141, I-142, I-143, I-144)
• Each bug fix was swept across the codebase (patterns: grep -rn "pip install" scio configs; grep -rn "gh pr checks\|statusCheckRollup\|check_runs" scio; every merge stop and every git_push in build.py; every whole-file rule in upgrade.py)
• Milestone retrospective written (milestone-closing PRs only)
• Guardrails 39 to 43, each naming its guard. Two are manual: (I-143, I-144: properties of the agent's shell).

Risk notes

• State: two optional fields (MilestonePR.ci, ReleaseRecord.pr_ci). A checkpoint without them loads, and its stop reads "CI not read yet", offering recheck.
• A new --decision word (recheck), and both merge stops' question text changed. Per the release rule, that makes the next release a minor one.
• milestone_pr and the release step now wait for the PR's CI, up to 15 minutes, before the stop. The wait ends at the first failing check, and a product's CI usually takes under a minute.
• New python scaffolds get a setuptools [build-system], so python -m build and pip install . behave the same everywhere.
• Rollback: revert the PR; old checkpoints carry nothing that only this code reads.

Agent run log (agent PRs only)

N/A (a human-directed session).

🤖 Generated with Claude Code