@skhema/cli 0.4.3 → 0.4.5

package/skills/skhema-operate/references/author-elements.md

@@ -0,0 +1,158 @@
+# Author elements in the environment
+
+Elements are the unit of strategy in Skhema: one typed judgment, decision,
+or thing. This capability is about getting well-formed elements INTO a
+workspace and keeping them clean. The thinking — what the challenge is, how
+to phrase the policy — is the practice skills' job (`skhema-frame`,
+`skhema-compose`). Do that first; then land it here.
+
+## Before you write anything
+
+1. **Know the workspace.** Set it once: `skhema workspace use <id>`. Every
+   command below then omits `--workspace`.
+2. **Know the component it belongs in.** Elements live inside components,
+   and components follow the five-part flow: Diagnosis → Method &
+   Positioning → Portfolio of Initiatives → Measures → Support Structures.
+   List what exists: `skhema component list`. Create one if needed:
+   `skhema component create --type diagnosis --name "Diagnosis"`.
+3. **Know the element's type and its expected mood.** Every element type
+   carries an expected grammatical mood. If the content doesn't match the
+   mood, the type is wrong:
+   - **indicative** — a claim about the world (judgments): key_challenge,
+     supporting_fact, impact, competitor_move, constraint,
+     assumption_hypothesis, estimate, baseline.
+   - **imperative** — a command (decisions to act): guiding_policy, scope,
+     experiment, action, principle.
+   - **noun_phrase** — a thing: solution, investment, outcome,
+     performance_variable, capability, system.
+
+   Plain check: is this element stating something you believe is TRUE,
+   something you've decided to DO, or NAMING a thing? A `guiding_policy`
+   phrased as a wish ("we want to be the leader") is mistyped — a policy is
+   a command ("compete only on integration depth, never price").
+
+## Placement is enforced — and it is not the same question as mood
+
+Two different questions; don't conflate them. **Mood** (step 3) tells you how
+to *write* the element — indicative for a judgment, imperative for a command,
+a noun phrase for a thing. It is a check on the sentence. **Placement** tells
+you *where the element is allowed to live*, and the platform enforces a strict
+type→component allow-list that does NOT follow mood. Put a type in the wrong
+component and `element create` rejects it. There is no discovery command for
+this; the allow-list is:
+
+| Component | Element types it accepts |
+|---|---|
+| Diagnosis | key_challenge, supporting_fact, impact |
+| Method & Positioning | guiding_policy, competitor_move, scope, constraint |
+| Portfolio of Initiatives | solution, assumption_hypothesis, experiment, action, estimate, investment |
+| Measures | baseline, outcome, performance_variable |
+| Support Structures | capability, system, principle |
+
+Where this bites if you place by mood: `constraint` is a claim about the world
+but lives in **Method**, not Diagnosis. `assumption_hypothesis` and `estimate`
+are judgments but live in the **Portfolio of Initiatives** — so an evidence-gap
+assumption goes in the Portfolio, not Diagnosis, even though it feels
+diagnostic. Place by this table, then flag the semantic oddity in the element's
+`reasoning`.
+
+## Create one element
+
+Quick path — flags:
+
+```sh
+skhema element create \
+  --component-type diagnosis \
+  --element-type key_challenge \
+  --content "Enterprise buyers churn at renewal because onboarding never proved value."
+```
+
+Full-payload path — for anything richer than content + types, write JSON and
+pipe it. This avoids shell-quoting pain and lets you set fields the flags
+don't cover:
+
+```sh
+skhema element create --file ./element.json
+cat element.json | skhema element create --file -
+```
+
+Use `--json` on the command to get back `{ ok, command, data }`; read
+`data.id` for the new element id.
+
+## Edit an element
+
+```sh
+skhema element update <element-id> --content "Sharper restatement of the same judgment."
+skhema element update <element-id> --file ./patch.json
+```
+
+Change the type when the content's mood shifts — e.g. a `key_challenge` that
+you've now decided how to attack becomes a separate `guiding_policy`
+element, not a retyped one. One element, one judgment; don't overload.
+
+## Write good element content
+
+- **One judgment per element.** If content contains an "and" joining two
+  claims, split it into two elements and link them.
+- **Falsifiable, not vague.** "Improve customer experience" is not a
+  challenge; "first-response time exceeds 48h for 40% of tickets" is.
+- **Evidence separate from claim.** A `supporting_fact` cites; a
+  `key_challenge` asserts. Don't smuggle the evidence into the challenge.
+- **State it so a second reader reads it the same way.** Ambiguity here
+  becomes disagreement three components downstream.
+- **Meta-annotations go in `reasoning`, never in `content`.** Evidence-gap
+  notes, pre-mortem provenance ("surfaced by the competitor pre-mortem"),
+  tripwire conditions, confidence caveats — none of that belongs in `content`.
+  `content` is the clean claim a reader sees in the workspace; `reasoning` is
+  where you record why the element is there and what's shaky about it.
+
+## Link elements to show the reasoning
+
+Elements gain meaning from their relationships. A policy addresses a
+challenge; a measure tracks an outcome. Make those explicit:
+
+```sh
+# link create takes --source/--target flags; notes go in a --file payload:
+echo '{"sourceElementId":"<policy-id>","targetElementId":"<challenge-id>","notes":"policy addresses this challenge"}' > link.json
+skhema link create --file link.json
+skhema link create --file ./link.json
+```
+
+Two things about links as they stand today:
+
+- **`--type` is accepted but not persisted.** The stored link keeps only
+  `sourceElementId`, `targetElementId`, `confidenceLevel`, `notes`, and
+  `status` — no type field. Don't rely on `--type` to carry `addresses` /
+  `tracks` / `supports`; put the relationship's meaning in `notes` as plain
+  text.
+- **Element links have no read path.** There is no `skhema link list`. You can
+  create, update, and delete a link but not enumerate links later, so you
+  cannot reconstruct the reasoning graph from links after the fact. Capture
+  anything you'll need later in the element's `reasoning` or the link's `notes`
+  at write time.
+
+## After authoring: validate
+
+Don't declare an element done because it saved. Run the validation loop —
+`references/validation-loop.md` — to check completeness and coherence, read
+the diagnostics, and revise. Authoring and validating are one cycle, not two
+steps.
+
+## Attach evidence as resources
+
+A claim backed by a document is stronger than one that isn't. Attach files,
+URLs, or citations to the element:
+
+```sh
+skhema resource upload ./market-study.pdf --element <element-id> --attribution "Q2 buyer survey"
+skhema resource list --element <element-id>
+```
+
+## Verify attachment after create
+
+The create response is `{ element: {…}, componentId: "…" }` — the attachment
+proof is the **top-level `componentId`**, NOT `element.componentId` (that
+nested field is always null; checking it reports a false orphan on every
+create). A null top-level `componentId` means the element was created but
+attached to nothing — stop, note the element id, and don't retry into that
+component (known platform bug).

