0x0LearnReferenceLibraries0x0.jmp0x1b.com

0x0 Scripting And REPL

The scripting profile adds direct execution and interactive inspection without

changing 0x0 into a separate interpreted language. Compiled 0x0 remains the production artifact path for programs, packages, runtime modules, native artifacts, release outputs, and deployment claims.

Script and REPL execution reuse the same parser, source contracts, type/effect

rules, package/import semantics, capability model, and host ABI boundary as the

compiled path. The profile is tracked by source and tooling contract evidence;

see docs/contract-taxonomy.tsv for the accepted contract kinds.

The three direct-execution surfaces are Eval 0x0, Script 0x0, and REPL 0x0.

The first frozen scripting compatibility profile is scripting-profile-v1.

That profile id names the stable command, output, capability, host ABI, REPL,

diagnostic, and deterministic behavior described here.

Command Surfaces

bin/zero eval evaluates one expression or form and prints the resulting value

with the stable scripting printer. It is for quick pure checks, smoke fixtures,

and small automation fragments.

The current bounded implementation exposes the equivalent tracked path

tools/zero-scripting.sh eval <expr>. That adapter writes the expression into a

declared build input, invokes the source-owned tools/scripting-eval.0x0

evaluator with bin/zero run, and maps the returned OK or ERR record to

stdout, stderr, and exit status.

The command family is tools/zero-scripting.sh eval,

tools/zero-scripting.sh eval --json, `tools/zero-scripting.sh eval --cap

<name>, tools/zero-scripting.sh script, tools/zero-scripting.sh script

--text, tools/zero-scripting.sh script --json`,

tools/zero-scripting.sh script --cap <name> <path.0x0> [-- args...], and

tools/zero-scripting.sh repl [--json] [--cap <name>] [--history <path>].

The current bounded eval slice supports pure literal integers, text, booleans,

Unit, (list ...) expressions, arithmetic +, -, *, /, comparisons,

if, text-len, text-cat, text-split, text-trim, text-replace,

text-prefix?, text-suffix?, text-contains?, pattern-match?,

json-encode, json-decode, json-object, record, record-get,

record-set, record-keys, record-has?, record-from-json,

record-to-json, and record-from-tsv-row. The TSV helper slice adds

tsv-decode, tsv-encode, tsv-headers, tsv-rows, and tsv-get. The path

helper slice adds path-normalize, path-join, and path-escape?.

Unsupported pure calls fail with SCRIPTING_TYPE_EFFECT; known host-effect

calls fail with

SCRIPTING_CAPABILITY until the matching host ABI scripting wrappers are

implemented. Malformed expressions fail with SCRIPTING_PARSE.

eval --json emits a stable source-owned report. Successful pure expressions

include capabilities, effects, expression, status, type, and

value; failed expressions include capabilities, effects, error,

expression, message, and status. Pure eval reports use an empty effects

list.

bin/zero script executes a .0x0 source file as a tool entrypoint. Script

execution receives explicit script arguments, returns a stable exit status, and

prints only declared stdout values unless an output mode requests structured

reports.

The current bounded implementation exposes the equivalent tracked path

tools/zero-scripting.sh script [--text|--json] <path.0x0> [-- args...]. It

requires exactly one main entrypoint and executes generated source through the

same checked bin/zero run path. Script arguments are exposed as (argv)

through a source-owned rewrite that turns the declared adapter argv input into a

stable text list; any script that reads (argv) must declare (cap process).

Scripts may return Unit successfully, or use the bounded explicit exit form

(script-exit N) where N is in the 0..125 range. The preflight rewrites the

explicit exit form to Unit, records the requested exit status in the

source-owned script record, and the adapter returns that status after checked

execution. (script-fail ...) is the current bounded typed failure surface and

fails before execution with a stable diagnostic.

Script output mode is also validated by the source-owned preflight. Text mode is

the default and prints the stable value emitted by bin/zero run. JSON mode

captures successful script stdout and prints a stable object with

capabilities, exit, mode, status, and value; diagnostics remain on

stderr in both modes.

