[opticon454]

Problem

Add Case → Create New → custom folder refuses any folder below the cases directory with "That folder is inside the cases folder; create a case there with plain Create New". The stated reason is that such a folder is already listed as a local case, but GET /api/cases lists only the direct children of the cases directory. A deeper folder is not listed, so linking it cannot register it twice.

It matters when CODEMAN_CASES_PATH is a broad root. With /mnt/user/Scripts, a new case at /mnt/user/Scripts/GitHub/me/new-project was refused, although existing linked cases already live at that depth.

Change

blockedReason() (src/web/case-path.ts) now refuses the cases directory itself and its direct children only. The message names the cases directory. The resolved-path (symlink) check is unchanged, because it goes through the same function.

Tests

test/case-path.test.ts: direct children and the cases directory itself are still refused (message names the folder); a folder two or more levels down, under a broad cases root, is allowed. tsc --noEmit clean. test/routes/case-custom-path-routes.test.ts only uses direct children, so it is unaffected (it refuses to run outside npm test).

[Ark0N]

Thanks @opticon454, and sorry this one sat for so long without a word. It is a clean fix: Create New with a custom folder now refuses only the cases folder itself and its direct children, so a broad CODEMAN_CASES_PATH such as /mnt/user/Scripts no longer blocks the whole tree below it. The reasoning holds: GET /api/cases reads one level, so only those folders can show up twice. I also ran it against a real filesystem: a nested folder is accepted, while a direct child, the cases folder itself, a CODEMAN_CASES_PATH with a trailing slash and a symlink pointing into the cases folder are all still refused through the resolved-path pass. Your new tests fail on master and pass here, which is exactly what I want to see.

A few small things, mostly docs:

1. docs/api-reference.md:779 still documents the old rule ("must not be, or be inside, the cases directory"). It should say the cases directory itself and its direct children are refused, and a folder further down is allowed.
2. src/web/case-path.ts:15: the @fileoverview bullet still says "must not be, or be inside, a cases directory", which now contradicts the comment you added below. Same update there.
3. src/web/case-path.ts:107 (wording): for the cases folder itself the message reads "That folder is in the cases folder (...), where it is already listed as a case", and for a direct child that does not exist yet "already listed" is not true either. A separate message for absPath === dir, and "is listed" instead of "is already listed" for a direct child, would read better.
4. test/routes/case-custom-path-routes.test.ts: a route test next to the existing refusal test, where POST /api/cases with a path two levels under the cases directory returns 200 and lands in the linked-cases registry, would pin the user-facing fix end to end.

These are small, so I will apply them on top at merge time; no need to push again unless you would like to do them yourself. Thanks again for the clear write-up, here and in #637.

[Ark0N]

Merged and shipped in 1.43.0. Thanks @opticon454, and sorry again for the long wait on this one.

As promised, the merge-time commits on top: docs/api-reference.md and the case-path.ts @fileoverview now state the new rule, the refusal message is split (the cases folder itself vs a direct child), and a route test creates a case two levels under the cases directory end to end. #637 is closed with it.