The day split by WHO CAN ACT: agent work ready now, the owner's buttons (owner_kind human, or assigned to a role declared in HUB/owner-roles.json), what is blocked and on what, overdue and due-soon. Different question from hub_brief (everything that is going on) and hub_inbox (what needs a decision): this one answers "what can I actually start", which a mixed list hides.

Compare what the hub DECLARES with what actually happened, and turn each disagreement into an incident somebody owns. Checks: a money bet whose gate date passed with no decision since · a project whose share of the journal contradicts the MODE its card declares · owner buttons nobody pressed · a card that stopped following its own journal · tasks with no project. Read-only by default; apply files one incident task per finding and writes ONE report. Every finding quotes the rule it enforces with the date that rule was written (HUB/rules.json -> laws), because an engine's opinion carries no weight and your own past decision does. Findings are keyed, so a weekly run never files the same incident twice. NOT a dashboard: the numbers it prints (attention share, close rates) are a thermometer and are never filed as violations.

Morning brief across all projects: open tasks (deadlines first), journal since N hours, stale cards, cards whose digest trails their own journal (staleDigests — the misleading kind of stale), active claims, per-role queue depth with last-seen agent (broadcast roles are flagged fanout instead of a depth — their cursors are per-reader), and a buttons rollup ("N buttons waiting, oldest X days" — pending items in a human-owner queue, see HUB/owner-roles.json). Two things wait on the owner and they are NOT the same: buttonItems = each unanswered package in an owner queue (age, sender, subject); ownerWaiting = open tasks only the owner can move, with age and how far past deadline — invisible in every "what can I start" list because the answer there is "not this". review carries the top few hub_lint + hub_audit findings, one per kind, each quoting the rule it enforces with the date that rule was written: the audit rides on this call instead of waiting to be remembered. It reports only — nothing is filed without an explicit hub_audit({apply:true}) carrying somebody's name.

Create or update a project card from just a name and a digest — no folder needed (unlike hub_sync). Use it to capture a project that is not a local git checkout, e.g. when harvesting a dialog. Preserves any hand-written frontmatter and Facts. To fix ONE stale line without touching the owner's framing, patch instead of replacing: replace: [{from, to}] and/or appendLine — a from that is not in the digest is an error, not a silent no-op.

Soft-lock a work area so other agents see it. Not enforced — informational. Write area as a path glob relative to the project root ("src/**/*.ts", "docs/{a,b}.md", "public/index.html", a bare directory) and hub_claim_check / hub_context can tell another agent that the file it opened is yours; prose is accepted but comes back matchable:false.

Before editing a file: is it inside somebody's live claim? Returns {free, holders:[{agent, area, since, note}], mine, unmatchable} — mine are your own claims covering it (pass agent), unmatchable the prose claims on the project that no path can be tested against. Pure read. The lock is soft by constitution: this informs, it does not forbid — coordinate with the holder.

Where am I — the first call of a session and the first call after a context compaction. Resolves which hub project YOUR working directory belongs to, most to least certain: a .hubd marker file (repo root, first line = project slug) · a project card's recorded sync path · the repo folder name as a last-resort guess (guessed:true, with the one-line fix in hint). Returns {project, via, root, guessed, digest, digestSetAt, digestSetBy, digestAgeDays, digestStale?, openTasks, activeClaims, presenceHere, journalTail}. digestStale is the same verdict hub_status gives — a digest can be four months behind its own journal and still read as current; presenceHere lists live heartbeats whose cwd is under this root — who else is editing this checkout right now; journalTail is the last few entries of the project, so resuming reads state, not a summary. project is null with a hint if nothing matched.

Everything about ONE project: its full card (digest + facts), recent journal entries for it, and any active soft-locks. Use after hub_status or hub_search points you at a project.

The typed relationship graph across projects AND resources: who runs where, what depends on / deploys to / exposes what. Edges are frontmatter [[links]] keyed by relation (runs_on, depends_on, deploys_to, exposes, part_of, ...). Returns nodes, edges, and dangling links. Filter by project or type.

