Capabilities & Security model

Quire compiles action usage to data descriptors (Action) instead of executable code.

Capabilities in source

button addToCart {
  label "Add to cart"
  action commerce.cart.add(product.defaultVariant.id)
}

commerce.cart.add is validated against the active schema registry, then emitted as a declarative descriptor in stretchpress.blocks.v1.

Capability registries

CLI commands:

quire capabilities --schema path/to/schema.json
quire capability-abis

Registry output is versioned with schemas/quire-capabilities.v1.json and schemas/quire-capability-host-abi.v1.json.

Standard categories include:

• analytics.*
• auth.*
• commerce.*
• forms.*
• navigation.*
• search.*

Host ABI expectations

Host ABI entries describe required and forbidden behavior for a conforming runtime, for example:

• call descriptors only for registered names
• do not treat descriptor arguments as executable code
• keep descriptor handling inside the host runtime boundary

The standard ABIs include host.sideEffects and explicit must / mustNot obligations. They are not callback/runtime handler maps.

Security model from language docs

Quire does not execute source text. Compiler output is limited to declarative data:

• view metadata
• typed block nodes
• declarative expressions
• conditional and repeat descriptors
• capability descriptors
• binding descriptors

Hardening checks explicitly reject escape-hatch keys in emitted IR, including:

• rawHtml, rawCss, rawJs, script, style, eval, code
• innerHTML, outerHTML, srcdoc
• event-like attributes such as onClick
• prototype pollution keys: __proto__, constructor, prototype

Planned vs implemented security notes

• The runtime/host boundary remains explicit: Quire compiles declarative intent; capabilities require host implementations.
• Additional threat-model docs are maintained separately (THREAT-MODEL.md in the source tree).
• New items in the changelog ## Unreleased should be validated against your installed runtime before using them in production.