Define MVP conformance and release criteria

Archived MVP specification. For ASPL 0.5.0, see the current reference and native HTTP guide.

Type: grilling Status: resolved Blocked by: 05, 06, 08, 09, 10, 12, 13, 14, 15, 16, 17, 19 Parent: Find the ASPL MVP specification

Question

Which normative examples, negative tests, cross-language equivalence checks, clean-system executable tests, shared-library calls, playground checks, website and installation checks, and documented limitations must pass before the resolved map counts as an implementation-ready MVP specification and an implementation may call itself the ASPL MVP?

Answer

ASPL separates specification completion, implementation conformance, and an official release. Resolving this map completes the specification gate only. It does not claim that an implementation exists or that release evidence has passed.

Claims and profiles

The three gates are:

1. MVP specification complete. The map has no open ticket or fog. Its decisions are consistent, and every normative rule maps to a specified acceptance obligation.
2. ASPL MVP conforming implementation. An implementation passes the externally observable requirements for every profile it claims.
3. Official ASPL 0.1.1 release. The project implementation passes both conformance profiles plus the project-owned internal, distribution, website, accessibility, performance, and release-production gates in this decision.

Every conforming implementation starts with the ASPL MVP common profile. It contains the source notation, semantic checking, diagnostics, canonical bytecode, VM behavior, and output builtin fixed by this map.

An ASPL MVP native implementation passes the common profile plus the native CLI, C interoperability, ELF packaging, Linux host, and native-limit requirements. An ASPL MVP browser implementation passes the common profile plus browser capability policy, worker execution, browser limits, output handling, and playground behavior. The unqualified ASPL MVP conforming implementation claim requires both profiles.

The implementation language does not affect these conformance claims. The official ASPL release uses the specified C11 implementation. Only the project may use the phrase Official ASPL 0.1.1 release.

A public claim names the implementation and version, ASPL MVP 0.1.1, every claimed profile, the conformance-suite revision, the manifest hash, and its evidence-bundle link. A third party may make a self-attested profile claim but may not say ASPL certified. A partial profile may not use an unqualified conformance claim. The compatibility wording forbidden by Define dynamic C interoperability, including full C compatibility, remains forbidden.

Normative authority

Every declarative behavior, numeric value, table entry, grammar rule, and explicit exclusion in the ## Answer of a resolved map ticket is normative unless that text identifies it as rationale, background, an example, or non-normative evidence. A ticket's conformance list adds coverage duties but does not limit the rules that precede it. A prototype contributes only the behavior or visual choice that its answer explicitly adopts.

The resolved tickets are the authority. Tests, existing implementation behavior, prototypes, and a reference executable are evidence rather than alternative specifications. No chronological rule resolves conflicts between tickets. A contradiction or ambiguity blocks specification completion until the ticket that owns the rule is corrected.

The map is specification-complete only after an audit confirms all of the following:

• every child ticket is resolved and the map contains no fog;
• all local links, parent links, blocker references, and dependency edges are valid;
• vocabulary, aliases, stable reasons, type IDs, adapter IDs, opcodes, limits, and version numbers agree across their uses;
• no unresolved placeholder, obsolete reason, or dangling ownership reference remains;
• every in-scope question has an owning decision; and
• every normative rule has an objective automated check or a precise witnessed procedure.

A future-release possibility is allowed only when the MVP behavior and current exclusion are explicit. Executed test results are not required to close this planning map. They are required for implementation and release claims.

Conformance manifest

The repository must implement the acceptance obligations in conformance/manifest.json and validate it against a checked JSON Schema. Each atomic requirement has a permanent ID in the form ASPL-<AREA>-NNNN. Retired IDs are never reused.

Each manifest requirement records:

• its owning ticket and heading;
• its complete normative statement;
• the common, native, browser, or official-release profiles to which it applies;
• whether its evidence is automated or witnessed;
• one or more case IDs;
• the required environment and capability policy;
• the exact oracle fields;
• every hashed fixture, generator, inspector, catalog, generated table, binary, asset, or configuration it consumes; and
• a limitation tag when it supplies the normative limitations page.

Requirements are split until each can pass or fail independently. Requirements and cases have a many-to-many relationship, but every requirement needs direct evidence. A happy-path case does not cover a rejection, boundary, cleanup rule, or exclusion merely because it exercises the same component.

