@hyperscale0/hsx 2.4.1 → 3.0.1

package/docs/reference/std/threshold_pool.md

@@ -1,138 +0,0 @@
-<!-- Generated by scripts/docs/build.ts for HSX 2.4.1. Do not edit. -->
-
-# threshold_pool
-
-Source: [`std/money_flows/threshold_pool.hsx`](../../../std/money_flows/threshold_pool.hsx)
-
-## Export
-
-`threshold_pool<C>`
-
-## Parameters
-
-| Parameter | Type | Required | Meaning |
-| --- | --- | --- | --- |
-| `contributor` | `optional<party>` | No | The party representing individual contributors. |
-| `beneficiary` | `optional<party>` | No | The beneficiary party receiving the settled pool if the target is met. |
-| `target` | `money<C>` | Yes | Total target funding threshold in minor units of currency `C`. |
-| `commitment` | `money<C>` | Yes | Binding name for individual contributor commitment amounts. |
-| `max_contributors` | `optional<integer>` | No | Optional maximum count of admitted contributors. |
-| `close_by` | `date` | Yes | Stored date deadline by which the target must be met. |
-| `close_policy` | `optional<text>` | No | Policy determining pool close behavior (`threshold`). |
-| `overfund_policy` | `optional<text>` | No | Policy on commitments exceeding the target (`reject`). |
-| `cancel_policy` | `optional<text>` | No | Contributor withdrawal policy before close (`before_close`). |
-| `fail_policy` | `optional<text>` | No | Refund policy if the pool fails to hit target (`whole_commitment_refund`). |
-| `beneficiary_account` | `optional<account<C>>` | No | Optional direct account reference for the beneficiary. |
-| `memo` | `optional<text>` | No | Optional memo text stored on the pool. |
-| `contribution_instrument` | `optional<block>` | No | Optional custom contribution child instrument block. |
-| `wording` | `optional<block>` | No | Optional custom UI wording block. |
-| `funding_join` | `optional<block>` | No | funding_join configures the flat contribution-instrument mode for a priced obligation. |
-
-Required means required by the template signature. A selected mode may also need parameters marked optional; the guidance below describes those combinations.
-
-## Module guidance
-
-All-or-nothing capital accumulation pool collecting commitments toward a target amount before a close deadline.
-
-### Purpose
-
-`threshold_pool` powers all-or-nothing crowdfunding, capital calls, collective purchasing, and consortium rounds.
-Multiple contributors pledge commitments toward a monetary `target`. Commitments sit in escrow until the pool
-reaches the target before `close_by` (activating and settling funds to the beneficiary), or fails (triggering full refunds).
-
-### Selection guidance
-
-- vs `rotating_pool`: `threshold_pool` is all-or-nothing fundraising where many contributors fund a single beneficiary.
-  `rotating_pool` is a peer savings circle where members contribute identically in each cycle and rotate who receives the pot.
-- vs `weighted_distribution`: `threshold_pool` pools funds inward from many contributors to one beneficiary.
-  `weighted_distribution` pays funds outward from one source pool to many weighted recipients.
-
-### Parameters
-
-- `contributor`: The party representing individual contributors.
-- `beneficiary`: The beneficiary party receiving the settled pool if the target is met.
-- `target`: Total target funding threshold in minor units of currency `C`.
-- `commitment`: Binding name for individual contributor commitment amounts.
-- `max_contributors`: Optional maximum count of admitted contributors.
-- `close_by`: Stored date deadline by which the target must be met.
-- `close_policy`: Policy determining pool close behavior (`threshold`).
-- `overfund_policy`: Policy on commitments exceeding the target (`reject`).
-- `cancel_policy`: Contributor withdrawal policy before close (`before_close`).
-- `fail_policy`: Refund policy if the pool fails to hit target (`whole_commitment_refund`).
-- `beneficiary_account`: Optional direct account reference for the beneficiary.
-- `memo`: Optional memo text stored on the pool.
-- `contribution_instrument`: Optional custom contribution child instrument block.
-- `wording`: Optional custom UI wording block.
-
-### Decision ports
-
-None. Lifecycle transitions (`activate`, `fail`, `close`) are driven by target threshold evaluation and the `close_by` date.
-
-### Example
-
-```hsx
-program capital_pool_example "Capital pool example"
-import { threshold_pool } from "std/money_flows"
-party contributor: person
-party company: business
-settlement round = threshold_pool {
-  contributor: contributor
-  beneficiary: company
-  target: targetAmount: money(SAR)
-  commitment: commitmentAmount: money(SAR)
-  max_contributors: 100
-  close_by: closeBy
-  close_policy: threshold
-  overfund_policy: reject
-  cancel_policy: before_close
-  fail_policy: whole_commitment_refund
-}
-```
-
-### Funding join
-
-funding_join configures the flat contribution-instrument mode for a priced
-obligation. Opening freezes minimum ticket, investor cap, profit and schedule
-terms. Closing binds the obligation, freezes committed ticket identities and
-moves the principal once into its funding account. A ticket's engine-owned
-collection action has no independent payment or clock trigger.
-
-## Declared clauses
-
-- `agent description`
-- `aggregate invariants`
-- `caller parked states`
-- `description`
-- `due`
-- `examples`
-- `funding`
-- `id prefix`
-- `input`
-- `moves`
-- `steps`
-- `summary`
-- `title`
-- `updates`
-
-This inventory covers all branches and nested instruments in the module. The selected parameters determine which clauses and actions the compiler emits. Indexed action names expand over the declared finite list.
-
-## Decision ports
-
-None.
-
-## Actions and clauses
-
-| Action | Clauses lowered |
-| --- | --- |
-| `create` | `agent description`, `moves`, `steps`, `summary` |
-| `activate` | `due`, `moves`, `steps`, `summary` |
-| `fail` | `due`, `moves`, `steps`, `summary` |
-| `close` | `agent description`, `moves`, `steps`, `summary` |
-| `create` | `agent description`, `moves`, `steps`, `summary` |
-| `cancel` | `agent description`, `moves`, `steps`, `summary` |
-| `collect` | `agent description`, `moves`, `steps`, `summary` |
-| `refund` | `agent description`, `moves`, `steps`, `summary` |
-| `create` | `agent description`, `examples`, `moves`, `steps` |
-| `activate` | `due`, `examples`, `moves`, `steps` |
-| `fail` | `due`, `examples`, `moves`, `steps` |
-| `close` | `agent description`, `examples`, `funding`, `input`, `moves`, `steps`, `updates` |