Executable scripts may start with the approved shebang

#!/usr/bin/env zero-script. The source-owned preflight strips that first line

before checked execution; unapproved shebangs fail closed.

Missing files and invalid command shapes fail with SCRIPTING_COMMAND;

parse/checker failures fail with SCRIPTING_PARSE; missing or ambiguous

entrypoints fail with SCRIPTING_SCRIPT_ENTRY; argv without process

capability fails with SCRIPTING_CAPABILITY; malformed or out-of-range explicit

exits fail with SCRIPTING_SCRIPT_EXIT; typed script failures fail with

SCRIPTING_SCRIPT_FAILURE; unapproved shebangs fail with

SCRIPTING_SCRIPT_SHEBANG. Top-level expression scripts remain outside the

bounded profile.

bin/zero repl starts an interactive REPL 0x0 session. A REPL entry is parsed,

type/effect checked, and evaluated under the session capability set. REPL

commands such as help, load, inspect, and capability audit are command forms,

not bypasses around source checking.

The current bounded implementation exposes the equivalent tracked path

tools/zero-scripting.sh repl. It prints the stable 0x0> prompt, reads one

logical form, evaluates the form through the source-owned eval path, prints the

value, and prompts again. In text mode, incomplete parenthesized forms use the

stable ...> continuation prompt until the form is complete. JSON transcript

mode accumulates the same logical input without printing prompts. EOF with an

unmatched opening parenthesis reports SCRIPTING_PARSE with

unterminated multiline form and exits cleanly. Unterminated strings are sent

to the normal parser immediately, report SCRIPTING_PARSE, and the next input

line starts a new logical form. :quit exits with status 0; EOF also exits

with status 0. Parse and type/effect failures are reported with stable

diagnostics without terminating the session. The bounded command set includes

:help,

:cap, :cap add <name>, :audit, :type <form>, :effects <form>,

:let <name> <form>, :fn <name> <arg> <form>,

:load <path.0x0>, :pkg <package> [signature-lock.tsv], :modules,

:exports <module>, and :version; unknown REPL commands report

SCRIPTING_REPL_COMMAND without terminating the session. Bounded :let

definitions store the expanded pure form after successful evaluation, so failed

value definitions are not added to the session. Bounded :fn definitions store

one-argument pure function rewrites that can be called later as (name arg).

Redefining a value or function name replaces the previous binding, and a value

definition also replaces any function with the same name. Bounded :load

accepts only relative .0x0 paths without .. segments, reads the file's

explicit (↦ ...) export list, and imports simple one-argument exported

functions into the session. Loaded modules are recorded by their (⊙ module)

declaration. :modules lists loaded module names as a deterministic JSON array,

and :exports <module> lists that module's loaded exported names in stable

sorted order. Missing files, path escapes, missing module declarations,

unsupported source shapes, or files without bounded exported functions report

SCRIPTING_REPL_LOAD without terminating the session. Unknown module names in

:exports <module> report SCRIPTING_REPL_COMMAND without terminating the

session. repl --json is the stable transcript mode for

automated tests. It emits one JSON object per input line with capabilities,

effects, input, status, type, and either value or error plus

message; transcript mode does not print prompts.

Bounded :pkg <package> [signature-lock.tsv] imports a local package through

the root 0x0.lock dependency map. The package command reads `dep <package>

<path> rows, loads the referenced .0x0` source, records the package module,

and imports bounded one-argument public functions. If a source declares

(↦ ...), only those exported names are considered public; otherwise package

imports follow compiler package semantics and treat all functions as public.

The optional signature lock uses the production-depth

module/function/signature/effects/source_sha256 TSV shape. Rows matching the

imported package module must match the source signature, effect row, and source

hash or the REPL reports PKG_SIGNATURE_DRIFT. Missing package rows report

TE_IMPORT_PKG, malformed signature locks report PKG_SIGNATURE_SCHEMA, and

the REPL does not rewrite or regenerate 0x0.lock or package manifests.

REPL history is disabled by default, including non-interactive stdin sessions

used by tests. The bounded adapter does not infer a history path from HOME,

