Fix an EmptySection false positive and grade DuplicateSession (1.0.1)

## What does this PR do? Fixes two problems found by using the tooling on real checkpoints rather than on the fixtures it was built against. Releases 1.0.1. **`EmptySection` false positive.** The body capture stopped at the next heading of *any* level, so a section whose content begins with a subheading was reported as empty. A real checkpoint with `## Accomplished` followed by `### Security work` was flagged despite being well formed. It now captures up to the next heading of the same or higher level. **`DuplicateSession` was ungraded.** It reported High whenever an identifier appeared in more than one file. Agent sessions are long lived, and a session resumed across days legitimately writes one file per day, so the check fired on correct usage. A check that fires on correct usage teaches people to ignore it. It now reports High only when the files share a date, which is the actual violation and the signature of an identifier copied forward from a restored checkpoint, and Low with an accurate message when they span days. **The rule behind the check was also wrong.** `SKILL.md` said one file per session. It now says one file per day, and explains why the two diverge: a session can be resumed for weeks, and a file covering three weeks is a diary rather than resumable state. `references/anti-patterns.md` entry 4 is reframed around the same day, and entry 2 now records that a shared identifier alone is not evidence of copying; what gives copying away is a file describing "previous sessions" while claiming to be one of them. Version bumped to 1.0.1 in all four manifests. The catalog's own `metadata.version` is deliberately left at 1.0.0, because it versions the marketplace catalog and not the plugin. ## How was this tested? - [x] `./scripts/Invoke-RepoChecks.ps1` passes with no findings - [x] The real file that exposed the bug now reports no `EmptySection`, and `DuplicateSession` at Low reading "spans 13 days" - [x] Regression: a same-day pair sharing an identifier still reports High - [x] Regression: a genuinely empty section still reports `EmptySection` - [x] Regression: a section whose content is only a subheading is not reported - [x] `Test-Checkpoint.ps1` parses Neither check was weakened to silence the warning; both still detect the cases they were written for. ## Checklist - [x] I have read the [Contributing Guide](../CONTRIBUTING.md) - [x] Changes are focused; one logical change per PR - [x] Documentation updated where behaviour changed - [x] No real host names, databases, employers, colleagues, or local paths in any example - [x] Any new entry in `references/anti-patterns.md` has a real observed example behind it - [x] No commented-out code or debug leftovers

hannah-vernon commented

2026-09-09 15:57:07 -05:00

Owner

What does this PR do?

Fixes two problems found by using the tooling on real checkpoints rather than on the fixtures it was built against. Releases 1.0.1.

EmptySection false positive. The body capture stopped at the next heading of any level, so a section whose content begins with a subheading was reported as empty. A real checkpoint with ## Accomplished followed by ### Security work was flagged despite being well formed. It now captures up to the next heading of the same or higher level.

DuplicateSession was ungraded. It reported High whenever an identifier appeared in more than one file. Agent sessions are long lived, and a session resumed across days legitimately writes one file per day, so the check fired on correct usage. A check that fires on correct usage teaches people to ignore it. It now reports High only when the files share a date, which is the actual violation and the signature of an identifier copied forward from a restored checkpoint, and Low with an accurate message when they span days.

The rule behind the check was also wrong. SKILL.md said one file per session. It now says one file per day, and explains why the two diverge: a session can be resumed for weeks, and a file covering three weeks is a diary rather than resumable state. references/anti-patterns.md entry 4 is reframed around the same day, and entry 2 now records that a shared identifier alone is not evidence of copying; what gives copying away is a file describing "previous sessions" while claiming to be one of them.

Version bumped to 1.0.1 in all four manifests. The catalog's own metadata.version is deliberately left at 1.0.0, because it versions the marketplace catalog and not the plugin.

How was this tested?

./scripts/Invoke-RepoChecks.ps1 passes with no findings
The real file that exposed the bug now reports no EmptySection, and DuplicateSession at Low reading "spans 13 days"
Regression: a same-day pair sharing an identifier still reports High
Regression: a genuinely empty section still reports EmptySection
Regression: a section whose content is only a subheading is not reported
Test-Checkpoint.ps1 parses

Neither check was weakened to silence the warning; both still detect the cases they were written for.

Checklist

I have read the Contributing Guide
Changes are focused; one logical change per PR
Documentation updated where behaviour changed
No real host names, databases, employers, colleagues, or local paths in any example
Any new entry in references/anti-patterns.md has a real observed example behind it
No commented-out code or debug leftovers

hannah-vernon added 1 commit

Fix an EmptySection false positive and grade DuplicateSession (1.0.1) 8cbb979d1f

Both found by pointing the tooling at real checkpoints rather than at
the fixtures it was built against.

EmptySection captured a section body up to the next heading of any
level, so a section whose content begins with a subheading was reported
as empty.  It now captures up to the next heading of the same or higher
level.  A genuinely empty section is still reported.

DuplicateSession reported High whenever an identifier appeared in more
than one file.  Agent sessions are long lived and a session resumed over
days legitimately writes one file per day, so the check fired on correct
usage, which teaches people to ignore it.  It now reports High only when
the files share a date, which is the real violation, and Low with an
accurate message when they span days.

The underlying rule was wrong too, not just the check.  SKILL.md said
one file per session; it now says one file per day, and explains that
the two diverge because a session can be resumed for weeks.  A file
covering three weeks is a diary, not resumable state.  anti-patterns.md
entry 4 is reframed around the same day, and entry 2 now notes that a
shared identifier alone is not evidence of copying.

Verified: the file that exposed the bug now reports no EmptySection and
DuplicateSession at Low; a same-day pair still reports High; a genuinely
empty section still reports.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

hannah-vernon merged commit b3e7f505e5 into dev

2026-09-09 15:57:08 -05:00

hannah-vernon referenced this pull request from a commit

2026-09-09 15:57:09 -05:00

Merge pull request 'Fix an EmptySection false positive and grade DuplicateSession (1.0.1)' (#8) from fix/lint-false-positives into dev

Rows
Columns

Fix an EmptySection false positive and grade DuplicateSession (1.0.1) #8

What does this PR do?

How was this tested?

Checklist