Record that an agent is alive — call it each work cycle (right after hub_report, before the next hub_queue_wait) so MCP/headless agents show up in hub_presence the same way screen-scraped ones do, no human bridge needed. Overwrites this agent's one presence record; freshness is judged at read time from ttlMin (default 15min), the same pattern hub_claim uses. Also refreshes this node's published snapshot (presence..json) at most once every 5 minutes, so agents on OTHER nodes can see you at all — the directory itself is node-local and never syncs.

What needs a DECISION right now, distilled from hubd data (not a time window like hub_brief): blocked reports, overdue open tasks, unassigned open tasks, and claim locks whose TTL expired but were never released. Returns {empty:true} when nothing needs attention — poll this instead of re-reading hub_status/hub_brief every cycle.

The board as data: open tasks split into queued (unassigned) and in-progress (assigned), plus done-in-the-last-day and recent journal — the same view the read-only web kanban renders. Each task carries blocked and overdue flags.

Every rule that CAN be checked, checked — the difference between a rule the hub enforces and one that is only written down somewhere. Reports a money bet whose gate has no date, and a human-owned communicative task with no prep it depends on (the owner would have to both prepare and decide). Each finding says whether the instance actually enforces it (HUB/rules.json -> strict, opt-in and empty by default) and quotes the local rule if one is declared. Read-only, never files anything.

The ONE task to do now, and why it won — not a list. Picking from a list is work, and a session that has to pick tends to pick the easy one. A task whose dependencies are still open is never eligible, however loud it is. Says explicitly when the chosen one is the owner's to press rather than an agent's.

Orientation for an agent that has never worked with this hub before: which channel to use for what (claim vs task vs report vs queue — the #1 mistake), the author rule, the session ritual, how to recover after a compaction. Call this FIRST the first time you connect. Default mode "short" is under 600 words and lists the sections of the full manual; mode "full" is the whole manual (~4000 words) — the same text as HUBD.md in the hub.

The operator card: facts and preferences about the HUMAN — rhythm, what framing works, and the Boundaries section listing what is never collected. Belongs to no project and changes slower than any of them. Agents READ Boundaries and never edit it. Returns a scaffold and how to create it if there is no card yet.

The fleet roster as far as it can honestly be seen from here: this node's live registry plus every other node's published snapshot (presence..json, one small file per node, refreshed on heartbeat). Each row carries observedOn — WHICH node saw that heartbeat — and alsoOn when one agent name turns up on several. Read coverage before believing any absence: it lists every current mesh member with the age of its snapshot, or null when it has published none, and blindTo/note say so outright. That distinction is the reason this tool exists in this shape — one role read as 383 minutes since heartbeat on one node and 5.9 days on another, nothing was stale and nothing had diverged, the registries were simply of different machines, and an orchestrator escalated "worker is dead" four times over 92 hours while the worker worked. A role nobody reports is invisible, which is NOT the same as dead.

Append a message to a role's queue (queues/..queue.md) for cross-agent/cross-node handoffs. Delivered to whoever calls hub_queue_wait (or hub queue wait) for that role, here or on a mesh-synced peer node.

Block until new content lands in 's queue (this node's file plus any mesh-synced peer files for that role), then return it — a real long-poll, not a snapshot you have to re-poll. Returns {changed:false} if nothing arrives within timeout. If a delivered block names a task (see hub_queue_send), the ids come back as tasks — report the outcome onto those tasks, or the message is the only place the blocker ever existed. Local/stdio only (not available on the shared HTTP server). Use this instead of a sleep-and-recheck loop when waiting on an agent to report back via hub_queue_send.

Subscribe to EVERY role's queue at once and block until new content lands in ANY of them — for an orchestrator reacting to whichever agent reports first, instead of calling hub_queue_wait per role or ssh-ing into each host to poll. Returns {changed:true, events:[{role,node,text}, ...]} tagging which role/node each event came from, or {changed:false} on timeout. Uses its own offset bookkeeping — does NOT consume/steal messages from a role's own hub_queue_wait consumer, it only taps. Local/stdio only.

What do we know about X — ranked across project cards, their sections, decisions, the journal and tasks, instead of hub_search's flat exact-substring list or hub_get's everything-about-one-project. Scoring is deterministic and readable: term coverage first, then where the line lives (a decision outranks a passing note), then recency. EVERY hit carries the date it was true as of and a stale flag — recall's real failure mode is handing over a two-month-old fact with this morning's confidence.

