@rosthq/cli 0.6.6 → 0.6.7

package/dist/generated/command-manifest.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"command-manifest.d.ts","sourceRoot":"","sources":["../../src/generated/command-manifest.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,gCAAgC,CAAC;AAE3E,eAAO,MAAM,gBAAgB,EAAE,SAAS,oBAAoB,EA2L3D,CAAC"}
+{"version":3,"file":"command-manifest.d.ts","sourceRoot":"","sources":["../../src/generated/command-manifest.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,gCAAgC,CAAC;AAE3E,eAAO,MAAM,gBAAgB,EAAE,SAAS,oBAAoB,EA4L3D,CAAC"}

package/dist/index.js

@@ -42268,11 +42268,11 @@ Use the lower-level commands after health names a finding: \`agent.get_run\` for
     order: 46,
     title: "Tool access and vault",
     summary: "How to give agents access to tools without exposing raw credentials or expanding authority by accident.",
-    version: "2026-06-30.2",
+    version: "2026-07-02.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
-    relatedCommandIds: ["charter.sign_manifest", "credential.ingress", "agent.configure_tools", "integration.list", "integration.readiness", "integration.status", "integration.test", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "confirmation.approve"],
+    relatedCommandIds: ["charter.sign_manifest", "credential.ingress", "agent.configure_tools", "integration.connect_rest", "integration.list", "integration.readiness", "integration.status", "integration.test", "mcp_token.create", "mcp_token.revoke", "mcp_token.list", "confirmation.approve"],
     legal: {
       publicRisk: "low",
       notes: [
@@ -42310,7 +42310,7 @@ Connecting a tool is a human-controlled step. The agent can recommend a tool, ex
 
 ## Generic REST connector
 
-For an API with no dedicated connector, the generic REST tool lets a seat call an HTTP endpoint with a credential you paste through the vault \u2014 no {{brand}}-owned app. It is escalate-by-default: the agent may only call a host, method, and explicit path prefix a steward has signed onto the allowlist; any other host, method, or path is refused and escalated, with no request made. A path prefix of \`/\` means the steward intentionally approved every path. The connector sets the Authorization header from the vaulted credential itself \u2014 the agent never sees the token, and the secret is redacted from the response before it reaches the agent, the audit row, or the logs. The token is only ever sent over HTTPS, only to the signed host and scoped path, and a redirect is never followed \u2014 so an allowlisted endpoint cannot bounce the call (and the token) to another host. A sandbox dry run of a REST tool makes no real request.
+For an API with no dedicated connector, the generic REST tool lets a seat read an HTTPS endpoint with a credential you paste through the vault \u2014 no {{brand}}-owned app. The agent-facing tool is GET-only. It is escalate-by-default: the agent may only call a host and explicit path prefix a steward has signed onto the allowlist; any other host or path is refused and escalated, with no request made. Mutating methods and request bodies fail before credential binding. A path prefix of \`/\` means the steward intentionally approved every path. The connector sets the Authorization header from the vaulted credential itself \u2014 the agent never sees the token, and the secret is redacted from the response before it reaches the agent, the audit row, or the logs. The token is only ever sent over HTTPS, only to the signed host and scoped path, and a redirect is never followed \u2014 so an allowlisted endpoint cannot bounce the call (and the token) to another host. A sandbox dry run of a REST tool makes no real request.
 
 ## Slack post connector
 
@@ -42326,6 +42326,8 @@ Google can be connected from Settings once the workspace OAuth app is configured
 
 CLI and MCP can inspect connector readiness without seeing secrets: \`integration.list\` / \`rost_list_integrations\` lists connected providers and health metadata, \`integration.status\` / \`rost_get_integration_status\` reads one provider by id or name, and \`integration.test\` / \`rost_test_integration_connection\` runs the installed provider-specific health check. For Google, the test refreshes the vaulted OAuth credential and reads the Gmail profile, then records only account, scope, and health metadata.
 
+\`integration.connect_rest\` / \`rost_connect_rest_integration\` creates or rotates the supported Baserow REST integration through the credential flow. It stores the token in the vault, persists only endpoint/account metadata plus a tenant-scoped integration row, marks the adapter as \`rest\`, and returns no vault ref or secret. Because the input includes a raw secret, generated CLI argv refuses the command; use Settings or the command API credential flow instead of shell arguments.
+
 \`integration.readiness\` / \`{{cli}} integration readiness --provider google --json\` / \`rost_check_integration_readiness\` returns the operator setup checklist: app configuration status, tenant connection state, granted scopes, latest test state, the demo-safe partner path, external verification/CASA caveats, handler availability, and the next operator action. The checklist is metadata-only. It never returns access tokens, refresh tokens, client secrets, vault refs, or raw provider responses. Settings deliberately keeps the live Google card narrower: connected account, last successful test, granted capabilities, and connect/reconnect/test actions.
 
 ## One write-only credential flow across every surface
@@ -42357,7 +42359,7 @@ There is exactly one way to give a connected tool its credential, and it is the
     order: 47,
     title: "Available tools guide",
     summary: "How to think about tool categories available to seats and what each category should be used for.",
-    version: "2026-06-30.1",
+    version: "2026-07-02.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42401,16 +42403,16 @@ Agents should explain the job, the required tool category, the minimum permissio
 
 ## How a tool actually runs
 
-Every tool call passes the server-side guard first: the guard checks the call against the seat's signed permission manifest and records a tool-call audit row for **every** call \u2014 allowed, denied, or escalated. Tool selection is never authorization. Only an allowed call reaches its handler. A connected credential is bound into the handler for the duration of the call only; the secret never appears in the result, the audit summary, logs, or the model's context.
+Every tool call passes the server-side guard first: the guard checks the call against the seat's signed permission manifest and records a tool-call audit row for **every** call \u2014 allowed, denied, or escalated. Tool selection is never authorization. An explicitly declined manifest entry is enforced as denied, even when the tool exists and the client asks for it. Only an allowed call reaches its handler. A connected credential is bound into the handler for the duration of the call only; the secret never appears in the result, the audit summary, logs, or the model's context.
 
-External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST connector when a signed host/method/path allowlist and credential exist, \`slack.post_message\` for a bound Slack channel, and Google handlers for \`gmail.read\`, \`gmail.draft\`, \`sheets.read\`, and approval-held \`sheets.write\` when Google is connected. \`gmail.send\` remains held for approval and live external send stays gated on Google verification. Before that verification is complete, partner demos should show sandbox dry runs, setup previews, and approval-held examples rather than claim production Google readiness. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
+External connectors are being rolled out provider by provider, conservatively (read and draft before send; write behind approval). A selected tool is only a permission until a live handler exists and the seat has the required credential or binding. Today the built-in execution path supports internal status reporting, the generic REST GET connector when a signed host/path allowlist and credential exist, \`slack.post_message\` for a bound Slack channel, and Google handlers for \`gmail.read\`, \`gmail.draft\`, \`sheets.read\`, and approval-held \`sheets.write\` when Google is connected. \`gmail.send\` remains held for approval and live external send stays gated on Google verification. Before that verification is complete, partner demos should show sandbox dry runs, setup previews, and approval-held examples rather than claim production Google readiness. Other provider entries remain configuration-only until their connector ships, so nothing runs silently.`
   },
   {
     slug: "mcp-and-cli-guide",
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-07-01.5",
+    version: "2026-07-02.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42868,7 +42870,7 @@ The signed-in app exposes the same Skill command surface under **Skills** in the
 | \`{{cli}} sync brief|compile|complete\` | \`sync.brief.get\`, \`sync.brief.compile\`, \`sync.run.complete\` | Compile, read, and complete a weekly Sync. | Tenant | \`{{cli}} sync brief --json\` |
 | \`{{cli}} runner list|status|diagnose|repair|work-orders|revoke|serve\` | \`runner.list\`, \`runner.status\`, \`runner.diagnose\`, \`runner.repair\`, \`work_order.list\`, \`runner.revoke\`, runner endpoint APIs | Inspect heartbeat and execute-readiness evidence, inspect work orders, diagnose offline runners, get repair guidance, revoke a runner, or run the headless local runner loop. | Tenant | \`{{cli}} runner diagnose --runner-id <id> --json\`; \`{{cli}} runner serve --once\` |
 | \`{{cli}} notification settings|test|errors\` | \`notification.settings.get\`, \`notification.test\`, \`notification.list_errors\` | Read notification settings, send a test, and list failed deliveries with linked product error source, seat id, and run id when available. | Tenant | \`{{cli}} notification errors --limit 10 --json\` |
-| \`{{cli}} integration list|readiness|status|test\` | \`integration.list\`, \`integration.readiness\`, \`integration.status\`, \`integration.test\` | List connector metadata, read the setup-readiness checklist, read one connector's health, and run the provider-specific connection test without exposing credentials. | Tenant | \`{{cli}} integration readiness --provider google --json\` |
+| \`{{cli}} integration list|readiness|status|test\` / credential flow for Baserow REST connect | \`integration.connect_rest\`, \`integration.list\`, \`integration.readiness\`, \`integration.status\`, \`integration.test\` | Create a vault-backed Baserow REST integration through the credential flow, list connector metadata, read setup-readiness, read one connector's health, and run provider-specific tests without exposing credentials. | Tenant-admin for connect; tenant for reads/tests | \`{{cli}} integration readiness --provider google --json\` |
 | \`{{cli}} system health\` | \`system.health\` | Read the scoped system-health snapshot across agent runs, unresolved errors, Signals, Cascade setup, work loop, integrations, runners, notifications, and Sync Brief readiness. | Tenant, member, or seat token | \`{{cli}} system health --json\`; \`{{cli}} system health --seat <id> --json\` |
 | \`{{cli}} command usage.report|usage.snapshot\` | \`usage.report\`, \`usage.snapshot\` | Read the AI-workforce ROI report (per-period agent turns, token/run cost, human-accepted value, exceptions, approvals) from immutable usage snapshots, and freeze a period's totals into a new snapshot (insert-only, idempotent). | Tenant | \`{{cli}} command usage.report --json\`; \`{{cli}} command usage.snapshot --json\` |
 | \`{{cli}} settings get|update|product-learning|agent-policy|rename\` | \`settings.get\`, \`settings.update\`, \`settings.product_learning.get\`, \`settings.product_learning.update\`, \`settings.agent_policy.get\`, \`settings.agent_policy.update\`, \`tenant.rename\` | Read tenant settings, update budget caps, read or update product-learning participation, read or set the company autonomy ceiling, and rename the company. Budget, product-learning, and policy updates stop at human confirmation in non-interactive CLI/MCP sessions; company rename is owner-only and human-gated. | Tenant / Tenant-admin for updates | \`{{cli}} settings product-learning get --json\`; \`{{cli}} settings agent-policy get --json\`; \`{{cli}} settings rename --company "Acme Operations"\` |
@@ -42951,7 +42953,7 @@ The equivalent CLI verbs are \`{{cli}} command schema <id>\` and \`{{cli}} comma
 
 These names are available to tenant-admin MCP tokens. They are aliases over the shared command layer and are audited as MCP tool calls. The list spans far more than onboarding \u2014 it groups, in order: onboarding, seats, Charter, confirmations, Compass, staffing, credentials/tokens, graph reads, agents, runners and work orders, notifications, members and settings, Signals, Cascade goals, Friction, tasks, Sync, and escalations.
 
-Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`, \`goal.*\`, and \`friction.*\` families) surfaced because they are also tenant-admin-callable \u2014 which is why the CLI wrapper table marks them "Seat". Scope selection follows the Seat scope note above: a seat-scoped token already carries seat context, while a tenant or owner token must pass \`--seat <seat-id>\` (CLI) or supply seat context (MCP). See the security-model-guide for the seat-vs-tenant authority principle.
+Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`, \`goal.*\`, and \`friction.*\` families) surfaced because they are also tenant-admin-callable \u2014 which is why the CLI wrapper table marks them "Seat". Scope selection follows the Seat scope note above: a seat-scoped token already carries seat context and sees only the seat-scoped MCP tools registered for that token; a tenant or owner CLI session must pass \`--seat <seat-id>\` to act in a seat context. See the security-model-guide for the seat-vs-tenant authority principle.
 
 | Tool | Command id | Purpose | Required scope | Safe example |
 |---|---|---|---|---|
@@ -43007,8 +43009,6 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_list_agent_tool_calls\` | \`agent.list_tool_calls\` | Read a seat's tool-call ledger (tool name, guard result, manifest clause, outcome) with the held-action count as the hero metric. Never returns argument summaries or secret material. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`; pass \`held_only: true\` for only guard-held calls. |
 | \`rost_list_agent_deliverables\` | \`deliverable.list\` | List durable agent deliverables for a seat, including explicit outputs and successful-run summaries. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>"}\`. |
 | \`rost_get_agent_deliverable\` | \`deliverable.get\` | Read one durable agent deliverable by id for a seat. | Seat or tenant-admin | Call with \`{"seat_id":"<seat-id>","deliverable_id":"<id>"}\`. |
-| \`rost_create_agent_deliverable\` | \`deliverable.create\` | Create a scrubbed durable work output for the acting seat. | Seat | Call with title, kind, summary/content, and optional safe links. |
-| \`rost_attach_agent_deliverable\` | \`deliverable.attach\` | Attach a scrubbed deliverable to a source run, task, or work order after server-side seat validation. | Seat | Call with title, kind, and the source ids that belong to the acting seat. |
 | \`rost_accept_deliverable_value\` | \`deliverable.accept\` | Record a human-confirmed accepted value (USD) on a deliverable; owner-only and human-gated. Humans decide \u2014 agents cannot self-accept. Re-accepting records a correction as a new event. | Tenant-admin | Call with \`{"deliverable_id":"<id>","impact_value_usd":<number>}\`; expect human confirmation. |
 | \`rost_ai_workforce_roi_report\` | \`usage.report\` | Read the AI-workforce ROI report \u2014 per-period agent turns, token/run cost, human-accepted value, exceptions, and approvals \u2014 from immutable usage snapshots. | Tenant | Call with \`{}\` or \`{"limit":<n>}\`. |
 | \`rost_capture_usage_period_snapshot\` | \`usage.snapshot\` | Freeze the current (or a given) period's usage and accepted-value totals into an immutable snapshot; insert-only and idempotent. | Tenant | Call with \`{}\` or \`{"period":"YYYY-MM-DD"}\`. |
@@ -43042,6 +43042,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_resolve_error_log\` | \`error_log.resolve\` | Acknowledge or resolve an error log with a required human reason and optional task, issue, or PR link. | Tenant | Call with \`error_log_id\`, \`reason\`, and \`disposition\` \`acknowledged\` or \`resolved\`. |
 | \`rost_supersede_error_log\` | \`error_log.supersede\` | Mark an older error log as superseded by a newer in-tenant error log. | Tenant | Call with \`error_log_id\`, \`new_error_log_id\`, and \`reason\`. |
 | \`rost_list_integrations\` | \`integration.list\` | List connected integration metadata and latest health state. | Tenant | Call with \`{}\` or \`{"provider":"google"}\`; no secrets or vault refs are returned. |
+| \`rost_connect_rest_integration\` | \`integration.connect_rest\` | Create or rotate the vault-backed Baserow REST integration for Signal pulls. | Tenant-admin | Use the credential flow with provider \`baserow\`, HTTPS endpoint, scope, secret name, and secret; no vault refs or secrets are returned. |
 | \`rost_check_integration_readiness\` | \`integration.readiness\` | Return the connector setup checklist: OAuth env/callback, tenant connection, scopes, latest test state, external verification/CASA, handler availability, and DER-coded next actions. | Tenant | Call with \`{"provider":"google"}\`; metadata only, no secrets or vault refs. |
 | \`rost_get_integration_status\` | \`integration.status\` | Read one integration's metadata by provider or integration id. | Tenant | Call with \`{"provider":"google"}\` or \`{"integration_id":"<id>"}\`. |
 | \`rost_test_integration_connection\` | \`integration.test\` | Run the provider-specific connection test and update integration health. | Tenant | Call with \`{"provider":"google"}\`; result is bounded metadata only. |
@@ -43061,7 +43062,6 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_get_signal\` | \`signal.get\` | Read a measurable with its full reading history. | Seat or tenant-admin | Call with \`{"measurable_id":"<id>"}\`. |
 | \`rost_confirm_signal_reading\` | \`signal.confirm_reading\` | Confirm an unconfirmed reading as human-verified. | Seat or tenant-admin | Humans confirm; call with \`{"reading_id":"<id>"}\`. |
 | \`rost_correct_signal_reading\` | \`signal.correct_reading\` | Overwrite a reading with a human-confirmed value. | Seat or tenant-admin | Manual correction; expect confirmation. |
-| \`rost_report_a_signal_reading\` | \`signal.report\` | A per-seat Signal agent proposes one draft reading for its own seat's agent-sourced measurable (a judgment/transform pull). The reading lands unconfirmed; a human confirms it with signal.confirm_reading. Refuses non-agent-sourced or other-seat measurables and cannot overwrite a human-confirmed reading. | Seat | Call with \`{"measurable_id":"<id>","value":42,"note":"read off the source","confidence":"high"}\`. |
 | \`rost_add_a_measurable\` | \`measurable.create\` | Add a measurable a seat owns (name, unit, direction, target, cadence). | Seat or tenant-admin | Call with \`{"seat_id":"<id>","name":"...","unit":"...","direction":"up_good","target":0,"cadence":"weekly"}\`. |
 | \`rost_import_signals_from_csv\` | \`signal.import\` | Bulk-import measurable definitions + trailing historical readings from a parsed scorecard export (e.g. a ninety CSV). Owners resolve to seats; readings are human-confirmed; re-import upserts by (measurable, period, cadence); a cross-cadence row is reported and skipped, not overwritten. | Tenant | Call with the parsed \`measurables\` array. |
 | \`rost_list_measurable_templates\` | \`measurable_template.list\` | List the measurable template catalog (Sales/Finance/Ops/Marketing/HR) with unit, direction, cadence, and a suggested target. | Seat or tenant-admin | Call with \`{}\` or \`{"function":"sales"}\`. |
@@ -43139,6 +43139,9 @@ Seat-scoped MCP tokens expose the operating protocol below. The server still che
 | \`rost_escalate\` | \`escalation.raise\` | Escalate approval-scope or must-escalate work. | Seat | Call with severity, reason, and requested decision. |
 | \`rost_file_issue\` | \`friction.file_issue\` | File a Friction issue. | Seat | Call with title, severity, and impact. |
 | \`rost_log_work\` | \`work.log\` | Record work performed by the seat. | Seat | Call with summary and evidence. |
+| \`rost_report_a_signal_reading\` | \`signal.report\` | Propose one draft reading for this seat's own agent-sourced measurable. The reading lands unconfirmed for human review. | Seat | Call with \`{"measurable_id":"<id>","value":42,"note":"read off the source","confidence":"high"}\`. |
+| \`rost_create_agent_deliverable\` | \`deliverable.create\` | Create a scrubbed durable work output for the acting seat. | Seat | Call with title, kind, summary/content, and optional safe links. |
+| \`rost_attach_agent_deliverable\` | \`deliverable.attach\` | Attach a scrubbed deliverable to a source run, task, or work order after server-side seat validation. | Seat | Call with title, kind, and the source ids that belong to the acting seat. |
 
 ### MCP operation resources
 
@@ -43458,7 +43461,7 @@ Set \`ROST_SKILL_INSTALL_ROOT\` only for a sandbox or CI override. Local copies
     order: 55,
     title: "Agent reference map",
     summary: "Where CLI sessions, MCP clients, and in-app agents should retrieve {{brand}} guidance before recommending setup changes.",
-    version: "2026-06-21.2",
+    version: "2026-07-02.2",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -43543,6 +43546,7 @@ Agents that run on {{brand}}-managed inference draw against a tenant inference b
 21. confirmations-guide
 22. steward-queue-guide
 23. sync-rhythm-playbook
+24. billing-and-pricing-guide
 
 ## Workflow to guide map
 
@@ -43568,6 +43572,7 @@ Read the listed guide before recommending or running each workflow. Every workfl
 - Operate local runners and work orders: runner-guide.
 - Approve or reject a pending confirmation (human only): confirmations-guide.
 - Manage members, settings, and notifications: settings-guide, settings-members-and-invites-guide, notifications-guide.
+- Explain company-wide billing, payment, invoices, or usage true-ups: billing-and-pricing-guide, then settings-guide.
 - Diagnose a failure on any surface: troubleshooting-guide, then security-model-guide.
 
 ## Stage map
@@ -43695,7 +43700,7 @@ Agents can suggest commitments and report progress. They should not create a new
     order: 61,
     title: "Signal guide",
     summary: "How to define and read measurables so the company runs on evidence instead of status theater.",
-    version: "2026-07-01.3",
+    version: "2026-07-02.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43764,7 +43769,7 @@ To move off a spreadsheet or another operating tool, upload a scorecard export f
 
 ## Adopt a measurable template
 
-Not sure which measurables to track? \`measurable_template.list\` returns a starter catalog grouped by function (Sales, Finance, Operations, Marketing, HR), each with a unit, direction, cadence, and suggested target. \`measurable_template.adopt\` instantiates one against a seat \u2014 the same write path as \`measurable.create\`, so the created measurable is a plain human-owned Signal you log against afterward. Adoption is a human act; the suggested target is just a starting point you can override.
+Not sure which measurables to track? \`measurable_template.list\` returns a starter catalog grouped by function (Sales, Finance, Operations, Marketing, HR), each with a unit, direction, cadence, suggested target, and source-readiness metadata when a known source path exists. Finance templates are explicit: platform billing usage baselines can use safe platform metadata, while tenant customer MRR, QuickBooks AR aging, and QuickBooks gross margin stay blocked until tenant-owned billing/accounting reads ship. \`measurable_template.adopt\` instantiates one against a seat \u2014 the same write path as \`measurable.create\`, so the created measurable is a plain human-owned Signal you log against afterward. Adoption is a human act; the suggested target is just a starting point you can override.
 
 ## The leadership scorecard grid
 
@@ -43779,7 +43784,11 @@ Once a measurable's number lives in a connected system, you can teach {{brand}}
 - \`signal.bind\` persists the validated recipe as an inert \`draft\` binding. It requires the \`preview_token\` from a preview of the same recipe, so nothing is bound that was not first seen working.
 - \`signal.bind_confirm\` is human-only. It activates the binding (\`draft -> active\`); an agent that calls it produces a pending confirmation instead. Only after a human confirms does the scheduled pull begin writing confirmed readings.
 
-Recipes are validated data, never code: a read-only GET, a closed set of non-secret headers, and a restricted scalar path to the value. Every fetch passes one SSRF guard (HTTPS only, a steward-confirmed host allowlist set at bind, and a runtime check that the host does not resolve to a private address). Deterministic pulls write \`integration\`-sourced readings on the measurable's cadence.
+Discovery always returns a \`recipe_presets\` array; it is empty when {{brand}} does not recognize a safe source type. Today those presets cover Baserow row fields and the generic REST JSON fallback. Google Sheets uses OAuth JSON credentials and is withheld from REST presets until the pull executor extracts and refreshes the Google access token instead of treating the stored credential blob as a bearer token. A preset includes a label, cadence, required metadata, a draft \`rest_for_signals\` recipe, and the host allowlist to preview with. The human still fills in the real Baserow table/row/field or exact REST URL and value path before running \`signal.preview\`; presets are starter recipes, not secret stores.
+
+Recipes are validated data, never code: a read-only GET, a closed set of non-secret headers, and a restricted scalar path to the value. Every fetch passes one SSRF guard (HTTPS only, a steward-confirmed host allowlist set at bind, and a runtime check that the host does not resolve to a private address). The preset output never contains \`nango://\` handles, vault refs, tokens, or static credential headers. Deterministic pulls write \`integration\`-sourced readings on the measurable's cadence.
+
+In the web app, the same workflow lives on \`/signal\` in the "Connect a self-filling source" panel. It shows each measurable's setup state \u2014 manual, agent draft, source draft, or auto-filled \u2014 plus the latest safe pull outcome when one exists. Choose a connected source, discover its non-secret metadata, preview a GET URL and value path, bind the working preview as a draft, then confirm the draft before scheduled pulls can write readings. The UI never displays credential material, vault refs, raw response bodies, or recipe secrets; if no connected source exists, connect one from Settings first.
 
 ## Collect a Signal by judgment (the Signal agent)
 
@@ -43798,7 +43807,7 @@ Agents may record readings when the Charter allows it. Agent-reported readings s
     order: 62,
     title: "Friction guide",
     summary: "How to capture issues with evidence, rank them, and resolve them without losing ownership.",
-    version: "2026-07-01.1",
+    version: "2026-07-01.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43858,6 +43867,8 @@ Friction, tasks, and escalations are the issue-to-action loop. A seat files, a t
 - Carry the work as a task: \`task.create\` / \`rost_create_task\` (a commitment between seats). \`task.create\` is \`none\` (no confirmation gate), so an agent can file one directly; an agent's task lands as a **draft** proposal (\`origin: agent_proposal\`) for a human to review and hand off \u2014 not a live offer in the owning seat's accept/decline queue. A seat runs its queue with \`{{cli}} task list|accept|decline|complete\` (\`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`). Link a task to an issue with \`friction.link_task\` / \`rost_link_task_to_friction_issue\`.
 - Route a decision: \`escalation.raise\` (seat) / \`rost_escalate\` sends approval-scope or must-escalate work to the Steward queue. Reads are \`escalation.list\` / \`escalation.get\`. See the steward queue guide for resolution.
 
+In the app, the Tasks surface exposes the same queue operations for a seat's visible work. Offered handoffs show Accept and Decline actions; Decline opens a reason field and records the reason through \`task.decline\`. Edit opens a separate task form for title, owner, due date, and description changes on non-terminal tasks. These controls are standard focusable disclosures so keyboard and pointer users can operate the queue without dropping to CLI.
+
 ## Friction assist
 
 \`friction.assist\` / \`rost_assist_friction_issue\` is a read-only advisory for an open issue \u2014 call it with the issue id. It returns the most-similar prior resolved issues with their root causes and recorded decisions, a recurring-pattern flag, and recommended options drawn from that history. It never resolves the issue or records a decision \u2014 a human still resolves via \`friction.resolve\`. The similar-issue recall is deterministic; the short narrative is best-effort and degrades to the deterministic summary when the model is slow or unavailable, so the assist stays responsive and never holds up other work.
@@ -43998,13 +44009,113 @@ An agent never approves or rejects its own request. \`decisions.decided_by\` is
 ## When to stop
 
 Stop before: approving a Charter, signing a manifest, connecting a tool or credential, minting a token, going live, resolving an escalation or Friction, reparenting or dropping a goal, changing a member role, or updating budget caps. These are human gates by design.`