shell history, or terminal state. Persistent history is opt-in with

tools/zero-scripting.sh repl --history <path>. The --history <path> option

requires a relative root-scoped path without .. segments. The adapter creates

the parent directory and appends only privacy-safe input lines. Blank lines,

:quit, capability mutations, value or function definitions, host-effect

calls, and inputs containing key, token, secret, password, private, bearer,

auth, payload, or signature markers are not written. Signing payloads and

secrets are therefore not written by default; callers that need full transcripts

should use explicit repl --json output and store it under their own policy.

bin/zero run remains the compatibility path for existing .0x0 tool

invocation while script mode is phased in. New scripting milestones should make

bin/zero script the production spelling and keep bin/zero run compatible

only where existing tools depend on it.

Capabilities

Eval starts pure. Script and REPL sessions start with no host capabilities

unless a caller grants them explicitly.

The command-line capability spelling starts with --cap file and uses the

same pattern for the remaining source capability names:


--cap file
--cap process
--cap network
--cap crypto
--cap hardware

Each granted source capability maps to the runtime host ABI operation it needs

in runtime/host-abi.tsv. File calls require file, process calls require

process, HTTP and socket calls require network, signing and verification

require crypto, and hardware emulator calls require hardware.

Unknown capability names fail closed with SCRIPTING_CAPABILITY. JSON reports

include the requested capabilities in fixed source capability order:

file, process, network, crypto, then hardware.

In REPL text mode, :cap prints the active capability set in the same stable

JSON-array spelling and :cap add <name> enables one supported source

capability for the current session. In REPL transcript mode, capability changes

are reflected in the capabilities field on the command response and all

subsequent responses. REPL :audit prints a deterministic JSON report with

the active requested capabilities and the successful host ABI operation ids

observed so far:


{"capabilities":["file"],"host_abi_operations":["fs.read"]}

Denied host operations fail before the audit state is updated, so failed

capability checks are not reported as successful observed effects. In

repl --json transcript mode, :audit returns the same report as an Audit

response value.

JSON Helpers

The bounded scripting standard library includes stable JSON helpers in eval,

script, and REPL mode:


(json-encode value)
(json-decode text)
(json-object "key" value ...)

json-encode accepts scripting integers, text, booleans, Unit, lists, and

JSON objects. Unit encodes as JSON null, and (list ...) encodes as a JSON

array. json-object builds an object from alternating text keys and values.

Object output is sorted by key before printing or encoding, so

(json-object "b" 2 "a" 1) encodes as {"a":1,"b":2}.

json-decode parses JSON objects, arrays, strings, integers, booleans, and

null. Decoded null becomes Unit; decoded arrays become stable scripting

lists; decoded objects become stable JSON object values with deterministic key

ordering. Malformed JSON fails with SCRIPTING_PARSE, and invalid helper

argument types or odd json-object key/value pairs fail with

SCRIPTING_TYPE_EFFECT.

Script mode supports these helpers through a bounded pre-execution rewrite that

evaluates explicit JSON helper forms with the same source-owned eval runner

before compiled execution. Direct script substitution is intentionally limited

to literals that can be represented in checked source. Decoded arrays are

rewritten to (list ...) source. Object results should be consumed through

json-encode, eval mode, or REPL mode until the native compiled standard

library grows first-class JSON object value constructors.

TSV Helpers

The bounded scripting standard library includes stable TSV helpers in eval,

script, and REPL mode:


(tsv-decode text)
(tsv-encode table)
(tsv-headers table)
(tsv-rows table)
(tsv-get table row-index "column")

tsv-decode parses a header row followed by zero or more data rows. Fields are

split on tab characters and rows are split on newline characters. A single

final newline is canonicalized away during parsing and restored by

tsv-encode, so writer output is deterministic. Header order and row order are

preserved exactly.

Duplicate headers, empty headers, empty TSV input, and rows whose field count

does not match the header count fail with SCRIPTING_PARSE. tsv-get returns

one cell by zero-based row index and header name; missing rows or columns fail

