@suss/intent-ir
v0.33.1
Published
The types for the intent your team writes down, product outcomes and system behavior, in a shape suss can check the code against.
Maintainers
Readme
@suss/intent-ir
Part of suss, which reads both sides of every call in a repository and says where the two disagree.
The team-authored side of the loop: what the code was meant to do, in a form that pairs against the derived BehavioralSummary of what it does.
What this package is
Two citizens, discriminated by kind, both built on @suss/ir-core so intent and behaviour describe boundaries the same way:
- System intent (
kind: boundary): what one boundary should do, as named outcomes. The boundary is REST, function-call, message-bus, storage or unit-invocation, and every field of one comes off the@suss/ir-coreschema for that protocol. - Outcome intent (
kind: prd): humanwhen/expectscenarios, each with an optionallinkto a system-intent outcome (<intent-name>.<outcome-id>). A scenario with nolinkis a valid state to be in: it reads fully, and nothing has linked it to an outcome yet.
Where it fits in suss
It is a peer of @suss/behavioral-ir; both build on @suss/ir-core. Readers (e.g. @suss/contract-intent) parse files into IntentDoc and call intentDocToSummary; the checker pairs the result against derived code summaries.
Status
v0: REST, function-call, message-bus, storage and unit-invocation system intent, effects as outcomes, PRD outcome intent with optional links. GraphQL, runtime-config and metric boundaries have no block yet.
The file format is also published as a JSON Schema, generated from the zod schemas at build time, so an editor can check a document and a tool in another language can read one without depending on this package. Intent format goes through both document kinds field by field.
More
Coverage
License
Apache-2.0
