宜博 / lemongraph

Attempt 13b was the first real run to get all the way through a real
cutover -- task lifecycle, classification, staging, health check (fixed
last commit), and a genuine blue-green cutover all succeeded for real. It
correctly landed in 'monitor' and then correctly couldn't finish: the real
production exit condition (deploy_monitor.MONITORING_WINDOW_HOURS=24h OR
MONITORING_MIN_TASK_COUNT=10 real tasks in the monitored project, NOT the
disposable per-cycle canary project) isn't practical to wait out in an
interactive session. This isn't a bug -- those are sensible real defaults
-- it's a testability gap: run_self_hosting_closed_loop already exposes
monitor_timeout_cycles as an override knob for exactly this kind of
situation, but never threaded the two constants that actually gate
"monitoring_window_clean" through to run_monitor_cycle.

Added monitor_window_hours/monitor_min_task_count params, defaulting to
deploy_monitor's real constants (production behavior unchanged), threaded
through to the actual run_monitor_cycle call. New assertion locks in that
overrides actually reach it.

Also documents the full run of 9 real bugs found and fixed across 13
attempts in development-plan.md's U-042 note.

564 tests green (441 src + 123 supervisor).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Adds supervisor/self_hosting_e2e.py: run_self_hosting_closed_loop() chains
every PH5 module built this session (U-034~U-041) with the Graph Engine's
own scheduler (U-032) into one real, callable path matching self-development-
feasibility.md's 9-step scenario -- self-target Goal -> Planner/Coder/
Validator -> core_engine classification -> stage -> health check -> cutover
(or rollback path A if health check fails) -> monitor until either
monitoring_window_clean (finalized) or anomaly_detected (rollback path B).
Both real outcome paths are branches of the same call, not two separate
scripted scenarios. Explicitly documented as this acceptance scenario's own
orchestration glue, not a claim about Deploy Supervisor's eventual
production poll loop (U-036's discovery-loop hook is still unfilled;
building that is future work).

Mocked wiring tests (6, run in normal regression) stub each already
independently-tested module boundary and only verify the branching logic.

The real, literal acceptance test is built and ready (RealSelfHostingClosedLoopTest,
reproduces the document's own "loop_round > 3 should be >= 3" example) but
gated behind RUN_REAL_SELF_HOSTING_E2E=1 -- deliberately a separate,
distinctly-named env var from this project's usual RUN_REAL_AGENT_E2E, since
this is the highest-blast-radius action in the project (can replace the
running graphlemon process and git-revert commits on this real repo).
Per this Unit's own explicit build instruction, not executed as part of
implementing it -- doing so requires checking with the user first.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>