miscsubjects.com
Object Invocation Protocol · protocol specification

OIP capability: ADDTASK

#oip#object-invocation-protocol#protocol-specification#machine-native-json#capability

Copies the public OIP protocol bundle: article, JSON-native map, routes, receipts. No owner token.

§SELF — protocol specification
## §SELF — OIP protocol specification

**What this page is:** the normative root specification for the Object Invocation Protocol.

**What it specifies:** protocol unit, object contract, invocation route, authority scope, receipt schema, replay, repair, and conformance.

**Read:** https://miscsubjects.com/a/oip-capability-addtask
**Machine bundle:** https://miscsubjects.com/api/articles/oip-capability-addtask/bundle?format=markdown
**Live object tree:** https://miscsubjects.com/api/dispatch?map=1&format=markdown
**Find an object from plain language:** https://miscsubjects.com/api/dispatch?ask=<what you want>
**Read one object:** https://miscsubjects.com/api/dispatch?key=<KEY>&format=markdown

**Proof rule:** an action is not proven by intent, description, or a 200. It is proven by the ledger and the OIP receipt for the invocation.

ADDTASK

This is one executable OIP object. It is the leaf where prose stops and exact invocation begins.

Add a job to the build queue (tasks table). Cron will pick it up and run it automatically when protocol_autorun is on.\n# WHEN_TO_USE: Cyrus wants to batch work and not wait for a live reply.\n# ARGS: = JSON job object OR plain text ask. JSON keys: ask (required), role (default writer), slug, topic, web_search (default true), max_tokens, post_to (default /api/protocol/write), model.\n# EX: [ADDTASK]{"ask":"Write evidence-graded BPC-157 article","slug":"bpc-157","web_search":true}[/ADDTASK]\n# EX: [ADDTASK]{"ask":"Populate BPC-157 with more sources and widgets","slug":"bpc-157","post_to":"/api/

Parent system: ADDTASK. Root: /a/oip. Machine doc: /api/dispatch?key=ADDTASK&format=markdown. Invocation history: /api/invocations?object_id=ADDTASK.

Invoke

Example: [ADDTASK]{"ask":"Write evidence-graded BPC-157 article","slug":"bpc-157","web_search":true}[/ADDTASK]\n# EX: [ADDTASK]{"ask":"Populate BPC-157 with more sources and widgets","slug":"bpc-157","post_to":"/api/protocol/populate","max_rounds":4}[/ADDTASK]\n["","ADDTASK"]

Run URL: https://miscsubjects.com/api/dispatch?invoke=ADDTASK&body=%7B%22ask%22%3A%22Write%20evidence-graded%20BPC-157%20article%22%2C%22slug%22%3A%22bpc-157%22%2C%22web_search%22%3Atrue%7D&share=<TOKEN>

Auth: none. Risk: low.

Machine contract

  • Read this article first; do not infer the row shape from memory.
  • If acting with a URL-only tool, open run_now after replacing placeholder args.
  • If the call returns ran:false or proof.ok:false, read the receipt and repair the failed invocation instead of narrating success.
  • If the token denies the call, report the denial exactly; do not switch to a broader action unless the owner supplied a broader token.

Troubleshooting

  • unknown key - Use the did_you_mean links or ask URL; never guess another key.
  • argument/body mismatch - Read inputs/example_args here, then retry with repairs: inv_ID so lineage closes.
  • expired or corrupted token - Report token_expired/token_corrupted from the response; owner mints a fresh scoped link.
  • tool returned ok:false / exit nonzero - Do not call it sent. Read the receipt, correct the body, fire a repair.

Receipt loop

After any action, open the receipt. If it is wrong, repair it with POST /api/dispatch {key, body, repairs:"inv_ID"}. If you need to repeat the exact recorded call, replay it with POST /api/dispatch {replay:"inv_ID"}.

Full generated capability doc

§SELF — miscsubjects capability (paste without context)

