@rosthq/cli 0.7.168 → 0.7.169

package/dist/index.js

@@ -31630,6 +31630,15 @@ var toolPolicyGetOutputSchema = external_exports.object({
   tool_policy: storedTenantToolPolicySchema
 }).strict();
 
+// ../../packages/protocol/src/credential-identity.ts
+var CREDENTIAL_IDENTITY_STATUSES = [
+  "unverified",
+  "verified",
+  "mismatch",
+  "unresolvable"
+];
+var credentialIdentityStatusSchema = external_exports.enum(CREDENTIAL_IDENTITY_STATUSES);
+
 // ../../packages/protocol/src/agent-capability-enforcement.ts
 var capabilityClassSchema = external_exports.enum([
   "connector",
@@ -33809,15 +33818,6 @@ var integrationReadinessOutputSchema = external_exports.object({
   connectors: external_exports.array(integrationReadinessConnectorSchema)
 }).strict();
 
-// ../../packages/protocol/src/credential-identity.ts
-var CREDENTIAL_IDENTITY_STATUSES = [
-  "unverified",
-  "verified",
-  "mismatch",
-  "unresolvable"
-];
-var credentialIdentityStatusSchema = external_exports.enum(CREDENTIAL_IDENTITY_STATUSES);
-
 // ../../packages/protocol/src/display-label.ts
 var tenantIdSchema = external_exports.uuid();
 var seatIdSchema = external_exports.uuid();
@@ -59451,7 +59451,7 @@ A command carrying any of these risk categories always asks a human, even under
     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-08-11.1",
+    version: "2026-08-13.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -59504,7 +59504,7 @@ Google production verification is a roadmap item planned after the first 100 use
 
 Reconnects keep historical rows for audit, but provider status in Settings, CLI, and MCP prefers the current connected row first, then the latest error or disconnected row.
 
-When a connection's credential authenticates as an account that does not match the one on record, the Settings card's description text warns that the connection authenticated as the wrong account; the connected/needs attention badge above it does not change, because the badge reflects connection status alone and never reads identity state. The remedy the description offers is to reconnect as the account the connection is recorded against: testing a stable mismatch again only records the same mismatch, and accepting the newly reported account is not yet offered from the card. Once the identity is verified again \u2014 because a later check resolves the recorded account, or because the newly reported account is accepted \u2014 the description drops that warning and, matching the connection's test history, either reports that identity was verified and asks for a fresh test or simply asks you to test the connection to confirm access; it never treats the verification alone as proof the connection works, because establishing who a credential belongs to is not evidence that it does. For the same reason, a passing test older than the most recent identity verification stops counting as current, and the description asks you to test again rather than reporting the stale pass. An identity the provider contradicts, or one it declined to report, keeps the description's warning even when an earlier test passed. The agent-setup card's Google connection readiness badge works differently from the Settings badge: it folds connection, test, and identity state together, so the same identity risk that leaves the Settings badge untouched can turn that badge to **Needs attention**, and once the risk clears without a current passing test it can read **Connected, not tested**. Note that \`integration.readiness\` does not read identity state yet: its connection-test check reports the stored test result on its own, so a connection with an identity warning on Settings, or a **Needs attention** agent-setup readiness badge, can still report as tested to CLI and MCP until it is tested again.
+When a connection's credential authenticates as an account that does not match the one on record, the Settings card's description text warns that the connection authenticated as the wrong account; the connected/needs attention badge above it does not change for that reason, because the badge reflects connection and credential presence and never reads identity state. The remedy the description offers is to reconnect as the account the connection is recorded against: testing a stable mismatch again only records the same mismatch, and accepting the newly reported account is not yet offered from the card. Once the identity is verified again \u2014 because a later check resolves the recorded account, or because the newly reported account is accepted \u2014 the description drops that warning and, matching the connection's test history, either reports that identity was verified and asks for a fresh test or simply asks you to test the connection to confirm access; it never treats the verification alone as proof the connection works, because establishing who a credential belongs to is not evidence that it does. For the same reason, a passing test older than the most recent identity verification stops counting as current, and the description asks you to test again rather than reporting the stale pass. An identity the provider contradicts, or one it declined to report, keeps the description's warning even when an earlier test passed. The agent-setup card's Google connection readiness badge works differently from the Settings badge: it folds connection, credential presence, test, and identity state together, so any row whose active credential is gone reads **Credential missing \u2014 reconnect** \u2014 whether the row reads connected or needs attention, and checked ahead of every other state, because nothing can execute without a credential \u2014 with its Test connection action disabled until you reconnect; the same identity risk that leaves the Settings badge untouched can turn that badge to **Needs attention**, and once the risk clears without a current passing test it can read **Connected, not tested**. Note that \`integration.readiness\` does not read identity state yet: its connection-test check reports the stored test result on its own, so a connection with an identity warning on Settings, or a **Needs attention** agent-setup readiness badge, can still report as tested to CLI and MCP until it is tested again.
 
 ## Sync Brief scope
 
@@ -60667,7 +60667,7 @@ This worked document **omits** \`unanswered_boundaries\` and \`seat_type_recomme
     order: 43,
     title: "Agent builder guide",
     summary: "The full agent setup sequence on the CLI/MCP path \u2014 seat, steward, job, boundaries, tools, credentials, model, schedule, dry-run, go-live \u2014 with the structured model config and access tiers.",
-    version: "2026-07-13.2",
+    version: "2026-08-13.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -60715,7 +60715,7 @@ Building teams of controlled agent workers is the product's core differentiator.
 3. **Job** \u2014 what the seat owns. On \`agent.create_custom\` this is the operational answers (what it owns, what success looks like, what it must never do alone); for a strong contract, submit the full Charter directly via \`charter.update_draft\` (see the charter-authoring deep-dive).
 4. **Boundaries** \u2014 the Charter's \`decision_authority\` (can-do / must-ask / never / escalate), \`escalation_rules\`, and \`budget\`. Conservative by default: send/spend/irreversible actions are approval-gated or escalated.
 5. **Tools** \u2014 pick from the discoverable catalog (\`{{cli}} tools list\`); each tool has a default scope tier and access policy. Connect or decline via \`agent.configure_tools\`. Selecting a tool records permission; live handlers execute later only behind the signed manifest, server guard, required credential or binding, and connector-specific approval boundary.
-6. **Credentials and provider readiness** \u2014 a tool that needs access declares a credential-ingress request (provider, scope, secret name). The secret itself flows through the vault-backed ingress command as a vault ref \u2014 never paste a secret into a builder command. For Google-backed tools, inspect the provider readiness shown in Settings or the builder: not connected, connected but untested, connected and tested, or failed. Use \`integration.test\` / \`rost_test_integration_connection\` or the builder Test connection action to refresh the same safe status facts; do not infer authorization from a connected credential.
+6. **Credentials and provider readiness** \u2014 a tool that needs access declares a credential-ingress request (provider, scope, secret name). The secret itself flows through the vault-backed ingress command as a vault ref \u2014 never paste a secret into a builder command. For Google-backed tools, inspect the provider readiness shown in Settings or the builder: not connected, missing a credential (reported for a connected or a failing row alike), connected but untested, connected and tested, or failed. Use \`integration.test\` / \`rost_test_integration_connection\` or the builder Test connection action to refresh the same safe status facts; the builder's Test connection action is disabled with an explanatory note while the credential is missing, since there is nothing to test until you reconnect. Do not infer authorization from a connected credential.
 7. **Operating instructions** \u2014 the runtime composes the agent's context from its Charter; you do not write a system prompt.
 8. **Model** \u2014 select the structured model config (see below). Read \`{{cli}} model list\` / \`model.catalog\` first when you are unsure; it returns the recommended default, effort, token price estimates, cost band, and best-fit work for each tier. If \`agent.create_custom\` omits \`model_config\`, {{brand}} recommends a tier from the supplied responsibility answers.
 9. **Heartbeat** \u2014 set the schedule (\`schedule_cron\`) for a recurring agent; a live scheduled agent must keep a steward chain.