with SCRIPTING_TYPE_EFFECT.

tsv-headers returns a scripting list of header names. tsv-rows returns a

list of row field lists. tsv-encode writes the canonical TSV text for a table

returned by tsv-decode.

Path Helpers

The bounded scripting standard library includes pure POSIX-style path helpers

in eval, script, and REPL mode:


(path-normalize text)
(path-join base child)
(path-escape? root candidate)

These helpers are lexical only and do not touch the filesystem. Repeated

slashes are collapsed, . segments are removed, and .. segments are resolved

without crossing an absolute root. Relative paths that would escape retain a

leading .., so (path-normalize "a/../../b") returns "../b".

path-join applies the same normalization after joining a relative child to a

base path. Absolute children replace the base path, matching POSIX path join

behavior. path-escape? returns true when an absolute candidate is outside

an absolute root, or when a relative candidate normalizes to a leading ...

This gives scripts a pure preflight check before calling filesystem host ABI

wrappers.

Text And Pattern Helpers

The bounded scripting standard library includes common pure text helpers in

eval, script, and REPL mode:


(text-split text separator)
(text-trim text)
(text-replace text needle replacement)
(text-prefix? text prefix)
(text-suffix? text suffix)
(text-contains? text needle)
(pattern-match? text pattern)

text-split performs literal, non-regex splitting and preserves empty fields,

including leading, repeated, and trailing separators. Empty separators fail

with SCRIPTING_TYPE_EFFECT. text-trim removes only ASCII whitespace:

space, tab, line feed, and carriage return. text-replace performs

left-to-right, non-overlapping literal replacement; an empty needle fails with

SCRIPTING_TYPE_EFFECT.

text-prefix?, text-suffix?, and text-contains? perform literal,

case-sensitive checks. Empty prefixes and suffixes match every string, and an

empty contains needle returns true.

pattern-match? is a bounded full-string glob matcher. The ASCII metacharacter

* matches zero or more existing Text characters, and ? matches exactly

one existing Text character. There is no escaping, regex syntax, case

folding, locale handling, or Unicode normalization. Non-metacharacter content

is compared with the same Text equality and indexing primitives used by the

rest of the scripting profile.

Record Helpers

The bounded scripting standard library includes deterministic record helpers

in eval, script, and REPL mode:


(record "key" value ...)
(record-get record "key")
(record-set record "key" value)
(record-keys record)
(record-has? record "key")
(record-from-json json-object)
(record-to-json record)
(record-from-tsv-row table row-index)

record constructs a Record value from alternating text keys and values.

Keys are stored in deterministic order using the same stable ordering as JSON

objects. Duplicate keys use the last value supplied through construction or

record-set, and the printed shape is ("RecordV1" ("key" value-json) ...).

record-get returns the decoded value for an existing key. Missing keys fail

with SCRIPTING_TYPE_EFFECT and the stable message missing record key.

record-has? returns a boolean when callers need to branch before lookup.

record-keys returns the sorted list of keys.

Records interoperate with JSON through stable JSON object storage.

json-encode accepts a Record directly, record-to-json returns a

JsonObject, and record-from-json converts a decoded JSON object into a

Record. record-from-tsv-row converts one row from a tsv-decode table into

a record whose keys are the TSV headers and whose values are text fields.

Filesystem Host ABI Scripting

The bounded filesystem scripting slice supports literal-path calls to

runtime-fs-read, runtime-fs-list, and runtime-fs-walk in script and REPL

mode. Scripts must declare (cap file) in source and callers must grant

--cap file; REPL sessions must start with --cap file or enable it with

:cap add file before evaluating filesystem calls.

Filesystem calls are root-scoped through production-host-runtime with

ZERO_RUNTIME_ROOT set to the current repository root. Path escapes are

rejected before checked script execution with SCRIPTING_HOST_ABI.

Successful filesystem calls are materialized as stable host result values:


HostFileReadResultV1(path,text,bytes,sha256)
HostDirectoryListResultV1(path,entries)
HostDirectoryWalkResultV1(path,entries)
HostDirectoryEntryV1(path,kind,size,ordering-key)

