tasks:announce
tasks family
Announce a task into the world by its tags — the first caller of world:announce
- Effect
- ask
- Awaits an outcome — the call returns the response below.
- Reversible
- yes
- The effect can be undone by a later call.
tasks family
Announce a task into the world by its tags — the first caller of world:announce
One click hands your coding agent a prompt that registers the substrate, reads this contract, and makes the call. Launch opens the app; the others copy the prompt.
curl -X POST https://one.ie/api/ask/tasks:announce \
-H "Authorization: Bearer $ONE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"data": { "taskId": <string>, "tags": <string[]> }}'The key is never in a link. npx -y @oneie/cli login writes it to ~/.config/oneie/key on your machine.
Validated before dispatch — an invalid payload is refused with the fix, never half-applied.
taskId string required tags string[] required board "marketplace" optional slug string optional workspace string optional title string optional meta object optional What comes back from the call.
ok boolean taskId string matched number REACH, NEVER DELIVERY. This is `actors.length` from the fan-out (`resolvers/subscriptions.ts:1245`) — how many staked actors the tags MATCHED, not how many received it, read it, or acted on it. Each matched actor got an inbox row; whether any of them moved the task is one `tasks:claim` away and this number cannot see it. A digest that quotes this as 'N people are on it' is reporting a fan-out as a delivery. actors string[] The actor ids the fan-out reached — the same reach `matched` counts, itemised. Reaching is not acting. Every call to tasks:announce, counted where it is dispatched — over HTTP or in-process alike. Aggregate only — no actor, no payload, no workspace.
Counting…
Every place in the open source that names tasks:announce, and the file that
answers it. Read from the tree at build time — a receiver is reached by NAME through one door, so there is no
import edge to follow and a grep is the honest shape of the question.
Structure, not volume — the count is in Traffic above.
Called from
Answered by
POST /api/ask/tasks:announce, after the envelope
validates the payload.
tasks family · 26 more
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"taskId": {
"type": "string"
},
"tags": {
"type": "array",
"items": {
"type": "string"
}
},
"board": {
"type": "string",
"const": "marketplace"
},
"slug": {
"type": "string"
},
"workspace": {
"type": "string"
},
"title": {
"type": "string"
},
"meta": {
"type": "object",
"propertyNames": {
"type": "string"
},
"additionalProperties": {}
}
},
"required": [
"taskId",
"tags"
]
} {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"ok": {
"type": "boolean"
},
"taskId": {
"type": "string"
},
"matched": {
"description": "REACH, NEVER DELIVERY. This is `actors.length` from the fan-out (`resolvers/subscriptions.ts:1245`) — how many staked actors the tags MATCHED, not how many received it, read it, or acted on it. Each matched actor got an inbox row; whether any of them moved the task is one `tasks:claim` away and this number cannot see it. A digest that quotes this as 'N people are on it' is reporting a fan-out as a delivery.",
"type": "number"
},
"actors": {
"description": "The actor ids the fan-out reached — the same reach `matched` counts, itemised. Reaching is not acting.",
"type": "array",
"items": {
"type": "string"
}
}
},
"required": [
"ok"
]
}