workgraph-workflowlisted

# WorkGraph Workflow Use WorkGraph when work must survive sessions, compaction, restarts, schedules, or coordination between agents. It is the shared commitment graph, not private scratch space and not semantic memory. ## Operating Rules - Use `workgraph_create` for a new durable commitment. Keep related work in the same host-granted namespace. Omitting `namespace` uses the namespace bound by the host's grant; it is `default` only when that is the granted namespace. The grant authorizes one immutable realm/namespace scope. Supplying another namespace string does not switch scope — it is rejected. - Use `workgraph_ready` to find eligible work. Do not infer readiness from item fields, blocker counts, due times, or edges yourself. - Claim an item before doing durable or shared work with `workgraph_claim`. Include your typed owner and the current `expected_revision`. Set `lease_seconds` for a lease, or omit it for no expiry. The tool computes expiry from the store's claim observation time. - If a write fails with a stale revision, reload the item with `workgraph_get` or `workgraph_snapshot`, reconsider the current state, then retry only if the work still makes sense. - Every successful mutation advances the item revision. Use the returned item, not an older cached revision, for the next claim, update, evidence, release, block, or close operation. - Use `workgraph_link` for real dependencies and relationships. Edges are permanent; there is no unlink. U