fix(security): move the interview protection note to the rule that provides it (#337)

The two-line comment above `documents/interview/**` says interview prep and
experience records live there. Nothing has ever written to that directory:
/interview saves its pack to
documents/applications/<company>_<role>/interview_prep_<stage>.md, covered by
the documents/applications/** rule. `git grep documents/interview` returns
only the two declarations of the rule itself (.gitignore and
REQUIRED_IGNORE_RULES), `git log --all -- 'documents/interview*'` is empty,
and documents/README.md documents the applications path outright.

Nothing leaks - the comment is the defect, and it is the misleading kind. It
is the one dedicated, well-argued line about interview material in the
personal-data block, so an auditor checking that the framework's most
sensitive artifact is covered reads it and stops, at the only path in the
block with no writer.

The comment's description of what needs protecting was always right; only its
location was wrong. It now sits above documents/applications/**, the rule that
actually provides that protection, so a reader auditing the block finds the
reasoning attached to the rule doing the work. documents/interview/** stays -
REQUIRED_IGNORE_RULES pins it, so dropping it from .gitignore alone turns CI
red, and it is harmless defence in depth - relabelled in both files as
belt-and-braces rather than the primary guard.

The new check-ignore case in GitignorePatternBehaviorTests derives the
prep-pack path from /interview's own spec instead of hardcoding it. That
distinction is the whole value of the test: a hardcoded path pins only that
documents/applications/** still matches that shape, which security_guards.py
already catches first, and stays green if /interview moves its output -
leaving the corrected comment stale exactly the way this issue found it.
Since #329 the spec states the location in two pieces - Step 1 derives the
archive folder, Step 3 names interview_prep_<stage>.md - so the test pins both
fragments separately and composes the concrete path from them. Mutation-
verified on each half: repointing the folder at documents/prep_packs/, and
renaming the file, both fail this test while `python3 tools/security_guards.py`
still reports OK.

The class's temp-repo setup moved to setUp for the second case.

ayobamiseun reviewed the pre-rebase branch and called all three rebase hazards
in advance: the split literal, the released CHANGELOG context, and the setUp
re-merge. Reached independently here during the rebase; the review was posted
first.
This commit is contained in:
Jakob Stender Guldberg
2026-08-31 17:49:22 +02:00
committed by GitHub
parent 42ba4b475a
commit 4c38f7ce4c
4 changed files with 72 additions and 16 deletions
+14
View File
@@ -26,6 +26,20 @@ per-file diff commands.
### Fixed
- **The `documents/interview/**` ignore rule no longer claims interview prep is written there**
(#336). `/interview` saves its pack to
`documents/applications/<company>_<role>/interview_prep_<stage>.md`, already ignored by
`documents/applications/**`; nothing has ever written to `documents/interview/`. Nothing leaked -
but it was the personal-data block's one dedicated line about interview material, so an auditor
checking the framework's most sensitive artifact had every reason to read it and stop, at the
only path in the block with no writer. The protection rationale now sits above
`documents/applications/**`, the rule that actually provides it, so the next reader finds it
where it lives; `documents/interview/**` stays, relabelled belt-and-braces rather than primary
guard (`REQUIRED_IGNORE_RULES` pins it, so removing it from `.gitignore` alone fails the guard).
Pinned by `tests/test_security_guards.py`, which derives the prep-pack path from
`/interview`'s own spec instead of hardcoding it - so moving that path fails CI rather than
quietly re-staling the comment.
- **`/scrape` now persists each posting's publication date** (#390) - Step 2's contract guarantees a
`date` on every portal CLI's search output (CI enforces it in `test_scrape_contract.py`) and
Step 1b uses that date to scope a run to the last 14 days, but Step 4's `seen_jobs.json` schema