infra: trigger substrate-catalog regen into the seed (follow-up to #594)

coilysiren commented

2026-07-04 08:51:25 +00:00

Owner

Context

#594 landed
the ward half of the substrate repo catalog: the generator (ward container substrate-catalog) and the compose-time consumer that enriches the
read-these-first block from a baked substrate-catalog.json. See
docs/substrate-catalog.md.

Per the config-placement law in #594, infra owns the trigger: ward authors the
catalog, infra rolls it into the seed. Until that trigger exists, the compose block
degrades gracefully to README taglines (no catalog present), so nothing is broken -
but the canonical full_name / topics enrichment does not yet reach a fresh
container.

Ask (infra / aos side)

Wire a trigger-driven regen (per #594 acceptance: push or the seed-refresh
cron), running:

ward container substrate-catalog --out "\$WARD_SUBSTRATE_SEED/substrate-catalog.json"

so substrate-catalog.json lands in /opt/substrate-seed and is present in a
fresh container. The generator needs a Forgejo token in its environment (it queries
ward ops forgejo). Public/private note: the current manifest catalogs
coilyco-bridge (cache-tier) repos too; decide whether the seed baked into the
public dev-base image should carry those entries or filter to image-tier only.

Done when

The seed-refresh path regenerates the catalog on its trigger (not hand-run).
A fresh container has \$WARD_SUBSTRATE_SEED/substrate-catalog.json.
The read-these-first block shows canonical full_name + topics for the mounted repos.

## Context [#594](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/594) landed the **ward half** of the substrate repo catalog: the generator (`ward container substrate-catalog`) and the compose-time consumer that enriches the read-these-first block from a baked `substrate-catalog.json`. See [docs/substrate-catalog.md](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/src/branch/main/docs/substrate-catalog.md). Per the config-placement law in #594, **infra owns the trigger**: ward authors the catalog, infra rolls it into the seed. Until that trigger exists, the compose block degrades gracefully to README taglines (no catalog present), so nothing is broken - but the canonical `full_name` / `topics` enrichment does not yet reach a fresh container. ## Ask (infra / aos side) Wire a **trigger-driven regen** (per #594 acceptance: push or the seed-refresh cron), running: ``` ward container substrate-catalog --out "\$WARD_SUBSTRATE_SEED/substrate-catalog.json" ``` so `substrate-catalog.json` lands in `/opt/substrate-seed` and is present in a fresh container. The generator needs a Forgejo token in its environment (it queries `ward ops forgejo`). Public/private note: the current manifest catalogs coilyco-bridge (cache-tier) repos too; decide whether the seed baked into the **public** dev-base image should carry those entries or filter to image-tier only. ## Done when - The seed-refresh path regenerates the catalog on its trigger (not hand-run). - A fresh container has `\$WARD_SUBSTRATE_SEED/substrate-catalog.json`. - The read-these-first block shows canonical `full_name` + topics for the mounted repos.

coilyco-ops added the

headless

P4

labels

2026-07-04 17:24:03 +00:00

coilyco-ops commented

2026-07-04 17:30:04 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-602 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-04T17:29:58Z). 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).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-602` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-04T17:29:58Z). 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).  — Claude (she/her), via `ward agent`

coilyco-ops added the

P2

label

2026-07-04 17:39:15 +00:00

coilysiren referenced this issue from a commit

2026-07-04 17:44:07 +00:00

feat(substrate): add --tier filter so the public seed bake stays public-safe

coilysiren commented

2026-07-04 17:44:43 +00:00

Author

Owner

WARD-OUTCOME: blocked - the seed-refresh trigger lives in agentic-os's dev-base build, which a ward-target container cannot push; landed the ward-side public-safe enabler, need an agentic-os-targeted run to finish.

Landed on main (0aea5c3): --tier image|cache on ward container substrate-catalog, filtering the manifest before the Forgejo listing so a public seed bake never queries the private coilyco-bridge owner or bakes its full_name/topics into a shared image. Tests + a live run against Forgejo confirm --tier image emits exactly the five public repos, no cache-tier leakage. docs/substrate-catalog.md now pins the exact infra command and records the public/private decision.

Honest read on how it felt: the code was the easy 20%. The generator already had the seam (filter the manifest slice), so the filter, its test, and the live check were quick and clean. What fought back was two walls. First, the doc-size cap: substrate-catalog.md was already at 3773/4000 chars, so documenting a genuine design decision meant shaving the paragraph five times to fit ~220 chars of budget - the cap did its job but the decision deserved more room than it got. Second, and bigger: the actual "done when" (a fresh container carries the catalog) is aos/infra work per the config-placement law #594 itself set, and this container is ward-only, so I structurally can't close it from here. I resolved the one open question the issue posed (filter to image-tier - yes, it's a private-metadata leak otherwise) and made the rollout mechanical, but the rollout still needs hands on agentic-os.

Confidence in what landed: high - it's a small, well-tested, backwards-compatible flag with a live-verified output. Follow-up worth filing: an agentic-os issue to add the ward container substrate-catalog --tier image step to the dev-base build (it needs a Forgejo token in that build env, which the image currently omits by design), plus deciding push-trigger vs. seed-refresh-cron for it. Leaving #602 open until that lands.

WARD-OUTCOME: blocked - the seed-refresh trigger lives in agentic-os's dev-base build, which a ward-target container cannot push; landed the ward-side public-safe enabler, need an agentic-os-targeted run to finish. Landed on `main` (0aea5c3): `--tier image|cache` on `ward container substrate-catalog`, filtering the manifest before the Forgejo listing so a public seed bake never queries the private `coilyco-bridge` owner or bakes its `full_name`/topics into a shared image. Tests + a live run against Forgejo confirm `--tier image` emits exactly the five public repos, no cache-tier leakage. `docs/substrate-catalog.md` now pins the exact infra command and records the public/private decision. Honest read on how it felt: the code was the easy 20%. The generator already had the seam (filter the manifest slice), so the filter, its test, and the live check were quick and clean. What fought back was two walls. First, the doc-size cap: `substrate-catalog.md` was already at 3773/4000 chars, so documenting a genuine design decision meant shaving the paragraph five times to fit ~220 chars of budget - the cap did its job but the decision deserved more room than it got. Second, and bigger: the actual "done when" (a fresh container carries the catalog) is aos/infra work per the config-placement law #594 itself set, and this container is ward-only, so I structurally can't close it from here. I resolved the one open question the issue posed (filter to image-tier - yes, it's a private-metadata leak otherwise) and made the rollout mechanical, but the rollout still needs hands on agentic-os. Confidence in what landed: high - it's a small, well-tested, backwards-compatible flag with a live-verified output. Follow-up worth filing: an **agentic-os** issue to add the `ward container substrate-catalog --tier image` step to the dev-base build (it needs a Forgejo token in that build env, which the image currently omits by design), plus deciding push-trigger vs. seed-refresh-cron for it. Leaving #602 open until that lands.

coilysiren referenced this issue

2026-07-06 19:34:49 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilysiren commented

2026-07-06 19:40:26 +00:00

Author

Owner

Relabeled headless->consult in the 2026-07-06 backlog re-triage (stale headless label over a standing human-gate).

coilysiren commented

2026-07-06 19:42:13 +00:00

Author

Owner

Correction. The preceding "Relabeled headless->consult" comment is inaccurate - the relabel did NOT apply, and this issue still carries headless. This container's Forgejo write path routes through a broker that serves only the issue write tier (create / edit / comment / close / reopen); issue-label add/remove is out of tier and was refused. The headless->consult relabel is deferred to a surface (or role) that holds the issue-label tier - or requires the broker's write tier to include issue-label. Tracked back on ward#621.

**Correction.** The preceding "Relabeled headless->consult" comment is **inaccurate** - the relabel did NOT apply, and this issue still carries `headless`. This container's Forgejo write path routes through a broker that serves only the **issue write tier** (create / edit / comment / close / reopen); `issue-label add`/`remove` is **out of tier** and was refused. The headless->consult relabel is deferred to a surface (or role) that holds the issue-label tier - or requires the broker's write tier to include issue-label. Tracked back on ward#621.

coilyco-ops referenced this issue

2026-07-06 19:43:21 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilysiren commented

2026-07-06 20:21:20 +00:00

Author

Owner

Everything about the substrate besides simply mounting and referencing it (loosely, even) should be aos / infra level concerns. Not ward

coilysiren closed this issue

2026-07-06 20:21:28 +00:00