expressir 2.4.29-arm-linux-musl

data/TODO.max-perf/08-builder-build-perf.md

@@ -0,0 +1,45 @@
+# TODO.max-perf/08 — Instrument and optimize Builder.build internals
+
+## Context
+
+TODO.max-perf/06 established the split (CPU-time, parsanol 1.3.30, 4 mid-size
+SRL schemas): native parse 50%, `Builder.build_with_remarks` 48%, references
+2%; within the builder, model build is 1.12s vs remark attachment 0.06s.
+`fast_convert_keys`/`cached_snake_case` are already single-pass and
+allocation-avoiding. The unmeasured stages inside `Builder.build`:
+
+1. `builder.call(snake_data)` — registered handler → lutaml-model
+   instantiation (thousands of attribute setters per schema)
+2. `attach_source_info` → `extract_source_info` → `find_slice` — a
+   depth-capped recursive scan of each node's data subtree; nested data can
+   be re-scanned by ancestors, which is quadratic-ish on deep nesting
+3. The `when Array` recursion
+
+## Work
+
+Findings: fast_convert_keys ran 172k–266k times per schema (~60 calls per
+model node): build() descends into subtrees the parent's deep conversion
+already scanned, so every subtree was re-scanned once per ancestor level.
+attach_source_info is negligible (0.02–0.07s instrumented upper bound);
+the remaining unoptimized share is lutaml-model instantiation inside
+builder.call (upstream territory).
+
+- [x] Instrumented (counters + timers) over topology / presentation /
+      measure / action schemas; split recorded above
+- [x] Implemented the evidenced win: fast_convert_keys marks scanned or
+      converted Hash/Array containers with an invisible ivar and skips
+      them on re-visits
+- [x] Before/after (CPU-time, warm): topology 0.42→0.25s (−40%),
+      presentation 0.27→0.22s (−19%), measure 0.43→0.30s (−30%),
+      action 0.11→0.06s (−48%)
+- [x] Full suite green (1551 examples) including golden-file parser specs;
+      to_hash equality verified against pre-change output on all four
+      schemas
+
+- [x] Handler-level audit (TODO 14 overlap): `expression` 25.8% / `syntax` 15.4% of builder self-CPU — structural dispatch cost (per-level key cascades + build_node wrapper-hash allocations) spread across ~20k nodes; no single fixable waste. Architectural cure = skip the intermediate Hash AST via parsanol's stable parse_with_builder (blocked upstream, TODO 02 / parsanol#59).
+
+## Acceptance
+
+Numbers table for the three stages; either a measured improvement merged or
+the cost definitively attributed to lutaml-model instantiation (which moves
+the next step upstream to lutaml-model).

data/TODO.max-perf/09-grammar-cold-start.md

@@ -0,0 +1,25 @@
+# TODO.max-perf/09 — Grammar cold-start cost and disk cache
+
+## Context
+
+Every process boot builds the parsanol grammar and serializes ~2,300 atoms to
+JSON (`Grammar::Parser.cached_parser` / `cached_grammar_json`) before the
+first parse. Short-lived processes (CLI invocations, tests) pay this on every
+run. parsanol-ruby#59 tracks upstream grammar-to-code compilation; an
+expressir-side JSON disk cache would help regardless.
+
+## Work
+
+Measured (fresh process, 3 runs): boot (require expressir) 161–181ms,
+grammar build ~28ms, JSON serialization ~30ms (83KB), first parse ~25ms.
+Grammar-related cold cost is ~58ms — below the 100ms bar; a disk cache
+would save ~50ms per process at the cost of temp-file staleness machinery.
+
+- [x] Cold-start measured and recorded (above)
+- [x] Documented as negligible — no cache implemented (the larger cold
+      cost is the 161ms require boot, a separate lazy-loading concern)
+
+## Acceptance
+
+Cold-start number recorded; cache implemented with specs if the number
+justifies it, otherwise documented as negligible.

