@fraczak/k 6.0.1 → 6.0.2

package/AGENTS.md

@@ -0,0 +1,35 @@
+# Repository Guidelines
+
+## Project Structure & Module Organization
+- Root `.mjs` files hold the core runtime and library entry points (e.g., `index.mjs`, `run.mjs`, `codes.mjs`, `typing.mjs`).
+- `k_compiler/` contains the Python prototype compiler and supporting modules.
+- `type_registry/` houses registry experiments and grammar artifacts.
+- `Examples/` and `DOCS/` provide sample programs and design notes.
+- Tests live in top-level `test*.mjs`, `Code-derivation-tests/`, and `tests.sh`.
+
+## Build, Test, and Development Commands
+- `npm install` installs dev dependencies and runs `prepare` to generate parsers.
+- `npm run prepare` regenerates `parser.mjs` and `valueParser.mjs` from `.jison` grammars.
+- `npm test` runs the full suite (`test.mjs`, `Code-derivation-tests/*.mjs`, `test-fingerprint.mjs`, `tests.sh`).
+- `node repl2.mjs` (or `k-repl`) starts the interactive REPL.
+- `./k.mjs <file.k>` executes a k script on binary pattern+value stream input from stdin or a file; use `k-parse` and `k-print` at the boundaries.
+
+## Coding Style & Naming Conventions
+- JavaScript uses ES modules (`.mjs`) with 2-space indentation and semicolons.
+- Prefer `const`/`let`, small focused modules, and descriptive lower-case filenames.
+- Python modules in `k_compiler/` follow 4-space indentation and standard snake_case.
+- Grammar sources are `parser.jison` and `valueParser.jison`; generated files should not be hand-edited.
+
+## Testing Guidelines
+- Add runtime tests alongside `test.mjs` or new `test-*.mjs` files.
+- Add type-derivation coverage in `Code-derivation-tests/` (one case per file is typical).
+- Verify locally with `npm test` before opening a PR.
+
+## Commit & Pull Request Guidelines
+- Commits use short, imperative, sentence-case summaries (e.g., "Improve type derivation").
+- PRs should include: a clear description, the commands run (`npm test` or specific subsets), and any relevant examples or docs updates.
+- If changes touch parsing or grammars, note whether `npm run prepare` was run.
+
+## Configuration Notes
+- Requires Node.js 18+.
+- The REPL and CLI binaries are `k-repl` and `k` (see `package.json` for mappings).

package/CHANGELOG.md

