Development record
GuardFindings reads the open/ issue folder at HEAD, so a major or critical finding captured but not yet committed is invisible to the findings gate; with --allow-dirty past the ingest's dirty-tree gate, the cut proceeds past it. Same class as iss-2610050259118177 (records read at HEAD), on the open side.
issueresolvedminoriss-2610050927169919
GuardFindings reads the open/ issue folder at HEAD, so a major or critical finding captured but not yet committed is invisible to the findings gate; with --allow-dirty past the ingest's dirty-tree gate, the cut proceeds past it. Same class as iss-2610050259118177 (records read at HEAD), on the open side.
Grounds
- pursued: launch ship over an uncommitted major/critical capture in open/ is refused naming the path, with or without --allow-dirty; shown wrong if Emit returns a ready cut while any open/ record differs from HEAD, or if dirt outside open/ (a README, a non-record file) refuses a clean cut
Frontmatter
| id | iss-2610050927169919 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610050927169919-the-findings-gate-reads-open-issues-at.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2610050259118177launch ship reads the release's records at HEAD (ShippedSince lists them with git ls-tree HEAD), so a spec close left uncommitted in the working tree is neither refused nor included: during the v0.13.0 cut, `launch ship --json` with the home-rename spec's close uncommitted returned rc=0 and a plausible cut of 54 records that silently left out the shipped intent itd-2610030720038073. The dirty-tree refusal fires only on the ingest (--changelog-json), not on the derivation the person reads first.