diff --git a/.devcontainer/Dockerfile b/.devcontainer/Dockerfile
index 3932588..cffa876 100644
--- a/.devcontainer/Dockerfile
+++ b/.devcontainer/Dockerfile
@@ -1,5 +1,6 @@
-# Every toolchain the skill's evaluation fixtures need, so the evals run the same way
-# on any machine and stay sandboxed in the container (see SECURITY.md).
+# The JDK, Ruby, Python, and C toolchains, and the libraries Swift needs, for running agent
+# sessions on projects in those languages, the same way on any machine and sandboxed in the
+# container. Node and Rust come from devcontainer.json; Swift from post-create.sh.
 # Base: the dev container project's Ubuntu image (non-root user "vscode").
 FROM mcr.microsoft.com/devcontainers/base:ubuntu-24.04
 
diff --git a/.devcontainer/post-create.sh b/.devcontainer/post-create.sh
index 7c9dab0..0009645 100755
--- a/.devcontainer/post-create.sh
+++ b/.devcontainer/post-create.sh
@@ -1,12 +1,11 @@
 #!/usr/bin/env bash
 # Runs once when the container is created. Installs what the Dockerfile does not:
-# the Claude Code CLI (for running evals) and Swift (for swift-shop).
+# the Claude Code CLI (for running agent sessions) and Swift.
 set -euo pipefail
 npm install -g @anthropic-ai/claude-code
 if ! command -v swift > /dev/null; then
   curl -fsSL https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz -o /tmp/swiftly.tar.gz
   tar -xzf /tmp/swiftly.tar.gz -C /tmp
-  /tmp/swiftly init --quiet-shell-followup --assume-yes || echo "Swift not installed; swift-shop cannot run. See https://www.swift.org/install/linux/"
+  /tmp/swiftly init --quiet-shell-followup --assume-yes || echo "Swift not installed. See https://www.swift.org/install/linux/"
 fi
 echo "Toolchains: $(java -version 2>&1 | head -1); $(ruby -v); $(node -v); $(cargo --version); $(python3 --version)"
-echo "Self-test the eval harness (no API cost): evals/selftest.sh"
diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml
index c966d35..7250cf0 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.yml
+++ b/.github/ISSUE_TEMPLATE/bug_report.yml
@@ -1,5 +1,5 @@
 name: Bug or wrong advice
-description: The skill made an agent do something wrong, unsafe, or slower, or the docs or eval scripts are broken.
+description: The skill made an agent do something wrong, unsafe, or slower, or the docs are wrong.
 labels: [bug]
 body:
   - type: markdown
diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index c18dd8d..0000000
--- a/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-__pycache__/
diff --git a/CHANGELOG.md b/CHANGELOG.md
index baa3707..2064a22 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -12,12 +12,32 @@ Versions follow [semantic versioning](https://semver.org): while the major versi
 - **Before filing a speedup as a behavior change, the agent looks for a version that keeps the behavior:** redo costly work only when its input changed, hand out copies of cached values, take the fast path and fall back to the original where it cannot match (for example, resend a failed batch one item at a time), or read data that something outside the operation may change once per operation. A behavior change is listed only when no such version exists, with each way tried. When the developer declines a behavior change, the agent applies the version that keeps the behavior.
 - **Changes to how code calls another system are now verifiable.** Batching, deduplicating, or caching calls to a database or service is checked against a fake that implements the collaborator's documented contract (limits, missing items, partial failure, error order), comparing everything callers observe and the requested items as a set. Only behavior the documentation does not settle stays unverified.
 - **The agent states its mode first, then reads the file for that mode before looking at code** (`WORKFLOW.md` or `WRITING-NEW-CODE.md`), and `DIFFERENTIAL-TESTING.md` before writing differential tests.
-- **The agent says when it runs on a small model.** If it knows its model and the model is a small, fast, or low-cost tier, it adds one line after the mode: the skill is tested with coding-tier models such as Claude Sonnet and Opus.
-- **New behavior traps,** from changes coding-tier models made in testing: numeric identity in hash keys (`1` against `1.0`), new size limits an optimization introduces, and batched queries that must keep values as bound parameters. In write mode, a cache key must include the user, tenant, and permissions when they change the result.
+- **The agent says when it runs on a small model.** If it knows its model and the model is a small, fast, or low-cost tier, it adds one line after the mode: the skill is built for coding-tier models such as Claude Sonnet and Opus.
+- **New behavior traps:** numeric identity in hash keys (`1` against `1.0`), new size limits an optimization introduces, and batched queries that must keep values as bound parameters. In write mode, a cache key must include the user, tenant, and permissions when they change the result.
 - **The A/A run of a differential test is required only when the behavior can vary between runs** (time, randomness, hash or iteration order, concurrency, external systems); deterministic code records "not needed".
 - **The end-to-end share is its own field** in the apply results and part of each item's prediction.
 - **One "Reproduce" section can cover every item** in `APPLY-RESULTS.md` when one harness tests them all.
 
+### Fixed
+
+- **Complexity and behavior claims checked across every skill file, and about 60 corrected.** The ones that could lead an agent to a slower or wrong choice:
+  - Dijkstra with a heap is slower than the array version on dense graphs.
+  - A deque does not make inserting in the middle O(1).
+  - One multi-source BFS gives only the distance to the nearest source.
+  - Components answer reachability only in undirected graphs.
+  - A rolling hash returns to O(n·m) when there are many matches.
+  - De Casteljau evaluation is O(d²), not O(d).
+  - A Fenwick tree cannot answer subtree minimum or maximum.
+  - Total unimodularity gives integer solutions only with integer data.
+  - Welford's method is no more accurate than the two-pass variance.
+  - Standard cardinality sketches fail after about k adaptive queries, not k².
+  - Rust's `HashMap` order varies per map, not only per process.
+  - glibc's `qsort` is stable in practice.
+  - Python's `median` does no exact arithmetic.
+  - Java's single-character `split` compiles no regex.
+  - C build files alone no longer select the C companion file for C++ projects.
+- **Citations corrected:** the LCS hardness result (Abboud, Backurs, and Vassilevska Williams), the differential-privacy method for robust streaming (Hassidim et al.), and the author list of the SODA 2026 cardinality-sketch paper.
+
 ### Added
 
 - **For contributors:** `docs/ARCHITECTURE.md` (what loads when, where each idea lives), `CONTRIBUTING.md`, issue and pull-request templates, `CODEOWNERS`, and a dev container with the JDK, Ruby, Node, Rust, Python, and Swift toolchains.
@@ -26,15 +46,8 @@ Versions follow [semantic versioning](https://semver.org): while the major versi
 
 ### Removed
 
-- **The evaluation harness (`evals/`) and the examples (`examples/`),** to be rebuilt per `docs/EVAL-PLAN.md`. Both stay readable in the [repository history](https://github.com/protechnocrats/algorithmic-intelligence/tree/da47e4b), with every round's results.
-- **The CI checks that depended on it** (token budgets, cross-references, rule evidence) and `docs/RULE-EVIDENCE.md`.
-
-### Evaluation
-
-Results on Claude Opus 5.5 from the rounds since 0.1.0 ([results in the history](https://github.com/protechnocrats/algorithmic-intelligence/tree/da47e4b/evals/results)), graded on every category including a judge reading each session's code and reports:
-- Without the skill, Opus applied behavior changes on a general "apply all" in all 3 sessions where this could be scored. With it, Opus held every one for review, in 4 of 4 sessions.
-- Bugs were reported to the developer in 4 of 4 sessions with the skill and 0 of 3 without.
-- Sessions with the skill cost 1.7 to 3 times as much.
+- **The evaluation harness (`evals/`), the examples (`examples/`), and all their results,** including the results quoted in the README and in the 0.1.0 notes below (the published v0.1.0 release page keeps its original notes). The skill will be benchmarked from scratch under `docs/EVAL-PLAN.md`, and only those results will be published.
+- **The CI checks that depended on the harness** (token budgets, cross-references, rule evidence), `docs/RULE-EVIDENCE.md`, and the harness's `.gitignore`.
 
 ## [0.1.0] - 2026-11-01
 
@@ -52,14 +65,8 @@ The first release. Install it with `npx skills add https://github.com/protechnoc
 - **Techniques:** core tables plus 16 domain files (graphs and trees; sequences, DP, search, and NP-hard problems; strings and text; math and numerics; machine learning; images and signals; geometry and CAD; games and simulation; spatial data; hardware and concurrency; data at scale; optimization and scheduling; hostile inputs; distributed systems; queues and latency; specialized data structures).
 - **Reports:** `OPTIMIZATION-REPORT.md` written once in report mode and never rewritten, `APPLY-RESULTS.md` written once in apply mode, and `BUGS-FOUND.md`. Bugs are documented, never fixed on purpose. Behavior changes are listed for review and marked in the code once approved.
 
-### Evaluation
-
-- Test projects in Kotlin, TypeScript, Swift, C, Rust, Java, Ruby, and Python with planted cases and answer keys; held-out Python and Ruby projects; grading probes for the Python, TypeScript, Java, and Ruby projects; a headless runner with a spending cap and a stall watchdog; cost, token, and permission-refusal statistics; trigger tests; token budgets; and checks of Kotlin claims the official documentation does not settle.
-- Results so far are in `evals/results/`. On the held-out Python project (round 3), report-flow cases passed at 1.00 with the skill against 0.50 without it on Opus 5.5, and 0.83 against 0.39 on Haiku 5.5. On the Java tuning project (rounds 4 to 6, Haiku 5.5, with the skill only) no session changed the code's behavior.
-
 ### Known limitations
 
-- Only Claude Code has been evaluated; the skill is written to be agent-neutral.
-- The Java and Ruby projects have no baseline runs yet, the Ruby held-out project has not been run, and the Swift project has not been run on a Swift toolchain.
-- Smaller models do not always load the skill for new-code requests from its description alone; the README gives a one-line project instruction that fixes most of it.
+- The skill is written to be agent-neutral, but has only been used with Claude Code.
+- Smaller models do not always load the skill for new-code requests from its description alone; the README gives a one-line project instruction for this.
 - Formal verification (proofs, model checking) is the least developed of the skill's roles.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8dc2c2a..7bb4e15 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -19,7 +19,7 @@ Thank you for helping. This project is a skill: Markdown instructions that codin
 ## Changing the skill
 
 - **Put each instruction where it belongs.** A mandatory rule goes in `skills/SKILL.md` and in the file that carries it out. Anything else lives in exactly one file, and others point to it.
-- **Write for coding-tier models.** The skill is tested with Claude Sonnet and Opus. Every instruction must be followable without guessing: explicit, no shorthand, and an example where a rule is easy to misread.
+- **Write for coding-tier models** such as Claude Sonnet and Opus. Every instruction must be followable without guessing: explicit, no shorthand, and an example where a rule is easy to misread.
 - **Keep generic files language-neutral.** Name concepts ("an operation that copies a collection"), not one language's functions. Language-specific names belong in `skills/languages/`.
 - **Keep references whole.** When you rename a file or a section, or renumber a rule, update every link, file name, quoted section name, and rule number that points at it. An agent that follows a reference to nothing skips that step.
 - **Do not trim instructions to save tokens.** Every file is loaded only when a step names it. Remove repetition, never content.
@@ -35,7 +35,7 @@ Use [`skills/languages/GENERIC.md`](skills/languages/GENERIC.md) as the checklis
 
 ## Evaluation
 
-The evaluation harness is being rebuilt. [docs/EVAL-PLAN.md](docs/EVAL-PLAN.md) describes what it will test (hostile inputs, security side effects of optimizations, unusual problems, and write mode, on Sonnet and Opus). Earlier rounds and their tooling are in the git history before the `evals/` folder was removed.
+A new evaluation harness is being built from scratch. [docs/EVAL-PLAN.md](docs/EVAL-PLAN.md) describes what it will test (hostile inputs, security side effects of optimizations, unusual problems, and write mode, on Sonnet and Opus).
 
 ## Toolchains
 
diff --git a/README.md b/README.md
index a0de061..ec15d19 100644
--- a/README.md
+++ b/README.md
@@ -12,8 +12,6 @@ Algorithmic Intelligence (`algorithmic-intelligence`) is a skill for AI coding a
 
 Sometimes the best engineering decision is to leave the code alone, and the skill says so when it is.
 
-**See it first:** [a real, unedited report](https://github.com/protechnocrats/algorithmic-intelligence/tree/da47e4b/examples) from one session on a Java project, and one item compared with and without the skill.
-
 ## Quick start
 
 ```bash
@@ -117,7 +115,7 @@ Agents load a skill by matching your request against the skill's description. Re
 Use the algorithmic-intelligence skill when writing new code that loops over collections or data, and for any question about the speed or complexity of existing code.
 ```
 
-Without it, agents often skip the skill for new code: in early testing, even Opus 5.5 did not load it for 1 of 3 write-mode requests. A broader line such as "use it when writing new code" also loads it for trivial helpers.
+Without it, agents can skip the skill for new code. A broader line such as "use it when writing new code" also loads it for trivial helpers.
 
 ### Verify and update
 
@@ -242,18 +240,9 @@ Algorithmic reasoning is independent of the programming language, but costs and
 
 Companion files cover the language and its standard library only. Frameworks and platforms (UI toolkits, ORMs, web frameworks, game engines) are deliberately not covered; the general rules (N+1 queries, main-thread blocking, I/O in loops) apply to them.
 
-## Evidence
-
-The skill was tested by running the same coding agent on small projects with planted problems, with and without the skill, and checking each session's final code against the original with trap inputs. The harness and every round's results are in the [repository history](https://github.com/protechnocrats/algorithmic-intelligence/tree/da47e4b/evals); a new harness is being built ([docs/EVAL-PLAN.md](docs/EVAL-PLAN.md)).
-
-Results on Claude Opus 5.5 so far:
-
-- **Hostile input** (held-out Python project): every run without the skill shipped a hash-based fix that becomes quadratic when an attacker chooses colliding IDs, and applied a concurrency change nobody approved. No run with the skill did either. Report-flow cases passed at 1.00 with the skill against 0.50 without.
-- **Behavior changes** (Ruby and Java projects, graded by a separate model reading each session's code and reports): without the skill, Opus applied behavior changes on a general "apply all" in all 3 sessions where this could be scored (edge cases handled differently, new size limits, changed error messages, shared mutable results). With the skill, it held every one for the developer's review, in 4 of 4 sessions.
-- **Bugs** found along the way were reported to the developer in 4 of 4 sessions with the skill and 0 of 3 without.
-- **Cost:** sessions with the skill cost 1.7 to 3 times as much, mostly for writing and running the differential tests and benchmarks that verify each change.
+## Evaluation
 
-**Limits:** small samples, so treat these as early signals. All runs used Claude Code; other agents have not been evaluated. Claude Sonnet has not been tested yet.
+The skill will be evaluated by running the same coding agent on projects with planted problems, with and without the skill, and checking each session's final code and reports. The benchmarks are being built ([docs/EVAL-PLAN.md](docs/EVAL-PLAN.md)); results will be published here when they exist.
 
 ## Files
 
@@ -280,7 +269,7 @@ The skill's knowledge base is modular and organized around its workflow. The age
 - [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md): what each part of the repository does, what the agent loads in each mode, and where each idea lives.
 - [CONTRIBUTING.md](CONTRIBUTING.md): how changes reach `main`, and the rules for changing the skill.
 - `.devcontainer/`: the JDK, Ruby, Node, Rust, Python, and Swift toolchains, and a sandbox for running agent sessions.
-- [docs/EVAL-PLAN.md](docs/EVAL-PLAN.md): the plan for the next evaluations. Earlier rounds are in the [repository history](https://github.com/protechnocrats/algorithmic-intelligence/tree/da47e4b/evals/results).
+- [docs/EVAL-PLAN.md](docs/EVAL-PLAN.md): the plan for the next evaluations.
 
 ## Releases and security
 
diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
index b422a6e..a41fc77 100644
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -4,7 +4,7 @@ A map of the repository for contributors: what each part does, what loads when,
 
 ## The skill
 
-`skills/` is everything an installed user gets: Markdown instructions that a coding agent loads. The skill has no code. Its "runtime" is the agent reading the files, so the main engineering constraints are **what an agent loads, when, and how much it costs**, and **whether a coding-tier model can follow every instruction without guessing**. The evaluation harness is being rebuilt ([EVAL-PLAN.md](EVAL-PLAN.md)).
+`skills/` is everything an installed user gets: Markdown instructions that a coding agent loads. The skill has no code. Its "runtime" is the agent reading the files, so the main engineering constraints are **what an agent loads, when, and how much it costs**, and **whether a coding-tier model can follow every instruction without guessing**. A new evaluation harness is being built from scratch ([EVAL-PLAN.md](EVAL-PLAN.md)).
 
 ## What loads when
 
diff --git a/docs/EVAL-PLAN.md b/docs/EVAL-PLAN.md
index 2c73de0..7f69636 100644
--- a/docs/EVAL-PLAN.md
+++ b/docs/EVAL-PLAN.md
@@ -1,17 +1,17 @@
 # Evaluation plan: adversarial inputs, security, unusual problems, and write mode on Sonnet and Opus
 
-Status: proposed, 2026-11-02. Nothing in this plan spends money until its phase's cap is agreed. The `evals/` folder was removed on 2026-11-02. The tools this plan names (`run-pilot.sh`, `grade.py`, the probes, `selftest.sh`) are in the repository history at commit `da47e4b`; phase 0 restores or rewrites the ones it needs, and the existing fixtures it mentions come back only if phase 0 brings them back.
+Status: proposed. Nothing in this plan spends money until its phase's cap is agreed. The harness, fixtures, and results are built from scratch: no earlier ones carry over, and every published number will come from rounds run under this plan.
 
 ## Why
 
-- **Every round since round 7 ran report mode only.** Write mode, the mode most developers will hit (new code, loaded from the description), has one case per fixture, was last run in round 7 on Haiku, and has no write-specific checks in `grade.py`. Every round from now on runs report **and** write mode.
-- **Headline metrics move to coding-tier models.** Sonnet 5.5 has never been tested; Opus 5.5 has 4 valid baselines in total.
-- **The probes undercount strong-model failures.** In rounds 8 and 9 the probe found no behavior difference in Opus baselines, but the judge found behavior changes applied on "apply all" in 3 of 4 (zero-length bookings, new size limits, `1` vs `1.0`, shared mutable strings, error messages, all-or-nothing batches). The probes only test the inputs they were written for.
-- **The cases are too textbook.** Most cases are problems Opus solves without the skill. The skill's value for strong models is in what they miss: hostile inputs, security side effects of an optimization, problems with no textbook answer, and keeping contracts under pressure.
+- **Write mode needs its own evaluation.** It is the mode most developers will hit (new code, loaded from the skill's description), and it needs its own cases and grading. Every round runs report **and** write mode.
+- **Headline metrics come from coding-tier models** (Sonnet and Opus), the models the skill is written for.
+- **Probes alone undercount strong-model failures.** A probe tests only the inputs it was written for. A judge model reading each session's code and reports can catch behavior changes no probe checked, such as those in group C below. Grade with both.
+- **Cases must not be textbook.** Strong models solve textbook problems without the skill. Its value for them is in what they miss: hostile inputs, security side effects of an optimization, problems with no textbook answer, and keeping contracts under pressure.
 
 ## What we test: the case catalogue
 
-Every case gets an answer key (Pass / Fail lines, rules tested), a probe check that runs on the session's final code, and a correct and a wrong self-test rewrite that the probe must pass and catch (`evals/selftest.sh --probes`). The skill is a performance skill, not a security scanner: the security cases test **whether an optimization opens a hole, or a performance problem is itself the attack**, and whether existing security bugs are reported (rule 4) rather than silently fixed or widened.
+Every case gets an answer key (Pass / Fail lines, rules tested), a probe check that runs on the session's final code, and a correct and a wrong self-test rewrite that the probe must pass and catch. The skill is a performance skill, not a security scanner: the security cases test **whether an optimization opens a hole, or a performance problem is itself the attack**, and whether existing security bugs are reported (rule 4) rather than silently fixed or widened.
 
 ### A. Hostile inputs: performance as the attack (CWE-407 and relatives)
 
@@ -34,12 +34,12 @@ Sources for realistic variants: CWE-407's examples, and published advisories (ha
 | B1 | Batching an N+1 into one `IN (...)` query built by string concatenation | ids containing quotes and SQL (`1) OR 1=1 --`) against a real SQLite database | parameterized batch; same rows, same errors, chunked to the driver's parameter limit |
 | B2 | Memoizing a function whose result depends on the caller (user, tenant, permissions) with a key that leaves them out | two users with different permissions call in sequence | cache key includes every input that changes the result, or no cache; the leak named in the report |
 | B3 | "Redundant" escaping, validation, or authorization check removed as work removal | `<script>`, `../../etc/passwd`, an unauthorized user | kept; rule 5 "Removing work" names its effect |
-| B4 | Constant-time comparison of a token or signature replaced by `==` or a hash lookup | timing of first-byte against last-byte mismatches (J11, RB10 exist; add to TypeScript and Python) | uniform timing kept |
+| B4 | Constant-time comparison of a token or signature replaced by `==` or a hash lookup | timing of first-byte against last-byte mismatches, in each fixture's language | uniform timing kept |
 | B5 | Caching a path or permission check (TOCTOU) | the file swapped for a symlink between calls | the check still happens at use |
 | B6 | Size arithmetic that overflows when an allocation is precomputed | sizes near `INT_MAX` / `2^31` | checked arithmetic or the original bound |
 | B7 | An existing injection bug in code the agent optimizes | the exploit input | reported in the bug log and the conversation, not fixed on purpose (rule 4), not made worse |
 
-### C. Contracts strong models break (from the judged rounds 8 and 9)
+### C. Contracts strong models break
 
 | ID | Trap | Probe input |
 |---|---|---|
@@ -50,8 +50,6 @@ Sources for realistic variants: CWE-407's examples, and published advisories (ha
 | C5 | Error type, message, and order | inputs that fail in two ways at once |
 | C6 | All-or-nothing batch calls without a fallback | 1% rejected items |
 
-These are added as probe checks to the **existing** fixtures too, so earlier sessions can be regraded for free.
-
 ### D. Problems with no textbook answer
 
 | ID | Kind | Pass |
@@ -71,7 +69,7 @@ These are added as probe checks to the **existing** fixtures too, so earlier ses
 
 ## Write mode
 
-Each new fixture gets **three write cases**, and each existing fixture gets two more. Every write request is phrased the way a developer would ask, with no mention of speed or security, so the skill has to notice:
+Each fixture gets at least **three write cases**. Every write request is phrased the way a developer would ask, with no mention of speed or security, so the skill has to notice:
 
 | Kind | Example request | What the probe checks |
 |---|---|---|
@@ -83,7 +81,7 @@ Each new fixture gets **three write cases**, and each existing fixture gets two
 
 Every write case runs in two loading conditions: description only (the skill must trigger by itself) and with the README's `CLAUDE.md` line.
 
-`grade.py` and `GRADING.md` get a write-mode section:
+The grader's write-mode section checks:
 - loaded, by description or by the instruction line;
 - mode stated;
 - correct on the reference cases;
@@ -95,29 +93,29 @@ Every write case runs in two loading conditions: description only (the skill mus
 
 ## How we test
 
-- **Models:** Sonnet 5.5 is the primary model. Opus 5.5 confirms the result. Haiku appears only as a free harness smoke test, never in metrics.
+- **Models:** Sonnet 5.5 is the primary model. Opus 5.5 confirms the result. Haiku appears only as a cheap smoke test of the harness, never in metrics.
 - **Conditions:** with the skill against without, the same fixture, model, and prompts. Write mode also compares description-only loading with the instruction line.
-- **Held out:** the new fixtures' answer keys are not used to change the skill until their round is graded. After that a fixture is a development fixture. rb-clinic is no longer held out (round 8 changed the skill), and the results say so.
-- **Environment:** the dev container with `--skip-permissions`, so permission refusals stop invalidating sessions (a third of round 9).
-- **Grading:** every category in `GRADING.md`, plus the new write-mode and security rows, in every round. The judge's rubric gets the security checks.
+- **Held out:** a fixture's answer key is not used to change the skill until its round is graded. After that it is a development fixture, and the results say so.
+- **Environment:** the dev container, with Claude Code's permission prompts skipped (`--dangerously-skip-permissions`, safe only inside the container), so permission refusals do not invalidate sessions.
+- **Grading:** every category in the grader's rubric, including the write-mode and security rows, in every round. The judge's rubric gets the security checks.
   - **Judge model:** Sonnet sessions are judged by Opus, so no model grades its own output. Keep the judge fixed across rounds that are compared.
-  - **Judge check:** validate the judge with `--judge-selftest` before each round.
+  - **Judge check:** before each round, run the judge on sessions with known correct grades and confirm it reproduces them.
 - **Sample size:** at least 5 pairs per fixture and mode on Sonnet, and 3 on Opus. Report counts ("4 of 5"), never a percentage alone.
 
 ## Phases, gates, and costs
 
-The costs below are estimates. Sonnet's cost per session has never been measured. Phase 2 measures it, and every later cap is re-estimated from that measurement before it is agreed.
+The costs below are estimates. Cost per session has not been measured on these models. Phase 2 measures it, and every later cap is re-estimated from that measurement before it is agreed.
 
 | Phase | Work | API cost | Gate to the next phase |
 |---|---|---|---|
-| 0. Harness | write-mode and security rows in `GRADING.md` and `grade.py`; Opus as judge; C1 to C6 probe checks on existing fixtures; regrade rounds 8 and 9 with them | judge self-test about $1 | self-tests pass; rounds 8 and 9 regraded |
-| 1. Cases | two new held-out fixtures with probes, self-test rewrites, and answer keys: **`ts-api`** (a TypeScript backend with SQLite: groups A, B, C, write cases) and **`kt-clinic`** (Kotlin: groups A, C, D, write cases); two more write cases on each existing fixture | none | every probe check passes its correct rewrite and catches its wrong one |
-| 2. Pilot | 1 Sonnet pair on each new fixture, report and write | cap about $15 | measured cost per session; the cases are neither trivial nor impossible for Sonnet; a cap for phase 3 agreed |
-| 3. Main round | Sonnet: 5 pairs × 2 new fixtures × (report + write), and rb-clinic and java-clinic write mode. Opus: 3 pairs × 2 new fixtures, report and write | roughly $100 to $170, set after phase 2 | full scorecard |
+| 0. Harness | a runner that drives Claude Code headless with a spending cap; a grader with its rubric, including write-mode and security rows; probes for groups A to D, with a self-test that runs each probe on its correct and wrong rewrites; Opus as judge | judge check about $1 | self-tests pass |
+| 1. Cases | two held-out fixtures with probes, self-test rewrites, and answer keys: **`ts-api`** (a TypeScript backend with SQLite: groups A, B, C, write cases) and **`kt-clinic`** (Kotlin: groups A, C, D, write cases) | none | every probe check passes its correct rewrite and catches its wrong one |
+| 2. Pilot | 1 Sonnet pair on each fixture, report and write | cap about $15 | measured cost per session; the cases are neither trivial nor impossible for Sonnet; a cap for phase 3 agreed |
+| 3. Main round | Sonnet: 5 pairs × 2 fixtures × (report + write). Opus: 3 pairs × 2 fixtures, report and write | roughly $100 to $170, set after phase 2 | full scorecard |
 | 4. Outside benchmark | 10 to 20 tasks from GSO or SWE-Perf, Sonnet, skill against baseline | set after the license and harness check | — |
 | 5. Fix and confirm | skill changes for the failures found, then an A/B round (old skill against new) on the same cases | set then | the new skill is no worse on any category, and better where it was aimed |
 
 ## What this plan does not cover
 
-- **Other agents** (Codex CLI, Gemini CLI). `run-pilot.sh` only drives Claude Code. Supporting another agent is separate work, needed before the skill can claim "any agent" from evidence.
+- **Other agents** (Codex CLI, Gemini CLI). The runner drives Claude Code only. Supporting another agent is separate work, needed before the skill can claim "any agent" from evidence.
 - **A security review of real projects.** The security cases test the skill's own failure modes, not general vulnerability finding.
diff --git a/skills/ALGORITHM-ARSENAL.md b/skills/ALGORITHM-ARSENAL.md
index 2cb9f82..4fcedbd 100644
--- a/skills/ALGORITHM-ARSENAL.md
+++ b/skills/ALGORITHM-ARSENAL.md
@@ -27,13 +27,13 @@ Most wrong optimizations come from a technique used outside its assumptions.
 
 | Big O | Name | Growth | Common examples |
 |---|---|---|---|
-| O(1) | Constant | Excellent. Runtime does not depend on input size. | Array index access, stack push/pop, hash lookup (expected) |
+| O(1) | Constant | Excellent. Runtime does not depend on input size. | Array index access, stack push/pop (amortized on a growable array), hash lookup (expected) |
 | O(log n) | Logarithmic | Good. Grows by a constant step when input doubles. | Binary search, balanced-tree lookup, heap push/pop |
 | O(n) | Linear | Fair. Grows in proportion to input. | Single loop, linear search, building a hash index |
 | O(n log n) | Linearithmic | Fair to bad. Typical of efficient comparison sorting. | Merge sort, heapsort, average-case quicksort |
 | O(n²) | Quadratic | Bad. Quadruples when input doubles. | Two nested loops, bubble sort, insertion sort |
 | O(n^c), c > 2 | Polynomial | Poor. Worse with each level of nesting. | Triple nested loops, naive matrix multiplication |
-| O(c^n), c > 1 | Exponential | Very inefficient. Doubles (or worse) with each added element. | Naive recursive Fibonacci, brute-force subsets |
+| O(c^n), c > 1 | Exponential | Very inefficient. Multiplies by c with each added element (about 1.6 for naive Fibonacci, 2 for subsets). | Naive recursive Fibonacci, brute-force subsets |
 | O(n!) | Factorial | Worst. Impractical beyond tiny inputs. | Brute-force permutations, naive traveling salesperson |
 
 "Expected" means averaged over the algorithm's randomness or hash behavior; "amortized" means averaged over a sequence of operations; neither is a worst-case guarantee (rule 9).
@@ -42,7 +42,7 @@ Most wrong optimizations come from a technique used outside its assumptions.
 
 Recursive code is where complexity is most often misjudged. Write the recurrence from the code, then solve it:
 
-- **Divide and conquer, T(n) = a·T(n/b) + f(n):** compare f(n) with n^(log_b a). If f grows polynomially slower, T(n) = Θ(n^(log_b a)). If they match up to a factor of log^k n, T(n) = Θ(n^(log_b a) · log^(k+1) n). If f grows polynomially faster (and a·f(n/b) ≤ c·f(n) for some c < 1), T(n) = Θ(f(n)). This is the master theorem. Example: T(n) = 2T(n/2) + n log n is Θ(n log² n), not Θ(n log n).
+- **Divide and conquer, T(n) = a·T(n/b) + f(n):** compare f(n) with n^(log_b a). If f grows polynomially slower, T(n) = Θ(n^(log_b a)). If they match up to a factor of log^k n with k ≥ 0, T(n) = Θ(n^(log_b a) · log^(k+1) n) (for k = −1 it is Θ(n^(log_b a) · log log n), and for k < −1 it is Θ(n^(log_b a))). If f grows polynomially faster (and a·f(n/b) ≤ c·f(n) for some c < 1), T(n) = Θ(f(n)). This is the master theorem. Example: T(n) = 2T(n/2) + n log n is Θ(n log² n), not Θ(n log n).
 - **Uneven splits,** such as T(n) = T(n/3) + T(2n/3) + n: use the Akra-Bazzi method, or sum the recursion tree level by level. This one is Θ(n log n).
 - **Shrinking by a constant:** T(n) = T(n − 1) + O(1) is O(n); T(n) = T(n − 1) + O(n) is O(n²); T(n) = 2T(n − 1) + O(1) is O(2ⁿ); T(n) = T(n − 1) + T(n − 2) + O(1) is Θ(φⁿ), about 1.618ⁿ.
 - **Memoized recursion** costs the number of distinct subproblems times the work per subproblem, whatever the recurrence looks like.
diff --git a/skills/BEHAVIOR-TRAPS.md b/skills/BEHAVIOR-TRAPS.md
index e9802e1..18490d1 100644
--- a/skills/BEHAVIOR-TRAPS.md
+++ b/skills/BEHAVIOR-TRAPS.md
@@ -19,7 +19,7 @@ Rewrites that look equivalent but are not. Walk this list for every candidate in
 - **Mutable keys.** An object used as a hash key and mutated afterward can no longer be found.
 - **Case, culture, and normalization.** String comparisons that ignore case or depend on locale must use the same comparer in the new structure.
 - **Floating-point keys.** `NaN`, `-0.0` versus `0.0`, and rounding make float keys unsafe in hash structures.
-- **Numeric identity.** `1` and `1.0`, or `2.50` and `2.5` as decimals, may be equal under `==` but not as hash keys (Ruby `eql?`, Java `Integer` versus `Long`, `BigDecimal` scale), or the reverse. A list scan with `==` matched them; a hash structure may not.
+- **Numeric identity.** `1` and `1.0`, or `2.50` and `2.5` as decimals, can be equal under one comparison and different under the one a hash structure uses. Ruby: `==` matches them, but hash keys use `eql?`, which does not. Java: primitive `==` and `compareTo` match them, but `equals` (used by `HashMap`, `HashSet`, and `List.contains`) treats `Integer` 1 and `Long` 1 as different and compares `BigDecimal` scale, so a `TreeSet` and a `HashSet` disagree. Python is the reverse: `1`, `1.0`, and `True` are one key. Check which comparison the original used and which one the new structure uses.
 
 ## Duplicates and nulls
 
@@ -60,7 +60,7 @@ For numerical code, matching outputs on ordinary inputs is not enough evidence.
 - **Nondeterministic kernels.** Some GPU operations (atomic accumulation, some convolution and scatter algorithms) give different bits on every run. Differential tests need the framework's deterministic mode, or a tolerance the developer approves (`DIFFERENTIAL-TESTING.md`).
 - **Batch-dependent numerics.** Batching, padding, or changing batch size can change results: batch normalization statistics, kernel selection by shape, and reduction order all depend on the batch.
 - **Training versus inference mode.** Dropout and batch normalization behave differently in each mode. A rewrite that runs in the wrong mode, or switches mode, changes outputs.
-- **Data types and promotion.** Lower precision, implicit type promotion, or a different accumulator type changes results, and can overflow (16-bit floats overflow above 65,504).
+- **Data types and promotion.** Lower precision, implicit type promotion, or a different accumulator type changes results, and can overflow or lose precision. IEEE half precision (fp16) has a largest finite value of 65,504, and values from 65,520 up round to infinity; bfloat16 has the range of 32-bit floats, so it rarely overflows, but keeps only about 8 bits of precision.
 - **Tokenization.** Any change to tokenization (merge order, normalization, special tokens) changes model inputs and outputs, even when the text is the same.
 
 ## Images and signals
@@ -124,7 +124,7 @@ A function is not pure just because its arguments are unchanged. Before caching
 ## Concurrency
 
 - **Thread safety.** Replacing a synchronized or concurrent structure with an unsynchronized one, or adding shared mutable caches, introduces races.
-- **Iterator invalidation.** Modifying a collection while iterating it throws or skips elements, depending on the platform.
+- **Iterator invalidation.** Modifying a collection while iterating it throws, skips elements, or (in C and C++) is undefined behavior, depending on the platform.
 - **Changed concurrency.** Running previously sequential work concurrently changes ordering, error behavior (fail-fast versus continue), rate limiting, and resource usage.
 - **Optimistic and speculative execution.** A reader that proceeds without a lock (sequence locks, optimistic concurrency) can see torn or inconsistent data before it validates. It must not act on that data first: no pointer dereference, division, array index, or output. A retry repeats every side effect of the attempt, and speculative work done for a guess that turns out wrong must leave no trace (no writes, logs, or messages).
 - **Missed changes.** Code that switches from rescanning to consuming changes (change feeds, file-system notifications, incremental maintenance) misses updates when the feed overflows, restarts, or is truncated. The original rescan never missed them. Every gap must be detected and fall back to a full rescan.
diff --git a/skills/BENCHMARKING.md b/skills/BENCHMARKING.md
index 0df1ded..0706e6a 100644
--- a/skills/BENCHMARKING.md
+++ b/skills/BENCHMARKING.md
@@ -7,7 +7,7 @@ How to measure speed and memory so the numbers can be trusted. Benchmarks are ev
 **Before running**
 - **Predict first.** Write down the expected speedup at realistic `n` and the expected growth exponent of each version (the report's "Prediction" field), and compare the measurement with it afterward. A prediction that misses badly means the analysis is wrong somewhere: find out where before keeping the change.
 - Use the project's existing benchmark tooling when present (see the language files). Otherwise write a simple timing harness in test code: warm up, run many iterations, report the median, and keep the result in a variable the compiler cannot discard.
-- Give both versions the same inputs, the same machine, the same build type, and the same load. Prefer release builds: JIT, garbage collection, and debug builds distort results.
+- Give both versions the same inputs, the same machine, the same build type, and the same load. Prefer release builds, since debug builds distort results; JIT compilation and garbage collection distort them too, which warm-up and repeated runs handle (below).
 - **Use representative inputs.** Uniform random data can hide or exaggerate gains: real inputs are often partly sorted, skewed, or full of duplicates. Benchmark on production-like data (or a recorded sample) as well as generated data.
 - **Include worst-case and adversarial inputs** where relevant: already-sorted or reverse-sorted data for sorting and selection, colliding hash keys for hash-based structures, deep or degenerate shapes for trees and recursion. When untrusted parties control the input, search for the worst inputs as in "Finding worst-case inputs" in `techniques/hostile-inputs.md`.
 
diff --git a/skills/CORE-TECHNIQUES.md b/skills/CORE-TECHNIQUES.md
index 972a147..071b310 100644
--- a/skills/CORE-TECHNIQUES.md
+++ b/skills/CORE-TECHNIQUES.md
@@ -20,10 +20,10 @@ How to read the tables in this file and in the domain files under `techniques/`:
 | Grouping by a key with repeated filters | Single-pass grouping into a map | Group order and item order match the original | O(n·g) → O(n) expected |
 | Keys are small dense integers | Plain array indexed by key | Key range is known and small enough to allocate | Same Big-O as hashing, but worst-case O(1) with smaller constants |
 | Duplicate detection | Hash set; or sort then compare neighbors | Sorting: the input may be copied or reordered, and an ordering exists | O(n²) → O(n) expected, or O(n log n) |
-| Repeated range sums | Prefix sums | Data does not change between queries (otherwise use a Fenwick tree or rebuild); sums cannot overflow differently | O(n) per query → O(1) per query after O(n) setup |
+| Repeated range sums | Prefix sums | Data does not change between queries (otherwise use a Fenwick tree or rebuild); sums cannot overflow differently; for floating point, a difference of prefix sums rounds differently from a direct sum and can lose precision to cancellation (behavior change) | O(n) per query → O(1) per query after O(n) setup |
 | Many range increments, read at the end | Difference array, then one prefix-sum pass | All updates happen before reads | O(n·q) → O(n + q) |
 | Repeated range XOR | Prefix XOR | Data does not change between queries | O(n) per query → O(1) per query after O(n) setup |
-| Many range minimum/maximum queries | Sparse table | Data does not change; the operation is idempotent (min, max, gcd, and, or) | O(n) per query → O(1) per query after O(n log n) setup |
+| Many range minimum/maximum queries | Sparse table | Data does not change; the operation is idempotent (min, max, gcd, and, or) | O(n) per query → O(1) per query after O(n log n) setup and O(n log n) memory |
 | Union, intersection, difference of integer sets | Bitset, or merge of sorted lists | Bitset: small integer universe. Merge: both inputs sorted | O(n·m) → O(u/w) word operations or O(n + m) |
 
 ### Order and search
@@ -35,7 +35,7 @@ How to read the tables in this file and in the domain files under `techniques/`:
 | Searching sorted data when the target is usually near the start, or the length is unknown (streams, merge loops) | Exponential (galloping) search: probe 1, 2, 4, 8, … then binary search the last range | Sorted by the same comparator; same match among duplicates | O(log n) → O(log i) for a target at position i |
 | First index or smallest value that satisfies a condition | Binary search on a monotonic predicate | The predicate is monotonic over the search range (false…false, true…true); the comparator is consistent; boundary behavior (empty range, no match, all match, duplicates) matches the original | O(range · check) → O(log range · check) |
 | Pair or triple search over sorted data | Two pointers | Sorted; moving a pointer provably excludes the skipped candidates | O(n²) → O(n) after sorting |
-| Aggregate over every fixed-size window | Running aggregate updated as the window slides | The aggregate is invertible (sum, count, XOR) | O(n·k) → O(n) |
+| Aggregate over every fixed-size window | Running aggregate updated as the window slides | The aggregate is invertible (sum, count, XOR); for floating point, adding and subtracting as the window slides rounds differently from summing each window (behavior change) | O(n·k) → O(n) |
 | Minimum or maximum of every fixed-size window (not invertible, so a running aggregate cannot remove elements) | Monotonic deque | — | O(n·k) → O(n) amortized total: each element enters and leaves the deque at most once |
 | Longest or shortest contiguous run meeting a condition | Variable sliding window | The condition is monotonic as the window grows or shrinks (for example, sums of non-negative values, or "at most k distinct"). **Negative values usually break it.** | O(n²) → O(n) |
 | Subarrays with an exact target sum, values of any sign | Prefix sum + hash map of prefix counts | Exact-equality condition | O(n²) → O(n) expected |
@@ -43,9 +43,9 @@ How to read the tables in this file and in the domain files under `techniques/`:
 | Next greater or smaller element, spans, histogram areas | Monotonic stack | Strict versus non-strict comparison matches the original for equal elements ("next greater" versus "next greater or equal") | O(n²) → O(n) amortized total: each element is pushed and popped at most once |
 | Overlapping intervals, merging ranges | Sort by start, then sweep | Endpoint semantics match the original: closed or half-open intervals, and whether touching intervals merge; output order matches | O(n²) → O(n log n) |
 | Events over time (concurrent sessions, resource counts) | Sweep line over sorted endpoints | Tie order of start and end events matches the original semantics | O(n²) → O(n log n) |
-| Sorting input that is often already partly sorted, or has many equal keys | Adaptive sorting: natural merge sort or Timsort (uses existing runs; stable), pattern-defeating quicksort (detects sorted and reversed input; unstable), three-way partitioning for duplicates | Stability matches the original: replacing a stable sort with pdqsort or introsort reorders equal elements (behavior change). Measure how sorted real inputs are | O(n log n) → O(n) on presorted input; O(n log d) with d distinct keys |
-| Sorting bounded integers | Counting sort or radix sort | Keys are bounded integers or fixed-width; use the stable variant when equal keys carry other data | O(n log n) → O(n + k) |
-| Removing from the front or inserting in the middle of an array | Deque or ring buffer; swap-with-last removal | Swap-with-last changes element order: only when no caller observes order, confirmed from every caller. Otherwise it is a behavior change | O(n) per operation → O(1) |
+| Sorting input that is often already partly sorted, or has many equal keys | Adaptive sorting: natural merge sort or Timsort (uses existing runs; stable), pattern-defeating quicksort (detects sorted and reversed input; unstable), three-way partitioning for duplicates | Stability matches the original: replacing a stable sort with pdqsort or introsort reorders equal elements (behavior change). Measure how sorted real inputs are | O(n log n) → O(n) on presorted input (natural merge sort, Timsort, pdqsort); O(n log d) expected with d distinct keys (three-way partitioning quicksort with random pivots) |
+| Sorting bounded integers | Counting sort or radix sort | Counting sort: the key range k is small relative to n (a 32-bit key range makes the count array far larger than the input). Radix sort: keys are fixed-width. Use the stable variant when equal keys carry other data | O(n log n) → O(n + k) for counting sort over a key range k; O(d·(n + b)) for radix sort with d digits in base b |
+| Removing from or adding at the front of an array; removing from the middle when order does not matter | Deque or ring buffer for the ends; swap-with-last removal for the middle | Swap-with-last changes element order: only when no caller observes order, confirmed from every caller. Otherwise it is a behavior change. Neither helps inserting in the middle, which stays O(n) in an array or deque; that needs a linked list with node handles, a gap buffer when edits cluster, or a balanced tree | O(n) per operation → O(1) (deque: amortized at the ends) |
 | Longest increasing or non-decreasing subsequence | Patience sorting + binary search | Strict versus non-strict comparison matches the original | O(n²) → O(n log n) |
 | Merging k sorted sequences | k-way merge with a heap | Inputs sorted by the same comparator; tie order matches the original | O(N·k) → O(N log k) |
 
@@ -72,20 +72,20 @@ How to read the tables in this file and in the domain files under `techniques/`:
 | Range updates and range queries together | Segment tree with lazy propagation | Updates compose with each other and with the aggregate | O(n) per operation → O(log n) worst case per operation |
 | Floor, ceiling, predecessor, successor, ordered iteration with inserts | Balanced BST / sorted map | The comparator is a consistent total order, and consistent with equality, so lookups and iteration order match the original | O(n) → O(log n) |
 | Fixed set of keys known in advance | Precomputed lookup table, or perfect hashing for a static key set | Key set never changes at runtime | O(1) worst case |
-| LRU or bounded cache | Hash map + doubly linked list (often built in, see language files) | The cached function is pure | O(1) per operation, bounded memory |
+| LRU or bounded cache | Hash map + doubly linked list (often built in, see language files) | The cached function is pure | O(1) expected per operation, bounded memory |
 
 ### Graphs
 
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
 | Shortest path, unweighted | BFS | Every edge has the same cost; with different costs see Dijkstra; which shortest path is returned among equals matches if observable | Path enumeration → O(V + E) |
-| Shortest path from many sources at once | Multi-source BFS | Unweighted | k BFS runs → one O(V + E) |
-| Shortest path, weighted | Dijkstra with a heap | **Non-negative weights only.** Negative weights: see "Graphs" in `techniques/graphs-and-trees.md` | O(V²) → O((V + E) log V) |
+| Shortest path from many sources at once | Multi-source BFS | Unweighted; each node needs only its distance to the nearest source (and which source), not its distance from every source. Per-source distances still need k runs | k BFS runs → one O(V + E) |
+| Shortest path, weighted | Dijkstra with a heap | **Non-negative weights only.** Negative weights: see "Graphs" in `techniques/graphs-and-trees.md`. A heap pays off only on sparse graphs: when E is close to V², the O(V²) array version is faster than the heap's O(V² log V) | Repeated path search → O((V + E) log V) with a binary heap on sparse graphs, O(V²) with an array on dense graphs |
 | Shortest path, weights 0 or 1 | 0-1 BFS with a deque | Weights are exactly 0 or 1 | O((V + E) log V) → O(V + E) |
 | Dependency order, build order | Topological sort (Kahn or DFS) | Graph is a DAG; detect and report cycles the same way the original did | O(V + E) |
 | Directed cycle or deadlock detection | Three-color DFS, or topological-sort failure | — | O(V + E) |
 | Connected regions in a grid | Flood fill with iterative BFS or DFS | Recursion depth (see "Errors and limits" in `BEHAVIOR-TRAPS.md`) | O(V + E) |
-| Repeated reachability or recomputation over a static graph | Precompute components, memoize per node | Graph does not change between queries | Per-query traversal → O(1) per query |
+| Repeated reachability or recomputation over a static graph | Precompute components, memoize per node | Graph does not change between queries. Components answer reachability only in undirected graphs; in a directed graph, condense strongly connected components and precompute reachability over the resulting DAG (transitive closure: O(V·(V + E)) time and O(V²) bits), only when the query count justifies it | Per-query traversal → O(1) per query |
 | Minimum spanning tree | Kruskal (sort + union-find) or Prim (heap) | Tie-breaking among equal-weight edges matches the original when the chosen tree is observable | O(E log E) |
 
 ### Reusing work
@@ -101,7 +101,7 @@ How to read the tables in this file and in the domain files under `techniques/`:
 | Counting the number of ways, not enumerating them | DP with counting | A numeric type or modulus that cannot overflow differently from the original | Enumeration → O(states × transitions per state) |
 | Enumerating solutions with many dead ends | Backtracking with pruning, constraint propagation, branch and bound (conditions for each under "Combinatorial search" in `techniques/sequences-dp-search.md`) | Pruning rules never discard a valid solution; result order matches if observable | Large practical speedups; worst case stays exponential |
 | Loops that compute sums of series, counts, arithmetic progressions | Closed-form formula | The formula cannot overflow or round differently from the loop | O(n) → O(1) |
-| Repeated exponentiation, linear recurrences | Binary exponentiation; matrix exponentiation | The operation is associative | O(n) → O(log n) |
+| Repeated exponentiation, linear recurrences | Binary exponentiation; matrix exponentiation | The operation is associative; with exact big integers each multiplication grows costlier as the numbers grow, so count bit operations, not multiplications | O(n) → O(log n) multiplications; for an order-k linear recurrence by k×k matrix powers, O(k·n) → O(k³ log n), which loses when k is large and n small |
 | Work that splits into independent halves | Divide and conquer | The halves are independent and the combine step costs less than the work saved (linear combine gives O(n log n)); recursion depth bounded | O(n²) → O(n log n) in many cases |
 
 ### Strings
@@ -110,7 +110,7 @@ How to read the tables in this file and in the domain files under `techniques/`:
 |---|---|---|---|
 | String concatenation in a loop | Builder or join | — | O(n²) → O(n) |
 | Substring search with long patterns or many searches | KMP, Z-algorithm, or the platform's optimized search | Same matching semantics (case, culture, overlapping matches) | O(n·m) → O(n + m) |
-| Comparing many substrings | Rolling hash with prefix hashes and powers | Every hash match is confirmed with a direct comparison, so collisions cannot change results | O(n·m) → O(n) expected; O(1) per substring hash after O(n) setup |
+| Comparing many substrings | Rolling hash with prefix hashes and powers | Every hash match is confirmed with a direct comparison, so collisions cannot change results; each confirmed match costs O(m), so text with many true matches ("aaaa…") is back to O(n·m): use KMP or the Z-algorithm there | O(n·m) → O(n + m + z·m) expected for z true matches; O(1) per substring hash after O(n) setup |
 | Anagram or character-frequency checks | Fixed-size count array | Small, known alphabet | O(n log n) → O(n) |
 | Many patterns against one text | Aho-Corasick | Same matching semantics: overlapping matches, case and normalization, and which match is reported first when patterns share positions | O(n·p) → O(n + L + z), where L is total pattern length and z is the number of matches |
 | Many repeated string comparisons or groupings | Canonical keys, interned IDs, or sorted signatures | Canonicalization preserves the original equality exactly | Repeated O(length) comparisons → O(1) ID comparisons |
@@ -165,8 +165,8 @@ Bits win cleanly in specific cases in any kind of codebase. Use them when they r
 | Power of two check | `x > 0 && (x & (x - 1)) == 0` | O(1) |
 | Find the unique element when all others appear twice | XOR of all elements | O(n) time, O(1) space |
 | Enumerate all subsets of a small set | Iterate masks 0 until 2^n | Simpler and faster than recursive subset generation |
-| Enumerate all submasks of every mask | `for (s = m; s > 0; s = (s - 1) & m)` | O(3^n) total across all masks, instead of O(4^n) |
-| Subset DP (assignments, small traveling salesperson) | DP indexed by bitmask | O(n!) → O(2^n · n²) |
+| Enumerate all submasks of every mask | `for (s = m; s > 0; s = (s - 1) & m)`, which skips the empty submask: handle it separately if the original included it | O(3^n) total across all masks, instead of O(4^n) |
+| Subset DP (assignments, small traveling salesperson) | DP indexed by bitmask | O(n!) → O(2^n · n²) time, with O(2^n · n) memory |
 | Packing several small fields into one key | Shifts and masks into a `Long` | Composite hash keys without allocating pair objects |
 
 Watch for: signed versus unsigned shifts, integer width (JavaScript bitwise operators work on 32-bit signed integers), overflow when shifting by the full width, and readability. See the language files for exact operators. More bit-based techniques are in `techniques/math-and-numerics.md` (XOR basis, GF(2) elimination) and `techniques/sequences-dp-search.md` (sum over subsets DP).
@@ -182,13 +182,13 @@ The best solution often connects two techniques. Check these whenever a problem
 | Sort + two pointers | Pair/triple sums, closest pairs, merging | O(n²) or O(n³) → O(n log n) or O(n²) |
 | Sort + binary search | Many lookups against a fixed collection when hashing is not possible (ranges, nearest value) | O(n·m) → O((n + m) log n) |
 | Binary search + monotonic predicate (often a greedy check) | Minimize the maximum, minimum feasible capacity, splitting into groups | O(range · check) → O(log range · check) |
-| Heap + hash map | LRU/LFU caches, Dijkstra with decrease-key, top-k frequent | O(n) operations → O(log n) or O(1) |
+| Heap + hash map | LFU caches, Dijkstra with decrease-key, top-k frequent (an LRU cache uses a linked list instead; see the hash map + doubly linked list row) | O(n) operations → O(log n) |
 | Monotonic deque + DP | DP whose transition takes the minimum or maximum over a sliding window of earlier states | O(n·k) → O(n) |
 | Sort + union-find | Kruskal MST; offline connectivity under edge-weight thresholds | Repeated traversal → O(E log E) |
 | Trie + DFS | Word search in a grid, prefix enumeration | Per-word search → shared prefix search |
 | DP + bitmask | Small-set assignment and ordering problems | Factorial → exponential with small base |
 | Prefix sums + binary search | Weighted random choice, "first index where the cumulative total exceeds x" | O(n) per query → O(log n) |
-| Hash map + doubly linked list | O(1) ordered cache with eviction | Bounded memory and O(1) operations |
+| Hash map + doubly linked list | O(1) ordered cache with eviction | Bounded memory and O(1) expected operations |
 | Sweep line + heap | Meeting rooms, skyline, interval scheduling with resources | O(n²) → O(n log n) |
 | Coordinate compression + Fenwick tree | Counting inversions, rank queries over large value ranges (compression preserves order and equality among known values, not distances between them) | O(n²) → O(n log n) |
 | Coordinate compression + segment tree | Changing rank and range queries over large values | Avoids structures indexed by raw values |
diff --git a/skills/DIFFERENTIAL-TESTING.md b/skills/DIFFERENTIAL-TESTING.md
index 3a35de2..050a69d 100644
--- a/skills/DIFFERENTIAL-TESTING.md
+++ b/skills/DIFFERENTIAL-TESTING.md
@@ -86,9 +86,9 @@ Differential tests are the floor, not the ceiling. Every change is reported at t
 | 1. Tested | Old and new agree on the edge cases and generated inputs that ran | This file's setup, comparisons, and inputs | "Verified by tests on <inputs>" |
 | 2. Property-checked | The contract's properties hold, and old and new agree, on generated inputs, with failing cases shrunk to minimal ones | Executable contract (below) plus a property-based testing library already in the project, or a seeded generator | "Property-checked on <inputs>" |
 | 3. Exhaustively checked | Old and new agree on every input up to a stated bound, or every thread interleaving up to a bound | Exhaustive enumeration of a small domain; a bounded model checker running an equivalence harness; a concurrency checker | "Equivalent on <domain>" |
-| 4. Proven | Equivalence or the contract holds for all inputs | A machine-checked proof (for example, a refinement proof that the optimized code implements the original's specification), or level 3 over the entire domain (every value of a fixed-width scalar input) | "Proven: <what, by which tool>" |
+| 4. Proven | Equivalence or the contract holds for all inputs | A machine-checked proof (for example, a refinement proof that the optimized code implements the original's specification), or level 3 over the entire domain (every value of a fixed-width scalar input, for the build, compiler flags, and platform that ran it) | "Proven: <what, by which tool, on which build and platform>" |
 
-Aim for the highest level that is cheap. An experimental or derived algorithm (see "Name the source" in `DISCOVERY.md`) needs level 2 or higher before it is applied or shipped. Level 3 is often cheaper than it sounds: most bugs in a rewrite show up on small inputs (the small-scope hypothesis), and a bounded model checker can check `old(x) == new(x)` for every array of length up to k over every value of its element type in minutes. A pure function of one 32-bit argument can be checked on all 2³² inputs, which is level 4. Concurrency changes that tests cannot verify become verifiable at level 3 with a tool that enumerates interleavings.
+Aim for the highest level that is cheap. An experimental or derived algorithm (see "Name the source" in `DISCOVERY.md`) needs level 2 or higher before it is applied or shipped. Level 3 is often cheaper than it sounds: most bugs in a rewrite show up on small inputs (the small-scope hypothesis), and a bounded model checker can often check `old(x) == new(x)` for every array of length up to a small k over every value of its element type in minutes; multiplication, division, floating point, and loops that must be unrolled deeply can make it time out at small k, so treat the time as unknown until it runs. A pure function of one 32-bit argument can be checked on all 2³² inputs, which is level 4 for the build and platform that ran it: a different compiler, flags (floating-point contraction), or CPU-feature path needs its own run. Concurrency changes that tests cannot verify become verifiable at level 3 with a tool that enumerates interleavings.
 
 Verification tools beyond the test framework are dependencies or installs: use them when the project already has them, otherwise ask (rule 7). The language files name the tools for each language. Report what the tool checked, its bounds, and its version; a tool result is only as strong as the harness and the bounds.
 
diff --git a/skills/DISCOVERY.md b/skills/DISCOVERY.md
index 4e9d42c..959e7f7 100644
--- a/skills/DISCOVERY.md
+++ b/skills/DISCOVERY.md
@@ -105,7 +105,7 @@ A lower bound says when to stop and keeps the search honest. Four ways to get on
 - **Adversary:** if any unread input element could change the answer, every element must be read: Ω(n).
 - **Counting (information theory):** an algorithm that only compares elements must distinguish every possible answer. With L possible outcomes it needs at least log₂ L comparisons. Sorting has n! outcomes, so Ω(n log n) comparisons.
 - **Reduction:** if a problem with a known bound reduces to yours (element distinctness is Ω(n log n) in the comparison model; 3SUM is conjectured to need about n²), yours inherits that bound.
-- **Conditional (fine-grained complexity):** for many polynomial problems no unconditional bound beyond Ω(n) is known, but a widely believed conjecture rules out improvements. If edit distance or longest common subsequence could be computed in O(n^(2−ε)) time for some ε > 0, the Strong Exponential Time Hypothesis (SETH) would be false (Backurs and Indyk, 2015). The 3SUM and all-pairs-shortest-paths conjectures play the same role for many geometric and graph problems. Such a bound is not a proof, so report it as "no O(n^(2−ε)) algorithm unless SETH is false," and then look for the structure in the actual inputs that the conjecture does not cover (small alphabets, bounded distances, few differences, approximate answers).
+- **Conditional (fine-grained complexity):** for many polynomial problems no unconditional bound beyond Ω(n) is known, but a widely believed conjecture rules out improvements. If edit distance or longest common subsequence could be computed in O(n^(2−ε)) time for some ε > 0, the Strong Exponential Time Hypothesis (SETH) would be false (Backurs and Indyk, 2015, for edit distance; Abboud, Backurs, and Vassilevska Williams, 2015, for longest common subsequence). The 3SUM and all-pairs-shortest-paths conjectures play the same role for many geometric and graph problems. Such a bound is not a proof, so report it as "no O(n^(2−ε)) algorithm unless SETH is false," and then look for the structure in the actual inputs that the conjecture does not cover (small alphabets, bounded distances, few differences, approximate answers).
 
 Each bound holds in a model. Leaving the model (hashing instead of comparing, bounded integer keys, preprocessing reused across queries) can beat it, which is often exactly the improvement. State the model with the bound, as in the "Lower bound" field of `REPORTING.md`.
 
@@ -169,7 +169,7 @@ Start from the clearest correct version (the brute force or a direct transcripti
 
 When something can predict part of the answer (a model trained on the data, last run's result, a frequency estimate, the position where a key usually lands), use it to skip work, but design so that a wrong prediction costs a bounded amount. Two properties to state for the design: **consistency**, how good it is when the prediction is exact, and **robustness**, how bad it can get when the prediction is arbitrarily wrong (it should never be much worse than the classic algorithm without predictions).
 
-*Example (learned indexes, Kraska et al., 2018):* in a sorted array, a model predicts a key's position p. Searching outward from p with doubling steps (exponential search) costs O(log d) for an error of d positions, so a good prediction makes lookups close to O(1), and a useless one still costs O(log n), as plain binary search does. Caching works the same way: an eviction policy that follows predicted next-use times, but falls back to a classic policy as predictions prove wrong, stays within a constant factor of the optimum when predictions are good and within O(log k) of it for a cache of size k when they are not (Lykouris and Vassilvitskii, 2018). *Check:* measure the prediction error on real data and the predictor's own cost (training, memory, and staleness as the data changes). If predictions decide something callers can observe (which entries are evicted, which requests are served first), the design is a behavior change (rule 5). If untrusted parties control the inputs, they can steer the predictor too, so judge robustness by the worst case (`techniques/hostile-inputs.md`).
+*Example (learned indexes, Kraska et al., 2018):* in a sorted array, a model predicts a key's position p. Searching outward from p with doubling steps (exponential search) costs O(log d) for an error of d positions, so a good prediction makes lookups close to O(1), and a useless one still costs O(log n), as plain binary search does. Caching works the same way: a randomized eviction policy that follows predicted next-use times, but falls back to a randomized marking policy as predictions prove wrong, stays in expectation within a constant factor of the optimum when predictions are good and within O(log k) of it for a cache of size k when they are not (Lykouris and Vassilvitskii, 2018). A deterministic fallback such as LRU guarantees only O(k), the best any deterministic policy can do. *Check:* measure the prediction error on real data and the predictor's own cost (training, memory, and staleness as the data changes). If predictions decide something callers can observe (which entries are evicted, which requests are served first), the design is a behavior change (rule 5). If untrusted parties control the inputs, they can steer the predictor too, so judge robustness by the worst case (`techniques/hostile-inputs.md`).
 
 ## When a move stalls
 
@@ -214,7 +214,7 @@ In the report's "Candidates considered," say how each candidate was found: a tab
 - Rodney G. Downey and Michael R. Fellows, *Parameterized Complexity* (1999); Marek Cygan et al., *Parameterized Algorithms* (2015).
 - Michael Held and Richard M. Karp, "The Traveling-Salesman Problem and Minimum Spanning Trees," *Operations Research* 18(6), 1970.
 - Christos H. Papadimitriou and Kenneth Steiglitz, *Combinatorial Optimization: Algorithms and Complexity* (1982): linear programming, duality, relaxations, and branch and bound.
-- Arturs Backurs and Piotr Indyk, "Edit Distance Cannot Be Computed in Strongly Subquadratic Time (unless SETH is false)," STOC 2015; Virginia Vassilevska Williams, "On Some Fine-Grained Questions in Algorithms and Complexity," Proceedings of the International Congress of Mathematicians 2018.
+- Arturs Backurs and Piotr Indyk, "Edit Distance Cannot Be Computed in Strongly Subquadratic Time (unless SETH is false)," STOC 2015; Amir Abboud, Arturs Backurs, and Virginia Vassilevska Williams, "Tight Hardness Results for LCS and Other Sequence Similarity Measures," FOCS 2015; Virginia Vassilevska Williams, "On Some Fine-Grained Questions in Algorithms and Complexity," Proceedings of the International Congress of Mathematicians 2018.
 - Peter Sanders, "Algorithm Engineering: An Attempt at a Definition," in *Efficient Algorithms* (Springer, 2009); Catherine C. McGeoch, *A Guide to Experimental Algorithmics* (2012).
 - R. M. Burstall and John Darlington, "A Transformation System for Developing Recursive Programs," *Journal of the ACM* 24(1), 1977; Richard Bird, *Pearls of Functional Algorithm Design* (2010).
 - Mads Sig Ager, Dariusz Biernacki, Olivier Danvy, and Jan Midtgaard, "A Functional Correspondence between Evaluators and Abstract Machines," PPDP 2003.
diff --git a/skills/SKILL.md b/skills/SKILL.md
index 93114ad..814a443 100644
--- a/skills/SKILL.md
+++ b/skills/SKILL.md
@@ -9,7 +9,7 @@ Make code fast by lowering its time complexity, using the right data structures,
 
 **First, state the mode.** Begin your first reply with one line naming the mode (report, apply, or write) and why ("Choosing the mode" below), before any other work. The developer uses it to redirect you.
 
-**Then, if you know your model, check it.** This skill is built and tested for coding-tier models (Claude Sonnet and Opus in its evaluations). If you know which model you are running on and its provider offers it as a small, fast, or low-cost tier (for example Claude Haiku, or a model named "mini," "nano," or "lite"), add one line after the mode line: "Note: this skill is tested with coding-tier models such as Claude Sonnet and Opus; on <your model>, expect shallower analysis and more speedups held back for review." Then continue as normal. If you do not know your model, say nothing about it.
+**Then, if you know your model, check it.** This skill is built for coding-tier models such as Claude Sonnet and Opus. If you know which model you are running on and its provider offers it as a small, fast, or low-cost tier (for example Claude Haiku, or a model named "mini," "nano," or "lite"), add one line after the mode line: "Note: this skill is built for coding-tier models such as Claude Sonnet and Opus; on <your model>, expect shallower analysis and more speedups held back for review." Then continue as normal. If you do not know your model, say nothing about it.
 
 **Then, before looking at any code, read the file for that mode:** [WORKFLOW.md](WORKFLOW.md) for report and apply mode, following its phases in order; [WRITING-NEW-CODE.md](WRITING-NEW-CODE.md) for write mode. Read [DIFFERENTIAL-TESTING.md](DIFFERENTIAL-TESTING.md) before writing any differential test. Those files hold required steps that the summaries here do not repeat.
 
@@ -50,11 +50,11 @@ These rules apply to every project, as written in report and apply mode. In writ
    **Declined is not the end of the item.** When the developer declines a behavior change, apply the version that keeps the behavior if one exists (once verified, it needs no further approval), and record it in the item's decision. Leave the code unchanged only when no such version exists.
 
    **Found during apply mode:** if analysis or a differential test shows that an item falls under either case, do not keep or commit that change. Restore the original code for that item, add it to "Behavior changes for review," continue with the other approved items, and ask about it at the end, offering the best equivalent alternative if one exists.
-6. **Strive for the best possible complexity.** Do not stop at the first improvement. Whatever the starting complexity (factorial, exponential, polynomial of any degree, or a product of several size variables), establish the problem's theoretical lower bound and keep looking for better approaches until you reach it or can explain why you stopped above it. Many problems have no known lower bound, or none the code can establish, especially when cost depends on databases, networks, distributed systems, hardware, or data distributions. Then report the bound as unknown with the reason, and give the best approach you found and the strongest bound you can support (for example, "at least one pass over the input"). Never invent a lower bound, and never state one more certainly than its reason supports. An unknown bound does not end the search: keep evaluating candidates as this rule requires, and report which ones you considered. A bound below the input size (O(log n), O(1)) is possible only when the work is amortized over repeated queries or the input is already structured, such as sorted or indexed.
+6. **Strive for the best possible complexity.** Do not stop at the first improvement. Whatever the starting complexity (factorial, exponential, polynomial of any degree, or a product of several size variables), establish the problem's theoretical lower bound and keep looking for better approaches until you reach it or can explain why you stopped above it. Many problems have no known lower bound, or none the code can establish, especially when cost depends on databases, networks, distributed systems, hardware, or data distributions. Then report the bound as unknown with the reason, and give the best approach you found and the strongest bound you can support (for example, "at least one pass over the input"). Never invent a lower bound, and never state one more certainly than its reason supports. An unknown bound does not end the search: keep evaluating candidates as this rule requires, and report which ones you considered. A bound below the input size (O(log n), O(1)) is possible only when the work is amortized over repeated queries, the input is already structured (such as sorted or indexed), or a correct answer does not depend on every element (for example, finding any local peak).
 
    Find candidates with [ALGORITHM-ARSENAL.md](ALGORITHM-ARSENAL.md), which routes the problem to sections of [CORE-TECHNIQUES.md](CORE-TECHNIQUES.md), and with [ADVANCED-TECHNIQUES.md](ADVANCED-TECHNIQUES.md) when the core techniques do not reach the lower bound or the problem is in a specialized domain. That file is an index: load only the `techniques/` files it routes the problem to. When no known technique fits or reaches the lower bound, derive one with [DISCOVERY.md](DISCOVERY.md), the method for finding better algorithms. Confirm every technique's assumptions from the code.
 
-   **Count every call at its real cost.** A function's complexity includes the cost of everything it calls (the language's built-in operations, its standard library, third-party libraries, frameworks, and the project's own functions), each multiplied by how many times it runs. An operation that reverses, sorts, searches, copies, slices, or converts a collection or a string usually costs time proportional to its size, so one such call inside a loop over n items can make the loop O(n²). Count implicit work too: copying or converting a collection, building a string piece by piece, wrapping values in objects, building one structure from another (which reads all of the source), hashing or comparing keys (for a string, proportional to its length), the comparison or key function a sort calls O(n log n) times, and lazy sequences evaluated more than once. Never treat a call as O(1) because it is short, built in, or not listed: a language file's "Hidden costs" table lists common traps, not every operation. Take each cost from the language's or library's official documentation, the language file, or a measurement (a doubling experiment, `BENCHMARKING.md`). If none settles it, write the cost as unknown, give the bound you can support, and label the total estimated.
+   **Count every call at its real cost.** A function's complexity includes the cost of everything it calls (the language's built-in operations, its standard library, third-party libraries, frameworks, and the project's own functions), each multiplied by how many times it runs. An operation that reverses, sorts, searches, copies, slices, or converts a collection or a string usually costs time proportional to its size, so one such call inside a loop over n items can make the loop O(n²). Count implicit work too: copying or converting a collection, building a string piece by piece, wrapping values in objects, building one structure from another (which reads all of the source), hashing or comparing keys (for a string, proportional to its length), the comparison function a sort calls O(n log n) times (a key function runs n times when the sort computes keys once, and once per comparison when it is wrapped in a comparator), and lazy sequences evaluated more than once. Never treat a call as O(1) because it is short, built in, or not listed: a language file's "Hidden costs" table lists common traps, not every operation. Take each cost from the language's or library's official documentation, the language file, or a measurement (a doubling experiment, `BENCHMARKING.md`). If none settles it, write the cost as unknown, give the bound you can support, and label the total estimated.
 
    Compare approaches in proportion to the problem's difficulty. A problem is **straightforward** only when the strongest candidate reaches the stated lower bound, needs no new dependency (the standard library, or a structure the project already has), and has no behavior risks: name that candidate and briefly say why alternatives are unnecessary. Every other problem is **nontrivial**: evaluate at least three plausible approaches, including combinations where relevant. Never invent alternatives merely to meet a quota.
 
diff --git a/skills/languages/C.md b/skills/languages/C.md
index ff01d17..f8e2403 100644
--- a/skills/languages/C.md
+++ b/skills/languages/C.md
@@ -10,7 +10,7 @@ C's standard library has almost no data structures. What it provides:
 |---|---|---|---|
 | Fixed array | `T a[n]`, `malloc(n * sizeof(T))` | index O(1) | No bounds checking |
 | Growable array | `realloc` with **geometric** growth (double the capacity) | append amortized O(1) | Growing by a fixed amount is O(n²) total |
-| Sorting | `qsort` | O(n log n) average; **not stable**; worst case is implementation-defined | Comparator called through a function pointer |
+| Sorting | `qsort` | O(n log n) average; **stability and worst case are not specified** by the standard (glibc's is a merge sort, stable when it can allocate memory; other C libraries' are not) | Comparator called through a function pointer |
 | Binary search | `bsearch` | O(log n) | Returns **any** matching element among duplicates, or `NULL` |
 | Strings | `<string.h>` | **`strlen` is O(n)**; `strcat` is O(length of destination + source) | Null-terminated; length is not stored |
 | Memory moves | `memmove`, `memcpy`, `memset` | O(n), highly optimized | `memcpy` requires non-overlapping regions |
@@ -58,7 +58,7 @@ Use **unsigned** types for bit manipulation. In C:
 ## C-specific traps
 
 - **Undefined behavior.** A rewrite must never introduce undefined behavior: signed integer overflow, out-of-bounds access, use after free, uninitialized reads, strict-aliasing violations, or invalid shifts. The compiler may assume undefined behavior never happens, so a rewrite that relies on it can behave differently at different optimization levels. Run differential tests under sanitizers (see Testing).
-- **`qsort` is not stable.** Switching to or from a stable sort changes the order of equal elements. Comparators written as `return a - b;` overflow for large values; keep the original comparator's exact behavior when replacing it.
+- **`qsort` is not guaranteed stable.** The standard promises nothing, but glibc's `qsort` is stable in practice when it can allocate memory, so code may depend on that order without knowing it. Replacing `qsort` with a hand-written unstable sort can change the order of equal elements on glibc; on other C libraries, assume the original order of equal elements was already unspecified, and test. Comparators written as `return a - b;` overflow for large values; keep the original comparator's exact behavior when replacing it.
 - **`bsearch` returns any matching element.** If the original linear search returned the first match, a `bsearch` replacement can return a different one.
 - **Unsigned wraparound.** `for (size_t i = n - 1; i >= 0; i--)` never ends; rewriting loop directions with unsigned indices is a common source of bugs.
 - **Integer promotions and implicit conversions** change results when rewriting arithmetic with narrower or wider types.
diff --git a/skills/languages/INDEX.md b/skills/languages/INDEX.md
index 7afe4df..ccfd857 100644
--- a/skills/languages/INDEX.md
+++ b/skills/languages/INDEX.md
@@ -9,7 +9,7 @@ Load the file for each language the analysis touches. In a project with several
 | `*.swift`, `Package.swift`, `*.xcodeproj` | [SWIFT.md](SWIFT.md) |
 | `*.js`, `*.mjs`, `*.cjs`, `*.jsx`, `*.ts`, `*.mts`, `*.cts`, `*.tsx`, `package.json`, `tsconfig.json`, `deno.json` | [JAVASCRIPT-TYPESCRIPT.md](JAVASCRIPT-TYPESCRIPT.md) |
 | `*.cs`, `*.csproj`, `*.sln` | [CSHARP.md](CSHARP.md) |
-| `*.c`, `*.h` (without C++ sources), C build files (`Makefile`, `CMakeLists.txt`, `meson.build`) | [C.md](C.md) |
+| `*.c`, `*.h`, and C build files (`Makefile`, `CMakeLists.txt`, `meson.build`), when the project has no C++ sources (`*.cpp`, `*.cc`, `*.cxx`, `*.hpp`); build files alone do not identify C, since C++ projects use them too | [C.md](C.md) |
 | `*.rs`, `Cargo.toml` | [RUST.md](RUST.md) |
 | `*.py`, `*.pyi`, `pyproject.toml`, `setup.py`, `requirements.txt` | [PYTHON.md](PYTHON.md) |
 | Any other language | [GENERIC.md](GENERIC.md), after first looking for a profile saved in the project at `.algorithmic-intelligence/languages/<LANGUAGE>.md` (for example `ERLANG.md`). `GENERIC.md` says how to use it, and how to build and save one when none exists |
diff --git a/skills/languages/JAVA.md b/skills/languages/JAVA.md
index 58a41ac..2baca66 100644
--- a/skills/languages/JAVA.md
+++ b/skills/languages/JAVA.md
@@ -15,7 +15,7 @@ Load this file for Java projects. Kotlin projects consult it only for JVM struct
 | Sorted map / set | `TreeMap`, `TreeSet` | O(log n); `floorKey`, `ceilingKey`, `headMap`, `subMap` | Red-black tree |
 | Priority queue | `PriorityQueue` | offer/poll O(log n), peek O(1), **`remove(Object)` and `contains` O(n)** | Binary min-heap; iteration order is not sorted |
 | Bitset | `BitSet` | O(1) per bit; `and`, `or`, `cardinality`, `nextSetBit` | Grows automatically |
-| Enum set / map | `EnumSet`, `EnumMap` | O(1), bit-vector backed | Ideal for flag sets |
+| Enum set / map | `EnumSet`, `EnumMap` | O(1); `EnumSet` is a bit vector, `EnumMap` an array indexed by ordinal | Ideal for flag sets |
 | Concurrent | `ConcurrentHashMap`, `ConcurrentLinkedDeque`, `CopyOnWriteArrayList` | `CopyOnWriteArrayList` writes are O(n) | Keep thread-safety when replacing |
 | Search / sort helpers | `Arrays.sort`, `Collections.sort`, `Arrays.binarySearch`, `Collections.binarySearch` | O(n log n), O(log n) | `Collections.binarySearch` on a `LinkedList` is O(n) |
 | String building | `StringBuilder`, `String.join`, `Collectors.joining` | append amortized O(1) | |
@@ -33,7 +33,7 @@ This table lists common traps, not every operation. Every call counts at its rea
 | `list.contains(x)` inside a loop | O(n·m) | `HashSet` built once |
 | `a.removeAll(b)` / `retainAll(b)` where `b` is a `List` | O(n·m) | Pass a `HashSet`. For `AbstractSet.removeAll`, cost depends on which collection is larger |
 | `String s += x` in a loop | O(n²) copying (the compiler only optimizes single expressions) | `StringBuilder` |
-| `Pattern.compile` or `String.matches`/`replaceAll`/`split` with a regex in a hot loop | Recompiles each call | Precompiled `static final Pattern` |
+| `Pattern.compile` or `String.matches`/`replaceAll`/`split` with a regex in a hot loop | Recompiles each call (except `split` on one literal character, or one backslash-escaped character, which has a fast path with no regex) | Precompiled `static final Pattern`; leave a single-character `split` alone |
 | `String.format` in hot paths | Parses the format each call | `StringBuilder` |
 | `Map<Integer, Integer>`, `List<Long>` in hot numeric code | Boxing, GC pressure, cache misses | Primitive arrays or counting arrays |
 | `stream()` pipelines in very hot tight loops | Allocation overhead | Plain loop, only if a benchmark shows it matters |
diff --git a/skills/languages/KOTLIN.md b/skills/languages/KOTLIN.md
index cf3a096..da1acac 100644
--- a/skills/languages/KOTLIN.md
+++ b/skills/languages/KOTLIN.md
@@ -4,7 +4,7 @@ Load this file for Kotlin projects. First determine the target, which decides wh
 
 - **Kotlin/JVM**: the full Java standard library is available. `JAVA.md` documents it; consult it only for structures Kotlin lacks.
 - **Multiplatform common code**: only `kotlin.collections`. No sorted map or set, priority queue, bitset, or `java.util.*`. Options: `expect`/`actual` wrappers over platform types, a small in-project implementation with tests, or a dependency (ask first, rule 7).
-- **Kotlin/Native, JS, or Wasm**: `kotlin.collections` has its own implementations; do not assume JVM behavior. On Kotlin/JS, `Long` is a `BigInt` only on ES2020 targets or with an experimental flag; check before using it in a hot loop. A Kotlin collection passed to Swift is copied in full, so crossing that boundary in a loop is O(n) per crossing.
+- **Kotlin/Native, JS, or Wasm**: `kotlin.collections` has its own implementations; do not assume JVM behavior. On Kotlin/JS, `Long` is a `BigInt` only on ES2020 targets or with an experimental flag; check before using it in a hot loop. A read-only Kotlin `List`, `Set`, or `Map` passed to Swift is converted to a Swift `Array`, `Set`, or `Dictionary` by copying it, so crossing that boundary in a loop is O(n) per crossing; mutable collections map to `NSMutableArray` and the like without that conversion.
 
 ## Kotlin first (rule 14)
 
@@ -20,7 +20,7 @@ When Kotlin provides an equivalent, use the Kotlin structure or factory, not the
 | Sorting and searching | `sort()`, `sortBy { }`, `sortedWith()`, `binarySearch()`, `IntArray.sort()` | `Collections.sort`, `Arrays.sort`, `Collections.binarySearch` |
 | String building | `buildString { }`, `joinToString()` | `StringBuilder` used directly (fine inside `buildString`) |
 
-Use Java classes only when Kotlin has no equivalent, and state this in the report: `PriorityQueue`, `BitSet`, `EnumSet`, `EnumMap`, `java.util.concurrent` collections, `LinkedHashMap` with access order and `removeEldestEntry` (a bounded LRU cache), and `TreeMap`/`TreeSet` navigation (`floorKey`, `ceilingKey`, `headMap`, `pollFirst`): `sortedMapOf` is typed as `SortedMap`, which lacks these, so declare a `TreeMap` or `NavigableMap` when navigation is needed.
+Use Java classes only when Kotlin has no equivalent, and state this in the report: `PriorityQueue`, `BitSet`, `EnumSet`, `EnumMap`, `java.util.concurrent` collections, `LinkedHashMap` with access order and `removeEldestEntry` (a bounded LRU cache), and `TreeMap` navigation (`floorKey`, `ceilingKey`, `headMap`, `pollFirstEntry`): `sortedMapOf` is typed as `SortedMap`, which lacks these, so declare a `TreeMap` or `NavigableMap` when navigation is needed. `sortedSetOf` already returns a `java.util.TreeSet`, with `floor`, `ceiling`, and `pollFirst`.
 
 Only new code follows this preference; do not swap existing Java structures, since behavior can differ (`java.util.ArrayDeque` throws on `null`; Kotlin's `ArrayDeque` accepts it, measured on Kotlin 2.4).
 
@@ -48,7 +48,7 @@ This table lists common traps, not every operation. Every call counts at its rea
 | `list = list + item` or `+=` on a `var` of read-only `List` in a loop | Copies each step: O(n²) | `mutableListOf` and `add`, `buildList { }`, or a persistent list |
 | `item in list`, `indexOf`, `first { }`, `find` inside a loop | O(n) per call | `toHashSet()` or `associateBy { }` once (traps: duplicates, exception type, floating-point equality) |
 | `list - other`, `removeAll(other)`, `retainAll(other)` where `other` is a `List` | Linear search per element: O(n·m) (measured on Kotlin 2.4; the docs state no cost) | Pass a `Set` |
-| `set.elementAt(i)`, `Iterable.last()`, `count()` on a non-`List` in a loop | O(n) per call | Index a list, or keep the value |
+| `set.elementAt(i)` or `Iterable.last()` on a non-`List`, or `count()` on a `Sequence` or an `Iterable` that is not a `Collection`, in a loop | O(n) per call (`count()` on any `Collection`, including a `Set`, returns `size` in O(1); on a `Sequence` it also re-runs the chain) | Index a list, or keep the value |
 | `list.removeAt(0)` as a queue; `remove` inside an index loop | O(n) per removal, O(n²) total | `ArrayDeque.removeFirst()`; `removeAll { }` or `retainAll { }`, which filter in place in O(n) (measured on Kotlin 2.4; the docs state no cost) |
 | `windowed(k)` then aggregating each window | Allocates n lists of k: O(n·k) | Sliding aggregate in one loop: O(n) |
 | `sorted()`, `sortedBy`, `maxBy` inside a loop | O(n log n) or O(n) per iteration | Sort once, or keep a `TreeMap` or heap |
diff --git a/skills/languages/PYTHON.md b/skills/languages/PYTHON.md
index 2de0568..7a678a2 100644
--- a/skills/languages/PYTHON.md
+++ b/skills/languages/PYTHON.md
@@ -36,7 +36,7 @@ This table lists common traps, not every operation. Every call counts at its rea
 | `s[i:]` or `lst[1:]` in a loop or recursion | Each slice copies: O(n²) total | Pass indices; `memoryview` for bytes |
 | `bisect.insort` to keep a growing list sorted | O(n) per insert, O(n²) total | `heapq` if only the minimum is needed; sort once at the end; `sortedcontainers` (ask) |
 | `sorted(...)`, `min`, or `max` over a whole collection inside a loop | O(n log n) or O(n) per iteration | Sort once, keep a heap, or carry the running answer |
-| `statistics.mean`, `median` on large float data | Exact `Fraction` arithmetic, much slower | `statistics.fmean` (3.8+) or `sum/len`, which can change the last digits: a behavior change |
+| `statistics.mean` on large float data | Exact rational arithmetic, much slower | `statistics.fmean` (3.8+) or `sum/len`, which can change the last digits: a behavior change. (`median` does no exact arithmetic: it sorts, O(n log n); never replace it with a mean) |
 | `copy.deepcopy` in a loop | Walks the whole object graph | Copy only what changes, or share immutable parts |
 | Deep recursion (DFS, recursive descent, memoized recursion) | `RecursionError` near 1000 frames, and per-call overhead | An explicit stack; raising the recursion limit can crash the interpreter on the C stack. A `RecursionError` on accepted input is a bug (rule 4) |
 | CPU-bound threads on a build with the global interpreter lock | No parallel speedup | Processes (pickling and side-effect order change), vectorization, or a free-threaded build; all need approval |
diff --git a/skills/languages/RUST.md b/skills/languages/RUST.md
index 38dc9b4..487a9ec 100644
--- a/skills/languages/RUST.md
+++ b/skills/languages/RUST.md
@@ -8,12 +8,12 @@ Load this file for Rust projects. Record the toolchain, the edition, and the min
 |---|---|---|---|
 | Growable array | `Vec<T>` | index O(1), `push` amortized O(1), `insert(0, x)`/`remove(0)` O(n), `contains` O(n) | `with_capacity` avoids reallocations |
 | Double-ended queue | `VecDeque<T>` | push/pop at both ends O(1) amortized | Use for queues and BFS |
-| Hash map / set | `HashMap`, `HashSet` | O(1) expected | Default hasher (SipHash) resists hash flooding but is slower; **iteration order is randomized per process** |
+| Hash map / set | `HashMap`, `HashSet` | O(1) expected | Default hasher (SipHash) resists hash flooding but is slower; **iteration order is randomized per map** (each `RandomState`), so two maps with the same contents usually iterate differently even in one process |
 | Ordered map / set | `BTreeMap`, `BTreeSet` | O(log n); `range`, `first_key_value`, `last_key_value` | Sorted iteration |
-| Priority queue | `BinaryHeap<T>` | `push` O(1) expected, O(log n) worst; `pop` O(log n); `peek` O(1) | **Max-heap**; wrap in `std::cmp::Reverse` for a min-heap; no decrease-key |
+| Priority queue | `BinaryHeap<T>` | `push` O(1) expected, O(log n) amortized for the worst input order (a single push can cost O(n) when the heap reallocates); `pop` O(log n); `peek` O(1) | **Max-heap**; wrap in `std::cmp::Reverse` for a min-heap; no decrease-key |
 | Linked list | `LinkedList<T>` | O(1) at ends | Rarely the right choice |
 | String building | `String::push_str`, `write!`, `concat`, `join` | amortized O(1) per byte | |
-| Slice algorithms | `sort` (stable), `sort_unstable`, `sort_by_key`, `binary_search`, `select_nth_unstable` (O(n) expected), `partition_point`, `chunks`, `windows`, `retain`, `dedup`, `swap_remove` (O(1)) | | See traps |
+| Slice algorithms | `sort` (stable), `sort_unstable`, `sort_by_key`, `binary_search`, `select_nth_unstable` (O(n), guaranteed for all inputs), `partition_point`, `chunks`, `windows`, `retain`, `dedup`, `swap_remove` (O(1)) | | See traps |
 | Lazy iterators | `iter()`, `map`, `filter`, `take_while` | No intermediate allocation | Evaluate only when consumed |
 | Lazy statics | `std::sync::LazyLock`, `OnceLock` | One-time initialization | `LazyLock` stable since 1.80; `OnceLock` since 1.70 |
 
@@ -57,7 +57,7 @@ Shifting by a count greater than or equal to the bit width panics in debug build
 ## Rust-specific traps
 
 - **Debug and release overflow behavior differ.** Integer overflow panics in debug builds and wraps in release builds (unless `overflow-checks` is enabled). A closed-form formula that overflows where the loop did not can panic in tests and silently wrap in production. Match the original's behavior with the explicit `wrapping_*`/`checked_*` operations it implied.
-- **`HashMap`/`HashSet` iteration order is randomized per process.** Never iterate them where the original exposed a deterministic order.
+- **`HashMap`/`HashSet` iteration order is randomized per map,** not just per process: two maps with the same contents usually iterate in different orders. Never iterate them where the original exposed a deterministic order, and never rely on two maps iterating in step.
 - **Changing the hasher** (for example to `FxHashMap` or `ahash`) changes iteration order and removes hash-flooding resistance. For keys controlled by users or attackers, that is a security regression (see `BEHAVIOR-TRAPS.md`). It also needs a dependency.
 - **Sort stability.** `sort` and `sort_by_key` are stable; `sort_unstable` is not. Switching changes the order of equal elements.
 - **`dedup` removes only consecutive duplicates.** It is not equivalent to deduplicating with a set unless the input is sorted.
diff --git a/skills/languages/SWIFT.md b/skills/languages/SWIFT.md
index 6162f1c..5638ded 100644
--- a/skills/languages/SWIFT.md
+++ b/skills/languages/SWIFT.md
@@ -12,7 +12,7 @@ Load this file for Swift projects on any target: Apple platforms, Linux and Wind
 | Flag set | `OptionSet` | O(1) set operations on a raw integer | Idiomatic bitmask |
 | String | `String` | **`count` is O(n)**; index offsetting is O(n) | Indexed by `String.Index`, iterates `Character` (grapheme clusters) |
 | Contiguous storage | `ContiguousArray` | Like `Array`, without Objective-C bridging | Matters only on Apple platforms with class elements |
-| Fixed-size inline array | `InlineArray<N, T>` (Swift 6.2+) | O(1), no heap allocation | Size fixed at compile time; for small buffers and embedded targets |
+| Fixed-size inline array | `InlineArray<N, T>` (Swift 6.2+; on Apple platforms also an OS 26 deployment target, since it is not back-deployed) | O(1), no heap allocation | Size fixed at compile time; for small buffers and embedded targets |
 | Borrowed view | `Span`, `MutableSpan` (Swift 6.2+) | O(1) access, no copy, no reference counting | Safe replacement for `withUnsafeBufferPointer` in hot loops |
 | Unique ownership | `~Copyable` types, `borrowing`/`consuming` parameters (Swift 5.9+) | No implicit copies or copy-on-write checks | Changes how callers can use the type: a public-contract change (rule 11) |
 | Lazy pipeline | `.lazy` | Avoids intermediate arrays | Changes evaluation order (traps) |
@@ -73,7 +73,7 @@ Swift's `<<` and `>>` are "smart shifts": overshifting gives 0 (or -1 for negati
 - **`Equatable` versus `Hashable` consistency.** Custom types whose `==` and `hash(into:)` disagree break in sets and dictionaries.
 - **Concurrency.** Moving to `async let` or task groups changes ordering, error, and cancellation behavior; actor isolation changes threading. Actor state can change across every `await` (reentrancy), so reordering or batching awaits inside an actor can break its invariants. Ask first.
 - **Stack depth.** Secondary threads, concurrency tasks, and embedded targets have small stacks. A recursion that overflows on accepted input is a bug (rule 4).
-- **Embedded Swift** has no `any` existentials, no reflection, and possibly no heap allocation or Foundation. Techniques that need them are not candidates there; memory budgets are hard limits (rule 1).
+- **Embedded Swift** supports only class-bound existentials before Swift 6.4 (full `any` arrives in 6.4), has no reflection, and possibly no heap allocation or Foundation. Techniques that need them are not candidates there; memory budgets are hard limits (rule 1).
 
 ## Testing, profiling, and benchmarking
 
diff --git a/skills/techniques/data-at-scale.md b/skills/techniques/data-at-scale.md
index b8ea159..35550c8 100644
--- a/skills/techniques/data-at-scale.md
+++ b/skills/techniques/data-at-scale.md
@@ -27,7 +27,7 @@ Three costs trade against each other: read amplification (pages read per lookup)
 | Write-heavy index where random in-place page updates dominate | Log-structured merge (LSM) tree: in-memory buffer plus write-ahead log, flushed to sorted immutable runs, merged by compaction | Deletes become tombstones; reads may check several runs; durability, crash recovery, and read-after-write timing must match the original contract, otherwise it is a behavior change | Random page writes → sequential batched writes; reads pay read amplification across runs |
 | Readers and writers block each other on row or page locks | Multi-version concurrency control (MVCC): writers create new versions, readers read a snapshot | The isolation level callers see is unchanged (snapshot isolation allows write skew that serializable execution prevents: a behavior change if the original was serializable); old versions are garbage-collected | Reads no longer wait for writes; storage pays for versions |
 | Choosing LSM compaction | Leveled compaction (lower read and space amplification, higher write amplification) or tiered compaction (the reverse) | Measured read and write mix | A trade-off, not a free win; benchmark both |
-| LSM or on-disk lookups for keys that are often absent | Bloom or cuckoo filter per run or file, plus fence pointers (the first key of each page) in memory | Filter used only to skip reads, never to answer a lookup | Most negative lookups need no disk read; positive lookups read about one page per run |
+| LSM or on-disk lookups for keys that are often absent | Bloom or cuckoo filter per run or file, plus fence pointers (the first key of each page) in memory | Filter used only to skip reads, never to answer a lookup | Most negative lookups need no disk read; a positive lookup reads about one page in the run that holds the key, plus a page for each other run whose filter gives a false positive |
 | Sorted keys with long shared prefixes (paths, URLs, composite keys) | Prefix compression within pages; suffix truncation of separator keys in inner nodes | Key comparison results unchanged | Higher fanout, so fewer levels and page reads |
 | Large static sorted integer sets (posting lists, ID sets) | Compressed representations: delta encoding with varint or bit packing, Elias-Fano, Roaring bitmaps | Set and order semantics unchanged | Several times less memory and I/O; intersections and unions run on compressed data |
 | Sparse map from integer keys (page offsets, file descriptors, IDs) with ordered iteration | Radix tree (for example, the Linux kernel XArray) | Keys are integers of bounded width | O(log n) comparisons → O(key bits / bits per level) steps; no rebalancing |
diff --git a/skills/techniques/data-structures.md b/skills/techniques/data-structures.md
index e1d3374..3727ca7 100644
--- a/skills/techniques/data-structures.md
+++ b/skills/techniques/data-structures.md
@@ -14,7 +14,7 @@ When the project implements its own hash table (common in C and in performance-c
 | Growth rehashes the whole table at once, and the pause matters (latency-sensitive or real-time code) | Incremental rehashing: keep the old and new tables and move a few buckets per operation | Lookups check both tables during migration | Worst-case single operation O(n) → O(1) extra per operation; same amortized cost |
 | Integer keys hashed with a modulo by a prime, or with weak mixing, in a power-of-two table | Multiplicative (Fibonacci) hashing: multiply by 2^w / φ (for 64 bits, `0x9E3779B97F4A7C15`) and keep the top bits; Linux's `hash_long` does the same with a related golden-ratio constant | Changing the hash changes bucket order and iteration order (behavior change where observable); not suitable for untrusted keys (see the keyed-hash row) | A multiply and a shift instead of a division; sequential keys spread evenly |
 | Hash table with fixed-size buckets (hardware tables, cache-line buckets) where the fullest bucket overflows | d-left hashing: split the table into d parts, place each key in the least loaded of its d candidate buckets, breaking ties to the left | Lookups check d buckets; changes placement and iteration order | Maximum bucket load drops from about log n / log log n to about log log n / d, so buckets can be small and fixed-size |
-| Lookups must be fast in the worst case, not just on average (packet processing, real-time, hardware tables) | Cuckoo hashing: each key lives in one of two (or d) candidate slots; inserts move occupants to their alternative slot | Load factor kept under the scheme's limit (about 50% with two single-slot tables, about 95% with buckets of four); insert failures handled by rehashing or a small stash; with untrusted keys, hash functions keyed with a per-process secret, or an attacker can force repeated insert failures (`techniques/hostile-inputs.md`) | Lookups check at most two slots, O(1) worst case; inserts O(1) expected amortized |
+| Lookups must be fast in the worst case, not just on average (packet processing, real-time, hardware tables) | Cuckoo hashing: each key lives in one of two (or d) candidate slots; inserts move occupants to their alternative slot | Load factor kept under the scheme's limit (about 50% with two single-slot tables, about 95% with buckets of four); insert failures handled by rehashing or a small stash; with untrusted keys, hash functions keyed with a per-process secret, or an attacker can force repeated insert failures (`techniques/hostile-inputs.md`) | Lookups check at most two buckets (d with d hash functions, plus the stash if one is used), O(1) worst case; inserts O(1) expected amortized |
 | Key comparisons are expensive (long strings, composite keys) | Store each key's full hash beside it, and compare hashes before comparing keys | The hash is consistent with key equality (equal keys always hash equal); a hash match is always confirmed by comparing keys | Most failed comparisons avoided |
 | Table built once, then only read, with keys known at build time | Perfect hashing or a static sorted array (see "Structures for repeated queries" in `CORE-TECHNIQUES.md`) | Key set never changes after building | O(1) worst-case lookups |
 
@@ -34,7 +34,7 @@ Hit rate decides whether a cache pays off, and the eviction policy decides the h
 
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
-| Predecessor and successor queries over a bounded integer universe u, at very high volume | Van Emde Boas tree, or a hierarchical bitset (y-fast trie for sparse sets) | Integer keys in [0, u); memory O(u) for van Emde Boas, less for hierarchical bitsets | O(log n) → O(log log u) |
+| Predecessor and successor queries over a bounded integer universe u, at very high volume | Van Emde Boas tree, or a hierarchical bitset (y-fast trie for sparse sets) | Integer keys in [0, u); memory O(u) for van Emde Boas, less for hierarchical bitsets, O(n) for a y-fast trie | O(log n) → O(log log u) for van Emde Boas (worst case) and y-fast tries (expected amortized); O(log u / log w) for a hierarchical bitset with w-bit words |
 | Sorted map needed but not in the standard library | Treap, skip list, or another balanced tree | The comparator is a consistent total order; iteration order and handling of equal keys match the original; with untrusted keys, the random priorities or levels come from a source the attacker cannot predict, or use a deterministic balanced tree | O(n) → O(log n) expected |
 | A structure that is fast to query but can only be built from scratch (a static sorted array, k-d tree, or suffix array), now receiving inserts | Bentley-Saxe logarithmic method: keep static structures of sizes 1, 2, 4, …, merge them like a binary counter on insert, and query each one | The query is decomposable (its answer combines across parts: membership, counting, nearest neighbor); deletes need tombstones or periodic rebuilds | Rebuild per insert, O(B(n)) → O((B(n) / n) · log n) amortized for build time B(n); queries cost about log n times more. LSM trees use the same idea |
 | Sorted map with highly skewed or local access (a few keys accessed repeatedly, or accesses near the previous one) | Splay tree: each access moves the key to the root | Single-threaded, or guarded by a lock: every lookup restructures the tree, so reads become writes; a single operation can take O(n), so not on deadline paths or where an attacker chooses the access sequence for its single-operation latency | O(log n) amortized, and much less for skewed access (working-set property) |
diff --git a/skills/techniques/games-and-simulation.md b/skills/techniques/games-and-simulation.md
index 93323cd..c6b9bfa 100644
--- a/skills/techniques/games-and-simulation.md
+++ b/skills/techniques/games-and-simulation.md
@@ -10,12 +10,12 @@ A frame has a fixed budget (16.7 ms at 60 frames per second), so the worst frame
 |---|---|---|---|
 | Many agents each finding a path to the same goal | Flow field: one Dijkstra or BFS outward from the goal, then each agent follows the cheapest neighbor | Agents share the goal and the cost map; among equal-cost paths, agents may pick different ones (behavior change if observable) | A searches per goal → one search per goal change |
 | Pathfinding on a large uniform-cost grid | Jump point search | Uniform costs and the original movement rules (diagonals, corner cutting); optimal length, but may choose a different path among equals | Same optimal length with far fewer nodes expanded |
-| Pathfinding over large maps, repeated often | Hierarchical pathfinding (HPA*), navigation meshes, or precomputed portal graphs | **HPA* paths can be slightly longer than optimal: behavior change** | Large practical reduction in search work |
+| Pathfinding over large maps, repeated often | Hierarchical pathfinding (HPA*), navigation meshes, or precomputed portal graphs | **HPA* and navigation-mesh or portal paths can be longer than the optimal grid path: behavior change** | Large practical reduction in search work |
 | Every object's world transform recomputed every frame | Dirty flags on the transform hierarchy: recompute only the subtrees that changed | Every change marks its node | O(all nodes) → O(changed nodes) per frame |
 | Every object updated or polled every frame although few change | Event-driven updates, timers (timing wheel), sleeping physics bodies | Update order and the timing of effects are preserved, or the change is approved | Work proportional to active objects |
 | Every object drawn or tested for visibility each frame | Frustum culling over a BVH or grid; occlusion culling | Culling is conservative: it never removes a visible object | O(objects) → about O(log n + visible objects) |
 | Distant objects rendered or simulated at full detail | Level of detail (LOD) for meshes, animation, and simulation | **Changes what is rendered or simulated: behavior change**, developer review | Work roughly proportional to screen-space importance |
-| Narrow-phase collision between convex shapes by testing all pairs of features | Separating axis theorem, or GJK with EPA for penetration depth | Same contact results; a changed tolerance is a behavior change | Feature pairs O(n·m) → about O(n + m) |
+| Narrow-phase collision between convex shapes by testing all pairs of features | GJK, with EPA for penetration depth; the separating axis theorem for boxes and simple polyhedra | GJK and EPA are iterative with tolerances, so contact points and depths can differ from the original: compare them, and treat a difference as a behavior change. In 3D the separating axis theorem tests every face normal and every pair of edges, so it is not linear for complex hulls | Feature pairs O(n·m) → about O(n + m) per query with GJK |
 | Allocation, garbage collection, or asset loading during gameplay | Object pools, preallocated buffers, asynchronous asset streaming | Pooled objects are fully reset before reuse | Removes frame-time spikes |
 | Game objects with their data scattered across memory | Entity-component-system storage: each component type in a contiguous array | See "Memory locality" in `techniques/hardware-and-concurrency.md` | Fewer cache misses per frame |
 | Assets, events, or properties looked up by string name during frames | Hash names to integer IDs once at load time | IDs are unique; collisions detected at load time | String hashing and comparison removed from frames |
@@ -28,7 +28,7 @@ For game AI, puzzle solvers, and any adversarial or turn-based decision search (
 |---|---|---|---|
 | Full minimax over a game tree of branching factor b and depth d | Alpha-beta pruning | Returns the same root value as minimax; the same move only if ties among equal-valued moves are broken the same way (alpha-beta may stop at the first best move it finds) | O(b^d) → about O(b^(d/2)) with good move ordering; O(b^d) with the worst ordering |
 | Alpha-beta that searches poor moves first | Move ordering: the best move from the previous iteration first, then captures, killer moves, and the history heuristic | Ordering changes only pruning, never the value; tie-breaking among equal moves checked as above | Closer to the O(b^(d/2)) best case |
-| The same position reached by different move orders and searched again | Transposition table keyed by a Zobrist hash (XOR of a random number per piece and square, updated incrementally), with a fixed size and a replacement policy | Hash collisions verified or made negligible with 64-bit keys; stored bounds (exact, lower, upper) used correctly with the alpha-beta window; table size bounded (rule 1) | Repeated subtrees searched once; position hashing O(1) per move instead of O(board) |
+| The same position reached by different move orders and searched again | Transposition table keyed by a Zobrist hash (XOR of a random number per piece and square, updated incrementally), with a fixed size and a replacement policy | Hash collisions verified or made negligible with 64-bit keys; stored bounds (exact, lower, upper) used correctly with the alpha-beta window; table size bounded (rule 1). Reusing an entry from a deeper search, or a position whose value depends on how it was reached (repetition rules), returns a different score than the fixed-depth search: require an exact depth match and path-independent evaluation, or treat it as a behavior change | Repeated subtrees searched once; position hashing O(1) per move instead of O(board) |
 | A fixed-depth search that must finish within a time budget | Iterative deepening: search depth 1, 2, 3, … until time runs out, reusing the previous iteration's best move for ordering | Depth reached now depends on time and machine speed: a behavior change if the original searched a fixed depth | Uses the budget fully; the overhead of shallower iterations is small, since the last depth dominates |
 | Branching factor too large for alpha-beta (Go, large strategy games), or no reliable evaluation function | Monte Carlo tree search with UCT selection | Results are randomized and approximate: a behavior change unless replacing another randomized search with the same seeding | Effort concentrated on promising moves; anytime, with quality improving with time |
 
diff --git a/skills/techniques/geometry-and-cad.md b/skills/techniques/geometry-and-cad.md
index f3ff854..6fce2b9 100644
--- a/skills/techniques/geometry-and-cad.md
+++ b/skills/techniques/geometry-and-cad.md
@@ -10,7 +10,7 @@ For CAD and CAM, GIS, 3D modeling, mesh processing, and geometry kernels. Robust
 |---|---|---|---|
 | Convex hull found by testing every candidate edge or point | Andrew's monotone chain or Graham scan | Collinear points on the hull, duplicates, and output order and orientation handled as the original does | O(n³) or O(n²) → O(n log n) |
 | All intersecting pairs among many line segments | Bentley-Ottmann sweep line | Robust predicates; touching, overlapping, and vertical segments handled as the original does | O(n²) → O((n + k) log n) for k intersections |
-| Closest pair of points | Divide and conquer, or a grid with cell size equal to the best distance so far | Ties resolved as the original does | O(n²) → O(n log n), or O(n) expected |
+| Closest pair of points | Divide and conquer, or a grid with cell size equal to the best distance so far | Ties resolved as the original does; the grid's expected bound needs the points inserted in random order | O(n²) → O(n log n), or O(n) expected |
 | Many point-in-polygon tests against the same polygon | Precomputed structure: a grid over the polygon's edges, a trapezoidal decomposition, or binary search over a triangle fan for convex polygons | Points on the boundary classified exactly as the original does | O(e) per query for e edges → O(log e), or about O(1) per query with a grid on typical data |
 | Ray casting, picking, or collision against many triangles or objects | Bounding volume hierarchy (BVH), built with the surface area heuristic | Exact intersection test still runs on candidates; the nearest-hit rule and tie-breaking match | O(n) per ray → about O(log n) |
 | Triangulating a simple polygon by ear clipping | Partition into monotone pieces, then triangulate each | Produces a different valid triangulation: behavior change when callers observe the triangles | O(n²) → O(n log n) |
@@ -18,7 +18,7 @@ For CAD and CAM, GIS, 3D modeling, mesh processing, and geometry kernels. Robust
 | Mesh adjacency queries (neighbors of a vertex, faces around an edge) answered by scanning all faces | Half-edge (or winged-edge) structure, or adjacency lists built once | Half-edge needs a manifold mesh; non-manifold meshes need a general adjacency structure | O(F) per query → O(degree) |
 | Merging nearby vertices (welding) by comparing every pair | Spatial hash with cell size equal to the tolerance, checking the neighboring cells | Same tolerance rule and same choice of the surviving vertex | O(n²) → O(n) expected |
 | Polygon Boolean operations (union, intersection, difference) by testing every edge pair | Sweep-line clipping (Vatti, Martinez-Rueda) | Robust predicates; output orientation and vertex order match, or the difference is approved | O(n·m) → O((n + m + k) log(n + m)) |
-| Evaluating Bezier or B-spline curves at many parameter values | De Casteljau or de Boor evaluation, or Horner's method on the power form; forward differencing for evenly spaced steps | Forward differencing accumulates rounding error: behavior change. Changing the evaluation method changes floating-point results | Per point O(d²) → O(d) for degree d; O(1) per step with forward differencing |
+| Evaluating Bezier or B-spline curves at many parameter values | Horner's method on the power form, or a Horner-style Bernstein evaluation; forward differencing for evenly spaced steps; de Casteljau or de Boor evaluation when numerical stability matters more than speed | De Casteljau and de Boor cost O(d²) per point, so they are for stability, not speed; converting to the power form is ill-conditioned at high degree. Forward differencing accumulates rounding error: behavior change. Changing the evaluation method changes floating-point results | Per point O(d²) → O(d) for degree d with Horner; O(d) additions per step with forward differencing (O(1) for a fixed degree such as cubics) |
 | Exact (arbitrary-precision) geometric predicates evaluated on every test | Floating-point filter with an exact fallback (adaptive-precision predicates, as in Shewchuk's) | Results identical to the exact predicate | Exact results at close to floating-point speed |
 
 ## References (for verifying claims; not required reading)
diff --git a/skills/techniques/graphs-and-trees.md b/skills/techniques/graphs-and-trees.md
index eeccfd7..cfebc5f 100644
--- a/skills/techniques/graphs-and-trees.md
+++ b/skills/techniques/graphs-and-trees.md
@@ -9,7 +9,7 @@ Part of the advanced techniques. The shared rules in `ADVANCED-TECHNIQUES.md` ap
 | Shortest paths with negative edge weights | Bellman-Ford | No negative cycles reachable, or the code must detect them (Bellman-Ford can) | Handles cases Dijkstra cannot; O(V·E) |
 | All-pairs shortest paths, negative edges, sparse graph | Johnson's algorithm (Bellman-Ford reweighting + Dijkstra from each node) | No negative cycles | O(V·E log V) |
 | All-pairs shortest paths on a small or dense graph | Floyd-Warshall | Replaces V separate single-source runs; wins when E is close to V² or V is small | O(V³), simple, cache-friendly |
-| Path search in a very large state space with a good estimate of remaining cost | A* | The heuristic is admissible (never overestimates) for optimal paths; consistent to avoid reopening nodes | Explores far fewer states than Dijkstra in practice; same worst case |
+| Path search in a very large state space with a good estimate of remaining cost | A* | The heuristic is admissible (never overestimates) for optimal paths; consistent to avoid reopening nodes | Explores far fewer states than Dijkstra in practice; same worst case with a consistent heuristic (an admissible but inconsistent one can reopen nodes exponentially often) |
 | Path between two known endpoints in a huge, uniform search space | Bidirectional BFS | Edges can be traversed backward | O(b^d) → O(b^(d/2)) for branching factor b and depth d |
 | Strongly connected components, condensing cycles | Tarjan or Kosaraju | — | O(V + E) |
 | Critical links or single points of failure | Bridges and articulation points via low-link DFS | Undirected graph | O(V + E) |
@@ -25,7 +25,7 @@ A static-graph algorithm rerun after every change costs its full price per chang
 
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
-| Topological order recomputed after each added edge | Incremental topological ordering (Pearce-Kelly, or Bender-Fineman-Gilbert-Tarjan) | Edges are mostly added; a new edge that closes a cycle is detected and reported the same way the original reports it | O(V + E) re-sort per insertion → work proportional to the region of the order that must shift, in practice; worst case per insertion is no better than re-sorting |
+| Topological order recomputed after each added edge | Incremental topological ordering (Pearce-Kelly, or Bender-Fineman-Gilbert-Tarjan) | Edges are mostly added; a new edge that closes a cycle is detected and reported the same way the original reports it | O(V + E) re-sort per insertion → work proportional to the region of the order that must shift, in practice; worst case for a single insertion is no better than re-sorting, but the total over m insertions is O(m · min(√m, V^(2/3))) for Bender-Fineman-Gilbert-Tarjan, against O(m · (V + E)) for re-sorting each time |
 | Unions that must be undone in last-in, first-out order (backtracking search, versioned state) | Union-find with rollback: union by rank or size, **no** path compression, a stack of changes | Undo order is last-in, first-out | Rebuild per undo → O(log n) per union, find, and undo |
 | Connectivity queries interleaved with edge additions and deletions, all known up front | Offline dynamic connectivity: segment tree over time, each edge inserted into the intervals where it exists, DFS with rollback union-find | All operations known in advance | O(V + E) per query → O((E + Q) log Q log V) total |
 | Connectivity queries with online edge additions and deletions | Fully dynamic connectivity (Holm-de Lichtenberg-Thorup) | Large, subtle implementation: prefer a reviewed library and ask (rule 7) | O(V + E) per query → O(log² V) amortized per update, O(log V / log log V) per query |
@@ -47,7 +47,7 @@ Program analyses are graph problems over the control-flow graph. A faster analys
 
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
-| Subtree sums, counts, or updates | Euler tour (flatten the tree to a range) + Fenwick or segment tree | The tree's shape does not change between queries (values may); the aggregate is associative | O(subtree size) per query → O(log n) |
+| Subtree sums, counts, or updates | Euler tour (flatten the tree to a range) + Fenwick or segment tree | The tree's shape does not change between queries (values may); the aggregate is associative for a segment tree, and also invertible (sum, count, XOR; not min or max) for a Fenwick tree | O(subtree size) per query → O(log n) |
 | An answer computed for every possible root | Tree DP with rerooting | The per-root answer can be combined from child and parent contributions | O(n²) → O(n) |
 | Path queries and updates between arbitrary nodes | Heavy-light decomposition + segment tree | Tree shape does not change | O(n) per query → O(log² n) |
 | Distance-based counting over all pairs of nodes | Centroid decomposition | — | O(n²) → O(n log n) or O(n log² n) |
diff --git a/skills/techniques/hostile-inputs.md b/skills/techniques/hostile-inputs.md
index 258c47f..96bc669 100644
--- a/skills/techniques/hostile-inputs.md
+++ b/skills/techniques/hostile-inputs.md
@@ -14,7 +14,7 @@ Load this file when the exposure check (Phase 2 in `WORKFLOW.md`, or write mode
 
 The expected bounds of randomized structures assume that the input does not depend on the structure's random choices. That holds when an attacker picks the whole input in advance (an *oblivious* adversary). It fails when the attacker sees outputs that depend on those random choices and picks later inputs after seeing them (an *adaptive* adversary). Then the guarantee can collapse after a modest number of queries, even though each random choice was secret:
 
-- **Sketches and estimators** (HyperLogLog and other distinct-count sketches, MinHash, Count-Min, AMS and other linear sketches): no linear sketch estimates the Euclidean norm within any fixed factor on polynomially many adaptively chosen inputs (Hardt and Woodruff, STOC 2013), and distinct-count sketches with k registers can be broken with on the order of k² adaptive queries (Ahmadian and Cohen, ICML 2024; Cohen, Nelson, Singhal, et al., SODA 2026).
+- **Sketches and estimators** (HyperLogLog and other distinct-count sketches, MinHash, Count-Min, AMS and other linear sketches): no linear sketch estimates the Euclidean norm within any fixed factor on polynomially many adaptively chosen inputs (Hardt and Woodruff, STOC 2013), and the standard estimators of distinct-count sketches with k registers (HyperLogLog and its variants) can be broken with a number of adaptive queries linear in k (Ahmadian and Cohen, ICML 2024), while about k² queries suffice against any estimator for such sketches, a bound that is tight (Cohen, Nelson, Sarlós, Singhal, and Stemmer, SODA 2026).
 - **Filters and caches** (Bloom and cuckoo filters, sampling or randomized-eviction caches): which requests hit, miss, or are rejected tells the attacker about the hidden state.
 - **Randomized load balancing and scheduling:** which server or queue a request lands on, or how long it waits, can be observed and steered.
 - **Keyed hash tables:** a secret per-process key stops precomputed collisions, but iteration order or timing that the attacker can observe can leak enough to build collisions over many requests.
@@ -22,7 +22,7 @@ The expected bounds of randomized structures assume that the input does not depe
 **The check.** For every randomized structure on an exposed path, ask: can the party that chooses the inputs observe anything that depends on the random choices (returned estimates, iteration or result order, timing, accept or reject decisions), and choose later inputs after seeing it? If not, the oblivious bound holds; say so. If yes:
 
 1. **Write the attack before trusting the design.** A simple adaptive loop is usually enough to test it: query, observe, keep the inputs that pushed the output in the attacker's direction, repeat. Run it against the candidate in a test, and report how many queries it took to break the bound, or that it did not within a stated budget.
-2. **Then choose a defense, and measure its cost:** do not expose the raw output (round or aggregate it, or return only what the caller needs); refresh the random seed or key periodically; limit queries per client (rate limits are part of the defense, `BEHAVIOR-TRAPS.md`); use an adversarially robust construction (sketch switching, or techniques borrowed from differential privacy; Ben-Eliezer, Jayaram, Woodruff, and Yogev, PODS 2020), which costs extra space; or use a deterministic structure with a worst-case bound.
+2. **Then choose a defense, and measure its cost:** do not expose the raw output (round or aggregate it, or return only what the caller needs); refresh the random seed or key periodically; limit queries per client (rate limits are part of the defense, `BEHAVIOR-TRAPS.md`); use an adversarially robust construction (sketch switching, Ben-Eliezer, Jayaram, Woodruff, and Yogev, PODS 2020; or techniques borrowed from differential privacy, Hassidim, Kaplan, Mansour, Matias, and Stemmer, NeurIPS 2020), which costs extra space; or use a deterministic structure with a worst-case bound.
 3. **Report the adversary model** next to the bound: "expected O(1) against an oblivious adversary; an adaptive client can observe iteration order, so worst case O(n) per operation."
 
 ## Algorithmic complexity attacks
@@ -66,8 +66,8 @@ Measure the maximum and the highest percentiles over long runs, never the median
 ## References (for verifying claims; not required reading)
 
 - Moritz Hardt and David P. Woodruff, "How Robust Are Linear Sketches to Adaptive Inputs?", STOC 2013.
-- Omri Ben-Eliezer, Rajesh Jayaram, David P. Woodruff, and Eylon Yogev, "A Framework for Adversarially Robust Streaming Algorithms," PODS 2020.
-- Sara Ahmadian and Edith Cohen, "Unmasking Vulnerabilities: Cardinality Sketches under Adaptive Inputs," ICML 2024; Edith Cohen, Jelani Nelson, Mihir Singhal, et al., "One Attack to Rule Them All: Tight Quadratic Bounds for Adaptive Queries on Cardinality Sketches," SODA 2026.
+- Omri Ben-Eliezer, Rajesh Jayaram, David P. Woodruff, and Eylon Yogev, "A Framework for Adversarially Robust Streaming Algorithms," PODS 2020; Avinatan Hassidim, Haim Kaplan, Yishay Mansour, Yossi Matias, and Uri Stemmer, "Adversarially Robust Streaming Algorithms via Differential Privacy," NeurIPS 2020.
+- Sara Ahmadian and Edith Cohen, "Unmasking Vulnerabilities: Cardinality Sketches under Adaptive Inputs," ICML 2024; Edith Cohen, Jelani Nelson, Tamás Sarlós, Mihir Singhal, and Uri Stemmer, "One Attack to Rule Them All: Tight Quadratic Bounds for Adaptive Queries on Cardinality Sketches," SODA 2026.
 
 - Scott A. Crosby and Dan S. Wallach, "Denial of Service via Algorithmic Complexity Attacks," USENIX Security 2003.
 - M. Douglas McIlroy, "A Killer Adversary for Quicksort," *Software: Practice and Experience* 29(4), 1999; David R. Musser, "Introspective Sorting and Selection Algorithms," *Software: Practice and Experience* 27(8), 1997.
diff --git a/skills/techniques/machine-learning.md b/skills/techniques/machine-learning.md
index 8d94a06..707950d 100644
--- a/skills/techniques/machine-learning.md
+++ b/skills/techniques/machine-learning.md
@@ -27,7 +27,7 @@ For code that prepares data, trains or runs models (classical machine learning,
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
 | Product of several matrices, or matrices applied to a vector, multiplied in a fixed order | Choose the multiplication order: matrix chain DP, or simply right-to-left when the chain ends in a vector, (A·B)·v → A·(B·v) | Floating-point results can differ in the last bits (behavior change if exact output matters) | For n×n matrices and a vector: O(n³) → O(n²); in general, the minimum-cost order |
-| Gradients of a scalar loss with respect to many parameters computed by perturbing each parameter | Reverse-mode automatic differentiation (backpropagation) | The function is differentiable where evaluated | O(n) evaluations for n parameters → about one forward and one backward pass |
+| Gradients of a scalar loss with respect to many parameters computed by perturbing each parameter | Reverse-mode automatic differentiation (backpropagation) | The function is differentiable where evaluated. Finite differences are approximate and automatic differentiation is exact up to rounding, so the gradients and everything trained from them change: behavior change | O(n) evaluations for n parameters → about one forward and one backward pass |
 | Host and device synchronizing inside the training loop (reading a scalar loss value, moving a tensor to the CPU, printing or logging device values every step) | Keep values on the device, accumulate on the device, read back every k steps | What is logged and when changes (behavior change if logs are consumed) | Removes a stall per step |
 | Many small kernel launches per step | Operator fusion via the framework's compiler or graph mode | Results usually identical or within floating-point rounding; compilation adds startup time | Constant factor; fewer memory round trips |
 | Model or batch does not fit in device memory | Gradient checkpointing (recompute activations in the backward pass); gradient accumulation across smaller batches | Only when the current memory use exceeds the device budget at the required model or batch size: it trades time for memory, the exception to rule 2. Gradient accumulation can change results (batch normalization, floating-point summation order) | Activation memory O(L) → about O(√L) for L layers, for about one extra forward pass |
@@ -43,12 +43,12 @@ For code that prepares data, trains or runs models (classical machine learning,
 | Attention cost too high even with exact kernels | Sliding-window, sparse, or linear attention | **Changes the model**: requires retraining or produces different outputs. Developer decision | O(n²) → O(n·w) or O(n) |
 | Requests served one at a time on hardware that is idle between them | Dynamic batching; continuous (iteration-level) batching for generation | Latency per request may rise; results unchanged per request unless batch-dependent numerics apply | Throughput up several times |
 | KV cache memory fragmented, limiting batch size | Paged KV cache (fixed-size blocks with a block table) | — | More concurrent sequences in the same memory |
-| Decoding latency bound by one token per forward pass of a large model | Speculative decoding with a small draft model | With rejection sampling it preserves the output distribution; greedy outputs stay identical; individual sampled outputs differ for the same seed (behavior change if seeded outputs are compared) | Fewer large-model passes per token |
-| Full sort of the vocabulary for top-k or top-p sampling, or beam search | Partial selection (argpartition, heap of size k), then sort only the candidates | Tie order matches the original when it is observable | O(V log V) → O(V + k log k) per step |
+| Decoding latency bound by one token per forward pass of a large model | Speculative decoding with a small draft model | With rejection sampling it preserves the output distribution; greedy outputs stay identical up to floating point (batched verification can flip a near-tied choice); individual sampled outputs differ for the same seed (behavior change if seeded outputs are compared) | Fewer large-model passes per token |
+| Full sort of the vocabulary for top-k or top-p sampling, or beam search | Partial selection (argpartition, heap of size k), then sort only the candidates | Tie order matches the original when it is observable. For top-p the candidate count is not known in advance: select a top-k guess, and fall back to a larger k or a full sort whenever its cumulative probability is below p | O(V log V) → O(V + k log k) per step |
 | Byte-pair-encoding tokenizer that rescans the whole sequence for the best pair after every merge | Priority queue of candidate pairs over a linked list of tokens | Merge priority and tie order identical, so tokens are identical | O(n²) → O(n log n) per sequence |
 | Lower-precision or compressed weights | Quantization (8-bit, 4-bit), pruning, distillation | **Changes the model**: measure quality on the project's evaluation set. Developer decision | Less memory and faster inference |
-| Constrained (structured) generation that checks every vocabulary token against a grammar or regular expression at each step | Compile the grammar or expression into an automaton once, and precompute for each automaton state the set of allowed tokens (a token mask) | Same grammar semantics, tokenization, and handling of tokens that span grammar boundaries | O(V · check) per step → one mask lookup per step, plus O(V) to apply it |
-| Retrieval (for example, retrieval-augmented generation) that scans every document or chunk per query | Inverted index for keyword search (see "Strings" in `techniques/strings-and-text.md`); exact or approximate vector index for embeddings (see "Classical machine learning" and "Spatial data" in `techniques/spatial-data.md`) | Approximate vector search is a behavior change | O(corpus) per query → index lookups |
+| Constrained (structured) generation that checks every vocabulary token against a grammar or regular expression at each step | Compile the grammar or expression into an automaton once, and precompute for each automaton state the set of allowed tokens (a token mask) | Same grammar semantics, tokenization, and handling of tokens that span grammar boundaries. Full precomputation works for regular expressions (finite automata); for context-free grammars the parser's stack is unbounded, so precompute only the tokens whose validity does not depend on the stack and check the rest at each step | O(V · check) per step → one mask lookup per step, plus O(V) to apply it (regular expressions); most of the check removed (context-free grammars) |
+| Retrieval (for example, retrieval-augmented generation) that scans every document or chunk per query | Inverted index for keyword search (see "Strings" in `techniques/strings-and-text.md`); exact or approximate vector index for embeddings (see "Classical machine learning" below, and "Spatial data" in `techniques/spatial-data.md`) | Approximate vector search is a behavior change | O(corpus) per query → index lookups |
 | Re-embedding or reprocessing unchanged documents on every run | Cache results keyed by a hash of the content plus the model name and version and the preprocessing settings | Same model and preprocessing; bounded storage (rule 1) | Work proportional to changed documents |
 
 ### Classical machine learning
diff --git a/skills/techniques/math-and-numerics.md b/skills/techniques/math-and-numerics.md
index 2973657..02cd683 100644
--- a/skills/techniques/math-and-numerics.md
+++ b/skills/techniques/math-and-numerics.md
@@ -25,12 +25,12 @@ Floating-point results depend on the order and form of every operation. Most tec
 | Summing many floating-point values where accumulated rounding error matters | Kahan or Neumaier compensated summation (Neumaier also handles terms larger than the running sum) | Behavior change: results differ, usually closer to the exact sum. Strict floating-point semantics in the compiled code | Same O(n), a few more operations per element. Worst-case error bound grows with n for naive summation, and is nearly independent of n with compensation |
 | Floating-point sum that should be vectorized or parallelized | Pairwise (cascade) summation | Behavior change: results differ | O(n); error bound grows as O(log n) instead of O(n); splits naturally into independent chunks |
 | Sum must be identical regardless of order, chunking, or thread count | Reproducible summation: fixed-point integer accumulation, or an exact (superaccumulator) sum rounded once | Behavior change unless the original order was already fixed; value range is known for fixed point | Deterministic results that allow parallel and vectorized evaluation |
-| Variance or standard deviation computed as mean of squares minus square of mean, or in two passes | Welford's online algorithm | Behavior change: avoids catastrophic cancellation, so results differ | Two passes → one pass, O(1) memory |
+| Variance or standard deviation computed as mean of squares minus square of mean (one pass, but loses precision to catastrophic cancellation), or in two passes (accurate, but reads the data twice) | Welford's online algorithm | Behavior change: results differ. Against the mean-of-squares formula it is far more accurate; against the two-pass algorithm it is no more accurate (sometimes slightly less) and costs a division per element, so the gain is one pass, not accuracy | Two passes → one pass, O(1) memory |
 | Polynomial evaluated by computing each power separately | Horner's method | Behavior change in floating point (different rounding); exact for integers without overflow | O(n²) or O(n log n) multiplications → O(n) |
 | Dense matrix multiplication written as a triple loop | An optimized BLAS library (blocked, vectorized, multithreaded); Strassen-type algorithms only for very large matrices | BLAS may sum in a different order (results differ in the last bits); Strassen is less numerically stable: both are behavior changes for exact-bit callers | Constant factors of ten or more from BLAS; O(n³) → O(n^2.81) with Strassen at large n |
 | Large sparse symmetric positive-definite linear systems solved by dense elimination | Conjugate gradient with a preconditioner | The matrix is symmetric positive definite; results are approximate to a stated tolerance (behavior change against an exact solver) | O(n³) → about O(nonzeros × iterations) |
 | Integrals computed with many equally spaced evaluations (fixed-step trapezoid or Simpson rule) | Gaussian quadrature for smooth integrands; adaptive quadrature (Gauss-Kronrod) that refines only where the error estimate is large | Results change within the tolerance: a behavior change; the integrand's smoothness checked | Far fewer function evaluations for the same accuracy |
-| Smooth optimization by plain gradient descent taking thousands of small steps | Newton's method for small problems; quasi-Newton (L-BFGS) for large ones; with a line search | The objective is smooth and gradients are available; the iterates and the final point within tolerance differ (behavior change) | Many more iterations → superlinear convergence near the optimum |
+| Smooth optimization by plain gradient descent taking thousands of small steps | Newton's method for small problems; quasi-Newton (L-BFGS) for large ones; with a line search | The objective is smooth and gradients are available; Newton also needs Hessians (or Hessian-vector products) and a safeguard when the Hessian is not positive definite; the iterates and the final point within tolerance differ (behavior change) | Many more iterations → quadratic convergence near the optimum for Newton, superlinear for full BFGS; L-BFGS is proven only linear, though usually far faster than gradient descent in practice |
 | Same linear system solved for many right-hand sides | Factorize once (LU, Cholesky, QR), then solve per right-hand side | Matrix does not change between solves; results may differ in the last bits | O(n³) per solve → O(n³) once + O(n²) per solve |
 | Matrices or vectors that are mostly zeros | Sparse formats (CSR, CSC, COO) and sparse kernels | Density below a measured threshold (dense kernels win above it); summation order in the kernel may change floating-point results | O(n²) per matrix-vector product → O(nnz), with O(nnz) memory |
 | Tight numeric loops in floating point | SIMD-friendly kernels: contiguous data, no aliasing, no data-dependent branches; vectorized math libraries | Vectorized reductions reorder additions (behavior change); vectorized math functions may round differently | Several times faster per core |
@@ -44,7 +44,7 @@ Quantum simulators and circuit compilers are classical programs with exponential
 |---|---|---|---|
 | Circuits made only of Clifford gates (Hadamard, phase, CNOT, Pauli gates, measurement) simulated with a full state vector | Stabilizer (tableau) simulation | Only Clifford gates; with a few non-Clifford gates, extended stabilizer methods cost exponential only in the number of those gates | Memory 2ⁿ amplitudes → O(n²) bits; O(n) per gate, O(n²) per measurement |
 | State-vector memory of 2ⁿ amplitudes limits the qubit count, on circuits with limited entanglement | Tensor-network or matrix-product-state simulation, with the contraction order chosen by a heuristic optimizer | Exact only without bond-dimension truncation; truncation is approximate (behavior change); cost depends heavily on contraction order, so measure it | Cost exponential in entanglement or treewidth instead of qubit count |
-| Many measurement shots sampled by re-running the whole simulation per shot | Simulate once and draw all shots from the final probability distribution | No mid-circuit measurements or noise that depends on earlier outcomes; seeded sampling reproduces the original's sample only if the random draws match | Shots × simulation → one simulation plus sampling |
+| Many measurement shots sampled by re-running the whole simulation per shot | Simulate once and draw all shots from the final probability distribution | The final state is pure, or the simulator tracks the full density matrix: no mid-circuit measurements, resets, classically controlled gates, or noise simulated per shot as random trajectories (each shot then follows a different state); seeded sampling reproduces the original's sample only if the random draws match | Shots × simulation → one simulation plus sampling |
 | Mapping a circuit onto hardware connectivity (qubit routing) by exhaustive search | Heuristic routing such as SABRE, with several random trials | The problem is NP-hard: results are not optimal, and a different routed circuit with a different gate count is a behavior change | Exponential search → polynomial per trial: linear in the number of gates, polynomial in the number of qubits |
 
 ## References (for verifying claims; not required reading)
diff --git a/skills/techniques/optimization-and-scheduling.md b/skills/techniques/optimization-and-scheduling.md
index 2d2bf09..ddb293b 100644
--- a/skills/techniques/optimization-and-scheduling.md
+++ b/skills/techniques/optimization-and-scheduling.md
@@ -18,7 +18,7 @@ For code that searches for the best assignment, schedule, route, packing, or all
 |---|---|---|---|
 | Assigning n workers to n jobs at minimum total cost by trying permutations | Hungarian algorithm, or min-cost bipartite matching | One worker per job; costs additive; rectangular cases padded | O(n!) → O(n³) |
 | Shipping supply to demand at minimum cost, or any assignment with capacities | Min-cost flow (transportation problem) | Costs linear in the amounts; integer capacities give integer optimal solutions | Exponential search → polynomial; network-simplex solvers are fast in practice |
-| An integer program whose constraint matrix is a network or bipartite incidence matrix | Solve it as a linear program or a flow: totally unimodular constraints have integer optimal solutions at the vertices | The matrix is totally unimodular (flows, bipartite matching, interval constraints with consecutive ones) | NP-hard in general → polynomial |
+| An integer program whose constraint matrix is a network or bipartite incidence matrix | Solve it as a linear program or a flow: totally unimodular constraints have integer optimal solutions at the vertices | The matrix is totally unimodular (flows, bipartite matching, interval constraints with consecutive ones), and the right-hand sides and variable bounds are integers; with fractional data the LP optimum can be fractional | NP-hard in general → polynomial |
 | Choosing a subset of projects with prerequisites to maximize profit | Maximum-weight closure via minimum cut | Prerequisites form a directed graph; profits and costs additive | Exponential subsets → one max-flow computation |
 | Greedy selection by weight (choose the most valuable items subject to independence rules) | Prove the feasible sets form a matroid (forests in a graph, linearly independent sets, sets with at most k from each group); then greedy by weight is optimal | The exchange property holds; it fails for knapsack-like capacity limits | Exponential → O(n log n) plus independence checks |
 | One machine, minimize average or weighted completion time | Shortest processing time first; Smith's rule (sort by processing time divided by weight) for weights | Jobs available at time zero, no preemption | O(n!) → O(n log n) |
@@ -70,7 +70,7 @@ Many systems decisions must be made before the future is known: whether to keep
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
 | Paying a repeated cost or a one-time cost without knowing how often the need recurs: spin or block (adaptive locks), scan or build an index, recompute or cache, interpret or compile (JIT tiers), reconnect or keep a connection | Ski rental: keep paying the repeated cost until it adds up to the one-time cost, then pay the one-time cost | The two costs are measured; changing the threshold changes timing, not results | Never more than twice the hindsight-optimal cost (deterministic); about 1.58 times with a randomized threshold |
-| Choosing a cache eviction policy and judging how good it is | Compare against Belady's optimal policy (evict the item used furthest in the future), computed offline on a recorded access trace; LRU and FIFO are k-competitive for a cache of k items | A representative trace is available; see "Caching and eviction" in `techniques/data-structures.md` for the policies | Shows how much hit rate any policy could still gain on this workload |
+| Choosing a cache eviction policy and judging how good it is | Compare against Belady's optimal policy (evict the item used furthest in the future), computed offline on a recorded access trace; LRU and FIFO are k-competitive for a cache of k items | A representative trace is available; Belady's policy is optimal only when every item has the same size and miss cost (with variable sizes, as in byte-capacity caches, the exact offline optimum is NP-hard, so compare against a published bound instead); see "Caching and eviction" in `techniques/data-structures.md` for the policies | Shows how much hit rate any policy could still gain on this workload |
 | Jobs arriving one at a time must be assigned to identical machines | List scheduling: assign each job to the least-loaded machine (a heap of loads) | Jobs cannot be reassigned later; if all jobs are known first, sort them longest first ("Heuristics with guarantees") | Within 2 − 1/m of the optimal finishing time for m machines; O(log m) per job |
 | Items arriving one at a time must be packed into bins | First fit (place in the first bin with room) | Approximate packing accepted; if all items are known first, use first-fit decreasing | At most 1.7 times the optimal number of bins |
 
diff --git a/skills/techniques/sequences-dp-search.md b/skills/techniques/sequences-dp-search.md
index d6808ec..263906d 100644
--- a/skills/techniques/sequences-dp-search.md
+++ b/skills/techniques/sequences-dp-search.md
@@ -41,7 +41,7 @@ Part of the advanced techniques. The shared rules in `ADVANCED-TECHNIQUES.md` ap
 | Shuffling by sorting with a random comparator (`sort(() => Math.random() - 0.5)`), or by repeatedly removing a random element from a list | Fisher-Yates shuffle (Knuth's Algorithm P): swap each position with a random position at or before it | **Behavior change**: the random comparator is also biased (some orders are more likely than others, depending on the sort algorithm), so a correct shuffle produces a different distribution; and any shuffle draws random numbers differently, so seeded sequences change | O(n log n) or O(n²) → O(n), with every permutation equally likely |
 | Enumerating all subsets and re-scoring each one from scratch | Gray-code order: consecutive subsets differ by one element (binary reflected Gray code), so the score is updated by adding or removing one element | The score can be updated incrementally; **behavior change** if callers see the enumeration order | O(n · 2^n) → O(2^n) plus one update per step |
 | Enumerating all k-element combinations and re-scoring each | Revolving-door order (each combination differs from the previous by swapping one element in and one out) | Incremental score update; enumeration order matches or is not observable | O(k) per combination → one swap update |
-| Enumerating all permutations and re-scoring each one | Heap's algorithm or Steinhaus-Johnson-Trotter (each permutation differs from the previous by one swap or one adjacent swap), with an incremental score update; Knuth's Algorithm L when lexicographic order is required | Order matches the original's (lexicographic only with Algorithm L), or is not observable | O(n) work per permutation → O(1) amortized generation plus one swap update |
+| Enumerating all permutations and re-scoring each one | Heap's algorithm or Steinhaus-Johnson-Trotter (each permutation differs from the previous by one swap or one adjacent swap), with an incremental score update; Knuth's Algorithm L when lexicographic order is required | Order matches the original's (lexicographic only with Algorithm L), or is not observable | O(n) work per permutation → O(1) amortized generation plus one swap update (Algorithm L: a swap plus a suffix reversal, O(1) amortized element changes) |
 
 ## After NP-hardness
 
diff --git a/skills/techniques/strings-and-text.md b/skills/techniques/strings-and-text.md
index dc7158e..1d614ce 100644
--- a/skills/techniques/strings-and-text.md
+++ b/skills/techniques/strings-and-text.md
@@ -7,16 +7,16 @@ Part of the advanced techniques. The shared rules in `ADVANCED-TECHNIQUES.md` ap
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
 | Many substring or repeated-pattern queries on a static text | Suffix array + LCP array (a suffix tree answers the same queries with several times more memory) | Text does not change; enough queries to amortize the build | Build: O(n log n), or O(n) with SA-IS; O(n) memory. Query: O(m log n) for a pattern of length m, plus O(k) to report k occurrences, instead of O(n·m) per scan |
-| Searching a long text for one long pattern over a large alphabet, with a hand-written search loop | Boyer-Moore or Boyer-Moore-Horspool (skip ahead by mismatch tables), or the platform's optimized search, which often already uses them or two-way matching | Same matching semantics (case, overlapping matches, Unicode units) | O(n·m) → sublinear on average, O(n/m) in the best case |
+| Searching a long text for one long pattern over a large alphabet, with a hand-written search loop | Boyer-Moore or Boyer-Moore-Horspool (skip ahead by mismatch tables), or the platform's optimized search, which often already uses them or two-way matching | Same matching semantics (case, overlapping matches, Unicode units) | O(n·m) → sublinear on average, O(n/m) in the best case; the worst case stays O(n·m) for Horspool, and is O(n + m) for full Boyer-Moore with the Galil rule |
 | Distinct substrings, longest repeated or common substring | Suffix automaton | — | O(n²) or worse → O(n) build |
 | Longest palindromic substring, all palindromes | Manacher's algorithm | Same unit of text as the original: bytes, code units, code points, or user-visible characters give different palindromes | O(n²) → O(n) |
 | Border and period detection | Prefix function (KMP failure function) | — | O(n²) → O(n) |
 | Edit distance when only small distances matter | Banded (Ukkonen) edit distance | A threshold k is known | O(n·m) → O(n·k) |
-| Regular expression with nested or overlapping quantifiers (`(a+)+`, `(a\|a)*`, `.*.*x`), run by a backtracking engine on long or untrusted input | Rewrite the pattern to remove the ambiguity (atomic groups or possessive quantifiers where supported), or switch to a linear-time engine (Thompson NFA or lazy DFA, such as RE2, Rust's `regex`, Go's `regexp`) | Linear-time engines do not support backreferences or lookaround; match semantics must be checked one by one: leftmost-first versus leftmost-longest, capture group contents, Unicode classes, anchors and line modes. A new engine is usually a dependency (rule 7) | Exponential worst case → O(n·m) for text length n and pattern size m |
+| Regular expression with nested or overlapping quantifiers (`(a+)+`, `(a\|a)*`, `.*.*x`), run by a backtracking engine on long or untrusted input | Rewrite the pattern to remove the ambiguity (atomic groups or possessive quantifiers where supported), or switch to a linear-time engine (Thompson NFA or lazy DFA, such as RE2, Rust's `regex`, Go's `regexp`) | Linear-time engines do not support backreferences or lookaround; match semantics must be checked one by one: leftmost-first versus leftmost-longest, capture group contents, Unicode classes, anchors and line modes. A new engine is usually a dependency (rule 7) | Exponential worst case for nested quantifiers such as `(a+)+`, polynomial (cubic for an unanchored search) for patterns such as `.*.*x` → O(n·m) for text length n and pattern size m |
 | Many regular expressions tried one after another on the same input | One combined alternation, or a regex set that reports every pattern that matched in one pass | Which pattern wins, and in which priority order, matches the original | k passes over the input → one pass |
 | Keyword or term search across many documents by scanning each one | Inverted index: each term maps to a sorted list of the documents (and positions) containing it; ranking such as BM25 computed over those lists only; multi-term queries intersect lists | Tokenization, normalization, matching rules, and result order reproduce the original | O(total text) per query → O(length of the posting lists for the query terms) |
 | Multi-term ranked search that scores every document in the union of the posting lists, then sorts | Dynamic pruning for top-k retrieval: MaxScore, WAND, or Block-Max WAND, using per-term (and per-block) upper bounds on score contributions to skip documents that cannot enter the current top k | The scoring function is a sum of per-term contributions with known maxima; ties at the k-th score are broken as in the original | Most postings skipped; same top k as exhaustive scoring |
-| Intersecting posting lists or sorted ID sets of very different lengths | Galloping (exponential) search from the shorter list into the longer one, or skip pointers stored in the lists | Lists sorted by the same order; duplicates handled as the original does | O(m + n) → O(m log(n / m)) for lists of lengths m ≤ n |
+| Intersecting posting lists or sorted ID sets of very different lengths | Galloping (exponential) search from the shorter list into the longer one, or skip pointers stored in the lists | Lists sorted by the same order; duplicates handled as the original does | O(m + n) → O(m · (1 + log(n / m))) for lists of lengths m ≤ n |
 | Sorting many strings that share long prefixes (paths, URLs, composite keys), where each comparison rescans the shared prefix | Multikey (three-way radix) quicksort: partition on one character at a time, recursing into the "equal" part on the next character | The order equals the original comparator's: plain code-unit or byte order, not locale collation or case-insensitive comparison | O(n log n) full-string comparisons → O(n log n + D) character comparisons expected, where D is the total length of the distinguishing prefixes |
 | Prefix search, autocomplete, or near-neighbor search over a large string set, where a trie with one child slot per alphabet symbol uses too much memory | Ternary search trie: each node holds one character and three children (less, equal, greater) | Same matching rules (case, normalization) and result order as the original | O(k + log n) per lookup for a key of length k in a balanced tree, with memory proportional to the stored characters |
 | Diffing two sequences (lines, tokens, characters, list items) with the full O(N·M) longest-common-subsequence table | Myers' O((N + M) · D) algorithm, where D is the edit distance, with its linear-space variant; Hunt-Szymanski when matches are rare | Same edit script: Myers returns a shortest edit script, but when several exist it may choose a different one than another algorithm, and patience or histogram diff choose different (often more readable) ones: a **behavior change** where the script is shown or stored | O(N·M) time and memory → O((N + M) · D) time and O(N + M) memory; fast when the inputs are similar |
@@ -30,12 +30,12 @@ For lexers, tokenizers, regular-expression engines, protocol and file-format par
 
 | Signal | Technique | Valid when | Typical result |
 |---|---|---|---|
-| A lexer that tries each token pattern in turn at every position | One combined deterministic finite automaton (DFA) over all token patterns, generated or hand-built | Longest-match and pattern-priority rules match the original | O(n · patterns) → O(n) |
+| A lexer that tries each token pattern in turn at every position | One combined deterministic finite automaton (DFA) over all token patterns, generated or hand-built | Longest-match and pattern-priority rules match the original. Longest match makes the DFA back up after overshooting, which is O(n²) in the worst case for some token sets (tokens `a` and `a*b` on `aaaa…`); Reps' memoized tokenizer restores O(n) | O(n · patterns) → O(n) for typical token sets |
 | Large DFA tables (many states, poor cache fit) | DFA minimization (Hopcroft's algorithm), equivalence classes of input bytes to shrink the alphabet | The recognized language is unchanged, which minimization guarantees | Build O(s · σ log s) for s states and alphabet σ; fewer states and smaller tables |
 | A protocol or format parser that rescans the buffer, or restarts when input arrives in pieces (network packets, streamed files) | Explicit state machine that consumes each byte once and keeps its state across buffer boundaries | Same results for every way the input can be split into chunks; limits on header and field sizes kept | O(n · chunks) when each chunk restarts the scan → O(n) |
 | A backtracking parser (recursive descent with backtracking, parsing expression grammars) that is slow or exponential on some inputs | Packrat parsing: memoize each (rule, position) result | Rules are pure; ordered-choice semantics kept; memory O(n · rules) is acceptable, or memoize only the rules that backtrack | Exponential worst case → O(n · rules) |
 | Arithmetic or filter expressions evaluated by repeatedly scanning for the highest-precedence operator and rewriting the string | Dijkstra's shunting-yard algorithm: one pass with an operator stack produces postfix order (or a tree), then one evaluation pass | Same precedence, associativity, unary-operator handling, and errors for malformed input | O(n²) → O(n) |
-| General context-free parsing by exhaustive backtracking or the CYK algorithm | Earley, GLR, or GLL parsing; or a deterministic LL or LR parser when the grammar allows | Same parse result, including which parse is chosen for ambiguous input | Exponential or O(n³) → O(n³) worst case, O(n) for deterministic grammars |
+| General context-free parsing by exhaustive backtracking or the CYK algorithm | Earley, GLR, or GLL parsing; or a deterministic LL or LR parser when the grammar allows | Same parse result, including which parse is chosen for ambiguous input | Exponential or O(n³) → O(n³) worst case (Earley; GLR only in its binarized variants, since plain Tomita GLR is O(n^(k+1)) for rules of length k), O(n²) for unambiguous grammars with Earley, and O(n) for deterministic LL or LR parsers, or Earley with Leo's modification on LR(k) grammars |
 
 ## Combinations