Уточнить эффективный статус agent loop

This commit is contained in:
2026-06-03 07:52:31 +03:00
parent 15f1a57039
commit d24f8476b4
3 changed files with 61 additions and 0 deletions
@@ -167,6 +167,8 @@ It stores the GUI review under `artifacts/domain_runs/stage_agent_loops/<stage_i
Use `python scripts/stage_agent_loop.py status --manifest docs/orchestration/<stage_loop>.json` as the cheap read-only checkpoint before continuing a stage. It prints the current next action, closing gate, latest GUI run, latest repair coder status, latest repair validation status, and cold-start continuation artifacts such as `domain_pack_loop.command.txt` without modifying artifacts.
The status payload also exposes `effective_stage_status`, `effective_stage_status_source`, and `latest_gui_review_superseded_by_validation`. These fields prevent stale GUI failures from looking current after a later accepted repair validation or domain-loop replay has already superseded them. Keep the historic `latest_gui_business_status` visible for audit, but use the effective status to decide whether the next action is repair, validation, or manual confirmation.
Use `python scripts/stage_agent_loop.py continue --manifest docs/orchestration/<stage_loop>.json` as the safe one-command continuation layer. From a cold start it materializes `domain_pack_loop.command.txt` without launching the long live loop; after a GUI review it can prepare a repair iteration and materialize `run-repair --dry-run` automatically; it will not run the real coder pass unless `--execute-repair` is passed, and it waits for a `--run-id assistant-stage1-<id>` when the next required step is post-repair rerun/ingest validation.
It also writes `stage_repair_handoff.md/json` next to the stage summary. That handoff is the preferred input for the next coder pass: it lists primary repair targets and sample user-facing failures without forcing the coder to reread the entire GUI conversation first.