@sailorbridge/client 0.2.0 → 0.2.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -73,6 +73,9 @@ sailorbridge host register
73
73
  sailorbridge host consume --once --dry-run-start
74
74
  sailorbridge host service install --binary /opt/sailorbridge/bin/sailorbridge
75
75
  sailorbridge host service status
76
+ sailorbridge worker list
77
+ sailorbridge worker run --worker dev-1 -- uname -s
78
+ sailorbridge worker job JOB_ID
76
79
  sailorbridge worker serve --worker dev-1 --workdir "$PWD"
77
80
  sailorbridge supervise --agent ab_hand --cli codex --cwd "$PWD" --i-own-this-agent
78
81
  ```
@@ -140,9 +143,13 @@ SAILORBRIDGE_WORKDIR=~/sailorbridge-workdir
140
143
  SAILORBRIDGE_MAX_CONCURRENCY=1
141
144
  ```
142
145
 
143
- `SAILORBRIDGE_CAPTAIN_ID` is optional for current descriptors but, when present,
144
- must be a numeric string. It is diagnostic identity metadata; routing still uses
145
- the short `SAILORBRIDGE_AGENT_NAME`.
146
+ `SAILORBRIDGE_CAPTAIN_ID` is required by `worker list`, `worker run`, and
147
+ `worker job`; it must be a numeric string. `worker list` and `worker run` also
148
+ require `SAILORBRIDGE_SESSION` so an unbound admin credential cannot
149
+ accidentally discover workers across teams. A paired host credential can
150
+ supply the captain id, but it does not contain a session, so list/run still
151
+ need `SAILORBRIDGE_SESSION`. Agent routing uses the separate
152
+ `SAILORBRIDGE_AGENT_NAME`.
146
153
 
147
154
  `SAILORBRIDGE_HOST_ID` and `SAILORBRIDGE_HOST_DISPLAY_NAME` identify the
148
155
  captain-scoped local host for Tier 6 console start-request polling. When omitted,
@@ -171,6 +178,21 @@ Use `--worker`, `--workdir`, and `--max-concurrency` or the matching
171
178
  `SAILORBRIDGE_MAX_CONCURRENCY` environment variables. `SAILORBRIDGE_MODE=readonly`
172
179
  blocks mutating job kinds locally.
173
180
 
181
+ `sailorbridge worker list [--format plain|json]` discovers registered workers
182
+ in the current team. Plain output shows at most 20 and points to JSON for the
183
+ complete response. `sailorbridge worker run [--detach] --worker NAME
184
+ [--timeout SEC] [--format plain|json] -- ARGV...` submits one `bash` job and
185
+ preserves `ARGV` as an array end to end; `--format` after `--` belongs to the
186
+ remote argv. The timeout is the remote execution budget; synchronous mode
187
+ waits that budget plus a 30-second queue/result grace for the persisted
188
+ terminal result. Plain output writes remote stdout/stderr to the matching local
189
+ streams. A remote negative signal code remains exact in JSON; plain output
190
+ states that code and uses the conventional local status `128 + signal`. For
191
+ long work, `--detach` returns the submit response immediately; `sailorbridge
192
+ worker job ID [--format plain|json]` reports queued/running or the terminal
193
+ result. Worker jobs are infrastructure execution, not product tasks; their
194
+ status never completes a SailorBridge task lifecycle.
195
+
174
196
  `sailorbridge login` creates a host pairing against
175
197
  `https://www.sailorbridge.com`. The command displays the one-time code and
176
198
  polls until approval. The stored credential contains a host-scoped relay key
@@ -233,10 +255,11 @@ Claude uses `$CLAUDE_CONFIG_DIR/.credentials.json` when set, otherwise
233
255
  The per-agent sandbox links to that single host auth file; missing engine auth
234
256
  fails fast instead of starting a CLI that will prompt for credentials.
235
257
 
236
- Worker commands implement the relay worker contract from `engine/PROTOCOL.md`:
237
- register, heartbeat, pull, stream upload, and result posting. Worker HTTP uses
238
- bounded connect/read-idle timeouts for liveness and leaves result uploads without
239
- a total timeout cap.
258
+ Worker commands implement both sides of the relay worker contract from
259
+ `engine/PROTOCOL.md`: register, heartbeat, pull, stream upload, result posting,
260
+ session-scoped worker listing, direct `bash` submission, and terminal result
261
+ reads. Worker HTTP uses bounded connect/read-idle timeouts for liveness and
262
+ leaves result uploads without a total timeout cap.
240
263
 
241
264
  Mailbox claim is a destructive operation on the relay; `mailbox peek` is the
242
265
  non-destructive command. Add `--lease` to a claim only to include rows already