The coverage audit rejects an orphan requirement, orphan case, duplicate or reused ID, missing profile, broken source heading, absent oracle, missing hashed input, or uncovered mandatory rule. Results live outside the manifest so a test run cannot rewrite its requirements.

The manifest has language_version: 0.1.1, an independent positive suite_revision, and a content hash. Revision 1 freezes with the official release. A correction limited to the harness, oracle, or test metadata creates a new immutable suite revision and a public erratum. A changed language, CLI, bytecode, or host rule requires a new ASPL release under Define distribution and installation. Every evidence bundle states all three identities. Old evidence remains available under the suite revision that produced it.

Conformance driver and independent inspection

An implementation supplies a contributor-only conformance driver for facts absent from the public product interfaces. The suite-versioned driver supports:

• compilation from exact source bytes under a selected host policy;
• retrieval of structured diagnostics, checked identities, source maps, and canonical bytecode;
• validation of externally supplied bytecode;
• execution with selected limits, cancellation probes, injected output callbacks, and host failures;
• native packaging into an owned ELF buffer; and
• browser worker events and state from a test build.

The driver is tied to the suite revision. It is not a public embedding API, stable C ABI, bytecode CLI, or product compatibility promise. Separate black-box tests still exercise the public CLI, generated executables, browser page, and published website.

Test-only inspectors for canonical bytecode, generated ELF structure, release archives, and Arabic or English website parity must not call the production serializer, loader, packager, or routing code. Representative artifacts also have fixed byte-level goldens. Production validation remains mandatory, but it cannot certify itself alone.

Passing rules and oracles

A gate passes with zero mandatory failures, unexpected skips, quarantined cases, or flaky individual retries. A bad environment invalidates the complete affected run. After correction, that entire gate runs again. A waived requirement does not pass. Only measurements already marked informational, such as native check timing and cold-cache performance, lack a pass ceiling.

The suite uses the lowest stable result as its oracle:

• Source failures compare reason, severity, typed arguments, primary and secondary byte spans, edits, ordering, duplicate removal, and truncation flags.
• Diagnostic rendering compares exact Arabic and English output for every catalog entry and selected compound cases, including safe direction and escaping.
• Successful compilation compares checked identities, canonical bytecode bytes, and contributor-only structural dumps.
• Execution compares the outcome class, stable reason and arguments, mapped or unmapped location, exact stdout and stderr bytes, process status, or terminating signal.
• Browser tests compare worker messages, source revisions, state transitions, DOM semantics, accessible names, live announcements, retained output bytes, and safe presentation. Screenshots support human review but cannot decide conformance alone.
• ELF tests parse the artifact contract and compare exact candidate hashes where determinism applies.
• Performance tests retain raw samples and apply only the formulas in Set the performance budget and benchmark protocol.

Manifest requirement coverage must be 100 percent, and every named failure operation must be exercised. The official implementation records line and branch coverage for its C, worker, and website code. It rejects a reachable production file with no exercised lines. Aggregate percentages remain informational. Every uncovered branch in the compiler, validator, VM, foreign adapter, packager, and output path is either justified as unreachable or receives a test.

Deterministic generators may create large boundary and malformed-input sets. Before a release run, the suite expands and hashes every concrete generated case and records the generator version, parameters, and seed. Each source reason, bytecode validator rule, native-envelope rule, host-limit boundary, and one-past-boundary condition has a named negative case. Property and fuzz tests add evidence but never replace a named case.

Bilingual equivalence

Every source-level conformance fixture has an Arabic canonical form. A generator creates its English counterpart by replacing only resolved keyword, adapter, and builtin aliases through the lossless lexical view. It preserves identifiers, strings, comments, C symbols, library names, paths, whitespace, and declaration order.

Successful Arabic and English counterparts must produce the same checked target identities, canonical bytecode bytes, output bytes, and final outcome. Rejected counterparts compare reason, severity, typed arguments, edit meaning, ordering, and the logical token or construct selected by each span. Each counterpart separately checks its exact UTF-8 byte offsets and rendered locations.

A hand-written mixed-vocabulary corpus covers every alias pair, both unsafe-marker spellings, both adapter aliases, both builtin aliases, per-occurrence mixing, and both atom directions. A generated mixed file cannot substitute for this corpus because it would only test the generator against itself.

Normative fixture inventory

