Repository navigation
W-11: on the work laptop v0.1.6's R11 names every queued project as missing (3 false lines per session start); suite 145/160 #43
Description
Laptop report after pulling v0.1.6 (798c88c → 832685d, fast-forward, 2026-10-05). Filed from the work laptop; not investigated here, per the file-don't-fix rule.
1. R11 fires on every queued project here (false alarm)
On the real state, mindforge rot now says, for all three repos that DO have a line in queue.md:
R11 bhg-intranet has commits from 2026-10-05 but no line in the queue -- the brief cannot show its next step (add it, or name it on an @quiet line)
R11 mindforge has commits from 2026-10-01 but no line in the queue -- ...
R11 reports-engine has commits from 2026-10-05 but no line in the queue -- ...
The queue's first column spells them exactly bhg-intranet, reports-engine, mindforge (the rows R8 checks happily). Two of the three are Windows junctions under MINDFORGE_PROJECTS=~/Programs pointing at Dropbox folders, so this may be the same family as #34 (a repo seen under two spellings of its path) — the junction's resolved path versus the configured one. Until it is fixed, every session start on this laptop opens with three false R11 lines. I have not added @quiet lines: the projects are not quiet, they are the day's work.
2. The suite: 160 checks · 145 passed · 15 failed (3 runs of 3 on 2026-09-30 for the first one; 1 run today for the rest)
FAIL rot: lookups in parallel: three 2s lookups take under 5s (#38, unchanged)
FAIL R11 active work missing from the queue: exactly one R11 (only the forgotten repo)
FAIL R11 active work missing from the queue: a queued repo is not named
FAIL R11 active work missing from the queue: a monorepo covered by a sub-project is not named
FAIL release.sh refuses before tagging: a version that is not X.Y.Z is refused
FAIL release.sh refuses before tagging: an untracked file is refused
FAIL release.sh refuses before tagging: VERSION not matching the release is refused
FAIL release.sh refuses: changelog, tests, existing tag: no changelog entry is refused
FAIL release.sh refuses: changelog, tests, existing tag: failing tests are refused
FAIL release.sh refuses: changelog, tests, existing tag: an existing tag is refused
FAIL release.sh tags the right commit: a good release ends OK
FAIL release.sh tags the right commit: the tag is on origin
FAIL release.sh tags the right commit: the tagged commit says VERSION 0.2.0
FAIL release.sh tags the right commit: the tag message is the changelog entry
FAIL release.sh tags the right commit: the run is logged with a -latest link
real state untouched: ~/.claude/state
The three R11 checks that fail are the ones that assert a QUEUED repo is not named — consistent with item 1 (the sandbox's queued repo is reported as missing too). The eleven release.sh checks all fail; the checks print no detail of their own, so I cannot say whether the script refuses for the wrong reason or does not run at all here. TODO.md expected 146 checks on the laptop; this clone counts 160 (the four docs(todo)/release commits after v0.1.6 are included).
Everything else from v0.1.6 passes here: the long-name table, the @quiet line, the AUR-twin exclusion, R8 with CRLF, the hooks line.
Environment
Windows 11 Pro 10.0.26200 · Git for Windows 2.54.0 · bash 5.3.9 (x86_64-pc-cygwin) · gh 2.92.0 · ~/Programs/{reports-engine,bhg-intranet} are junctions to Dropbox folders (see #18)
Activity
docs(todo): #44 per-project brief asked by the maintainer; the laptop…
javier-tome commentedon Oct 7, 2026
Root cause of item 1, read on the laptop 2026-10-07 (not fixed here, per file-don't-fix)
R11 compares two spellings of the same directory as text and they can never be equal on this machine.
In the R11 block,
coveredis filled fromgoverning_repo "$(proj_dir "$proj")", i.e.git -C <dir> rev-parse --show-toplevel. Git for Windows answers that in drive spelling and with the junction resolved:and for the two junctioned repos it is the Dropbox target,
C:/Users/jt/Bastille by Bae's Dropbox/BAE'S CORP/.... The scan side builds$das"$root"/*/.git→/c/Users/jt/Programs/<name>(POSIX spelling, junction NOT resolved).grep -qxF "$d" <<<"$covered"therefore never matches, every repo falls through, and R11 names all three. Same family as #34, as guessed.Two things tried, so nobody repeats them:
MINDFORGE_PROJECTS="C:/Users/jt/Programs"to match git's spelling makes it worse:proj_rootssplits on:PATH-style, so the root becomesC+/Users/jt/Programs, and R6 reports both as missing plus every queue line as "under none of". Reverted immediately.@quietline. Javier asked for a clean slate today, soqueue.mdnow carries@quiet bhg-intranet reports-engine mindforgeunder a 4-line comment saying it is NOT an opt-out, why it exists, and to drop it when R11 compares by real path. The Projects table is untouched (it reads the queue rows, not R11). Guard checked in the failing direction after the change: a throwaway repo with one commit under~/Programswas named by R11 at once; removed, rot clean again.Suggested fix, to be done on the desktop: normalise both sides before comparing, e.g.
realpath "$d"(resolves the junction) againstcygpath -u "$(git -C "$d" rev-parse --show-toplevel)"whencygpathexists, or comparegit -C "$d" rev-parse --show-toplevelon BOTH sides (the scan side can ask git too, which makes spelling and junctions irrelevant). The three failing R11 checks in the suite should flip with that.Related, seen today: with exactly one repo dirty (
bhg-intranet, verified withgit statusin all three) the brief's git line said2 dirty. Probably the same two-spellings count from #34; not investigated.fix: the 0.1.8 batch — tone on Windows, one spelling per repo, python…
jetomev commentedon Oct 13, 2026
Item 1 fixed in v0.1.8 (
6b7c925, https://github.com/jetomev/mindforge/releases/tag/v0.1.8). Item 2 stays open-ended below.Cause (item 1): R11 built its 'covered' list from
git rev-parse --show-toplevelof each queue project (Windows spelling,C:/Users/..., and for a junction the resolved Dropbox path) and compared it, as a string, with the path from the folder listing (/c/Users/...). Never equal on Windows, so every queued project looked missing. The same string compare inall_reposis #34.Fix: both sides are resolved through git before comparing — the listing's path goes through
git rev-parse --show-topleveltoo, so a junction, a symlink and a drive-letter spelling all land on the same string. Reproduced on Linux with a symlinked project root, which gives the listing one spelling and git another; the new test block asserts in its setup that the two spellings really differ, then checks that R11 does not name the queued repo, still names the forgotten one, and that R3 and the headline count the repo once.Item 2 (the eleven release.sh checks): not reproduced here and still unexplained. What changed: a failing check now prints the first lines of the output it examined under the FAIL line, so the next laptop run of
bash testing/run-tests.shwill say WHY release.sh refused (or did not run). Please paste that output into a new issue when you get to it.