@rosthq/cli 0.7.138 → 0.7.140

package/dist/index.js

@@ -52427,7 +52427,7 @@ var referenceDocuments = [
     order: 10,
     title: "{{brand}} implementation method",
     summary: "The staged operating-system setup path used by humans, CLI sessions, MCP clients, and in-app agents.",
-    version: "2026-07-30.2",
+    version: "2026-07-30.3",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -52560,6 +52560,8 @@ The Compass is drafted, then activated by a human through supersession.
 
 \`onboarding.setup\`, \`onboarding.finish\`, \`compass.approve_version\`, \`compass.reject_draft\`, and \`compass.set\` are \`human_required\`. \`onboarding.source_ingest\` is a bootstrap-safe \`none\` prerequisite that retains bounded source bytes encrypted under the exact tenant/run, computes its digest and canonical parser manifest server-side, and remains permanently outside Trusted and Full Operator. \`onboarding.setup\` is the one-approval composite apply: it freezes the complete plan and live proof at staging, then rechecks them and applies Compass, cycle, Responsibility Graph, Charters, staffing, goals, Signals/readings, Frictions, tasks, and Sync scope in one transaction. A failure rolls back the entire application and leaves the confirmation pending.
 
+Both commands fail closed on a missing server capability (for example unconfigured document-source storage) with a named, owner-facing remediation string that says what to do next \u2014 never a bare error code or a raw configuration value. \`onboarding.source_ingest\` checks this before decoding the uploaded source; \`onboarding.setup\` checks it before any plan-shape or Responsibility Graph foundation validation runs, so the block happens as early as the command can report it. The web onboarding entry screen surfaces the same deployment-wide readiness state before an owner invests in the flow.
+
 The whole composite flow has first-class CLI verbs: \`{{cli}} onboard source-ingest --file <path> ...\` for each allowed local source, \`{{cli}} onboard setup --input-file <plan.json>\` to stage the one owner approval (it prints the confirmation id and exact approval URL), \`{{cli}} onboard setup-status --input-file <plan.json>\` to discover the applied receipt by idempotent re-submission of the identical plan, then \`{{cli}} onboard rehearse\` and \`{{cli}} onboard activate\`. Each authenticates with the implementation-bootstrap credential first and falls back to the user session; the generic \`{{cli}} command <id> --json\` path and the generated MCP tools expose the same schemas.
 
 After setup succeeds, call \`onboarding.rehearse\` with the exact setup application, expected setup digest/revision, and a caller idempotency key. This is the implementation principal's one bounded \`execute\` exception: it is ungated because it can run only the setup receipt's exact agents in the sandbox, with no schedule arming, go-live transition, credential access, source mutation, or external communication. It rechecks the current Charter manifest, pinned published Skill versions and content hashes, schedule, execution lane, and canonical configuration digest under the same tenant/run boundary. A complete batch returns an immutable terminal batch receipt plus one immutable per-agent receipt with nonzero checked counts, runtime run ids, bounded tool previews/manifest holds/errors, and \`passed\` or \`failed\` status. Same-key/same-configuration retry returns that terminal evidence; a changed configuration conflicts instead of silently reusing it. The rehearsal never returns an approval URL and never stages activation. The later, separate \`onboarding.activate\` command consumes that exact terminal batch and the unique run/configuration evidence for the setup receipt's complete agent set. It stages one owner approval whose durable card shows every agent, Seat, Charter/configuration digest, rehearsal run, effective lane/model, permissions, schedule, warnings, and the onboarding-completion effect. Approval rechecks the full projection, records one composite human decision, makes every agent live, arms eligible schedules, and completes onboarding atomically. Any stale or failed member rolls the transaction back; same-key retry returns the committed receipt without duplicating effects.