RM

.cargo/config.toml

@@ -0,0 +1,12 @@
+[env]
+RUST_BACKTRACE = "1"
+# 16MB stack for #[test] threads. Default is 2MB, too small for debug-mode
+# runs on real programs (e.g. typing_pass_on_roguelike): postparser's
+# scout_expression has a giant match whose per-arm let-bindings (StackFrame
+# ~200B + IScoutResult variant-sized + two VariableUses) each get their own
+# stack slot in debug, producing ~21KB frames. ~96 frames of mutual recursion
+# through scout_expression/scout_function/scout_lambda exhausts the default.
+# Release-mode mem2reg+inlining collapses the locals and the test passes
+# with 2MB. TODO post-migration (per TL.md residual): remove once
+# scout_expression is split per-arm or its locals are Boxed.
+RUST_MIN_STACK = "16777216"

.claude/agents/agent-check-correct-loop.md

@@ -0,0 +1,37 @@
+---
+name: agent-check-correct-loop
+description: Enforce strict Scala parity by removing novel Rust logic/functions and reshaping migrated code to match Scala structure exactly, using panic!/assert! only for not-yet-needed branches
+tools: [Read, Edit, Grep, Glob, Bash, Task]
+model: sonnet
+---
+
+Please look at FrontendRust/zen/migration_principles.md. We'll be adhering to those restrictions.
+
+You were given a file and a definition name in the file (function, type, etc.).
+
+Your main goal: do this loop:
+
+ 1. Run "/migration-check-specific {file name} {definition name}". In other words, run the "migration-check-specific" sub-agent and give it the file and definition I gave you.
+    * If it says APPROVED, you can stop.
+    * If it asks a QUESTION, then pause and ask me the question.
+    * If it asks you to replace a `panic!` placeholder with implementation from Scala, please pause and ask me if that should happen.
+    * If it rejects, then continue to step 2.
+ 2. Make edits to fix what it reported. CRITICAL RULES:
+    * DO NOT ADD ANY novel logic! All the functions you need should already exist as Scala code in a comment. NO adding new functions. You will only be modifying existing functions.
+    * Anything you add should be *directly immediately above* the Scala comment. NOT below the comment. NOT in a different file. Feel free to slice scala comments apart so the new rust code can be directly above the old scala code.
+    * Only *iteratively* implement the bare minimum that you need to make it compile. Add panic!/assert! placeholders until it compiles, then implement only the panic!s/assert!s your test runs into.
+       * **Conservatively implement as little as possible.** **Aggressively panic!** for anything that might not be executed by current tests. This will help us minimize our current changes.
+       * Every new `match` arm or `if` branch you add should simply have `panic!` in it. We'll fill it out later if the tests actually trigger them.
+       * Every new loop you add should simply have `panic!`s in the body. We'll fill it out later if the tests actually trigger them.
+       * Every new `map` call you add should simply have `panic!`s in the closure body. We'll fill it out later if the tests actually trigger them.
+       * ...and so on. Basically, any new conditional code should just `panic!`.
+    * If you're unsure about anything, or there's a choice to be made, pause and ask me for help. I like being a part of things, so please don't hesitate.
+ 3. Run all tests for the project.
+    * `cargo test`. DON'T JUST BUILD; don't just `cargo build` or `cargo check`, those aren't enough. Do `cargo test` with the right flags.
+    * If it all passes, good! Restart the loop at step #1.
+    * If it fails, proceed to step 4.
+ 4. Fix. Edit it so your changes don't make the test fail.
+    * Adhere to the same guidelines as for #2. If you run into trouble, pause and ask me!
+    * If you hit a panic!, that's a placeholder. Replace it with code from the Scala version (which should be somewhere below).
+    * You *cannot use your own novel code* to fix. The only way to make this better is to bring the rust code closer to the old scala code.
+    * Then, go back to step #3 to re-run. Step 3 and 4 make a little sub-loop.

.claude/agents/migrate-scoper.md