Release a soft-lock. Pass id, or project+area+agent.

Append a session report to the shared journal: what was done / broken / blocked.

One resource card plus its inbound and outbound typed relationships.

List resource cards (hosts, vms, services, endpoints, providers). Optionally filter by type.

Create or update a resource — an infrastructure/topology entity: host, vm, service, endpoint, or provider. Structured attributes (type, address, os, provider, status) and typed relationships go in fields, NOT prose. Use this instead of describing infra inside a card digest.

The team constitution (AGENTS.md) over MCP: read it, or append an amendment. hubd mechanics live in the generated HUBD.md — this is the file where the rules YOU set live. An amendment is APPENDED under one dated, attributed heading and never edits a line already there: rewriting a rule destroys the record of what it used to say, which is exactly what hub_audit needs to quote.

Full-text search across every project card and the entire journal, archived months included. Returns each matching line with its location. START HERE whenever you know a keyword, a task id or a name but not which project owns it — searching once beats guessing project × status against hub_task_list, which is how sessions have actually wasted calls. Also the way to find where something was discussed or decided.

Append ONE line to ONE section of a project card, leaving everything around it untouched. This is how Gates / Metrics / Market and any hand-written section get written by a tool at all — hub_card_set only writes the digest, and the report router only reaches Decisions / Facts / Communication / Next step. For those four, a normal hub_report with DECIDE:/FACT:/COMM:/NEXT: is still the right call; use this for the rest. The section is created if missing (you get created:true back — check it, a typo is how a card grows two nearly identical headings).

Snapshot of every project at once: the latest digest of each, when it was last synced, and its open-task count, plus the most recent shared-journal entries. A project whose card has fallen behind its OWN journal carries digestStale {daysBehind, lastJournal} — the card still reads fresh while the work moved on. Best for orienting at the start of a session. For a deadline-sorted to-do list use hub_brief; for one project in depth use hub_get.

Sync a project folder into the hub. Collects git facts automatically; pass digest (your own summary of state/next steps) and the card is rewritten.

Add a task to the shared cross-project backlog.

ONE task by id, plus what it is blocked by and what it blocks. Use this when you know the id — do NOT go guessing project × status combinations with hub_task_list. Know a keyword but not the id? hub_search first.

List backlog tasks. Filter by project and/or status; page with limit/offset. total is always the full matching count, so a page never reads as the whole backlog. Looking for ONE task you can name? hub_task_get by id, or hub_search by keyword — both beat listing and scanning.

Update a task: close it (status=done), reassign, reprioritise, edit text/deadline/cat.

Deterministic dependency-graph plan over tasks' depends_on — the probable trajectory as a critical PATH, not an ML forecast. Returns: ready (doable now, no open deps), blocked (with waitingOn ids), layers (Kahn topo-order — what unlocks when), criticalPath (longest dependency chain = ordering bound), cycles (dependency loops to fix). Use to see "given deps, what is the actual order / what is the critical path to a milestone". Weight is task-count now; weighted by real durations once logd records them.

What the work cost, over a window, per project and per agent — with a hard line between SUPPLIED (seconds/tokens/money, reported by clients through hub_usage_add, since the hub cannot see them) and MEASURED (closed-task spans and journal events, the hub's own arithmetic). The split is the point: a cost number that mixes an observed span with a guessed rate gets quoted later as if someone had counted.

Record what only YOU can see about a piece of work: seconds, tokens, cost, model. The hub cannot observe any of these, so they arrive here explicitly and are reported back as SUPPLIED, never mixed with what the hub measured itself. At least one number is required — an empty entry would record a $0 session.

Personalized "what did I miss" — journal activity since YOUR OWN last hub_whatsnew call (tracked per agent name), not a fixed time window like hub_brief. Call this at the start of a session/sweep instead of re-reading hub_status/hub_brief from scratch; a never-seen agent gets a 24h window on its first call. Also carries review: the top few hub_lint + hub_audit findings, one per kind, each quoting the rule it enforces and the date that rule was written — read-only, files nothing.