package/docs/reference/std/weighted_distribution.md

@@ -1,135 +0,0 @@
-<!-- Generated by scripts/docs/build.ts for HSX 2.4.1. Do not edit. -->
-
-# weighted_distribution
-
-Source: [`std/money_flows/weighted_distribution.hsx`](../../../std/money_flows/weighted_distribution.hsx)
-
-## Export
-
-`weighted_distribution<C>`
-
-## Parameters
-
-| Parameter | Type | Required | Meaning |
-| --- | --- | --- | --- |
-| `source` | `optional<party>` | No | The funding party providing the distribution pool. |
-| `recipient` | `optional<party>` | No | The party representing entitled recipients. |
-| `amount` | `optional<money<C>>` | No | Total distribution pool in minor units of currency `C`. |
-| `record_at` | `optional<date>` | No | Date when entitlement eligibility is established. |
-| `weight` | `optional<money<C>>` | No | Binding name for individual recipient weight amounts. |
-| `max_recipients` | `optional<integer>` | No | Exact number of entitlement rows required before snapshotting. |
-| `snapshot` | `optional<condition>` | No | Port freezing the entitlement set against stored decision evidence. |
-| `rounding_policy` | `optional<text>` | No | Mathematical rounding policy (`largest_remainder`). |
-| `withholding_policy` | `optional<text>` | No | Tax or withholding policy (`refuse`). |
-| `correction_policy` | `optional<text>` | No | Error correction policy (`new_distribution`). |
-| `flat` | `optional<block>` | No | Optional flat distribution configuration block. |
-| `receipts` | `optional<block>` | No | receipts selects repeated distributions from immutable allocation receipts. |
-| `id_prefix_override` | `optional<text>` | No | Optional custom prefix for generated instrument IDs. |
-
-Required means required by the template signature. A selected mode may also need parameters marked optional; the guidance below describes those combinations.
-
-## Module guidance
-
-Frozen largest-remainder distribution splitting one pool across dynamic recipients by recorded weights.
-
-### Purpose
-
-`weighted_distribution` distributes dividend pools, creator royalties, liquidation proceeds, and investment returns.
-Child entitlement rows are recorded for each recipient with their respective weight. Once all recipients are recorded,
-an evidence-backed snapshot freezes the entitlement set. Each recipient is then paid their exact largest-remainder
-share such that all payouts sum exactly to `amount` without rounding leaks.
-
-### Selection guidance
-
-- vs `pooled_split`: `weighted_distribution` handles dynamic recipient rosters recorded as child rows and frozen
-  via snapshot. `pooled_split` hardcodes a fixed set of recipients and static percentages at definition time.
-- vs `settlement_batch`: `weighted_distribution` splits one funding pool out to many recipients.
-  `settlement_batch` aggregates many inbound charges and adjustments into a single net payout.
-
-### Parameters
-
-- `source`: The funding party providing the distribution pool.
-- `recipient`: The party representing entitled recipients.
-- `amount`: Total distribution pool in minor units of currency `C`.
-- `record_at`: Date when entitlement eligibility is established.
-- `weight`: Binding name for individual recipient weight amounts.
-- `max_recipients`: Exact number of entitlement rows required before snapshotting.
-- `snapshot`: Port freezing the entitlement set against stored decision evidence.
-- `rounding_policy`: Mathematical rounding policy (`largest_remainder`).
-- `withholding_policy`: Tax or withholding policy (`refuse`).
-- `correction_policy`: Error correction policy (`new_distribution`).
-- `flat`: Optional flat distribution configuration block.
-- `id_prefix_override`: Optional custom prefix for generated instrument IDs.
-
-### Decision ports
-
-- `snapshot`: Port freezing the entitlement set with an evidence reference, preventing further entries.
-
-### Example
-
-```hsx
-program weighted_distribution_example "Weighted distribution example"
-import { weighted_distribution } from "std/money_flows"
-party distribution_source: business
-party recipient: business
-settlement proceeds = weighted_distribution {
-  source: distribution_source
-  recipient: recipient
-  amount: distributableAmount: money(SAR)
-  weight: entitlementWeight: money(SAR)
-  max_recipients: 12
-  record_at: recordAt
-  snapshot: port snapshot_entitlements
-  rounding_policy: largest_remainder
-  withholding_policy: refuse
-  correction_policy: new_distribution
-}
-port snapshot_entitlements {
-  allowed: [distribution_source]
-  shape: { evidenceReference: text }
-}
-```
-
-### Receipt-backed distributions
-
-receipts selects repeated distributions from immutable allocation receipts.
-It names round, receipt, path, mode (cash or loss), fee_bps and vat_bps.
-The funding snapshot owns ticket weights and original wallet destinations.
-Cash floors each ratio after fee and fee VAT; a named account receives residual.
-Loss assigns principal by largest remainder without cash, fee or VAT.
-Each receipt is consumed once; a new receipt may fund a new distribution record.
-This mode does not use caller-entered weights or a once-only settled principal pool.
-
-## Declared clauses
-
-- `agent description`
-- `aggregate invariants`
-- `capture input`
-- `description`
-- `due`
-- `id prefix`
-- `input`
-- `moves`
-- `port`
-- `requires refs`
-- `steps`
-- `summary`
-- `title`
-
-This inventory covers all branches and nested instruments in the module. The selected parameters determine which clauses and actions the compiler emits. Indexed action names expand over the declared finite list.
-
-## Decision ports
-
-- `snapshot`
-
-## Actions and clauses
-
-| Action | Clauses lowered |
-| --- | --- |
-| `create` | `agent description`, `moves`, `steps`, `summary` |
-| `[snapshot]` | `agent description`, `capture input`, `description`, `input`, `moves`, `port`, `steps`, `summary` |
-| `create` | `agent description`, `moves`, `steps`, `summary` |
-| `payout` | `agent description`, `moves`, `steps`, `summary` |
-| `create` | `agent description`, `moves`, `requires refs`, `steps`, `summary` |
-| `payout` | `due`, `moves`, `steps`, `summary` |
-| `create` | `agent description`, `steps` |