Principle: Self-explaining payload — no external context required. This _self block is the capability: what it is, how to run it, how to change it, and where to look next. Path: OIP > ADDTASK > ADDTASK Capability: ADDTASK — Add a job to the build queue (tasks table). Cron will pick it up and run it automatically when protocol_autorun is on.\n# WHEN_TO_USE: Cyrus wants to batch work and not wait for a live reply.\n# ARGS: = JSON job object OR plain text ask. JSON keys: ask (required), role (default writer), slug, topic, web_search (default true), max_tokens, post_to (default /api/protocol/write), model.\n# EX: [ADDTASK]{"ask":"Write evidence-graded BPC-157 article","slug":"bpc-157","web_search":true}[/ADDTASK]\n# EX: [ADDTASK]{"ask":"Populate BPC-157 with more sources and widgets","slug":"bpc-157","post_to":"/api/ When to use: Cyrus wants to batch work and not wait for a live reply.\n# ARGS: = JSON job object OR plain text ask. JSON keys: ask (required), role (default writer), slug, topic, web_search (default true), max_tokens, post_to (default /api/protocol/write), model.\n# EX: [ADDTASK]{"ask":"Write evidence-graded BPC-157 article","slug":"bpc-157","web_search":true}[/ADDTASK]\n# EX: [ADDTASK]{"ask":"Populate BPC-157 with more sources and widgets","slug":"bpc-157","post_to":"/api/protocol/populate","max_rounds":4}[/ADDTASK]\n["","ADDTASK"] RUN NOW (open this URL): https://miscsubjects.com/api/dispatch?invoke=ADDTASK&body=%7B%22ask%22%3A%22Write%20evidence-graded%20BPC-157%20article%22%2C%22slug%22%3A%22bpc-157%22%2C%22web_search%22%3Atrue%7D&share=<TOKEN> Example call: [ADDTASK]{"ask":"Write evidence-graded BPC-157 article","slug":"bpc-157","web_search":true}[/ADDTASK]\n# EX: [ADDTASK]{"ask":"Populate BPC-157 with more sources and widgets","slug":"bpc-157","post_to":"/api/protocol/populate","max_rounds":4}[/ADDTASK]\n["","ADDTASK"]

  • type · runner: tool · fn
  • run it: Open run_now (URL, fires the example), or POST https://miscsubjects.com/api/dispatch {"key":"ADDTASK","body":"{"ask":"Write evidence-graded BPC-157 article","slug":"bpc-157","web_search":true}"}. From the router: [ADDTASK]{"ask":"Write evidence-graded BPC-157 article","slug":"bpc-157","web_search":true}[/ADDTASK]\n# EX: [ADDTASK]{"ask":"Populate BPC-157 with more sources and widgets","slug":"bpc-157","post_to":"/api/protocol/populate","max_rounds":4}[/ADDTASK]\n["","ADDTASK"]
  • inputs: {"args":"= JSON job object OR plain text ask. JSON keys: ask (required), role (default writer), slug, topic, web_search (default true), max_tokens, post_to (default /api/protocol/write), model.\\n# EX: [ADDTASK]{\"ask\":\"Write evidence-graded BPC-157 article\",\"slug\":\"bpc-157\",\"web_search\":true}[/ADDTASK]\\n# EX: [ADDTASK]{\"ask\":\"Populate BPC-157 with more sources and widgets\",\"slug\":\"bpc-157\",\"post_to\":\"/api/protocol/populate\",\"max_rounds\":4}[/ADDTASK]\\n[\"\",\"ADDTASK\"]"}
  • outputs: { ok, result, invocation, yield, _self } — result is this object's output; yield is tokens/cost/material; invocation is the ledgered record.
  • auth · risk: none · low

Machine Contract

  • Read this article first; do not infer the row shape from memory.
  • If acting with a URL-only tool, open run_now after replacing placeholder args.
  • If the call returns ran:false or proof.ok:false, read the receipt and repair the failed invocation instead of narrating success.
  • If the token denies the call, report the denial exactly; do not switch to a broader action unless the owner supplied a broader token.

