Version: 0.11.1
bmad-loop sweep --max-bundles 15 works correctly: the value is persisted to the run's sweep.json, and compose_resume reads it back, so a resumed run keeps the override. Behaviour is right.
What is wrong is what the run reports about itself. cmd_sweep passes max_bundles / repeat / max_cycles alongside the policy rather than folding them into it, so the snapshot written to state.json keeps the policy.toml values:
$ cat .bmad-loop/runs/<id>/sweep.json
{"prompting": true, "decisions_only": false, "max_bundles": 15, "repeat": null, "max_cycles": null, "trigger": "cli"}
$ python -c "import json;print(json.load(open('.bmad-loop/runs/<id>/state.json'))['policy_snapshot']['sweep'])"
{'auto': 'never', 'max_bundles': 5, ..., 'repeat': False, 'max_cycles': 5}
bmad-loop status prints no effective options at all, so the only cap visible anywhere in run state is the one the run is not using.
Why it matters in practice. Reading a live run's state gives you the wrong number, and the wrong number is the plausible one. With 37 bundles triaged and a snapshot saying max_bundles: 5, a seventh dispatched bundle reads as the cap failing to hold rather than as an override working exactly as intended — which is a worrying-looking symptom for something that is fine. It also makes after-the-fact reconstruction from a run directory unreliable for anyone (or anything) that reads the snapshot as "what this run enforced"; the engine's own resume-path comment describes the stamp that way.
Suggested fix, either would do:
- fold the CLI overrides into the policy before the snapshot is stamped, so
policy_snapshot.sweep describes the run; or
- have
bmad-loop status print the effective options from sweep.json beside the run header, and leave the snapshot as the file's record.
The first keeps one place to look. The second preserves the distinction between "configured" and "passed for this run", which may be the more useful pair to keep.
Version: 0.11.1
bmad-loop sweep --max-bundles 15works correctly: the value is persisted to the run'ssweep.json, andcompose_resumereads it back, so a resumed run keeps the override. Behaviour is right.What is wrong is what the run reports about itself.
cmd_sweeppassesmax_bundles/repeat/max_cyclesalongside the policy rather than folding them into it, so the snapshot written tostate.jsonkeeps thepolicy.tomlvalues:bmad-loop statusprints no effective options at all, so the only cap visible anywhere in run state is the one the run is not using.Why it matters in practice. Reading a live run's state gives you the wrong number, and the wrong number is the plausible one. With 37 bundles triaged and a snapshot saying
max_bundles: 5, a seventh dispatched bundle reads as the cap failing to hold rather than as an override working exactly as intended — which is a worrying-looking symptom for something that is fine. It also makes after-the-fact reconstruction from a run directory unreliable for anyone (or anything) that reads the snapshot as "what this run enforced"; the engine's own resume-path comment describes the stamp that way.Suggested fix, either would do:
policy_snapshot.sweepdescribes the run; orbmad-loop statusprint the effective options fromsweep.jsonbeside the run header, and leave the snapshot as the file's record.The first keeps one place to look. The second preserves the distinction between "configured" and "passed for this run", which may be the more useful pair to keep.