The canonical public hello.aspl fixture is shared by the website entry, first documentation program, installation check, browser smoke test, direct native run, and generated-executable smoke test. It sums the integers from 1 through 10. When the result is 55, it writes the exact bytes 55\n through اطبع and returns status 0. Its failure path returns a nonzero status without success output. It has generated English and hand-written mixed counterparts.

The focused common-profile success fixtures from Define the MVP semantic core remain distinct:

• sum_loop returns 55 directly;
• recursive_factorial returns 120;
• mutual_recursion proves source-order-independent resolution;
• short_circuit leaves its zero-divisor branches unexecuted;
• string_identity preserves an Arabic string containing NUL;
• float_round_trip converts 42 from i64 to f64 and back;
• unit_call uses a unit result only as a statement;
• builtin_output exercises exact output bytes without an added newline;
• null_round_trip relays and compares null; and
• maximum_status completes with status 255.

Independent fixtures cover every source rejection in the semantic, notation, diagnostics, foreign, and builtin decisions. Independent runtime fixtures cover all five traps, every outcome class, mapped and unmapped traces, configured limits, cancellation, allocator failure, host callback failure, and VM-invariant injection. Raw-bytecode fixtures cover every envelope, table, instruction, type, control-flow, definite-assignment, import, version, CRC, padding, count, offset, and host-policy rule in Choose the register bytecode contract.

Mechanically exercisable exclusions use the nearest public boundary. The suite rejects multiple source operands, stdin source, modules, globals, arrays, excluded operators, unsupported C signatures, standalone-bytecode CLI access, generated-program operands, browser foreign imports, and forbidden browser filesystem or network bridges through their existing diagnostic, usage, policy, or load outcome. It does not invent a reason merely to name an absent feature.

Nonclaims such as production readiness, full C replacement, security-support duration, and stable public bytecode are documentation obligations. A rule that is neither objectively testable nor reviewable through a precise witnessed procedure is not ready for the manifest and blocks specification completion.

Native and C interoperability evidence

The native profile runs every accepted and rejected public CLI form, every workflow phase boundary, all statuses and signal cases, the fixed native limits at their exact boundaries, every atomic-publication fault, and every generated-program argument rule from Define the CLI and build behavior.

It proves byte-identical generated ELF contents across destination paths, current directories, umasks, locales, environments, metadata, repeated builds, and source files that differ only in reserved vocabulary. It validates the release template, native envelope, embedded canonical bytecode, final segment sizes, security-related ELF properties, fixed dependencies, and load-before-main ordering from Choose native executable packaging.

The foreign suite:

• calls real puts from libc.so.6 through adapter 1;
• calls real sqrt from libm.so.6 through adapter 2;
• uses a test-only shared library with the same exact signatures to prove negative C int conversion, noncanonical NaN normalization, floating-point environment restoration, and another compatible-library load;
• rejects every declaration and malformed-import case from Define dynamic C interoperability;
• proves check and build never require or open declared libraries;
• proves missing libraries and symbols stop before every main side effect; and
• proves a string containing NUL traps before the C function observes a call.

The test-only shared library is built in the pinned glibc 2.34 release-test environment and recorded by hash. It is copied into clean test machines but never enters the release archive. Only its cases use an explicit test directory through LD_LIBRARY_PATH. The real puts and sqrt cases use each system's normal libc.so.6 and libm.so.6.

The output suite covers empty strings, Arabic text, embedded NUL, ordered calls, no implicit newline, interrupted and short native writes, failure after a partial write, default SIGPIPE, ignored or blocked SIGPIPE, exact browser limits, safe control rendering, live output, partial output retention, stale-source labeling, and clearing on the next run.

Clean Linux matrix

The official release uses fresh pinned x86-64 virtual-machine images for RHEL 9, Ubuntu 22.04, and Debian 12 on real x86-64 hardware. RHEL 9 exercises the glibc 2.34 floor. The other systems catch behavior under newer supported loaders.

The test procedure applies documented system updates, installs only ordinary utilities required to verify and extract the archive, and confirms that no C compiler, assembler, linker, ASPL runtime, or previous aspl installation exists. It copies in the candidate archive, checksum, conformance inputs, and hashed test library, then disconnects release-test networking.

Each machine follows the published user installation commands exactly and checks:

