@rosthq/cli 0.5.1 → 0.5.2

package/dist/index.js

@@ -27775,7 +27775,7 @@ function date4(params) {
 config(en_default());
 
 // src/redact.ts
-var KEYED_SECRET_PATTERN = /((?:authorization|token|secret|password|api[_-]?key|connection[_-]?string|database[_-]?url)["'\s:=]+)([^\s"',}]+)/gi;
+var KEYED_SECRET_PATTERN = /((?:authorization|token|secret|password|api[_-]?key|connection[_-]?string|database[_-]?url)["']?\s*[:=]\s*["']?)([^\s"',}]+)/gi;
 function redactSecrets(value) {
   return value.replace(/(Bearer\s+)([A-Za-z0-9._~+/=-]+)/gi, "$1[redacted]").replace(KEYED_SECRET_PATTERN, "$1[redacted]").replace(/([a-z][a-z0-9+.-]*:\/\/[^:@/\s]+:)([^@/\s]+)(@)/gi, "$1[redacted]$3");
 }
@@ -42110,11 +42110,13 @@ Agents can recommend, draft, prepare, check, classify, summarize, and execute ap
 A seat-scoped MCP token or the CLI runs the hand-shaped protocol. The server still checks the seat's manifest, Charter, task ownership, and tenant boundary.
 
 1. Context: \`rost_get_context\` (or read \`rost://seat/<seat-id>/context\`) \u2014 Charter, Compass, goals, open tasks, open issues, protocol.
-2. Tasks: \`rost_get_tasks\` / \`{{cli}} task list\`, then \`rost_accept_task\` / \`rost_decline_task\` (with a \`reason\`).
-3. Report: \`rost_report_status\` / \`{{cli}} status record\` as work progresses; \`rost_log_work\` to record evidence.
-4. Finish: \`rost_complete_task\` / \`{{cli}} task complete\` with evidence.
+2. Tasks: \`rost_get_tasks\` / \`{{cli}} task list --seat <seat-id>\`, then \`rost_accept_task\` / \`rost_decline_task\` (with a \`reason\`).
+3. Report: \`rost_report_status\` / \`{{cli}} status record --seat <seat-id>\` as work progresses; \`rost_log_work\` to record evidence.
+4. Finish: \`rost_complete_task\` / \`{{cli}} task complete --seat <seat-id>\` with evidence.
 5. Surface problems: \`rost_file_issue\` (Friction) and \`rost_escalate\` when the work exceeds autonomous scope.
 
+A seat-scoped MCP token already carries the seat, so its tools (\`rost_get_tasks\`, \u2026) need no seat argument. A tenant or owner CLI **session** does not, so pass \`--seat <seat-id>\` on seat-operating wrappers (an owner can target any seat in the tenant; a member only a seat they occupy). See "Seat scope" below.
+
 \`task.accept\`, \`task.decline\`, and \`task.complete\` are \`human_required\` for the acting human on the seat; \`status.record\`, \`work.log\`, and \`escalation.raise\` are not gated. An agent never approves a confirmation on behalf of a human.
 
 ## What humans should review
@@ -43706,7 +43708,7 @@ A consultancy's purpose might be "Make expert tax guidance affordable for first-
     ],
     body: `# Charter authoring deep-dive
 
-A Charter is a seat's executable operating contract. On the CLI and MCP path you author the **full document** and submit it directly with \`charter.update_draft\` (edit an existing draft) or \`charter.set\` (create-or-replace in one call). The server validates the whole document against the Charter schema and stores it; it does not re-synthesize it. Read the exact contract first with \`command.describe\` (\`{{cli}} command schema charter.update_draft\`), which returns the JSON Schema and a validated worked example. The companion charter-design-playbook covers the narrative; this guide covers every field of the document.
+A Charter is a seat's executable operating contract. On the CLI and MCP path you author the **full document** and submit it directly with \`charter.update_draft\` (edit an existing draft) or \`charter.set\` (create-or-replace in one call). The server validates the whole document against the Charter schema and stores it; it does not re-synthesize it. Two internal-ish fields (\`unanswered_boundaries\`, \`seat_type_recommendation\`) are optional \u2014 omit them and the server fills them conservatively; everything else you author. Read the exact contract first with \`command.describe\` (\`{{cli}} command schema charter.update_draft\`), which returns the JSON Schema and a validated worked example. The companion charter-design-playbook covers the narrative; this guide covers every field of the document.
 
 ## Field-by-field
 
@@ -43720,8 +43722,8 @@ A Charter is a seat's executable operating contract. On the CLI and MCP path you
 - **measurables** (1+) \u2014 each \`{ name, target, cadence, source }\`. A measurable must measure the accountability, not vanity. \`cadence\` is \`daily|weekly|monthly|quarterly\`; \`source\` is \`human|agent|integration\`. Agent-sourced readings are unconfirmed until a human confirms them.
 - **permission_manifest** \u2014 each \`{ tool, scope, granted, rationale }\`. Map each accountability to the narrowest tool scope that performs it. Prefer draft/read scopes; a send or spend scope is a deliberate, justified grant. The manifest is what the tool-guard enforces and what a human signs.
 - **budget** \u2014 \`{ monthly_usd, approval_required_over_usd, notes }\`. \`monthly_usd\` may be \`null\` (no autonomous budget). \`approval_required_over_usd: 0\` means any spend needs approval. State the rule in \`notes\`.
-- **unanswered_boundaries** \u2014 the open questions about this seat's authority you have not resolved. Naming them keeps them conservative instead of silently autonomous.
-- **seat_type_recommendation** \u2014 \`{ recommendation, rationale, confidence }\` where recommendation is \`human|agent|hybrid\`. Reason from the work: high-volume, rule-bound, reviewable work suits an agent under a Steward; judgment-heavy or relationship work stays human; split work is hybrid.
+- **unanswered_boundaries** (optional) \u2014 the open questions about this seat's authority you have not resolved. Naming them keeps them conservative instead of silently autonomous. **You may omit this field**; the server defaults it to \`[]\` (and still records any boundary you flag inline via \`unanswered_boundary: true\` on an authority item).
+- **seat_type_recommendation** (optional) \u2014 \`{ recommendation, rationale, confidence }\` where recommendation is \`human|agent|hybrid\`. Reason from the work: high-volume, rule-bound, reviewable work suits an agent under a Steward; judgment-heavy or relationship work stays human; split work is hybrid. **You may omit this field**; the server defaults conservatively to \`human\` until a human decides otherwise. Supply it when you have a clear recommendation.
 
 ## The full JSON shape
 
@@ -43752,17 +43754,17 @@ A Charter is a seat's executable operating contract. On the CLI and MCP path you
   "permission_manifest": [
     { "tool": "ap.invoices.read", "scope": "Read inbound invoices and the vendor ledger.", "granted": true, "rationale": "Needed to draft entries from source invoices." }
   ],
-  "budget": { "monthly_usd": null, "approval_required_over_usd": 0, "notes": "No autonomous spend; any spend requires Steward approval until a budget is set." },
-  "unanswered_boundaries": ["Approval threshold for auto-posting"],
-  "seat_type_recommendation": { "recommendation": "agent", "rationale": "High-volume, rule-bound, fully reviewable work suits a draft-and-confirm agent under a human Steward.", "confidence": 0.8 }
+  "budget": { "monthly_usd": null, "approval_required_over_usd": 0, "notes": "No autonomous spend; any spend requires Steward approval until a budget is set." }
 }
 \`\`\`
 
+This worked document **omits** \`unanswered_boundaries\` and \`seat_type_recommendation\` \u2014 both are optional. The server fills them conservatively on submit (\`unanswered_boundaries\` defaults to \`[]\`, picking up anything you flagged inline with \`unanswered_boundary: true\`; \`seat_type_recommendation\` defaults to \`human\`). Supply either field when you have a concrete value and it is respected as-is. Everything else is required.
+
 ## Three worked seats
 
-- **Human seat (Head of Sales).** Purpose centers on judgment and relationships. Almost everything is autonomous within budget; approval covers discounts past a threshold; escalate covers contract terms outside policy. Measurables are human-sourced (pipeline, close rate). \`seat_type_recommendation\` is \`human\`.
-- **Agent seat (AP intake clerk).** The example above. Tight autonomous scope (draft only), approval for posting/sending, escalation for unknown vendors and large amounts, an explicit draft-only permission manifest, and \`approval_required_over_usd: 0\`. \`seat_type_recommendation\` is \`agent\`.
-- **Hybrid seat (Customer success).** Split the work: the agent drafts renewal summaries and flags at-risk accounts autonomously; the human owns the renewal conversation and any concession. Approval covers anything customer-facing being sent; escalate covers churn risk and credits. \`seat_type_recommendation\` is \`hybrid\` with a rationale naming the handoff.
+- **Human seat (Head of Sales).** Purpose centers on judgment and relationships. Almost everything is autonomous within budget; approval covers discounts past a threshold; escalate covers contract terms outside policy. Measurables are human-sourced (pipeline, close rate). Supply \`seat_type_recommendation: { "recommendation": "human", \u2026 }\`, or omit it \u2014 the server defaults to \`human\`.
+- **Agent seat (AP intake clerk).** The example above. Tight autonomous scope (draft only), approval for posting/sending, escalation for unknown vendors and large amounts, an explicit draft-only permission manifest, and \`approval_required_over_usd: 0\`. Supply \`seat_type_recommendation: { "recommendation": "agent", \u2026 }\` so the seat is recommended as an agent under a human Steward.
+- **Hybrid seat (Customer success).** Split the work: the agent drafts renewal summaries and flags at-risk accounts autonomously; the human owns the renewal conversation and any concession. Approval covers anything customer-facing being sent; escalate covers churn risk and credits. Supply \`seat_type_recommendation\` as \`hybrid\` with a rationale naming the handoff.
 
 ## Authoring workflow and the human gate