Mutating seams read --dir through the permissive flag reader #137
Labels
No labels
already-shipped
bug
documentation
duplicate
enhancement
external-review
good first issue
help wanted
in progress
invalid
needs-decision
proposal
question
security
wontfix
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: crenshawdev/cadence-archived#137
Loading…
Add table
Add a link
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?
Source: deep dive F6
Verdict: AGREE - medium (narrowed from the reviewer's framing)
Claim as reviewed
optionalFlagdeliberately returnsundefinedfor both an absent flag and a present flag with no value, and multiple effectful entry points then applyflag('--dir') || process.cwd(). The stricterflagValuehelper exists specifically to distinguish the two, but the mutating seams do not use it.At HEAD
f354864(v3.3.0)cadence-core/bin/lib/seam-input.mjs:45-60-optionalFlagcollapses absent and present-with-no-value.cadence-core/bin/lib/seam-input.mjs:63-89-flagValueexists for exactly this, and its doc comment names the failure class: "the caller got ok:true and the Cadence repo's numbers for a tree it never named. That is the quiet-wrong-number class, and it is worse than a hard error because the envelope looks correct."cadence-core/bin/git-publish.mjs:204-215-publish(flag('--dir') || process.cwd(), flag('--remote') || 'origin').cadence-core/bin/release-bump.mjs:202-219- same shape for--dirand--date.Note
Narrowed on verification:
git-publishstill re-checksrepoAutoCloseand the protected-branch list against whatever directory it landed on, so pushing an unintended repository requires that repository to have repo-layerauto_closetrue as well.release-bumpis the live one - an empty--dirbumps whatever manifest sits under the session's cwd, with no second check.v3.5.4 also carries #147, which is the extraction question for this exact defect. Answer it here, not after: the fix is either (a) switch the mutating seams to the existing flagValue reader, which is a few lines and closes the reported defect, or (b) build the declarative parser #147 describes. Do not build (b) speculatively - the zero-dependency constraint and the size of (a) both argue for (a), and #147 should close as not-worth-it if that is what the work shows.
Closed by v3.5.5 (ARG-01, verified against the shipped tree).