Implement Rework

[ineedjet]

Summary

rework is the other remaining placeholder job in proposal-shared.yml. This issue is its concrete implementation, split out from #11 now that #11 itself is closed.

What #11 specifies

Rework — agent — read comment feedback the human left instead of editing fields directly, and revise the proposal's own fields/body accordingly.

The counterpart to Distill: where Distill looks at direct field edits the human made, Rework looks at comment feedback the human left instead of editing fields, and revises the proposal itself (not the parent) in response.

Open questions

• Which comments count as feedback? The proposal issue accumulates the control comment, StarCast's own Telegram/notification traffic (if any lands as comments), and potentially unrelated human chatter. Rework needs to read "feedback left since the proposal was created or last reworked" — what's the boundary, and how is it distinguished from noise?
• Model invocation. Same open dependency as Implement Distill #86 (Distill) — needs whatever Design a configurable agent execution contract #9 (configurable agent execution contract) defines for model credentials, regulations content, and prompt/playbook structure, rather than inventing an ad hoc shape.
• What does "revise the proposal's own fields/body" touch? Presumably the same prefixed Issue Fields Apply already knows how to read (title/body/prefixed fields), but through a write path — does rework reuse apply's field-catalog/write helpers directly (actions/proposal's existing build_field_input/set_issue_field_values), just pointed at the proposal issue instead of the parent?
• Does the control comment change? After a rework, is a fresh control comment posted, or is the existing one left in place (its checkboxes presumably need to go back to unchecked so a human can act again) — GitHub doesn't auto-uncheck boxes, so something has to reset them if re-triggering the same checkbox surface is intended.
• Idempotency / re-triggering. If a human checks [x] Rework again after it already ran, what happens — same question shape as Apply's "already closed = no-op," but Rework doesn't close anything, so the no-op condition needs its own definition.

Acceptance criteria

• A defined mechanism identifies which comments on the proposal issue count as feedback for a given rework run.
• rework revises the proposal's own fields/body based on that feedback, reusing apply's existing field-write helpers rather than duplicating them.
• The control comment's checkbox state after a rework is deliberately handled (reset, reposted, or left as-is — documented, not accidental).
• Re-triggering rework without new feedback since the last run is a defined no-op, not undefined behavior.
• Verified live against a real feedback-comment-to-revised-proposal cycle, not just unit-level.

Related

• Implement Distill #86 (Distill) is the sibling agent-driven job, split out at the same time for the same reason.
• Design a configurable agent execution contract #9's agent execution contract is a likely prerequisite for how rework invokes a model.
• Extract reusable proposal and review primitives #11 (closed) is the parent design that originally scoped rework as a placeholder.