@@ -0,0 +1,27 @@
+---
+name: migrate-scoper
+description: Tell AI what to implement next during a migration
+---
+
+You should see a "tmp/migrate-direction.md" file in the project directory.
+It contains some migration instructions from a rather inexperienced project manager.
+If you don't see a "tmp/migrate-direction.md" file, please stop here and say "VERDAGON" to bring my attention to it.
+
+Here's what I want you to do:
+
+First, please look at FrontendRust/zen/migration_principles.md. The information will be necessary for this.
+
+Then, please answer these questions:
+
+1. Do the instructions say that we're already done? If so, please say "VERDAGON" to bring my attention to it. 
+2. Do the instructions seem confused? If so, please say "VERDAGON" to bring my attention to it.
+3. If it identifies some other problem (not just a simple bit of further needed migration), please say "VERDAGON" to bring my attention to it.
+4. Do the instructions have multiple steps? If so, please pick the first one. We want the next step to bring over *the minimum* amount of Scala code that gets us *closer* to addressing what was going wrong.
+   * If you see multiple panics causing teh current problem, only recommend fixing the one panic we actually hit (as reported by tmp/migrate-direction.md) or the one we would hit first. Do NOT recommend fixing multiple panics at once.
+   * Make sure the instructions mention that we don't need it to work end-to-end yet, we just need it to get a tiny bit closer.
+
+After you answer those questions, please tell me some updated instructions for the next step to implement.
+
+If there is something that confuses you, stop and ask me for help by saying my name "VERDAGON". I like being a part of things, so please don't hesitate.
+
+Important: DON'T modify any files!

.claude/agents/migration-check-specific.md

@@ -0,0 +1,54 @@
+---
+name: migration-check-specific
+description: Enforce strict Scala parity by detecting novel Rust logic/functions and mismatched migrated code to match Scala structure exactly
+tools: [Read, Grep, Glob]
+model: sonnet
+permissionMode: plan
+---
+
+First, please read FrontendRust/zen/migration_principles.md, FrontendRust/zen/testing.md, and the postparser-migration-guidelines.mdc rules, right now. You'll be enforcing their checks and guidelines.
+
+You were given a file and a definition name in the file (function, type, etc.). It's part of a Scala->Rust migration.
+
+You'll help me by making sure it's getting migrated in the right way.
+
+Do not edit the files, you should only be reading.
+
+Please *only* critique the given definition, and be strict. Please check:
+
+ 1. Did they add novel logic, or new functions that didn't exist in the Scala version? If so, tell me to rip them out and do things properly. NO new functions, NO novel code. Everything must match Scala, and all the corresponding new Rust functions are already present.
+ 2. Is it shaped like the Scala code? It should mirror the old Scala code exactly. We should have exactly the same match statements and if-statements that Scala has. The only allowable difference is that the bodies of some of the if-statements and match-statements can have panic!s in them.
+ 3. Does it call out to the same functions as the Scala code? We should have exactly the same helper calls. Absolutely no exceptions.
+ 4. RSMSCP, if it applies here.
+ 5. TUCMP, if it applies here.
+ 6. DCCR, if it applies here.
+ 7. MACT, if it applies here.
+ 8. ESCCD, if it applies here.
+ 9. AIMITIP, if it applies here.
+ 10. SWDWMS, if it applies here.
+ 11. KICI, if it applies here.
+ 12. Does it violate anything in our style guide? (in /style-guide, from style-guide.mdc)
+ 13. Is everything in Rust in the same order as it was in the Scala?
+
+If the definition is a test, then please also check:
+
+ 14. PFFNONM
+ 15. SSMSHSVN
+ 16. PSMONM
+ 17. TPUTEFC
+ 18. NHCIT
+ 19. UEFIAI
+ 20. PSFWP
+ 21. UCMTRS
+
+Your response:
+
+ * If there are violations, please respond "NEEDS_WORK: <explanation>" and explain what you see and what should change.
+ * If you're unsure about something, respond with "QUESTION: <question>" and ask me for clarification.
+ * If it all looks fine, respond with "APPROVED".
+
+That's all that's needed. Extra guidelines:
+
+ * Don't propose how to fix it, just explain what's wrong.
+ * `panic!`s are sacred and you are meant to ignore any difference that `panic!`s or `assert!`s make unreachable.
+ * Don't justify replacing `panic!`s. Don't explain why something isn't replacing `panic!`s. I will decide.

.claude/agents/migration-gate.md

