Spec-conformance fix: correct stub levels and add BPMN-DI

Three corrections grounded in the UAPF SSOT specification (UAPFormat/
UAPF-specification, specification/01-concepts.md, 04-folder-structure.md,
05-level-composition.md, 10-conformance-checklist.md), which had not been
read in full before the initial workspace build.

1. Level relabel. The FG3 sub-process stubs fg3-2, fg3-3 and fg3-6 had
   been marked level: 4 by template inheritance from fg3-1 at Step 4 of
   the build, despite carrying no BPMN and no resources. Per the spec
   conformance checklist this fails the L4 requirement. The three are
   composition placeholders, which the spec models as L3 (composed
   subprocess / variant). Their uapf.yaml is now level: 3 with
   cornerstones.bpmn: false — conformant: L1-L3 packages MUST NOT
   duplicate L4 content. The three real executables fg3-1, fg3-4 and
   fg3-5 remain L4.

2. BPMN Diagram Interchange. All five .bpmn files in the workspace now
   carry a bpmndi:BPMNDiagram with BPMNShape and BPMNEdge elements
   produced by a swim-lane left-to-right auto-layout, so the diagrams
   preview in bpmn.io, Camunda Modeler and ProcessGit's web view. The
   spec doesn't require DI (its own examples have none) but practical
   reviewability does.

3. Transcoder. tools/register-transcoder gains bpmn_di.py — also runnable
   standalone for retrofitting existing BPMN files. transcode.py now
   imports it and emits DI by default for newly generated skeletons.
   sample-output/3.5.2.skeleton.bpmn and 3.5.3.skeleton.bpmn regenerated
   with DI; the logical-model content is byte-identical to the previous
   commit, only DI is added.

docs/methodology.md updated: adds an explicit Workspace-structure section
grounding L0-L4 in the SSOT spec, a Conformance-correction section
documenting the Step-4 mislabel and its fix, and drops the now-untrue
'no DI' line from limitations.

Validation after the change, full L1-L4 sweep: uapf-cli validate green on
all 10 packages (domains/gramatvediba, fg1-fg6, fg3, fg3-1..fg3-6);
xmllint clean on all 8 .bpmn/.dmn; every .bpmn has BPMNDiagram present.

docs/methodology.md

@@ -53,13 +53,47 @@ metadata the register does not carry), and the curator is identified in the
 package's ownership metadata. The two passes are mechanically
 distinguishable, and the workspace makes that visible.
 
+## Workspace structure — the L0–L4 level model
+
+The workspace's directory layout is grounded in the UAPF SSOT
+specification at `UAPFormat/UAPF-specification/specification/`, in
+particular `01-concepts.md` (Levels), `04-folder-structure.md`,
+`05-level-composition.md` and the conformance checklist in
+`10-conformance-checklist.md`.
+
+The spec defines five levels as aggregation and governance scope only —
+not as modeling semantics:
+
+- **L0 — Enterprise process collection index.** Workspace-level. MUST NOT
+  contain executable logic. Here: `enterprise/enterprise.yaml`.
+- **L1 — Domain process collection.** Composes L2/L3/L4 packages within a
+  domain. Here: `domains/gramatvediba/`.
+- **L2 — End-to-end business process.** Composes L3/L4 packages.
+  Here: `processes/fg1`, `fg2`, `fg3`, `fg4`, `fg5`, `fg6` — one per
+  Valsts Kase function group.
+- **L3 — Composed subprocess / variant.** A composition placeholder that
+  references one or more L4 packages.
+  Here: `processes/fg3-2`, `fg3-3`, `fg3-6` — the FG3 sub-processes that
+  were in scope for the POC but not built out to atomic executables.
+- **L4 — Atomic executable process.** MUST include at least one BPMN file
+  and MUST include resource mappings. Cornerstones (BPMN, optional DMN,
+  optional CMMN, resources) live here and only here.
+  Here: `processes/fg3-1`, `fg3-4`, `fg3-5`.
+
+The spec enforces strict containment of executable artefacts at L4: L1–L3
+packages MUST reference lower-level packages via `includes` and MUST NOT
+duplicate BPMN/DMN/CMMN files. The validator in `uapf-cli` and the
+conformance rules in `05-level-composition.md` reject workspaces that
+mix the layers.
+
 ## Pass 1 in detail — the transcoder
 
-The transcoder, `tools/register-transcoder/transcode.py`, is a single-file
-Python tool with one external dependency (`openpyxl`). It locates the
-worksheet and header row by content rather than by position, so it tolerates
-the leading title rows the registers carry and applies unchanged to any of
-the FG1–FG6 registers. It expects the standard register columns: the
+The transcoder, `tools/register-transcoder/transcode.py`, is a small Python
+tool with one external dependency (`openpyxl`) plus a co-installed layout
+helper `bpmn_di.py` (also runnable standalone). It locates the worksheet
+and header row by content rather than by position, so it tolerates the
+leading title rows the registers carry and applies unchanged to any of the
+FG1–FG6 registers. It expects the standard register columns: the
 predecessor block (FG-group and step-number in adjacent cells), the step's
 *Nr.p.k.*, *Process, apakšprocess*, the RACI block split across the three
 actor sub-columns (Nodarbinātais / Iestāde / VPC), *Darbību apraksts*,
