repocfg: DiscoverChildren scans depth-1 only, misses grandchild configs from workspace root #62

Closed
opened 2026-06-04 06:26:08 +00:00 by coilysiren · 1 comment
Owner

Problem

repocfg.DiscoverAll scans direct children only (DiscoverChildren, repocfg/repocfg.go:122), depth-1. Kai's workspace is laid out two levels deep: grouping dir (coilyco-bridge/, coilyco-flight-deck/, coilysiren/) then repo. So from ~/projects every coily.yaml is a grandchild, the discovery pool is empty, and coily exec <verb> fails with repo_no_config:

coily: no .coily/coily.yaml reachable from cwd (/Users/kai/projects) via ancestor walk or direct-child scan

This contradicts the operating doctrine that repo verbs should self-discover their declarant from any cwd with no repo-scope flag.

Decision

Bump the child scan from depth-1 to depth-2 (chosen over workspace-root anchoring and a global verb index for smallest blast radius). Covers the grouping-dir/repo layout while staying cwd-relative and deterministic.

Change

  • DiscoverChildren (repocfg/repocfg.go:122): also descend one level into each child dir, checking <child>/<grandchild>/.coily/coily.yaml. Keep the .-prefix skip and the dedupe-by-path / sort-by-path invariants. Consider a DiscoverChildrenDepth(parentDir, depth int) so the depth is explicit and testable rather than hardcoded.
  • Update the DiscoverAll doc comment (repocfg/repocfg.go:159) to state the new depth.

Downstream

  • coily picks this up via a module bump in coily/go.mod (forgejo.coilysiren.me/coilyco-flight-deck/cli-guard).
  • Update coily's exec help/error text in cmd/coily/ops_repo.go (lines ~73-83, 126-133) which still say "direct child of cwd".
  • Watch for new name collisions: a larger pool means more verbs declared by 2+ repos, which fall through to the numeric-pick prompt. Acceptable, but note in the PR.

Tests

  • DiscoverChildren finds a grandchild config and ignores depth-3+.
  • TestLoadRepoExecCommand_DiscoversChildren (coily/cmd/coily/ops_repo_test.go:361) extended for the grouping-dir case.
## Problem `repocfg.DiscoverAll` scans **direct children only** (`DiscoverChildren`, `repocfg/repocfg.go:122`), depth-1. Kai's workspace is laid out two levels deep: grouping dir (`coilyco-bridge/`, `coilyco-flight-deck/`, `coilysiren/`) then repo. So from `~/projects` every `coily.yaml` is a *grandchild*, the discovery pool is empty, and `coily exec <verb>` fails with `repo_no_config`: ``` coily: no .coily/coily.yaml reachable from cwd (/Users/kai/projects) via ancestor walk or direct-child scan ``` This contradicts the operating doctrine that repo verbs should self-discover their declarant from any cwd with no repo-scope flag. ## Decision Bump the child scan from depth-1 to depth-2 (chosen over workspace-root anchoring and a global verb index for smallest blast radius). Covers the grouping-dir/repo layout while staying cwd-relative and deterministic. ## Change - `DiscoverChildren` (`repocfg/repocfg.go:122`): also descend one level into each child dir, checking `<child>/<grandchild>/.coily/coily.yaml`. Keep the `.`-prefix skip and the dedupe-by-path / sort-by-path invariants. Consider a `DiscoverChildrenDepth(parentDir, depth int)` so the depth is explicit and testable rather than hardcoded. - Update the `DiscoverAll` doc comment (`repocfg/repocfg.go:159`) to state the new depth. ## Downstream - coily picks this up via a module bump in `coily/go.mod` (`forgejo.coilysiren.me/coilyco-flight-deck/cli-guard`). - Update coily's `exec` help/error text in `cmd/coily/ops_repo.go` (lines ~73-83, 126-133) which still say "direct child of cwd". - Watch for new name collisions: a larger pool means more verbs declared by 2+ repos, which fall through to the numeric-pick prompt. Acceptable, but note in the PR. ## Tests - `DiscoverChildren` finds a grandchild config and ignores depth-3+. - `TestLoadRepoExecCommand_DiscoversChildren` (`coily/cmd/coily/ops_repo_test.go:361`) extended for the grouping-dir case.
Author
Owner

do this, but ward version

do this, but `ward` version
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/cli-guard#62
No description provided.