@hireobi/cli 0.1.8 → 0.1.10

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hireobi/cli",
-  "version": "0.1.8",
+  "version": "0.1.10",
   "description": "Obi, the AI Search Employee: CLI and Skill for your AI assistant",
   "keywords": [
     "obi",

package/skills/obi/SKILL.md

@@ -33,7 +33,7 @@ Obi remembers what the customer tells it to remember, across hosts and sessions:
 
 Check `obi capabilities --json`, then `obi memory list --json`. Keep the account context established by the conversation or CLI result. For the ordinary connected business, use `obi status --json` and work commands without `--eval-case`; do not look for an evaluation ID. Only an explicitly established public-company evaluation uses `--eval-case <id>` on every account or work read and write, including `status`. `obi eval list --json` recovers a missing ID for that already selected evaluation; a missing ID alone never establishes one. If the machine is unconnected, follow [connection](references/connection.md). If the customer names a public company to evaluate, use its domain only after they choose it inside this conversation. An eligible operator starts an isolated case with `obi eval start <domain> --json`. Never use the ordinary account's old results for a new domain.
 
-When no domain is chosen, offer to continue the connected company's saved work or evaluate a new public domain. Ask once for the research mission: the domain, intended buyer or market if known, and whether you may read its public pages and relevant public competitors. Within that scope, continue routine public reads and checks autonomously. Read [adaptive research](references/host-work.md#adaptive-research-and-tool-recovery) for priority-page understanding, tool discovery, interrupted inventories or a missing search/browser capability.
+When no domain is chosen, offer to continue the connected company's saved work or evaluate a new public domain. Ask once for the research mission: the domain, intended buyer or market if known, and whether you may read its public pages and relevant public competitors. Before any work is spent, run the [fit check](references/fit-and-scope.md): say plainly when the market is not measured or Obi is a weak fit, instead of proceeding. When the customer asks for several audiences, markets or languages, give the [one-scope answer](references/fit-and-scope.md#several-audiences-markets-or-languages). Within that scope, continue routine public reads and checks autonomously. Read [adaptive research](references/host-work.md#adaptive-research-and-tool-recovery) for priority-page understanding, tool discovery, interrupted inventories or a missing search/browser capability.
 
 Read `obi harness coverage --json` for the selected case before new Business work. If the account is inactive and `eligibleForFreeActivation` is true, the customer's agreed public-research mission includes activating the new Free plan with `obi harness activate --free --json`; show the actual question and engine coverage returned by that plan. An existing active plan needs no activation. If eligibility is false, keep its historical coverage and explain that an offer migration is separate. Activation does not start a scan. If its response is lost, read `harness coverage` before another activation attempt. When the customer wants to buy or change packs or engines, or evidence shows a gap the plan does not measure, read [purchase](references/purchase.md).
 
@@ -51,6 +51,10 @@ When the customer reports an implemented action, read [outcome observations](ref
 
 Lead with the outcome, material uncertainty and one useful next action. On an interrupted job, reread the same case and stage; report meaningful progress or a blocker, use the server's next poll time when available, and retain the work ID. A timeout on a write calls for a read before any retry. Reuse the same replay key for an identical result; a changed result needs the current work version and a new key.
 
+When a failure cannot be recovered in this conversation (the same error after the retry its `nextAction` names, or `obi doctor --json` reporting `server` as `degraded` or `unreachable`), say so and offer once to send it to Obi support. On the customer's yes, run `obi support "<what happened, in their words>" --json`: it adds the CLI version, the system and the last error code itself. When it fails with `SUPPORT_NOT_SENT`, nothing was sent: give them support@hireobi.com and the `support.diagnosticText` to paste. Never put a token or a credential file in the message.
+
+When a CLI result carries `update` (or stderr says a newer Obi CLI is available), tell the customer in one sentence, once per conversation, and offer to update it for them. Run `update.command` (`npm i -g @hireobi/cli`) only on their yes, then run `obi` once so the Skill links refresh, and ask them to open a new chat if this one keeps the old Skill. Without a yes, carry on with the current version. `CLI_UPDATE_REQUIRED` means the service refuses this version: say so, offer the same update, and retry the command after it.
+
 Separate site observations, customer confirmations, host inferences and independently measured answers. Request only the private extracts needed for the agreed scope; keep secrets and unrelated workspace material local. A local draft or patch is a reviewable suggestion until the customer accepts it. The Skill runs when invoked; while the harness is closed, saved server measurements can continue but host research and reasoning wait for resumption.
 
 Stay in customer mode even inside the Obi source repository. A product-use failure is explained and recovered in this conversation. Open a development task, branch or pull request only after an explicit separate software-development request.

package/skills/obi/references/fit-and-scope.md

@@ -0,0 +1,32 @@
+# Fit, markets and scope
+
+Read before the first research of a business, and when the customer asks for several audiences, markets or languages. Obi says what it cannot measure before any work is spent, and never stretches one scope to cover several.
+
+## Fit check, before any work
+
+Judge the fit from the domain, the customer's words and one read of the home page, before activating a plan or starting research. `obi capabilities --json` lists the markets Obi measures in `measurementMarkets`; name them from that list.
+
+| What you see | What you say | What you do next |
+|---|---|---|
+| The buyers are in a market outside `measurementMarkets` | "Obi does not measure <market> yet. It measures in: <the names from `measurementMarkets`>." | Ask whether they also sell in a listed market. If yes, offer that market as the scope and say the answers will describe that market only. If no, stop there. Either way, offer to record the request: `obi support "<market>, <domain>" --tag market-request --json`. |
+| The buyers search in a language no listed market uses | The same sentence, naming the language and the markets. | The same two offers. |
+| No AI-search buying journey: buyers choose without asking an assistant (an impulse or habit purchase, a walk-in local trade, a sale won only by tender or by marketplace listing) | "Obi is a weak fit for <business>: <the reason from what you read>. It measures what AI assistants answer to buyers who research before choosing." | Say what would change the verdict (a product line buyers research, a business customer segment). Continue only when the customer names such a segment or still asks for the Free measurement; then say what the scan will not show. |
+| The company has no public pages to read, or blocks them | "Obi reads public pages; it cannot ground questions without them." | Ask for the public domain that carries the offer; without one, stop. |
+
+`obi support` sends only from a signed-in machine. When it fails with `SUPPORT_NOT_SENT`, as for a prospect who has no account yet, give them support@hireobi.com and the `support.diagnosticText` to paste.
+
+A weak fit is a judgment you state with its evidence, as [business judgment](business-judgment.md) describes; the customer may correct the fact it rests on. Say it once, in one or two sentences, then the one next action. A supported market with a clear buying journey needs no fit statement.
+
+When the server answers `MARKET_UNSUPPORTED` to a questions submission, the same rule applies: say it plainly, name the markets, offer the request.
+
+## Several audiences, markets or languages
+
+One scope is one market, one primary audience and one measured language: the language buyers of that market use. An account holds one scope; packs add questions inside it. There is no second scope on an account today, so it has no price.
+
+When the customer asks for more (for example three ICPs, or three languages), answer in this order:
+
+1. The rule, in one sentence: "Obi measures one scope per account: one market, one primary audience, in that market's language. More packs add questions for that scope; they do not add a second one."
+2. Your recommendation of the primary scope, with its reason from the evidence: the segment the pricing page, customer stories and hiring serve, or the market where the measured rivals compete. Recommend one; ask only for confirmation.
+3. What still covers the others inside one scope: a secondary segment stays in the business review, and the three to five buyer profiles of the [cold and context pairs](questions.md#buyer-profiles-and-the-coldcontext-pairs) vary the personas of the primary audience.
+4. The limit, plainly: "A second market, audience or language on the same account is not available yet." Offer to record the request: `obi support "<the scopes wanted>" --tag scope-request --json`.
+5. Save the confirmed choice: `obi memory add --kind decision --text "<their words>" --json`.

package/skills/obi/references/purchase.md

@@ -1,6 +1,6 @@
 # Buying paid packs
 
-Read when the customer wants to buy packs or change the packs or engines of a paid plan, and before proposing a change yourself. Buying happens in this conversation, where the customer reviews the questions each pack will measure; the `/billing` page shows the plan and keeps cards, invoices and cancellation. Every price you show comes from the server's quote response.
+Read when the customer wants to buy packs or change the packs or engines of a paid plan, and before proposing a change yourself. Buying happens in this conversation, where the customer reviews the questions each pack will measure; the `/billing` page shows the plan and keeps cards, invoices and cancellation. Every amount the customer agrees to pay comes from the server's quote or preview response.
 
 Only the owner of the connected business account buys, with a verified email; a public-company evaluation case cannot.
 
@@ -70,7 +70,38 @@ A change that adds and removes at once (`PLAN_CHANGE_TWO_STEPS`) runs in two ste
 
 ## Proposing a change yourself
 
-When evidence shows a gap the plan does not measure, such as a buying situation outside the reviewed questions or a rival cited on questions the plan leaves out, propose the change once, with that evidence and the price from a quote or preview. After a no, raise it again only on new evidence.
+Propose a change only when a measurement shows a gap the plan does not cover. Each trigger needs its evidence from the saved results (`obi questions results --json`, `obi harness evidence`), named by question and date:
+
+| Trigger | Measured evidence it needs | What you propose |
+|---|---|---|
+| Perplexity | On research-style buying questions (comparisons, alternatives, "which should we use"), the scan's answers name rivals with cited sources while the company is absent or uncited. | Perplexity on those questions, 1 to 10 per pack. |
+| Claude | The confirmed primary audience is technical or B2B, and on the same measured buying questions the engines already disagree on the brands they name. Where Claude is already measured on some questions, its answers differ from the other engines on them. | Claude on those buying questions, 1 to 10 per pack. |
+| More packs | Buying situations in the evidence (a confirmed segment's situations, a rival's angle, the sources the answers cite) that no reviewed question covers, while every current question covers a distinct one. | One more pack, with the situations it would add. |
+| Paid from Free | Two monthly scans differ (a rival enters or leaves the answers, the company's presence changes) and nothing dates the change inside the month, or the customer reported an action whose effect the next monthly scan would show weeks late. | The first pack, for its weekly scan. |
+
+The host's own answer to a question is never this evidence, and an engine the plan does not measure has no measured answers to cite.
+
+A proposal is one sentence of evidence, the price, one question. Cite the server's price whenever a quote is possible; both commands below charge nothing:
+
+| Plan and change | Price to cite |
+|---|---|
+| A paid plan, adding an engine on questions it already measures | Write the quote file of the new plan and run `obi harness purchase change --input <file> --json` ([changing a paid plan](#changing-a-paid-plan), step 2): cite `amountDueCents` now and the new `quote.monthlyAmountCents`. |
+| No paid plan, with a reviewed set of 25 questions per pack | `obi harness purchase quote --input <file> --json`: cite `monthlyAmountCents`. |
+| The change needs questions not reviewed yet (one more pack, a first pack without a reviewed set) | No quote is possible yet: cite the list price below, labelled "list price", and offer to prepare the questions and the quote. |
+
+The list price is what the change adds each month, computed from `obi capabilities --json` (`catalog.monthlyCents`) and the plan in `obi harness coverage --json`:
+
+| Change | Monthly amount it adds |
+|---|---|
+| An engine on a paid plan | Its per-pack amount times the packs of the plan (`plan.questionCount` divided by 25). |
+| One more pack | `corePack`, plus the per-pack amount of each engine already on the plan (an engine whose `plan.engineQuestionCounts` is above zero). |
+| The first pack from Free | `corePack`. |
+
+A list price is before any discount on the account; the quote or preview confirms the exact amount before any yes to pay. For example: "On 6 of your 10 comparison questions, the 3 November scan cites <rival> with sources and never you. Perplexity on those questions adds <monthlyAmountCents difference> a month, <amountDueCents> today. Shall I apply it?"
+
+- Propose once per gap, and at most one proposal in a reply. After a no, save it (`obi memory add --kind decision --text "<their words>" --json`) and raise that gap again only on new evidence: a later scan, a reported outcome, a corrected business fact.
+- Optional engines are never filled to quota: propose the buying questions the evidence names, however few.
+- No proposal while a failure is unresolved, before the first results exist, or as the answer to a question the customer asked about something else.
 
 ## What waits for the customer
 

package/skills/obi/references/questions.md

@@ -1,6 +1,6 @@
 # Buyer questions, scan and priorities
 
-After the business review is confirmed, inspect `obi harness show --stage questions --json`. Show the supported measurement markets and confirmed buyer audiences from its work context. Ask the customer to choose one market and one primary audience; a suggested market is guidance, not consent or a default. Prepare the displayed coverage count in the host and save it with the versioned `harness submit --stage questions --input <file> --json` path described in [host work](host-work.md). `obi questions show --json` reads the accepted set and its preparation state. A queued or running state means wait and inspect again after meaningful progress; do not announce that questions already exist.
+After the business review is confirmed, inspect `obi harness show --stage questions --json`. Show the supported measurement markets and confirmed buyer audiences from its work context. Ask the customer to choose one market and one primary audience; a suggested market is guidance, not consent or a default. When they ask for several, give the [one-scope answer](fit-and-scope.md#several-audiences-markets-or-languages). Prepare the displayed coverage count in the host and save it with the versioned `harness submit --stage questions --input <file> --json` path described in [host work](host-work.md). `obi questions show --json` reads the accepted set and its preparation state. A queued or running state means wait and inspect again after meaningful progress; do not announce that questions already exist.
 
 ## Writing the questions