[kittimzhe]

Refs #1273 (Phase 1 — the skills half; the hooks half needs the plugin-route design)

What

WorkBuddy 5.7+ moved its runtime to .workbuddy-ai/ and stops reading .workbuddy/, so on a 5.7+ member teamai reported the tool as not installed and delivered skills into a directory the app never scans — while every doctor self-check stayed green.

Two changes:

• Install probe accepts either root: .workbuddy (≤5.6) or .workbuddy-ai (5.7+) counts as installed, so a 5.7+ member is visible again.
• Skills delivery swaps to the new root when only .workbuddy-ai/ exists at the delivery base (HOME in user scope, project root in project scope): the default .workbuddy/skills becomes .workbuddy-ai/skills. Only the default swaps — a team that redirected skills on purpose keeps its own path. Other surfaces keep their configured paths; writes into the dead old layout are no-ops the app ignores.

Verification

Real-CLI record (workspace scope, only .workbuddy-ai/ at the project root): pull --force reports Synced 2 skills (2 new) — fixture-skill, teamai — and both land in .workbuddy-ai/skills/; no .workbuddy/ directory is created. This mirrors @XiaoWanWH's live 5.7.6 result in the issue (13 team skills visible in the app's / menu after the same redirect).

Nine red-first unit tests across both halves: old-root/new-root/both probe states, a bare .codebuddy not counting, the swap firing only for the default path, not stomping team redirects, and project-root resolution.

The hooks half (not here)