runtime-fs-list returns entries sorted by name. runtime-fs-walk returns

entries sorted by relative path with file sizes where available. REPL

:effects reports the underlying ABI operation, such as ["fs.read"] or

["fs.walk"], and transcript mode includes both the requested capabilities and

the effect list.

Process Host ABI Scripting

The bounded process scripting slice supports literal runtime-process-spawn

calls in script and REPL mode:


(runtime-process-spawn timeout cwd (list "KEY=VALUE" ...) stdin (list "argv" ...))

Scripts must declare (cap process) in source and callers must grant

--cap process; REPL sessions must start with --cap process or enable it

with :cap add process before evaluating process calls. The adapter invokes

production-host-runtime process-spawn, which executes the argv array directly

without an implicit shell.

Successful process calls are materialized as stable host result values:


HostProcessResultV1(argv,cwd,exit-code,stdout,stderr,elapsed-ms,timed-out,killed,error-code)

The current slice covers argv array execution, cwd, env overrides, stdin,

stdout, stderr, exit code, elapsed time, timeout marker, killed marker, and

stable error code. REPL :effects reports ["process.spawn"], and transcript

mode includes the requested capabilities and effect list.

Network Host ABI Scripting

The bounded network scripting slice supports loopback-verified literal HTTP

and socket calls in script and REPL mode:


(runtime-http-fetch method url body)
(runtime-socket-connect host port payload read-bytes timeout)

Scripts must declare (cap network) in source and callers must grant

--cap network; REPL sessions must start with --cap network or enable it

with :cap add network before evaluating network calls. The adapter invokes

production-host-runtime http-fetch and `production-host-runtime

socket-connect` through the runtime host ABI boundary.

Successful network calls are materialized as stable host result values:


HostHttpResultV1(status,headers-hash,body,body-hash,timed-out,error-code)
HostSocketResultV1(endpoint,bytes-sent,bytes-read,payload-hash,timed-out,error-code)

HTTP failures use a -1 status with HOST_ABI_HTTP or

HOST_ABI_HTTP_TIMEOUT. Socket failures keep the endpoint and return stable

byte counts, timeout marker, payload hash, and HOST_ABI_SOCKET or

HOST_ABI_SOCKET_TIMEOUT. REPL :effects reports ["http.fetch"] or

["socket.connect"], and transcript mode includes the requested capabilities

and effect list. The scripting tests use loopback-only fixtures and do not

depend on remote network access.

Signing Host ABI Scripting

The bounded signing scripting slice supports fixture-key signing and

verification in script and REPL mode:


(runtime-sign key-id algorithm payload)
(runtime-verify key-id algorithm payload signature)

Scripts must declare (cap crypto) in source and callers must grant

--cap crypto; REPL sessions must start with --cap crypto or enable it with

:cap add crypto before evaluating signing calls. The adapter invokes

production-host-runtime sign and production-host-runtime verify through the

runtime host ABI boundary. The production scripting fixture uses

fixture-sha256 only; no release key custody or external signing service is

required for this gate.

Signing and verification calls are materialized as stable receipt values:


HostSigningReceiptV1(key-id,algorithm,payload-hash,signature-hash,status)
HostVerificationReceiptV1(key-id,algorithm,payload-hash,signature-hash,status)

Signing returns signed. Verification returns verified for the deterministic

fixture signature and rejected for mismatches. REPL :effects reports

["sign"] or ["verify"], and transcript mode includes the requested

capabilities and effect list.

Hardware Emulator ABI Scripting

The bounded hardware scripting slice supports dry-run emulator receipts in

script and REPL mode:


(runtime-hardware-emulator-run target-id image timeout)

Scripts must declare (cap hardware) in source and callers must grant

--cap hardware; REPL sessions must start with --cap hardware or enable it

with :cap add hardware before evaluating hardware calls. The adapter invokes

production-host-runtime hardware-emulator-run through the runtime host ABI

boundary with ZERO_RUNTIME_ROOT fixed to the repository root. The production

scripting fixture uses the sim-cortex-m0 dry-run target and a local image

