ADR-005: Centralize All Registry Configuration Under `config/`

Status

Accepted

Context

Phase 1 v1 placed skills/registry.yaml and tools/registry.yaml inside their respective source packages (backend/src/skills/, backend/src/tools/), while routing configuration already correctly lived under top-level config/routing/. This inconsistency was flagged in review: it contradicts the project's own stated principle of configuration-driven architecture and creates two different conventions for what is conceptually the same kind of artifact (a registry mapping names to implementations/config).

Decision

Move all registry configuration to a single top-level hierarchy:

config/
├── routing/
│   ├── skills_routing.yaml
│   └── thresholds.yaml
├── skills/
│   └── registry.yaml
└── tools/
    └── registry.yaml

backend/src/skills/ and backend/src/tools/ retain only code: base contracts, concrete Skill/Tool classes, and the loader logic that reads the corresponding config/ file. backend/src/config/settings.py gains explicit path settings (SKILLS_REGISTRY_PATH, TOOLS_REGISTRY_PATH) alongside the existing routing config paths.

Alternatives Considered

A. Leave registries in src/, only routing config in config/ (status quo) Rejected: this is the exact inconsistency the review flagged — no principled reason exists for routing config to be external while functionally identical Skill/Tool registries are not.

B. Put everything, including secrets, in config/ Rejected: secrets (API keys, credentials) correctly remain in .env/settings.py, never committed as YAML. config/ is for non-secret, structural/behavioral configuration only — this ADR does not change that boundary.

C. A single monolithic config/app.yaml for routing + skills + tools Rejected: the three concerns (routing rules, skill registry, tool registry) have different owners conceptually and change independently; keeping them in separate files under a shared top-level directory preserves clarity without forcing a shared schema across unrelated concerns.

Consequences

Positive:

One consistent place (config/) for every non-secret behavioral configuration artifact — matches the architecture documentation's own descriptions exactly, reducing "the docs say one thing, the repo does another" drift.
Environment-specific overrides (e.g. disabling a Skill in staging, pointing at a different Tool provider) become a config/ concern, deployable independently of a code build.
No schema or interface changes — this is a pure file relocation plus two settings-path updates.

Negative / accepted tradeoffs:

Minor migration cost (two file moves, two path constants) — accepted as low-risk since, as of this revision, Phase 1 has not yet been implemented in code, so there is no runtime data migration, only a documentation update ahead of implementation.

Interview Talking Point

Consistency of convention matters as much as the convention itself — having one correct pattern (routing config external) sitting next to a different, incorrect pattern (skills/tools config internal) is worse for maintainability than either extreme applied uniformly. This ADR is really about closing that gap before it gets implemented and copied forward.

ADR-005: Centralize All Registry Configuration Under config/