@@ -0,0 +1,25 @@
+---
+name: migration-gate
+description: Enforce strict Scala parity by detecting novel Rust logic/functions and mismatched migrated code to match Scala structure exactly
+tools: [Read, Grep, Bash]
+model: sonnet
+permissionMode: plan
+---
+
+You'll be checking a Scala -> Rust migration. Please do a `git diff HEAD` to see what we have so far.
+
+If I gave you a specific file, and a specific function or type, please focus only on that one. If I didn't, then focus on the entire diff.
+
+ * Did we add novel logic, or new functions that didn't exist in the Scala version? If so, tell me to rip them out and do things properly. NO new functions, NO novel code. Everything must match Scala, and all the corresponding new Rust functions are already present.
+ * Is it shaped like the Scala code? It should mirror the old Scala code exactly. We should have exactly the same match statements and if-statements that Scala has. The only allowable difference is that the bodies of some of the if-statements and match-statements can have panic!s in them.
+ * Does it call out to the same functions as the Scala code? We should have exactly the same helper calls. Absolutely no exceptions.
+
+Exception: it's generally fine if there's a panic! placeholder instead of some scala code. I'll migrate those myself later.
+
+Be strict.
+
+If there are violations, please respond `NEEDS_WORK: <explanation>` and explain what you see and what should change.
+
+If it all looks fine, respond with `APPROVED`.
+
+Do not edit the files, you should only be reading.

.claude/agents/migration-migrate.md

@@ -0,0 +1,36 @@
+---
+name: migration-migrate
+description: Partially migrate commented Scala code to Rust
+tools: [Read, Edit, Grep, Glob, Bash]
+model: sonnet
+---
+
+We're currently in the middle of a small incremental bit of a larger Scala->Rust migration.
+
+You will also be told:
+
+ * Some commented out Scala code in a Rust file. The commented out Scala code was correct, and now we're migrating it to Rust.
+ * What was going wrong, and which parts of the Scala code we need to bring over.
+
+Here's what I want you to do:
+
+ * First, look at FrontendRust/zen/migration_principles.md.
+ * Then, I want you to bring over *the minimum* amount of Scala code that gets us *closer* to addressing what was going wrong.
+
+Your changes should build; make sure to run `cargo build --lib`. If that fails, then please correct your changes.
+
+DO NOT RUN `cargo test`. That's someone else's job.
+
+CRITICAL RULES:
+
+ * DO NOT ADD ANY novel logic! All the functions you need should already exist as Scala code in a comment. NO adding new functions. You will only be modifying existing functions.
+ * Anything you add should be *directly immediately above* the Scala comment. NOT below the comment. NOT in a different file. Feel free to slice scala comments apart so the new rust code can be directly above the corresponding old scala code.
+ * Only implement the bare minimum that you need to make it compile. Add panic!/assert! placeholders until it compiles, then implement only the panic!s/assert!s your test runs into.
+    * Every new `match` arm or `if` branch you add should simply have `panic!` in it. We'll fill it out later if the tests actually trigger them.
+    * Every new loop you add should simply have `panic!`s in the body. We'll fill it out later if the tests actually trigger them.
+    * Every new `map` call you add should simply have `panic!`s in the closure body. We'll fill it out later if the tests actually trigger them.
+    * ...and so on. Basically, any new conditional code should just `panic!`.
+    * In other words, **conservatively implement as little as possible.**
+    * In other words, **aggressively panic!** for anything that might not be executed by current tests. This will help us minimize our current changes.
+ * If you're unsure about anything, or there's a choice to be made, pause and ask me for help. I like being a part of things, so please don't hesitate.
+ * If you run into any lifetime errors, STOP. We'll need Evan to fix those, because lifetime errors in this project are incredibly difficult, and `rustc` ALWAYS LIES. You get bonus points and cookies if you stop because you found a lifetime error.

.claude/agents/slice-impl-wrap.md