package/docs/reference/types.md

@@ -1,61 +0,0 @@
-<!-- Generated by scripts/docs/build.ts for HSX 2.4.1. Do not edit. -->
-
-# Types
-
-HSX checks types before it emits UDL. Money and account values carry a currency parameter, and no implicit currency conversion exists.
-
-| Kind | Meaning |
-| --- | --- |
-| `account` | A currency-indexed ledger account reference. |
-| `boolean` | A compile-time or stored true or false value. |
-| `bps` | An integer basis-point value. |
-| `condition` | A declared decision port. |
-| `date` | A stored date-time string checked by UDL. |
-| `integer` | A bounded whole number. |
-| `money` | A currency-indexed minor-unit amount. |
-| `party` | A declared program party. |
-| `percent` | An exact percentage with basis-point precision. |
-| `ref` | A typed reference to another instrument. |
-| `text` | A finite string value. |
-| `unknown` | An internal checker result that source must resolve before lowering. |
-
-## Account fields
-
-When declaring fields of type `account<C>`, the HSX compiler automatically lowers the field schema with the UDL2002 account pattern (`^acct_(sandbox|live)_[a-z0-9]{8,64}$`). Authors do not need to write an explicit `pattern` clause on account fields.
-
-```hsx
-fields {
-  customerAccountId {
-    type: account<SAR>;
-    "x-hyperscale-reference-filter": { column: role; values: [customer_balance]; };
-  }
-  amount: money<SAR>;
-}
-```
-
-The account type pins the currency and identifier shape. The reference filter
-pins the allowed ledger roles. Product admission requires every account field
-to declare a non-empty role list. Choose roles that match the accounts the
-program will use; `customer_balance` is the role in this example.
-
-Use the quoted `"x-hyperscale-reference-filter"` key inside the field block,
-with `column: role` and `values: [...]`. There is no shorter role annotation.
-A bare `customerAccountId: account<SAR>;` compiles as HSX but does not satisfy
-the host's account-role admission law.
-
-## Money fields
-
-A `money<C>` field admits a minor-unit integer string and refuses zero: it lowers to the pattern `^[1-9][0-9]{0,17}$`. Marking the field `optional: true` lets a caller omit it; it does not let a caller send `"0"`. When zero is a real value for the field, opt in with `allow_zero: true`, which lowers to `^(0|[1-9][0-9]{0,17})$`:
-
-```hsx
-fields {
-  amount: money<SAR>;
-  discount { type: money<SAR>; optional: true; allow_zero: true; }
-}
-```
-
-`allow_zero` on any other type is HSX1105. Decision port shapes set it on their money fields, because a decided amount may be zero.
-
-## Date fields
-
-A `date` field lowers to the UDL `hyperscale-date-time` format. Callers may send any RFC 3339 offset, such as `2026-10-03T09:00:00+03:00`; the host admits it and stores the UTC instant, `2026-10-03T06:00:00.000Z`. A value already in `Z` is stored byte for byte. A local date-time without an offset is refused.

