coilyco-flight-deck/ward

Fork 0

advisor follow-up: read repo-local catalog.dependsOn at launch, not an embedded Atlas snapshot #566

New issue

Closed

opened 2026-07-03 10:08:55 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-03 10:08:55 +00:00

Owner

Follow-up to ward#565

ward#565 landed an Atlas-backed advisor auto-context path, but it is still not the right source of truth.

The actual first-class source already exists in each repo's own config YAML: the top-level catalog: block and its dependsOn key. The advisor should read those keys from the cloned repos at launch time, not from an embedded/snapshotted graph baked elsewhere.

Relevant existing doctrine in the tree:

agentic-os-kai/scripts/build-catalog-graph.py compiles the graph from each repo's catalog: block
agentic-os-kai/docs/FEATURES.md says the graph is compiled from .ward/ward.yaml (external repos) or .coily/coily.yaml (personal repos)
ward/docs/ward-yaml.md explicitly says catalog: is not read by ward today

That last point is the gap this issue closes.

Correct requirement

On advisor launch, after the primary repo clone exists, ward should inspect the repo's own config YAML and read the repo-local catalog.dependsOn declaration directly.

For external-facing repos, that means .ward/ward.yaml.
For personal repos, that means .coily/coily.yaml.

If the Eco repos declare a dependency on StrangeLoopGames/Eco there, the advisor should discover and clone that repo from the declaration itself. It should not depend on Kai owning the repo, and it should not require the dispatcher to pre-bake a special Eco map.

Problem with the current shape

An embedded Atlas graph is only a snapshot. It can drift from the repo-local truth and it adds an unnecessary indirection for advisor launch-time context collection.

The advisor needs the live declaration in the cloned repo.

Ask

Refactor the advisor auto-context collector so its primary input is the cloned repo's own catalog.dependsOn data, read at launch.

Atlas/the compiled graph can still exist for other consumers, but advisor launch-time context resolution should not depend on a precompiled snapshot when the canonical declaration is already present in the cloned repo.

Required behavior

For the primary repo, inspect repo-local config in this order:
- .ward/ward.yaml
- .coily/coily.yaml
Read the top-level catalog.dependsOn value from the first applicable config.
Treat those declared repos as auto-granted read-only advisor context repos.
Merge repo-local catalog.dependsOn repos with explicit --repo / --with-repo grants.
De-duplicate the final set.
Stay chatty about provenance: repo-local catalog vs explicit grant.
Preserve the longer TTL behavior for external/upstream repos.
Preserve fresh clones in-container. Never mount host working copies.

External repos

catalog.dependsOn must be able to point at repos that are not Kai-owned and not on the same forge, such as StrangeLoopGames/Eco on GitHub. Advisor launch should resolve and clone those as read-only context when declared.

Non-goals

do not require a hand-maintained ward-local special map for Eco
do not require a precompiled Atlas snapshot to be current
do not mount ~/projects

Done-condition

Advisor launch reads catalog.dependsOn directly from the cloned repo config.
Eco repos can declare StrangeLoopGames/Eco in their own config and advisor auto-context picks it up.
The final repo set remains de-duplicated, chatty, and read-only.
Any snapshot/Atlas path is secondary, not the primary runtime source.

coilyco-flight-deck/ward#564 - first landing of advisor auto-context repos
coilyco-flight-deck/ward#565 - follow-up that moved to Atlas-backed deps, but still not launch-time repo-local truth
coilyco-gaming/eco-ops#26 - triggering advisor use case