• host detection, SHA-256 verification, extraction, --version, PATH, and silent successful check;
• Arabic-default and explicitly English diagnostics;
• check, run, and build with the canonical and negative fixtures;
• exact builtin output and statuses from direct and generated execution;
• real puts, real sqrt, and the test-only library;
• missing-library and missing-symbol failure before main;
• acceptance by check and build of a declaration naming a nonexistent library;
• every generated-program option rule; and
• continued execution of a generated program after the installed aspl executable is removed.

The machines remain free of compiler, assembler, and linker executables throughout the procedure.

Browser and website evidence

At candidate freeze, the official release pins the current stable Firefox and Chromium releases by exact version. Both run the complete browser, website, and performance suites on the reference machine with clean profiles. Each tests desktop, a 390 by 844 CSS-pixel viewport, and reflow at 320 CSS pixels.

The browser profile covers every state, source revision, debounce, mandatory recheck, worker replacement, Stop, stale message, immutable snapshot, output, outcome, policy rejection, source-map, digit-conversion, limit, clock, race, layout, keyboard, and accessibility obligation from Design the browser playground behavior. It also proves that a foreign declaration reaches host-neutral checking and then receives policy-rejection/foreign-imports-not-supported, and that no browser path packages ELF or loads a shared library.

All website code, WebAssembly, fonts, and documentation come from the project's own origin. Editing, checking, running, stopping, diagnostics, and program output may cause no network request. Only same-origin static asset requests needed to load or navigate the website are permitted. The MVP ships no analytics, advertising, remote font, source upload, server runner, or update check.

Every published source example appears in the manifest with exact source bytes, locale counterparts where required, host applicability, expected check result, expected output bytes, expected status or failure, and every embedding page. The documentation build consumes the registered source rather than a hidden copy and compiles or runs it where supported. A placeholder version, command, checksum, output, counterpart, anchor, or host label blocks release.

The site must pass every parity, route, token-aware display, capability-label, C-warning, installation, and WCAG 2.2 AA publishing obligation from Design the bilingual website and documentation. Automated checks cover keyboard paths, focus, contrast, reflow, accessibility-tree semantics, and live announcements.

Two witnessed sessions remain mandatory. One Arabic-primary reviewer tests keyboard use and mixed-direction content in both pinned browsers. One screen-reader reviewer uses Firefox with Orca on Linux across both locales. Each record includes the candidate identity, browser, operating system, assistive technology where applicable, scenarios, results, reviewer, and date. Any failed scenario blocks release.

Normative limitations page

The website publishes one normative Arabic and English MVP limits reference page generated from manifest entries tagged limitation. Other pages link to its entries rather than paraphrasing them.

It covers every map exclusion and every narrower guarantee, including:

• one source file, no modules or package system, and no program arguments;
• the five storable types, unit, literal-only immutable strings, and excluded language forms;
• exactly two foreign adapters, the call-scoped C-string loan, ordinary loader lookup, and foreign behavior outside ASPL's guarantees;
• the x86-64 Linux and glibc 2.34 floor, unsupported systems, and native library dependencies;
• private version-matched bytecode and native packaging rather than a stable public VM ABI;
• the browser's lack of ELF, shared libraries, filesystem, network, source upload, and server execution;
• the absence of sandboxing for native execution;
• SHA-256 integrity without publisher authentication or release signing;
• the narrow build-performance and tested-browser claims; and
• the absence of production-readiness, complete C compatibility, or practical C-replacement claims.

Every mechanically testable limitation has an automated case. The remaining entries receive bilingual parity and wording review.

Official implementation gates

The official native implementation builds with pinned GCC and Clang releases in strict C11 mode. Both builds compile without warnings and pass the common and native suites. The complete native suite runs again under AddressSanitizer and UndefinedBehaviorSanitizer with leak detection, including injected failures and cleanup. The production build uses the pinned glibc 2.34 environment and disables floating-point optimizations that could change ASPL semantics. Evidence records every compiler, flag, sysroot, build tool, and generated-table hash.

The conformance driver enumerates every reachable allocation site and every publication, diagnostic-output, and builtin-output operation. For each injected failure it checks the required class, reason, arguments, absence or preservation of side effects, and complete cleanup.

Four native fuzz targets cover source decoding and parsing, complete compilation, raw bytecode loading, and native-envelope loading. Each runs under the sanitizers for at least 60 CPU-seconds against the exact candidate with fixed memory and per-input time limits. A crash, sanitizer finding, unbounded allocation, or unclassified hang blocks release. The corpus starts with named conformance cases. Every discovered input becomes a permanent regression fixture.

