Use o2r dictatable IDs for director session suffixes #811

New issue

Closed

opened 2026-07-09 16:12:47 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 16:12:47 +00:00

Member

Director/surface session containers should use the o2r dictatable agent-id suffix format instead of the current machine-derived suffix.

Context:

Kai asked for director container sessions to use the o2r name format for their suffix.
Current ward code appears to build director surface session names through containerRoleName(roleSession, mode, repo, 0, plan.Machine), yielding names like session-<harness>-<machine>.
The o2r format is now documented in aos as the canonical short agent id: two lowercase letters followed by two digits, with letters from abcdefghjkmpqrstuvwxyz and digits from 456789, e.g. ab85.
Relevant aos sources: /substrate/agentic-os/agentic_os/agent_id.py and /substrate/agentic-os/docs/dictatable-id-alphabet.md. coilyco-flight-deck/agentic-os#308 is related naming/config context, but this issue tracks the ward implementation.

Scope:

Apply this to director/surface session containers, i.e. the session role used by director interactive surfaces.
Do not rename issue-bound engineer containers unless the implementation uncovers a shared naming contract that requires it.

Acceptance:

New director/surface session container suffixes match the o2r dictatable id contract: ^[a-hjkm-pqrstuvwxyz]{2}[456789]{2}$.
Session names remain Docker-safe and avoid practical collisions across concurrent director sessions.
Tests cover the generated session/director container name shape.
Any docs that describe director/session container names are updated.

Director/surface session containers should use the o2r dictatable agent-id suffix format instead of the current machine-derived suffix. Context: - Kai asked for director container sessions to use the o2r name format for their suffix. - Current ward code appears to build director surface session names through `containerRoleName(roleSession, mode, repo, 0, plan.Machine)`, yielding names like `session-<harness>-<machine>`. - The o2r format is now documented in aos as the canonical short agent id: two lowercase letters followed by two digits, with letters from `abcdefghjkmpqrstuvwxyz` and digits from `456789`, e.g. `ab85`. - Relevant aos sources: `/substrate/agentic-os/agentic_os/agent_id.py` and `/substrate/agentic-os/docs/dictatable-id-alphabet.md`. `coilyco-flight-deck/agentic-os#308` is related naming/config context, but this issue tracks the ward implementation. Scope: - Apply this to director/surface session containers, i.e. the `session` role used by director interactive surfaces. - Do not rename issue-bound engineer containers unless the implementation uncovers a shared naming contract that requires it. Acceptance: - New director/surface session container suffixes match the o2r dictatable id contract: `^[a-hjkm-pqrstuvwxyz]{2}[456789]{2}$`. - Session names remain Docker-safe and avoid practical collisions across concurrent director sessions. - Tests cover the generated session/director container name shape. - Any docs that describe director/session container names are updated.

coilyco-ops commented

2026-07-09 16:12:56 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-811 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T16:12:54Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h 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).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#811 · branch issue-811 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-811 · ward v0.493.0 · dispatched 2026-07-09T16:12:54Z
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.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-811` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T16:12:54Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h 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). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#811` · branch `issue-811` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-811` · ward `v0.493.0` · dispatched `2026-07-09T16:12:54Z` - **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.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 16:21:08 +00:00

Use o2r dictatable IDs for director session suffixes #814

coilyco-ops closed this issue

2026-07-09 16:21:57 +00:00

coilyco-ops commented

2026-07-09 16:22:22 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: review gate skipped by --skip-review / --no-review-gate
felt: narrow and predictable. one suffix seam, one helper, tests and docs stayed local.
confidence: high.
surprises: Forgejo API merge and status polling were straightforward.
follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped by --skip-review / --no-review-gate felt: narrow and predictable. one suffix seam, one helper, tests and docs stayed local. confidence: high. surprises: Forgejo API merge and status polling were straightforward. follow-ups: none. </details>