Let broker-only clusters start without repository target environment #1639

New issue

Closed

opened 2026-08-02 06:22:52 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-02 06:22:52 +00:00

Member

Problem

Ward v0.868.0 creates the broker container for a repository-independent collaboration cluster, but the broker immediately enters a restart loop:

/opt/ward-shell-entrypoint.sh: line 10: WARD_TARGET_OWNER: missing WARD_TARGET_OWNER

Reproduction from a directory outside a Git checkout:

ward agent cluster start --harness codex

The command creates the Compose network and broker container, then fails because the container is unhealthy. Ward embeds and stages /opt/ward-shell-entrypoint.sh, and that wrapper currently requires repository-target variables even for the broker-only plan.

This violates the repository-independent lifecycle introduced by #1635 and blocks the generic peer path in #1636.

Expected behavior

Starting a broker-only collaboration cluster must not require a repository owner, repository name, issue, workflow, checkout, or Forgejo credential. The broker should become healthy and Ward should return the cluster id.

Acceptance criteria

ward agent cluster start succeeds from outside a Git checkout with no repository target.
The broker-only entrypoint does not require WARD_TARGET_OWNER or other repository workflow variables.
The started cluster contains only the supervised broker and reaches healthy state.
Harness or repository credentials are not required until a peer that needs them attaches.
Focused runtime coverage exercises the generated Compose plan and broker health check, not only YAML rendering.
Repository-backed engineer, QA, director, recovery, and reaper entrypoints remain unchanged.
Documentation changes are unnecessary unless the public contract changes.

## Problem Ward v0.868.0 creates the broker container for a repository-independent collaboration cluster, but the broker immediately enters a restart loop: ```text /opt/ward-shell-entrypoint.sh: line 10: WARD_TARGET_OWNER: missing WARD_TARGET_OWNER ``` Reproduction from a directory outside a Git checkout: ```text ward agent cluster start --harness codex ``` The command creates the Compose network and broker container, then fails because the container is unhealthy. Ward embeds and stages `/opt/ward-shell-entrypoint.sh`, and that wrapper currently requires repository-target variables even for the broker-only plan. This violates the repository-independent lifecycle introduced by #1635 and blocks the generic peer path in #1636. ## Expected behavior Starting a broker-only collaboration cluster must not require a repository owner, repository name, issue, workflow, checkout, or Forgejo credential. The broker should become healthy and Ward should return the cluster id. ## Acceptance criteria * `ward agent cluster start` succeeds from outside a Git checkout with no repository target. * The broker-only entrypoint does not require `WARD_TARGET_OWNER` or other repository workflow variables. * The started cluster contains only the supervised broker and reaches healthy state. * Harness or repository credentials are not required until a peer that needs them attaches. * Focused runtime coverage exercises the generated Compose plan and broker health check, not only YAML rendering. * Repository-backed engineer, QA, director, recovery, and reaper entrypoints remain unchanged. * Documentation changes are unnecessary unless the public contract changes. ## Related * #1592 * #1635 * #1636 * #1637

coilyco-ops added the

autonomy

headless

priority

labels

2026-08-02 06:23:00 +00:00

coilyco-ops referenced this issue from a commit

2026-08-02 06:44:13 +00:00

fix: start broker-only clusters without repo target

coilyco-ops closed this issue

2026-08-02 06:44:14 +00:00