The performance and artifact-size gates in Set the performance budget and benchmark protocol apply without waiver. This includes the physical reference host, canonical warning-free fixture, warm p95 below 100 milliseconds, hosted-CI relative checks, packaging equations, determinism checks, browser ceilings in both pinned browsers, raw samples, and environment-identity rules.

Reproducible production and dependency audit

The release is built twice in fresh directories from the same candidate and pinned toolchain environment. Both builds must produce byte-identical copies of aspl, the VM template, generated tables, WebAssembly, JavaScript, CSS, documentation output, release archive, and checksum file.

Release production normalizes archive ordering, ownership, modes, timestamps, and compression inputs. It uses the candidate commit time for archive timestamps. Published bytes contain no absolute build path, build-directory name, host name, random value, or current wall-clock time.

An independent component and license audit verifies:

• the native binary and VM template have only their fixed allowed ELF dependencies;
• no required symbol version exceeds GLIBC_2.34;
• generated code uses no instruction-set extension beyond baseline x86-64;
• the archive contains only the entries, modes, and notices allowed by Define distribution and installation;
• every incorporated third-party notice is present; and
• website assets match the same-origin and no-runtime-network rules above.

Candidate identity and evidence invalidation

One candidate identity contains the git commit, release version, compiler binary hash, VM-template hash, website asset hashes, fixture hashes, manifest hash, suite revision, generated-table hashes, and build-environment identity. All mandatory evidence belongs to that candidate.

Every evidence record declares its hashed inputs. Tooling marks it stale when an input changes:

• compiler or VM changes invalidate common, native, browser, clean-system, and performance evidence;
• template or packaging changes invalidate native, clean-system, distribution, determinism, and performance evidence;
• website or documentation changes invalidate browser integration, parity, accessibility, and witnessed review evidence; and
• fixture, manifest, generated Unicode table, diagnostic catalog, generator, or inspector changes invalidate every entry that names it.

The final archive and deployed website may contain only bytes and hashes from the same accepted candidate.

Evidence bundle

Every public conformance claim links an immutable ASPL conformance evidence bundle. It contains machine-readable JSON and an equivalent Arabic and English human summary with:

• specification, language-version, suite-revision, and manifest identities;
• implementation identity and claimed profiles;
• complete case results and a zero skipped-case count;
• independent-inspector and golden results;
• build, toolchain, component, license, and environment records;
• clean-system logs;
• sanitizer and fuzz summaries;
• raw native and browser benchmark samples;
• final artifact and deployed-asset hashes;
• browser, documentation, parity, and accessibility results; and
• witnessed-session records.

The ASPL project certifies only its own official release. Official evidence remains downloadable beside its archived version for as long as that release remains downloadable.

Release order and defect policy

The official release follows this order:

1. Close the specification and pass its consistency and manifest-coverage audit.
2. Freeze one candidate commit and build environment.
3. Produce two reproducible builds and select their byte-identical outputs.
4. Pass common, native, browser, internal, sanitizer, independent-inspector, and fuzz gates.
5. Pass clean-system, pinned-browser, performance, documentation, and witnessed-accessibility gates.
6. Create the final archive, checksum, evidence bundle, and immutable website assets from the accepted bytes.
7. Upload versioned assets to their final immutable URLs without changing the recommended-release pointer.
8. Test those public bytes from all three clean machines and run the bilingual deployed-site smoke suite.
9. Put the immutable v0.1.1 tag on the same candidate commit and promote the recommended-release pointer.

A failure returns to the earliest invalidated step. A later success cannot compensate for it.

An official release may have no known defect that violates an MVP rule, corrupts evidence, or weakens a release gate. An issue wholly outside the MVP may ship only when it does not undermine an in-scope claim and the release notes link it to the applicable MVP limits entry. An in-scope failure cannot be relabeled as a limitation.

Closure audit result

The map audit found all child links and blocker references valid, all blocker edges acyclic, all local Markdown links resolvable, and all earlier tickets resolved. The canonical aliases, adapter IDs, opcode table, diagnostic replacements, native and browser limits, packaging versions, glibc floor, and release version agree across their owning decisions.

The audit removed two stale planning statements: the map no longer suggests that an unresolved ticket may approve a vendored compiler or runtime library, and the pipeline contract now points to the resolved native and browser host limits. No in-scope fog or further decision ticket remains.