Add compact repo maps for high-churn warded workflow areas #524

Closed
opened 2026-07-14 10:09:11 +00:00 by coilyco-ops · 3 comments
Member

Parent

coilysiren/inbox#212

What to build

Add compact AOS-hosted repo maps for the high-churn warded workflow areas that repeatedly cost agents wrong-path searches and stale-tree reads.

The maps should be small enough to read early, and they should point agents at the first files and targeted validation commands for common issue shapes. This is AOS-owned context tooling so it can apply across warded runs instead of living as scattered repo lore.

Initial map set

  • Ward reaper and drain lifecycle.
  • Ward PR workflow and director merge/burn-down paths.
  • Forgejo ops or replacement workflow surface discovery.
  • Container startup and broker dispatch.
  • AOS Ward spec overlay and role-tier bundle.

Acceptance criteria

  • A compact map exists for each initial high-churn area, or the issue documents why a specific area moved to a separate ticket.
  • Each map lists the current entry-point files and the first targeted validation command or check to run.
  • The maps explicitly remind agents that /workspace is authoritative when the same repo also exists under /substrate.
  • The maps stay public-safe and avoid host-private identifiers.
  • A repo-level index or doc points agents to these maps without requiring broad doc search.

Blocked by

None - can start immediately.

## Parent coilysiren/inbox#212 ## What to build Add compact AOS-hosted repo maps for the high-churn warded workflow areas that repeatedly cost agents wrong-path searches and stale-tree reads. The maps should be small enough to read early, and they should point agents at the first files and targeted validation commands for common issue shapes. This is AOS-owned context tooling so it can apply across warded runs instead of living as scattered repo lore. ## Initial map set - Ward reaper and drain lifecycle. - Ward PR workflow and director merge/burn-down paths. - Forgejo ops or replacement workflow surface discovery. - Container startup and broker dispatch. - AOS Ward spec overlay and role-tier bundle. ## Acceptance criteria - [ ] A compact map exists for each initial high-churn area, or the issue documents why a specific area moved to a separate ticket. - [ ] Each map lists the current entry-point files and the first targeted validation command or check to run. - [ ] The maps explicitly remind agents that `/workspace` is authoritative when the same repo also exists under `/substrate`. - [ ] The maps stay public-safe and avoid host-private identifiers. - [ ] A repo-level index or doc points agents to these maps without requiring broad doc search. ## Blocked by None - can start immediately. ## Related - coilyco-flight-deck/ward#1237 covers structured friction events that can later feed map priority.
Author
Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-agentic-os-524 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-14T10:15:52Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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).

run seed context — what this run is carrying (ward#609)
  • Resolved: coilyco-flight-deck/agentic-os#524 · branch issue-524 · harness codex · workflow pull-request-and-merge
  • Run: engineer-codex-agentic-os-524 · ward v0.679.0 · dispatched 2026-07-14T10:15:48Z
  • Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.679.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-agentic-os-524` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-14T10:15:52Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/agentic-os#524` · branch `issue-524` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-agentic-os-524` · ward `v0.679.0` · dispatched `2026-07-14T10:15:48Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.679.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Owner

Comment on the 1st pass at impl

As written it doesn't meet the goal / my vision. I was envisioning a flow / system where aos knows how to dynamically pull data about every one of my github repos that is structurally always fresh. This is... the opposite. It even hardcodes individual files that I'm planning on churning today

Comment on the 1st pass at impl > As written it doesn't meet the goal / my vision. I was envisioning a flow / system where aos knows how to dynamically pull data about every one of my github repos that is structurally always fresh. This is... the opposite. It even hardcodes individual files that I'm planning on churning *today*
Author
Member

WARDED_WORKFLOW: pass

details

workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default

{
  "verdict": "pass",
  "summary": "Reworked the maps around discovery-first search commands so the current files stay rediscoverable as the surface moves.",
  "evidence": [
    "Added a repo-level index in docs/repo-maps.md.",
    "Converted each map to search-first discovery commands plus the current first check.",
    "Kept /workspace authoritative when the repo is also mounted under /substrate.",
    "ward exec pre-commit-all passed.",
    "PR #527 checks are green on head SHA 0970ba934665216ee027f613d58d202c31824c0d."
  ]
}

Retro: the first pass was too static, so the maps were reworked around discovery commands.
Confidence: high.
Surprise: the director merge path keys off the issue-thread verdict, not the PR URL.
Follow-up: none.

WARDED_WORKFLOW: pass <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default ```json { "verdict": "pass", "summary": "Reworked the maps around discovery-first search commands so the current files stay rediscoverable as the surface moves.", "evidence": [ "Added a repo-level index in docs/repo-maps.md.", "Converted each map to search-first discovery commands plus the current first check.", "Kept /workspace authoritative when the repo is also mounted under /substrate.", "ward exec pre-commit-all passed.", "PR #527 checks are green on head SHA 0970ba934665216ee027f613d58d202c31824c0d." ] } ``` Retro: the first pass was too static, so the maps were reworked around discovery commands. Confidence: high. Surprise: the director merge path keys off the issue-thread verdict, not the PR URL. Follow-up: none. </details>
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
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/agentic-os#524
No description provided.