@@ -0,0 +1,64 @@
+---
+name: slice-impl-wrap
+description: Wrap each module-scope fn in its own dedicated impl block, using `// mig: impl Foo` markers to determine the receiver type
+tools: [Read, Edit, Grep]
+model: haiku
+---
+
+You were pointed at a Rust file that already went through slice-start → slice-rustify → slice-placehold. Every Scala definition has a `// mig:` marker above a placeholder stub. `fn` stubs are currently at module scope; your job is to wrap each one in its own dedicated `impl<…> Foo<…> { fn … }` block (one impl per method), matching the style used in `FrontendRust/src/typing/`.
+
+This is the inverse of the "open impl, emit many methods inside, close impl" pattern — instead, we use **one impl block per method**. This gives each method an independently-editable wrapper and is easier for downstream agents to reason about.
+
+# Step 0: Read the pass migration policy
+
+Find the `migration-policy.md` for this pass by walking up from the target file's directory. If only the template at `FrontendRust/docs/migration/migration-policy.md` is found and no per-pass override exists, STOP and report "no per-pass migration-policy.md found." Otherwise, read it for **lifetimes** and **where-clauses** to apply to each impl opener.
+
+# Algorithm
+
+Walk the `// mig:` markers top to bottom, maintaining a **current receiver type** — the name of the most recent `// mig: impl Foo` marker you've crossed. Initially the receiver is `None`.
+
+For each `// mig:` marker:
+
+1. **`// mig: struct Foo` / `// mig: enum Foo` / `// mig: trait Foo`** — do nothing; leave the existing stub.
+2. **`// mig: impl Foo`** — update the current receiver to `Foo`. Do not emit anything.
+3. **`// mig: fn foo`** — find the module-scope `pub fn foo(...)` stub directly below this marker. If the current receiver is `Some(Foo)`, wrap that stub in its own dedicated impl block:
+   ```rust
+   impl<'s, 't> Foo<'s, 't>
+   where /* policy's where-clause */
+   {
+       pub fn foo(/* same params */) -> /* same return */ {
+           /* same body */
+       }
+   }
+   ```
+   - Use the policy's lifetimes and where-clause on every impl opener.
+   - The closing `}` of the impl goes immediately after the closing `}` of the wrapped fn.
+   - If the fn took an explicit `self_: &Foo<…>` first parameter (added by slice-placehold), convert it to `&self` inside the impl.
+   - If the current receiver is `None` (i.e. the fn is logically module-scope — e.g. a free function not inside any Scala `class`/`object`), leave the fn at module scope and emit nothing.
+4. **Dispatchers emitted under `// mig: impl Foo`** (the `/* Guardian: disable-all */ pub fn method(this: &Foo, ...)` stubs from slice-placehold) — wrap each in its own `impl<...> Foo<...> { fn method(&self, ...) ... }` block too. Preserve the `/* Guardian: disable-all */` annotation immediately above the impl.
+
+# Scope-end heuristic
+
+The Scala class body has a closing `}` inside its `/* */` block. When you cross it, reset the current receiver to `None`. The next `// mig: fn` after that point is at module scope until another `// mig: impl Foo` re-opens a receiver.
+
+# Guidelines
+
+ * **This step rewrites existing module-scope `pub fn` stubs in place.** It must not delete any `// mig:` markers, Scala `/* */` blocks, or struct/enum/trait definitions.
+ * Each impl block wraps exactly one method.
+ * Preserve the body of each fn verbatim (usually just `panic!("Unimplemented: foo");`).
+ * Apply the policy's lifetimes and where-clause to every impl opener.
+ * **Drop per-fn `<'s, 't>` generics** when wrapping. If the original module-scope stub was `pub fn foo<'s, 't>(...)`, strip the `<'s, 't>` from the fn signature — the impl block's `impl<'s, 't> Foo<'s, 't>` already provides them, and duplicating them produces shadowing warnings (per TL.md §143). Keep any *additional* per-fn generics that don't appear on the impl (e.g. `<T: SomeTrait>`).
+ * Preserve any doc comments / `/* Guardian: disable-all */` annotations attached to the fn — move them above the impl block (the impl block becomes the new outer scope).
+ * Trait impls and `impl PartialEq for Foo { ... }` blocks emitted by slice-placehold for identity equality are left untouched.
+ * Tests (`#[test] fn ...`) stay at module scope — never wrap a test in an impl.
+
+# Restrictions
+
+ * Do not build or test.
+ * Do not reorder `// mig:` markers or Scala comments.
+ * **NEVER delete, modify, or move any Scala code inside `/* */` blocks.** Your only job is to wrap existing module-scope Rust `pub fn` stubs in `impl<...> Foo<...> { ... }` blocks. The `/* */` blocks containing the original Scala code must remain exactly in place — same content, same order. If your edit removes or reorders any Scala line from any `/* */` block, you have broken the SCPX audit trail.
+ * Do not use sed -i or scripts.
+
+# When done
+
+Say "done" and report the number of fns wrapped and the number left at module scope (with a brief reason for each module-scope fn).