package/skills/skhema-operate/references/navigate.md

@@ -0,0 +1,110 @@
+# Find things in a workspace
+
+Before you change or reason about a strategy, you have to locate it. This
+capability is the reading half of the environment: which workspace, what's
+in it, where a thing lives, and what a strategy actually contains.
+
+## Start at the workspace
+
+```sh
+skhema workspace list                 # every workspace you can reach
+skhema workspace get <workspace-id>   # one workspace's detail
+skhema workspace use <workspace-id>   # set it as default; drop --workspace after
+```
+
+If you're unsure which workspace holds the thing you want, `list` first and
+read the names. Everything below assumes a default is set (or you pass
+`--workspace <id>`).
+
+## The hierarchy, top to bottom
+
+```
+workspace
+└── component        (Diagnosis, Method & Positioning, Portfolio, Measures, Support)
+    └── element      (one typed judgment / decision / thing)
+        ├── link         (element → element: addresses, supports, tracks…)
+        └── resource     (files, URLs, citations backing the element)
+strategy             (a committed snapshot of elements/components)
+```
+
+Learn the shape of a workspace by walking it:
+
+```sh
+skhema component list                  # the five-part structure in this workspace
+skhema element list                    # CAUTION: org-corpus read — see below
+skhema document list                   # workspace documents (correctly scoped)
+skhema component-link list             # component-to-component relationships
+```
+
+## Search instead of scrolling
+
+When you know roughly what you're after but not where it is, search beats
+listing. It's full-text over the workspace's elements:
+
+```sh
+skhema element search "renewal churn" --limit 10
+skhema element search "pricing" --workspace <id>
+```
+
+Use search to answer "have we already said this somewhere?" before authoring
+a duplicate, and to find the element an id-less request refers to ("update
+the onboarding challenge").
+
+## Read one thing in full
+
+```sh
+skhema element get <element-id>        # content, type, and metadata
+skhema resource list --element <id>    # what evidence is attached
+```
+
+There is no read path for element-to-element links: you can create links but
+not enumerate them, so you cannot list "what connects to this element" after
+the fact. Capture relationship context in the element's `reasoning` (or the
+link's `notes`) at write time — you can't recover it from the links later.
+Component-to-component links *do* have a read path (`skhema component-link
+list`).
+
+Reconstruct the argument, not just the parts, by reading each element's
+`reasoning` and walking the five components in order (Diagnosis → Method →
+Portfolio → Measures → Support). Because element links can't be enumerated, the
+`reasoning` field and the component structure — not a link graph — are how you
+rebuild why each element is there.
+
+## Read a whole strategy
+
+A strategy is a committed set of elements — the durable, shareable artifact.
+
+```sh
+skhema strategy list                   # strategies in the workspace
+skhema strategy get <strategy-id>      # the strategy WITH its committed elements
+```
+
+`strategy get` is the fastest way to see "what did we actually commit to?"
+as one object, versus the live, in-progress elements in the workspace.
+
+## Get results as data
+
+Add `--json` to any read command and parse the `{ ok, command, data }`
+envelope instead of scraping the human table. For agents this is the default
+posture: `data` on a `list` or `search` is an array you can iterate; `data`
+on a `get` is the object. Read ids off `data`, then act.
+
+## When a read returns nothing or the wrong org
+
+- Empty list where you expected content → wrong workspace (check
+  `skhema workspace use` / `--workspace`) or wrong org.
+- Right workspace, wrong org's data → the credential is bound to another
+  org. `skhema auth status`, then `skhema auth switch` (OAuth) or use the
+  right key. See `references/auth.md`.
+
+## Known platform gap: element reads are not workspace-scoped
+
+`element list` and `element search` currently return the ORGANIZATION's
+element corpus regardless of `--workspace` (first page = oldest elements,
+which is usually a different workspace's set). Until fixed:
+
+- Trust `component list` (correctly workspace-scoped; `elementCount` tells
+  you what's really in each component) and `element get <id>` (reliable
+  by id).
+- Track the ids of anything you create; never infer a workspace's contents
+  from `element list` output.

package/skills/skhema-operate/references/surfaces.md

@@ -0,0 +1,67 @@
+# Pick the right surface
+
+Skhema exposes the same environment through three surfaces. They are not
+ranked — each wins for a different situation. Pick before you start; the
+choice shapes how you authenticate, how you read results, and how you
+recover from errors.
+
+## The three surfaces
+
+**CLI — `skhema` in a terminal.** The default for an agent with shell
+access. One binary, the credential precedence and exit-code contract are
+built in, `--json` gives you a parseable envelope. Best for: interactive
+work, CI steps, shell-driven agents, one-off commands, anything scriptable.
+
+**Public API — `api.skhema.com/v1`.** Raw HTTP. Best for: code running
+inside an application (not a shell), a language without the CLI installed,
+or when you need a route the CLI doesn't wrap yet. It is self-describing —
+`GET /v1/openapi.json` returns the full live route surface. You still need
+a credential (an API key in the `Authorization` header, or a JWT obtained
+by key exchange).
+
+**MCP — Skhema tools inside the agent.** Best when you are already an agent
+in an MCP-capable host and want Skhema as native tools rather than shelling
+out. Registered by `skhema init` or `skhema-setup`. No terminal, no HTTP
+plumbing — the host handles auth and transport.
+
+## How to choose
+
+| Situation | Surface |
+|---|---|
+| You have a shell and the CLI is (or can be) installed | **CLI** |
+| You're inside application code, no shell | **Public API** |
+| The CLI doesn't wrap the route you need | **Public API** (`skhema api …` or raw HTTP) |
+| You're an MCP-host agent and want native tools | **MCP** |
+| CI pipeline step | **CLI** with `--api-key` or `SKHEMA_API_KEY` |
+| You need to discover what routes exist | **Public API** — `GET /v1/openapi.json` |
+
+When two fit, prefer the CLI: it centralises the credential precedence, the
+`{ ok, command, data|error }` envelope, and exit codes 0–5 so you don't
+reimplement them.
+
+## The CLI is a thin client over the same API
+
+`skhema element create` and `POST /v1/.../elements` do the same thing. So
+you can mix: script the common path with the CLI, and reach for a raw route
+only where the CLI has no wrapper. The escape hatch is built in:
+
+```sh
+skhema api routes                       # list every live gateway route
+skhema api GET /workspaces              # raw authenticated GET (leading /v1 optional)
+skhema api POST /workspaces --data @body.json
+skhema api GET /workspaces/<workspace-id>/elements --query limit=10
+```
+
+`skhema api` uses the same credential precedence as every other command, so
+you get authenticated raw access without hand-rolling headers. The gateway
+does NOT infer your organization from the path — the org comes from the
+credential (an API key's binding, or your consent-selected OAuth org). If a
+raw call returns the wrong org's data, fix the credential, not the path.
+
+## Don't fight the surface
+
+- Reading one field off one object from a shell → CLI, not raw HTTP.
+- Bulk work across hundreds of objects from app code → Public API, drive it
+  with real code, not a shell loop over the CLI.
+- Already have MCP tools bound → use them; shelling out from an MCP agent
+  just adds a credential you have to manage separately.

package/skills/skhema-operate/references/validation-loop.md

@@ -0,0 +1,84 @@
+# The validation loop
+
+An element that saved is not an element that's sound. Validation checks it
+for completeness and coherence, hands back diagnostics, and you revise until
+the judgments hold. This is a LOOP, not a final step — author, validate,
+read, revise, re-validate.
+
+## Budget first — validate is an AI action
+
+`skhema element validate` and `skhema element rephrase` run model
+inference server-side. They cost credits, unlike list/get/search which are
+cheap reads. Spend accordingly:
+
+- Don't validate after every keystroke. Author the element as well as you
+  can by hand first (right type, right mood, one judgment, falsifiable),
+  THEN validate.
+- Batch: get a component's worth of elements into decent shape, then
+  validate the ones that matter.
+- Re-validate only what you changed. If diagnostics flagged element A and
+  you edited A, re-validate A — not the whole component.
+
+## The loop
+
+**1. Validate.**
+
+```sh
+skhema element validate <element-id> --json
+```
+
+Read the `data` in the `{ ok, command, data }` envelope. It carries the
+diagnostics — completeness gaps and coherence problems.
+
+**2. Read the diagnostics as concrete defects.** Each finding maps to a
+fixable defect. Translate it before you act:
+
+- *Type/mood mismatch* — the content's mood doesn't match the element type
+  (a `guiding_policy` phrased as a wish, a `key_challenge` that's actually a
+  solution). Fix the wording OR change the type — whichever makes the mood
+  match the intent.
+- *Incompleteness* — a claim with no evidence, an outcome with no measure, a
+  policy that addresses no challenge. The fix is usually a NEW linked element
+  (a `supporting_fact`, a measure) plus a `skhema link create`, not an edit
+  to this one.
+- *Ambiguity / vagueness* — the content reads two ways, or uses a term that
+  isn't pinned down. Rewrite it so a second reader reads it once way only.
+- *Incoherence* — it contradicts or duplicates another element. Reconcile
+  the two: merge, delete one, or make the tension explicit.
+
+**3. Revise.** Edit directly, or ask the service to propose a rewrite:
+
+```sh
+skhema element update <element-id> --content "…the sharpened version…"
+# or, to get a model-proposed rephrase (also an AI action — costs budget):
+skhema element rephrase <element-id> --json
+```
+
+Treat `rephrase` output as a proposal, not a commit. Read it, decide, then
+`update` with the version you actually want. Don't chain rephrase→rephrase
+hoping it converges — that just burns budget.
+
+**4. Re-validate the changed element.** Repeat 1–3 until the diagnostics
+come back clean.
+
+## Stop conditions
+
+Stop the loop when EITHER:
+
+- Validation returns no material findings — the judgments hold. Done.
+- The remaining findings are ones you deliberately accept (e.g. an
+  assumption you know is unevidenced and have typed honestly as
+  `assumption_hypothesis`). Record why, and move on. Not every finding
+  demands a fix; some are the map telling the truth.
+
+Do NOT loop indefinitely chasing a perfect score. Two or three passes on a
+real element is normal; more than that usually means the element is trying
+to be two elements — split it and validate the halves.
+
+## Validate the whole before you commit
+
+Individual elements can each be sound while the strategy they form isn't.
+Before committing elements into a strategy (`skhema strategy commit`), walk
+the links (`references/navigate.md`) and check the cross-element story:
+every challenge has a policy, every outcome has a measure, nothing
+contradicts. Coherence is a property of the set, not the parts.

package/skills/skhema-pressure-test/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: skhema-pressure-test
+description: "Use when a strategy or a decision needs to survive contact with reality — attack it the way a competitor, a skeptical board, or an indifferent market will, before they do. This is the adversary's chair, not a self-check."
+---
+
+# Pressure-Test
+
+You play the adversary against the user's own strategy. Not to be cruel — to
+find the weak joints before reality does, while there's still time to fix them.
+
+This is the grill-me of strategy. You are the competitor who moves against
+them, the board member who won't fund hand-waving, the market that simply
+doesn't care. You attack. They defend. What survives is stronger; what breaks
+gets fixed today instead of in eighteen months.
+
+## What this is (and what it is not)
+
+Pressure-testing is deliberately hostile. That is the point. A strategy the
+author checks for tidiness (that is `skhema-calibrate` — the self-check) can
+still be perfectly consistent and completely doomed. Pressure-testing asks a
+different question: **not "is this coherent?" but "will this hold when someone
+wants it to fail?"**
+
+You are not the user's teammate right now. You are the thing standing between
+them and success. Stay in character.
+
+## The one rule that keeps it fair
+
+Relentless, but fair. **Every attack must name its defeater** — the specific
+evidence or decision that would kill the attack. "This won't work" is noise.
+"This assumes buyers switch for a 10% price gap; if they'd switch for 5% you're
+fine — do you know which it is?" is an attack, because it tells them exactly
+what would end the argument.
+
+An attack you cannot defeat with any conceivable evidence isn't an attack. Drop
+it. You are testing the strategy, not venting.
+
+## The three adversaries
+
+Pick the one that bites hardest for each attack.
+
+- **The competitor** — moves against them the day after they commit. Asks:
+  what do I do to make this fail? Where's the opening?
+- **The board skeptic** — controls the money and has seen a hundred decks.
+  Asks: where's the evidence? What happens if you're wrong? Why this and not
+  the obvious alternative?
+- **The market that doesn't care** — not opposition, indifference. Asks: why
+  would anyone change what they do today for this? What if they just... don't?
+
+## Ground rules for the ritual
+
+- One attack at a time. Let them answer before the next.
+- Attack the load-bearing claim, not the typo. Go where it hurts.
+- Steelman before you knife: attack the *strongest* version of their argument,
+  not a weak one you invented.
+- The output is decisions, not a scorecard. End by asking what they'll change.
+- Drop the adversary coat the instant they need help fixing something. You wear
+  it to find the wounds, not to gloat over them.
+
+## Capabilities
+
+| Capability | Route here when… | Reference |
+|---|---|---|
+| Full grill | They have a whole strategy and want it stress-tested end to end. | `references/full-grill.md` |
+| Decision grill | One decision or bet is on the table and they want it attacked hard. | `references/decision-grill.md` |
+| Pre-mortem | They want to surface failure modes they can't yet see — imagine it already failed. | `references/pre-mortem.md` |
+
+## Routing logic
+
+- Whole strategy in front of you → **full-grill**. Work the component flow,
+  attack the weakest links first, keep a ledger.
+- A single choice, bet, or decision → **decision-grill**. Go deep on that one
+  thing: the case against it, the competitor's counter, when it's wrong.
+- "What could go wrong that we're not seeing?" → **pre-mortem**. Assume it
+  failed, narrate why backwards, then make the strategy carry each cause
+  visibly as an assumption or a risk.
+
+These chain. A pre-mortem surfaces failure causes → a full-grill works breadth
+across the whole strategy → a decision-grill goes deep on the one bet that
+survived shakiest. Offer the next move when one ends.
+
+## When an attack lands and there's no answer
+
+Most unanswerable attacks point at a missing judgment. Either a claim they've
+been treating as true without ever testing it (a belief they assumed was a
+fact), or a decision they never actually made (they've been acting as if the
+choice was settled when it wasn't). Name which one. That's the fix: write the
+judgment down, honestly typed, so the strategy carries it in the open instead
+of leaning on it in the dark.
+
+## Without a live respondent
+
+Run headless, with no one to answer? Don't invent their answers. Make the
+minimal reasonable assumption, mark it in the output as yours ("assumed: …"),
+and list the questions only the owner can settle — what's in scope, what a word
+means, whose dissent to record — at the end instead of papering over them. A
+marked assumption is honest work; a silent one is a guess you built on.
+
+## Sharpen with Skhema
+
+This ritual works with pen and paper. If the user keeps their strategy in
+Skhema, every attack that lands can be written straight back as a typed element
+— an assumption with its evidence gap, a risk with its tripwire — so the
+pressure-test leaves a durable trail instead of a memory. `@skhema/method`
+(`npm i @skhema/method`) gives you the typed vocabulary (assumption, risk,
+constraint, decision) and validates that each new judgment is well-formed. The
+skill needs none of this to do its job.

package/skills/skhema-pressure-test/references/decision-grill.md

@@ -0,0 +1,127 @@
+# Decision Grill — interrogate one decision hard
+
+One choice is on the table. Go deep, not wide. Build the strongest case against
+it, force it to survive the smartest competitor's response, and name the exact
+conditions under which it's wrong. Then help them decide: keep it, kill it,
+hedge it, or set a tripwire.
+
+## Before you start
+
+Get the decision stated as a decision — a command, something they will *do*:
+"We will move upmarket and drop the free tier." If what you hear is mushy
+("we're thinking about the enterprise space"), sharpen it first. You can't
+attack a fog. Make them commit to a sentence, then attack the sentence.
+
+Sometimes the sharpest thing on the table isn't a decision at all — it's a
+*judgment*, a claim like "consented-data supply, not analytics, is the binding
+constraint." You can't grill a claim as a decision, but you can promote it:
+state the command that claim justifies ("so: we will invest in consented-data
+supply, not more analytics"), confirm that's the real bet, then grill *that*.
+Promoting a judgment to its implied decision is a distinct move from sharpening
+a fog — the fog has no content yet; the judgment has content but no verb.
+
+## The moves
+
+### 1. Steelman it first
+
+Say the best case *for* the decision, out loud, in your own words. This is not
+politeness — it's how they know your coming attack is fair. It also flushes out
+their real reasons: if your steelman is stronger than theirs, they may not have
+thought it through.
+
+"The case for this is: your free tier attracts users who never convert and cost
+you support, while the enterprise buyers you actually want are put off by a
+consumer-grade free plan. Dropping it sharpens the product and the buyer. That's
+a real argument. Now here's the problem with it."
+
+### 2. The strongest case against — just one
+
+Not three weak objections. The one that hurts. Find the single argument that,
+if true, makes this decision a mistake — and make it as hard as you can. Name
+its defeater.
+
+"The strongest case against: your free tier is your top of funnel. Half your
+enterprise deals started as a free user who became a champion inside their
+company. Kill the free tier and you kill the pipeline that feeds the very
+buyers you're chasing. If you can show that enterprise deals *don't* originate
+from free users — pull the numbers — this dies. Can you?"
+
+### 3. The competitor's response
+
+A decision isn't made in a vacuum. The smartest competitor reacts the day after
+you commit. Ask: what do they do, and does your decision get *better or worse*
+once they've moved?
+
+"You drop your free tier. Your sharpest competitor keeps theirs and runs ads
+saying 'still free, still here.' Every price-sensitive user you shed walks
+straight to them, and some of those would have grown into your buyers. Does your
+decision assume competitors hold still? They won't."
+
+The strongest decisions get *better* under competitive response (the competitor
+can't follow without hurting themselves). The weak ones assume no one reacts.
+
+### 4. The conditions under which it's wrong
+
+Name the world-states where this decision is a mistake. Be specific — these
+become the strategy's tripwires.
+
+"This is wrong if: (a) more than a third of enterprise deals trace back to free
+users, or (b) your paid conversion from the new top-of-funnel is slower than
+the free-to-champion path you're removing. Two conditions. Here's the real
+question:" —
+
+### 5. Would you know you're in that world?
+
+For each condition, ask how they'd *know*. A condition you can't detect is a
+landmine. If they can't name the signal, that's a finding: the decision needs
+an instrument before it's safe to make.
+
+"How would you know deals stopped originating from free users — what would you
+watch, and how long before the damage is done? If you can't see it for two
+quarters, you're flying blind on your biggest risk."
+
+### 6. The reversibility question
+
+One-way door or two-way? Cheap to unwind or not? This changes everything about
+how much certainty they need before committing. A reversible decision can be
+made on a hunch and corrected; an irreversible one demands the evidence you've
+just been demanding.
+
+"If dropping the free tier turns out wrong, can you bring it back? Or have you
+lost the users, the SEO, the muscle memory? If it's a one-way door, you need to
+be far more sure than you are right now."
+
+## End on a verdict — theirs
+
+Hand them four options and make them pick:
+
+- **Keep** — it survived; the case against didn't land or was defeated by
+  evidence.
+- **Kill** — the case against held; the decision is a mistake.
+- **Hedge** — make it smaller or reversible so being wrong is survivable (run
+  the free tier in one segment, not kill it everywhere).
+- **Tripwire** — make the decision, but install the instrument from move 5 so
+  you'll *know* if you've entered a world where it's wrong, and pre-commit to
+  what you'll do then.
+
+## What good looks like
+
+- The decision was stated as a crisp command before any attack.
+- You steelmanned it before knifing it.
+- One strong case against, not a scatter of weak ones.
+- The competitor's reaction was played out, not assumed away.
+- The "wrong-if" conditions came paired with "how would you know."
+- Reversibility was named explicitly.
+- It ended with keep / kill / hedge / tripwire — their call, not yours.
+
+## Common failure modes
+
+- **Attacking a fog.** Grilling a decision that was never stated as one. Sharpen
+  to a command first.
+- **A pile of weak objections.** Three soft doubts feel thorough but let the real
+  risk hide. Find the one that hurts.
+- **Assuming a static world.** Forgetting the competitor moves. Always play the
+  response.
+- **Conditions with no detector.** Naming when it's wrong but not how you'd know
+  — that's a landmine, not a safeguard.
+- **Deciding for them.** You built the case; they make the call.