+  },
+  {
+    slug: "billing-and-pricing-guide",
+    order: 71,
+    title: "Billing and pricing guide",
+    summary: "How {{brand}} packages company-wide access, Stripe billing, and governed-agent usage without per-human-seat pricing.",
+    version: "2026-07-02.4",
+    public: true,
+    audiences: ["human", "cli", "mcp", "in_app_agent"],
+    stages: ["company_setup", "staffing", "operating_rhythm"],
+    relatedCommandIds: ["settings.get"],
+    legal: {
+      publicRisk: "medium",
+      notes: [
+        "Describes the product packaging model, not tax, accounting, legal, or contract advice.",
+        "Avoids Stripe price ids, secrets, payment details, and unpublished negotiated contract terms."
+      ]
+    },
+    sources: [
+      {
+        label: "ADR-0016",
+        internalPath: "docs/adr/0016-commerce-pricing-and-packaging.md",
+        note: "Canonical pricing and packaging decision for the first-client commerce workstream."
+      },
+      {
+        label: "MVP implementation plan",
+        internalPath: "docs/specs/MVP-implementation-plan.md",
+        note: "FR-11 billing and commerce requirements."
+      },
+      {
+        label: "Full repo analysis",
+        internalPath: "docs/research/2026-07-01-rost-full-repo-analysis.md",
+        note: "Identifies commerce as the top first-client blocker."
+      }
+    ],
+    body: `# Billing and pricing guide
+
+{{brand}} is priced for company-wide adoption. A Seat is a function, not a paid human license, so inviting the whole team should not create a per-person tax on running the operating system.
+
+## Package model
+
+The launch billing model has two parts:
+
+- **Company base subscription.** One company subscription covers the operating system: Compass, Responsibility Graph, Cascade, Signal, Friction, Sync, Settings, reference docs, and governed agent setup.
+- **Governed-agent usage.** The base subscription includes a configurable allowance for billable successful agent work. Usage above the included allowance is metered from service-owned closed-period billing finalization.
+
+Human members are not the billing unit. A company can invite the people needed to run the operating rhythm without paying for each human login. Seat or member limits may still exist as entitlement controls for abuse prevention, package design, or enterprise contracts, but they are not the default subscription meter.
+
+## How usage is measured
+
+Agent usage is measured from the same billing-grade records that power the AI-workforce ROI view:
+
+- Agent runs record token/cost data as they execute.
+- \`usage.snapshot\` freezes usage into \`usage_period_snapshot\` for ROI/reporting.
+- Billing true-up uses a service-owned closed-period finalization path, not mutable running totals and not a tenant-created current-period snapshot.
+- A true-up must be idempotent and no-overcharge: the same closed period should not be reported twice.
+
+The first meter is billable-successful-agent-run based because the current platform records per-run usage and cost. The v1 overage quantity starts from successful real runs, excludes setup/sandbox dry runs and other non-billable rehearsals, and keeps failed, timed-out, and cancelled runs visible in the ROI and exception views without charging them as overage. The usage layer should keep enough metadata to support future accepted-value or outcome-based units without changing the subscription model.
+
+Billable true-up is service-owned and runs after a period is closed. The tenant-facing \`usage.snapshot\` command is an ROI/reporting tool; an early current-period snapshot must not become, replace, or block the final billable close. The billing close records a separate \`billing_usage_true_ups\` row keyed by tenant and period with the source kind, included allowance, billable overage, status, and Stripe meter event identifier. A closed usage snapshot is preferred only when it was captured after the period ended; otherwise the service close uses a live rollup for that closed period so an early ROI snapshot cannot undercount the invoice true-up.
+
+## Stripe boundary
+
+Stripe owns payment collection, payment methods, invoices, and hosted customer self-service.
+
+{{brand}} stores only safe commerce metadata: Stripe customer/subscription identifiers, plan state, entitlement state, usage true-up state, and safe audit/error metadata. Card numbers, bank details, payment-method secrets, Stripe API secrets, webhook signing secrets, and raw payment details must never be stored in {{brand}}, entered into an agent prompt, written to logs, or copied into tool arguments.
+
+## Design partners and test tenants
+
+Test and design-partner companies may run without a Stripe customer or subscription. They are invite-flagged plans with explicit billing state and model safety caps. Do not use fake coupons or hidden payment workarounds to represent them.
+
+When a company converts to paid, Stripe subscription state plus the tenant plan become the authority for the company subscription. Account entitlements remain user/account-scoped capability grants or limit overrides; they should not make the whole company's paid access depend on one owner's account grant. Limitable gates resolve through a paid-plan-aware entitlement helper: explicit service-owned \`account_entitlements\` rows override the tenant default for a specific user and tenant, while active paid tenant state selects the paid-plan default. Empty metadata means unlimited today; future tenant-wide caps must use a service-owned billing configuration surface, not client-editable tenant settings.
+
+## Billing versus inference budget
+
+There are three separate allowances or caps:
+
+- **Subscription usage allowance:** the included billable-successful-agent-run allowance in the paid company plan.
+- **Platform onboarding model allowance:** the app-provided setup tokens used during assisted onboarding.
+- **Inference hard cap:** a safety and spend-control setting for {{brand}}-managed model calls.
+
+The inference hard cap is not the subscription invoice, and raising it is not the same as buying a plan. The onboarding model allowance is also separate from the subscription usage allowance.
+
+A company may bring its own provider key. BYOK changes which provider account pays eligible model calls; it does not change the company base subscription, the Charter, the tool guard, human confirmations, or billing for governed-agent platform usage.
+
+## What users should see
+
+The billing area in Settings answers:
+
+- Which plan is active.
+- Whether the company is on free setup access, design-partner access, or a paid Stripe-backed subscription.
+- Where tenant owners can start Checkout or open Stripe's hosted portal for payment method and invoice management.
+- Recent Stripe invoice summaries when Stripe billing is configured for the company.
+- Human/member coverage plus agent-seat and live-agent coverage.
+- The latest subscription usage snapshot from the immutable usage-period table.
+- The latest true-up status, including whether overage was reported, skipped because the included allowance covered the period, or needs retry.
+
+Settings labels subscription usage separately from the setup model allowance and the inference hard cap. Payment methods and invoice payment stay in Stripe. {{brand}} renders subscription ids/status and invoice summaries only; it does not store card, bank, payment-method, or invoice-payment details.
+
+Do not claim that a live charge happened unless Stripe test/live evidence proves it. For internal or design-partner validation, use Stripe test mode only unless a human owner explicitly completes a real live-payment step.`
   },
   {
     slug: "settings-guide",
     order: 72,
     title: "Settings guide",
     summary: "How to use Settings as the control plane for company access, channels, providers, tokens, and operating defaults.",
-    version: "2026-07-01.1",
+    version: "2026-07-02.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -44034,6 +44145,7 @@ Settings is one page with anchored sections, not separate sub-pages. Documented
 - Company profile and workspace defaults. Rename the company from Settings or with \`tenant.rename\` (CLI: \`{{cli}} settings rename --company "<name>"\`); the command is owner-only, human-gated, and records a rename event with old and new names.
 - Members, invites, and tenant roles.
 - Agent access tokens for local agents.
+- Billing plan, hosted Stripe actions, invoices, subscription usage coverage, and latest true-up status.
 - Provider and integration configuration.
 - Slack channels (the channel bindings that route escalations, Sync Briefs, and reports to a seat or cluster).
 - Connected machines (the paired Runners that run scheduled local work orders).
@@ -44424,7 +44536,7 @@ Name the failing surface, collect evidence, recommend the smallest correction, a
     order: 78,
     title: "AI model data handling guide",
     summary: "How {{brand}} cloud agents, local MCP sessions, runners, BYOK, and connected tools handle model-bound data.",
-    version: "2026-07-01.2",
+    version: "2026-07-01.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44511,7 +44623,7 @@ Cloud prompts should not include raw credentials, long exports, unrelated custom
 
 ## BYOK Anthropic
 
-Tenant BYOK changes which provider account is used for eligible \`cloud\` model calls. It does not loosen tool permissions, human gates, tenant isolation, or audit requirements. The same tenant-key resolution also covers the read-only advisory analyzers (friction assist, compass-alignment drift, and the coach draft-guide): when a tenant has saved its own Anthropic key those advisory calls use it and are metered on that key, otherwise they fall back to the platform key, and when neither is available they degrade to their deterministic summary rather than failing.
+Tenant BYOK changes which provider account is used for eligible \`cloud\` model calls. It does not loosen tool permissions, human gates, tenant isolation, or audit requirements. The same tenant-key resolution also covers the read-only advisory analyzers (friction assist, compass-alignment drift, and the coach draft-guide): when a tenant has saved its own Anthropic key those advisory calls use it and are metered on that key, otherwise they fall back to the platform key and are recorded against the managed hard cap and platform allowance before returning advisory text. When neither key is available, they degrade to their deterministic summary rather than failing.
 
 {{brand}} also includes a capped, app-provided Claude allowance for agent-assisted setup so a new company can complete onboarding before saving its own key. That allowance is shown in the onboarding provider card and in Settings as an approximate number of included setup tokens \u2014 never a dollar amount \u2014 and is enforced server-side on every platform-key call: an agent turn or an org-intake step reserves the allowance before the provider request and settles actual usage after. When the included tokens are used, agent-assisted steps stop before calling the provider and prompt you to add your own Anthropic API key, while non-AI setup steps stay available. Saving a tenant Anthropic key (BYOK) switches those calls to your provider account and does not draw down the included allowance.
 
@@ -44600,7 +44712,7 @@ When asked about AI data handling:
     order: 79,
     title: "Security model guide",
     summary: "How {{brand}} protects tenant data, credentials, tool calls, and human decisions across web, MCP, CLI, and agents.",
-    version: "2026-06-29.1",
+    version: "2026-07-01.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -44661,7 +44773,7 @@ Do not store raw passwords, OAuth tokens, API keys, full \`.env\` files, session
 
 ## Access and isolation
 
-Every tenant-scoped product record is scoped by \`tenant_id\`, and database policies are written so one tenant cannot read another tenant's data through normal application access. Server-side tenant context comes from trusted server-side authority, not from client-supplied tenant ids: browser and CLI user sessions use authenticated Supabase claims plus membership, MCP sessions use the authenticated MCP token record, and runner sessions use the authenticated runner credential record.
+Every tenant-scoped product record is scoped by \`tenant_id\`, and database policies are written so one tenant cannot read another tenant's data through normal application access. Server-side tenant context comes from trusted server-side authority, not from client-supplied tenant ids: browser and CLI user sessions use authenticated Supabase claims plus membership, MCP sessions use the authenticated MCP token record, and runner sessions use the authenticated runner credential record. Raw server SQL over tenant-scoped tables is also checked in CI so those statements carry tenant context explicitly.
 
 Human access is role-based through tenant membership:
 
@@ -44695,7 +44807,7 @@ Tool selection is never authorization. A selected tool in setup records the requ
 - Decisions are human-decided records. Agents can draft or recommend, but durable decisions require a human.
 - Charters, Compass versions, and accepted knowledge change by supersession instead of silent overwrite.
 - Agent runs, work orders, tool calls, Skill activations, notification failures, and integration tests leave diagnostic records that can be inspected without exposing raw secrets.
-- Product-visible server/integration/runtime failures are recorded in \`error_logs\` when tenant context is available; pre-auth or tenant-less failures fall back to structured server logging.
+- Product-visible server/integration/runtime failures are recorded in \`error_logs\` when tenant context is available; pre-auth or tenant-less failures fall back to structured server logging. MCP route failures return safe JSON instead of framework HTML errors, so local clients can key off the structured error and request id.
 
 When reporting evidence to a human, summarize the relevant fields and include stable ids only when they help trace the record. Do not paste raw secrets, full provider responses, full prompt text, or broad exports into status updates.
 
@@ -46044,6 +46156,7 @@ var COMMAND_MANIFEST = [
   { "id": "goal.unbind_measurable", "namespace": "goal", "action": "unbind_measurable", "title": "Unbind a Signal from a Cascade goal", "description": "Remove a measurable's drives_status binding from a goal. The goal keeps its last status; unbinding only stops future signal-driven updates.", "requiredScope": "seat", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "goal_id", "flag": "goal-id", "type": "string", "required": true }, { "name": "measurable_id", "flag": "measurable-id", "type": "string", "required": true }], "hasComplexInput": false, "help": "Remove a Signal's drives_status binding from a goal; the goal keeps its last status and stops receiving signal-driven updates." },
   { "id": "goal.update", "namespace": "goal", "action": "update", "title": "Update Cascade goal", "description": "Update a goal's title or definition of done. Topology (parent/seat) and status have dedicated commands.", "requiredScope": "tenant_admin", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "goal_id", "flag": "goal-id", "type": "string", "required": true }, { "name": "title", "flag": "title", "type": "string", "required": false }, { "name": "definition_of_done", "flag": "definition-of-done", "type": "string", "required": false }], "hasComplexInput": false, "help": "Update a goal's title or definition of done; topology and status have dedicated commands." },
   { "id": "graph.get", "namespace": "graph", "action": "get", "title": "Get Responsibility Graph", "description": "Return the tenant's Responsibility Graph: seats, edges, root, occupants, and status rollups.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": true, "fields": [], "hasComplexInput": false, "help": "Read the Responsibility Graph to discover seat ids, parentage, occupants, and status before mutating or routing work." },
+  { "id": "integration.connect_rest", "namespace": "integration", "action": "connect_rest", "title": "Connect REST integration", "description": "Create or rotate the tenant Baserow REST integration using a vault-backed secret. Stores endpoint metadata only; never returns secrets or vault refs.", "requiredScope": "tenant_admin", "confirmation": "credential_flow", "exposeOverMcp": true, "fields": [{ "name": "provider", "flag": "provider", "type": "enum", "required": true, "enumValues": ["baserow"] }, { "name": "endpoint_url", "flag": "endpoint-url", "type": "string", "required": true }, { "name": "scope_description", "flag": "scope-description", "type": "string", "required": true }, { "name": "secret_name", "flag": "secret-name", "type": "string", "required": true }, { "name": "account_label", "flag": "account-label", "type": "string", "required": false }], "hasComplexInput": false, "secretBlocked": true, "help": "Create or rotate a vault-backed Baserow REST integration for Signal pulls. Use the credential flow; never pass secrets through CLI argv." },
   { "id": "integration.discover", "namespace": "integration", "action": "discover", "title": "Discover a connection for signals", "description": "Read-only introspection of a connected source for signal binding. Returns non-secret adapter metadata and a rest-for-signals recipe skeleton to author against signal.preview. Exposes no secrets.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "integration_id", "flag": "integration-id", "type": "string", "required": true }], "hasComplexInput": false, "help": "Read-only introspection of a connected source: returns non-secret metadata + a recipe skeleton to author a signal pull against. No network." },
   { "id": "integration.list", "namespace": "integration", "action": "list", "title": "List integrations", "description": "List tenant integration metadata and health status. Returns account/scopes/capabilities only; never secrets or vault refs.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "provider", "flag": "provider", "type": "string", "required": false }], "hasComplexInput": false, "help": "List connected integrations and their metadata-only health state before enabling a connector-backed tool." },
   { "id": "integration.readiness", "namespace": "integration", "action": "readiness", "title": "Check integration readiness", "description": "Return a safe connector setup checklist for operators and agents. Starts with Google and exposes no secrets.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "provider", "flag": "provider", "type": "enum", "required": false, "enumValues": ["google"] }], "hasComplexInput": false, "help": "Read the connector setup checklist before relying on Google-backed agent work; the checklist names missing config, connection, scopes, external verification, and handler blockers." },