Keep ward-ssh generic: remove Kai-specific host/user assumptions #842

New issue

Closed

opened 2026-07-09 18:21:56 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-09 18:21:56 +00:00

Member

Problem

ward#836 added a useful container SSH-over-SOCKS helper, but review from the director surface found it crossed the ownership boundary: ward now knows too much about Kai's local setup.

Evidence in e12c316 feat: add ward-ssh tailnet helper:

cmd/ward/container_bootstrap.go installs /usr/local/bin/ward-ssh when WARD_TS_SOCKS5 is present. The generic proxy mechanics are fine.
The helper defaults short destinations to kai@<host>, which is Kai-specific.
Docs such as docs/agent-ts-sidecar.md center the mac-proxy / ward-tailnet implementation, which is also localized to Kai's infra.

The right split is: ward may consume a generic WARD_TS_SOCKS5 value and provide generic SSH proxy plumbing, but it should not encode Kai's user, host names, or mac-proxy topology as product assumptions. Kai-specific defaults belong in infrastructure / agentic-os-kai / local composed context, not ward core.

Do

Remove kai@ defaulting from ward-ssh, or make it configurable through an env var owned by the launcher/context (for example a default SSH user env) with no Kai default in ward.
Keep WARD_TS_SOCKS5 parsing generic. It is acceptable for ward to use a SOCKS5 URL it was explicitly handed.
Move or soften mac-proxy-specific docs so ward documents the generic contract and links/points to local infra for one implementation.
Preserve the useful helper behavior for explicit destinations such as ward-ssh kai@kai-server hostname.
Add/update tests so ward does not regress into hardcoded Kai-local assumptions.

Acceptance

Ward core has no hardcoded Kai username/default host behavior in ward-ssh.
Ward docs describe a generic SOCKS5 tailnet route contract, not a product dependency on Kai's mac-proxy deployment.
Kai-specific mac-proxy details remain in the infrastructure/local-context docs that own them.

Codex, via director surface

## Problem `ward#836` added a useful container SSH-over-SOCKS helper, but review from the director surface found it crossed the ownership boundary: ward now knows too much about Kai's local setup. Evidence in `e12c316 feat: add ward-ssh tailnet helper`: * `cmd/ward/container_bootstrap.go` installs `/usr/local/bin/ward-ssh` when `WARD_TS_SOCKS5` is present. The generic proxy mechanics are fine. * The helper defaults short destinations to `kai@<host>`, which is Kai-specific. * Docs such as `docs/agent-ts-sidecar.md` center the `mac-proxy` / `ward-tailnet` implementation, which is also localized to Kai's infra. The right split is: ward may consume a generic `WARD_TS_SOCKS5` value and provide generic SSH proxy plumbing, but it should not encode Kai's user, host names, or mac-proxy topology as product assumptions. Kai-specific defaults belong in infrastructure / agentic-os-kai / local composed context, not ward core. ## Do * Remove `kai@` defaulting from `ward-ssh`, or make it configurable through an env var owned by the launcher/context (for example a default SSH user env) with no Kai default in ward. * Keep `WARD_TS_SOCKS5` parsing generic. It is acceptable for ward to use a SOCKS5 URL it was explicitly handed. * Move or soften mac-proxy-specific docs so ward documents the generic contract and links/points to local infra for one implementation. * Preserve the useful helper behavior for explicit destinations such as `ward-ssh kai@kai-server hostname`. * Add/update tests so ward does not regress into hardcoded Kai-local assumptions. ## Acceptance * Ward core has no hardcoded Kai username/default host behavior in `ward-ssh`. * Ward docs describe a generic SOCKS5 tailnet route contract, not a product dependency on Kai's `mac-proxy` deployment. * Kai-specific mac-proxy details remain in the infrastructure/local-context docs that own them.  Codex, via director surface

coilyco-ops commented

2026-07-09 18:22:06 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T18:22:03Z). 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#842 · branch issue-842 · harness codex · workflow direct-to-main
Run: engineer-codex-ward-842 · ward v0.495.0 · dispatched 2026-07-09T18:22:03Z
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.495.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-842` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T18:22:03Z). 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#842` · branch `issue-842` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-ward-842` · ward `v0.495.0` · dispatched `2026-07-09T18:22:03Z` - **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.495.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

headless

labels

2026-07-09 21:49:43 +00:00

coilyco-ops commented

2026-07-09 22:44:52 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T22:44:50Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

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

Resolved: coilyco-flight-deck/ward#842 · branch issue-842 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-842 · ward v0.540.0 · dispatched 2026-07-09T22:44:50Z
Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-09T18:22:06Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-842` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T22:44:50Z). 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#842` · branch `issue-842` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-842` · ward `v0.540.0` · dispatched `2026-07-09T22:44:50Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-09T18:22:06Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.540.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-09 23:07:29 +00:00

fix: keep ward-ssh generic #881