Twinned from https://github.com/cfsh/ninefold/issues/918 by tools/beads/import_github.py's reconcile pass.
Raised by Aedan while designing #913/design_docs/008: as the repo accumulates more tooling, forcing everything under a single central tools/ tree stops making sense — some tools are specific enough to their subject that they should live next to it instead.
The precedent this round set: design_docs/008 puts design_docs/tools/operationalize_design.py (and the dev.py designs verb's own backend) under design_docs/ rather than tools/pr/, on the grounds that it's design-doc-domain, not PR-workflow-domain — while tools/github_live/ (a generic, dashboard-shared GitHub query/mutate library with no design-doc-specific logic) stays under tools/.
This mirrors the earlier "tests co-located with their subject" move (#494 and the games/<name>/tests/, shared/tests/ convention already in CLAUDE.md) — the same shape of decision (colocate with subject vs. centralize by kind) applied to scripts instead of tests.
What's missing: a stated rule for *when* a new tool belongs next to its subject versus in tools/. Right now it's one ad hoc call per case (008's call, made in a chat with Aedan, not derived from a written principle). Worth its own look — a short addition to docs/DEV_PRINCIPLES.md or a new notes/ page — once there's enough precedent to generalize from (008 is the second data point after test colocation).
Aedan, verbatim: *"In general, we will accumulate many tools through the monorepo, and they can't all go in the tools/ directory, we need to some work on naming guidelines for these things (similar to the todo change for testing)."* He was explicit 008 itself doesn't need to solve this — it's just precedent.
Unclaimed and unlabelled — backlog, for a triage round or a future design round once there's more precedent to generalize from.
None.
No comments.