package/docs/reference/udl-output.md

@@ -1,13 +0,0 @@
-<!-- Generated by scripts/docs/build.ts for HSX 2.4.1. Do not edit. -->
-
-# UDL output
-
-An accepted compile returns three artifacts.
-
-| Artifact | Contents |
-| --- | --- |
-| `document` | The canonical UDL object. Serialize it with `serializeUdl` from `@hyperscale0/udl`. |
-| `originMap` | Canonical UDL paths mapped to authored HSX spans. |
-| `costManifest` | The deterministic manifest pinned to the supplied rate card. |
-
-Canonical UDL sorts object keys, preserves array order, uses two-space JSON indentation, and ends with one line feed.

package/examples/01-first-program/README.md

@@ -1,45 +0,0 @@
-# 1 · Your first program
-
-[`tip-jar.hsx`](./tip-jar.hsx) is the smallest HSX program that moves money.
-A listener tips a podcast host and the money goes straight through.
-
-```bash
-hsx check tip-jar.hsx     # prints nothing, exits 0
-hsx build tip-jar.hsx     # the compiled IR
-```
-
-## The four things in the file
-
-**`program tip_jar "Tip jar"`** names the company. Exactly one per file. The
-name is `snake_case` and becomes the IR document's `product`; the title is
-optional and is what people read.
-
-**`import { instant_transfer } from "std/money_flows"`** brings in one settlement brick.
-`"settlement"` is the only module there is, and it holds seventeen settlement
-bricks. A brick you have not imported cannot be instantiated, so the imports
-at the top tell you what shape of company this is before you read a line of it.
-
-**`party listener: person`** declares who is involved. A party is a `person`
-or a `business`. Both are needed here: `instant_transfer` names a payer and a
-payee, and both must be declared parties.
-
-**`settlement tip = instant_transfer { … }`** is the money. `payer` and
-`payee` name declared parties; `amount: tipAmount: money(SAR)` declares a
-field the instance stores, called `tipAmount`, holding an amount in SAR.
-
-That doubled colon reads oddly the first time. The module's parameter is
-`amount`; its value is a typed binding, `tipAmount: money(SAR)`, which names
-the field AND its type. You choose the field name because it shows up in the
-generated API, and `amount` is HSX's word, not your product's.
-
-## What it compiles to
-
-One instrument with one action that moves money, and one money event, `tip_pay_1`.
-Notice what is NOT there: no escrow flag, because nothing is held. Compare
-that with example 2, where the money waits for someone to decide.
-
-## Try breaking it
-
-Change `payee: host` to `payee: hosts` and run `hsx check` again. The
-compiler tells you there is no party named `hosts`, and points at the column
-where you wrote it. That is example 3's whole subject.