@@ -79,6 +113,11 @@ successor references whose endpoints are both inside the sub-process; and
 one `bpmn:startEvent` per *entry step* (no in-group predecessor) and one
 `bpmn:endEvent` per *exit step* (no in-group successor), so the fragment's
 real boundary is visible rather than hidden behind synthesised gateways.
+The output then has BPMN Diagram Interchange (`bpmndi:BPMNDiagram` with
+`BPMNShape` and `BPMNEdge` elements) appended by `bpmn_di.py` using a
+swim-lane left-to-right auto-layout, so the resulting file previews in
+bpmn.io, Camunda Modeler and the ProcessGit web view without manual
+positioning.
 
 The output is `isExecutable="false"` and deliberately unembellished: no
 inferred gateways, no synthesised decision logic, no compensation for
@@ -165,27 +204,51 @@ register's prose and in the cited *Komandējuma izdevumu noteikumi*.
 
 ## Final validation pass
 
-The workspace at HEAD `a608de4` contains three Level 4 executable packages,
-six Level 2 composition stubs, the function-group L2 manifests, the
-transcoder tool, and this methodology note. The validation pass run for
-this step:
+The workspace contains three Level 4 executable packages, three Level 3
+composition stubs, six Level 2 function-group manifests, the Level 1
+domain manifest, the Level 0 enterprise index, the transcoder tool, and
+this methodology note. The validation pass run after the level-marker
+correction (next section):
 
+- `uapf-cli validate processes/fg3-1` → `OK: package valid`.
 - `uapf-cli validate processes/fg3-4` → `OK: package valid`.
 - `uapf-cli validate processes/fg3-5` → `OK: package valid`.
-- `uapf-cli validate processes/fg3-1` was passed at its build session (see
-  commit `81d32e8`) and the package has not been touched since.
-- All `.bpmn` and `.dmn` files in the workspace are XML-well-formed
-  (`xmllint --noout`).
-- All schema-validated UAPF files (`uapf.yaml`, `resources/*.yaml`,
-  `metadata/policies.yaml`) pass the UAPF 2.2.0 JSON schemas.
+- All `.bpmn` and `.dmn` files in the workspace are XML well-formed.
 - BPMN graph integrity: every `sequenceFlow` references existing
   `sourceRef`/`targetRef` nodes; every `flowNodeRef` resolves to a defined
   node; every `incoming`/`outgoing` reference is consistent with the
   corresponding flow's source/target.
+- All `.bpmn` files now carry BPMN Diagram Interchange — they preview
+  cleanly in bpmn.io, Camunda Modeler and ProcessGit's web view.
 - The transcoder is byte-deterministic: re-running it on the FG3 register
   for 3.5.2 and 3.5.3 reproduces the committed `sample-output/` files
   exactly.
 
+## Conformance correction — Step-4 level-labelling
+
+An initial pass of this workspace shipped with the FG3 sub-process stubs
+(`fg3-2`, `fg3-3`, `fg3-6`) marked `level: 4` by template inheritance from
+`fg3-1`, with no BPMN and no resources. That fails the spec's L4
+requirement — *§01-concepts: "A Level-4 package MUST include BPMN and MUST
+include resources and mappings, even if minimal."*
+
+The cause was a Step-4 design error: the FG3 sub-process packages were
+created in a single sweep with the same level marker as the FG3-1
+template, without checking whether each one would actually carry
+executable artefacts. Three of them never would in this POC's scope; they
+are composition placeholders, which the spec models as **L3** (composed
+subprocess / variant — `05-level-composition.md`).
+
+The correction is a level-marker change: `fg3-2`, `fg3-3`, `fg3-6` are
+now `level: 3` with `cornerstones.bpmn: false`. Their lack of BPMN is now
+spec-conformant (L1–L3 MUST NOT duplicate L4 content). The three real
+executables (`fg3-1`, `fg3-4`, `fg3-5`) remain L4. The mermaid in
+`05-level-composition.md` shows L2 → L3 → L4 as a typical chain, but the
+spec text is explicit that the diagram is informative and that L2
+packages may reference L4 directly when no intermediate composition is
+needed (`fg3` `includes` references the three L4s and the three L3 stubs
+in parallel, which is conformant).
+
 ## Implications for the AI regulatory sandbox
 
 The pipeline has four properties that bear on the sandbox's evaluation.