Context injection needs a plugin-route hooks writer (per the issue's evidence: no user-level hooks.json is read on 5.7.6, only plugin-carried ones) — that design depends on the plugin mechanism and the event vocabulary captured in the issue, and I'll bring it as a follow-up once the direction is agreed.

[github-actions]

• [P1 blocking] An upgraded installation retaining the old root still receives skills in the unread directory — src/types.ts:2751. When WorkBuddy 5.7+ has both .workbuddy-ai/ and a leftover .workbuddy/, the old-root check prevents the swap. Default skills continue landing in .workbuddy/skills, which the new runtime ignores. Prefer the new root when it exists.

• [P1 blocking] User-scope overrides can undo the generation swap — src/types.ts:2761. For a team entry with userScope.skills: '.workbuddy/skills', the helper adjusts the top-level path, but the subsequent user-scope merge restores the old path. With only ~/.workbuddy-ai/ present, user-scope delivery still targets the unread directory. Adjust the effective skills path after scope overrides.

The PR description provides a representative real-CLI verification record; no missing-testing finding applies.

Review limitation: The requested three-dot diff cannot resolve in this shallow checkout, and remote access failed. These findings come from the two WorkBuddy commits ending at the specified head; I cannot certify the complete requested diff. No PR code was run, built, or installed.

[SaulMoro]

This was generated by AI during triage.

@kittimzhe Thanks. The branch at da90ceef conflicts with main in src/doctor.ts, src/resources/base.ts and src/types.ts, mostly because of the locate work from #1221. That resolution touches the same delivery and install-probe code this PR changes, so we'll review the rebased head rather than this one. Please rebase onto current main and rerun the real-CLI record on the result.

[SaulMoro]

Adding to the review above, after the rebase:

• The first P1 from the bot review (both roots present) is the reporter's own machine: the issue says ~/.workbuddy/ is still there with logs, settings.json and skills. So as written this PR does not fix the reported install.
• The same check may also flip back on a clean 5.7 install. The probe now says WorkBuddy is installed, so if any surface still pointed at .workbuddy/ (user rules, agents, MCP) creates ~/.workbuddy/ on the first pull, the swap stops from the second pull on. I have not run that case. A user-scope record with a team that has rules would show it.
• [P2 non-blocking] Fixes #1273 closes the issue at merge, while context injection on 5.7.6 still has no surface. Refs #1273 keeps it open for the hooks work.

[kittimzhe]

Both P1s taken, pushed:

• Leftover old root: the swap no longer requires the old root to be absent — the new root wins whenever it exists, matching the upgraded-install shape from the issue (both roots present, the app reading only .workbuddy-ai). Real-CLI record, dual-root project root: pull --force delivers fixture-skill, teamai into .workbuddy-ai/skills/ and writes nothing into .workbuddy/skills.
• userScope undo: the swap is now re-applied after the user-scope merge (idempotent), so a userScope.skills carrying the default path no longer restores the unread directory; a userScope redirect of its own is still never stomped (covered by a guard test).

Red-first: three new/changed tests — dual-root preference, swap surviving the default userScope merge, custom userScope redirect untouched.

[github-actions]

No new confident findings in the available WorkBuddy changes.

• Resolved: New-root detection now prefers .workbuddy-ai even when .workbuddy remains.
• Resolved: The generation swap runs again after user-scope overrides, preserving the corrected default skills path without overwriting custom redirects.
• Testing: The PR description includes a representative real-CLI verification record; no missing-testing finding applies.

Review limitation: The requested three-dot diff fails with no merge base in this shallow checkout. I reviewed the three available WorkBuddy commits through c388d93; I cannot certify the complete requested diff. No PR code was run, built, or installed.

[SaulMoro]

This was generated by AI during triage.

@kittimzhe Thanks, the two fixes in c388d93f cover what my review raised: the new root now wins when both exist, and the swap survives the user-scope merge. Refs #1273 is right too.

Two things before we review it again:

• Rebase. The branch still conflicts with main in src/types.ts, src/resources/base.ts, src/doctor.ts, src/doctor-delivery.ts and the dropped-keys test. Part of the cause is 515a18b3: it is an earlier version of the docs/diagnostics: a named toolPaths entry replaces that tool's defaults whole, and nothing surfaces the dropped keys #1115 change that is already on main as 0d57ac46 (feat(doctor): surface toolPaths keys a team entry drops (#1115) #1274). Dropping that commit should make the rebase smaller.
• Body. The description still says the swap fires "when only .workbuddy-ai/ exists", and the real-CLI record is the single-root one. Please update both to match the new rule, using the dual-root record from your comment, run on the rebased head.

[SaulMoro]

This was generated by AI during triage.

@kittimzhe Thanks for the update. c388d93f still conflicts with main, now in src/doctor.ts, src/doctor-delivery.ts, src/resources/base.ts, src/types.ts and src/__tests__/doctor-toolpaths-dropped-keys.test.ts. Main caused it: the locate work in #1221, the toolPaths doctor check in #1274 (0d57ac46) and #1234 (2401d047) changed those files after this branch's base d60e68f5. The earlier request stands until there is a rebased head. Please rebase onto current main and rerun the real-CLI record on the result.

[github-actions]

• [P1 blocking] Custom skills paths prevent new-root install detection — src/locate.ts:177. With only .workbuddy-ai/ present and skills: 'custom/skills', the path condition leaves newGenerationRoot null, so the install gate probes the absent .workbuddy/. writableDir() consequently returns null, skipping delivery despite WorkBuddy being installed. Detect the generation independently of the skills path; restrict only the path swap to defaults. The custom-path test checks writesOf(), which ignores gates.

Resolved: Both earlier findings are fixed: the new root wins when both remain, and the swap runs after user-scope overrides.

Testing: The description documents a representative real-CLI verification; no missing-testing finding applies.

Limitation: The requested three-dot diff fails with no merge base in this shallow checkout. I reviewed the four available WorkBuddy commits through 49ac887; I cannot certify the complete requested diff. No PR code was run, built, or installed.

[kittimzhe]

Rebased onto current main (99fd56c) — twice in one sitting, since #1265 (the wider locate migration: rules/blocks/agents/MCP) landed right after the first rebase. The generation swap is now re-homed inside that architecture: the write side lives in locateSkills beside the other skills special cases, the install proof in installedGateOf's own-root case (shared by every resource), and NEW_GENERATION_INSTALL_ROOTS moved to tools.ts beside the tool registry, where base.ts's probe shares it. The old doctor commit (515a18b) is not carried: it is already in main via #1274.

Real-CLI record rerun on the rebased head (same fixture: workspace scope, only .workbuddy-ai/ at the project root): pull --force reports Synced 2 skills (2 new) — fixture-skill, teamai — both land in .workbuddy-ai/skills/, and no .workbuddy/ directory is created. Also added seven locate-level tests against the in-memory Host (mirroring locate-matrix's style): new root alone, both roots (new wins, #1290), old root alone, neither (gate closed), team redirect keeps its path, and both spellings of the default under user scope.

Full suite on the rebased head matches main's baseline here — the four git-discovery/submodule-checkout/workflow-workspace failures reproduce on pristine main in this environment, so they are pre-existing rather than from this branch.

[github-actions]

• [P2 non-blocking] Generation detection bypasses the supplied host — src/types.ts:2910. scopedToolPaths() now probes the process HOME with fs.existsSync(), even when locate() supplies a different Host. If the process HOME contains .workbuddy-ai but the supplied host has only .workbuddy, user-scope resolution selects <host.home>/.workbuddy-ai/skills while the old-root install gate passes. Keep generation detection host-backed so another machine’s filesystem cannot change the resolved destination.

Resolved: All three earlier findings are fixed: the new root wins when both exist, default user-scope overrides retain the swap, and install detection no longer depends on the skills path.

Testing: The description includes a representative real-CLI verification record; no missing-testing finding applies.

Reviewed the complete requested three-dot diff successfully. No PR code was run, built, or installed.