@agentistics/mcp 2.201.1 → 2.202.0

package/dist/agentistics-mcp.js

@@ -2,6 +2,7 @@
 
 // live-delivery-args.ts
 var LIVE_STAGES = ["queue", "running", "qa", "adjust", "leader", "merge", "published"];
+var LIVE_SORTS = ["priority", "time-in-stage", "recent"];
 function liveDeliveryQuery(a) {
   const q = new URLSearchParams;
   const task = typeof a?.task === "string" ? a.task.trim() : "";
@@ -11,6 +12,12 @@ function liveDeliveryQuery(a) {
     q.set("stage", a.stage);
   if (a?.stalledOnly === true)
     q.set("stalled", "1");
+  if (a?.onlyActive === false)
+    q.set("onlyActive", "0");
+  if (a?.showQueue === false)
+    q.set("showQueue", "0");
+  if (typeof a?.sort === "string" && LIVE_SORTS.includes(a.sort))
+    q.set("sort", a.sort);
   return q.toString() ? `?${q}` : "";
 }
 
@@ -997,8 +1004,8 @@ var AGENT_TOOL_POLICY = {
   agentistics_task_phase: {
     ...TASKS,
     risk: "W",
-    routes: ["GET /api/deliveries", "GET /api/deliveries/:subtask", "POST /api/deliveries/:subtask"],
-    reason: "reads or moves a delivery through the fixed phase table; a skipped phase is refused (422 fase_pulada) and every gate is checked by the host from evidence, never from the caller"
+    routes: ["GET /api/deliveries", "GET /api/deliveries/:subtask", "POST /api/deliveries/:subtask", "POST /api/deliveries/release"],
+    reason: "reads or moves a delivery through the fixed phase table; release declares which pieces a release shipped (leader/owner only; the host still reads the green run and the tag); a skipped phase is refused (422 fase_pulada) and every gate is checked by the host from evidence, never from the caller"
   },
   agentistics_task_stage: {
     ...TASKS,
@@ -1006,6 +1013,18 @@ var AGENT_TOOL_POLICY = {
     routes: ["POST /api/deliveries/:subtask"],
     reason: "writes the pre-dispatch (staged session draft) on a subtask and opens its delivery in the queue; nothing starts until stage-run passes the predispatch and vaga gates"
   },
+  agentistics_task_queue: {
+    ...TASKS,
+    risk: "R",
+    routes: ["GET /api/deliveries/queue/:task"],
+    reason: "reads the delivery queue in leaving order with every fact the Fila tab shows (priority, pre-dispatch, slot verdict, hold, open question, notes); read only"
+  },
+  agentistics_task_queue_answer: {
+    ...TASKS,
+    risk: "W",
+    routes: ["POST /api/deliveries/:subtask", "POST /api/deliveries/queue-next"],
+    reason: "answers the queue question (sim opens the session through the same claim-guarded stage run; nao/agendar keep the piece queued with a recorded reason); leader of the task or owner only, every decision is a comment on the subtask"
+  },
   agentistics_wait: {
     ...GROUPS,
     risk: "W",
@@ -1059,6 +1078,12 @@ var AGENT_TOOL_POLICY = {
   agentistics_export_pdf: { ...DATA, risk: "R", routes: [], reason: "composes a local dashboard URL; calls nothing and exports nothing itself" },
   agentistics_tags: { ...DATA, risk: "R", routes: ["GET /api/tags"], reason: "reads aggregate-only tag cards" },
   agentistics_tag_detail: { ...DATA, risk: "R", routes: ["GET /api/tags", "GET /api/tags/:id"], reason: "reads one tag aggregate (counts and sums only)" },
+  agentistics_vault_status: {
+    ...TASKS,
+    risk: "R",
+    routes: ["GET /api/vault"],
+    reason: "reads how the vault is protected (state, ways to confirm in use and offered, password rules) through an allowlist; never an item, a key id or a secret"
+  },
   agentistics_flow_run: { ...DATA, capability: "localShell", host: true, risk: "R", routes: ["POST /api/flows/run"], reason: "runs only the built-in deterministic flow gates; it deletes nothing" },
   agentistics_flow_status: { ...DATA, capability: "localShell", host: true, risk: "R", routes: ["GET /api/flows/status/:runId"], reason: "reads a durable deterministic flow run" }
 };
@@ -1182,6 +1207,21 @@ var GO_WINDOW_MS = {
 function isFlowRunId(id) {
   return /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/.test(id);
 }
+// ../core/src/vaultPassword.ts
+var VAULT_PASSWORD_RULES = ["length", "upper", "special", "digit"];
+var VAULT_PASSWORD_MIN_LENGTH = 9;
+var VAULT_PASSWORD_MIN_SPECIAL = 2;
+var VAULT_PASSWORD_RULE_TEXT = {
+  length: { en: `At least ${VAULT_PASSWORD_MIN_LENGTH} characters`, pt: `Pelo menos ${VAULT_PASSWORD_MIN_LENGTH} caracteres` },
+  upper: { en: "At least 1 uppercase letter", pt: "Pelo menos 1 letra maiúscula" },
+  special: { en: `At least ${VAULT_PASSWORD_MIN_SPECIAL} special characters (like ! @ # $)`, pt: `Pelo menos ${VAULT_PASSWORD_MIN_SPECIAL} caracteres especiais (como ! @ # $)` },
+  digit: { en: "At least 1 number", pt: "Pelo menos 1 número" }
+};
+var UPPER = "ABCDEFGHJKLMNPQRSTUVWXYZ";
+var LOWER = "abcdefghijkmnopqrstuvwxyz";
+var DIGITS = "23456789";
+var SPECIALS = "!@#$%&*+-=?_";
+var ALL = UPPER + LOWER + DIGITS + SPECIALS;
 // flow-status.ts
 function flowStatusRunId(runId) {
   if (!isFlowRunId(runId))
@@ -1682,6 +1722,34 @@ function harnessesTool(rows, body) {
   return rows.map((row) => ({ ...row, ...body.harnesses?.[row.harness] }));
 }
 
+// vault-tool.ts
+var PRESENCE = new Set(["touchid", "hello", "password", "fido2"]);
+var rules = () => ({
+  minLength: VAULT_PASSWORD_MIN_LENGTH,
+  minSpecial: VAULT_PASSWORD_MIN_SPECIAL,
+  rules: VAULT_PASSWORD_RULES.map((id) => ({ id, ...VAULT_PASSWORD_RULE_TEXT[id] }))
+});
+function vaultStatusTool(body) {
+  const b = body && typeof body === "object" ? body : {};
+  const v = b.view && typeof b.view === "object" ? b.view : b;
+  const wrappers = Array.isArray(v.wrappers) ? v.wrappers.filter((w) => typeof w === "string") : [];
+  const offered = Array.isArray(v.unlockMethods) ? v.unlockMethods.flatMap((m) => {
+    const o = m && typeof m === "object" ? m : {};
+    return typeof o.id === "string" && PRESENCE.has(o.id) ? [{ id: o.id, advanced: o.advanced === true }] : [];
+  }) : [];
+  const state = typeof v.state === "string" ? v.state : typeof b.state === "string" ? b.state : "unknown";
+  return {
+    state,
+    confirmsWith: wrappers.filter((w) => PRESENCE.has(w)),
+    offered,
+    legacyAppCode: v.legacyAppCode === true,
+    recoveryKey: typeof v.recoveryCreatedAt === "string" && v.recoveryCreatedAt.length > 0,
+    autoLockMinutes: typeof v.autoLockMinutes === "number" ? v.autoLockMinutes : null,
+    passwordRules: rules(),
+    note: "Setting up, unlocking and confirming are done by the person on the /vault page or with `agentop vault`; an agent never handles the vault password or the 24 words."
+  };
+}
+
 // legacy-analytics.ts
 function legacySummary(data, harness) {
   const unified = !harness || harness === "all";
@@ -2290,7 +2358,7 @@ var TOOLS = [
   },
   {
     name: "agentistics_task_subtask",
-    description: "Add a subtask, or change one. Pass `title` to add; pass `id` with `done`, `status`, `dueDate`, `startDate`, `blockedBy` or `parentGroupId` to edit one. `startedAt`/`deliveredAt` are system-stamped facts (when real work began / when this piece reached `done`) and are never set through this tool — they are read back on the subtask record. A subtask carries the same columns its parent does; its own cost, tokens, rounds and harness are rolled up from the sessions filed under it — the PARENT task's rollup is the sum of all its subtasks' sessions. A subtask CAN be blocked by another subtask of the SAME parent (pass `blockedBy` as the full list of sibling subtask ids that must be `done` first; a sibling outside this task, or the subtask itself, is dropped rather than accepted) — this is separate from agentistics_task_blocked_by, which blocks a whole TASK on other tasks. **`done` REQUIRES the subtask to have at least one session filed under it** and is refused (422, `done_needs_session`) without one — EXCEPT for a group MEMBER (`parentGroupId` set), which can never hold a session of its own (see below) and therefore reaches `done` through this same edit with no session required; a GROUP itself (`isGroup: true`) and an ordinary loose subtask both still need one. **The moment every one of a task's top-level subtasks (loose subtasks and groups — a group's own members never count separately) reaches `done`, the parent task auto-delivers too.** To put a session ON a subtask use agentistics_task_session with `subtaskId` — a subtask holds ANY NUMBER of sessions, so the link lives on the session, not in a field here. **SUBTASK GROUPS are a real hierarchy level, not a label**: pass `isGroup: true` with `title` to create a GROUP — a peer row that CAN hold a session, exactly like a loose subtask. Pass `id` (a subtask) with `parentGroupId` (a group's own subtask id, from the SAME parent task) to make it a MEMBER of that group — join with the group's id, leave with `parentGroupId: ''`. A refused reference (the id names no subtask, names one that is not `isGroup: true`, names a different task, or the subtask being patched is itself a group) is refused as `invalid_group` (422). **Joining a group is ALSO refused (422, `subtask_has_sessions`) when the subtask already has a session filed on it** — a member gets no rollup bucket of its own, so that session's cost would silently drop out of every visible breakdown while the task's own total kept counting it; detach the session first. **A MEMBER can never hold a session of its own** — filing on one is refused by agentistics_task_session with `subtask_in_group` (422); only the group itself accounts for a session, and a member's own status/dates/comments still exist and feed the group's progress percentage.",
+    description: "Joining a staged subtask to a group folds its queued delivery and brief into the group, keeping one queue card and an audit reason. " + "Add a subtask, or change one. Pass `title` to add; pass `id` with `done`, `status`, `dueDate`, `startDate`, `blockedBy` or `parentGroupId` to edit one. `startedAt`/`deliveredAt` are system-stamped facts (when real work began / when this piece reached `done`) and are never set through this tool — they are read back on the subtask record. A subtask carries the same columns its parent does; its own cost, tokens, rounds and harness are rolled up from the sessions filed under it — the PARENT task's rollup is the sum of all its subtasks' sessions. A subtask CAN be blocked by another subtask of the SAME parent (pass `blockedBy` as the full list of sibling subtask ids that must be `done` first; a sibling outside this task, or the subtask itself, is dropped rather than accepted) — this is separate from agentistics_task_blocked_by, which blocks a whole TASK on other tasks. **`done` REQUIRES the subtask to have at least one session filed under it** and is refused (422, `done_needs_session`) without one — EXCEPT for a group MEMBER (`parentGroupId` set), which can never hold a session of its own (see below) and therefore reaches `done` through this same edit with no session required; a GROUP itself (`isGroup: true`) and an ordinary loose subtask both still need one. **The moment every one of a task's top-level subtasks (loose subtasks and groups — a group's own members never count separately) reaches `done`, the parent task auto-delivers too.** To put a session ON a subtask use agentistics_task_session with `subtaskId` — a subtask holds ANY NUMBER of sessions, so the link lives on the session, not in a field here. **SUBTASK GROUPS are a real hierarchy level, not a label**: pass `isGroup: true` with `title` to create a GROUP — a peer row that CAN hold a session, exactly like a loose subtask. Pass `id` (a subtask) with `parentGroupId` (a group's own subtask id, from the SAME parent task) to make it a MEMBER of that group — join with the group's id, leave with `parentGroupId: ''`. A refused reference (the id names no subtask, names one that is not `isGroup: true`, names a different task, or the subtask being patched is itself a group) is refused as `invalid_group` (422). **Joining a group is ALSO refused (422, `subtask_has_sessions`) when the subtask already has a session filed on it** — a member gets no rollup bucket of its own, so that session's cost would silently drop out of every visible breakdown while the task's own total kept counting it; detach the session first. **A MEMBER can never hold a session of its own** — filing on one is refused by agentistics_task_session with `subtask_in_group` (422); only the group itself accounts for a session, and a member's own status/dates/comments still exist and feed the group's progress percentage.",
     inputSchema: {
       type: "object",
       properties: {
@@ -2389,13 +2457,16 @@ var TOOLS = [
   },
   {
     name: "agentistics_live_delivery",
-    description: 'What is being DELIVERED right now — the Live Delivery line, the same source as the screen. Use it to answer "what is running", "when does X ship" and "is anything stalled". Returns a `summary` (active deliveries, agents working, stalled, the next delivery with an estimate), the active `deliveries` with their stage (queue, running, qa, adjust, leader, merge, published), the agents on each (harness, model, account, live state), time in the stage and in total, the ETA with its source and confidence (`kind: none` means there is NO estimate — say so, never invent a time), the last action, and the `leaders` band (each leader\'s current action, its workers and what waits on a decision — leaders are never deliveries). Filters: `task` (id or part of the title), `stage`, `stalledOnly`.',
+    description: 'What is being DELIVERED right now — the Live Delivery line, the same source as the screen. Use it to answer "what is running", "when does X ship" and "is anything stalled". Returns a `summary` (active deliveries, agents working, stalled, the next delivery with an estimate), the active `deliveries` with their stage (queue, running, qa, adjust, leader, merge, published), the agents on each (harness, model, account, live state), time in the stage and in total, the step inside the stage (`step`, with `stepSource` = `reported` or `signals` and `stepSignal` naming the observed fact — null `step` means nothing is observable, say so; the screen then draws no percent), the ETA with its source and confidence (`kind: none` means there is NO estimate — say so, never invent a time), the last action, and the `leaders` band (each leader\'s current action, its workers and what waits on a decision — leaders are never deliveries). Each delivery carries its Agentask `priority` (urgent | high | medium | low; a subtask inherits its task\'s). Filters: `task` (id or part of the title), `stage`, `stalledOnly`, and the screen\'s own switches — `onlyActive` (the stages after the queue; default true) and `showQueue` (the Na fila column; default true), pass false to turn one off — plus `sort` (how each stage lists its cards; default `priority`, highest first, ties by longest in the stage). Stage names on screen: queue = Na fila, running = Em desenvolvimento, qa = QA. `history` is the screen\'s Histórico column: pieces published more than 24 h ago (up to 30 days, newest first, same `task` filter, no live agents) — Publicado keeps a card for 24 h and then it moves there.',
     inputSchema: {
       type: "object",
       properties: {
         task: { type: "string", description: "A task id or part of its title." },
         stage: { type: "string", enum: ["queue", "running", "qa", "adjust", "leader", "merge", "published"] },
-        stalledOnly: { type: "boolean", description: "Only deliveries that need a person, lost an agent or are blocked." }
+        stalledOnly: { type: "boolean", description: "Only deliveries that need a person, lost an agent or are blocked." },
+        onlyActive: { type: "boolean", description: `The screen's "apenas ativas": the cards of the stages after the queue. Default true; false hides them.` },
+        showQueue: { type: "boolean", description: `The screen's "exibir itens na fila": the cards of the Na fila column. Default true; false hides them.` },
+        sort: { type: "string", enum: ["priority", "time-in-stage", "recent"], description: "Order within each stage. Default priority (highest first, ties by longest in the stage)." }
       },
       required: []
     }
@@ -2458,12 +2529,16 @@ var TOOLS = [
   },
   {
     name: "agentistics_task_phase",
-    description: "FLUXO.ENTREGA-DSL — read or move a DELIVERY (one subtask) through its fixed phases: fila → executando → qa → (ajuste ⇄ qa) → revisao_lider → pr_merge → ci → publicado, plus bloqueado (from any phase, back to the stored origin only). Any transition outside that table is REFUSED (422 `fase_pulada`) with a sentence naming what is missing — executando → revisao_lider, ajuste → revisao_lider and every other skip included. The gates each edge needs are run BY THE SERVER from evidence (predispatch, vaga, salvo = sha on origin per ls-remote, qa-modelo = QA model ≠ author model from the registry and never Sonnet over Sonnet, cabeca = the pushed branch is still at the sha QA tested, delecoes = no file deleted outright by the PR, mergeado = gh says the PR is MERGED, the merge commit is on origin/main and the PR head is the sha QA approved — the merge sha is READ FROM THE PR, never from you, release = release.yml green for the merge sha AND the batch's tag exists); salvo needs every check run on the pushed head to have concluded green (pending or absent refuse); you never pass proof. `action`: `get` (default; omit `subtaskId` to list every delivery) | `phase` (`to` + what that edge reads: `verdict` APROVADO/REPROVADO + `findings` from qa, `reviewedSha` = the sha QA approved for revisao_lider → pr_merge, `detail` for a request for change or a failure reason) | `gate` (`name`: run ONE gate and record its evidence) | `block` (`reason` one of dependencia, pedido_de_bloqueio, limite, maquina, externo, fora_das_autorizacoes; `text`) | `unblock` (`detail`; the leader of the task or the owner — an owner-decision block only the owner) | `step` (`step` 1..9: the step of the current phase, for the Live %) | `configure` (the LEADER of the task or the owner only; `patch`: versionTarget, humanGates [phases needing the owner's approval — skipped and recorded as 'pulado: modo autônomo' while autonomous mode is on], leaderSessionId, pr, tag, allowDeletions {paths, reason}; the QA and author sessions are never settable — the host records them from the sessions it opened and the registry) | `approve` (`phase`, `decision` approve|reject, `note`: answers a human gate the owner was ASKED about; a session identity is deliberately not sent, the owner answers through this same door as the Live card button and `agentop flow approve`) | `stage-run` (predispatch + vaga gates, then start the staged session and move to executando) | `merge` (delecoes gate, squash-merge the PR, move to ci; a failure goes back to revisao_lider). In autonomous mode nothing here ever asks or waits for the owner.",
+    description: "`tick` also enables the mandatory owner-request/placement flows through the official engine switches and reads canonical pedidos; after 10 minutes without complete staging it wakes the current live task leader, including after a handoff or restart, and never asks the owner. " + "Queue actions: `dequeue` withdraws a queued piece with a required free-text `reason` (task leader or owner only), keeps the draft/history, and refuses dispatch until explicitly restaged; `tick` reconciles stale queued pieces against board review/done/abandoned and records a comment. Vacancy counts live backend processes; lost/exited/closed sessions reserve no slots. " + "FLUXO.ENTREGA-DSL — read or move a DELIVERY (one subtask) through its fixed phases: fila → executando → qa → (ajuste ⇄ qa) → revisao_lider → pr_merge → ci → publicado, plus bloqueado (from any phase, back to the stored origin only). Any transition outside that table is REFUSED (422 `fase_pulada`) with a sentence naming what is missing — executando → revisao_lider, ajuste → revisao_lider and every other skip included. The gates each edge needs are run BY THE SERVER from evidence (predispatch, vaga, salvo = sha on origin per ls-remote, qa-modelo = QA model ≠ author model from the registry and never Sonnet over Sonnet, cabeca = the pushed branch is still at the sha QA tested, delecoes = no file deleted outright by the PR, mergeado = gh says the PR is MERGED, the merge commit is on origin/main and the PR head is the sha QA approved — the merge sha is READ FROM THE PR, never from you, release = the batch's version tag exists AND the release.yml run that produced it is green, read in the repository the release recorded); salvo needs every check run on the pushed head to have concluded green (pending or absent refuse); you never pass proof. `action`: `get` (default; omit `subtaskId` to list every delivery) | `phase` (`to` + what that edge reads: `verdict` APROVADO/REPROVADO + `findings` from qa, `reviewedSha` = the sha QA approved for revisao_lider → pr_merge, `detail` for a request for change or a failure reason) | `gate` (`name`: run ONE gate and record its evidence) | `block` (`reason` one of dependencia, pedido_de_bloqueio, limite, maquina, externo, fora_das_autorizacoes; `text`) | `unblock` (`detail`; the leader of the task or the owner — an owner-decision block only the owner) | `step` (`step` 1..9: the step of the current phase, for the Live %. The Live already DERIVES the step from real signals — a session open, a file edit, a test run, a commit, the gates, the PR — so report only when you know better; the card shows the larger of the two and says which it is. Works for a legacy piece with no delivery record too: only the board's `step` event is written, nothing is adopted into the flow) | `configure` (the LEADER of the task or the owner only; `patch`: versionTarget, humanGates [phases needing the owner's approval — skipped and recorded as 'pulado: modo autônomo' while autonomous mode is on], leaderSessionId, pr, tag, allowDeletions {paths, reason}; the QA and author sessions are never settable — the host records them from the sessions it opened and the registry) | `approve` (`phase`, `decision` approve|reject, `note`: answers a human gate the owner was ASKED about; a session identity is deliberately not sent, the owner answers through this same door as the Live card button and `agentop flow approve`) | `stage-run` (predispatch + vaga gates, then start the staged session and move to executando) | `merge` (delecoes gate, squash-merge the PR, move to ci; a failure goes back to revisao_lider) | `release` (the LEADER of the task or the owner DECLARES what a release contains: `version` x.y.z, `mergeSha` = the commit on main carrying it (information only; 40 characters, or a short sha the server resolves), optional `repo` = owner/name (default agentistics/agentistics), `subtaskIds` = every piece in it; no `subtaskId`. Each piece gets its record (a legacy one is adopted), versionTarget/mergeSha/tag/repo, goes to ci and then to publicado as soon as the tag `v<version>` exists and the release.yml run that produced it is green — read by the server from the TAG, not from the sha — with the release's own publish time; a declared piece is never sent back to revisao_lider by the tick (a red tag run keeps it in ci and wakes the leader once); done/abandoned/blocked/unknown/other-task pieces refuse the whole batch, which is written in ONE store write; a second run changes nothing). In autonomous mode nothing here ever asks or waits for the owner.",
     inputSchema: {
       type: "object",
       properties: {
-        action: { type: "string", enum: ["get", "phase", "gate", "block", "unblock", "step", "configure", "approve", "stage-run", "merge"] },
+        action: { type: "string", enum: ["get", "phase", "gate", "block", "unblock", "dequeue", "tick", "step", "configure", "approve", "stage-run", "merge", "release"] },
         subtaskId: { type: "string" },
+        version: { type: "string", description: "release: the version the pieces shipped in, x.y.z" },
+        mergeSha: { type: "string", description: "release: the commit on main that carries the release (information only: stored on the record; a short sha is resolved to 40 characters or refused). The publication evidence is the version tag's own green release.yml run" },
+        repo: { type: "string", description: "release: the repository owner/name the release belongs to (default agentistics/agentistics); recorded on every piece, the release gate reads it there" },
+        subtaskIds: { type: "array", items: { type: "string" }, description: "release: every subtask in the release" },
         to: { type: "string", enum: ["executando", "qa", "ajuste", "revisao_lider", "pr_merge", "ci", "publicado"] },
         verdict: { type: "string", enum: ["APROVADO", "REPROVADO"] },
         findings: { type: "string" },
@@ -2473,7 +2548,7 @@ var TOOLS = [
         phase: { type: "string", description: "approve: the phase whose human gate is answered" },
         decision: { type: "string", enum: ["approve", "reject"] },
         note: { type: "string" },
-        reason: { type: "string", enum: ["dependencia", "pedido_de_bloqueio", "limite", "maquina", "externo", "fora_das_autorizacoes"] },
+        reason: { type: "string", description: "dequeue: required free-text audit reason (leader only); block: dependencia | pedido_de_bloqueio | limite | maquina | externo | fora_das_autorizacoes" },
         text: { type: "string" },
         step: { type: "number" },
         patch: { type: "object" }
@@ -2483,7 +2558,7 @@ var TOOLS = [
   },
   {
     name: "agentistics_task_stage",
-    description: 'FLUXO.ENTREGA-DSL pre-dispatch — write the STAGED SESSION on a subtask (prompt/brief, harness, model, effort, account, cwd) and open its delivery in `fila` ("Na fila"). A leader receiving a request from the owner stages it in the SAME turn: the demand flow reminds the leader (never the owner) after 10 minutes of an owner request with no staged subtask. The fields merge over what the subtask already holds, and the predispatch gate is checked right away (the reply says what is still missing). Nothing starts here — `agentistics_task_phase action=stage-run` starts it once the vaga gate passes. `pedidoId` links the owner request this answers.',
+    description: "Placement is deterministic: a queued piece of the same task sharing a file, area tag or UI surface is returned as an `encaixe` warning so you can extend that brief or group the pieces. Withdrawn pieces are excluded. " + 'FLUXO.ENTREGA-DSL pre-dispatch — write the STAGED SESSION on a subtask (prompt/brief, harness, model, effort, account, cwd) and open its delivery in `fila` ("Na fila"). A leader receiving a request from the owner stages it in the SAME turn: the demand flow reminds the leader (never the owner) after 10 minutes of an owner request with no staged subtask. The fields merge over what the subtask already holds, and the predispatch gate is checked right away (the reply says what is still missing). Nothing starts here — `agentistics_task_phase action=stage-run` starts it once the vaga gate passes. `pedidoId` links the owner request this answers.',
     inputSchema: {
       type: "object",
       properties: {
@@ -2500,6 +2575,24 @@ var TOOLS = [
       required: ["subtaskId"]
     }
   },
+  {
+    name: "agentistics_task_queue",
+    description: `FILA.PRIORIDADE — read the delivery QUEUE ("Na fila") exactly as the task page's Fila tab shows it, from the same source, in the order pieces LEAVE: the task's priority (urgent → low), then arrival. ` + "Each item: `position` (in its task) and `globalPosition`, `priority`, the subtask/group (with `group.members`), the full PRE-DISPATCH (`predispatch`: harness, model, effort, account and its name, cwd, prompt), the slot gate's last verdict (`slot`; ok=false carries the raw reason such as `no slot: 4 workers running (machine ceiling 4)`), " + "`hold` (the leader said `nao <motivo>` or `agendar <ISO> <motivo>`: kind, reason, until, who, `active`), `ask` (the system question to the leader: when, delivered, approved, `expiresAt` = 10 min, `onTimeout` = `sim` with autonomous mode on, `esperar` with it off), the leader, and the subtask's notes (`notes.last` the newest 3, `notes.total`). " + "`recent` lists pieces the queue opened in the last 24 h with the session they opened. Pass `taskId` for one task's queue. To change the order, change the TASK's priority with `agentistics_task_edit`; to edit a piece's pre-dispatch use `agentistics_task_stage`; to start now / schedule / answer use `agentistics_task_queue_answer`; to withdraw use `agentistics_task_phase action=dequeue`.",
+    inputSchema: { type: "object", properties: { taskId: { type: "string", description: "Only this task's queued pieces. Omit for every task." } }, required: [] }
+  },
+  {
+    name: "agentistics_task_queue_answer",
+    description: "FILA.PRIORIDADE — answer the queue's SYSTEM QUESTION (the message headed `[from flow fila · confirmar]` that arrives in a leader's composer when a slot opens and its piece is next), or act on a queued piece from the Fila tab. Leader of the task or owner only. " + "`answer` is one of: `sim` (open the session now — if no slot is free right now the approval is kept and the next tick starts it; never opens twice), `nao <motivo>` (the piece stays queued with the reason on its card; the flow moves on to the next one), `agendar <ISO> <motivo>` (stays queued, becomes a candidate again only from that FUTURE instant, shown on the card as `começa às HH:MM`). " + "A `nao` or `agendar` without a reason, and an `agendar` in the past, are refused with a sentence. Every decision is recorded as a comment on the subtask (who, why, when). With no answer in 10 minutes: autonomous mode ON → the flow carries on as `sim` and records it; OFF → it keeps waiting and reminds you. " + "Set `runNow: true` instead of `answer` to run the queue flow once right now (what happens automatically when a worker ends and every minute).",
+    inputSchema: {
+      type: "object",
+      properties: {
+        subtaskId: { type: "string" },
+        answer: { type: "string", description: "`sim` | `nao <motivo>` | `agendar <ISO> <motivo>`" },
+        runNow: { type: "boolean", description: "Run the queue flow now instead of answering." }
+      },
+      required: []
+    }
+  },
   {
     name: "agentistics_session_groups",
     description: 'List the user\'s SESSION GROUPS — the named folders in the Sessions sidebar ("Saved to later", "Pelvie", …) — with the sessions in each. A group is how a person keeps a fleet of assistants organised; every session belongs to at most one. Each member carries its `id` (the managed session id you can pass to the other tools), `title`, `state` and `harness` when the session is on this machine right now, or only its `key` when it is gone. Call this BEFORE creating a group, so you file a session under an existing one instead of making a near-duplicate. Only works on a machine, not on a central (a central has no local sessions to organise).',
@@ -2830,6 +2923,11 @@ var TOOLS = [
     description: "List all tags — saved cross-cutting filters over repos/projects/machines/teams/accounts — with their aggregate sessions, cost, and tokens. Use for 'what tags exist' or 'how much did tag X cost' questions.",
     inputSchema: { type: "object", properties: {}, required: [] }
   },
+  {
+    name: "agentistics_vault_status",
+    description: "How this machine's vault is protected — never what it holds. Returns the state (open/locked/uninitialized…), the ways to confirm it is you already in use (touchid = Touch ID or the Mac password, hello = Windows Hello, password = the vault's own password, fido2 = a security key), the ways this machine offers (a security key only when its tools are present, marked advanced), whether an old app-code record is still on disk (it is no longer asked; it is deleted once a way to confirm is chosen), whether the 24-word recovery key exists, the auto-lock minutes, and the vault-password rules (the same table the page and the server enforce). Setting up, unlocking and confirming are the person's: on the /vault page or with `agentop vault` — never pass a vault password or recovery words through a tool.",
+    inputSchema: { type: "object", properties: {}, required: [] }
+  },
   {
     name: "agentistics_tag_detail",
     description: "Get full detail for one tag by name or id: aggregate totals plus per-source breakdown and distributions (top projects, models, harnesses, repos, members/users), daily activity series, and the active date window. Call agentistics_tags first to find the id/name.",
@@ -3081,9 +3179,20 @@ async function callTool(req) {
           const body = a.subtaskId ? await apiGet(`/api/deliveries/${encodeURIComponent(String(a.subtaskId))}`) : await apiGet("/api/deliveries");
           return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
         }
-        if (typeof a.subtaskId !== "string" || !a.subtaskId)
+        if (action === "release") {
+          const body = await apiSend("POST", "/api/deliveries/release", {
+            version: a.version,
+            mergeSha: a.mergeSha,
+            repo: a.repo,
+            subtaskIds: a.subtaskIds,
+            session: sessionProof(process.env)
+          });
+          return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
+        }
+        if (action !== "tick" && (typeof a.subtaskId !== "string" || !a.subtaskId))
           throw new Error("subtaskId is required");
-        const { subtaskId, action: _a, ...rest } = a;
+        const { subtaskId: _s, action: _a, ...rest } = a;
+        const subtaskId = action === "tick" ? "tick" : a.subtaskId;
         const body = await apiSend("POST", `/api/deliveries/${encodeURIComponent(subtaskId)}`, { ...rest, action, ...action === "approve" ? {} : { session: sessionProof(process.env) } });
         return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
       }
@@ -3104,6 +3213,24 @@ async function callTool(req) {
         });
         return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
       }
+      case "agentistics_task_queue": {
+        const a = args ?? {};
+        const body = await apiGet(`/api/deliveries/queue/${encodeURIComponent(typeof a.taskId === "string" ? a.taskId : "")}`);
+        return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
+      }
+      case "agentistics_task_queue_answer": {
+        const a = args ?? {};
+        if (a.runNow === true) {
+          const body = await apiSend("POST", "/api/deliveries/queue-next", { session: sessionProof(process.env) });
+          return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
+        }
+        if (typeof a.subtaskId !== "string" || !a.subtaskId)
+          throw new Error("subtaskId is required");
+        if (typeof a.answer !== "string" || !a.answer.trim())
+          throw new Error("answer is required: sim | nao <motivo> | agendar <ISO> <motivo>");
+        const body = await apiSend("POST", `/api/deliveries/${encodeURIComponent(a.subtaskId)}`, { action: "queue-answer", answer: a.answer, session: sessionProof(process.env) });
+        return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
+      }
       case "agentistics_session_groups": {
         const body = await apiGet("/api/session-groups");
         return { content: [{ type: "text", text: JSON.stringify(body, null, 2) }] };
@@ -3490,6 +3617,13 @@ async function callTool(req) {
         }));
         return { content: [{ type: "text", text: JSON.stringify(rows, null, 2) }] };
       }
+      case "agentistics_vault_status": {
+        const res = await fetch(`${API}/api/vault`);
+        const body = await res.json().catch(() => ({}));
+        if (!res.ok && !(body && typeof body === "object" && body.view))
+          throw new Error(`GET /api/vault → HTTP ${res.status}`);
+        return text(vaultStatusTool(body));
+      }
       case "agentistics_tag_detail": {
         const wanted = (args?.tag ?? "").trim();
         if (!wanted)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agentistics/mcp",
-  "version": "2.201.1",
+  "version": "2.202.0",
   "description": "Agentistics MCP server — Claude Code analytics for Claude Desktop and Claude Code",
   "type": "module",
   "main": "./dist/agentistics-mcp.js",