plan-verify 0.0.0-stage → 0.1.0

package/examples/checkout.ears.md

@@ -0,0 +1,74 @@
+# Checkout and a subscription.
+# R4 contradicts R1. R8, R12, and R14 cannot all hold. R16 contradicts R15.
+# A receipt is required only after payment and a confirmed address.
+# Billed seats are left open when checkout starts and stock is not available.
+
+event cart_opened: Bool "The customer opens the cart." phrase "the cart is open"
+event item_added: Bool "The customer adds an item." phrase "an item is added"
+event checkout_started: Bool "The customer starts checkout." phrase "checkout is started"
+event payment_submitted: Bool "The customer submits payment." phrase "payment is submitted"
+unwanted event payment_declined: Bool "The card is declined." phrase "payment is declined"
+event address_confirmed: Bool "The customer confirms a shipping address." phrase "the address is confirmed"
+event subscribe_clicked: Bool "The customer starts a subscription." phrase "the customer is subscribing"
+event cancel_requested: Bool "The customer cancels the subscription." phrase "the customer is cancelling"
+state signed_in: Bool "The customer is signed in." phrase "the customer is signed in"
+state card_saved: Bool "A card is on file." phrase "a card is saved"
+state stock_ok: Bool "The warehouse can fill the cart." phrase "stock is available"
+output order_accepted: Bool "The order is accepted." phrase "accept the order" outcome "the order was accepted" / "the order was not accepted"
+output order_rejected: Bool "The order is rejected." phrase "reject the order" outcome "the order was rejected" / "the order was not rejected"
+output subscription_started: Bool "A subscription begins." phrase "the subscription is started" action "start the subscription" outcome "the subscription was started" / "the subscription was not started"
+output receipt_sent: Bool "A receipt goes out." phrase "send a receipt" outcome "a receipt was sent" / "a receipt was not sent"
+enum Lane { hold, fulfill }
+output lane: Lane "Whether the warehouse holds or fulfills." phrase "the lane" as "route the order to the {value} lane" says "the order was routed to the {value} lane"
+output billed_seats: Int 1..3 "How many seats are billed." phrase "the billed seats" as "bill {op} {value} seats" says "{value} seats were billed"
+
+R1 When payment is submitted and the address is confirmed, the Checkout shall accept the order.
+R2 When payment is submitted and the address is not confirmed, the Checkout shall not accept the order.
+R3 When payment is not submitted, the Checkout shall not accept the order.
+R4 When payment is submitted and the address is confirmed, the Checkout shall not accept the order.
+R5 When payment is submitted and the address is confirmed, the Checkout shall send a receipt.
+R6 If payment is declined, then the Checkout shall reject the order.
+R7 If payment is not declined, then the Checkout shall not reject the order.
+R8 When the customer is subscribing and the customer is not cancelling and the customer is signed in, the Checkout shall start the subscription.
+R9 When the customer is not subscribing, the Checkout shall not start the subscription.
+R10 When the customer is cancelling, the Checkout shall not start the subscription.
+R11 When the customer is subscribing and the customer is not cancelling and the customer is not signed in, the Checkout shall not start the subscription.
+R12 When the subscription is started, the Checkout shall route the order to the fulfill lane.
+R13 When the subscription is not started, the Checkout shall route the order to the hold lane.
+R14 When the customer is subscribing, the Checkout shall route the order to the hold lane.
+R15 When checkout is started and stock is available, the Checkout shall bill at most 2 seats.
+R16 When checkout is started and stock is available, the Checkout shall bill 3 seats.
+R17 When checkout is not started, the Checkout shall bill 1 seat.
+R18 When payment is submitted and the address is confirmed and the customer is signed in, the Checkout shall accept the order.
+R19 When payment is submitted and the address is confirmed and a card is saved, the Checkout shall accept the order.
+R20 When payment is submitted and the address is confirmed and stock is available, the Checkout shall accept the order.
+R21 When payment is submitted and the address is confirmed and the cart is open, the Checkout shall accept the order.
+R22 When payment is submitted and the address is confirmed and an item is added, the Checkout shall accept the order.
+R23 When payment is submitted and the address is confirmed and checkout is started, the Checkout shall accept the order.
+R24 When payment is submitted and the address is confirmed and the customer is subscribing, the Checkout shall accept the order.
+R25 When payment is submitted and the address is not confirmed and the customer is signed in, the Checkout shall not accept the order.
+R26 When payment is submitted and the address is not confirmed and the cart is open, the Checkout shall not accept the order.
+R27 When payment is submitted and the address is not confirmed and an item is added, the Checkout shall not accept the order.
+R28 When payment is submitted and the address is not confirmed and a card is saved, the Checkout shall not accept the order.
+R29 When payment is not submitted and the cart is open, the Checkout shall not accept the order.
+R30 When payment is not submitted and an item is added, the Checkout shall not accept the order.
+R31 When payment is not submitted and checkout is started, the Checkout shall not accept the order.
+R32 When payment is not submitted and the customer is signed in, the Checkout shall not accept the order.
+R33 When payment is not submitted and a card is saved, the Checkout shall not accept the order.
+R34 When payment is not submitted and stock is available, the Checkout shall not accept the order.
+R35 When payment is not submitted and the customer is subscribing, the Checkout shall not accept the order.
+R36 When the customer is subscribing and the customer is not cancelling and the customer is signed in and a card is saved, the Checkout shall start the subscription.
+R37 When the customer is subscribing and the customer is not cancelling and the customer is signed in and the cart is open, the Checkout shall start the subscription.
+R38 When the customer is subscribing and the customer is not cancelling and the customer is signed in and an item is added, the Checkout shall start the subscription.
+R39 When the customer is subscribing and the customer is cancelling, the Checkout shall not start the subscription.
+R40 When the customer is cancelling and the cart is open, the Checkout shall not start the subscription.
+R41 When the customer is cancelling and an item is added, the Checkout shall not start the subscription.
+R42 When the customer is not subscribing and the cart is open, the Checkout shall not start the subscription.
+R43 When the customer is not subscribing and an item is added, the Checkout shall not start the subscription.
+R44 When the customer is not subscribing and a card is saved, the Checkout shall not start the subscription.
+R45 When the customer is subscribing and the customer is not cancelling and the customer is not signed in and the cart is open, the Checkout shall not start the subscription.
+R46 When the subscription is not started and the cart is open, the Checkout shall route the order to the hold lane.
+R47 When the subscription is not started and an item is added, the Checkout shall route the order to the hold lane.
+R48 When the subscription is started and a card is saved, the Checkout shall route the order to the fulfill lane.
+R49 When payment is submitted and the address is confirmed and the customer is signed in, the Checkout shall send a receipt.
+R50 When payment is submitted and the address is confirmed and the cart is open, the Checkout shall send a receipt.

