Triage automated proposal reviews before revision

[eshulman2]

Summary

• semantically triage bot-authored PRD and specification reviews before requesting regeneration
• stop only on satisfied reviews
• revise blocking and uncertain reviews, preserving the original feedback for uncertain decisions
• count successful automated regeneration iterations and cap each machine-only cycle at three
• reset the cycle when a human requests a revision and between PRD and specification artifacts
• pass distilled blocking feedback into artifact regeneration

This prevents loops like osac-project/enhancement-proposals#169 while preserving actionable automated review feedback.

Validation

• Ruff check passed on changed Python files
• Focused worker, proposal-event, generation, prompt, and triage tests: 123 passed

[eranco74]

The revision counter is shared across all bot reviewers and never resets. If CodeRabbit uses 2 of the 3 allowed revisions and then the EP Review fires, it only gets 1 shot. Also, if a human later intervenes and triggers a new revision cycle, subsequent bot reviews would still be capped at the old count.

Not a blocker — it errs on the safe side — but worth being aware of.

[eranco74]

/lgtm
/approve

[eshulman2]

Addressed Eran's observation in 9c8857a. The limit now counts successful automated regeneration iterations rather than incoming bot feedback events. A human-requested proposal revision resets the completed count and pending marker, starting a fresh automated-review cycle. The cap remains shared across bots because it bounds total machine-only churn within one cycle.