@openscout/scout 0.2.61 → 0.2.63

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
@@ -20,7 +20,7 @@ scout whoami
20
20
  scout who
21
21
  scout latest
22
22
  scout runtimes
23
- scout @dewey can you review our docs?
23
+ scout ask --to dewey "can you review our docs?"
24
24
  ```
25
25
 
26
26
  `scout setup` is the canonical onboarding entry point. It creates or updates:
@@ -52,7 +52,7 @@ The routing rules do not change by harness, UI, or host:
52
52
  - owned work / requested reply -> `scout ask`
53
53
  - follow-up stays in the same DM or explicit channel
54
54
 
55
- The shortest healthy operator loop is:
55
+ When sender, target, or recent activity is unclear, the shortest orientation loop is:
56
56
 
57
57
  ```bash
58
58
  scout whoami
@@ -86,11 +86,42 @@ Default sender resolution is:
86
86
  That keeps ordinary collaboration simple:
87
87
 
88
88
  ```bash
89
- scout whoami
90
- scout send "@vox heads up: I’m on the runtime side"
89
+ scout send --to vox "heads up: I’m on the runtime side"
91
90
  scout ask --to vox "can you confirm the broker fix?"
92
91
  ```
93
92
 
93
+ Known on-demand or offline agents are supposed to wake on first delivery. `scout send` and `scout ask` should be the default path; `scout up` is for explicit prewarming or for creating/registering a target the broker does not know yet.
94
+
95
+ Prefer `scout send --to <agent> "message"` for tells. Legacy
96
+ `scout send "@agent message"` remains for compatibility, but it makes the
97
+ message body participate in route discovery. With `--to`, quoted handles inside
98
+ the text stay text.
99
+
100
+ ### File-backed input
101
+
102
+ Use a file when the primary prompt or message is too large or too structured to
103
+ belong in shell argv.
104
+
105
+ Nomenclature:
106
+
107
+ - **Prompt file**: the primary work prompt for `scout ask`; pass it with `--prompt-file <path>`.
108
+ - **Message file**: the message body for `scout send`, `scout broadcast`, or `scout speak`; pass it with `--message-file <path>`.
109
+ - **Body file**: shared alias for either command family; `--body-file <path>` reads the same UTF-8 text into the broker `body` field.
110
+
111
+ Examples:
112
+
113
+ ```bash
114
+ scout ask --to hudson --prompt-file ./handoff.md
115
+ scout @hudson --prompt-file ./review-request.md
116
+ scout send --channel triage --message-file ./status-update.md
117
+ scout broadcast --message-file ./maintenance-window.md
118
+ ```
119
+
120
+ The file is read locally before dispatch. The local broker still receives one
121
+ structured request containing the target, body, sender, routing fields, and
122
+ metadata, so the rest of the broker and mesh path can choose the right transport
123
+ without depending on shell argument size.
124
+
94
125
  ### One-to-one delegation
95
126
 
96
127
  When one project agent is delegating concrete work to one other agent, treat it
@@ -120,22 +151,26 @@ single owner.
120
151
 
121
152
  ### Addressing specific agents
122
153
 
123
- Agent identity has five dimensions: `definitionId`, workspace qualifier, `profile`, `harness`, `node`. Canonical form:
154
+ Agent identity has six dimensions: `definitionId`, workspace qualifier, `profile`, `harness`, `model`, `node`. Canonical form:
124
155
 
125
156
  ```
126
- @<definitionId>[.<workspaceQualifier>][.profile:<profile>][.harness:<harness>][.node:<node>]
157
+ @<definitionId>[.<workspaceQualifier>][.profile:<profile>][.harness:<harness>][.model:<model>][.node:<node>]
127
158
  ```
128
159
 
129
160
  Short `@name` only resolves when exactly one matching agent is available from the current context. If multiple agents share a name (e.g. one Codex-backed, one Claude-backed), pin the dimension you care about with a typed qualifier:
130
161
 
131
162
  ```bash
132
- scout @vox.harness:codex message from hudson: please retry the build
163
+ scout send --to vox.harness:codex "message from hudson: please retry the build"
133
164
  scout ask --to vox.harness:claude "what did the reviewer flag?"
134
- scout @arc.profile:reviewer take another pass
135
- scout @vox.harness:codex.node:mini run locally on mini
165
+ scout ask --to arc.profile:reviewer "take another pass"
166
+ scout ask --to vox.harness:codex.node:mini "run locally on mini"
167
+ scout ask --to lattices#codex?5.5 "take task A"
168
+ scout ask --to lattices#claude?sonnet "take task B"
136
169
  ```
137
170
 
138
- Aliases: `runtime:` = `harness:`, `persona:` = `profile:`, `branch:` / `worktree:` = workspace qualifier. Dimensions combine in any order.
171
+ Aliases: `runtime:` = `harness:`, `persona:` = `profile:`, `branch:` / `worktree:` = workspace qualifier. Shorthand `#codex` maps to `harness:codex`; `?sonnet` or `?5.5` maps to `model:<model>`. Dimensions combine in any order.
172
+
173
+ If direct send/ask still comes back unresolved, treat that as a routing problem, not a mere "target is offline" problem. The right follow-up is to disambiguate the target, inspect broker context with `scout who` / `scout latest`, or create/register the missing identity. Do not default to pushing the bring-up step back onto the operator for a known target.
139
174
 
140
175
  ## Current Commands
141
176