@@ -0,0 +1,48 @@
+# Changelog
+
+All notable changes to this project will be documented here.
+
+The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
+This project uses [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+---
+
+## [6.0.0] — 2026-05-12 — First public release
+
+### Language & Runtime
+
+- First-class partial functions over algebraic data types (products and tagged unions).
+- Three combinators: composition `(f g)`, merge `<f, g>`, product `{f l1, g l2}`.
+- Pattern-based type derivation with filter expressions (`?<...>`, `?{...}`).
+- Canonical (hash-addressed) code names — two structurally equivalent codes always produce the same hash.
+- Content-addressed object files (`.ko` / `.klib`) for compiled modules.
+
+### Type System
+
+- Finite tree automaton type representation (`codes.mjs`).
+- Graph-based constraint propagation via `TypePatternGraph`.
+- SCC-aware convergence with configurable strategy (`auto` / `single_pass` / `fixed_point`).
+- `compileStats` API for inspecting convergence behaviour per SCC.
+
+### Toolchain
+
+- `k` — CLI executor: reads binary pattern+value stream, applies a k script, writes result.
+- `k-repl` / `k-repl2` — interactive interpreter with tab-completion.
+- `k-pattern` — extract the canonical root pattern from a k script.
+- `k-compile-object` / `k-decompile-object` — object file compilation and decompilation.
+
+### Codec Pipeline
+
+- Binary format: serialised pattern graph followed by value encoded under that pattern.
+- JSON codec, UTF-8/UTF-16 string codec, IEEE 754 codec.
+- Polymorphic codec streams: pattern carried in-memory through projections and constructors.
+
+### Node.js Library API
+
+- `k.compile(source, options?)` — returns a runnable JS function.
+- `k.annotate(source, options?)` — type-checks and returns annotated AST with `compileStats`.
+- `k.run(expression, value)` — evaluate a single expression against a value.
+
+---
+
+[6.0.0]: https://github.com/fraczak/k/releases/tag/v6.0.0

package/CLAUDE.md

@@ -0,0 +1,64 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Project Overview
+
+k-language is an experimental programming language for building and manipulating algebraic data types ("codes")—tree-shaped values built from product and tagged union. The native k-like notation is canonical; a JSON-like notation is available as a convenience for newcomers.
+
+## Essential Commands
+
+**Build/Parser Generation:**
+```bash
+npm run prepare  # Generate parsers from Jison grammar files
+```
+
+**Testing:**
+```bash
+npm test  # Run comprehensive test suite (unit tests, derivation tests, shell tests)
+```
+
+**Running k programs:**
+```bash
+./k.mjs <file.k>      # Execute k script
+./repl2.mjs           # Start interactive REPL (or: k-repl)
+```
+
+## Architecture
+
+### Core Language Concepts
+- **Partial Functions**: Functions may be undefined for some inputs (e.g., `.field` projection)
+- **Function Composition**: `(f g h)` - sequential application
+- **Union/Merge**: `<f, g>` - try f first, fallback to g
+- **Product**: `{f label1, g label2}` - parallel application building records
+- **Types (Codes)**: Finite tree automata defining value sets, no built-in types
+- **Notation**: Prefer native k-like for products `{A l, ...}` and unions `<A t, ...>`; JSON-like `{l: A, ...}` and `<t: A, ...>` is supported for convenience
+- **Variant value literals**: Use single-field product notation. Unit: `{{} tag}`; with payload `v`: `{ v tag }`. Angle brackets are for types/merge, not value literals.
+
+### Key Implementation Files
+- `parser.mjs` / `parser.jison` - Language parser (generated from Jison grammar)
+- `run.mjs` - Runtime execution engine for partial functions
+- `codes.mjs` - Type/code management and canonicalization
+- `TypePatternGraph.mjs` - Core pattern graph data structure for type derivation
+- `typing.mjs` - Type compression and advanced type system operations
+- `Value.mjs` - Value representation and operations
+- `index.mjs` - Main library entry point
+
+### Multi-Stage Processing Pipeline
+1. **Parsing**: Text → AST via Jison-generated parser
+2. **Type Derivation**: Pattern-based type inference across expressions
+3. **Canonicalization**: Types/functions get hash-based canonical names
+4. **Execution**: Runtime evaluation with partial function semantics
+
+### Type System
+- **Product types**: `{type1 label1, type2 label2}` with projections `.label1`
+- **Union types**: `<type1 label1, type2 label2>` with variant selection
+- **Pattern matching**: Sophisticated constraint derivation system
+- **Canonical names**: Hash-based universal registry for content-addressed modules
+
+## Development Notes
+
+- No external runtime dependencies (only jiwson for parser generation)
+- Uses ES6 modules (.mjs files) throughout
+- Extensive test suite in `Code-derivation-tests/` for type system validation
+- REPL supports commands like `--C name` (show canonical type) and `--R name` (show type derivation)

package/DOCS/BIG_PICTURE.md

@@ -255,14 +255,10 @@ cdr = list? /cons .cdr;
 For example, the filter annotation for `car` is:
 
 ```k-repl
---R car
-{
-  name: 'yRXGSJrIWCuKV',
-  type: '?<{X1 car, X0 cdr} cons, $KL nil>=X0  -->  ?X1',
-  def: '?<{X1 car, X0 cdr} cons, $KL nil>=X0 .cons .car ?X1'
-}
---C KL
-$ KL = {}; -- $C0={};
+> :t car
+car : ?<{X1 car, X0 cdr} cons, $KL nil>=X0  -->  ?X1  (@...)
+> :C KL
+$ KL = {};  -- @...
 ```
 
 ## Universal Schema Registry

package/DOCS/BINARY_CODEC_STATUS_AND_TODO.md

@@ -0,0 +1,74 @@
+# Codec Wire Format Status
+
+This note tracks the current `k-parse | k | k-print` pipeline after the move
+to self-hosted binary pattern framing.
+
+## Current Shape
+
+The only wire format is:
+
+```text
+encode($pattern_value : $pattern) encode(value : decoded_pattern)
+```
+
+where:
+
+- the first segment is a normal k value of type `$pattern`, encoded under the
+  fixed singleton pattern for `$pattern` from [`core.k`](../core.k),
+- that decoded pattern becomes the structural authority for the second segment,
+- the second segment is the prefix-free value payload interpreted by that
+  pattern.
+
+Decoding the stream produces a materialized `Value` that carries the decoded
+pattern as `value.pattern`. The evaluator propagates the carried pattern, and
+encoding uses it by default.
+
+There is no second JSON transport format. Property-list JSON may still appear in
+tests or debug output as a readable notation for pattern graphs, but it is not a
+codec container and is not accepted at the command boundary.
+
+## Current Pipeline
+
+1. `k-parse`: text value plus optional pattern/type script -> binary pattern+value stream
+2. `k`: binary input -> `Value(pattern, tree)` -> evaluate `k` expression -> binary pattern+value stream
+3. `k-print`: binary input -> JSON-like textual k value
+
+This keeps the evaluator stage free of formatting concerns while staying close
+to the new semantic codec model.
+
+When `k-parse` has no explicit input pattern or type, it builds the pattern from
+the parsed value tree. Empty nodes become closed products, multi-child nodes
+become closed products, and one-child nodes become open unions by default. An
+explicit product pattern can force a one-child node to be treated as a singleton
+product.
+
+The derived wire pattern is canonicalized by collapsing finite closed
+subtrees from the leaves upward, starting at `["closed-product", []]`. Open
+pattern nodes remain distinct. This is pattern graph canonicalization, not
+value-payload DAG compression.
+
+## Verified Workflow
+
+```bash
+echo '["zebara", "ela", "kupa", ala, owca]' | \
+  ./codecs/k-parse.mjs | \
+  ./k.mjs '{.1 0,.3 1}' | \
+  ./codecs/k-print.mjs
+```
+
+Expected output:
+
+```json
+["ela","ala"]
+```
+
+## Open Work
+
+- tighten the pattern/value validation rules,
+- add direct coverage for more non-ASCII pattern labels in CLI fixtures,
+- extend tests and examples for the prefix codec.
+
+For the semantic design, see:
+
+- [`codecs/README.md`](../codecs/README.md)
+- [`codecs/POLYMORPHIC_BINARY_FORMAT.md`](../codecs/POLYMORPHIC_BINARY_FORMAT.md)

package/DOCS/CONVERGENCE.md

@@ -0,0 +1,92 @@
+# Convergence Strategies
+
+This note describes the current structure of the JavaScript type-derivation engine and the places intended for experimentation.
+
+## Current default
+
+Type derivation operates on the SCC DAG of relation dependencies.
+
+- Singleton SCC with no self-reference:
+  - use `single_pass`
+  - clone already-derived callee boundary patterns once
+  - compact once
+- Recursive SCC:
+  - use `fixed_point`
+  - iterate until signatures stabilize or the iteration budget is exhausted
+
+This split keeps acyclic modules fast while preserving the old behavior for recursive polymorphic definitions.
+
+## Public tuning hook
+
+`annotate`, `compile`, and `run` accept:
+
+```js
+{
+  convergence: {
+    strategy: "auto" | "single_pass" | "fixed_point",
+    maxIterations?: number
+  }
+}
+```
+
+The returned `annotate(...)` object includes:
+
+```js
+{
+  compileStats: {
+    sccCount,
+    sccs: [
+      {
+        members: ["relA", "relB"],
+        strategy: "fixed_point",
+        iterations: 3,
+        converged: true
+      }
+    ]
+  }
+}
+```
+
+This is the supported inspection surface for convergence experiments.
+
+## Why the current fast path works
+
+For an acyclic singleton SCC, every callee has already been fully derived by the time the current relation is processed. There is no need for repeated fixed-point propagation because:
+
+1. Callee boundary patterns are stable.
+2. The current relation only needs those stable input/output boundaries.
+3. One propagation pass plus one compaction is sufficient.
+
+`Examples/ieee.k` is exactly this shape: a large acyclic dependency graph. The major speedup comes from avoiding unnecessary fixed-point iteration there.
+
+## Current implementation choices
+
+Two implementation changes matter for performance:
+
+1. Compaction now starts from the quotient graph of live representatives instead of cloning the full historical union-find forest.
+2. Singleton-pattern registration is incremental and no longer re-finalizes the entire global code repository on every compaction.
+
+These two changes are what make `Examples/ieee.k` practical to type-check.
+
+## Where to experiment next
+
+If you want to continue convergence work, these are the main seams:
+
+- `convergence.mjs`
+  - strategy selection
+  - recursive SCC processing
+  - future divergence detection
+- `compression.mjs`
+  - quotient-graph construction
+  - equivalence partitioning
+  - alternative canonicalization schemes
+- `typing.mjs`
+  - clone/unify behavior
+  - pattern-graph data structure
+
+Promising next experiments:
+
+- Replace signature-string stabilization in `fixed_point` with structural change tracking.
+- Add divergence heuristics for recursive polymorphic SCCs.
+- Cache cloned callee boundary graphs for repeated call sites within one relation.
+- Compare the current partition refinement in `compression.mjs` with a hash-consed canonical-form approach.

package/DOCS/DIVERGENCE_DETECTION.md

@@ -0,0 +1,24 @@
+# Divergence detection (sketch)
+
+We can detect divergence when there is a cycle of definitions:
+
+```
+X1 = D1;
+X2 = D2;
+...
+Xn = Dn;
+```
+
+such that for each i, `Xi` is in `HEAD(Di-1)` (with indices modulo n).
+
+Define `HEAD` as the set of direct first ref calls:
+
+```
+HEAD(ref(X)) = {X}
+HEAD(?F E) = HEAD(E)
+HEAD($T E) = HEAD(E)
+HEAD((E1 E2 ...)) = HEAD(E1)
+HEAD({ E1 f1, E2 f2, ... }) = HEAD(E1) union HEAD(E2) union ...
+HEAD(<E1, E2, ...>) = {}   -- heads of a union is empty set
+HEAD(/ tag) = HEAD(. lab) = HEAD(| tag) = {}
+```

package/DOCS/Makefile

@@ -0,0 +1,99 @@
+# Dependencies: pandoc, dejavu-fonts-all, texlive-xetex
+
+CHAPTERS = book/01-introduction.md \
+           book/02-syntax-and-values.md \
+           book/03-types-as-finite-automata.md \
+           book/04-partial-functions-and-composition.md \
+           book/05-typing-filters-and-normalization.md \
+           book/06-values-in-memory.md \
+           book/07-the-partial-function-abi.md \
+           book/08-operational-semantics-and-execution.md \
+           book/09-compiler-architecture.md \
+           book/10-from-ast-to-intermediate-representation.md \
+           book/11-llvm-basics.md \
+           book/12-code-generation.md \
+           book/13-linking-and-execution.md \
+           book/14-canonical-serialization.md \
+           book/15-optimization-and-folding.md \
+           book/16-toward-a-universal-schema-registry.md \
+           book/appendix-a-implementing-a-prototype-compiler-in-python.md \
+           book/appendix-b-incorporating-external-predefined-types-and-functions.md
+
+all: book-combined.pdf book-combined.html book-combined.tex book.pdf book.html book.tex
+
+# Combined book from individual chapters
+book-combined.md: $(CHAPTERS)
+	echo "---" > book-combined.md
+	echo "title: \"k-language\"" >> book-combined.md
+	echo "author: \"W. Fraczak\"" >> book-combined.md
+	echo "---" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "<div align=\"center\">" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "\`\`\`" >> book-combined.md
+	echo "      { }                         { }" >> book-combined.md
+	echo "     /   \\       {.lang name}      |" >> book-combined.md
+	echo "   lang   by          -->         name" >> book-combined.md
+	echo "    |      |                       |" >> book-combined.md
+	echo "   'k'  'wojtek'                  'k'" >> book-combined.md
+	echo "\`\`\`" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "</div>" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "# Table of Contents" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "1. [Introduction](#chapter-1-introduction)" >> book-combined.md
+	echo "2. [Syntax and Values](#chapter-2-syntax-and-values)" >> book-combined.md
+	echo "3. [Types as Finite Automata](#chapter-3-types-as-finite-automata)" >> book-combined.md
+	echo "4. [Partial Functions and Composition](#chapter-4-partial-functions-and-composition)" >> book-combined.md
+	echo "5. [Typing, Filters, and Normalization](#chapter-5-typing-filters-and-normalization)" >> book-combined.md
+	echo "6. [Values in Memory](#chapter-6-values-in-memory)" >> book-combined.md
+	echo "7. [The Partial Function ABI](#chapter-7-the-partial-function-abi)" >> book-combined.md
+	echo "8. [Operational Semantics and Execution](#chapter-8-operational-semantics-and-execution)" >> book-combined.md
+	echo "9. [Compiler Architecture](#chapter-9-compiler-architecture)" >> book-combined.md
+	echo "10. [From AST to Intermediate Representation](#chapter-10-from-ast-to-intermediate-representation)" >> book-combined.md
+	echo "11. [LLVM Basics](#chapter-11-llvm-basics)" >> book-combined.md
+	echo "12. [Code Generation](#chapter-12-code-generation)" >> book-combined.md
+	echo "13. [Linking and Execution](#chapter-13-linking-and-execution)" >> book-combined.md
+	echo "14. [Canonical Serialization](#chapter-14-canonical-serialization)" >> book-combined.md
+	echo "15. [Optimization and Folding](#chapter-15-optimization-and-folding)" >> book-combined.md
+	echo "16. [Toward a Universal Schema Registry](#chapter-16-toward-a-universal-schema-registry)" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "## Appendices" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "- [Appendix A: Implementing a Prototype Compiler in Python](#appendix-a-implementing-a-prototype-compiler-in-python)" >> book-combined.md
+	echo "- [Appendix B: Incorporating External Predefined Types and Functions](#appendix-b-incorporating-external-predefined-types-and-functions)" >> book-combined.md
+	echo "" >> book-combined.md
+	echo "---" >> book-combined.md
+	echo "" >> book-combined.md
+	for chapter in $(CHAPTERS); do \
+		echo "" >> book-combined.md; \
+		cat $$chapter >> book-combined.md; \
+		echo "" >> book-combined.md; \
+		echo "---" >> book-combined.md; \
+		echo "" >> book-combined.md; \
+	done
+
+book-combined.tex: book-combined.md
+	pandoc book-combined.md -t latex -s -o book-combined.tex
+
+book-combined.pdf: book-combined.md
+	pandoc book-combined.md --pdf-engine=xelatex -V monofont="DejaVu Sans Mono" -V mainfont="DejaVu Serif" -o book-combined.pdf
+
+book-combined.html: book-combined.md
+	pandoc book-combined.md -o book-combined.html
+
+# Master file (table of contents only)
+book.tex: book.md
+	pandoc book.md -t latex -s -o book.tex
+
+book.pdf: book.md
+	pandoc book.md --pdf-engine=xelatex -V monofont="DejaVu Sans Mono" -V mainfont="DejaVu Serif" -o book.pdf
+
+book.html: book.md
+	pandoc book.md -o book.html
+
+clean:
+	rm -f book.pdf book.html book.tex book-combined.* *.aux *.log *.out
+
+.PHONY: all clean

package/DOCS/OBJECT_FILE_AND_PATTERN.md

@@ -0,0 +1,217 @@
+# Object File And Pattern Type
+
+This note records the representation boundary after parsing and type derivation.
+The codec boundary is no longer a JSON object. A serialized value is one binary
+stream:
+
+```text
+encode($pattern_value : $pattern) encode(value : decoded_pattern)
+```
+
+The pattern is the framing protocol. There is no separate envelope type.
+
+## Pattern Schema
+
+[`core.k`](../core.k) defines the canonical self-hosted pattern type:
+
+```k
+$ edge = { string label, bits target };
+$ edges = < {} nil, { edge car, edges cdr } cons >;
+
+$ pattern-node = <
+  {} any,
+  edges open-product,
+  edges open-union,
+  edges closed-product,
+  edges closed-union
+>;
+
+$ pattern = < {} nil, { pattern-node car, pattern cdr } cons >;
+```
+
+In this schema:
+
+- the first pattern-list element is node `0`, the root,
+- an edge target is a node index encoded as `$bits`,
+- labels are `$string` values and therefore Unicode scalar-value strings,
+- edge lists are sorted by label,
+- `any` carries no edges,
+- the four product/union node kinds carry their edge list directly.
+
+The fixed singleton pattern of `$pattern` is the first decoder context for all
+k wire values. Decoding any value first decodes a `$pattern` value under that
+constant, then decodes the remaining bits under the pattern just obtained.
+
+## Debug Notation
+
+Documentation and tests often show patterns as property-list JSON because it is
+compact to read:
+
+```json
+[
+  ["open-union", [["a", 1]]],
+  ["closed-product", [["b", 2], ["c", 3]]],
+  ["open-union", [["x", 3]]],
+  ["closed-product", []]
+]
+```
+
+That notation is not a transport format. It is only a host-side rendering of
+the same abstract graph.
+
+## Object File Direction
+
+The parser plus type-derivation phase should eventually emit an object value
+rather than executable JavaScript structures. A minimal first object shape is:
+
+```k
+$ object-file = {
+  pattern input-pattern,
+  pattern output-pattern,
+  pattern value-pattern
+};
+```
+
+The concrete input payload is then stored in the same binary stream form:
+`encode(value-pattern) encode(input : value-pattern)`. The exact object-file
+type still needs design work because the concrete input value is typed by the
+decoded pattern. The important boundary is that object files should carry
+ordinary k values and patterns, not a JSON codec object.
+
+Later versions can add relation IR, constant tables, symbol dictionaries,
+relocation/linking records, optimization metadata, and optional indexes.
+
+## Executable Object Container v1
+
+The current executable object format is a small binary container:
+
+```text
+"KOBJ" 0x00 0x01 0x0a
+uint32-be payload-byte-length
+utf8-json-payload
+```
+
+The payload stores:
+
+- the normalized code repository needed by the object,
+- the compiled relation IR,
+- each relation's type-pattern graph state,
+- the main relation name.
+
+Loading an object hydrates the type-pattern graphs back into runtime
+`TypePatternGraph` instances and executes them through `run.mjs`. This avoids
+source parsing and type derivation on the execution path.
+
+Object execution through `k.mjs`:
+
+```sh
+echo "..." | ./some-codec --parse | ./k.mjs -k path/to/program.ko | ./some-codec --print
+```
+
+The `-k` option accepts either an object file or a source `.k` file. `k.mjs`
+tries to load the file as an object first, then falls back to source parsing and
+compilation.
+
+Standalone helpers live in `objects/`:
+
+```sh
+./objects/compile.mjs path/to/program.k path/to/program.ko
+./objects/decompile.mjs path/to/program.ko path/to/program.decompiled.k
+```
+
+With no arguments, both helpers read from stdin and write to stdout:
+
+```sh
+cat path/to/program.k | ./objects/compile.mjs > path/to/program.ko
+cat path/to/program.ko | ./objects/decompile.mjs > path/to/program.decompiled.k
+```
+
+The decompiled source is canonical source regenerated from object IR. It uses
+shortest unique prefixes of the object's hash-based names for type and relation
+definitions, with a minimum prefix length of `4`. It is intended to be runnable
+and inspectable, not a byte-for-byte reconstruction of the original source.
+
+## Small Object Example
+
+For a tiny source file:
+
+```k
+-- id.k
+()
+```
+
+compile it with:
+
+```sh
+./objects/compile.mjs id.k id.ko
+```
+
+The first bytes of `id.ko` are the binary container header:
+
+```text
+4b 4f 42 4a 00 01 0a 00 00 03 0b ...
+K  O  B  J  \0 v1 \n payload-length
+```
+
+After the header, the payload is UTF-8 JSON. Pretty-printed and shortened, the
+payload has this shape:
+
+```json
+{
+  "format": "k-object",
+  "version": 1,
+  "codes": {
+    "@NiDZqYggx3VZ6b8quBZKTfkgJztWctkesuX4CrhTxM5c": {
+      "code": "product",
+      "product": {},
+      "def": "$C0={};"
+    }
+  },
+  "main": "__main__",
+  "defs": {
+    "rels": {
+      "__main__": {
+        "def": {
+          "op": "filter",
+          "filter": { "type": null, "open": true, "fields": {}, "name": "X0" },
+          "patterns": [0, 0],
+          "start": { "line": 1, "column": 1 },
+          "end": { "line": 1, "column": 3 }
+        },
+        "typePatternGraph": {
+          "patterns": {
+            "nodes": [{ "pattern": "(...)", "fields": [] }],
+            "parent": []
+          },
+          "edges": [{}],
+          "codeId": {}
+        }
+      }
+    },
+    "representatives": {},
+    "relAlias": { "__main__": "..." },
+    "compileStats": { "sccs": [...], "sccCount": 1 }
+  }
+}
+```
+
+The `codes` field is the type repository snapshot needed by this object. The
+`defs.rels.__main__.def` field is the executable relation IR. The
+`typePatternGraph` field is the compiled pattern graph used by `run.mjs` for
+input-envelope refinement. Loading the object reconstructs live
+`TypePatternGraph` instances from this JSON state and then evaluates the input
+value directly against the compiled IR.
+
+Decompiling this object produces canonical source with generated prefix names:
+
+```k
+----- codes -----
+$ NiDZ = {};
+----- rels -----
+QfyL = ?X0;
+----- main -----
+?(...) QfyL ?(...)
+```
+
+In the `rels` section, relation definitions are printed in the same SCC order
+recorded during compilation. Non-empty SCC groups are separated by a blank line.