## Follow-up to ward#565 `ward#565` landed an Atlas-backed advisor auto-context path, but it is still **not the right source of truth**. The actual first-class source already exists in each repo's own config YAML: the top-level `catalog:` block and its `dependsOn` key. The advisor should read those keys **from the cloned repos at launch time**, not from an embedded/snapshotted graph baked elsewhere. Relevant existing doctrine in the tree: - `agentic-os-kai/scripts/build-catalog-graph.py` compiles the graph from each repo's `catalog:` block - `agentic-os-kai/docs/FEATURES.md` says the graph is compiled from `.ward/ward.yaml` (external repos) or `.coily/coily.yaml` (personal repos) - `ward/docs/ward-yaml.md` explicitly says `catalog:` is **not read by ward** today That last point is the gap this issue closes. ## Correct requirement On advisor launch, after the primary repo clone exists, ward should inspect the repo's own config YAML and read the repo-local `catalog.dependsOn` declaration directly. For external-facing repos, that means `.ward/ward.yaml`. For personal repos, that means `.coily/coily.yaml`. If the Eco repos declare a dependency on `StrangeLoopGames/Eco` there, the advisor should discover and clone that repo from the declaration itself. It should not depend on Kai owning the repo, and it should not require the dispatcher to pre-bake a special Eco map. ## Problem with the current shape An embedded Atlas graph is only a snapshot. It can drift from the repo-local truth and it adds an unnecessary indirection for advisor launch-time context collection. The advisor needs the **live declaration in the cloned repo**. ## Ask Refactor the advisor auto-context collector so its primary input is the cloned repo's own `catalog.dependsOn` data, read at launch. Atlas/the compiled graph can still exist for other consumers, but advisor launch-time context resolution should not depend on a precompiled snapshot when the canonical declaration is already present in the cloned repo. ## Required behavior - For the primary repo, inspect repo-local config in this order: - `.ward/ward.yaml` - `.coily/coily.yaml` - Read the top-level `catalog.dependsOn` value from the first applicable config. - Treat those declared repos as auto-granted read-only advisor context repos. - Merge repo-local `catalog.dependsOn` repos with explicit `--repo` / `--with-repo` grants. - De-duplicate the final set. - Stay chatty about provenance: repo-local catalog vs explicit grant. - Preserve the longer TTL behavior for external/upstream repos. - Preserve fresh clones in-container. Never mount host working copies. ## External repos `catalog.dependsOn` must be able to point at repos that are not Kai-owned and not on the same forge, such as `StrangeLoopGames/Eco` on GitHub. Advisor launch should resolve and clone those as read-only context when declared. ## Non-goals - do not require a hand-maintained ward-local special map for Eco - do not require a precompiled Atlas snapshot to be current - do not mount `~/projects` ## Done-condition - Advisor launch reads `catalog.dependsOn` directly from the cloned repo config. - Eco repos can declare `StrangeLoopGames/Eco` in their own config and advisor auto-context picks it up. - The final repo set remains de-duplicated, chatty, and read-only. - Any snapshot/Atlas path is secondary, not the primary runtime source. ## Related - `coilyco-flight-deck/ward#564` - first landing of advisor auto-context repos - `coilyco-flight-deck/ward#565` - follow-up that moved to Atlas-backed deps, but still not launch-time repo-local truth - `coilyco-gaming/eco-ops#26` - triggering advisor use case

coilyco-ops commented

2026-07-03 10:09:26 +00:00

Member

🔒 Reserved by ward agent --driver codex — container engineer-codex-ward-566 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-03T10:09:21Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

— Codex, via ward agent

🔒 Reserved by `ward agent --driver codex` — container `engineer-codex-ward-566` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-03T10:09:21Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).  — Codex, via `ward agent`

coilysiren referenced this issue from a commit

2026-07-03 10:13:46 +00:00

feat(advisor): read repo-local catalog deps at launch

coilysiren closed this issue

2026-07-03 10:13:46 +00:00

coilysiren commented

2026-07-03 10:14:00 +00:00

Author

Owner

WARD-OUTCOME: done - advisor launch now reads repo-local catalog.dependsOn at runtime
The change was straightforward once I traced the launch path into buildUpPlan. The only friction was the old Atlas-shape test expectations, which had to be reworked to prove the live config walk-up and the dedupe/provenance behavior. Confidence is high, and the only rough edge I would file next is a follow-up cleanup around naming the helper more explicitly for repo-local config, since it now does what the old Atlas loader used to pretend to do.

WARD-OUTCOME: done - advisor launch now reads repo-local catalog.dependsOn at runtime The change was straightforward once I traced the launch path into buildUpPlan. The only friction was the old Atlas-shape test expectations, which had to be reworked to prove the live config walk-up and the dedupe/provenance behavior. Confidence is high, and the only rough edge I would file next is a follow-up cleanup around naming the helper more explicitly for repo-local config, since it now does what the old Atlas loader used to pretend to do.

coilysiren referenced this issue

2026-07-03 17:34:49 +00:00

Expand catalog.dependsOn auto-context (read-only dep grants) from advisor-only to all warded roles #573

coilysiren referenced this issue from a commit

2026-07-03 18:40:46 +00:00

feat(agent): read-only catalog.dependsOn context for every warded role