Exact

Exact Union RegExp

Repository files (latest commit first)

Filename	Latest commit message	Latest commit date
Transaction Science a1bbce7fad WAI Quantum: the sign-off loop on the job service, in Python and npm; a grade held to the service's bounds case by case; a whole task set graded ... The sign-off loop (check, grade, attest; 4b17804c2) ran on the command line and its MCP server. It now runs wherever the engine does, with the same answers. - engine::front holds the check, the attestation and the loop's MCP tools (check_quantum_program, grade_quantum_program, attest_quantum_job, in one wording with the sealer named), which the command line, both MCP servers, the Python package and the npm package call; the command line keeps its flags and its printing. The output schemas of check and attest move from the command line's local-tools.v1.json into the engine's tools.v1.json ($defs/check, $defs/attest), which both servers name. - The job service serves the three tools on its MCP server and as POST /v1/check, /v1/grade and /v1/attest (GET /v1, the OpenAPI document and the README list them), a grade and a sign-off sealed with its own key, their energy unmetered with the reason. Each is counted as a check, held to its bounds and made in a reading child, each case within half the child's memory. A check of a task, a grade, and a sealed grade POST /v1/verify works out again are now held case by case (analysis::grade_bounds: each case's intent that compares the program with a reference held to the equivalence check's bound with the program written out at that case's inputs, and the task's job read as a job's is), where before a grade was remade within the reading child's budget whole; a case past them is refused at that case (J031, "case N: ...", naming wai-quantum grade). An attestation holds what verifying the job works out again and the intent its sign-off checks to the same bounds (naming wai-quantum attest). - Python: wq.check, wq.grade, wq.attest (and _engine.check/grade/attest); npm: QuantumEngine.check, .grade, .attest; each with a test (test_engine.py, smoke.mjs, a wasm32 test in wai-web) and a README example. - The instructions both MCP servers give at initialize describe the loop (guide::LOOP), and the committed lists (docs/local-mcp.json, docs/service-mcp.json), llms.txt, llms-full.txt and the skill's tools.md are written again from the live lists. - A whole task set graded: wai-quantum grade --set FILE --programs ANSWERS (the model harness's set; the programs a JSON object of programs or of a model's answers as eval run --scripted reads them, or a directory of NAME.qasm files), or --course --programs DIR; engine::grade::batch, wai.quantum.grades/1 (schemas/grades.v1.json), quantum-providers §8.10 "A task set graded": one sealed grade a task, missing and refused tasks said so, the set's digest and a summary. The batch is not sealed; wai-quantum verify works it out again (grade::check_batch): each grade checked and made again, each entry's name and grade held to what its grade seals, a refused entry refused again, the digest and the summary made again from the sealed results. The same set, programs and key give the same bytes. quantum-conformance/grades/ holds a batch and six changed ones with what a reader must say (written by hand from §8.10), natively and under wasm32-wasip2 (tests/grades_conformance.rs), including one that shows what a batch does not: a grade dropped as missing with the summary made to agree is valid; that a task had no program is the grader's statement. - wai-web's pinned digest of a level-2 compile (COMPILE_DIGEST) follows the compile of 7c00ef138, which writes each region of CNOT and phase gates again at level 2 and so changed those sealed bytes; wai-web wasm32 runs on pull requests and nightly only, so nothing had run it since. Native and wasm32 give the new digest alike. The npm smoke runs the loop on an engine of 1 GiB: one of 256 MiB says an intent's exact check is unchecked, and why (asserted too). - Which trust list an attester used stays outside the seal: sealing it would add a member to the sign-off's closed request, which every released verifier refuses (J001), and it would show only which keys the attester trusted, which is each reader's to decide; the changes entry and the skill say so. Tests: engine::front, engine::grade (the batch), the guide's instructions, service analysis (bounds case by case), mcp (an agent runs the loop over the service's server; every tool's answer held to its output schema), verify.rs (the loop over HTTP in a running service, its grade and sign-off verified), the command line's front_door.rs (a whole set graded through the binary, verified, a changed summary found) and check_schemas.py (the batch and an attestation held to their schemas). wai-quantum-verdict.yml, -service.yml, -cli.yml and wai-web-wasm.yml require the new tests by name. schema::FILES gains grades.v1.json (acknowledged in the changes entry). Co-Authored-By: Claude Opus 5.5 <[email protected]>		2026-11-11 17:14:39 -05:00
..
install.md	wai-quantum: every MCP tool says what it answers, both servers and the command line report their versions, and the provider protocol has its schema	2026-10-27 23:44:27 -04:00
loop.md	WAI Quantum: the sign-off loop on the job service, in Python and npm; a grade held to the service's bounds case by case; a whole task set graded	2026-11-11 17:14:39 -05:00
receipts.md	wai-quantum: documentation that runs in CI, its drift fixed, an index of every page, and a changelog entry	2026-10-28 08:43:06 -04:00
tools.md	WAI Quantum: the sign-off loop on the job service, in Python and npm; a grade held to the service's bounds case by case; a whole task set graded	2026-11-11 17:14:39 -05:00
workflow.md	wai-quantum-cli: run --intent, repair, test on the engine's verdict, and the MCP verdict in every answer	2026-10-27 23:44:27 -04:00