Summary
Comparing each repo's live GitHub top-level directory listing against what's actually indexed in the shipped v0.5.0-dev bundle turned up real, meaningful coverage gaps in 3 repos. Checked all 19 repos that haven't been rebuilt since the FULL_HINTS fix (#5); most show zero or only trivial gaps (asset/image dirs, deploy scripts). These 3 are real:
| Repo |
Missing top-level dirs |
ruflo |
docs/, plugins/, scripts/, verification/, data/ |
agentdb |
packages/, bench-data/, data/ |
ruvector |
harnesses/, external/ |
ruflo is the standout — 5 whole subsystems absent, including docs/ (confirmed a real 19KB file exists there, docs/metaharness-user-guide.md, present at the exact commit the bundle claims to be built from) and plugins/ (likely means other bundled-plugin READMEs, e.g. ruflo-metaharness, aren't indexed either).
Why this isn't a scoping decision
Checked two places this could be intentional and ruled both out:
forge-build.mjs's own markdown-ingestion logic (kb/forge-build.mjs lines ~182–196): walks every .md/.txt/.rst file found in the tree, gated only by SKIP_DIRS (node_modules, target, .git, dist, build, .next, .cache, coverage, .venv, venv, __pycache__, .vite, vendor, v2) — none of which include docs, plugins, scripts, verification, data, packages, bench-data, harnesses, or external. If this exact script ran fresh against a full clone today, it would index all of these.docs/adr/0007-tiered-scope.md: explicitly designates ruflo as one of three T0 "pillar" repos requiring "max depth" coverage — the deepest tier in the system. So the gap directly contradicts the repo's own stated design intent, not a documented trade-off.
Most likely explanation: the original crawl that produced the shipped bundle didn't walk the true repo root completely for these 3 (the original build command isn't recorded anywhere, per the same caveat noted in #4/#5).
Suggested fix
A full rebuild of ruflo, agentdb, and ruvector from a fresh full clone (not an incremental self-update.mjs run — since builtFromSha already matches live HEAD for all 3, the drift-check correctly reports them up-to-date and would never trigger a rebuild; the gap is in initial coverage, not staleness).
Related to #4 / #5.
Summary
Comparing each repo's live GitHub top-level directory listing against what's actually indexed in the shipped
v0.5.0-devbundle turned up real, meaningful coverage gaps in 3 repos. Checked all 19 repos that haven't been rebuilt since theFULL_HINTSfix (#5); most show zero or only trivial gaps (asset/image dirs, deploy scripts). These 3 are real:ruflodocs/,plugins/,scripts/,verification/,data/agentdbpackages/,bench-data/,data/ruvectorharnesses/,external/ruflois the standout — 5 whole subsystems absent, includingdocs/(confirmed a real 19KB file exists there,docs/metaharness-user-guide.md, present at the exact commit the bundle claims to be built from) andplugins/(likely means other bundled-plugin READMEs, e.g.ruflo-metaharness, aren't indexed either).Why this isn't a scoping decision
Checked two places this could be intentional and ruled both out:
forge-build.mjs's own markdown-ingestion logic (kb/forge-build.mjslines ~182–196): walks every.md/.txt/.rstfile found in the tree, gated only bySKIP_DIRS(node_modules,target,.git,dist,build,.next,.cache,coverage,.venv,venv,__pycache__,.vite,vendor,v2) — none of which includedocs,plugins,scripts,verification,data,packages,bench-data,harnesses, orexternal. If this exact script ran fresh against a full clone today, it would index all of these.docs/adr/0007-tiered-scope.md: explicitly designatesrufloas one of three T0 "pillar" repos requiring "max depth" coverage — the deepest tier in the system. So the gap directly contradicts the repo's own stated design intent, not a documented trade-off.Most likely explanation: the original crawl that produced the shipped bundle didn't walk the true repo root completely for these 3 (the original build command isn't recorded anywhere, per the same caveat noted in #4/#5).
Suggested fix
A full rebuild of
ruflo,agentdb, andruvectorfrom a fresh full clone (not an incrementalself-update.mjsrun — sincebuiltFromShaalready matches live HEAD for all 3, the drift-check correctly reports themup-to-dateand would never trigger a rebuild; the gap is in initial coverage, not staleness).Related to #4 / #5.