fixture only; no physical hardware is required.

Hardware calls are materialized as stable receipt values:


HostHardwareReceiptV1(target-id,mode,image-hash,trace-hash,exit-status,receipt-path,outcome)

The dry-run fixture returns mode emulator-dry-run, exit status 0, and

outcome pass. REPL :effects reports ["hardware.emulator"], and transcript

mode includes the requested capabilities and effect list.

Pure source code cannot call host effects in eval, script, REPL, or compiled

mode. REPL convenience commands may inspect the current capability set, but

they must not widen it unless the caller uses an explicit capability command

that is recorded in the transcript or audit report.

Output And Exit Status

Eval prints one stable value to stdout on success. Script text mode prints only

the stable value emitted by the script entrypoint. Script JSON mode prints a

stable machine-readable object on stdout only after successful checked

execution. REPL text mode prints the 0x0> prompt, the ...> continuation

prompt for incomplete parenthesized forms, successful values, and command output

in the interactive text format. REPL JSON transcript mode prints stable JSON

lines without prompts.

Diagnostics and tracebacks are written to stderr. Structured modes emit stable

JSON with sorted keys, stable field names, and stable diagnostic codes.

Determinism Evidence

The bounded scripting gate records deterministic evidence for repeated local

runs. The fixture covers stable JSON object ordering, TSV encode output,

deterministic record key order, sorted filesystem walk output, and stable JSON

diagnostics. tests/scripting.sh runs each determinism fixture twice, compares

the outputs byte-for-byte, and records SHA-256 hashes in

build/scripting/determinism-evidence.tsv.

Exit status rules:

script failure, or runtime evaluation failed with a stable diagnostic.

shape, or malformed REPL command.

Stable Diagnostics

The scripting profile reserves the following public diagnostic codes:

The bounded profile gate also reports stable JSON diagnostics for missing

documentation, contract inventory wiring, helper wiring, and diagnostic

documentation. See docs/diagnostics.html for the current list.

Security Negative Evidence

The scripting gate includes security negative evidence for denied file,

process, network, crypto, and hardware host effects. JSON eval mode must fail

closed with SCRIPTING_CAPABILITY when those effects are requested without an

explicit capability.

Script mode also carries host-boundary negative fixtures for filesystem path

escape and process command shape. A root-scoped filesystem escape fails with

SCRIPTING_HOST_ABI, and an implicit shell command string passed to

runtime-process-spawn fails with SCRIPTING_TYPE_EFFECT; process execution

must use an explicit argv list. Each security fixture records a stable JSON

diagnostic hash in build/scripting/security-negative-evidence.tsv.

Python Tooling Classification

The scripting gate generates

build/scripting/python-tooling-classification.tsv to classify Python files

under tools/ while scripting mode is used to reduce Python adapter surface.

Production-critical Python adapters are classified as host-only only when

they are present in tooling/source-owned-tooling.tsv, name a .0x0 source

owner, and declare host ABI operations. Temporary Python shims are reported as

temporary. Python files that are not production-critical adapters are reported

as out-of-production-critical-scope.

The checked progress inventory is tooling/python-dehosting-progress.tsv.

It records migrated Python surfaces as migrated, current production-critical

Python adapters as host-only, and other Python files under tools/ as

remaining-python. Each row also carries optional migration ledger fields for

the replacement owner, native backend dependency, parity gate, and migration

note; migrated rows must name a replacement owner. The frozen migration scope is

tooling/python-dehosting-migration-snapshot.tsv, which records the 172

original remaining-python rows.

tools/adr-rfc-check.py is a migrated Phase 1 row. Its replacement owner is

tools/adr-rfc-check.0x0, and the public make adr-rfc-check command runs

that script through explicit file and process capabilities.

tools/docs-coverage-check.py is also migrated in Phase 1. Its replacement

owner is tools/docs-coverage-check.0x0, and make docs-coverage-check runs

the source-owned checker through tools/docs-coverage-check.sh.

tools/docs-safe-check.py is migrated in Phase 1 as well. Its replacement