package/examples/order-always.ears.md

@@ -0,0 +1,3 @@
+# Property: every scenario fulfills the order.
+
+P1 The Order System shall fulfill the order.

package/examples/order-awkward.ears.md

@@ -0,0 +1,8 @@
+# The response and the trigger are the old awkward shape. Lint names both.
+
+state subscription_started: Bool "A subscription begins." phrase "the subscription is started" action "start the subscription"
+enum Lane { hold, fulfill }
+output lane: Lane "Whether the warehouse holds or fulfills." phrase "the lane" as "route the order to the {value} lane" says "the order was routed to the {value} lane"
+
+R1 When start the subscription, the Checkout shall the lane is fulfill.
+R2 When not start the subscription, the Checkout shall the lane is hold.

package/examples/order-bad.json

@@ -0,0 +1 @@
+{

package/examples/order-chain.ears.md

@@ -0,0 +1,9 @@
+# Three requirements clash only as a set.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_accepted: Bool "The order is accepted." phrase "the order is accepted" action "accept the order" outcome "the order was accepted" / "the order was not accepted"
+output order_shipped: Bool "The order is shipped." phrase "ship the order" outcome "the order was shipped" / "the order was not shipped"
+
+R1 When an order is submitted, the Order System shall accept the order.
+R2 When the order is accepted, the Order System shall ship the order.
+R3 When an order is submitted, the Order System shall not ship the order.

package/examples/order-chosen.ears.md

@@ -0,0 +1,7 @@
+# The PM kept fulfillment of a submitted order and dropped the refusal.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is not submitted, the Order System shall not fulfill the order.
+R2 When an order is submitted, the Order System shall fulfill the order.

package/examples/order-clear.ears.md

@@ -0,0 +1,8 @@
+# The same checkout lane, written so a reader can say it out loud.
+
+state subscription_started: Bool "A subscription begins." phrase "the subscription is started" action "start the subscription"
+enum Lane { hold, fulfill }
+output lane: Lane "Whether the warehouse holds or fulfills." phrase "the lane" as "route the order to the {value} lane" says "the order was routed to the {value} lane"
+
+R1 When the subscription is started, the Checkout shall route the order to the fulfill lane.
+R2 When the subscription is not started, the Checkout shall route the order to the hold lane.

package/examples/order-combined.ears.md

@@ -0,0 +1,10 @@
+# Combined clauses
+
+state inventory_available: Bool "Enough stock is on hand to fill the order." phrase "inventory is available"
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+input quantity: Int 1..5 "How many units the customer asked for." phrase "the quantity"
+enum Region { us, eu }
+input region: Region "The region the order ships to." phrase "the region"
+output shipped: Int 1..5 "How many units are shipped." phrase "the number shipped" as "ship {value}"
+
+R1.2 While inventory is available, when an order is submitted, if the quantity is at least 1, where the region is us, then the Warehouse shall ship the quantity.

package/examples/order-conflict.ears.md

@@ -0,0 +1,8 @@
+# Two requirements disagree about a submitted order.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is not submitted, the Order System shall not fulfill the order.
+R2 When an order is submitted, the Order System shall fulfill the order.
+R3 When an order is submitted, the Order System shall not fulfill the order.

package/examples/order-covered.ears.md

@@ -0,0 +1,9 @@
+# Every situation has a response.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+state inventory_available: Bool "Enough stock is on hand to fill the order." phrase "inventory is available"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is submitted and inventory is available, the Order System shall fulfill the order.
+R2 When an order is submitted and inventory is not available, the Order System shall not fulfill the order.
+R3 When an order is not submitted, the Order System shall not fulfill the order.

package/examples/order-duplicate.ears.md

@@ -0,0 +1,8 @@
+# R2 states the same condition and the same response as R1.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is submitted, the Order System shall fulfill the order.
+R3 When an order is not submitted, the Order System shall not fulfill the order.

package/examples/order-fail.json

@@ -0,0 +1,5 @@
+{
+  "order_submitted": true,
+  "inventory_available": true,
+  "order_fulfilled": false
+}

package/examples/order-misuse.ears.md

@@ -0,0 +1,7 @@
+# An unwanted event written with when.
+
+unwanted event payment_declined: Bool "The payment was declined." phrase "payment fails"
+output order_rejected: Bool "The order is rejected." phrase "reject the order" outcome "the order was rejected" / "the order was not rejected"
+
+R4 When payment fails, the Order System shall reject the order.
+R5 The Order System shall reject the order.

package/examples/order-negation.ears.md

@@ -0,0 +1,7 @@
+# The trigger is a bare negation. A positive event would name the person.
+
+event borrow_requested: Bool "A member asks to take a copy home." phrase "a member asks to take a copy home"
+output loan_allowed: Bool "Whether the loan was allowed." phrase "allow the loan" outcome "the loan was allowed" / "the loan was not allowed"
+
+R1 When not a member asks to take a copy home, the Desk shall not allow the loan.
+R2 When a member asks to take a copy home, the Desk shall allow the loan.

package/examples/order-pass.json

@@ -0,0 +1,5 @@
+{
+  "order_submitted": true,
+  "inventory_available": true,
+  "order_fulfilled": true
+}

package/examples/order-quantity.ears.md

@@ -0,0 +1,8 @@
+# R4 caps the accepted quantity at 10. R5 accepts an order of 12.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output quantity: Int 0..12 "How many units the order accepts." phrase "the quantity" as "accept {op} {value} units" says "{value} units were accepted"
+
+R3 When an order is not submitted, the Order System shall accept 0 units.
+R4 When an order is submitted, the Order System shall accept at most 10 units.
+R5 When an order is submitted, the Order System shall accept 12 units.

package/examples/order-redundant.ears.md

@@ -0,0 +1,9 @@
+# R2 repeats what R1 already requires.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+state inventory_available: Bool "Enough stock is on hand to fill the order." phrase "inventory is available"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is submitted and inventory is available, the Order System shall fulfill the order.
+R3 When an order is not submitted, the Order System shall not fulfill the order.

package/examples/order-repair.ears.md

@@ -0,0 +1,9 @@
+# The copy cannot be lent and refused for the same request.
+
+state copy_in_building: Bool "That copy is still in the building." phrase "the copy is in the building"
+state copy_on_loan: Bool "That copy is already out on loan." phrase "the copy is out on loan"
+event borrow_requested: Bool "A member asks to take a copy home." phrase "a member asks to take a copy home"
+output loan_allowed: Bool "Whether the loan was allowed." phrase "allow the loan" outcome "the loan was allowed" / "the loan was not allowed"
+
+R1 While the copy is in the building, when a member asks to take a copy home, the Desk shall allow the loan.
+R2 While the copy is out on loan, when a member asks to take a copy home, the Desk shall not allow the loan.

package/examples/order-repeat.ears.md

@@ -0,0 +1,13 @@
+# R5 repeats R4. R1 conflicts with R2, and that clash does not hide the repeat.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+state inventory_available: Bool "Enough stock is on hand to fill the order." phrase "inventory is available"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+output order_closed: Bool "The order is closed." phrase "close the order" outcome "the order was closed" / "the order was not closed"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is submitted, the Order System shall not fulfill the order.
+R3 When an order is not submitted, the Order System shall not fulfill the order.
+R4 When an order is submitted, the Order System shall close the order.
+R5 When an order is submitted and inventory is available, the Order System shall close the order.
+R6 When an order is not submitted, the Order System shall not close the order.

package/examples/order-same.ears.md

@@ -0,0 +1,3 @@
+# Property: the same rule as R1.
+
+P1 WHEN an order is submitted AND inventory is available, THE Order System SHALL fulfill the order.

package/examples/order-status.ears.md

@@ -0,0 +1,7 @@
+# The status would have to be shipped and cancelled at once.
+
+enum Status { placed, shipped, cancelled }
+output status: Status "Where the order stands." phrase "the status" as "mark the order {value}" says "the order was {value}"
+
+R6 The Order System shall mark the order shipped.
+R7 The Order System shall mark the order cancelled.

package/examples/order-unanswered.ears.md

@@ -0,0 +1,8 @@
+# An error condition with no stated response
+
+unwanted event payment_declined: Bool "The payment was declined." phrase "payment fails"
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is not submitted, the Order System shall not fulfill the order.

package/examples/order-unhandled.ears.md

@@ -0,0 +1,8 @@
+# A declared event that no requirement handles
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+event order_cancelled: Bool "The customer cancels an order." phrase "an order is cancelled"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is not submitted, the Order System shall not fulfill the order.

package/examples/order-unmeasured.ears.md

@@ -0,0 +1,10 @@
+# "as needed" is free text. "respond quickly" is a declared phrase, so that wording is bound.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_fulfilled: Bool "Handle it as needed." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+output shipped: Bool "The order left the building." phrase "respond quickly" outcome "the order was shipped quickly" / "the order was not shipped quickly"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is not submitted, the Order System shall not fulfill the order.
+R3 When an order is submitted, the Order System shall respond quickly.
+R4 When an order is not submitted, the Order System shall not respond quickly.

package/examples/order-unused.ears.md

@@ -0,0 +1,13 @@
+# loyalty and region are never mentioned. refund is never mentioned.
+# A receipt is only read, never set.
+
+state cart_open: Bool "The cart is open." phrase "the cart is open"
+state loyalty: Bool "The customer is in the loyalty program." phrase "the customer is loyal"
+input region: Int 1..3 "The region code." phrase "the region"
+enum Lane { hold, fulfill, refund }
+output lane: Lane "Whether the warehouse holds or fulfills." phrase "the lane" as "route the order to the {value} lane" says "the order was routed to the {value} lane"
+output receipt_sent: Bool "A receipt goes out." phrase "a receipt is sent" action "send a receipt" outcome "a receipt was sent" / "a receipt was not sent"
+
+R1 When the cart is open and a receipt is not sent, the Checkout shall route the order to the hold lane.
+R2 When the cart is not open and a receipt is not sent, the Checkout shall route the order to the fulfill lane.
+R3 When a receipt is sent, the Checkout shall route the order to the hold lane.

package/examples/order-vacuous.ears.md

@@ -0,0 +1,9 @@
+# R1 contradicts itself. R2 asks for a quantity the declared range does not contain.
+
+state cart_open: Bool "The cart is open." phrase "the cart is open"
+input quantity: Int 1..5 "How many units the customer asked for." phrase "the quantity"
+output order_accepted: Bool "The order is accepted." phrase "accept the order" outcome "the order was accepted" / "the order was not accepted"
+
+R1 When the cart is open and the cart is not open, the Checkout shall accept the order.
+R2 When the quantity is at least 9, the Checkout shall accept the order.
+R3 The Checkout shall accept the order.

package/examples/order-vague.ears.md

@@ -0,0 +1,7 @@
+# Vague words in an order requirement's description
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_fulfilled: Bool "The checkout is fast, appropriate, and user-friendly." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is not submitted, the Order System shall not fulfill the order.

package/examples/order-wide.ears.md

@@ -0,0 +1,5 @@
+# A wide integer range the solver still decides.
+
+output quantity: Int 0..250000 "A count with a wide range." phrase "the quantity" as "count {value}"
+
+R1 The Counter shall count 0.

package/examples/order-wording.ears.md

@@ -0,0 +1,8 @@
+# Vague words and solution words.
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+output order_fulfilled: Bool "The system responds quickly." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+state saved: Bool "Store the order in the database." phrase "the order is saved"
+
+R1 When an order is submitted, the Order System shall fulfill the order.
+R2 When an order is not submitted, the Order System shall not fulfill the order.

package/examples/order.ears.md

@@ -0,0 +1,7 @@
+# Order fulfillment
+
+event order_submitted: Bool "The customer submits an order." phrase "an order is submitted"
+state inventory_available: Bool "Enough stock is on hand to fill the order." phrase "inventory is available"
+output order_fulfilled: Bool "The order is fulfilled." phrase "fulfill the order" outcome "the order was fulfilled" / "the order was not fulfilled"
+
+R1 WHEN an order is submitted AND inventory is available, THE Order System SHALL fulfill the order.

package/examples/payment-if.ears.md

@@ -0,0 +1,7 @@
+# Unwanted events use if, then.
+
+unwanted event payment_declined: Bool "The payment was declined." phrase "payment fails"
+output order_rejected: Bool "The order is rejected." phrase "reject the order" outcome "the order was rejected" / "the order was not rejected"
+
+R4 If payment fails, then the Order System shall reject the order.
+R5 If not payment fails, then the Order System shall not reject the order.

package/examples/plan-to-problems/README.md

@@ -0,0 +1,54 @@
+# From a plan to a list of problems
+
+A product plan goes in as plain English. A list of its logical problems comes out as plain English.
+
+`generated.ears.md` is a recorded run from grok-4.7 on 2026-10-22. The model translated `plan.md`. The file is that reply, unedited.
+
+## Flow
+
+1. `plan.md` is the product plan, written the way a product manager talks. It has no EARS syntax. The problems planted in it are listed for a person in `expected-problems.md`. `planted.txt` is the same list in a small machine-readable form: two direct contradictions (`R2`/`R3` and `R5`/`R6`), one gap (`reminder_sent`), one condition that can never be true (`R9`), and one redundant requirement (`R11`).
+2. `generate.mjs` reads the agent skill and the plan and asks a model for an EARS spec. The user message tells the model it has no tools, must translate every rule faithfully, and must reply with only the spec in one fenced block. The request is streamed. It writes only the spec text to the output file. This step is live and needs a key. The offline test does not run it.
+3. `plan-verify lint --json` checks the spec and prints `lint.json`.
+4. `plan-verify report` turns that lint result into `problems.md`. Each logical problem is plain English, with requirement ids, line numbers, and the EARS sentences quoted. For a contradiction it asks which requirement should win and does not choose one. No model is involved.
+
+Lint names redundancy on the requirements that are not part of any conflict. `R11` repeats `R10`, and neither requirement is in a conflict, so lint reports `R11` itself. The report still explains that `R11` only repeats `R10` in a stricter situation. It does not delete `R11`. A requirement whose condition can never be true stays vacuous only. `R9` is not also called redundant.
+
+For each conflict the report asks which requirement should win, then lists candidate repairs and does not choose one. A repair drops one requirement in the conflicting set, or adds one Bool, enum equality, or integer bound to one requirement's condition. A suggestion is shown only after lint on the patched spec no longer has that conflict and has no new one. `R1` and `R2` can be separated by adding "and the copy is not out on loan" to `R1`, or "and the copy is not in the building" to `R2`. `R2` against `R3`, and `R5` against `R6`, share a condition, so the only candidates are to drop one of the two.
+
+The recorded spec also has findings that were not planted. `R1` and `R2` contradict when the copy is both in the building and out on loan, because those two states are independent. `loan_allowed` is uncovered when a member asks and the copy is neither in the building nor out on loan. `renewal_allowed` is uncovered when nobody asks to renew. `R4` and `R12` negate a trigger with "When not …". Lint flags each one as wording kind `negation` and asks for a positive condition, such as "When a non-member asks", or a positive event.
+
+## Live command
+
+`generate.mjs` has no packages. It runs on Node 18 or later with `fetch`. The key is read only from `XAI_API_KEY` and is never printed. `XAI_MODEL` overrides the model. The default is `grok-4.7`. The call goes to the OpenAI-compatible chat completions endpoint at `api.x.ai`. The skill text is the system prompt. The plan is wrapped in the user message.
+
+From the repo root:
+
+```bash
+XAI_API_KEY=... node examples/plan-to-problems/generate.mjs skills/plan-verify/SKILL.md examples/plan-to-problems/plan.md out.ears.md
+```
+
+The script is self-contained. Copied next to `skill.md`, `plan.md`, and the output path, the same command is:
+
+```bash
+node generate.mjs skill.md plan.md out.ears.md
+```
+
+If the spec fails to parse, pass the parser error and the previous spec. The model is asked for a corrected spec:
+
+```bash
+node generate.mjs skill.md plan.md out.ears.md repair-error.txt previous.ears.md
+```
+
+Then print the problems. Either Node or the native binary works. They must print the same bytes.
+
+```bash
+npm run build
+./build/plan-verify lint --json examples/plan-to-problems/generated.ears.md
+./build/plan-verify report examples/plan-to-problems/generated.ears.md
+```
+
+`node --experimental-strip-types src/main.ts report examples/plan-to-problems/generated.ears.md` prints the same report.
+
+## Offline test
+
+`npm test` runs an offline check that needs no key. It lints `generated.ears.md` and runs `report`, under Node and as the native binary. Stdout must match the committed `lint.json` and `problems.md`, stderr must be empty, and the exit status is 1 because problems were found. It then checks that every line in `planted.txt` is detected and is also named in `expected-problems.md`. Contradictions, the gap, and the impossible condition must show up in `lint.json`. The redundant requirement must show up in `lint.json` and in `problems.md`. The two bare negations must show up in `lint.json` as wording kind `negation`. The report must ask which requirement should win for every planted contradiction, and for any further contradiction the spec contains, and must not pick one.

package/examples/plan-to-problems/expected-problems.md

@@ -0,0 +1,25 @@
+# Planted problems
+
+These are the logical problems written into `plan.md` on purpose. The recorded spec uses the ids below. Line numbers are the lines in `generated.ears.md`.
+
+## Two direct contradictions
+
+The plan says not to lend a copy that is already out, and then it says to lend that same copy. Those are R2 line 17 and R3 line 18. Both apply when a member asks to take a copy home while the copy is out on loan, and they demand opposite answers.
+
+The plan says a member who still owes a fine cannot renew, and it also says that member can renew. Those are R5 line 20 and R6 line 21. Both apply when a fine is owed and a member asks to renew, and they demand opposite answers.
+
+## One gap
+
+The plan says to send a reminder after the due date. It never says what to do about a reminder when the loan is not overdue. No sentence covers that situation. The uncovered output is reminder_sent. R8 line 23 only speaks once the loan is overdue.
+
+## One condition that can never be true
+
+Loans are only 1 to 21 days, and the plan also says to allow a loan of 40 days or longer. A loan length of at least 40 days cannot happen. That is R9 line 24.
+
+## One redundant requirement
+
+Closing the loan when a copy comes back already requires the overdue case too. Saying it again adds nothing. R11 line 26 only repeats R10 line 25 in the stricter case where the loan is also overdue.
+
+## Negated triggers
+
+R4 line 19 says "When not a member asks to take a copy home". R12 line 27 says "When not a member brings a copy back". Lint flags each sentence as wording kind `negation`. The suggested rewrite is a positive condition, such as "When a non-member asks", or a positive event.