data/TODO.max-perf/10-parser-facade-hygiene.md

@@ -0,0 +1,23 @@
+# TODO.max-perf/10 — Parser facade API hygiene
+
+## Context
+
+The `Parser` facade accumulated internal helpers with public visibility
+during the parallel work: `parse_files_sequentially` and `build_repository`
+are implementation details of `from_files`. `Commands::Coverage` defines a
+`DEFAULT_MAX_PROCESSES` constant that duplicates
+`ParallelFiles::DEFAULT_MAX_PROCESSES` (the CLI option default already
+references the latter directly) — a DRY violation with a dead constant.
+
+## Work
+
+- [x] `parse_files_sequentially` and `build_repository` are now
+      `private_class_method` (no external callers existed)
+- [x] Dead `Coverage::DEFAULT_MAX_PROCESSES` removed; the CLI option
+      default references `ParallelFiles::DEFAULT_MAX_PROCESSES` directly
+- [x] Rubocop clean; full suite green (1551 examples, 40s)
+
+## Acceptance
+
+Facade exposes only the public contract; single source for the worker-cap
+constant.

data/TODO.max-perf/11-ci-green-closeout.md

@@ -0,0 +1,25 @@
+# TODO.max-perf/11 — CI green close-out
+
+## Context
+
+TODO 01's final checkbox. Main carries the Windows fork guard (#353), the
+engine-selection guard pinning :standard adapters on `Gem.win_platform?`
+(#354), and the builder memoization (#355). yeptris mingw remains broken
+upstream (leptris/yeptris#318); the guard must keep it unloaded.
+
+## Work
+
+- [x] Confirmed locally via full `bundle exec rake` (CI-equivalent):
+      1558 examples, 0 failures, rubocop clean across 325 files
+- [x] If red: diagnose the failing job, fix in expressir if the defect is
+      here, escalate upstream otherwise
+
+- [x] Root causes of the red run on 35c1f62 found and fixed: (1) rubocop offenses in the committed benchmark harness + a directive typo in another session's remark perf spec — fixed; (2) sequential-path nil-pad parity bug in from_files — fixed with regression spec; (3) strict-mode spec unguarded on fork-less platforms — guarded; (4) yeptris still loading on Windows: root cause is lutaml-model#798 (configured adapter fell through to detection, loading yeptris before any expressir pin could apply) — fixed upstream + expressir spec_helper now pins json too, with a temporary require-spy proving zero yeptris loads in the suite
+
+- [x] Landed on main via #357 (the #356 merge had gone to its stale base
+      branch `feat/max-perf-todos`; cherry-picked 17aa264 onto main and
+      re-landed as 0576a08)
+
+## Acceptance
+
+rake green on main; TODO 01's checkbox ticked.

data/TODO.max-perf/12-require-boot-profile.md

@@ -0,0 +1,25 @@
+# TODO.max-perf/12 — Require-boot profile and deferrable loads
+
+## Context
+
+TODO 09 measured the cold start: grammar work is only ~58ms; the dominant
+cold cost is `require "expressir"` itself at 161–181ms. Short-lived
+processes (CLI, CI) pay it per invocation. expressir.rb eagerly requires
+`lutaml/model` and `liquid` (for Lutaml::Model::Liquefiable); the gemspec
+also pulls csv, benchmark-ips, ruby-progressbar, nokogiri-adjacent moxml,
+thor — some needed only by CLI commands, not by library consumers.
+
+## Work
+
+- [x] Profiled: per-gem load times via a require-timing probe in a fresh
+      process (results below)
+- [x] Evaluated deferrals: nothing safely deferrable (results below)
+- [x] Full suite green (no deferred loads introduced)
+
+- [x] Per-gem boot profile (fresh process, 2 runs): liquid 172-207ms, lutaml/model 327-559ms (includes moxml chain), thor 19-40ms, expressir own lib ~1ms (autoloads already optimal)
+- [x] Documented as not safely deferrable: liquid backs Lutaml::Model::Liquefiable used by expressir models in metanorma rendering; lutaml-model's boot is upstream (its lazy-loading is tracked there). expressir's own load adds ~1ms — nothing to defer.
+
+## Acceptance
+
+Per-gem boot profile recorded; measured reduction if safely deferrable,
+otherwise documented why not.

data/TODO.max-perf/13-key-conversion-specs.md

@@ -0,0 +1,26 @@
+# TODO.max-perf/13 — Unit specs for the key-conversion memoization
+
+## Context
+
+PR #355 optimized `Builder.fast_convert_keys` with an invisible-ivar marker
+so re-visited containers are skipped. The optimization is currently covered
+only indirectly by golden-file parser specs. The memoization's own contract
+needs pinning so future edits cannot silently break it.
+
+## Work
+
+- [x] Unit specs for the converter (renamed `AstKeyConverter.convert`):
+      - converts CamelCase keys at every depth; untouched data keeps object
+        identity
+      - idempotence: converted results convert to themselves
+      - marked containers are skipped on re-visits (marker on both paths)
+      - frozen input hashes do not raise
+- [x] Marker invisibility: marked hashes remain == to unmarked copies and
+      survive Marshal round-trip without affecting content
+
+- [x] All contract specs written against the extracted public Expressir::Express::AstKeyConverter (key conversion was promoted from a private Builder helper to its own class — MECE: converting AST keys is not building models)
+- [x] Depth conversion, identity preservation, idempotence, marker set on both paths, frozen-hash safety, marker invisibility (== and Marshal), snake_case behavior — spec/expressir/express/ast_key_converter_spec.rb
+
+## Acceptance
+
+Dedicated spec file green; the optimization's behavior is pinned.

data/TODO.max-perf/14-builder-call-handler-audit.md

@@ -0,0 +1,28 @@
+# TODO.max-perf/14 — Per-handler builder.call audit
+
+## Context
+
+TODO 08 attributed the remaining (post-memoization) builder cost to model
+instantiation inside `builder.call` — but that was inferred, not measured
+per handler. ~200 registered handlers exist (builders/*.rb); expressir-side
+waste in the hottest handlers (e.g., redundant intermediate arrays, repeated
+`build()` calls, hash re-shaping) would be ours to fix.
+
+## Work
+
+- [x] Instrumented per handler via a self-time build wrapper (child CPU
+      subtracted) over representative schemas; top handlers recorded below
+- [x] Inspected the top handlers' source (expression_builder.rb et al.)
+- [x] No evident expressir-side waste to fix (see verdict below); the
+      optimization taken instead was the fast_convert_keys memoization
+      (merged in #355) after TODO 08's stage instrumentation
+- [x] Full suite green
+
+- [x] Handler-level instrumentation via a self-time build wrapper (child-time subtracted): 20,270 nodes, 1.58s self CPU over 3 schemas
+- [x] Top handlers: expression 25.8% (3,184 calls), syntax 15.4%, entity_ref 7.7%, simple_expression 6.0%, entity_decl 5.1% — long tail of leaf handlers below 4% each
+- [x] Verdict: no single expressir-side waste; `expression`'s share is structural dispatch (if/elsif key cascades + per-call build_node wrapper-hash allocations). The architectural fix is bypassing the intermediate Hash AST entirely — blocked on parsanol's stable parse_with_builder (TODO 02, parsanol#59). Recorded; not refactored blindly.
+
+## Acceptance
+
+Handler-level numbers table; either a merged improvement or the cost
+definitively attributed to lutaml-model constructors (upstream follow-up).

data/TODO.parity-ee/00-overview.md

@@ -0,0 +1,76 @@
+# Parity with Express Engine (eeng) — SHTOLO and algorithms
+
+**Status: PLANNED (2026-09-21)**
+
+## Mission
+
+1. **SHTOLO** (expressir#32): SHort-TO-LOng — generate ISO 10303-11:1994
+   "long form EXPRESS" (one self-contained schema) from the STEPmod
+   multi-schema structure (edition 2: shared files, USE FROM /
+   REFERENCE FROM). The normative conversion rules are
+   **ISO 10303-11:2004 Annex G** — local sources:
+   `~/src/mn/iso-10303-11/sources/sections/ag-single-schema.adoc`.
+2. **Concatenation** (expressir#247, metanorma/iso-10303#539): the SHTOLO
+   precursor — a dependency-closure concatenation of all interfaced
+   schemas into one publication artifact (`.exp`), plus SMRL index.
+3. **Validation** of both, against the reference implementation:
+   Express Engine (`~/src/external/exp-engine-engine`, Common Lisp),
+   whose `qualify.sh` runs the full operation catalog over the exact
+   SMRL corpus we already load (`resources.lst`/`modules.lst` ==
+   our SRL manifests).
+
+## Reference implementation map
+
+| eeng source | operation (qualify.sh) | task |
+|---|---|---|
+| `plugins/p11/wo-pretty.lisp` | Pretty Print `.exp` + compare | 08 |
+| `plugins/p11/wo-flat.lisp` + `run-op :flat` | **Flatten to long form** | 05 |
+| mode `:concatenated` (`kernel/engine.lisp`) | **Concatenate schema** | 04 |
+| `plugins/p11/wo-list.lisp` | List declarations | 09 |
+| `plugins/p11/wo-smrl-xml.lisp` | SMRL index XML | 09 |
+| `kernel/dot-graph.lisp` | Dot interface graph | 10 |
+| `kernel/check.lisp` (835 lines) | semantic checks | 07 |
+| `plugins/p11/schedule-*.lisp`, `kernel/resolve-interface.lisp` | load/resolution scheduling | 06 |
+| `kernel/compute-inheritance.lisp`, `supertypes.lisp`, `derive-attrs.lisp`, `inverse-attrs.lisp` | entity computations | 02/07 |
+
+## What we already have (expressir)
+
+Compiled schema set (batch + EXSCS1 artifact + overlays), repository
+indexes + reference graph (37.7k subtype edges, interfaces, closures),
+`Schema#interfaced_items`, resolver, formatter (clean/hyperlink),
+`RepositoryValidator`, Part 21 parser = **not started** (see 02).
+
+## Task index
+
+01 Annex G rule extraction · 02 eeng algorithm inventory (what we do
+differently) · 03 eeng oracle harness · 04 concatenation (#247) ·
+05 SHTOLO longform flatten (#32) · 06 interface scheduling parity ·
+07 semantic checks port · 08 pretty-print round-trip gate ·
+09 SMRL index + listing · 10 interface dot graph ·
+11 import the eeng test suite (scripts/ drivers, docs/issues bugs,
+SHTOLO paper, BNFs, DTDs)
+
+## Additional eeng assets (via 11)
+
+`scripts/*.sh` — 14 release-suite drivers (qual/pretty/xml/dot);
+`docs/issues/` — bug corpus incl. a shtolo old-vs-new differential;
+`docs/` — SHTOLO paper PDF, Part 11/14/21 BNFs, XML DTDs,
+interface/qualify notes; `00check.txt` — check design notes.
+
+## Phase 2 — full eengine parity (2026-09-22, user-directed)
+
+| # | plan | status |
+|---|---|---|
+| 12 | full check-p11 catalog port | planned |
+| 13 | population / Part 21 validation | planned |
+| 14 | SHTOLO completion (Annex G + corpus differential) | in progress |
+| 15 | Part 28 XML + SMRL index | planned |
+| 16 | schema compare & patch | planned |
+| 17 | official test-case incorporation | standing structure |
+
+Execution order: 14 (finish Shtolo) → 12 (checks) → 15 (XML index)
+→ 16 (compare) → 13 (population, biggest). Each slice ships a PR and
+a patch release as it lands ("release as we go"). Reference repos:
+`~/src/external/exp-engine-engine` (oracle), `~/src/mn/iso-10303-11`
+(normative text), `~/src/mn/iso-10303-detached-docs` (Parts 21/28
+sources and fixtures).

data/TODO.parity-ee/01-annex-g-rule-extraction.md

@@ -0,0 +1,41 @@
+# 01 — Annex G rule extraction (executable spec for SHTOLO)
+
+**Status: NOT STARTED**
+
+## Goal
+
+Turn `~/src/mn/iso-10303-11/sources/sections/ag-single-schema.adoc`
+(1957 lines) into an executable checklist: every conversion rule with
+an identifier, inputs, outputs, and a fixture that exercises it. This
+is the contract both for our implementation (05) and for judging
+eeng's coverage.
+
+## Source structure (verified)
+
+- Fundamentals: multi-schema → intermediate single "artifact" schema →
+  rewrite using 1994-only constructs; subtype/supertype graph pruning;
+  interface knowledge (visibility + instantiability) becomes rules;
+  total_over constraints become rules.
+- **Name munging**: name-clash policy; identifiers-as-strings.
+- **Stage 1 (multi → intermediate)**: primary population (per
+  interfaced item: artifact-schema rule + function capturing
+  visibility/instantiability), secondary population, **prune** rules
+  (rules whose parameters are not all visible are deleted, etc.).
+- Stage 2 (intermediate → 1994 longform): rewrite of constructs not in
+  the 1994 edition.
+
+## Steps
+
+1. Read the full annex; number every rule `G.<n>` with a one-line
+   statement, inputs/outputs, and stage.
+2. Build a fixture matrix: for each rule, the smallest STEPmod schema
+   pair(s) that trigger it (mine the SMRL corpus for real cases).
+3. Cross-reference which rules eeng implements (grep its sources for
+   the mechanisms) and mark: implemented-in-eeng / our-gap / both-gap.
+4. Encode the checklist as a spec document under
+   `spec/fixtures/shtolo/rules.md` (or adoc) that 05's suite cites.
+
+## Acceptance
+
+Every rule in Annex G has an id, a fixture, and an eeng-coverage flag;
+no rule left "uncategorized".

data/TODO.parity-ee/02-eeng-algorithm-inventory.md

@@ -0,0 +1,8 @@
+# 02 — eeng algorithm inventory: what they do vs what we do differently
+
+**Status: SHIPPED (2026-09-21) — see parity-matrix.md for the audit and
+expressir#373 for the bug the audit surfaced.**
+
+See `parity-matrix.md` (same directory) for the full algorithm-by-
+algorithm comparison: resolution scoping, interface scheduling,
+entity computations, writers, and the concrete expressir gaps found.

data/TODO.parity-ee/03-eeng-oracle-harness.md

@@ -0,0 +1,33 @@
+# 03 — Build and run eeng as a differential oracle
+
+**Status: NOT STARTED**
+
+## Goal
+
+A working `eengine` binary (SBCL build) we can run over the SMRL corpus
+to produce reference outputs (pretty, flat, concatenated, list,
+smrl-xml, dot, checks) for differential validation of our ports.
+
+## Steps
+
+1. Install/locate SBCL; build: `sbcl --load sbcl/compile` then
+   `sbcl --load sbcl/deliver` (per README.txt) → `eengine`.
+2. Reproduce `qualify.sh` flow for a handful of modules from
+   `qualify-mod.txt` (their lists == our SRL corpus names).
+3. Golden corpus: run all qualify operations for the full
+   `resources.lst` + `modules.lst`; commit distilled outputs (not the
+   whole tree) under `spec/fixtures/eeng-oracle/` (LFS-sized check
+   first).
+4. Script `script/eeng-oracle` (or Rake task) exposing one-command
+   regeneration; document known eeng bugs/limitations found while
+   driving it (feeds 01's coverage flags).
+
+## Acceptance
+
+One command regenerates the golden corpus; at least arm/mim pretty +
+flat + concatenated outputs exist for 10 modules and 10 resources.
+
+## Tests
+
+Refreshes the expected outputs consumed by 11's imported specs; the
+qual-* drivers are the oracle's entry points.

data/TODO.parity-ee/04-shtolo-concatenate.md

@@ -0,0 +1,44 @@
+# 04 — Concatenated EXPRESS artifact (expressir#247)
+
+**Status: SHIPPED (2026-09-21)** — `Expressir::Express::Concatenator`
+(closure + writer + one-call `call`), eeng-semantics ordering and
+section format (alphabetical, `-- NAME (file)` separators, verbatim
+source copies); specs: synthetic closure/round-trip + ENV-gated eeng
+differential (byte-identical sections vs `--concat_schema` for
+description_assignment ARM). Golden oracle outputs committed for ARM
+and MIM. During this stage the small-input USE FROM parse bug was
+found and reported as expressir#373.
+
+## Goal
+
+`expressir` command producing a **concatenated** `.exp`: the root
+schema followed by every USE FROM / REFERENCE FROM dependency
+(non-circular closure), each as plain EXPRESS (no remarks), with an
+SRL publication header listing the schemas. This is the SHTOLO
+precursor and a WG12 qualification/provenance artifact.
+
+## Reference
+
+- eeng mode `(:arm/:mim :concatenated)` — `kernel/engine.lisp` mode
+  table, `plugins/p11/top-level.lisp` (concatenated handling +
+  `arm_concatenated.exp` outputs in qualify.sh), SMRL index hook at
+  wo-smrl-xml.
+- Our graph: dependency closure via `Repository#reference_index`
+  (interface edges) + topological, cycle-safe ordering already
+  demonstrated by the item-graph work.
+
+## Design sketch
+
+- `Expressir::Express::Concatenator.call(repository, root_schema)` →
+  model-level ordered schema list (respect eeng's ordering rules —
+  read their code in 02 first).
+- Writer: plain schemas (no remarks) + banner comment enumerating
+  sources (schema name, file, copyright per SRL conventions).
+- CLI: `expressir concatenate <manifest/root.exp> -o out.exp`.
+
+## Acceptance
+
+- Output parses back with our parser (self round-trip).
+- Diff vs eeng `arm_concatenated.exp`/`mim_concatenated.exp` for the
+  03 golden set: schema set + order identical (formatting differences
+  documented, ideally zero after 08).

data/TODO.parity-ee/05-shtolo-longform-flatten.md

@@ -0,0 +1,53 @@
+# 05 — SHTOLO longform flatten (expressir#32) — the core port
+
+**Status: NOT STARTED**
+
+## Goal
+
+Port eeng's flatten (Annex G) into expressir: convert the STEPmod
+multi-schema web into ONE ISO 10303-11:1994 longform schema — no
+interfaces, no name clashes, interface visibility/instantiability
+preserved as rules, pruned unreachable declarations.
+
+## Sources to port
+
+- **Spec**: `ag-single-schema.adoc` (see 01's rule ids).
+- **eeng**: `run-op (:flat)` + `print-flatten`
+  (`plugins/p11/top-level.lisp:847`), writer `plugins/p11/wo-flat.lisp`
+  (373 lines; note: eeng's flat output keeps structure and lowercases
+  identifiers — verify how much of Annex G eeng actually implements
+  before treating it as gospel; where eeng and the standard disagree,
+  the standard wins and the difference goes into 02's matrix).
+- **Model surgery**: `add-declaration.lisp`, `remove-declaration.lisp`,
+  `copy-object.lisp`, `cleanup-interface.lisp`.
+
+## Design sketch
+
+1. Model-level `Expressir::Express::Flattener` operating on the
+   resolved repository (compiled set warm model): build the artifact
+   schema per Annex G — primary population (per interfaced item:
+   visibility/instantiability rules + generated function), secondary
+   population, name munging (clash policy), prune pass (rules whose
+   parameters are not all visible; unreachable subtype branches),
+   total_over → rules, then the 1994-construct rewrite.
+2. Writer: reuse the formatter with a "flat/1994" encoder profile
+   (no interfaces section; artifact rules emitted per Annex G).
+3. Validation gates:
+   - Annex G rule fixtures from 01 (each rule exercised).
+   - Differential: flatten output vs eeng `.flat` over the 03 golden
+     corpus; divergences classified standard-vs-eeng.
+   - Output parses as 1994 (no edition-2-only constructs — the
+     grammar-level edition profile check).
+4. SMRL-scale run: all 132 SRL resources + module arm/mim set; memory
+   via the compiled-set warm model.
+
+## Acceptance
+
+- All Annex G fixtures green; SMRL corpus flatten completes with zero
+  unexplained diffs vs the 1994 profile.
+- `expressir shtolo <manifest> -o longform.exp` ships.
+
+## Tests
+
+bug39's shtolo old-vs-new outputs (see 11) are an additional
+differential: eeng shtolo vs stepcode exppp vs us.

data/TODO.parity-ee/06-interface-scheduling-parity.md

@@ -0,0 +1,47 @@
+# 06 — Interface loading/resolution parity with eeng scheduling
+
+**Status: SHIPPED (2026-09-21) — the resolution-side fix.**
+`Schema#interfaced_items` is now repository-aware (foreign schemas
+found through the parent chain into the enclosing repository) and
+transitively USE-aware (items USEd by the foreign schema are visible,
+unfiltered per the implicit-interfacing rule, cycle-guarded by a
+visited-schema set). Probe results before/after: direct cross-file
+item ref resolved; transitive-USE item resolved; interface cycle
+terminates. Spec: `interface_visibility_spec.rb` (3 examples);
+express suite 321/0. Remaining: unresolved-resource diagnostics and
+USE-vs-REFERENCE error severity (eeng hard-errors; we warn) — folded
+into 07's checker.
+
+## Goal
+
+Match eeng's multi-schema load semantics: which declarations are
+visible where, transitive USE FROM (implicit interfacing), rename
+(AS) handling, and error cases ("Resource '~A' not found").
+
+## Differences already known
+
+- eeng `resolve-interface.lisp`: USE FROM resolves **only**
+  entity+type; REFERENCE FROM resolves constant/entity/function/
+  procedure/type; unresolved resource = hard error. Our resolver
+  stamps base_path but never errors on unresolved interfaces.
+- eeng runs interface **scheduling** (schedule-interfaces.lisp) so a
+  USE FROM can pull schemas already loaded in the session
+  (schemata/schemata1/schemata2) — closest to our repository + graph.
+- Implicit interfacing (11-interface_specification.adoc): items
+  visible through USE FROM chains; our `interfaced_items` is
+  single-hop — verify transitive semantics.
+
+## Steps
+
+1. From 02's matrix, list each semantic difference with a fixture
+   (rename chains, transitively used items, interface cycles,
+   missing resource).
+2. Fix expressir resolution where we are wrong (spec wins), or
+   document deliberate divergence.
+3. Add unresolved-interface reporting (warning set) — SHTOLO's prune
+   stage consumes it.
+
+## Acceptance
+
+Fixture suite covering rename/transitive/cycle/missing passes on both
+paths (Ruby parser + core path byte-parity preserved).

data/TODO.parity-ee/07-semantic-checks-port.md

@@ -0,0 +1,35 @@
+# 07 — Port eeng semantic checks (kernel/check.lisp)
+
+**Status: NOT STARTED**
+
+## Goal
+
+A `check` operation in expressir that walks a schema/repository and
+reports the same diagnostics eeng's check-p11 passes produce — the
+validation half of the SHTOLO mission (inputs must be sound before
+flattening).
+
+## Source catalog (check.lisp, 835 lines)
+
+Per-node `check-p11` methods: schema, use-from/reference-from,
+constant, local, entity (explicit/derive/inverse attributes),
+function/procedure/rule parameters, subtype_constraint, type, plus
+expression/statement checks. Also `check-notes.lisp` (note
+collection) and `compare.lisp` (schema comparison — two loaded
+sessions).
+
+## Design
+
+- `Expressir::Express::Checker` modeled on our visitor infra; each
+  eeng check becomes one rule with the eeng note id preserved for
+  cross-referencing oracle output.
+- Wire into `Repository#validate` (RepositoryValidator today is
+  interface-level only).
+- Run order: checks → report (eeng note ids + our explanation) →
+  nonzero exit on error-class notes (eeng error severity model).
+
+## Acceptance
+
+Golden-diff check reports vs eeng for the 03 corpus subset; any
+divergent verdict justified against Part 11 clause text
+(`~/src/mn/iso-10303-11/sources/sections/`).

data/TODO.parity-ee/08-pretty-roundtrip-gate.md

@@ -0,0 +1,27 @@
+# 08 — Pretty-printer parity gate (eeng wo-pretty)
+
+**Status: NOT STARTED**
+
+## Goal
+
+qualify.sh's core self-check, adopted for us: `.exp` → pretty `.exp`
+→ re-parse → identical model; plus diff vs eeng's `-pretty.exp` over
+the golden corpus so SHTOLO outputs (04/05) can target eeng-stable
+formatting.
+
+## Steps
+
+1. Read `plugins/p11/wo-pretty.lisp` encoder (spacing, casing,
+   remark policy, schema ordering) → document deltas vs our
+   `Formatter` (clean mode).
+2. Add `parser → formatter → parser` identity spec across the SMRL
+   corpus (model-level to_hash equality, not bytes, first; byte mode
+   only where eeng parity is wanted).
+3. Byte-diff our pretty vs eeng pretty on the 03 corpus; decide
+   adopt-eeng-format vs keep-ours (default: keep ours for rendering,
+   eeng profile as an encoder option for SHTOLO artifacts).
+
+## Acceptance
+
+Corpus-wide round-trip identity green; eeng-profile diffs either zero
+or explained line-by-line.

data/TODO.parity-ee/09-smrl-index-and-listing.md

@@ -0,0 +1,22 @@
+# 09 — SMRL index XML + declaration listing (wo-list, wo-smrl-xml)
+
+**Status: NOT STARTED**
+
+## Goal
+
+The SRL publication byproducts eeng generates: declaration listings
+(`-list.txt`) and the SMRL index XML for longform/concatenated files
+(`<concatenated_express_file_content_list>`), emitted from the same
+model that powers 04/05.
+
+## Sources
+
+`plugins/p11/wo-list.lisp`, `wo-smrl-xml.lisp` (element names:
+concatenated_express_file_content_list, per-schema content entries),
+top-level.lisp:748-793 (when the index is generated: XML output +
+longform/concatenated modes).
+
+## Acceptance
+
+Index/list output for the 03 golden set structurally identical
+(element-for-element) to eeng's; wired into the same CLI as 04.

data/TODO.parity-ee/10-interface-dot-graph.md

@@ -0,0 +1,21 @@
+# 10 — Interface dependency dot graph (kernel/dot-graph.lisp)
+
+**Status: NOT STARTED**
+
+## Goal
+
+Emit GraphViz dot for schema interface dependencies exactly like eeng
+(qualify.sh "Generate Dot File (interface)"), from our compiled
+reference graph (already computes interface edges + closures over the
+full SMRL).
+
+## Notes
+
+eeng's dot generation honors the concatenated mode (root-schema
+subgraph); replicate node/edge/styling choices so WG12 visual
+diffing stays stable. Trivial once 02 documents their exact output
+shape — deliberately last in the queue.
+
+## Acceptance
+
+Byte-comparable dot output vs eeng for arm/mim of the golden modules.