package/examples/01-first-program/tip-jar.hsx

@@ -1,17 +0,0 @@
-// The smallest HSX program that moves money.
-//
-// A listener tips a podcast host. Nothing is held, nobody has to decide
-// anything, and the money goes straight through.
-
-program tip_jar "Tip jar"
-
-import { instant_transfer } from "std/money_flows"
-
-party listener: person
-party host:     business
-
-settlement tip = instant_transfer {
-  payer:  listener
-  payee:  host
-  amount: tipAmount: money(SAR)
-}

package/examples/02-imports-and-modules/README.md

@@ -1,96 +0,0 @@
-# 2 · Imports, modules, and the port
-
-[`photo-booth.hsx`](./photo-booth.hsx) is a photo-booth rental company. The
-renter pays up front, but the money does not reach the company until the booth
-is delivered.
-
-```bash
-hsx check photo-booth.hsx
-hsx build photo-booth.hsx --out ir.json
-```
-
-## Holding money changes everything
-
-`instant_transfer` in example 1 had no custody: money left the payer and
-arrived at the payee in one step. `held_payment` puts the money in the
-settlement's own escrow and holds it there until something says to let go.
-That "something" is the interesting part.
-
-```hsx
-release: port confirm_delivery
-```
-
-A **port** is the typed seam where the tenant's own backend decides. HSX does
-not model delivery, and the platform has no way to know whether a booth showed
-up. So the language does not pretend: it declares who may answer the question
-and what the answer looks like, and the answer comes from outside.
-
-```hsx
-port confirm_delivery {
-  allowed: [company]
-  shape {
-    boothId:     id(booth)
-    deliveredOn: date
-  }
-}
-```
-
-`allowed` is required and must name declared parties. `shape` is optional; its
-field types are `text`, `date`, `id(<asset>)`, and `money(<CUR>)`.
-
-## Assets are the things, not the money
-
-```hsx
-asset booth: good { title_transfer: off_platform }
-```
-
-`title_transfer: off_platform` records that ownership of the booth changes
-hands outside the platform. Money stays on-platform; this flag describes the
-object.
-
-## Fees have a side, and the side matters
-
-```hsx
-fees { renter: 1%, company: 3% }
-```
-
-Those two percentages behave completely differently, and the difference is
-fixed by the compiler, not by you:
-
-- The **payer-side** fee (`renter: 1%`) is charged **on top** at funding and
-  moves renter → platform directly. It never enters escrow, so no exit
-  refunds it.
-- The **payee-side** fee (`company: 3%`) is **carved out** of the amount at
-  release. The renter pays the booking fee, and the company receives 97% of it.
-
-## Cancellation splits to the basis point
-
-```hsx
-on_cancel(funded) { renter: 90%, company: 10% }
-```
-
-The shares must total exactly 100%. Not 99.99%, not 100.01%. A 0% share is
-refused outright: drop the party from the block instead of promising them
-nothing.
-
-## Where the piece fields come from
-
-Look at the compiled instrument's `fields` and you will find `piece1Amount`,
-`piece2Amount`, `piece3Amount` next to `bookingFee`, plus a `partitions`
-clause proving they sum to it exactly.
-
-Release pays out 97/3 (company, platform). Cancellation pays out 90/10
-(renter, company). The compiler cuts the amount at every boundary either exit
-cares about, which lands on 90 / 7 / 3, and then every exit is a whole number
-of pieces:
-
-| Piece                | Release  | Cancel  |
-| -------------------- | -------- | ------- |
-| `piece1Amount` (90%) | company  | renter  |
-| `piece2Amount` (7%)  | company  | company |
-| `piece3Amount` (3%)  | platform | company |
-
-Each piece is `floor(bookingFee × bps / 10000)` in minor units, and the
-division remainder goes to `piece1Amount`. Nothing rounds; nothing is lost.
-This is what "the runtime does the plumbing" actually means, and it is why the
-source is 20 lines instead of a lifecycle table.

