review-state: the phase key of a checkpoint is unconstrained, so two spellings make two entries #492
Labels
No labels
agent-ready
bug
contract
documentation
duplicate
enhancement
good first issue
help wanted
invalid
needs-human
needs-input
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
iterative-works/iw-cli#492
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found triaging IW-436 (LESSONS.md entry 2).
parseCheckpoint(core/model/ReviewStateCliParser.scala:75-79) splits--checkpointon the first colon and accepts any string as the phase key. So--checkpoint 1:<sha>and--checkpoint phase-01:<sha>create two separate entries for the same phase, and neither the validator (ReviewStateValidator.scala:365-388) nor the schema constrains the key.Both spellings are in use in this repository
schemas/review-state.schema.json:117-122gives examples keyed"1"and"2".core/test/ReviewStateCliParserTest.scala:141,321,449uses"phase-01"and"phase-02".Nothing decides which is correct, so a revert-to-phase lookup can miss a checkpoint that is present under the other spelling.
Wanted
Settle the phase-key format, then enforce it — in
parseCheckpoint, and consistently in the schema examples and the tests.Scope note
Out of scope for IW-436, which fixed the checkpoint value (#464 SHA validation, #446 merge mode), not the key.
From IW-718 follow-ups:
--checkpoint 2:<sha>appended to a card that holds"02"leaves both"2"and"02"; the drop (--drop-checkpoints-after, IW-718) treats both as phase 2, but the duplicate stays. —core/model/ReviewStateUpdater.scalacheckpoint union keys on the raw stringIntake: agent-ready
Workflow: waterfall
Reason: all gates passed
Analysis: project-management/issues/IW-492/analysis.md on branch IW-492
Implement: needs-human
Reason: batch-implement exit 1 — the kanon plugin does not compile against the iw-cli core on main: ForgeCatchUp.scala:143 expects Either[String, …] from fetchPullRequestForBranch, and core now returns Either[TrackerError, …] (#778, #780). No phase ran; nothing in IW-492 is at fault. There is no batch-implement.log, because the command stopped at compile time; the lines below are its output.
Release: the implement loop failed this issue for a reason outside it. The kanon plugin did not compile against iw-cli main, because the tracker port now returns TrackerError (iw-cli #778). The plugin fix is dev-docs #484, and iw-cli 0.22.1 carries the core change. The issue goes back to the implement loop.