propose: walk-up config discovery and configurable source root

[HumanBean17]

What

Adds a proposal for walk-up config discovery and a source_root YAML field, plus an AGENTS.md instruction so brainstorming skills use the repo's proposal format.

Why now

Real users hit walls because the tool couples config location, source root, and cwd:

• User A runs init from a multi-system parent → mixed index
• User B cds to a microservice subdir → MCP can't find config
• User C puts config in a context dir, code elsewhere → must pass --source-root every time

Highlights

• discover_project_root() walks up from cwd to find .java-codebase-rag.yml (like git)
• New source_root field in YAML config — config can live separately from source code
• Index directory follows source root, not config location
• No breaking changes — existing workflows unchanged
• AGENTS.md now tells brainstorming skills to write proposals in repo format

Tests

Proposal-only; baseline unchanged.

Out of scope

• Implementation (follow-up PR after proposal approval)
• Multi-system auto-split
• Changes to init command behavior

🤖 Generated with Claude Code

[HumanBean17]

Review: DIRS-HIERARCHY proposal

The AGENTS.md edit is clean and well-placed. The proposal is well-structured and follows the repo format. The core design (walk-up + source_root field) is sound.

A few things to address before implementation:

---

1. User C scenario in §3.6 doesn't hold for walk-up

The directory layout is:

System-D/
  system-D-context/    ← config lives here
  microservice-D-1/    ← user works here
  microservice-D-2/

The proposal says: "Walk-up from any subdirectory finds the config." But walking up from microservice-D-1/ goes microservice-D-1/ → System-D/ → IdeaProjects/ — it never passes through system-D-context/, which is a sibling, not an ancestor.

Walk-up only helps User C if they run from system-D-context/ (or its subdirectories). The source_root: ../ field still solves their pain, but the wording should be corrected, e.g.:

Run init from system-D-context/. Then run MCP from system-D-context/ (or any subdirectory). Walk-up finds the config; source_root: ../ resolves to System-D/.

---

2. Missing detail: what about $HOME config?

§3.1 says walk-up stops before $HOME. Good safety measure, but if a user legitimately wants a project rooted at $HOME, there's no escape hatch. Probably fine for v1, but worth noting in §7 (Open Questions) or §8 (Out of scope) so it's tracked.

---

3. find_config_dir() mentioned but not in test plan

§3.4 introduces find_config_dir(source_root) as a new function, but §6 doesn't test it directly. An explicit unit test would help — it's the integration point between walk-up discovery and the precedence chain.

---

4. init warning — when exactly does it fire?

§3.5 says "soft warning if a parent config is detected" during init. Does the warning fire when the resolved source root has a parent config, or only when cwd does? A one-line clarification would prevent ambiguity during implementation.

---

Overall: ready to implement after addressing the User C walk-up description and the minor gaps above.