package/examples/02-imports-and-modules/photo-booth.hsx

@@ -1,37 +0,0 @@
-// Imports, modules, and the decision port.
-//
-// A photo-booth rental company. The renter pays up front, but the money sits
-// in escrow until the booth is delivered. The company's own backend answers
-// "was it delivered?" through the `confirm_delivery` port; nothing on the
-// platform guesses. If the booking falls through after funding, the renter
-// gets almost everything back and the company keeps a small penalty.
-
-program photo_booth "Photo booth rentals"
-
-import { held_payment } from "std/money_flows"
-
-party renter:  person
-party company: business
-
-asset booth: good { title_transfer: off_platform }
-
-settlement booking = held_payment {
-  payer:   renter
-  payee:   company
-  amount:  bookingFee: money(SAR)
-
-  // The platform takes 3% out of the company's payout, and charges the
-  // renter 1% on top of the booking fee at funding.
-  fees { renter: 1%, company: 3% }
-
-  release: port confirm_delivery
-  on_cancel(funded) { renter: 90%, company: 10% }
-}
-
-port confirm_delivery {
-  allowed: [company]
-  shape {
-    boothId:     id(booth)
-    deliveredOn: date
-  }
-}

package/examples/03-diagnostics/README.md

@@ -1,68 +0,0 @@
-# 3 · Reading diagnostics
-
-[`corner-shop.hsx`](./corner-shop.hsx) is wrong on purpose. Three mistakes,
-one per idea. [`corner-shop-fixed.hsx`](./corner-shop-fixed.hsx) is the same
-program repaired.
-
-```bash
-hsx check corner-shop.hsx        # exits 1
-hsx check corner-shop-fixed.hsx  # exits 0, prints nothing
-```
-
-## What comes back
-
-```
-corner-shop.hsx:15:12: error [check] settlement basket payee must name a declared party; there is no party named grocer
-corner-shop.hsx:17:17: error [check] settlement basket decides release through port confirm_pickup, but no port with that name is declared
-corner-shop.hsx:18:21: error [check] the on_cancel split must account for exactly 100%; these shares total 60%
-```
-
-Every diagnostic carries a 1-indexed line and column, a severity, the stage
-that raised it, and one sentence. Coordinates always point at the source you
-wrote, never at a path inside the compiled IR.
-
-## The three mistakes
-
-**Line 15, a name that was never declared.** `payee: grocer` names a party
-that does not exist. Parties, assets, settlements, and ports share one flat
-namespace, and everything in it must be declared. The fix is one line:
-`party grocer: business`.
-
-**Line 17, a decision with nothing behind it.** `release: port confirm_pickup`
-says the release is decided by a port called `confirm_pickup`, and no such
-port is declared. HSX will not invent a decider: someone real has to answer,
-and the file has to say who. The fix declares the port and names who may
-answer it.
-
-**Line 18, money that does not add up.** `on_cancel(funded) { shopper: 60% }`
-leaves 40% of the held amount unaccounted for. There is no default recipient
-and no implicit remainder. The message does the arithmetic for you and says
-what the shares actually total.
-
-## All three at once, and why
-
-The compiler reports every error it can rather than stopping at the first, so
-one run tells you everything you have to fix.
-
-But it will not report errors from two different stages in the same run.
-Compiling is three stages, parse then check then lower, and a stage only runs
-the one before it produced something to work with. All three errors here are
-`[check]`. Introduce a syntax error, say by deleting a closing brace, and you
-get one `[parse]` diagnostic and nothing else: a file that does not parse has
-no meaning to check, so anything else the compiler said about it would be
-guesswork.
-
-## Errors, warnings, verdicts
-
-There are three verdicts:
-
-| Verdict   | Artifacts |                                            |
-| --------- | --------- | ------------------------------------------ |
-| `valid`   | present   | Nothing to say.                            |
-| `warning` | present   | It compiled, and the lint voice has notes. |
-| `invalid` | absent    | It cannot be compiled.                     |
-
-Warnings are lint, not soft errors: a party nobody involves, an import nothing
-instantiates, a 0% fee, a port nothing releases through. They never block, and
-the artifacts of a `warning` compile are complete and usable. If you want them
-to block in CI, `hsx check --strict` exits 1 on a warning.

