Add StarGraph[n] and fix the generator argument-array leak

.claude/GUIDANCE_ROLES.md

@@ -0,0 +1,60 @@
+# Guidance roles
+
+Some skills ask for org-supplied guidance documents by name — a security baseline, an
+engineering-principles file, PR-review conventions — because that content is genuinely
+yours to write, not something a generic kit can ship.
+
+Skills never hardcode a path to your document. They read this file for a named **role**
+and resolve it here instead. Fill in the ones your team has; leave the rest
+`not-configured`.
+
+Written by `/setup-kit` on 2026-08-22. DETECT (`kit-setup/scripts/detect_guidance_roles.py`)
+found one hit — root `AGENTS.md` — and no signal for the other five; confirmed with the
+human rather than guessed.
+
+## security-baseline
+
+```
+security-baseline = not-configured
+```
+
+## multi-cloud-guidelines
+
+```
+multi-cloud-guidelines = not-configured
+```
+
+## documents-and-data-guidelines
+
+```
+documents-and-data-guidelines = not-configured
+```
+
+## pr-and-review-guidelines
+
+```
+pr-and-review-guidelines = not-configured
+```
+
+## agents-guide
+
+```
+agents-guide = AGENTS.md
+```
+
+Root `AGENTS.md` documents the code-review-graph MCP tool usage convention for this repo.
+
+## pr-template
+
+```
+pr-template = not-configured
+```
+
+Not actually a gap — `/describe-pr` discovers its own template; this role has no effect on
+its behavior.
+
+## code-review-checklist
+
+```
+code-review-checklist = not-configured
+```

.claude/VERIFICATION_LADDER.md

@@ -0,0 +1,56 @@
+# Verification ladder configuration
+
+One file, read by `skills/verification-ladder/scripts/ladder.py`. Change a value here instead
+of editing that script.
+
+Written by `/setup-kit` on 2026-08-22. DETECT (`kit-setup/scripts/detect_ladder.py`) found
+**zero signal for all four phases** against this repo: `CMakeLists.txt` lives at
+`tests/CMakeLists.txt`, not repo root (the detector only checks the root), and there is no
+`c-cmake`/`make` toolchain entry that recognizes a hand-written top-level `makefile` at all —
+so a `make ...`-only CI (`.github/workflows/build.yml`) produced no CI-marker hits either.
+Every value below comes from `SPEC.md` §9 and `.github/workflows/build.yml`, confirmed with
+the human directly, not from DETECT.
+
+## Static analysis
+
+```
+static = make check-c99 && make check-packed-aware
+```
+
+`make check-c99` (`tools/check_c99_portability.py`) flags POSIX-only symbols glibc hides
+under `-std=c99` (missing `#ifndef` guards on `<math.h>` constants, missing feature-test
+macros on POSIX functions) — this repo's actual lint tier, and the one CI runs first
+(`.github/workflows/build.yml:73`). `make check-packed-aware` is a static structural audit:
+diffs the NDArray dispatch sites in source against `src/pack.c`'s `AWARE` list.
+
+## Type checking
+
+```
+typecheck = make -j$(nproc)
+```
+
+C99 has no separate type-check phase from compilation — `SPEC.md`'s own words: "for
+C/C++/Go/Java, this is often just 'does it build.'" `gcc -std=c99 -Wall -Wextra`
+(`-Werror` on several diagnostics GCC 14 promotes) is the closest equivalent.
+
+## Unit tests
+
+```
+unit = cd tests && mkdir -p build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Release && make -j$(nproc) && for t in *_tests; do ./$t || exit 1; done
+```
+
+The CMake-built `test_*.c` suite under `tests/` (SPEC.md §9).
+
+## Integration tests
+
+```
+integration = make check-nd-surfaces
+```
+
+Runs the built `./Mathilda` binary over probe expressions across three representations
+(plain `List`, packed `List`, visible `NDArray`) and requires them to agree — components
+(evaluator, pack transparency gate, ND kernels) exercised together, with real execution, not
+isolated unit logic. `valgrind --leak-check=full ./Mathilda` (SPEC.md §4) is real practice
+here but was left out of this phase: it needs a script argument with no single canonical
+choice, so scripting it as the ladder's integration command would be a guess, not a
+confirmed answer.

Mathilda_spec.md

@@ -85,5 +85,6 @@ Detailed feature-addition and bug-fix notes, organized by week (Mon – Sun, key
 | 2026-08-03 → 2026-08-09 | [`changelog/2026-08-03.md`](docs/spec/changelog/2026-08-03.md) |
 | 2026-08-10 → 2026-08-16 | [`changelog/2026-08-10.md`](docs/spec/changelog/2026-08-10.md) |
 | 2026-08-17 → 2026-08-23 | [`changelog/2026-08-17.md`](docs/spec/changelog/2026-08-17.md) |
+| 2026-08-31 → 2026-09-06 | [`changelog/2026-08-31.md`](docs/spec/changelog/2026-08-31.md) |
 
 New entries land in the file for the current week (use the Monday-date of that week as the filename, format `YYYY-MM-DD.md`). When a change touches a built-in's documented behavior, the corresponding `docs/spec/builtins/*.md` file is updated as well; the changelog records the rationale and timing.