Mount the issue-corpus discovery index into warded containers via gitcache

coilysiren commented

2026-06-26 02:40:35 +00:00

Owner

Goal

Mount the issue-corpus discovery index (built in agentic-os#297) into warded
containers so the agent and Kai can grep -r the entire issue/inbox corpus
offline, in-container.

Why

A critical bit of information lived in coilysiren/inbox and was found only by
grepping two weeks of session logs from outside the container. The fix is offline
full-text grep over the issue corpus. agentic-os#297 renders that corpus to a
private git mirror repo. This issue wires that mirror into the container.

Inclusion mechanism: piggyback agent-compose (do NOT invent a new path)

The mount lever already exists. The mount-eligibility manifest
(~/.config/agent-compose/mount-eligibility.json) is generated by
agentic_os.generators.generate_agent_compose
(agentic_os/generators/generate_agent_compose.py:410-483) and is already
segmented per-harness: it emits harnesses: {claude: [...], codex: [...]}.
Inclusion = add the rendered corpus mirror to the agent-compose source that feeds
the agents cleared for private-repo access, and it flows through the existing
gitcache hydrate the same way /substrate/<name> does.

One correction to the obvious shorthand: we add the rendered corpus mirror
repo, not coilysiren/inbox directly. Inbox's issues are not in its git tree,
so mounting the raw inbox repo gives no greppable issues. The renderer's markdown
mirror is the artifact that gets mounted.

Gating: BLOCKED on per-driver permission segmentation (hard prerequisite)

The corpus contains coilysiren/inbox (private). It MUST NOT mount for any agent
until warded agent permissions are segmented by driver
(claude|codex|qwen|goose). Per-harness mount lists exist today, but the deeper
per-driver permission/trust boundary must land first so inbox content reaches
only the cleared driver tier. Do not ship this mount before that gate exists.

Refinement that makes the gate clean: agentic-os#297 should segment its output
into a public-tier corpus (the public substrate repos, greppable by any
agent) and a private corpus (inbox + private repos, gated). Then this mount
exposes the public corpus broadly and the private corpus only to the cleared
driver tier. (Captured as a note on agentic-os#297.)

Spec

Add the corpus mirror(s) to the agent-compose source / mount-eligibility set
(cache-tier, NOT the public image seed). Hydrate with creds like other private repos.
Mount read-only under a clear path (e.g. /substrate/issue-corpus or
/corpus), labelled a discovery index, never a work surface.
Discovery index discipline: grep to locate, confirm live state via
ward ops forgejo issue view. Surface that in the in-container doctrine.

Blocked on

agentic-os#297 - the renderer + private mirror repo must exist first (defines
the repo name/layout/segmentation this mount consumes).
The per-driver warded-agent permission segmentation issue (ward, number TBD -
Kai to confirm). No inbox mount lands before this.

Design consult and capture from a warded architect session.

## Goal Mount the **issue-corpus discovery index** (built in agentic-os#297) into warded containers so the agent and Kai can `grep -r` the entire issue/inbox corpus offline, in-container. ## Why A critical bit of information lived in `coilysiren/inbox` and was found only by grepping two weeks of session logs from outside the container. The fix is offline full-text grep over the issue corpus. agentic-os#297 renders that corpus to a **private git mirror repo**. This issue wires that mirror into the container. ## Inclusion mechanism: piggyback agent-compose (do NOT invent a new path) The mount lever already exists. The mount-eligibility manifest (`~/.config/agent-compose/mount-eligibility.json`) is generated by `agentic_os.generators.generate_agent_compose` (`agentic_os/generators/generate_agent_compose.py:410-483`) and is **already segmented per-harness**: it emits `harnesses: {claude: [...], codex: [...]}`. Inclusion = add the rendered corpus mirror to the agent-compose source that feeds the agents cleared for private-repo access, and it flows through the existing gitcache hydrate the same way `/substrate/<name>` does. One correction to the obvious shorthand: we add the **rendered corpus mirror repo**, not `coilysiren/inbox` directly. Inbox's issues are not in its git tree, so mounting the raw inbox repo gives no greppable issues. The renderer's markdown mirror is the artifact that gets mounted. ## Gating: BLOCKED on per-driver permission segmentation (hard prerequisite) The corpus contains `coilysiren/inbox` (private). It MUST NOT mount for any agent until warded agent permissions are segmented **by driver** (claude|codex|qwen|goose). Per-harness mount *lists* exist today, but the deeper per-driver permission/trust boundary must land first so inbox content reaches only the cleared driver tier. Do not ship this mount before that gate exists. Refinement that makes the gate clean: agentic-os#297 should segment its output into a **public-tier corpus** (the public substrate repos, greppable by any agent) and a **private corpus** (inbox + private repos, gated). Then this mount exposes the public corpus broadly and the private corpus only to the cleared driver tier. (Captured as a note on agentic-os#297.) ## Spec - Add the corpus mirror(s) to the agent-compose source / mount-eligibility set (cache-tier, NOT the public image seed). Hydrate with creds like other private repos. - Mount **read-only** under a clear path (e.g. `/substrate/issue-corpus` or `/corpus`), labelled a discovery index, never a work surface. - Discovery index discipline: grep to locate, confirm live state via `ward ops forgejo issue view`. Surface that in the in-container doctrine. ## Blocked on - agentic-os#297 - the renderer + private mirror repo must exist first (defines the repo name/layout/segmentation this mount consumes). - The per-driver warded-agent permission segmentation issue (ward, number TBD - Kai to confirm). No inbox mount lands before this. Design consult and capture from a `warded architect` session.

coilysiren added the

labels

2026-07-01 04:29:35 +00:00

coilyco-ops commented

2026-07-01 04:40:56 +00:00

Owner

🛫 ward pre-flight: NO-GO

ward agent engineer --driver claude ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

hard-blocked on agentic-os#297 (renderer/mirror not built) and an unnumbered per-driver permission-segmentation gate ("Kai to confirm"); shipping the mount before that gate risks leaking private inbox content, and the issue itself calls for a design consult first.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent engineer --driver claude <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

This is a pre-flight judgment, and the issue text settles it before any exploration is needed.

Context to front-load: If this run were unblocked, it would touch the agent-compose generator (agentic_os/generators/generate_agent_compose.py, the mount-eligibility.json per-harness segmentation), the gitcache hydrate path that mounts /substrate/<name>, and the ward-agent driver/permission model (docs/agent.md, docs/agent-preflight.md, docs/ward-kdl*.md, the tooling-ward-agent skill). I would read each in the clone before editing. But I don't reach that point here, because the issue is gated.

The issue declares itself BLOCKED on two hard prerequisites that are not resolved: (1) agentic-os#297 must first render the private corpus mirror repo with public/private tier segmentation — the artifact this mount consumes doesn't exist yet, and (2) a per-driver (claude|codex|qwen|goose) warded-agent permission-segmentation issue whose number is explicitly "TBD - Kai to confirm." The corpus contains coilysiren/inbox (private), and the issue is emphatic that mounting before the driver-tier gate exists would leak private content to uncleared agents — a data-exposure risk, exactly the irreversible/externally-consequential wall an unattended run must not cross. On top of that, the issue asks for a "design consult and capture from a warded architect session," so it's a design task with unconfirmed dependencies, not a clean implementable spec.

NO-GO: hard-blocked on agentic-os#297 (renderer/mirror not built) and an unnumbered per-driver permission-segmentation gate ("Kai to confirm"); shipping the mount before that gate risks leaking private inbox content, and the issue itself calls for a design consult first.

Posted automatically by ward agent engineer --driver claude pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent engineer --driver claude` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > hard-blocked on agentic-os#297 (renderer/mirror not built) and an unnumbered per-driver permission-segmentation gate ("Kai to confirm"); shipping the mount before that gate risks leaking private inbox content, and the issue itself calls for a design consult first. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent engineer --driver claude <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> This is a pre-flight judgment, and the issue text settles it before any exploration is needed. **Context to front-load:** If this run were unblocked, it would touch the agent-compose generator (`agentic_os/generators/generate_agent_compose.py`, the `mount-eligibility.json` per-harness segmentation), the gitcache hydrate path that mounts `/substrate/<name>`, and the ward-agent driver/permission model (docs/agent.md, docs/agent-preflight.md, docs/ward-kdl*.md, the `tooling-ward-agent` skill). I would read each in the clone before editing. But I don't reach that point here, because the issue is gated. The issue declares itself **BLOCKED on two hard prerequisites that are not resolved**: (1) agentic-os#297 must first render the private corpus mirror repo with public/private tier segmentation — the artifact this mount consumes doesn't exist yet, and (2) a per-driver (claude|codex|qwen|goose) warded-agent permission-segmentation issue whose number is explicitly "TBD - Kai to confirm." The corpus contains `coilysiren/inbox` (private), and the issue is emphatic that mounting before the driver-tier gate exists would leak private content to uncleared agents — a data-exposure risk, exactly the irreversible/externally-consequential wall an unattended run must not cross. On top of that, the issue asks for a "design consult and capture from a warded architect session," so it's a design task with unconfirmed dependencies, not a clean implementable spec. NO-GO: hard-blocked on agentic-os#297 (renderer/mirror not built) and an unnumbered per-driver permission-segmentation gate ("Kai to confirm"); shipping the mount before that gate risks leaking private inbox content, and the issue itself calls for a design consult first. </details> --- Posted automatically by `ward agent engineer --driver claude` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilyco-ops referenced this issue

2026-07-02 00:21:31 +00:00

1st class Ward to agent compose integration #215

coilyco-ops commented

2026-07-04 08:26:46 +00:00

Owner

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

coilysiren commented

2026-07-04 08:31:44 +00:00

Author

Owner

WARD-OUTCOME: blocked - both hard prerequisites are unmet: the coilysiren/issue-corpus mirror repo does not exist yet (404) and no per-driver substrate-mount gate exists. Needs the #297 rollout to actually create/populate the mirror, plus the reserved warded architect consult that defines the per-driver trust boundary, before the inbox corpus can safely mount.

I came in expecting to at least scaffold the mount, but the investigation closed it out fast and clean, so this is a candid "why it stayed blocked" rather than a build log. Two things I verified in-container instead of taking on faith:

The artifact doesn't exist. agentic-os#297's renderer landed, but ward ops forgejo repo get coilysiren issue-corpus is a 404, and a forge-wide search for "corpus" returns nothing. The #297 retro flagged exactly this - the mirror repo, push token, and first green cron run are rollout work that hasn't landed. You can't mount a repo that isn't there.
The gate doesn't exist. Substrate warming (preclone-repos.txt) is uniform across every driver; I confirmed zero coupling between the mount and the driver trust ladder. ward#578 landed per-role guardfile capability (advisor vs engineer, gating aws/tailnet), which is a different axis from the per-driver (claude|codex|qwen|goose) boundary this mount needs.

What made me stop rather than push a scaffold: the missing gate is a security trust boundary whose failure mode is leaking private coilysiren/inbox to uncleared drivers, and the issue explicitly reserves that design for you + an architect session ("number TBD - Kai to confirm"). A half-built gate landed on main as "done" is worse than none - it invites a later change to add the corpus behind a boundary nobody reviewed. So main is untouched.

Confidence this is genuinely blocked and not me missing a path: high - both blockers are objective facts, not judgment calls, and the earlier pre-flight NO-GO reached the same read.

Follow-ups, in order: (1) the agentic-os/infrastructure rollout that creates + populates coilysiren/issue-corpus; (2) the per-driver mount-gate ward issue (the "TBD" sibling) - likely a third preclone-repos.txt tier (e.g. gated) hydrated only for a cleared-driver allowlist, wired off the existing trust ladder. Once both land, the mount here is small and safe: add the corpus line at the gated tier + the discovery-index discipline in AGENTS.container.md.

WARD-OUTCOME: blocked - both hard prerequisites are unmet: the `coilysiren/issue-corpus` mirror repo does not exist yet (404) and no per-driver substrate-mount gate exists. Needs the #297 rollout to actually create/populate the mirror, plus the reserved `warded architect` consult that defines the per-driver trust boundary, before the inbox corpus can safely mount. I came in expecting to at least scaffold the mount, but the investigation closed it out fast and clean, so this is a candid "why it stayed blocked" rather than a build log. Two things I verified in-container instead of taking on faith: - **The artifact doesn't exist.** agentic-os#297's renderer landed, but `ward ops forgejo repo get coilysiren issue-corpus` is a 404, and a forge-wide search for "corpus" returns nothing. The #297 retro flagged exactly this - the mirror repo, push token, and first green cron run are rollout work that hasn't landed. You can't mount a repo that isn't there. - **The gate doesn't exist.** Substrate warming (`preclone-repos.txt`) is uniform across every driver; I confirmed zero coupling between the mount and the driver trust ladder. ward#578 landed *per-role* guardfile capability (advisor vs engineer, gating aws/tailnet), which is a different axis from the *per-driver* (claude|codex|qwen|goose) boundary this mount needs. What made me stop rather than push a scaffold: the missing gate is a security trust boundary whose failure mode is leaking private `coilysiren/inbox` to uncleared drivers, and the issue explicitly reserves that design for you + an architect session ("number TBD - Kai to confirm"). A half-built gate landed on `main` as "done" is worse than none - it invites a later change to add the corpus behind a boundary nobody reviewed. So `main` is untouched. Confidence this is genuinely blocked and not me missing a path: high - both blockers are objective facts, not judgment calls, and the earlier pre-flight NO-GO reached the same read. Follow-ups, in order: (1) the agentic-os/infrastructure rollout that creates + populates `coilysiren/issue-corpus`; (2) the per-driver mount-gate ward issue (the "TBD" sibling) - likely a third `preclone-repos.txt` tier (e.g. `gated`) hydrated only for a cleared-driver allowlist, wired off the existing trust ladder. Once both land, the mount here is small and safe: add the corpus line at the gated tier + the discovery-index discipline in `AGENTS.container.md`.

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:25 +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:12 +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:17:02 +00:00

Author

Owner

I'm going to do this - but it's going to be transparent to ward

coilysiren closed this issue

2026-07-06 20:17:02 +00:00

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00