Remove ward SSH feature surfaces from the shipped product

coilysiren commented

2026-07-09 23:24:01 +00:00

Owner

Release-readiness scope for the 2026-07-10 five-push batch. Follows #842 and replaces the placeholder body.

Goal

Ward should not ship Kai-specific SSH-backed features as product behavior. If SSH is only an implementation detail for an operator's private KDL bundle, it belongs in that selected bundle, not in ward's baked defaults, generated docs, or core feature code.

Do

Inventory every shipped SSH surface in code, KDL assets, generated docs, and feature docs.
Remove Kai-specific SSH feature surfaces from ward's default shipped bundle and docs.
Keep generic git-over-SSH dependency seeding only if it is truly part of the external dependency feature and not a Kai ops shortcut. If kept, docs must clearly distinguish it from ward ops SSH features.
Remove or neutralize docs such as custom server/admin SSH operator pages if they are only valid for Kai's infrastructure.
Update docs/FEATURES.md if the feature inventory changes.

Acceptance

rg -n "ssh|kai-server|kai@|eco-server" .ward docs cmd/ward shows no shipped Kai-specific SSH feature surface, except clearly marked historical/reference text or generic git SSH support that remains intentionally supported.
ward exec test passes, or the issue comment names the exact failing check.

Ignore the earlier scope comment's trailing patch marker. This body is the clean contract.

Closes #885 when merged.

Release-readiness scope for the 2026-07-10 five-push batch. Follows #842 and replaces the placeholder body. ## Goal Ward should not ship Kai-specific SSH-backed features as product behavior. If SSH is only an implementation detail for an operator's private KDL bundle, it belongs in that selected bundle, not in ward's baked defaults, generated docs, or core feature code. ## Do - Inventory every shipped SSH surface in code, KDL assets, generated docs, and feature docs. - Remove Kai-specific SSH feature surfaces from ward's default shipped bundle and docs. - Keep generic git-over-SSH dependency seeding only if it is truly part of the external dependency feature and not a Kai ops shortcut. If kept, docs must clearly distinguish it from ward ops SSH features. - Remove or neutralize docs such as custom server/admin SSH operator pages if they are only valid for Kai's infrastructure. - Update `docs/FEATURES.md` if the feature inventory changes. ## Acceptance - `rg -n "ssh|kai-server|kai@|eco-server" .ward docs cmd/ward` shows no shipped Kai-specific SSH feature surface, except clearly marked historical/reference text or generic git SSH support that remains intentionally supported. - `ward exec test` passes, or the issue comment names the exact failing check. Ignore the earlier scope comment's trailing patch marker. This body is the clean contract. Closes #885 when merged.

coilysiren referenced this issue

2026-07-09 23:59:57 +00:00

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

coilysiren referenced this issue

2026-07-10 00:00:04 +00:00

fix: keep ward-ssh generic #881

coilyco-ops commented

2026-07-10 00:36:51 +00:00

Member

Release-readiness scope for this push batch, from the 2026-07-10 director surface.\n\nPlease carry this as the third of five release pushes: remove ward's custom SSH feature code, not merely narrow one unsafe verb.\n\n## Goal\n\nWard should not ship Kai-specific SSH-backed features as product behavior. If SSH is only an implementation detail for an operator's private KDL bundle, it belongs in that bundle, not in ward's baked defaults, generated docs, or core feature code.\n\n## Do\n\n- Inventory every shipped SSH surface in code, KDL assets, generated docs, and feature docs.\n- Remove Kai-specific SSH feature surfaces from ward's default shipped bundle and docs.\n- Keep generic git-over-SSH dependency seeding only if it is truly part of the external dependency feature and not a Kai ops shortcut. If kept, docs must clearly distinguish it from ward ops SSH features.\n- Remove or neutralize docs such as custom server/admin SSH operator pages if they are only valid for Kai's infrastructure.\n- Update docs/FEATURES.md if the feature inventory changes.\n\n## Acceptance\n\n- rg -n \"ssh|kai-server|kai@|eco-server\" .ward docs cmd/ward shows no shipped Kai-specific SSH feature surface, except clearly marked historical/reference text or generic git SSH support that remains intentionally supported.\n- ward exec test passes, or the issue comment names the exact failing check.\n\nThis should close #885 when merged.\n*** End Patch

Release-readiness scope for this push batch, from the 2026-07-10 director surface.\n\nPlease carry this as the third of five release pushes: remove ward's custom SSH feature code, not merely narrow one unsafe verb.\n\n## Goal\n\nWard should not ship Kai-specific SSH-backed features as product behavior. If SSH is only an implementation detail for an operator's private KDL bundle, it belongs in that bundle, not in ward's baked defaults, generated docs, or core feature code.\n\n## Do\n\n- Inventory every shipped SSH surface in code, KDL assets, generated docs, and feature docs.\n- Remove Kai-specific SSH feature surfaces from ward's default shipped bundle and docs.\n- Keep generic git-over-SSH dependency seeding only if it is truly part of the external dependency feature and not a Kai ops shortcut. If kept, docs must clearly distinguish it from ward ops SSH features.\n- Remove or neutralize docs such as custom server/admin SSH operator pages if they are only valid for Kai's infrastructure.\n- Update `docs/FEATURES.md` if the feature inventory changes.\n\n## Acceptance\n\n- `rg -n \"ssh|kai-server|kai@|eco-server\" .ward docs cmd/ward` shows no shipped Kai-specific SSH feature surface, except clearly marked historical/reference text or generic git SSH support that remains intentionally supported.\n- `ward exec test` passes, or the issue comment names the exact failing check.\n\nThis should close #885 when merged.\n*** End Patch

