Section 03: Tracked Artifact Removal & Gitignore Verification
Status: Not Started
Goal: Remove the two tracked build/debug/* artifacts (simplest_crash.ll and test_simple) that were committed to git before (or alongside) the existing **/build/ gitignore rule was added, and that therefore persist as tracked despite the rule. Important architectural correction (TPR-XX-002-codex iteration 3 fix — 2026-04-11): the **/build/ gitignore rule ALREADY correctly matches these paths — verified empirically via git check-ignore -v --no-index build/debug/simplest_crash.ll which returns .gitignore:5:**/build/. The reason Pass 1 research saw “no output” from git check-ignore (without --no-index) is that git’s check-ignore command by design returns “not ignored” for files that are already TRACKED — tracked files override ignore rules. This is not a gitignore drift bug; it’s already-tracked-files-that-should-be-untracked. The fix is git rm --cached on the two files; no gitignore edit is needed (the **/build/ rule already protects against future leaks).
Success Criteria:
-
git ls-files build/returns empty — both leaked files are no longer tracked -
git check-ignore -v --no-index build/debug/simplest_crash.llreturns a matched rule (verifying**/build/already covers the path for future files — using--no-indexbecausecheck-ignoreignores tracked files by default) -
git ls-files compiler/oric/src/commands/build/returns its existing tracked files (the negative rule!compiler/oric/src/commands/build/is still working) -
profile.json.gzis still ingit ls-files(this section does NOT delete it — it’s intentionally tracked as a perf reference) -
.gitignoreis UNCHANGED from plan-start state (no new/build/rule added — that was my iteration 1 false premise corrected in iteration 3; the existing**/build/already handles root-level/build/correctly via its**path component semantics) -
./test-all.shgreen post-fix - Single atomic commit lands:
fix(plan): remove tracked build/debug leak - Satisfies mission criterion: “Gitignore drift bug fixed” (reclassified: the bug is tracked-files-that-should-not-be, NOT an actual gitignore pattern gap)
Context (TPR iteration 3 rewrite): The Pass 1 research agent ran git check-ignore -v build/debug/simplest_crash.ll and received NO output. I originally interpreted this as “the file is not ignored by any rule” and concluded **/build/ had a pattern gap. This was wrong. Fresh empirical verification on 2026-04-11:
# Tests whether the PATH would be ignored IF it weren't tracked
$ git check-ignore -v --no-index build/debug/simplest_crash.ll
.gitignore:5:**/build/ build/debug/simplest_crash.ll
# Tests whether the file is CURRENTLY subject to ignore (no for tracked files)
$ git check-ignore -v build/debug/simplest_crash.ll
(no output — because tracked files override ignore rules)
The **/build/ rule works correctly — ** matches zero or more path components, which INCLUDES the zero-component case (root-level build/). The rule matches build/ at any depth, including root. My earlier claim (“gitignore treats ** as zero-or-more path components, which sometimes excludes the root-level case”) was incorrect. **/build/ DOES match root-level build/, full stop.
So why are the files tracked if the rule matches? Because gitignore rules do not apply retroactively to already-tracked files. Once a file is in the git index, subsequent additions to .gitignore don’t remove it — you must explicitly git rm --cached it. This is git’s normal behavior, not a bug. The files were likely committed before the **/build/ rule was added to .gitignore, or via git add -f at some point. The git check-ignore command (without --no-index) reflects the CURRENT state, which correctly reports “not ignored” for tracked files.
Implication: the fix is entirely git rm --cached on the two tracked files. The existing **/build/ rule already prevents FUTURE leaks. No gitignore edit is needed. The previous iteration 1 / iteration 2 instruction to add a root-anchored /build/ rule is withdrawn as unnecessary redundancy.
The critical constraint is that compiler/oric/src/commands/build/ is a legitimate source directory containing tracked Rust files. The existing .gitignore has two negative rules that preserve it:
!compiler/oric/src/commands/build/
!compiler/oric/src/commands/target/
These negative rules continue working — no change needed. The **/build/ rule + the negative rule correctly handle all cases: build/debug/* at root is ignored (for future files); compiler/oric/src/commands/build/ is tracked (negative rule wins).
Reference implementations:
- git gitignore documentation:
**/build/matchesbuild/at any depth, including root level. The**glob matches zero or more path components. - TPR iteration 3 empirical verification:
git check-ignore -v --no-index build/debug/simplest_crash.llreturned.gitignore:5:**/build/— confirming the rule matches. The--no-indexflag is load-bearing: without it,check-ignorereports “not ignored” for tracked files by design, which is what led iteration 1 to the false root-cause.
Depends on: §01 (baseline must prove the tracked state before the fix).
03.1 Tracked Artifact Removal
File(s): build/debug/simplest_crash.ll, build/debug/test_simple
Remove the two leaked files from git tracking (but not from disk — they stay as gitignored local artifacts, matching the intent).
-
Verify the files are currently tracked:
cd /home/eric/projects/ori_lang git ls-files build/ # Expected: build/debug/simplest_crash.ll + build/debug/test_simple- Both files are listed. If either is missing, investigate — someone may have already removed it between baseline and now.
-
Verify nothing ELSE is tracked under
build/:git ls-files build/ | wc -l # Expected: 2- If >2: STOP. Another file leaked through the gitignore pattern; investigate and add to the removal list.
- If 0: the files were already removed; skip to 03.2 and document “already removed by {commit hash}”
-
Remove the tracked files from git index only (files stay on disk — they are ALREADY covered by the existing
**/build/rule at.gitignore:5, per iteration 3’s--no-indexverification; no new rule is added in 03.2):git rm --cached build/debug/simplest_crash.ll build/debug/test_simple- Why
--cachedand not plaingit rm: the files on disk are legitimate local artifacts (debug IR dump and a compiled test binary). Developers may still want them for debugging.--cachedremoves them from git tracking without deleting the files.
- Why
-
Verify the removal staged:
git status | grep 'build/' # Expected: 'deleted: build/debug/simplest_crash.ll' and similar for test_simple (staged) -
Do NOT commit yet — the §03.2 gitignore verification must run before the §03.3 commit to confirm the existing
**/build/rule already covers root-levelbuild/. -
Subsection close-out (03.1) — MANDATORY before starting 03.2:
- Both files are staged for removal (
git statusshowsdeleted:entries) - Files still exist on disk (
ls build/debug/shows them — they’re already covered by the existing**/build/rule at.gitignore:5, so after §03.3’s commit removes them from the index they’ll be gitignored automatically) - Update this subsection’s
statusin section frontmatter tocomplete - Run
/improve-toolingretrospectively on THIS subsection — reflect on whethergit ls-files build/was the right discovery command. Is there ascripts/dev/gitignore-leaks.shhelper that would scan the entire repo for “tracked files thatgit check-ignoresays should be ignored” (the generalization of “find all leaked-past-gitignore artifacts”)? That would be broadly useful. If yes, add and commit viabuild(scripts): add gitignore-leaks.sh — surfaced by project-reorganization/section-03.1 retrospective. If no: “Retrospective 03.1: no tooling gaps — direct git ls-files adequate.” - Run
/sync-claudeon THIS subsection — check whether code changes invalidated any CLAUDE.md,.claude/rules/*.md, orcanon.mdclaims. If no API/command/phase changes, document briefly. Fix any drift NOW.
- Both files are staged for removal (
03.2 Gitignore Verification (No Edit Required) — iteration 3 correction
File(s): .gitignore (READ-ONLY verification; NO edits per TPR-XX-002-codex iteration 3 fix)
CORRECTION — iteration 3: This subsection previously prescribed adding a root-anchored /build/ rule to .gitignore. That was based on a factually incorrect reading of git check-ignore output (we ran it on tracked files without --no-index, which returns “not ignored” by design — git’s check-ignore defers to the index for tracked files). Fresh empirical verification (2026-04-11):
$ git check-ignore -v --no-index build/debug/simplest_crash.ll
.gitignore:5:**/build/ build/debug/simplest_crash.ll
$ git check-ignore -v --no-index build/debug/test_simple
.gitignore:5:**/build/ build/debug/test_simple
The existing **/build/ rule at .gitignore:5 already matches both files. No new gitignore rule is needed — the rule works correctly. This subsection is therefore a verification-only step, not an editing step.
-
Verify the
**/build/rule already covers the root-levelbuild/path with--no-index(bypassing the tracked-file override):git check-ignore -v --no-index build/debug/simplest_crash.ll git check-ignore -v --no-index build/debug/test_simple # Expected output for each: .gitignore:5:**/build/ <path>- Both commands match
.gitignore:5:**/build/ - Without
--no-index, both return empty (because §03.1 already removed tracking, or because the files are still in the index). After §03.1 completes AND the commit lands,git check-ignore -v <path>(without--no-index) should ALSO match the rule because the files are no longer in the index.
- Both commands match
-
Verify the existing negative rule for
compiler/oric/src/commands/build/still applies (to guard against accidentally ignoring source code namedbuild):# Pick one tracked file from the compiler command directory file=$(git ls-files compiler/oric/src/commands/build/ | head -1) git check-ignore -v "$file" || echo "not ignored (expected — negative rule wins)"- Exit code 1 (not ignored — meaning the negative rule at
.gitignore:11:!compiler/oric/src/commands/build/correctly exempts these files)
- Exit code 1 (not ignored — meaning the negative rule at
-
.gitignoreis UNCHANGED — verify:git diff .gitignore # Expected: no output (no changes)-
.gitignorediff is empty
-
-
Subsection close-out (03.2) — MANDATORY before starting 03.3:
-
.gitignoreis NOT edited in this section (iteration 3 correction — the rule already works) -
git check-ignore -v --no-indexconfirms**/build/matches root-levelbuild/ - Negative rule for
compiler/oric/src/commands/build/still works - Update this subsection’s
statusin section frontmatter tocomplete - Run
/improve-toolingretrospectively on THIS subsection — the real tooling gap surfaced here is thatgit check-ignorewithout--no-indexsilently returns “not ignored” for tracked files, which misleads newcomers into thinking gitignore patterns don’t match. Is this gotcha documented anywhere in the repo? If not: is a briefdocs/development/gitignore-gotchas.mdor a CLAUDE.md note worth adding so future maintainers don’t fall into the same trap iteration 1 fell into? Yes — add it. Commit viadocs(development): document git check-ignore tracked-file gotcha — surfaced by project-reorganization/section-03.2 retrospective (TPR iteration 3). - Run
/sync-claudeon THIS subsection — check whether code changes invalidated any CLAUDE.md,.claude/rules/*.md, orcanon.mdclaims. If no API/command/phase changes, document briefly. Fix any drift NOW.
-
03.3 Negative Rule Verification
File(s): No edits — verification only
Prove that the existing **/build/ rule still does NOT break the existing negative rules for compiler/oric/src/commands/build/. This is the regression guard: since we are NOT adding a new rule in iteration 3, this should be a trivial verification — the negative rules continue to work exactly as they did before this section ran.
-
Verify the tracked contents of
compiler/oric/src/commands/build/are still tracked:git ls-files compiler/oric/src/commands/build/ | head -20 # Expected: multiple tracked Rust files (mod.rs, etc.)- At least one file is still tracked
- The file list matches the baseline captured in §01.1
-
Verify that git check-ignore treats those files correctly:
# Pick one tracked file from the command directory file=$(git ls-files compiler/oric/src/commands/build/ | head -1) git check-ignore -v "$file" || echo "not ignored (expected)"- Expected result:
git check-ignore -vreturns with exit code 1 and no output, meaning the file is NOT ignored (because the negative rule wins).
- Expected result:
-
Verify
./test-all.shstill green (guards against compiler build breakage from a botched gitignore edit):timeout 150 ./test-all.sh 2>&1 | tail -10- Exit code 0
- All phases PASS
-
Verify
profile.json.gzis still tracked (not accidentally deleted by this section — it’s intentional):git ls-files profile.json.gz # Expected: 'profile.json.gz' -
Commit everything from §03 as a single atomic commit. Per TPR-XX-002-codex iteration 3 fix: the commit does NOT include a
.gitignoreedit. Only the 2git rm --cachedremovals land — the existing**/build/rule is unchanged.cd /home/eric/projects/ori_lang # build/debug/simplest_crash.ll and build/debug/test_simple are already staged # for removal from 03.1. NO .gitignore edit — the existing **/build/ rule # already covers root-level build/ (verified in 03.2 via --no-index). git commit -m "fix(plan): remove tracked build/debug leak
Two files were tracked despite the ’**/build/’ gitignore rule because they were committed before the rule was added to .gitignore (or via ‘git add -f’ at some point). Once in the index, gitignore rules no longer apply — the fix is ‘git rm —cached’, NOT a gitignore edit.
build/debug/simplest_crash.ll build/debug/test_simple
Empirical verification (2026-04-11 TPR iteration 3): git check-ignore -v —no-index build/debug/simplest_crash.ll → .gitignore:5:**/build/ build/debug/simplest_crash.ll
The ‘/build/’ rule at .gitignore:5 already matches root-level build/. The iteration 1 premise that ‘/build/ doesn’t match root-level build/ due to ** path component semantics’ was factually wrong. The existing negative rules for compiler/oric/src/commands/build/ are preserved and continue to work.
profile.json.gz stays tracked (intentional perf reference).
Refs: plans/project-reorganization/section-03-tracked-artifacts.md”
- [ ] Verify the commit:
```bash
git log --oneline -1
# Expected: fix(plan): remove tracked build/debug leak
git show --stat HEAD
# Expected: build/debug/simplest_crash.ll -1/-0 (deleted),
# build/debug/test_simple -1/-0 (deleted)
# NOT expected: .gitignore change (that was iteration 1's false premise)
- Subsection close-out (03.3) — MANDATORY before 03.R:
- Negative rules verified intact
-
./test-all.shgreen -
profile.json.gzstill tracked - Commit landed atomically (3 files in one commit)
- Update this subsection’s
statusin section frontmatter tocomplete - Run
/improve-toolingretrospectively on THIS subsection — reflect on the verification approach. Was the “check-ignore on a tracked source file to prove negative rule wins” verification obvious, or would ascripts/dev/verify-gitignore.shhelper that runs standard sanity checks (tracked files still tracked, ignored files still ignored, pattern collisions flagged) help future .gitignore edits? If yes: add and commit viabuild(scripts): add verify-gitignore.sh — surfaced by project-reorganization/section-03.3 retrospective. Otherwise: “Retrospective 03.3: no tooling gaps — direct git check-ignore adequate for single-rule verification.” - Run
/sync-claudeon THIS subsection — check whether code changes invalidated any CLAUDE.md,.claude/rules/*.md, orcanon.mdclaims. If no API/command/phase changes, document briefly. Fix any drift NOW.
03.R Third Party Review Findings
-
[TPR-XX-002-codex][high](iteration 3)plans/project-reorganization/section-03-tracked-artifacts.md:41— WASTE: Remove the false /build/ root-cause from §03. Evidence: §03 claimed**/build/does NOT match root-levelbuild/directory due to gitignore pattern resolution. Fresh empirical verification withgit check-ignore -v --no-index build/debug/simplest_crash.llreturned.gitignore:5:**/build/ build/debug/simplest_crash.ll— the rule DOES match. The no-output probe cited in Pass 1 research was fromgit check-ignoreWITHOUT--no-indexrun on TRACKED files; git’scheck-ignoredefers to the index for tracked files, returning “not ignored” by design. The iteration 1 plan prescribed an unnecessary/build/root-anchored rule addition. Impact: §03 and 00-overview.md were anchored to incorrect gitignore semantics, prescribing unnecessary.gitignorechurn instead of identifying the real problem: tracked-files-that-should-not-be (committed before the rule existed, or viagit add -f). Required plan update: Rewrite §03 (goal, success_criteria, context, §03.2 subsection, commit message template) and 00-overview.md (mission success criterion, current-state diagram, Known Bugs table) to treat this as removal of already-tracked build artifacts under an existing ignore rule. Drop the/build/edit. Fix verification commands to usegit check-ignore --no-indexwhere pre-removal ignore semantics are being demonstrated. Basis: fresh_verification. Confidence: high. Resolved: Fixed on 2026-04-11 iteration 3. Rewrote §03 goal, success_criteria, context paragraph, reference implementations, and §03.2 subsection (now “Gitignore Verification (No Edit Required)” — verification-only, not editing). Updated commit message template to drop the.gitignoreadd. Updated 00-overview.md mission success criterion “Gitignore drift bug fixed” to “Tracked build/debug artifacts removed” with the empirical--no-indexproof. Updated 00-overview.md Known Bugs row to reflect the correct root cause. The iteration 1 false premise is now explicitly documented and corrected inline.
-
[TPR-XX-001-gemini][high]+[TPR-XX-001-codex][medium](iteration 4)plans/project-reorganization/section-03-tracked-artifacts.md:multiple— Remove vestigial gitignore edit references from §03 and propagate the §03 rewrite to every reference. Evidence: Iteration 3’s §03 rewrite updated the main body but left stale pre-rewrite text in multiple execution-critical places: §03 frontmatter sections list still titled §03.2 as “.gitignore Root-Anchored /build/ Rule Addition”; §03.1 body said “files will be gitignored by the rule added in 03.2”; §03.3 body said “new /build/ rule must not break…”; §03.N completion checklist had “/build/rule added to.gitignore(03.2)” and “gitignore root anchor” commit message; §03 exit criteria said “3 file operations (2 deletions + 1 gitignore edit)”. Impact: The §03 propagation was incomplete — executors following the checklist or reading the frontmatter sections list would still attempt to edit.gitignore, contradicting the corrected §03.2 body. Required plan update: Rename §03.2 frontmatter title; remove/build/ ruletext from §03.1 and §03.3 bodies; update §03.N completion checklist items; update §03 exit criteria to say “2 file operations (both deletions)”. Basis: direct_file_inspection + fresh_verification. Confidence: high. Resolved: Fixed on 2026-04-11 iteration 4. (a) §03.2 frontmatter title → “Gitignore Verification (No Edit Required)”. (b) §03.1 body: “gitignored by the rule added in 03.2” → “ALREADY covered by the existing**/build/rule at.gitignore:5, per iteration 3’s--no-indexverification”. (c) §03.3 body: “Prove that the new/build/rule does NOT break…” → “Prove that the existing**/build/rule still does NOT break…”. (d) §03.N checklist: “/build/rule added to.gitignore(03.2)” → “.gitignoreverified UNCHANGED (03.2)”; “gitignore root anchor” commit message tag removed. (e) §03 exit criteria: “3 file operations (2 deletions + 1 gitignore edit)” → “2 file operations (both deletions; NO.gitignoreedit)”. Now every reference to iteration 1’s false premise is corrected. -
[TPR-XX-003-gemini][low]+[TPR-XX-002-gemini][medium](iteration 4)plans/project-reorganization/00-overview.md:157,250,382+section-09-verification.md:255,459— Remove vestigial gitignore edit from overview and §09 final commit template. Evidence: 00-overview.md line 250 Implementation Sequence still said “§03 Tracked artifact removal + /build/ gitignore fix”; line 382 Estimated Effort table said “§03 Tracked Artifact + Gitignore Fix”; line 157 dependency graph comment said “gitignore fix”. §09 final commit template line 459 still claimed “.gitignore /build/ rule added” and line 255 said “Modified: .gitignore (if §03 decides…)” which was vague. Impact: Overview and §09 final commit template disagreed with §03’s iteration 3 correction. Required plan update: Update overview implementation sequence / effort table / dependency graph and §09 final commit template / modified files list to remove all “.gitignore rule added” references. Basis: direct_file_inspection. Confidence: high. Resolved: Fixed on 2026-04-11 iteration 4. (a) 00-overview dependency graphgitignore fix→gitignore verify. (b) Implementation Sequence§03 Tracked artifact removal + /build/ gitignore fix→§03 Tracked artifact removal (+.gitignoreverification; no edit — iteration 3 correction). (c) Estimated Effort table§03 Tracked Artifact + Gitignore Fix→§03 Tracked Artifact Removal & Gitignore Verification. (d) §09 final commit template2 build/debug leak files removed, .gitignore /build/ rule added→2 build/debug leak files removed via git rm --cached (no .gitignore edit — iteration 3 correction...). (e) §09.2 Modified bullet:.gitignore (if §03 decides...)removed; added explicit note that.gitignoreis NOT modified + a verification gategit diff BASELINE_COMMIT..HEAD --stat --diff-filter=M -- .gitignorereturns empty. -
[TPR-XX-002-codex][medium](iteration 4)plans/project-reorganization/section-09-verification.md:252— Recompute §09.2 category counts from the actual baseline diff. Evidence: §09.2 said it comparedBASELINE_COMMIT..HEAD, but its expected counts were based on pre-baseline or non-git-visible work. The Added bullet counted files that already exist at the baseline commit (4 test-all baseline artifacts, 9 section files, 2 plan index/overview). The Deleted bullet counted filesystem-only cleanup (scratchpad/, samples/) that would not appear in git diff because those paths are gitignored. Impact: The §09.2 expected-counts cross-check was mathematically wrong — executors could see a correct diff stat but compare it against non-git-visible estimates and conclude something was missing. Required plan update: Recalculate Added/Deleted/Renamed/Modified expectations relative toBASELINE_COMMIT..HEAD: exclude pre-baseline plan files and baseline artifacts, exclude untracked scratchpad and samples cleanup from Deleted, use the real trackedtools/ori-lsp/footprint, and keep.gitignoreout of Modified. Basis: fresh_verification. Confidence: high. Resolved: Fixed on 2026-04-11 iteration 4. Rewrote §09.2 “Expected category counts” with explicit “relative toBASELINE_COMMIT..HEAD(git-diff visible)” framing: Added = ~17 (dropped pre-baseline artifacts + section files + plan index/overview — they are committed AT baseline); Deleted = ~27 (git-tracked only — scratchpad + samples filesystem cleanup reported via §01 baseline snapshot comparison, NOT git diff); Modified = ~240+ WITHOUT.gitignore. Added an explicit verification gate:git diff BASELINE_COMMIT..HEAD --stat --diff-filter=M -- .gitignorereturns empty. -
[TPR-XX-003-codex][low](iteration 4)plans/project-reorganization/index.md:107,153+section-07-scratchpad-triage.md:62,169,561— Propagate the reconciled §07/§08 metadata into remaining navigation text. Evidence:index.md:107still said “scratchpad/ audit, 31 files, 14 migrate, 17 delete”;index.md:153still said “08.7 NEW invocation matrix (29 cells”; §07:62 still said “17+ files deleted”; §07:169 still said “All 31 files classified”; §07:561 still said “17 or 18 depending on modern-lang-repos decision”. Impact: The iteration 2 / iteration 3 scratchpad math propagation missed the index.md keyword clusters and multiple §07 checklist items. Required plan update: Updateindex.md§07 and §08 entries to 30/12/18 and 33-cell; rename §07.6 body “17 files” to “18 files”; remove “17+” / “17 or 18” wording. Basis: fresh_verification. Confidence: low. Resolved: Fixed on 2026-04-11 iteration 4. (a)index.md:107updated to “30 files, 12 migrate, 18 delete”. (b)index.md:153updated to “33 cells: 29 exercisable + 4 PATH SKIP”. (c) §07.N checklist “17+ files deleted” → “18 files deleted… reconciled math: 30 total − 12 migrations = 18 deletions”. (d) §07.1 “All 31 files classified” → “All 30 files classified, live count at §01.1 baseline”. (e) §07.6 “17 or 18 depending on modern-lang-repos decision” → “18 total, per reconciled math that includes07-modern-lang-repos.mdin the DELETE list”. -
[TPR-XX-004-codex][low](iteration 4)plans/project-reorganization/section-01-census.md:90— Document PIPESTATUS alternative is bash-only. Evidence: The primary §01.1 pipefail fix at lines 83-88 was correct. The documented alternative at lines 90-95 used${PIPESTATUS[0]}, which works in bash but is unset in zsh (zsh uses lowercase, 1-indexed${pipestatus[1]}). Presented as interchangeable with the portable pipefail form. Impact: A zsh user following the “alternative” would record an empty exit code and silently pass red baselines. Required plan update: Label the${PIPESTATUS[0]}snippet as bash-only or add a zsh alternative. Basis: fresh_verification. Confidence: low. Resolved: Fixed on 2026-04-11 iteration 4. Added explicit label “BASH ONLY — zsh users: use the pipefail form above instead” above the${PIPESTATUS[0]}snippet. Added prose explaining thatset -o pipefailis the portable default and is recommended; the PIPESTATUS alternative is only safe if the invoking shell is known to be bash. Added a comment inside the bash-only code block.
03.N Completion Checklist
-
build/debug/simplest_crash.llremoved from git tracking (03.1) -
build/debug/test_simpleremoved from git tracking (03.1) -
.gitignoreverified UNCHANGED (03.2) — no/build/rule added; the existing**/build/rule already covers root-levelbuild/per iteration 3’s empirical--no-indexverification -
git check-ignore -v --no-index build/debug/simplest_crash.llconfirms the existing**/build/rule at.gitignore:5already matches (03.2 — no new rule added per iteration 3 correction) - Negative rules for
compiler/oric/src/commands/build/verified intact (03.3) -
profile.json.gzstill tracked (NOT deleted by this section) -
./test-all.shgreen post-fix - Single atomic commit lands:
fix(plan): remove tracked build/debug leak(NO+ gitignore root anchor— iteration 3 correction) - Plan annotation cleanup: N/A (no
.rsfiles modified) - Plan sync — update plan metadata:
- This section’s frontmatter
status→complete -
00-overview.mdQuick Reference table for §03 →Complete -
00-overview.mdmission success criterion “Gitignore drift bug fixed” → checked -
00-overview.mdKnown Bugs table row forbuild/debug/*leak →Fixed -
index.mdupdated
- This section’s frontmatter
-
/tpr-reviewpassed — simple section; review should be brief -
/impl-hygiene-reviewpassed (AFTER TPR clean) -
/improve-toolingsection-close sweep — per-subsection retrospectives (03.1, 03.2, 03.3) should already be committed. Cross-subsection pattern check: is there a single reusablescripts/dev/gitignore-sanity.shhelper that combines the leak-finder (03.1), the pattern-pairing knowledge (03.2), and the negative-rule verifier (03.3)? If yes, consolidate the three per-subsection helpers (if any were built) into one and commit viabuild(scripts): consolidate gitignore-sanity.sh — surfaced by section-03 close sweep. If no cross-cutting value: document “Section-03 close sweep: per-subsection retrospectives covered everything; the three helpers are independent enough that consolidation is not warranted.” -
/sync-claudesection-close doc sync — verify Claude artifacts across all section commits. Map changed crates to rules files, check CLAUDE.md, canon.md. Fix drift NOW.
Exit Criteria: git ls-files build/ returns empty. git check-ignore -v --no-index build/debug/simplest_crash.ll matches .gitignore:5:**/build/ (the existing rule — no new rule needed). git ls-files compiler/oric/src/commands/build/ returns its tracked files (negative rule preserved). profile.json.gz still tracked. ./test-all.sh green. A single commit (fix(plan): remove tracked build/debug leak) contains exactly 2 file operations (both deletions; NO .gitignore edit per iteration 3 correction). Mission success criterion “Tracked build/debug artifacts removed” is satisfied.