Run generic broker peers without a repository target #1636

New issue

Closed

opened 2026-08-02 04:42:57 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-02 04:42:57 +00:00

Member

Outcome

Let a generic broker-launched peer run without resolving, cloning, mounting, or authorizing a repository.

Ward should use a dedicated collaboration plan for this path instead of making the repository target optional throughout its existing engineering workflow plan.

Runtime contract

Required inputs are an existing cluster id, harness, role, freeform work, and a verified composed-context bundle.
The peer receives the current read-only substrate and Agent Compose materialization supplied by the launcher.
The peer receives a fresh writable scratch directory.
Repository metadata, checkout mounts, issue references, workflow selection, and Forgejo credentials are absent unless a repository integration is explicitly requested.
Existing repository-backed engineer, QA, director, reaper, and recovery behavior stays unchanged.
Nested peer launches inherit the parent cluster identity.

Acceptance criteria

A generic peer can attach to a broker-only cluster while the caller is outside a Git checkout.
The launch path does not call repository target resolution, owner allowlisting, clone preparation, or repository workflow selection.
No Forgejo credential is requested or projected.
The composed bundle and substrate are mounted read-only, with writable state limited to the peer's scratch and runtime homes.
Messages, logs, stop, and cleanup work for the repo-free peer.
A repository remains an explicit optional integration for software work.
Focused tests prove both the repo-free path and non-regression of repository-backed launches.
Documentation distinguishes collaboration plans from repository workflow plans.

Depends on

#1592
#1635

## Outcome Let a generic broker-launched peer run without resolving, cloning, mounting, or authorizing a repository. Ward should use a dedicated collaboration plan for this path instead of making the repository target optional throughout its existing engineering workflow plan. ## Runtime contract * Required inputs are an existing cluster id, harness, role, freeform work, and a verified composed-context bundle. * The peer receives the current read-only substrate and Agent Compose materialization supplied by the launcher. * The peer receives a fresh writable scratch directory. * Repository metadata, checkout mounts, issue references, workflow selection, and Forgejo credentials are absent unless a repository integration is explicitly requested. * Existing repository-backed engineer, QA, director, reaper, and recovery behavior stays unchanged. * Nested peer launches inherit the parent cluster identity. ## Acceptance criteria * A generic peer can attach to a broker-only cluster while the caller is outside a Git checkout. * The launch path does not call repository target resolution, owner allowlisting, clone preparation, or repository workflow selection. * No Forgejo credential is requested or projected. * The composed bundle and substrate are mounted read-only, with writable state limited to the peer's scratch and runtime homes. * Messages, logs, stop, and cleanup work for the repo-free peer. * A repository remains an explicit optional integration for software work. * Focused tests prove both the repo-free path and non-regression of repository-backed launches. * Documentation distinguishes collaboration plans from repository workflow plans. ## Depends on * #1592 * #1635 ## Related * #1626 * coilyco-flight-deck/agentic-os#825 * coilysiren/inbox#309 * coilysiren/inbox#310

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

2026-08-02 04:43:27 +00:00

Attach composed agents to repo-free Ward collaboration clusters #851

coilyco-ops referenced this issue

2026-08-02 04:43:42 +00:00

Give each Ward collaboration cluster a harness-scoped stable identity #1592

coilyco-ops added the

priority

autonomy

headless

labels

2026-08-02 04:43:50 +00:00