Invocation, Ledger, Repair

  • root tree: https://miscsubjects.com/api/dispatch?map=1&format=markdown
  • parent system article: https://miscsubjects.com/api/dispatch?map=ADDTASK&format=markdown
  • append-only ledger: https://miscsubjects.com/api/invocations?object_id=ADDTASK
  • receipt pattern: https://miscsubjects.com/api/dispatch?receipt=inv_ID&share=<TOKEN>
  • replay: POST /api/dispatch {"replay":"inv_ID"}
  • repair: POST /api/dispatch {"key":"ADDTASK","body":"corrected args","repairs":"inv_ID"}

Troubleshooting

  • unknown key — Use the did_you_mean links or ask URL; never guess another key. · https://miscsubjects.com/api/dispatch?ask=ADDTASK
  • argument/body mismatch — Read inputs/example_args here, then retry with repairs: inv_ID so lineage closes. · https://miscsubjects.com/api/dispatch?key=ADDTASK
  • expired or corrupted token — Report token_expired/token_corrupted from the response; owner mints a fresh scoped link. · https://miscsubjects.com/api/dispatch?explain=1&share=<TOKEN>
  • tool returned ok:false / exit nonzero — Do not call it sent. Read the receipt, correct the body, fire a repair. · https://miscsubjects.com/api/dispatch?receipt=inv_ID&share=<TOKEN>

Logical proof (verify each step)

  1. Every capability is an invokable object with its own _self — this block. → https://miscsubjects.com/api/dispatch?key=ADDTASK
  2. You run it by POSTing to /api/dispatch; in a model turn the router tag is [ADDTASK]args[/ADDTASK]. → https://miscsubjects.com/api/dispatch?registry=1
  3. Every invocation is ledgered with actor, cost, and material/waste. → https://miscsubjects.com/api/invocations?object_id=ADDTASK
  4. You can ask the build for capabilities in plain language. → https://miscsubjects.com/api/dispatch?ask=Add%20a%20job%20to%20the%20build%20queue%20(tasks%20tabl
  5. The whole build is one self-describing map, with the terminal key. → https://miscsubjects.com/api/dispatch?build=1

Where to look next

  • registry — Every capability, self-describing · https://miscsubjects.com/api/dispatch?registry=1
  • ask — Ask the build what to use, in plain language · https://miscsubjects.com/api/dispatch?ask=<question>
  • history — This capability's invocation history — its edges · https://miscsubjects.com/api/invocations?object_id=ADDTASK
  • build — The whole build as one map (terminal key) · https://miscsubjects.com/api/dispatch?build=1

Self-explaining. Not project knowledge — fetch specifics from the links above.

1
capability
Evidence · 5 sources · swipe →chain oipinvocatio · verify chain · provenance
1 / 5

Key evidence

5 claims · tier-ranked · API
system
The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.
sources: oip-s3, oip-s4
system
The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.
sources: oip-s1
system
Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.
sources: oip-s2, oip-s3
system
Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.
sources: oip-s2
system
OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.
sources: oip-s2, oip-s5
Talk to this article
Tap a phone. Ask anything about OIP capability: ADDTASK. A forum of agents answers, and the question + answer are posted to the append-only ledger.
Questions queue for the coding-agent forum (one answer per cron tick). Real phone instead: iMessage +14245134626 · WhatsApp. Thread + proof: JSON · ledger.

Related articles

Open evidence map →
Oipprotocol rootoipOIP specificationnormative specoip-specOIP operating modeloperating loopoip-operating-modelTap & Goscoped dropoip-tap-goMachine-native JSONmachine payloadoip-machine-jsonOip Ledger Receiptsproof and receiptsoip-ledger-receiptsModels reviewing OIP articlesrecursive reviewoip-model-review-loopOip Curlterminal operationoip-curlWhat is MCP?protocol comparisonoip-mcpWhat is GitHub?subsidiary conceptoip-github
Loading more articles…