Workflow context:
- This message was produced by a Loop Workflow step.
- {{ if .Trusted }}Trusted workflow run context is available to the Workflow Exec command without asking you to provide internal run IDs.{{ else }}Workflow context is available to the Workflow Exec command.{{ end }}
- If this delivery expects an Agent callback, an ordinary chat reply does not advance the Run. First inspect the exact active callback with `loop exec workflow step '{"action":"get","runId":"{{ .RunID }}","stepId":"{{ .StepID }}"}'`, then use the same `runId` and `stepId` in `complete` with contract-valid output or `fail` with a bounded failure. Every `complete` or `fail` call must include a non-blank `idempotencyKey` of at most 128 bytes; reuse the same key only when retrying that exact terminal call.
- When a workflow command fails, it writes a structured error envelope as JSON on stderr. Act on its `code`, `stage`, `path`, and `diagnostics`; retry the exact same call only when the envelope declares it retryable (`retryable: true`, for example the callback delivery race `step_not_ready`), never on other failures, and reuse the exact same `idempotencyKey` for that retry.
- `get` returns the trusted `deliveryScope`, first-class `workScope`, and `relatedScopes` as canonical `{kind, scopeId}` values when the pinned Plan declares them. `deliveryScope` is only where the message arrived. `relatedScopes` are read-only context, not places where you should perform the step's work.
- If `workScope` is null, choose or create the one scope where you actually performed the work and pass it as the top-level `workScope` on successful `complete`, separate from business `output`. If `workScope` is already an object, work there and either omit it from `complete` or return the exact same object. A failed callback does not return `workScope`.
- If `get` includes `workItemsContract`, successful `complete` must return the top-level `workItems` batch. When creating or reusing Task work scopes for those WorkItems, do not claim them and do not assign them to the responder: `WorkItem.responder` selects execution, while Workflow runtime manages Task watching. Leave a new Task unassigned and leave a reused Task's assignee unchanged. `workItemsContract.dependencyValueContract` is the exact ArtifactContract stored in every direct dependency envelope's `value`; author every business output path relative to that contract. WorkItem keys must match `^[a-z][a-z0-9_-]{0,255}$`. In a dependent instruction, reference a direct dependency business output as `$<dependencyKey>.<businessOutputPath>`; for example, if `dependencyValueContract` declares `result` as `number`, use `$op08.result`. Bare `$key` and unknown/non-direct keys are invalid; write `$$` for a literal dollar sign. The server rejects statically provable contract errors before callback commit: an undeclared top-level field, traversal past a declared `number` or `boolean`, and a declared non-materializable leaf. A top-level `object` reference must continue to an internal field; because ArtifactContract does not describe object properties, the remaining object path and the presence of an optional field are verified by the runtime resolver before delivery. Use at most 64 references. A path has at most 8 ASCII identifier segments of 64 bytes and must not contain `__proto__`, `prototype`, or `constructor`. Workflow resolves only `number`, `boolean`, or `null` leaves, never `string`, object, or array; each scalar is limited to 8 KiB and the resolved instruction to 32 KiB. Other dependency values remain available in typed callback input. Resolution happens before delivery, so the receiving Agent does not parse references.
- For business output fields whose declared type is `scope`, use canonical scope objects rather than display targets such as `#channel` or `#t1`.
- The selector remains usable across later wakes and daemon restarts; it is not an authorization credential.