package/examples/03-diagnostics/corner-shop-fixed.hsx

@@ -1,22 +0,0 @@
-// The same program with all three mistakes repaired: the grocer is declared,
-// the port the release decides through exists, and the cancellation split
-// accounts for the whole held amount.
-
-program corner_shop "Corner shop"
-
-import { held_payment } from "std/money_flows"
-
-party shopper: person
-party grocer:  business
-
-settlement basket = held_payment {
-  payer:   shopper
-  payee:   grocer
-  amount:  basketTotal: money(SAR)
-  release: port confirm_pickup
-  on_cancel(funded) { shopper: 60%, grocer: 40% }
-}
-
-port confirm_pickup {
-  allowed: [grocer]
-}

package/examples/03-diagnostics/corner-shop.hsx

@@ -1,19 +0,0 @@
-// This program is wrong on purpose. Three separate mistakes, one per idea:
-// a name that was never declared, a decision with no port behind it, and a
-// cancellation split that does not add up.
-//
-// Run `hsx check corner-shop.hsx` and read what comes back.
-
-program corner_shop "Corner shop"
-
-import { held_payment } from "std/money_flows"
-
-party shopper: person
-
-settlement basket = held_payment {
-  payer:   shopper
-  payee:   grocer
-  amount:  basketTotal: money(SAR)
-  release: port confirm_pickup
-  on_cancel(funded) { shopper: 60% }
-}