Development record

2026-08-02 — iss-39 (merge-gate round 3): the exemption-scope enumeration is made exhaustive, and the block-sequence parse stops truncating. `scanIntentTree` lost its `contentExempt` filter, and that one scan feeds TWO rules — `intent_lifecycle` and `intent_impact_valid` — but the CHANGELOG, the `ExemptPaths` doc, the per-file walk comment, and `contentExempt`'s own doc each named only the first while reading as an exhaustive partition. A reader arming `intent_impact_valid` with `exempt_paths` would therefore conclude it was unchanged and be surprised on upgrade by a new blocker over an exempt record's illegal `impact:` value, so the changelog now states that consequence outright. `record_schema` is dropped from that partition and stated separately: it is cross-store and never consulted the exemption, so describing it as having "stopped" honouring one was wrong in a way that would mislead anyone trying to reason about which rules the exemption still governs. Separately, `blockSequenceAt` broke on a blank or comment line inside a sequence rather than skipping past it. YAML reads `- a`, blank, `# note`, `- b` as one two-item list; stopping at the interruption dropped the tail, and a dropped `supersedes` handle is not a quiet under-read — it made the bidirectional check assert that another file omits a link that file plainly carries, which is the same false-claim failure the block parse was added to prevent. The corpus has no interrupted sequence today (every `.md` scanned), so this closed a latent hole rather than a live one. The closing `---` is neither blank nor a comment, so the scan still ends at the frontmatter boundary — covered by its own test, because a skip that ran past the delimiter would read a body list as the key's value.