owner is tools/docs-safe-check.0x0, and make docs-safe-check runs the

source-owned checker through tools/docs-safe-check.sh.

tools/documentation-impact-check.py is migrated in Phase 1 too. Its

replacement owner is tools/documentation-impact-check.0x0, and

make documentation-impact-check runs the source-owned checker through

tools/documentation-impact-check.sh.

tools/doccheck.py is retired in Phase 1. Its replacement owner is

tools/doccheck.0x0, and the stable make docs-check gate continues to run

through tools/doccheck.sh.

The focused gate is:


make python-dehosting-progress-check

That gate regenerates the expected inventory from

tooling/source-owned-tooling.tsv, tooling/host-shim-classification.tsv, and

the current tools/*.py scan. Drift between the checked TSV and scanner output

fails with SCRIPTING_PYTHON_TOOLING. It also validates the frozen snapshot,

the backend-gap checklist template at

tooling/python-dehosting-native-backend-gap-template.html, and the parity

harness at tools/python-dehosting-parity.sh.

Migration parity evidence uses tools/python-dehosting-parity.sh. The harness

runs an old command file and a new command file with isolated output roots,

then compares exit status, stdout, stderr diagnostic code, and declared output

files. Expected drift must be documented with Needs verification.

Unknown production-critical Python behavior fails with

SCRIPTING_PYTHON_TOOLING. A Python host shim listed as production-critical

without source-owned manifest ownership is rejected, and a host-only Python

adapter without declared host ABI operations is rejected.

Production Boundary

The scripting profile is production-ready only when every scripting host effect

routes through runtime/host-abi.tsv, every granted capability is explicit, and

tooling policy lives in .0x0 source rather than in shell or Python adapters.

The current production slice specifies the profile and installs the bounded

gate:


make scripting-check

source/tooling-performance-budgets.tsv records bounded local rows for the

overall scripting gate plus eval, script, and REPL startup surfaces. The

scripting gate checks those rows for implemented status, bounded-source

classification, positive local max_seconds, no_heavy_gates=yes, and narrow

test evidence. The gate also checks the Python tooling classification report.

The budget, classification, and Python de-hosting progress checks do not run

self-hosting, release verification, remote network jobs, or hardware jobs.

Determinism and compatibility are covered by the scripting gate. Script and

REPL compatibility policy, breaking-change requirements, and downgrade

expectations are governed by docs/release-compat.html. Release evidence is

recorded in release/source-tooling-contract-evidence.tsv, and final release

discipline references the bounded scripting gate through

release/final-discipline.tsv.

Scripting Production Closure

The bounded production closure gate is:


make scripting-production-closure-check

The gate is evidence-only. It reads the scripting docs, diagnostics, host ABI

table, eval/script/REPL fixtures, release helper list, release evidence,

bounded budgets, final discipline inventory, and Python de-hosting progress

inventory, plus the production-critical source-owned tooling manifest. It

proves that eval, script execution, REPL behavior, capability denials, host ABI

routing, standard library helpers, determinism evidence, stable diagnostics,

release evidence, production tooling routes, and the frozen

scripting-profile-v1 profile version are all present without invoking

self-hosting, remote network publication, physical hardware, or release-only

jobs.

Production-critical tools that have migrated to scripting must invoke

tools/zero-scripting.sh script for their .0x0 source owner or for a bounded

runtime .0x0 entrypoint that imports that owner. Host-only adapters must

declare known runtime/host-abi.tsv operations and must not define production

policy functions for formatting, resolving, signing, or policy-specific

validation.

Failures emit stable JSON diagnostics with

SCRIPTING_PRODUCTION_CLOSURE.

Final Production-Ready Evidence

The final scripting release evidence is

release/scripting-production-ready.tsv. That TSV is profile-scoped to

scripting-profile-v1 and records production-ready rows for:

The closure checker rejects missing rows, non-production-ready status, wrong

profile versions, missing evidence paths, and missing Make targets. It also

requires a milestone closure row stating that no production-critical scripting

milestone remains open.

No production-critical scripting milestone remains open.