Summary
rgit review / rgit resegment currently lack validation around proposal state and candidate shape. When a user or agent passes the wrong argument or malformed JSON, the graph can be silently polluted, or a later CLI command can crash with a traceback.
Problems
-
A resolved proposal can be approved again.
curation.approve() does not check prop.status.
- Re-approving the same proposal creates duplicate capsules and repeats related edges.
-
review --approve --name <name> falls back to candidate_index when the name does not match.
- A typo can approve candidate 0 and assign it the wrong user-provided name.
- Expected: if
--name is provided and no candidate matches, fail clearly.
-
resegment accepts arbitrary JSON / candidate shape.
- Missing or extra
code_slices fields can later make approve() raise an uncaught TypeError.
- A candidate missing
name can also break the rgit review listing.
-
Store.set_proposal_candidates() and set_proposal_status() do not report whether a row was actually updated.
- A mistyped proposal id can look successful even though nothing changed.
Expected Behavior
- Only
open proposals can be approved or dismissed.
- If
--name is provided, it must match a candidate; otherwise the command should return a clear error.
resegment should validate that input is a list of candidate dictionaries with the required fields.
- Malformed candidates should produce a friendly CLI error, not a traceback.
- Updating an unknown proposal id should fail clearly.
Suggested Tests
- Approving an already resolved proposal fails and does not create a second capsule.
- A resolved proposal cannot be dismissed again, or is rejected consistently.
review --approve <pid> --name typo fails instead of approving index 0.
resegment <bad-id> returns non-zero status and a clear error.
resegment rejects candidates with missing name, missing intent, or malformed code_slices.
rgit review listing does not crash on existing malformed candidates, or reports them clearly.
Summary
rgit review/rgit resegmentcurrently lack validation around proposal state and candidate shape. When a user or agent passes the wrong argument or malformed JSON, the graph can be silently polluted, or a later CLI command can crash with a traceback.Problems
A resolved proposal can be approved again.
curation.approve()does not checkprop.status.review --approve --name <name>falls back tocandidate_indexwhen the name does not match.--nameis provided and no candidate matches, fail clearly.resegmentaccepts arbitrary JSON / candidate shape.code_slicesfields can later makeapprove()raise an uncaughtTypeError.namecan also break thergit reviewlisting.Store.set_proposal_candidates()andset_proposal_status()do not report whether a row was actually updated.Expected Behavior
openproposals can be approved or dismissed.--nameis provided, it must match a candidate; otherwise the command should return a clear error.resegmentshould validate that input is a list of candidate dictionaries with the required fields.Suggested Tests
review --approve <pid> --name typofails instead of approving index 0.resegment <bad-id>returns non-zero status and a clear error.resegmentrejects candidates with missingname, missingintent, or malformedcode_slices.rgit reviewlisting does not crash on existing malformed candidates, or reports them clearly.