📬 Standing issue-triage log (auto-updated every other day)

[stuinfla]

This is the standing triage log for incoming issues, maintained automatically.

What happens here: every other day, an automated triage pass checks open issues on
stuinfla/Repo-Explainer and stuinfla/ruvnet-brain and posts a short digest below —
new arrivals, anything awaiting a maintainer response, and suggested next actions.
A quiet day still gets a one-line heartbeat so silence is never ambiguous.

House rule this log helps enforce: every issue gets engaged with quickly, and every
close comes with a personal, genuine thank-you to the person who took the time to file it.

(If you're a user landing here: your issues are read — file away.)

[stuinfla]

🔍 Triage digest — 2026-07-24

Repo-Explainer: 0 open issues (other than this log). All quiet.

ruvnet-brain: 2 open issues, both got automated bot replies but no personal maintainer reply yet — flagging both since the bot activity could make them look "handled" at a glance when they aren't.

repo	#	title	author	age	status
ruvnet-brain	#38	Windows: every Bash tool call errors twice — hook-shim.mjs hard-codes /bin/bash	tkmeownow	~17h	15(!) failed automated fixer attempts since filing; user's own tested patch sitting unapplied
ruvnet-brain	#39	Plugin writes empty ruvector.db into consumer project's cwd	rmcune	~13h	bot root-caused it (upstream ruvector native binary) and laid out 2 remediation options; needs a human product call

Suggested replies

#38 (tkmeownow): Thank you for not just reporting this but shipping a fully tested, ready-to-review patch — that's an exceptional contribution. Sorry the automated fixer spun on this for 16+ hours without landing it; I'm pulling your patch and reviewing it by hand instead of leaving it to the bot. The WSL bash.exe-exclusion reasoning alone would've cost me a confusing debugging session, so genuinely appreciate the depth here.

#39 (rmcune): Really appreciate you tracing this all the way into the ruvector native binary's default storage_path — that's well beyond what a bug report needs to include. I'm leaning toward the documentation/onboarding-warning fix for now rather than having ruvnet-brain silently rewrite every consuming project's .gitignore, and I'll also open this upstream against ruvector so the actual default gets fixed at the source. Will follow up here once decided.

---

Generated by Claude Code

[stuinfla]

📬 Triage digest — 2026-07-29

Repo-Explainer: 0 open issues (aside from this log).
ruvnet-brain: 4 open issues — 3 already have substantive maintainer engagement in-thread; 1 has only the automated ack so far.

Repo	#	Title	Author	Age	Status
ruvnet-brain	#64	Stable Spine auto-update is Claude-only — Codex reloads a stale plugin snapshot	sparkling	<1 day	Auto-ack only — needs a personal reply
ruvnet-brain	#54	Grounding query never returns an answer on a fresh WSL2 install	lafinak	1 day	Engaged — fix in PR #57, held open pending npm publish
ruvnet-brain	#52	Codex wiring stops at MCP — lifecycle hooks never installed	sparkling	2 days	Engaged — fixed on main, reopened over npm-vs-source distribution gap
ruvnet-brain	#48	verify-interface governs at an unstructured boundary	stuinfla	2 days	Engaged — self-filed, tracked as a 4.0 blocker

Needs a reply

#64 (sparkling) — only the automated ack has landed so far. The report is a well-evidenced follow-up to #52: it traces active.json's generation counter against the installed Codex plugin cache and shows Codex staying pinned to a stale snapshot after the Stable Spine advances, with a concrete root-cause list and a suggested host-sync.mjs extraction.

Suggested reply: "This is a sharp follow-up to #52 — the active.json-vs-installed-cache trace makes the Codex-only auto-update gap concrete rather than theoretical. I think the fix is the same host-sync.mjs extraction you sketch in part A (detectHost/syncStableEntrypoints/syncPluginSnapshot/verifyHost), reused by the installer and the updater so they can't drift apart again. Picking this up alongside #52's follow-through."

Nothing else needs action today — #54, #52, and #48 already have real substantive maintainer replies in-thread; no new unanswered user comments on any of them in the last 3 days.

---

Generated by Claude Code

[stuinfla]

📬 Triage digest — 2026-07-31

Repo	#	Title	Author	Age	Status
ruvnet-brain	#76	[bug] Codex whats-new skill loses its release-note asset after a supported install	sparkling	<1 day	🔴 unanswered

Repo-Explainer: 0 other open issues — all quiet there.

Suggested reply — ruvnet-brain #76

This is a genuinely excellent report — sparkling didn't just flag a symptom, they traced it back through #56, pinned the exact gap (installConsoleRuntime() copies the console/scripts payload but never docs/RELEASE-NOTES-4.0.md), and shipped acceptance criteria plus a concrete fix path. Worth a reply along these lines:

Thanks for the exceptionally thorough writeup — tracing this from #56's command-discovery fix through to the actual asset-resolution gap, and pinning exactly which copy step in installConsoleRuntime() misses the release notes, is really appreciated. Your persistent-runtime approach (mirroring how Console assets are already handled instead of inventing a new cache) looks like the right fix. I'll get this queued and will report back here once the installed-boundary regression test from your acceptance criteria is wired up.

---

Generated by Claude Code

[stuinfla]

📬 Issue Triage Digest — 2026-08-01

Repo-Explainer: 0 open issues (excluding this log). All quiet. ✅

ruvnet-brain: 3 open issues, all filed by sparkling within the last day, all still needing a real reply from you. Each has exactly one comment — an automated "🤖 paged" acknowledgment posted from your account — but no substantive human response yet. Worth a quick check that this auto-ack bot is something you set up intentionally, since it's posting under your own login and could make issues look handled when they aren't.

Repo	#	Title	Author	Age	Status
ruvnet-brain	78	[Codex] search_ruvnet disappears when tools/list waits on warmup past Codex startup timeout	sparkling	~2h	Bot-ack only
ruvnet-brain	77	[release regression] Keep the Brain bundle, Claude plugin, and Codex plugin in version lockstep	sparkling	~2h	Bot-ack only
ruvnet-brain	76	[bug] Codex whats-new skill loses its release-note asset after a supported install	sparkling	~1d	Bot-ack only

Suggested replies

#78 — Thanks for the incredibly thorough repro and root-cause trace here — the tools/list vs. warmup-timeout mismatch is spot on, and returning FALLBACK_TOOLS synchronously while deferring ensureChild() to the first tools/call is exactly the right fix. I'll get startup_timeout_sec written into the managed Codex block as defense-in-depth too, and wire the warmup failure into doctor/health per your acceptance criteria.

#77 — This is a genuinely great catch — nightly-wrapper.sh treating "tag changed" as proof of success instead of gating on transaction state is exactly the mechanism that let v4.0.3 ship half-published (npm stuck on 4.0.2). I agree self-update.mjs needs to hand off to release.mjs's canonical transaction rather than running its own gh release create/npm publish sequence; I'll scope the single-publisher refactor and the prepare/promote staging you outlined before cutting 4.0.4.

#76 — Good follow-up to #56 — makes sense that installConsoleRuntime() persists console//scripts/ but not docs/RELEASE-NOTES-4.0.md, so whats-new has nothing to read post-install with no checkout present. I'll extend that persistence step to copy the release notes into .console-runtime/docs/ and point the skill's resolution path there instead of guessing at a ~/Code checkout.

---

Automated triage — Claude

---

Generated by Claude Code

[stuinfla]

📬 Triage digest — 2026-08-03

Repo-Explainer: 0 open issues (excluding this log).
ruvnet-brain: 10 open issues — 9 already have a substantive maintainer reply as the latest comment. 1 needs attention.

Repo	#	Title	Author	Age	Status
ruvnet-brain	#99	distill-project.mjs hardcodes ~/.npm-global/bin/ruflo — fails on Homebrew/other-prefix installs	Tigon32	~hours old (filed today)	Only the automated ack so far — no substantive maintainer reply yet

Suggested reply — #99

Nice catch, and thanks for doing the archaeology on this one — you're right that distill-project.mjs just never got the resolveRuflo() fix that health-repair.mjs already carries (the one with the "find ruflo HONESTLY" comment). I'll port that function over and, since you counted ~10 scripts doing this independently, pull it out into a shared resolve-ruflo.mjs helper so this class of bug (same as #18) can't regress script-by-script again.

Everything else quiet: all 9 other open ruvnet-brain issues (#76–#87) currently end with a substantive owner comment as the most recent activity — no unanswered user follow-ups in the last 3 days.

---

Generated by Claude Code

[stuinfla]

✅ 2026-08-05: all quiet — 0 open issues on Repo-Explainer, 10 open on ruvnet-brain, all engaged.

---

Generated by Claude Code

[stuinfla]

📬 Triage digest — 2026-08-07

Repo	#	Title	Author	Age	Status
Repo-Explainer	#16	Preflight rejects the Claude Code subscription path (ANTHROPIC_API_KEY MISSING)	ciprianmelian	1 day	No maintainer response yet
ruvnet-brain	#77	[release regression] Keep Brain bundle/Claude plugin/Codex plugin in lockstep	sparkling (opener) / ObiWanKenobi (latest)	6 days, reopened	New comment today (09:38 UTC) unanswered

Suggested replies:

• Repo-Explainer Preflight rejects the Claude Code subscription path: --no-deploy run fails with "ANTHROPIC_API_KEY MISSING" despite "Brain ok — riding your Claude Code login" #16 — Thanks for tracking this down to the exact line — src/orchestrator.mjs:160 checks only ANTHROPIC_API_KEY/CLAUDE_API_KEY and never picked up the claudeCliAvailable() path that src/claude.mjs already exposes for the CLI-login flow, so it wrongly blocks users who intentionally skip the API key. Your diff looks like the right minimal fix — I'll pull it in and add a regression test for --no-deploy on a logged-in-CLI-only machine before cutting a release.

• ruvnet-brain #77 (ObiWanKenobi, latest comment) — This is an exceptional trace — you tied five separate signals (probe failures, the repo-count test, the ci→stranger-matrix→release-aggregate skip chain, and the stranded #114/#119/#104-108/#116) into one causal chain instead of five separate reports. Agreed the gates themselves are behaving correctly and the real break is the stale repo-count literals in README.md, SKILL.md, ruvnet-primer.md, and explainer/index.html racing ahead of the manifest's built/catalogued counts. I'd rather fix those literals (or land your exemption-list idea for the prose-only sites) than loosen the CI gate — will get a PR up to resync the six sites so main goes green and release-aggregate can resume and unstick the backed-up merges.

---

Generated by Claude Code

[stuinfla]

✅ 2026-08-09: all quiet — 0 open issues on Repo-Explainer, 0 open on ruvnet-brain, all engaged.

---

Generated by Claude Code

[stuinfla]

📬 Triage digest — 2026-08-11

Repo-Explainer: 0 open issues (besides this log).
ruvnet-brain: 1 open issue, 1 needs a real (non-automated) reply.

Repo	#	Title	Author	Age	Status
ruvnet-brain	#138	ground-ruvnet flywheel advisory conflates configured with operational and omits mandatory project anchor	sparkling	<1 day	Only the automated ack has landed — no personal/technical reply yet

Suggested reply — ruvnet-brain #138

This is an exceptionally well-documented report (live repro on two OSes, exact line refs, an acceptance-test matrix) and deserves more than the auto-ack it got. Suggested reply for Stuart to adapt:

Thanks for the thorough repro here, sparkling — the macOS/Linux side-by-side plus the exact harness-worker.ts/harness-project-anchor.ts line refs made this trivial to confirm. Agreed the settings.json substring grep can't stand in for the daemon-env + anchor checks Ruflo actually enforces post-#2840/#2848. I like the "configured vs. active" state split and the flywheel doctor --format json boundary idea best — planning to land the JSON-parse fix plus that intermediate "configured, runtime unverified" state first, then wire in the doctor contract once it exists on the Ruflo side. Will use your acceptance-test matrix as the base for the table-driven tests.

---

Generated by Claude Code

[stuinfla]

✅ 2026-08-13: all quiet — 0 open issues on Repo-Explainer, 1 open on ruvnet-brain, all engaged.

---

Generated by Claude Code

[stuinfla]

✅ 2026-08-15: all quiet — 0 open issues on Repo-Explainer, 1 open on ruvnet-brain, all engaged.

---

Generated by Claude Code

[stuinfla]

✅ 2026-08-17: all quiet — 0 open issues on Repo-Explainer, 1 open on ruvnet-brain (#138), all engaged.

---

Generated by Claude Code

[stuinfla]

Triage digest — 2026-08-19

Repo-Explainer: 0 open issues (besides this log). All quiet.

ruvnet-brain: 2 open issues. Both got the automated ack comment today, but neither has a substantive maintainer answer yet — flagging so they don't sit on the auto-ack.

Repo	#	Title	Author	Age	Status
ruvnet-brain	#141	Fixes merged to main but nothing published since 4.0.36 (11 days)	sparkling	few hrs	Auto-acked only, real questions unanswered
ruvnet-brain	#142	[Dream Cycle 2026-08-19] memory-durability: restore-local-ingests.mjs three-state fix	stuinfla (dream-cycle bot)	few hrs	Auto-acked; draft PR awaiting human review

Suggested replies

#141 (sparkling) — this one did real diagnostic work (npm view, gh compare, table of six issues closed-but-unpublished) and asked two direct, answerable questions. Worth a real reply, not just the ack:

Thanks for pulling the actual evidence here — the npm view/compare output makes this trivial to confirm and act on. Short version: the -dev channel going quiet on the 4.0 line wasn't a deliberate policy change, it looks like publishing got skipped while merges kept landing on main. I'll cut a release (or at minimum resume -dev builds) so #128/#129/#130/#133/#138/#140 actually reach installed hosts, and going forward I'll note on closed issues when a fix is merged-but-unreleased so a closure doesn't read as "available."

#142 (dream-cycle, self-filed) — not a user report, it's the nightly research agent's own hypothesis writeup with a linked draft PR waiting on human review. No "thank you for filing" needed here, just a merge/no-merge call:

Reviewed — the fresh-checkout vs. wipe conflation is real and the three-state classifier (OK/NEVER-MATERIALIZED/WIPED) is the right shape; tests were written against the old code first, which is what I want to see. Holding merge until the trailing npm run test:unit tail comes back clean, then I'll take it. The two out-of-scope findings (brain-score.mjs catalogue conflation, ADR-0063's dead hook-shim entry) are fine to leave for their own night.

---

Generated by Claude Code

[stuinfla]

✅ 2026-08-21: all quiet — 0 open issues on Repo-Explainer, 5 open on ruvnet-brain, all engaged (each has an OWNER response, no unanswered user comments).

---

Generated by Claude Code

[stuinfla]

✅ 2026-08-22: all quiet — 0 open issues on Repo-Explainer, 2 open on ruvnet-brain (both self-filed Dream Cycle research reports, already acknowledged), all engaged.

---

Generated by Claude Code