coilyco-ops changed title from ~~remove ward ssh~~ to Remove ward SSH feature surfaces from the shipped product

2026-07-10 00:37:10 +00:00

coilyco-ops commented

2026-07-10 00:38:02 +00:00

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T00:37:59Z). 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#885 · branch issue-885 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-885 · ward v0.543.0 · dispatched 2026-07-10T00:37:59Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T00:36:51Z)

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

— Codex, via ward agent

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

coilyco-ops added the

headless

P1

labels

2026-07-10 00:41:40 +00:00

coilyco-ops referenced this issue

2026-07-10 00:45:41 +00:00

Director surface heartbeat marks broker-forwarded runs failed when local Docker is unavailable #900

coilyco-ops commented

2026-07-10 00:45:42 +00:00

Member

WARD-DISPATCH: failed ❌

failure details

This forwarded dispatch failed after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#885 --harness codex --image forgejo.coilysiren.me/coilyco-flight-deck/agentic-os --tag latest
Container: engineer-codex-ward-885
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T004439Z-director-codex-zv98-coilyco-flight-deck-ward-885.log
Failure: ward agent engineer --harness codex: issue coilyco-flight-deck/ward#885 already has a running worker container engineer-codex-ward-885; wait for it to finish or pass --force to reclaim

Retry: choose another harness if the first one is down, or rerun with --force if the reservation is stale.

— Codex, via ward agent

WARD-DISPATCH: failed ❌ <details><summary>failure details</summary> This forwarded dispatch failed after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#885 --harness codex --image forgejo.coilysiren.me/coilyco-flight-deck/agentic-os --tag latest` Container: `engineer-codex-ward-885` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T004439Z-director-codex-zv98-coilyco-flight-deck-ward-885.log` Failure: `ward agent engineer --harness codex: issue coilyco-flight-deck/ward#885 already has a running worker container engineer-codex-ward-885; wait for it to finish or pass --force to reclaim` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-10 00:50:08 +00:00

remove ward ssh feature surfaces

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

2026-07-10 00:50:12 +00:00

Remove ward SSH feature surfaces #904

coilyco-ops commented

2026-07-10 00:55:57 +00:00

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped by ~/.ward/config.yaml default
review gate was intentionally skipped by ~/.ward/config.yaml default.
felt: the removal was straightforward, but I had to clear unrelated lint debt in agent.go to get CI green.
confidence: high
surprise: CI first failed on existing gocognit and funlen debt in launchAgentContainer, not on the SSH removal.
follow-ups: merge PR #904 once the director loop picks it up, then record the final done outcome.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped by ~/.ward/config.yaml default review gate was intentionally skipped by ~/.ward/config.yaml default. felt: the removal was straightforward, but I had to clear unrelated lint debt in `agent.go` to get CI green. confidence: high surprise: CI first failed on existing `gocognit` and `funlen` debt in `launchAgentContainer`, not on the SSH removal. follow-ups: merge PR #904 once the director loop picks it up, then record the final done outcome. </details>

coilyco-ops commented

2026-07-10 05:11:30 +00:00

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T05:11:30Z). 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#885 · branch issue-885 · harness codex · workflow pull-requests
Run: engineer-codex-ward-885 · ward v0.555.0 · dispatched 2026-07-10T05:11:30Z
Comment thread: 3 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T00:36:51Z), @coilyco-ops (2026-07-10T00:45:42Z), @coilyco-ops (2026-07-10T00:55:57Z)
- stripped: @coilyco-ops (2026-07-10T00:38:02Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-885` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T05:11:30Z). 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#885` · branch `issue-885` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-885` · ward `v0.555.0` · dispatched `2026-07-10T05:11:30Z` - **Comment thread:** 3 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T00:36:51Z), @coilyco-ops (2026-07-10T00:45:42Z), @coilyco-ops (2026-07-10T00:55:57Z) - stripped: @coilyco-ops (2026-07-10T00:38:02Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-10 05:25:57 +00:00

remove ward ssh feature surfaces

coilyco-ops commented

2026-07-10 05:26:06 +00:00

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 05:27:12 +00:00

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 05:32:34 +00:00

Member

WARD-OUTCOME: blocked 🛑

details

workflow: pull-requests; review summary: skipped because review gate skipped by ~/.ward/config.yaml default

Local ward exec test passes. Forgejo Actions runs 1511 and 1512 both fail in test / test (pull_request) during Set up job after 3s, with no step logs exposed, so I could not confirm a repo-side regression from CI.

Implementation felt straightforward on the code path and noisy on the rebase path. Confidence: medium. Surprise: the refreshed branch still dies before checkout, which points to the runner or workflow layer, not the SSH cleanup itself. Follow-up: investigate the Forgejo Actions setup failure on the test.yml workflow for PR #904.

WARD-OUTCOME: blocked 🛑 <details><summary>details</summary> workflow: pull-requests; review summary: skipped because review gate skipped by ~/.ward/config.yaml default Local `ward exec test` passes. Forgejo Actions runs 1511 and 1512 both fail in `test / test (pull_request)` during `Set up job` after 3s, with no step logs exposed, so I could not confirm a repo-side regression from CI. Implementation felt straightforward on the code path and noisy on the rebase path. Confidence: medium. Surprise: the refreshed branch still dies before checkout, which points to the runner or workflow layer, not the SSH cleanup itself. Follow-up: investigate the Forgejo Actions setup failure on the `test.yml` workflow for PR #904. </details>

coilyco-ops closed this issue

2026-07-10 06:25:09 +00:00

Rows
Columns

Remove ward SSH feature surfaces from the shipped product #885

Goal

Do

Acceptance