IV.15
CLI and diagnostics
Prepare, run, and verify commands, finite presets, outcomes, and diagnostics.
Scope
Use the command forms below to prepare a rule, supply one explicit input, and receive one result under finite limits. The host reads explicit files and transports the result.
Every product uses the same argument grammar, numeric display, result framing, and numeric command status. Named value, artifact, receipt, report, and graph formats supply their bytes.
Command grammar
commandLine = "lispex" "--language" "2.0" "--product" product command
product = "native" | "npm" | "wasm"
command = prepare | run | verify | graph | replay
prepare = "prepare" prepareOption+
run = "run" runOption+
verify = "verify" verifyOption+
graph = "graph" graphOption+
replay = "replay" replayOption+
prepareOption = bundle | engine | output | preset | prepareLimits
runOption = program | input | engine | output | receiptOutput | profile | profileDeclaration | preset | prepareLimits | evaluateLimits | profileLimits
verifyOption = expected | actual | evidence | trust | output | profileLimits
graphOption = program | engine | output | preset | prepareLimits
replayOption = program | request | expected | evidence | trust | engine | output | receiptOutput | prepareLimits | profileLimits
program = bundle | artifact
bundle = "--bundle" file
artifact = "--artifact" file
input = "--input" inputSource
engine = "--engine" engineIdentity
output = "--output" outputDestination
receiptOutput = "--receipt-output" file
profile = "--profile" profileName
profileName = "base" | "vouch/2"
profileDeclaration = "--profile-declaration" file
preset = "--preset" presetName
prepareLimits = "--prepare-limits" file
evaluateLimits = "--evaluate-limits" file
profileLimits = "--profile-limits" file
request = "--request" file
expected = "--expected" file
actual = "--actual" file
evidence = "--evidence" file
trust = "--trust" file
inputSource = file | "-"
outputDestination = file | "-"
file = localPathArgument
engineIdentity = identityArgument
presetName = nameArgument
Each terminal is one argument after shell processing. Each imported argument is one nonempty string. An argument cannot contain NUL. A file is an explicit local path other than the single hyphen. Identity arguments name installed capabilities. Name arguments select the named finite preset. The option table supplies cardinality and compatibility rules.
numberDisplay = integerDisplay | rationalDisplay
integerDisplay = "0" | positiveInteger | "-" positiveInteger
rationalDisplay = nonzeroInteger "/" denominator
nonzeroInteger = positiveInteger | "-" positiveInteger
denominator = positiveInteger
positiveInteger = nonzeroDigit digit*
nonzeroDigit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
digit = "0" | nonzeroDigit
The numerator and denominator are coprime. The denominator is greater than one. An integral value uses integer display. The spelling represents the exact mathematical value.
Prepare
Preparation reads the supplied closed source bundle and resolves its entry and dependencies. Its finite budget is separate from evaluation. A prepared rule records the fixed program needed by a later request. See Preparation and modules.
The root source uses the module grammar and declares its entry. Each alternative source case selects its own closed bundle.
15.1 Prepare before evaluating
The command applies the phase separation rule to the submitted source bundle. A preparation failure stops command dispatch before entry evaluation. Reused preparation follows the cache-preservation rule.
Why
A caller needs to distinguish an invalid submission from an evaluated rule. Separate budgets keep preparation work and cache state from changing the rule outcome.
Prepare without calling the entry
lispex.example.v2.cli-and-diagnostics.prepare-only · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [],
"operationUnderTest": "Prepare the supplied closed bundle without requesting evaluation.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"preparation": {
"kind": "prepared-rule",
"closedBundle": true,
"entryEvaluated": false
}
}Product invocation
Expected result
Preparation yields a verified prepared rule and does not evaluate the entry. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
15.2 Concrete command forms
Use the command grammar for every product. The language and product arguments precede the command. Command options may appear in any order. Each option occurs at most once. Each option takes exactly one following argument.
Unknown options, missing arguments, duplicate options, and extra positional arguments fail during invocation. Short options, attached values, response files, and environment substitutions are outside this grammar. The command reads no implicit configuration file. Shell processing finishes before this contract applies.
Validate the complete argument vector before opening input files. Scan lexical errors from left to right. Then check required operands in the command table order. Finally check option conflicts in the option table order. A value error identifies its introducing option. A conflict identifies its later option. A missing required option identifies the end of the argument vector. Argument positions start at zero after the executable token.
| Command | Required operands | Successful payload |
|---|---|---|
| prepare | One bundle | Prepared program artifact |
| run | One bundle or one artifact and one input | Canonical evaluation outcome |
| verify | One expected receipt and one actual receipt | Verification report |
| graph | One bundle or one artifact | Meaning graph |
| replay | One bundle or one artifact, one recorded request, and one expected receipt | Replay comparison report |
| Option | Meaning | Default or restriction |
|---|---|---|
| --language | Require Lispex 2.0 semantics | Required before the command |
| --product | Select the installed native, npm, or wasm product | Required before the command |
| --engine | Select an exact installed engine identity | Use the engine pinned by the selected product |
| --bundle | Read one closed source bundle | Excludes --artifact |
| --artifact | Read one prepared artifact | Excludes --bundle |
| --input | Read exact canonical input bytes | Required for run |
| --output | Write the primary result | Default is the single hyphen for stdout |
| --receipt-output | Write an eligible evaluation receipt to a separate file | Available for run and replay |
| --profile | Select base or vouch/2 | base |
| --profile-declaration | Supply explicit profile declaration data | Required when the selected profile requires request declarations |
| --preset | Select one named finite preset for the performed phases | common-default |
| --prepare-limits | Supply PrepareLimits for preparation | Replace only that complete phase scope |
| --evaluate-limits | Supply EvaluationLimits for evaluation | Replace only that complete phase scope |
| --profile-limits | Supply ProfileHostBudget for host profile work | Replace only that complete phase scope |
| --request | Supply the complete recorded semantic request | Required for replay |
| --expected | Supply the recorded receipt to compare | Required for verify and replay |
| --actual | Supply the second receipt to compare | Required for verify |
| --evidence | Supply the explicit evidence envelope to verify | Pair with --trust |
| --trust | Supply fixed verification policy and trust inputs | Pair with --evidence |
The selected bundle or artifact declares its single entry. A command cannot override that declaration. All three products use the same semantic input. The product and engine selectors affect execution evidence. They do not change the semantic request. Missing products, missing engines, and incompatible package identities fail admission. The command never installs a product or changes engines after refusal.
The host snapshots explicit file operands before using them. Only the input operand accepts stdin through the single hyphen. Stdin is read through EOF as one canonical value. A second encoded value or trailing bytes fail canonical decoding. Other operands do not consume stdin. The input bytes are never evaluated as source text. File paths remain host presentation data. Guest code receives the decoded Datum.
An explicit preset excludes all three phase limit files. Without an explicit preset, a phase file replaces its own complete scope. Other performed phases use common-default. A limit option for an unperformed phase fails invocation. Unknown fields, missing fields, nonfinite limits, and out-of-range fields fail admission. A missing or invalid file never triggers a preset fallback. The resource contract defines the finite scopes. The profile host budget remains separate. Numeric coefficients and defaults follow the cost model freeze.
Prepare resolves and verifies the bundle without guest evaluation. Graph projects the prepared canonical program without guest evaluation. A graph engine used for replay must be an explicitly selected installed engine with the required conformance support. A graph command does not select an execution engine by producing a graph.
Verify admits both receipts and checks their program and complete request identities before comparing whole canonical outcomes. Source provenance stays separate from the canonical comparison. Evidence verification uses only supplied evidence and trust inputs. It performs no issuer lookup or trust store discovery. Verify performs no guest evaluation. Check supplied evidence after the whole outcome comparison succeeds. A supplied evidence envelope authenticates the actual receipt. A different receipt binding fails verification. Successful outcome comparison does not excuse an evidence failure. Without evidence and trust operands, evidence verification is not requested.
Verification work uses the separate finite profile host budget. Exhaustion before a new evaluation uses phase verify and status 42. Recorded receipts and outcomes stay unchanged.
Replay obtains canonical input, evaluation limits, resource model, and semantic identities exclusively from the recorded request. It admits the supplied program and expected receipt against that request before guest entry. Their program and request identities must agree. An inconsistent expected receipt is an admission refusal with status 30. A supplied evidence envelope authenticates the expected receipt. Its verification completes before replay evaluation. A well formed envelope bound to another receipt fails verification with status 42. Replay accepts no input, profile, preset, or evaluation limit override. Preparation and profile host limits cover only their separate host work. The comparison preserves both recorded and recomputed outcomes. Command statuses follow the numeric mapping.
The primary output contains exactly one complete command result record. Its named byte contract carries the payload or reports for that command. The command adds no banner, separator, newline, or second record. A file output leaves stdout empty. Human diagnostics use stderr. A preparation failure uses its source report. Admission refusal uses its admission report. A later profile refusal preserves the evaluation outcome with its separate profile work report. Operational failures use their attempt report.
For the same admitted semantic request and format versions, every product emits the same canonical payload and evaluation receipt bytes. Product labels, host paths, and locale text stay outside those bytes. Execution evidence retains its separate identity.
Serialization completes before the primary record is published. Semantic failure never publishes a truncated success value. Interrupted output delivery is an operational failure. Receipt files are written only for eligible completed evaluation outcomes. Qualification or evidence refusal preserves that eligibility. Distinct output operands must name distinct destinations and must not overwrite an input operand.
| Named bytes | Definition home |
|---|---|
| Closed source bundle | Source bundle |
| Prepared program | Prepared format |
| Canonical input Datum | Canonical value codec |
| Profile declaration data | Profile declarations |
| Canonical outcome and evaluation receipt | Outcome and receipt formats |
| Command result record and source or attempt reports | Result and report formats |
| Admission and profile work reports | Separate reports |
| Evidence and trust inputs | Evidence envelope |
| Recorded request and comparison report | Replay interface |
| Meaning graph | Graph format |
These names select the byte contracts. This command grammar supplies no alternate encoding.
Why
Explicit operands make the same request available to every product. Separate phase limits preserve preparation and evaluation accounting. Exact replay operands prevent silent changes to the recorded request. One result record keeps machine output independent of host presentation.
Three products receive the same request
lispex.example.v2.cli-and-diagnostics.command-product-forms · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"invocations": [
{
"product": "native",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"run",
"--artifact",
"rule.artifact",
"--input",
"input.datum"
],
"artifact": "same admitted artifact",
"input": {
"kind": "rational",
"numerator": "3",
"denominator": "2"
},
"profile": "base",
"preset": "common-default"
},
{
"product": "npm",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"npm",
"run",
"--artifact",
"rule.artifact",
"--input",
"input.datum"
],
"artifact": "same admitted artifact",
"input": {
"kind": "rational",
"numerator": "3",
"denominator": "2"
},
"profile": "base",
"preset": "common-default"
},
{
"product": "wasm",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"wasm",
"run",
"--artifact",
"rule.artifact",
"--input",
"input.datum"
],
"artifact": "same admitted artifact",
"input": {
"kind": "rational",
"numerator": "3",
"denominator": "2"
},
"profile": "base",
"preset": "common-default"
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
3/2Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "rational",
"numerator": "3",
"denominator": "2"
}
}3/2Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "rational",
"numerator": "3",
"denominator": "2"
}
}3/2Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "rational",
"numerator": "3",
"denominator": "2"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"products": [
"native",
"npm",
"wasm"
],
"sameCanonicalInputBytes": true,
"sameCanonicalOutcomeBytes": true,
"sameEvaluationReceiptBytes": true,
"exitStatuses": [
0,
0,
0
],
"fallbackUsed": false
}Product invocation
Expected result
All products select the same finite request and return the exact value three halves. Product invocation awaits its 2.0 adapter.
The argument arrays specify command syntax. Named operand contents use documentation notation. Their named format contracts define the public bytes. The expectation is authored for Lispex 2.0. Product execution awaits its 2.0 adapter.
Invalid options stop before entry
lispex.example.v2.cli-and-diagnostics.command-option-rejections · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"invocations": [
{
"reason": "duplicate-option",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"run",
"--artifact",
"a",
"--input",
"a",
"--input",
"b"
]
},
{
"reason": "unknown-option",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"npm",
"run",
"--artifact",
"a",
"--input",
"b",
"--unlimited"
]
},
{
"reason": "exclusive-program-operands",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"wasm",
"run",
"--bundle",
"a",
"--artifact",
"b",
"--input",
"c"
]
},
{
"reason": "stdin-only-for-input",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"run",
"--bundle",
"-",
"--input",
"-"
]
},
{
"reason": "replay-input-override",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"npm",
"replay",
"--artifact",
"a",
"--request",
"r",
"--expected",
"e",
"--input",
"i"
]
},
{
"reason": "missing-trust-input",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"wasm",
"verify",
"--expected",
"e",
"--actual",
"a",
"--evidence",
"v"
]
},
{
"reason": "preset-and-phase-file",
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"prepare",
"--bundle",
"b",
"--preset",
"common-default",
"--prepare-limits",
"p"
]
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"reasons": [
"duplicate-option",
"unknown-option",
"exclusive-program-operands",
"stdin-only-for-input",
"replay-input-override",
"missing-trust-input",
"preset-and-phase-file"
],
"phases": [
"invocation",
"invocation",
"invocation",
"invocation",
"invocation",
"invocation",
"invocation"
],
"exitStatuses": [
2,
2,
2,
2,
2,
2,
2
],
"guestEntries": 0,
"canonicalOutcomesProduced": false,
"evaluationReceiptsEligible": false
}Product invocation
Expected result
Duplicate, unknown, incompatible, and incomplete option sets fail during invocation. Product invocation awaits its 2.0 adapter.
The argument arrays specify command syntax. Named operand contents use documentation notation. Their named format contracts define the public bytes. The expectation is authored for Lispex 2.0. Product execution awaits its 2.0 adapter.
Primary output contains one record
lispex.example.v2.cli-and-diagnostics.command-result-framing · rev. 2
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"invocations": [
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"run",
"--artifact",
"a",
"--input",
"-",
"--receipt-output",
"receipt.record"
],
"stdinContent": "one complete canonical Datum followed by EOF",
"input": {
"kind": "integer",
"value": "42"
}
},
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"run",
"--artifact",
"a",
"--input",
"input.datum",
"--output",
"outcome.record",
"--receipt-output",
"receipt.record"
],
"input": {
"kind": "integer",
"value": "42"
}
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"stdoutRecordCounts": [
1,
0
],
"primaryFileRecordCounts": [
0,
1
],
"receiptFileRecordCounts": [
1,
1
],
"extraOutputBytes": false,
"semanticInputFromPath": false,
"guestReads": 0
}Product invocation
Expected result
A stdout result is one named record. A file result leaves stdout empty. Its receipt uses a separate eligible file. Product invocation awaits its 2.0 adapter.
The argument arrays specify command syntax. Named operand contents use documentation notation. Their named format contracts define the public bytes. The expectation is authored for Lispex 2.0. Product execution awaits its 2.0 adapter.
Verification and replay use explicit records
lispex.example.v2.cli-and-diagnostics.command-verification-operands · rev. 2
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"invocations": [
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"verify",
"--expected",
"expected.receipt",
"--actual",
"actual.receipt"
],
"receiptPair": "identical complete semantic request and failure outcome"
},
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"npm",
"replay",
"--artifact",
"rule.artifact",
"--request",
"request.record",
"--expected",
"expected.receipt",
"--engine",
"installed-graph-engine-identity"
],
"request": "same complete recorded semantic request"
},
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"wasm",
"verify",
"--expected",
"expected.receipt",
"--actual",
"changed.receipt"
],
"receiptPair": "different complete semantic request identities"
},
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"replay",
"--artifact",
"rule.artifact",
"--request",
"request.record",
"--expected",
"other.receipt"
],
"recordedRequest": "same admitted rule and input",
"expectedReceipt": "an admitted receipt for a different semantic request"
},
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"npm",
"verify",
"--expected",
"expected.receipt",
"--actual",
"actual.receipt",
"--evidence",
"other.evidence",
"--trust",
"fixed.policy"
],
"receiptPair": "identical complete semantic request and outcome",
"evidenceBinding": "a third unrelated receipt",
"trustInputs": "complete fixed verification inputs"
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"commandCases": [
{
"command": "verify",
"guestEvaluation": false,
"comparison": "equal",
"status": 0
},
{
"command": "replay",
"evaluationInput": "recorded-request",
"evaluationLimits": "recorded-request",
"engineSelection": "explicit-installed-identity",
"semanticOverrides": false
},
{
"command": "verify",
"comparison": "request-mismatch",
"status": 42
},
{
"command": "replay",
"guestEvaluation": false,
"comparison": "not-run",
"phase": "admission",
"code": "artifact.invalid",
"reason": "identity-mismatch",
"status": 30
},
{
"command": "verify",
"guestEvaluation": false,
"comparison": "equal",
"phase": "verify",
"code": "verification.failed",
"check": "evidence-binding",
"status": 42
}
],
"trustInputsImplicit": false,
"externalLookups": 0,
"hostActionAuthorized": false,
"evidenceTargets": {
"verify": "actual-receipt",
"replay": "expected-receipt"
},
"replayPreflightBeforeEntry": true
}Product invocation
Expected result
Verification compares admitted complete outcomes without evaluation. Replay uses only the recorded request. A conflicting expected receipt refuses replay before entry. Supplied evidence authenticates the selected receipt. Product invocation awaits its 2.0 adapter.
The argument arrays specify command syntax. Named operand contents use documentation notation. Their named format contracts define the public bytes. The expectation is authored for Lispex 2.0. Product execution awaits its 2.0 adapter.
Graph projection does not call the rule
lispex.example.v2.cli-and-diagnostics.command-static-graph · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
(car '())))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"invocations": [
{
"argv": [
"lispex",
"--language",
"2.0",
"--product",
"native",
"graph",
"--artifact",
"rule.artifact",
"--output",
"rule.graph"
],
"programBehaviorIfRun": "raises a domain condition"
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"graphProduced": true,
"graphFormat": "lispex.graph/1",
"guestEntries": 0,
"inputReads": 0,
"evaluationReceiptProduced": false,
"exitStatus": 0
}Product invocation
Expected result
Graph accepts the prepared program and writes its canonical graph without evaluating the entry. Product invocation awaits its 2.0 adapter.
The argument arrays specify command syntax. Named operand contents use documentation notation. Their named format contracts define the public bytes. The expectation is authored for Lispex 2.0. Product execution awaits its 2.0 adapter.
15.3 Exact numeric display
Every CLI numeric display uses the numeric display grammar. Integers use decimal digits. Every nonintegral value uses a reduced fraction with a positive denominator. Zero is written as 0. Source scale is absent.
| Exact value or source spelling | Display |
|---|---|
| 0 | 0 |
| -0.00 | 0 |
| 1.00 | 1 |
| 6/3 | 2 |
| 1.50 | 3/2 |
| -0.125 | -1/8 |
| 1/3 | 1/3 |
| 9007199254740993 | 9007199254740993 |
The display contains no leading plus, leading zeroes, exponent, decimal point, grouping mark, or locale variation. It performs no rounding. Canonical value bytes still follow the value codec. Display spelling never selects a different numeric value or semantic identity.
Why
A number has one mathematical value after normalization. Reduced fractions give that value one exact spelling across products. The display needs neither source scale nor rounding policy.
Equal numbers have equal display spellings
lispex.example.v2.cli-and-diagnostics.command-numeric-display · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"operationUnderTest": "Render each exact numeric value for CLI display.",
"sourceSpellings": [
"0",
"-0.00",
"1.00",
"6/3",
"1.50",
"-0.125",
"1/3",
"9007199254740993"
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"numericDisplays": [
{
"input": "0",
"display": "0"
},
{
"input": "-0.00",
"display": "0"
},
{
"input": "1.00",
"display": "1"
},
{
"input": "6/3",
"display": "2"
},
{
"input": "1.50",
"display": "3/2"
},
{
"input": "-0.125",
"display": "-1/8"
},
{
"input": "1/3",
"display": "1/3"
},
{
"input": "9007199254740993",
"display": "9007199254740993"
}
],
"productInvariant": true,
"sourceScaleObserved": false,
"implicitRounding": false,
"localeDependent": false
}Product invocation
Expected result
All products display exact integers and reduced fractions with the same characters. Product invocation awaits its 2.0 adapter.
The argument arrays specify command syntax. Named operand contents use documentation notation. Their named format contracts define the public bytes. The expectation is authored for Lispex 2.0. Product execution awaits its 2.0 adapter.
Run
Supply a source bundle or prepared artifact and one canonical input to lispex run. The selected program declares its entry. The command uses the single Datum boundary. The host reads files or standard input and displays the result. Guest code receives the input as an ordinary argument. The canonical codec defines the data representation.
15.4 One explicit input and one result
The run command applies the entry input rule and the entry result rule. The host supplies and presents those values through the value-only interface.
Why
Explicit input records the facts used by a rule. One result lets every caller handle the same decision without reconstructing a stream of guest effects.
15.5 Fresh requests in interactive tools
Each interactive execution uses a fresh finite request. Source editing state belongs to the host. An earlier value or failure does not become hidden input to the next rule.
Why
A rule should give the same answer when moved from an interactive session into a command or calling application.
Return one explicit input
lispex.example.v2.cli-and-diagnostics.run-result · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "42"
}
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Product invocation
Expected result
The command returns the exact integer 42 as one result Datum. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Reject guest input
lispex.example.v2.cli-and-diagnostics.guest-read · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
(read)))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "0"
}
}
],
"operationUnderTest": "Attempt guest input instead of using the supplied Datum.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
library.referenceOutcome details
{
"kind": "failure",
"valueCount": 0,
"diagnostic": {
"phase": "resolve",
"code": "library.reference",
"data": {
"name": "read",
"reason": "removed-operation"
}
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"guestHostReads": 0,
"canonicalOutcomeProduced": false,
"evaluationReceiptEligible": false
}Product invocation
Expected result
The guest input attempt fails and performs no host read. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Reject multiple boundary results
lispex.example.v2.cli-and-diagnostics.multiple-results · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
(values input input)))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "5"
}
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
value.boundaryOutcome details
{
"kind": "failure",
"valueCount": 0,
"boundary": "entry-result",
"requiredValueCount": 1,
"receivedValueCount": 2,
"diagnostic": {
"phase": "evaluate",
"code": "value.boundary",
"data": {
"reason": "count",
"count": "2",
"path": [],
"actual": false
}
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Product invocation
Expected result
Two internal values cannot escape the single result boundary. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Evaluate after a failed request
lispex.example.v2.cli-and-diagnostics.fresh-runs · rev. 2
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
(car input)))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "empty-list"
}
},
{
"input": {
"kind": "list",
"items": [
{
"kind": "integer",
"value": "9"
}
]
}
}
],
"operationUnderTest": "Execute both requests in the same interactive host while preserving the same fixed rule and finite preset.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
domain.typeOutcome details
{
"kind": "language-failure",
"valueCount": 0,
"condition": {
"phase": "evaluate",
"code": "domain.type",
"data": {
"operation": "car",
"argument": "0",
"path": [],
"expected": "pair",
"actual": "empty-list"
}
}
}9Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "9"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"hiddenInputFromPreviousRequest": false
}Product invocation
Expected result
A failed request is followed by an independent successful request returning 9. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Verify
Verification uses the recorded request and canonical outcome. Replay compares the language result. Signature verification checks the attached issuer evidence. The calling application separately decides whether to trust that issuer or act on the result.
Use the profile work report for qualification or evidence refusal after evaluation. Report the profile work identity and completed canonical outcome separately. A refusal before guest entry uses the admission report and has no canonical evaluation outcome.
15.6 Keep replay and evidence checks distinct
The verify command compares two supplied receipts. It performs no guest evaluation. The replay command evaluates the recorded request and compares its actual receipt with the expected receipt. Both use the comparison contract. They report issuer evidence checks separately. A valid signature does not replace semantic comparison or authorize a host action.
Why
Execution agreement and issuer authentication answer different questions. Reporting each result preserves the information a caller needs to judge a receipt.
Compare a recorded result
lispex.example.v2.cli-and-diagnostics.verified-replay · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "42"
}
},
{
"input": {
"kind": "integer",
"value": "42"
}
}
],
"operationUnderTest": "Record a completed evaluation and replay its identical semantic request. Check any attached issuer evidence separately.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"verification": {
"canonicalOutcomeEqual": true,
"evidenceCheckSeparate": true,
"signatureSubstitutesForReplay": false
},
"externalActionCalls": 0
}Product invocation
Expected result
Replay returns 42 and compares the whole outcome. Issuer evidence remains a separate check. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Finite presets
A preset names a complete finite limit selection. The command resolves that selection before admission and records the effective limits in the request. Products use the same common preset. The Resources chapter defines the resource axes and event order. A malformed explicit limit record is refused.
A profile selects its separate finite profile host budget. Record it with profile work identity. It does not change the base preparation or evaluation request.
15.7 Resolve a common finite preset
Public execution requests use finite limits for every phase they perform. A preparation request uses preparation limits. A run uses separate preparation and evaluation limits. Omitting an explicit selection chooses the common finite preset. Malformed explicit selections cause refusal before evaluation. A product cannot silently reduce the requested limits.
Why
A default is still part of the request. Resolving it explicitly makes the same request reproducible across products and prevents malformed options from opening an unlimited path.
Resolve the same default
lispex.example.v2.cli-and-diagnostics.default-preset · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "42"
}
}
],
"limitSelection": "The caller omits an explicit preset. Admission uses the complete common finite preset once its values are fixed.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"preset": {
"selection": "common-default",
"effectiveLimitsFinite": true,
"effectiveLimitsMatchCommonPreset": true,
"productSpecificReduction": false
}
}Product invocation
Expected result
Omitted limit selection resolves to the same finite limits on each product and returns 42. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Reject malformed explicit limits
lispex.example.v2.cli-and-diagnostics.invalid-limits · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "42"
},
"limitCase": "missing-field"
},
{
"input": {
"kind": "integer",
"value": "42"
},
"limitCase": "unknown-field"
},
{
"input": {
"kind": "integer",
"value": "42"
},
"limitCase": "invalid-value"
},
{
"input": {
"kind": "integer",
"value": "42"
},
"limitCase": "overflow"
},
{
"input": {
"kind": "integer",
"value": "42"
},
"limitCase": "unlimited"
}
],
"limitCaseMeaning": {
"missing-field": "Remove one required axis from an explicit complete record.",
"unknown-field": "Add an unrecognized axis to an explicit record.",
"invalid-value": "Supply a negative budget for a nonnegative axis.",
"overflow": "Supply a value beyond the settled representation range.",
"unlimited": "Request an unlimited axis."
},
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
{"kind":"admission-failure","valueCount":0,"diagnosticIdentity":{"phase":"admission","code":"request.invalid"},"reason":"missing-field"}Outcome details
{
"kind": "admission-failure",
"valueCount": 0,
"diagnosticIdentity": {
"phase": "admission",
"code": "request.invalid"
},
"reason": "missing-field"
}{"kind":"admission-failure","valueCount":0,"diagnosticIdentity":{"phase":"admission","code":"request.invalid"},"reason":"unknown-field"}Outcome details
{
"kind": "admission-failure",
"valueCount": 0,
"diagnosticIdentity": {
"phase": "admission",
"code": "request.invalid"
},
"reason": "unknown-field"
}{"kind":"admission-failure","valueCount":0,"diagnosticIdentity":{"phase":"admission","code":"request.invalid"},"reason":"invalid-value"}Outcome details
{
"kind": "admission-failure",
"valueCount": 0,
"diagnosticIdentity": {
"phase": "admission",
"code": "request.invalid"
},
"reason": "invalid-value"
}{"kind":"admission-failure","valueCount":0,"diagnosticIdentity":{"phase":"admission","code":"request.invalid"},"reason":"overflow"}Outcome details
{
"kind": "admission-failure",
"valueCount": 0,
"diagnosticIdentity": {
"phase": "admission",
"code": "request.invalid"
},
"reason": "overflow"
}{"kind":"admission-failure","valueCount":0,"diagnosticIdentity":{"phase":"admission","code":"request.invalid"},"reason":"unlimited"}Outcome details
{
"kind": "admission-failure",
"valueCount": 0,
"diagnosticIdentity": {
"phase": "admission",
"code": "request.invalid"
},
"reason": "unlimited"
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"entryEvaluations": 0,
"defaultsSubstitutedForInvalidFields": false,
"canonicalOutcomeProduced": false,
"evaluationReceiptEligible": false
}Product invocation
Expected result
Each malformed explicit limit request is refused before evaluation. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Outcomes and exit mapping
An exit class tells the caller how the command finished. A returned Datum is successful evaluation, including an application decision named deny or review. Language and resource failures, request refusal, profile refusal, and operational failure remain distinguishable.
The numeric mapping below distinguishes source preparation, admission, qualification, and required evidence. The command preserves a completed canonical outcome. A failed evaluation keeps its status when later profile host work refuses.
15.8 Common command outcomes
Products report common exit classes for a returned Datum, a deterministic language or resource failure, a request refusal, a profile refusal, and an operational failure. Application decision labels remain ordinary result data. After a successful evaluation, qualification or required evidence refusal uses the profile refusal class. The command reports the completed canonical outcome and the separate profile work report. A deterministic evaluation failure retains its failure class when later profile work also refuses.
Why
Scripts need to distinguish a completed decision from a request that never produced a language result. Common classes make that distinction independent of the chosen product.
A caller needs to distinguish a completed language evaluation from delivery of a qualified profile result. A separate profile refusal class exposes that failure without rewriting the language outcome.
Return application decision data
lispex.example.v2.cli-and-diagnostics.decision-data · rev. 2
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "symbol",
"value": "deny"
}
},
{
"input": {
"kind": "symbol",
"value": "review"
}
}
],
"operationUnderTest": "Use base language input data. No vouch/2 decision schema is established by these symbol values.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
denyOutcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "symbol",
"value": "deny"
}
}reviewOutcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "symbol",
"value": "review"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"exitClasses": [
"success",
"success"
],
"exitStatuses": [
0,
0
]
}Product invocation
Expected result
Data named deny and review each return successfully. Their names do not select a failure exit. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Report profile refusal after successful evaluation
lispex.example.v2.cli-and-diagnostics.profile-refusal-exit · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "42"
}
},
{
"input": {
"kind": "integer",
"value": "42"
}
}
],
"operationUnderTest": "Keep the base requests identical. The first host profile attempt stops during qualification. The second stops while producing required evidence.",
"profileWork": {
"contract": "one fixed versioned profile work contract accepting the returned integer",
"attempts": [
{
"identity": "qualification-work",
"profileHostBudget": "finite resources below the next required qualification reservation"
},
{
"identity": "evidence-work",
"profileHostBudget": "finite resources sufficient for qualification but below the next required evidence reservation"
}
]
},
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}42Outcome details
{
"kind": "value",
"valueCount": 1,
"datum": {
"kind": "integer",
"value": "42"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"exitClasses": [
"profile-refusal",
"profile-refusal"
],
"profileWorkReports": [
{
"profileWorkIdentity": "qualification-work",
"stage": "qualification",
"status": "budget-refusal",
"canonicalOutcomePreserved": true,
"evaluationReceiptEligible": true,
"diagnosticIdentity": {
"phase": "qualification",
"code": "profile.budget"
}
},
{
"profileWorkIdentity": "evidence-work",
"stage": "evidence",
"status": "budget-refusal",
"canonicalOutcomePreserved": true,
"evaluationReceiptEligible": true,
"diagnosticIdentity": {
"phase": "evidence",
"code": "profile.budget"
}
}
],
"evaluationRequestUnchanged": true,
"exitStatuses": [
40,
41
]
}Product invocation
Expected result
Both evaluations return the exact integer 42. Qualification or required evidence work then exhausts the separate profile host budget. Both commands report profile refusal while preserving their canonical outcomes and evaluation receipt eligibility. Product invocation awaits its 2.0 adapter.
The finite profile host budget is insufficient for the named host phase. The evaluation request and its finite limits are unchanged. Qualification uses status 40. Required evidence uses status 41. Report encoding follows its separate format contract.
Report an evaluation domain failure
lispex.example.v2.cli-and-diagnostics.domain-phase · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
(car input)))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "empty-list"
}
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
domain.typeOutcome details
{
"kind": "language-failure",
"valueCount": 0,
"condition": {
"phase": "evaluate",
"code": "domain.type",
"data": {
"operation": "car",
"argument": "0",
"path": [],
"expected": "pair",
"actual": "empty-list"
}
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"exitClasses": [
"deterministic-failure"
],
"diagnostic": {
"phase": "evaluate",
"code": "domain.type",
"data": {
"operation": "car",
"argument": "0",
"path": [],
"expected": "pair",
"actual": "empty-list"
}
},
"exitStatuses": [
20
]
}Product invocation
Expected result
Applying car to the empty list reports a domain failure during evaluation and no result Datum. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Report incomplete host input
lispex.example.v2.cli-and-diagnostics.host-ingestion · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [],
"hostSetup": {
"fault": "source-or-input-read-fails-before-complete-bytes",
"stage": "ingestion"
},
"operationUnderTest": "Simulate a transport failure before the host has the complete source and input bytes.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"requestReport": {
"kind": "transport-failure",
"completeSubmission": false,
"entryEvaluated": false,
"semanticReceiptAvailable": false,
"diagnosticIdentity": {
"phase": "ingestion",
"code": "transport.input"
}
},
"exitClasses": [
"request-refusal"
],
"exitStatuses": [
2
]
}Product invocation
Expected result
A failed host read rejects the request before a complete submission or evaluation exists. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Report a resource failure exit
lispex.example.v2.cli-and-diagnostics.command-resource-stop · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
(let loop ()
(loop))))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to prepare this rule",
"evaluate": "finite values sufficient to enter the recursive call. The settled event order selects the first exhausted axis."
},
"requests": [
{
"input": {
"kind": "integer",
"value": "0"
}
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
resource-stopOutcome details
{
"kind": "resource-stop",
"valueCount": 0,
"terminal": true,
"diagnosticIdentity": {
"phase": "evaluate",
"code": "resource.exhausted"
}
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"exitClasses": [
"deterministic-failure"
],
"exitStatuses": [
21
]
}Product invocation
Expected result
An unending rule under finite limits ends in the deterministic failure class. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
Report an operational failure exit
lispex.example.v2.cli-and-diagnostics.command-interruption · rev. 3
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "finite values sufficient to complete preparation checks",
"evaluate": "finite values sufficient for the stated finite calculation"
},
"requests": [
{
"input": {
"kind": "integer",
"value": "42"
},
"hostFault": "operational-interruption-after-admission"
}
],
"operationUnderTest": "Interrupt an admitted evaluation through a controlled host fault hook.",
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"attemptReports": [
{
"kind": "operational-interruption",
"semanticReceiptAvailable": false,
"successValueAvailable": false,
"diagnosticIdentity": {
"phase": "host",
"code": "host.interrupted"
}
}
],
"exitClasses": [
"operational-failure"
],
"exitStatuses": [
50
]
}Product invocation
Expected result
An operational interruption uses the operational failure class and has no semantic receipt. Product invocation awaits its 2.0 adapter.
The source and request files express the 2.0 case. The request file is documentation notation. It does not define command options, codec bytes, artifact fields, diagnostic codes or numeric exit values. Each product plan compares the complete authored expectation. Product execution awaits the 2.0 observation adapter.
15.9 Numeric command status
Each completed command uses the numeric status in this table. The status describes command completion. The canonical outcome remains separate.
| Status | Phase | Completion | Exit class |
|---|---|---|---|
| 0 | Any completed operation | The requested operation succeeds | success |
| 2 | invocation or ingestion | Command arguments or input transport fail | request-refusal |
| 10 | decode, read, normalize, resolve, or prepare | Complete submitted source fails preparation | deterministic-failure |
| 11 | prepare | A finite preparation limit stops preparation | deterministic-failure |
| 20 | evaluate | An uncaught condition or value boundary failure ends evaluation | deterministic-failure |
| 21 | evaluate | A finite evaluation limit stops evaluation | deterministic-failure |
| 30 | admission | Artifact, package, request, or profile admission refuses entry | request-refusal |
| 40 | qualification | Qualification or its host budget refuses a successful evaluation | profile-refusal |
| 41 | evidence | Required evidence or its host budget refuses a successful evaluation | profile-refusal |
| 42 | verify or replay | Admitted records fail verification or comparison | request-refusal |
| 50 | render or host | Output delivery or host execution is interrupted | operational-failure |
| 51 | host | The product reports an engine defect | operational-failure |
The preparation resource diagnostic uses phase prepare. Its stage identifies the interrupted source step. Status 11 produces no canonical evaluation outcome or evaluation receipt. Status 30 also produces neither.
Status 20 or 21 retains precedence over later qualification or evidence refusal. After successful evaluation, the first required profile refusal determines status 40 or 41. Both preserve the completed canonical outcome and its evaluation receipt eligibility.
A successful verification command returns 0 even when its operand records a language or resource failure. An exact replay preserves status 20 or 21 for a reproduced evaluation failure. A replay mismatch returns 42. The report preserves both the recorded outcome and the recomputed outcome. Operand admission failure uses 30 before comparison begins.
Output delivery failure uses command/CLI completion classification 50 even when evaluation has completed. Preserve the completed outcome and receipt. Qualification or evidence refusal still leaves completed evaluation status 20 or 21 unchanged; this precedence does not convert a delivery interruption into a profile refusal.
CommandResult.status is the status serialized in the selected packet. Delivery completion can be learned after that packet was fixed. Before the first primary octet, a complete preserving status 50 replacement may be selected under the command result guards. After the first octet, retain the packet's original status and bytes and classify command/CLI completion as 50 from the existing transport-error observation. A full packet followed by a flush failure obeys the same rule. Unknown delivery count or an in-flight write cannot establish the confirmed zero needed for replacement. A rejected replacement retains the original complete packet and completed data.
The delivery packet examples supply complete packets for these boundaries. An operational failure or engine defect never becomes a language failure receipt. An external process termination without a completion report supplies no portable command status. Other numeric command statuses are reserved.
This command/CLI classification preserves the existing ABI transport call-status enum 0, 1, and 2. A complete ABI reply uses transport success 0 even when its complete command record reports a refusal or failure. No extra status field, channel, or API is introduced.
Why
Callers need to distinguish invalid source, exhausted preparation limits, rejected entry, and failed evaluation. Separate profile statuses show which later obligation failed. Fixed numbers let every product report the same completion without changing the language outcome.
Transport completion stays separate from bytes already delivered. Status 50 reports interruption without retroactively changing an earlier packet or its canonical evaluation outcome.
Every phase has a command status
lispex.example.v2.cli-and-diagnostics.phase-exit-table · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"operationUnderTest": "Classify each reported command completion after the named phase has failed.",
"completions": [
{
"phase": "invocation",
"failure": "request"
},
{
"phase": "ingestion",
"failure": "request"
},
{
"phase": "decode",
"failure": "source"
},
{
"phase": "read",
"failure": "source"
},
{
"phase": "normalize",
"failure": "source"
},
{
"phase": "resolve",
"failure": "source"
},
{
"phase": "prepare",
"failure": "source"
},
{
"phase": "prepare",
"failure": "resource.exhausted"
},
{
"phase": "evaluate",
"failure": "condition-or-value-boundary"
},
{
"phase": "evaluate",
"failure": "resource.exhausted"
},
{
"phase": "admission",
"failure": "request-or-profile"
},
{
"phase": "qualification",
"failure": "profile-after-success"
},
{
"phase": "evidence",
"failure": "profile-after-success"
},
{
"phase": "verify",
"failure": "comparison-or-verification"
},
{
"phase": "replay",
"failure": "comparison-or-verification"
},
{
"phase": "render",
"failure": "operational-interruption"
},
{
"phase": "host",
"failure": "operational-interruption"
},
{
"phase": "host",
"failure": "engine-defect"
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
[]Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"commandStatuses": [
{
"phase": "invocation",
"failure": "request",
"status": 2,
"exitClass": "request-refusal"
},
{
"phase": "ingestion",
"failure": "request",
"status": 2,
"exitClass": "request-refusal"
},
{
"phase": "decode",
"failure": "source",
"status": 10,
"exitClass": "deterministic-failure"
},
{
"phase": "read",
"failure": "source",
"status": 10,
"exitClass": "deterministic-failure"
},
{
"phase": "normalize",
"failure": "source",
"status": 10,
"exitClass": "deterministic-failure"
},
{
"phase": "resolve",
"failure": "source",
"status": 10,
"exitClass": "deterministic-failure"
},
{
"phase": "prepare",
"failure": "source",
"status": 10,
"exitClass": "deterministic-failure"
},
{
"phase": "prepare",
"failure": "resource.exhausted",
"status": 11,
"exitClass": "deterministic-failure"
},
{
"phase": "evaluate",
"failure": "condition-or-value-boundary",
"status": 20,
"exitClass": "deterministic-failure"
},
{
"phase": "evaluate",
"failure": "resource.exhausted",
"status": 21,
"exitClass": "deterministic-failure"
},
{
"phase": "admission",
"failure": "request-or-profile",
"status": 30,
"exitClass": "request-refusal"
},
{
"phase": "qualification",
"failure": "profile-after-success",
"status": 40,
"exitClass": "profile-refusal"
},
{
"phase": "evidence",
"failure": "profile-after-success",
"status": 41,
"exitClass": "profile-refusal"
},
{
"phase": "verify",
"failure": "comparison-or-verification",
"status": 42,
"exitClass": "request-refusal"
},
{
"phase": "replay",
"failure": "comparison-or-verification",
"status": 42,
"exitClass": "request-refusal"
},
{
"phase": "render",
"failure": "operational-interruption",
"status": 50,
"exitClass": "operational-failure"
},
{
"phase": "host",
"failure": "operational-interruption",
"status": 50,
"exitClass": "operational-failure"
},
{
"phase": "host",
"failure": "engine-defect",
"status": 51,
"exitClass": "operational-failure"
}
],
"sourcePreparationReceiptEligible": false,
"admissionReceiptEligible": false,
"productDependentStatus": false
}Product invocation
Expected result
Source preparation uses 10 or 11. Admission uses 30. Qualification and evidence use 40 and 41. Product invocation awaits its 2.0 adapter.
The fixture describes command observations as documentation data. The numeric statuses follow this Rule. Report bytes use their own format contracts. Product execution awaits the 2.0 observation adapter.
An evaluation failure keeps its status
lispex.example.v2.cli-and-diagnostics.evaluation-before-profile-exit · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"operationUnderTest": "Complete a failing evaluation and then refuse required profile host work.",
"requests": [
{
"guestFailure": "domain",
"laterProfileFailure": "evidence"
},
{
"guestFailure": "resource",
"laterProfileFailure": "qualification"
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
{"kind":"language-failure","valueCount":0,"conditionFamily":"domain","canonicalOutcomeProduced":true,"evaluationReceiptEligible":true}Outcome details
{
"kind": "language-failure",
"valueCount": 0,
"conditionFamily": "domain",
"canonicalOutcomeProduced": true,
"evaluationReceiptEligible": true
}resource-stopOutcome details
{
"kind": "resource-stop",
"valueCount": 0,
"terminal": true,
"canonicalOutcomeProduced": true,
"evaluationReceiptEligible": true
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"exitStatuses": [
20,
21
],
"exitClasses": [
"deterministic-failure",
"deterministic-failure"
],
"profileWorkPhases": [
"evidence",
"qualification"
],
"canonicalOutcomesPreserved": true,
"evaluationReceiptsEligible": [
true,
true
]
}Product invocation
Expected result
An uncaught domain condition keeps 20 after evidence refusal. Evaluation exhaustion keeps 21 after qualification refusal. Product invocation awaits its 2.0 adapter.
The fixture describes command observations as documentation data. The numeric statuses follow this Rule. Report bytes use their own format contracts. Product execution awaits the 2.0 observation adapter.
Verification and replay retain the outcome
lispex.example.v2.cli-and-diagnostics.verification-exit-precedence · rev. 1
(module main
(import)
(export rule)
(entry rule)
(define rule
(lambda (input)
input))
)
Request and files
{
"notation": "documentation-request",
"source": "source.scm",
"semantics": {
"language": "Lispex 2.0",
"standardLibrary": "one fixed library identity",
"unicode": "one fixed Unicode semantics version",
"resourceModel": "one fixed finite resource model"
},
"limits": {
"prepare": "the named finite preparation contract",
"evaluate": "the named finite evaluation contract",
"profileHost": "the named finite profile host contract"
},
"operationUnderTest": "Verify a failure receipt, replay its exact request, then compare a deliberately different admitted expected outcome.",
"requests": [
{
"command": "verify",
"recordedOutcome": "language-failure",
"recordsValid": true
},
{
"command": "replay",
"recordedOutcome": "language-failure",
"recomputedOutcome": "same-language-failure"
},
{
"command": "replay",
"recordedOutcome": "integer-42",
"recomputedOutcome": "language-failure"
}
],
"rootModule": "main",
"moduleSources": [
{
"name": "main",
"source": "source.scm"
}
]
}
{"kind":"language-failure","valueCount":0,"conditionFamily":"domain","canonicalOutcomeProduced":true,"evaluationReceiptEligible":true}Outcome details
{
"kind": "language-failure",
"valueCount": 0,
"conditionFamily": "domain",
"canonicalOutcomeProduced": true,
"evaluationReceiptEligible": true
}{"kind":"language-failure","valueCount":0,"conditionFamily":"domain","canonicalOutcomeProduced":true,"evaluationReceiptEligible":true}Outcome details
{
"kind": "language-failure",
"valueCount": 0,
"conditionFamily": "domain",
"canonicalOutcomeProduced": true,
"evaluationReceiptEligible": true
}Specification outcome. Product runs are pending the 2.0 adapter.
Semantic details
{
"commandStatuses": [
{
"command": "verify",
"match": true,
"status": 0,
"exitClass": "success"
},
{
"command": "replay",
"match": true,
"status": 20,
"exitClass": "deterministic-failure"
},
{
"command": "replay",
"match": false,
"status": 42,
"exitClass": "request-refusal"
}
],
"mismatchPreservesRecordedOutcome": true,
"mismatchPreservesRecomputedOutcome": true,
"verificationExecutesGuest": false
}Product invocation
Expected result
Verification of an admitted failure receipt succeeds with 0. An exact replay of that failure uses 20. A replay mismatch uses 42 and keeps both outcomes. Product invocation awaits its 2.0 adapter.
The fixture describes command observations as documentation data. The numeric statuses follow this Rule. Report bytes use their own format contracts. Product execution awaits the 2.0 observation adapter.