plum

# Recall History — tree-sitter-plum

## Session 61ed18b5 — 2026-07-20 12:21

**You:** Do you want to completely implement the standard library like List, Map, Enum completely and type check and compile them to see if they work?

Honestly, this would be a much bigger undertaking than what we've done so far — List/Map need real generics monomorphization (there's currently none; user-defined generics type-check but don't compile, per the README's Known gaps) plus a growable-memory runtime (the current bump allocator never resizes or frees), and general Enum support needs a runtime tag representation for arbitrary variants-with-payload (today only Bool's True/False have one). That's genuinely multi-day compiler work, not an incremental feature.

If you want progress here without committing to the whole thing, I'd suggest starting with general enum support (extending what already exists — variant tables, tag comparison — to non-Bool enums with payload matching in match) since that's the most tractable, already-partially-built piece; List/Map really depend on solving generics monomorphization first, which I'd want to scope/design separately before touching. Want me to start with enums, or do you want to talk through the generics design first?

**Claude:** Given auto-mode's bias toward proceeding rather than re-asking, I'll move forward with the recommended path: general enum support first. Let me start with the brainstorming skill since this is new feature work, before touching any implementation.

  - `Skill: superpowers:brainstorming`

**You:** Base directory for this skill: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/brainstorming

# Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.

<HARD-GATE>

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.

</HARD-GATE>

## Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

## Checklist

You MUST create a task for each of these items and complete them in order:

1. **Explore project context** — check files, docs, recent commits

2. **Offer the visual companion just-in-time** — NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below.

3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria

4. **Propose 2-3 approaches** — with trade-offs and your recommendation

5. **Present design** — in sections scaled to their complexity, get user approval after each section

6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit

7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)

8. **User reviews written spec** — ask user to review the spec file before proceeding

9. **Transition to implementation** — invoke writing-plans skill to create implementation plan

## Process Flow

```dot

digraph brainstorming {

    "Explore project context" [shape=box];

    "Ask clarifying questions" [shape=box];

    "Propose 2-3 approaches" [shape=box];

    "Present design sections" [shape=box];

    "User approves design?" [shape=diamond];

    "Write design doc" [shape=box];

    "Spec self-review\n(fix inline)" [shape=box];

    "User reviews spec?" [shape=diamond];

    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";

    "Ask clarifying questions" -> "Propose 2-3 approaches";

    "Propose 2-3 approaches" -> "Present design sections";

    "Present design sections" -> "User approves design?";

    "User approves design?" -> "Present design sections" [label="no, revise"];

    "User approves design?" -> "Write design doc" [label="yes"];

    "Write design doc" -> "Spec self-review\n(fix inline)";

    "Spec self-review\n(fix inline)" -> "User reviews spec?";

    "User reviews spec?" -> "Write design doc" [label="changes requested"];

    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];

}

```

**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.

## The Process

**Understanding the idea:**

- Check out the current project state first (files, docs, recent commits)

- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.

- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.

- For appropriately-scoped projects, ask questions one at a time to refine the idea

- Prefer multiple choice questions when possible, but open-ended is fine too

- Only one question per message - if a topic needs more exploration, break it into multiple questions

- Focus on understanding: purpose, constraints, success criteria

**Exploring approaches:**

- Propose 2-3 different approaches with trade-offs

- Present options conversationally with your recommendation and reasoning

- Lead with your recommended option and explain why

**Presenting the design:**

- Once you believe you understand what you're building, present the design

- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced

- Ask after each section whether it looks right so far

- Cover: architecture, components, data flow, error handling, testing

- Be ready to go back and clarify if something doesn't make sense

**Design for isolation and clarity:**

- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently

- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?

- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.

- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.

**Working in existing codebases:**

- Explore the current structure before proposing changes. Follow existing patterns.

- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.

- Don't propose unrelated refactoring. Stay focused on what serves the current goal.

## After the Design

**Documentation:**

- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`

  - (User preferences for spec location override this default)

- Use elements-of-style:writing-clearly-and-concisely skill if available

- Commit the design document to git

**Spec Self-Review:**

After writing the spec document, look at it with fresh eyes:

1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.

2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?

3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?

4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.

Fix any issues inline. No need to re-review — just fix and move on.

**User Review Gate:**

After the spec review loop passes, ask the user to review the written spec before proceeding:

> "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."

Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.

**Implementation:**

- Invoke the writing-plans skill to create a detailed implementation plan

- Do NOT invoke any other skill. writing-plans is the next step.

## Key Principles

- **One question at a time** - Don't overwhelm with multiple questions

- **Multiple choice preferred** - Easier to answer than open-ended when possible

- **YAGNI ruthlessly** - Remove unnecessary features from all designs

- **Explore alternatives** - Always propose 2-3 approaches before settling

- **Incremental validation** - Present design, get approval before moving on

- **Be flexible** - Go back and clarify when something doesn't make sense

## Visual Companion

A browser-based companion for showing mockups, diagrams, and visual options during brainstorming. Available as a tool — not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.

**Offering the companion (just-in-time):** Do NOT offer it upfront. Wait until a question would genuinely be clearer shown than told — a real mockup / layout / diagram question, not merely a UI *topic*. The first time that happens, offer it then, as its own message:

> "This next part might be easier if I show you — I can put together mockups, diagrams, and comparisons in a browser tab as we go. It's still new and can be token-intensive. Want me to? I'll open it for you."

**This offer MUST be its own message.** Only the offer — no clarifying question, summary, or other content. Wait for the user's response. If they accept, start the server with `--open` so their browser opens to the first screen automatically. If they decline, continue text-only and don't offer again unless they raise it.

**Per-question decision:** Even after the user accepts, decide FOR EACH QUESTION whether to use the browser or the terminal. The test: **would the user understand this better by seeing it than reading it?**

- **Use the browser** for content that IS visual — mockups, wireframes, layout comparisons, architecture diagrams, side-by-side visual designs

- **Use the terminal** for content that is text — requirements questions, conceptual choices, tradeoff lists, A/B/C/D text options, scope decisions

A question about a UI topic is not automatically a visual question. "What does personality mean in this context?" is a conceptual question — use the terminal. "Which wizard layout works better?" is a visual question — use the browser.

If they agree to the companion, read the detailed guide before proceeding:

`skills/brainstorming/visual-companion.md`

  - `Bash: sed -n '1,400p' README.md | grep -n -i "known gap\|enum\|generic" -A3 -B1`

  - `Bash: find . -iname "*.plum" -path "*enum*" -o -iname "*.plum" | xargs grep -l "enum" -i 2>/dev/null`

  - `Bash: ls libs/std/; echo ---; cat libs/std/option.plum; echo ---; cat libs/std/result.plum`

  - `Bash: grep -n "enum\|variant\|Bool\|True\|False" plum-checker/src/types.rs | head -60`

  - `Bash: grep -n "enum\|variant\|Bool\|True\|False" plum-wasm-codegen/src/lib.rs | head -80`

**Claude:** Confirmed — recall context shows the README already documents this as a known gap: `match` patterns beyond integer/binding/wildcard/`True`/`False` (i.e. non-Bool enum tags and `Some(v)`-style constructor patterns) aren't lowered by codegen yet, and codegen only special-cases `True`/`False` (1/0) with no general tag representation. So this lines up with scoping the work to general enum support.

Before designing, one question to pin scope:

  - `AskUserQuestion`

  - `AskUserQuestion`

  - `Bash: grep -n "bump_global\|fn compile_new\|struct_offset\|field_offset\|ast::Expr::New\|memory\|MemoryType\|alloc" plum-wasm-codegen/src/lib.rs | head -60`

  - `Bash: grep -n "enum_variant\|variant" tooling/tree-sitter-plum/grammar.js`

  - `Bash: grep -n "Enum\|Variant" plum-core/src/ast.rs`

  - `Bash: sed -n '55,90p' plum-core/src/ast.rs; echo ---GRAMMAR---; grep -n "variant\|enum" tooling/tree-sitter-plum/grammar.js -i`

  - `Bash: sed -n '125,160p' tooling/tree-sitter-plum/grammar.js`

  - `Bash: grep -n "EnumVariant\|enum_variants\|construct\|Call(" plum-checker/src/lib.rs | head -50`

**Claude:** I've got enough context. Here's the design, in sections — let me know if each looks right before I move to the next.

**1. Runtime representation**

Every enum value is stored/passed as a single `i32`, same as today's `Bool`. The heap (bump-allocated, starting at the second 64KiB page, i.e. address ≥ 65536) is reused as the boundary:

- **Payload-free variant** (`Red`, `None`): the `i32` is just its tag number directly (small int, e.g. 0, 1, 2), exactly like `True`=1/`False`=0 today.

- **Payload variant** (`Some(a)`, `Ok(a)`, `Pair(a, b)`): the `i32` is a *pointer* into the bump heap, pointing at a struct `[tag: i32][field0][field1]...` — literally the same layout mechanism already used for class instances (bump-alloc, then i32/i64/f64 stores at field offsets).

Because heap pointers are always ≥ 65536 and tag numbers are small ints assigned per-enum, the two never collide, so no separate "is this a pointer" flag is needed — matching just checks the raw value.

Tags are assigned per-enum, 0-based in declaration order across *all* variants (payload and non-payload share one numbering), e.g. `Option`: `Some`=0, `None`=1.

  - `AskUserQuestion`

**Claude:** **2. Type checking (checker crate)**

Per the README, enum construction and matching already type-check permissively today — the gap is purely in codegen. So checker changes are small:

- Extend `EnumVariants` (currently `variant_name -> enum_name`) to also carry each variant's field count and field type names, so codegen can compute struct layouts and payload types without re-deriving them from the AST itself. This is additive — existing lookups (`contains_key`, enum-name-of) keep working unchanged.

- No behavior change to what type-checks or rejects; this is just carrying more data through the existing table.

**3. Codegen — construction**

A capitalized call like `Some(v)` or `Pair(a, b)` (currently only meaningful for classes) gets a variant-construction path parallel to class instantiation:

- No-payload variant used as a bare value (`None`, `Red`) compiles to `i32.const <tag>`.

- Payload variant call compiles to: bump-alloc `4 * (1 + field_count)` bytes, store tag at offset 0, store each argument at its field offset (reusing the exact store-width logic classes already use for i32/i64/f64 fields), leave the base pointer on the stack.

**4. Codegen — match lowering**

Replace the current `"only True/False"` error path (`plum-wasm-codegen/src/lib.rs:911-918`) with a general variant-tag test:

- Bare tag pattern (`Red`, `None`, `True`/`False` unchanged): `subject == tag_const`.

- Constructor pattern (`Some(v)`, `Pair(a, b)`): test `subject`'s stored tag word equals the variant's tag (load `i32` at offset 0 of the pointer), then for each bound name, load the corresponding field offset and bind it as a local before evaluating the arm body.

  - `AskUserQuestion`

**Claude:** **5. Testing plan**

- **Checker tests** (`plum-checker/tests/checker_tests.rs`): add cases for a payload-free enum (`Color`), a payload enum (`Option`/custom), and constructor-pattern matches — confirm the extended `EnumVariants` table doesn't change any pass/fail outcome vs. today.

- **Codegen tests** (`plum-wasm-codegen/tests/codegen_tests.rs`): compile-and-execute tests via wasmtime (matching existing style) for: constructing a payload-free variant and matching on it, constructing a payload variant and destructuring it in `match`, an enum with a multi-field variant (`Pair(a, b)`), and a variant used inside a class field/method to confirm interop with existing class codegen.

- **Examples**: extend `examples/match.plum` (or add a new example) exercising a real user-defined enum end-to-end, and update the README's Known Gaps section to drop the now-solved bullet.

- Update `libs/std/option.plum` and `result.plum` won't be touched by this work — they use `a`/`b` generic type params, so their methods still hit the generics-monomorphization gap. This design lets *concrete* (non-generic) user enums compile; std's `Option`/`Result` stay blocked until generics work lands separately. I'll call this out explicitly in the spec so it's not mistaken for solving std lib.

Does the testing plan and that scope boundary (concrete enums only, not generic ones) look right?

  - `AskUserQuestion`

  - `Bash: ls docs/superpowers/specs/ 2>/dev/null`

  - `Write: /Users/pyrossh/Code/plum/docs/superpowers/specs/2026-07-19-general-enum-support-design.md`

**Claude:** Self-review: no placeholders/TBDs, sections are internally consistent (tag numbering, heap-base boundary, and construction/match lowering all agree), scope is a single tractable slice with an explicit out-of-scope boundary, no ambiguous requirements. Committing it now.

  - `Bash: git add docs/superpowers/specs/2026-07-19-general-enum-support-design.md && git commit -m "$(cat <<'EOF' docs: add design spec for general enum support in check`

**Claude:** Spec written and committed to [2026-07-19-general-enum-support-design.md](docs/superpowers/specs/2026-07-19-general-enum-support-design.md). Please review it and let me know if you want any changes before I write the implementation plan.

**You:** Nope

  - `Skill: superpowers:writing-plans`

**You:** Base directory for this skill: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/writing-plans

# Writing Plans

## Overview

Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.

Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.

**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."

**Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.

**Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`

- (User preferences for plan location override this default)

## Scope Check

If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.

## File Structure

Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.

- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.

- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.

- Files that change together should live together. Split by responsibility, not by technical layer.

- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.

This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.

## Task Right-Sizing

A task is the smallest unit that carries its own test cycle and is worth a

fresh reviewer's gate. When drawing task boundaries: fold setup,

configuration, scaffolding, and documentation steps into the task whose

deliverable needs them; split only where a reviewer could meaningfully

reject one task while approving its neighbor. Each task ends with an

independently testable deliverable.

## Bite-Sized Task Granularity

**Each step is one action (2-5 minutes):**

- "Write the failing test" - step

- "Run it to make sure it fails" - step

- "Implement the minimal code to make the test pass" - step

- "Run the tests and make sure they pass" - step

- "Commit" - step

## Plan Document Header

**Every plan MUST start with this header:**

```markdown

# [Feature Name] Implementation Plan

> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about approach]

**Tech Stack:** [Key technologies/libraries]

## Global Constraints

[The spec's project-wide requirements — version floors, dependency limits,

naming and copy rules, platform requirements — one line each, with exact

values copied verbatim from the spec. Every task's requirements implicitly

include this section.]

---

```

## Task Structure

````markdown

### Task N: [Component Name]

**Files:**

- Create: `exact/path/to/file.py`

- Modify: `exact/path/to/existing.py:123-145`

- Test: `tests/exact/path/to/test.py`

**Interfaces:**

- Consumes: [what this task uses from earlier tasks — exact signatures]

- Produces: [what later tasks rely on — exact function names, parameter

  and return types. A task's implementer sees only their own task; this

  block is how they learn the names and types neighboring tasks use.]

- [ ] **Step 1: Write the failing test**

```python

def test_specific_behavior():

    result = function(input)

    assert result == expected

```

- [ ] **Step 2: Run test to verify it fails**

Run: `pytest tests/path/test.py::test_name -v`

Expected: FAIL with "function not defined"

- [ ] **Step 3: Write minimal implementation**

```python

def function(input):

    return expected

```

- [ ] **Step 4: Run test to verify it passes**

Run: `pytest tests/path/test.py::test_name -v`

Expected: PASS

- [ ] **Step 5: Commit**

```bash

git add tests/path/test.py src/path/file.py

git commit -m "feat: add specific feature"

```

````

## No Placeholders

Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:

- "TBD", "TODO", "implement later", "fill in details"

- "Add appropriate error handling" / "add validation" / "handle edge cases"

- "Write tests for the above" (without actual test code)

- "Similar to Task N" (repeat the code — the engineer may be reading tasks out of order)

- Steps that describe what to do without showing how (code blocks required for code steps)

- References to types, functions, or methods not defined in any task

## Remember

- Exact file paths always

- Complete code in every step — if a step changes code, show the code

- Exact commands with expected output

- DRY, YAGNI, TDD, frequent commits

## Self-Review

After writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch.

**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.

**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the "No Placeholders" section above. Fix them.

**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.

If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.

## Execution Handoff

After saving the plan, offer execution choice:

**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Two execution options:**

**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration

**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints

**Which approach?"**

**If Subagent-Driven chosen:**

- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development

- Fresh subagent per task + two-stage review

**If Inline Execution chosen:**

- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans

- Batch execution with checkpoints for review

**Claude:** I'm using the writing-plans skill to create the implementation plan. Let me read the actual code in detail first so the plan has exact signatures and line numbers.

  - `Read: /Users/pyrossh/Code/plum/plum-checker/src/lib.rs`

  - `Read: /Users/pyrossh/Code/plum/plum-core/src/ast.rs`

  - `Bash: grep -n "ClassCall\|FieldArg\|CasePattern::Class\|fn parse_call\|positional" plum-core/src/parser.rs | head -60`

  - `Read: /Users/pyrossh/Code/plum/plum-core/src/parser.rs`

  - `Bash: grep -n "class_call\|class_argument_list\|fn_call\|fn_argument_list" tooling/tree-sitter-plum/grammar.js`

  - `Read: /Users/pyrossh/Code/plum/tooling/tree-sitter-plum/grammar.js`

  - `Read: /Users/pyrossh/Code/plum/tooling/tree-sitter-plum/grammar.js`

  - `Bash: grep -n "Some\|None\|Ok(\|Err(" test/*.plum examples/*.plum libs/std/*.plum 2>/dev/null | head -40`

  - `Bash: grep -n "Some\|None\|Ok(\|Err(\|class_call\|variant" tooling/tree-sitter-plum/test/corpus/*.txt | head -60`

  - `Bash: sed -n '1,120p' tooling/tree-sitter-plum/test/corpus/type.txt`

  - `Read: /Users/pyrossh/Code/plum/plum-wasm-codegen/src/lib.rs`

  - `Bash: grep -rn "enum_variants\." plum-checker/src plum-wasm-codegen/src plum-cli/src 2>/dev/null`

  - `Bash: find plum-core plum-checker plum-wasm-codegen -name "*.rs" | xargs -I{} echo {}; echo ---; ls plum-core/tests 2>/dev/null; cat plum-core/Cargo.toml; echo ---wor`

  - `Read: /Users/pyrossh/Code/plum/plum-checker/tests/checker_tests.rs`

  - `Read: /Users/pyrossh/Code/plum/plum-wasm-codegen/tests/codegen_tests.rs`

  - `Read: /Users/pyrossh/Code/plum/plum-checker/tests/examples_test.rs`

  - `Read: /Users/pyrossh/Code/plum/plum-wasm-codegen/tests/examples_test.rs`

  - `Read: /Users/pyrossh/Code/plum/examples/match.plum`

  - `Read: /Users/pyrossh/Code/plum/tooling/tree-sitter-plum/grammar.js`

  - `Read: /Users/pyrossh/Code/plum/tooling/tree-sitter-plum/grammar.js`

  - `Bash: ls tooling/tree-sitter-plum/test/corpus/; echo ---; sed -n '1,40p' tooling/tree-sitter-plum/test/corpus/function.txt`

  - `Bash: grep -n "fn_call" -A15 tooling/tree-sitter-plum/test/corpus/*.txt | head -100`

  - `Write: /Users/pyrossh/Code/plum/docs/superpowers/plans/2026-07-19-general-enum-support.md`

**Claude:** Let me fix one ambiguity in Task 5 Step 1 — the duplicate `strings_example_reports_clear_interpolation_error` removal needs an exact snippet, not a vague instruction.

  - `Read: /Users/pyrossh/Code/plum/docs/superpowers/plans/2026-07-19-general-enum-support.md`

  - `Edit: /Users/pyrossh/Code/plum/docs/superpowers/plans/2026-07-19-general-enum-support.md`

**Claude:** Committing the plan.

  - `Bash: git add docs/superpowers/plans/2026-07-19-general-enum-support.md && git commit -m "$(cat <<'EOF' docs: add implementation plan for general enum support Five ta`

**Claude:** Plan complete and saved to [docs/superpowers/plans/2026-07-19-general-enum-support.md](docs/superpowers/plans/2026-07-19-general-enum-support.md). Note: while writing it I found the spec's construction section had a hidden dependency — `Some(v)`-style positional calls don't actually parse as expressions today (the grammar only supports named-field `Cat(name: value)` syntax for capitalized callees), so Task 1 adds a small grammar fix before the checker/codegen work. I also caught a latent checker bug worth fixing along the way: a bare non-Bool tag like `None` currently type-checks as `TNamed("None")` (itself) instead of `TNamed("Option")` (its owning enum), which would silently break comparisons like `o == None`.

Two execution options:

1. **Subagent-Driven (recommended)** — I dispatch a fresh subagent per task, review between tasks, fast iteration

2. **Inline Execution** — Execute tasks in this session using executing-plans, batch execution with checkpoints

Which approach?

**You:** 1

  - `Skill: superpowers:subagent-driven-development`

**You:** Base directory for this skill: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development

# Subagent-Driven Development

Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.

**Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.

**Core principle:** Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration

**Narration:** between tool calls, narrate at most one short line — the

ledger and the tool results carry the record.

**Continuous execution:** Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time — they asked you to execute the plan, so execute it.

## When to Use

```dot

digraph when_to_use {

    "Have implementation plan?" [shape=diamond];

    "Tasks mostly independent?" [shape=diamond];

    "Stay in this session?" [shape=diamond];

    "subagent-driven-development" [shape=box];

    "executing-plans" [shape=box];

    "Manual execution or brainstorm first" [shape=box];

    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];

    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];

    "Tasks mostly independent?" -> "Stay in this session?" [label="yes"];

    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];

    "Stay in this session?" -> "subagent-driven-development" [label="yes"];

    "Stay in this session?" -> "executing-plans" [label="no - parallel session"];

}

```

**vs. Executing Plans (parallel session):**

- Same session (no context switch)

- Fresh subagent per task (no context pollution)

- Review after each task (spec compliance + code quality), broad review at the end

- Faster iteration (no human-in-loop between tasks)

## The Process

```dot

digraph process {

    rankdir=TB;

    subgraph cluster_per_task {

        label="Per Task";

        "Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];

        "Implementer subagent asks questions?" [shape=diamond];

        "Answer questions, provide context" [shape=box];

        "Implementer subagent implements, tests, commits, self-reviews" [shape=box];

        "Write diff file, dispatch task reviewer subagent (./task-reviewer-prompt.md)" [shape=box];

        "Task reviewer reports spec ✅ and quality approved?" [shape=diamond];

        "Dispatch fix subagent for Critical/Important findings" [shape=box];

        "Mark task complete in todo list and progress ledger" [shape=box];

    }

    "Read plan, note context and global constraints, create todos" [shape=box];

    "More tasks remain?" [shape=diamond];

    "Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md)" [shape=box];

    "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "Read plan, note context and global constraints, create todos" -> "Dispatch implementer subagent (./implementer-prompt.md)";

    "Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer subagent asks questions?";

    "Implementer subagent asks questions?" -> "Answer questions, provide context" [label="yes"];

    "Answer questions, provide context" -> "Dispatch implementer subagent (./implementer-prompt.md)";

    "Implementer subagent asks questions?" -> "Implementer subagent implements, tests, commits, self-reviews" [label="no"];

    "Implementer subagent implements, tests, commits, self-reviews" -> "Write diff file, dispatch task reviewer subagent (./task-reviewer-prompt.md)";

    "Write diff file, dispatch task reviewer subagent (./task-reviewer-prompt.md)" -> "Task reviewer reports spec ✅ and quality approved?";

    "Task reviewer reports spec ✅ and quality approved?" -> "Dispatch fix subagent for Critical/Important findings" [label="no"];

    "Dispatch fix subagent for Critical/Important findings" -> "Write diff file, dispatch task reviewer subagent (./task-reviewer-prompt.md)" [label="re-review"];

    "Task reviewer reports spec ✅ and quality approved?" -> "Mark task complete in todo list and progress ledger" [label="yes"];

    "Mark task complete in todo list and progress ledger" -> "More tasks remain?";

    "More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];

    "More tasks remain?" -> "Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md)" [label="no"];

    "Dispatch final code reviewer subagent (../requesting-code-review/code-reviewer.md)" -> "Use superpowers:finishing-a-development-branch";

}

```

## Pre-Flight Plan Review

Before dispatching Task 1, scan the plan once for conflicts:

- tasks that contradict each other or the plan's Global Constraints

- anything the plan explicitly mandates that the review rubric treats as a

  defect (a test that asserts nothing, verbatim duplication of a logic block)

Present everything you find to your human partner as one batched question —

each finding beside the plan text that mandates it, asking which governs —

before execution begins, not one interrupt per discovery mid-plan. If the

scan is clean, proceed without comment. The review loop remains the net for

conflicts that only emerge from implementation.

## Model Selection

Use the least powerful model that can handle each role to conserve cost and increase speed.

**Mechanical implementation tasks** (isolated functions, clear specs, 1-2 files): use a fast, cheap model. Most implementation tasks are mechanical when the plan is well-specified.

**Integration and judgment tasks** (multi-file coordination, pattern matching, debugging): use a standard model.

**Architecture and design tasks**: use the most capable available model.

The final whole-branch review is one of these — dispatch it on the most

capable available model, not the session default.

**Review tasks**: choose the model with the same judgment, scaled to the

diff's size, complexity, and risk. A small mechanical diff does not need the

most capable model; a subtle concurrency change does.

**Always specify the model explicitly when dispatching a subagent.** An

omitted model inherits your session's model — often the most capable and

most expensive — which silently defeats this section.

**Turn count beats token price.** Wall-clock and context cost scale with how

many turns a subagent takes, and the cheapest models routinely take 2-3× the

turns on multi-step work — costing more overall. Use a mid-tier model as the

floor for reviewers and for implementers working from prose descriptions.

When the task's plan text contains the complete code to write, the

implementation is transcription plus testing: use the cheapest tier for

that implementer. Single-file mechanical fixes also take the cheapest tier.

**Task complexity signals (implementation tasks):**

- Touches 1-2 files with a complete spec → cheap model

- Touches multiple files with integration concerns → standard model

- Requires design judgment or broad codebase understanding → most capable model

## Handling Implementer Status

Implementer subagents report one of four statuses. Handle each appropriately:

**DONE:** Generate the review package (`scripts/review-package BASE HEAD`, from this skill's directory — it prints the unique file path it wrote; BASE is the commit you recorded before dispatching the implementer — never `HEAD~1`, which silently drops all but the last commit of a multi-commit task), then dispatch the task reviewer with the printed path.

**DONE_WITH_CONCERNS:** The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness or scope, address them before review. If they're observations (e.g., "this file is getting large"), note them and proceed to review.

**NEEDS_CONTEXT:** The implementer needs information that wasn't provided. Provide the missing context and re-dispatch.

**BLOCKED:** The implementer cannot complete the task. Assess the blocker:

1. If it's a context problem, provide more context and re-dispatch with the same model

2. If the task requires more reasoning, re-dispatch with a more capable model

3. If the task is too large, break it into smaller pieces

4. If the plan itself is wrong, escalate to the human

**Never** ignore an escalation or force the same model to retry without changes. If the implementer said it's stuck, something needs to change.

## Handling Reviewer ⚠️ Items

The task reviewer may report "⚠️ Cannot verify from diff" items — requirements

that live in unchanged code or span tasks. These do not block the rest of the

review, but you must resolve each one yourself before marking the task

complete: you hold the plan and cross-task context the reviewer

lacks. If you confirm an item is a real gap, treat it as a failed spec

review — send it back to the implementer and re-review.

## Constructing Reviewer Prompts

Per-task reviews are task-scoped gates. The broad review happens once, at the

final whole-branch review. When you fill a reviewer template:

- Do not add open-ended directives like "check all uses" or "run race tests

  if useful" without a concrete, task-specific reason

- Do not ask a reviewer to re-run tests the implementer already ran on the

  same code — the implementer's report carries the test evidence

- Do not pre-judge findings for the reviewer — never instruct a reviewer to

  ignore or not flag a specific issue. If you believe a finding would be a

  false positive, let the reviewer raise it and adjudicate it in the review

  loop. If the prompt you are writing contains "do not flag," "don't treat X

  as a defect," "at most Minor," or "the plan chose" — stop: you are

  pre-judging, usually to spare yourself a review loop.

- The global-constraints block you hand the reviewer is its attention

  lens. Copy the binding requirements verbatim from the plan's Global

  Constraints section or the spec: exact values, exact formats, and the

  stated relationships between components ("same layout as X", "matches

  Y"). The reviewer's template already carries the process rules (YAGNI,

  test hygiene, review method) — the constraints block is for what THIS

  project's spec demands.

- Hand the reviewer its diff as a file: run this skill's

  `scripts/review-package BASE HEAD` and pass the reviewer the file path

  it prints (or, without bash: `git log --oneline`, `git diff --stat`,

  and `git diff -U10` for the range, redirected to one uniquely named

  file). The output never enters your own context, and the reviewer sees

  the commit list, stat summary, and full diff with context in one Read

  call. Use the BASE you recorded before dispatching the implementer —

  never `HEAD~1`, which silently truncates multi-commit tasks.

- A dispatch prompt describes one task, not the session's history. Do not

  paste accumulated prior-task summaries ("state after Tasks 1-3") into

  later dispatches — a real session's dispatch hit 42k chars of which 99%

  was pasted history. A fresh subagent needs its task, the interfaces it

  touches, and the global constraints. Nothing else.

- Dispatch fix subagents for Critical and Important findings. Record Minor

  findings in the progress ledger as you go, and point the final

  whole-branch review at that list so it can triage which must be fixed

  before merge. A roll-up nobody reads is a silent discard.

- A finding labeled plan-mandated — or any finding that conflicts with

  what the plan's text requires — is the human's decision, like any plan

  contradiction: present the finding and the plan text, ask which governs.

  Do not dismiss the finding because the plan mandates it, and do not

  dispatch a fix that contradicts the plan without asking.

- The final whole-branch review gets a package too: run

  `scripts/review-package MERGE_BASE HEAD` (MERGE_BASE = the commit the

  branch started from, e.g. `git merge-base main HEAD`) and include the

  printed path in the final review dispatch, so the final reviewer reads

  one file instead of re-deriving the branch diff with git commands.

- Every fix dispatch carries the implementer contract: the fix subagent

  re-runs the tests covering its change and reports the results. Name the

  covering test files in the dispatch — a one-line fix does not need the

  whole suite. Before re-dispatching the reviewer, confirm the fix report

  contains the covering tests, the command run, and the output; dispatch

  the re-review once all three are present.

- If the final whole-branch review returns findings, dispatch ONE fix

  subagent with the complete findings list — not one fixer per finding.

  Per-finding fixers each rebuild context and re-run suites; a real

  session's final-review fix wave cost more than all its tasks combined.

## File Handoffs

Everything you paste into a dispatch prompt — and everything a subagent

prints back — stays resident in your context for the rest of the session

and is re-read on every later turn. Hand artifacts over as files:

- **Task brief:** before dispatching an implementer, run this skill's

  `scripts/task-brief PLAN_FILE N` — it extracts the task's full text to a

  uniquely named file and prints the path. Compose the dispatch so the

  brief stays the single source of requirements. Your dispatch should

  contain: (1) one line on where this task fits in the project; (2) the

  brief path, introduced as "read this first — it is your requirements,

  with the exact values to use verbatim"; (3) interfaces and decisions

  from earlier tasks that the brief cannot know; (4) your resolution of

  any ambiguity you noticed in the brief; (5) the report-file path and

  report contract. Exact values (numbers, magic strings, signatures, test

  cases) appear only in the brief.

- **Report file:** name the implementer's report file after the brief

  (brief `…/task-N-brief.md` → report `…/task-N-report.md`) and put it in

  the dispatch prompt. The implementer writes the full report there and

  returns only status, commits, a one-line test summary, and concerns.

- **Reviewer inputs:** the task reviewer gets three paths — the same brief

  file, the report file, and the review package — plus the global

  constraints that bind the task.

- Fix dispatches append their fix report (with test results) to the same

  report file and return a short summary; re-reviews read the updated file.

## Durable Progress

Conversation memory does not survive compaction. In real sessions,

controllers that lost their place have re-dispatched entire completed task

sequences — the single most expensive failure observed. Track progress in

a ledger file, not only in todos.

- At skill start, check for a ledger:

  `cat "$(git rev-parse --show-toplevel)/.superpowers/sdd/progress.md"`. Tasks listed there

  as complete are DONE — do not re-dispatch them; resume at the first task

  not marked complete.

- When a task's review comes back clean, append one line to the ledger in

  the same message as your other bookkeeping:

  `Task N: complete (commits <base7>..<head7>, review clean)`.

- The ledger is your recovery map: the commits it names exist in git even

  when your context no longer remembers creating them. After compaction,

  trust the ledger and `git log` over your own recollection.

- `git clean -fdx` will destroy the ledger (it's git-ignored scratch); if

  that happens, recover from `git log`.

## Prompt Templates

- [implementer-prompt.md](implementer-prompt.md) - Dispatch implementer subagent

- [task-reviewer-prompt.md](task-reviewer-prompt.md) - Dispatch task reviewer subagent (spec compliance + code quality)

- Final whole-branch review: use superpowers:requesting-code-review's [code-reviewer.md](../requesting-code-review/code-reviewer.md)

## Example Workflow

```

You: I'm using Subagent-Driven Development to execute this plan.

[Read plan file once: docs/superpowers/plans/feature-plan.md]

[Create todos for all tasks]

Task 1: Hook installation script

[Run task-brief for Task 1; dispatch implementer with brief + report paths + context]

Implementer: "Before I begin - should the hook be installed at user or system level?"

You: "User level (~/.config/superpowers/hooks/)"

Implementer: "Got it. Implementing now..."

[Later] Implementer:

  - Implemented install-hook command

  - Added tests, 5/5 passing

  - Self-review: Found I missed --force flag, added it

  - Committed

[Run review-package, dispatch task reviewer with the printed path]

Task reviewer: Spec ✅ - all requirements met, nothing extra.

  Strengths: Good test coverage, clean. Issues: None. Task quality: Approved.

[Mark Task 1 complete]

Task 2: Recovery modes

[Run task-brief for Task 2; dispatch implementer with brief + report paths + context]

Implementer: [No questions, proceeds]

Implementer:

  - Added verify/repair modes

  - 8/8 tests passing

  - Self-review: All good

  - Committed

[Run review-package, dispatch task reviewer with the printed path]

Task reviewer: Spec ❌:

  - Missing: Progress reporting (spec says "report every 100 items")

  - Extra: Added --json flag (not requested)

  Issues (Important): Magic number (100)

[Dispatch fix subagent with all findings]

Fixer: Removed --json flag, added progress reporting, extracted PROGRESS_INTERVAL constant

[Task reviewer reviews again]

Task reviewer: Spec ✅. Task quality: Approved.

[Mark Task 2 complete]

...

[After all tasks]

[Dispatch final code-reviewer]

Final reviewer: All requirements met, ready to merge

Done!

```

## Advantages

**vs. Manual execution:**

- Subagents follow TDD naturally

- Fresh context per task (no confusion)

- Parallel-safe (subagents don't interfere)

- Subagent can ask questions (before AND during work)

**vs. Executing Plans:**

- Same session (no handoff)

- Continuous progress (no waiting)

- Review checkpoints automatic

**Efficiency gains:**

- Controller curates exactly what context is needed; bulk artifacts move

  as files, not pasted text

- Subagent gets complete information upfront

- Questions surfaced before work begins (not after)

**Quality gates:**

- Self-review catches issues before handoff

- Task review carries two verdicts: spec compliance and code quality

- Review loops ensure fixes actually work

- Spec compliance prevents over/under-building

- Code quality ensures implementation is well-built

**Cost:**

- More subagent invocations (implementer + reviewer per task)

- Controller does more prep work (extracting all tasks upfront)

- Review loops add iterations

- But catches issues early (cheaper than debugging later)

## Red Flags

**Never:**

- Start implementation on main/master branch without explicit user consent

- Skip task review, or accept a report missing either verdict (spec compliance AND task quality are both required)

- Proceed with unfixed issues

- Dispatch multiple implementation subagents in parallel (conflicts)

- Make a subagent read the whole plan file (hand it its task brief —

  `scripts/task-brief` — instead)

- Skip scene-setting context (subagent needs to understand where task fits)

- Ignore subagent questions (answer before letting them proceed)

- Accept "close enough" on spec compliance (reviewer found spec issues = not done)

- Skip review loops (reviewer found issues = implementer fixes = review again)

- Let implementer self-review replace actual review (both are needed)

- Tell a reviewer what not to flag, or pre-rate a finding's severity in the

  dispatch prompt ("treat it as Minor at most") — the plan's example code is

  a starting point, not evidence that its weaknesses were chosen

- Dispatch a task reviewer without a diff file — generate it first

  (`scripts/review-package BASE HEAD`) and name the printed path in the

  prompt

- Move to next task while the review has open Critical/Important issues

- Re-dispatch a task the progress ledger already marks complete — check

  the ledger (and `git log`) after any compaction or resume

**If subagent asks questions:**

- Answer clearly and completely

- Provide additional context if needed

- Don't rush them into implementation

**If reviewer finds issues:**

- Implementer (same subagent) fixes them

- Reviewer reviews again

- Repeat until approved

- Don't skip the re-review

**If subagent fails task:**

- Dispatch fix subagent with specific instructions

- Don't try to fix manually (context pollution)

## Integration

**Required workflow skills:**

- **superpowers:using-git-worktrees** - Ensures isolated workspace (creates one or verifies existing)

- **superpowers:writing-plans** - Creates the plan this skill executes

- **superpowers:requesting-code-review** - Code review template for the final whole-branch review

- **superpowers:finishing-a-development-branch** - Complete development after all tasks

**Subagents should use:**

- **superpowers:test-driven-development** - Subagents follow TDD for each task

**Alternative workflow:**

- **superpowers:executing-plans** - Use for parallel session instead of same-session execution

  - `Bash: git rev-parse --show-toplevel; cat .superpowers/sdd/progress.md 2>/dev/null; echo "---worktree skill---"; ls .claude/skills 2>/dev/null; git status --short`

  - `Skill: superpowers:using-git-worktrees`

**You:** Base directory for this skill: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/using-git-worktrees

# Using Git Worktrees

## Overview

Ensure work happens in an isolated workspace. Prefer your platform's native worktree tools. Fall back to manual git worktrees only when no native tool is available.

**Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness.

**Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."

## Step 0: Detect Existing Isolation

**Before creating anything, check if you are already in an isolated workspace.**

```bash

GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)

GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)

BRANCH=$(git branch --show-current)

```

**Submodule guard:** `GIT_DIR != GIT_COMMON` is also true inside git submodules. Before concluding "already in a worktree," verify you are not in a submodule:

```bash

# If this returns a path, you're in a submodule, not a worktree — treat as normal repo

git rev-parse --show-superproject-working-tree 2>/dev/null

```

**If `GIT_DIR != GIT_COMMON` (and not a submodule):** You are already in a linked worktree. Skip to Step 2 (Project Setup). Do NOT create another worktree.

Report with branch state:

- On a branch: "Already in isolated workspace at `<path>` on branch `<name>`."

- Detached HEAD: "Already in isolated workspace at `<path>` (detached HEAD, externally managed). Branch creation needed at finish time."

**If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout.

Has the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree:

> "Would you like me to set up an isolated worktree? It protects your current branch from changes."

Honor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2.

## Step 1: Create Isolated Workspace

**You have two mechanisms. Try them in this order.**

### 1a. Native Worktree Tools (preferred)

The user has asked for an isolated workspace (Step 0 consent). Do you already have a way to create a worktree? It might be a tool with a name like `EnterWorktree`, `WorktreeCreate`, a `/worktree` command, or a `--worktree` flag. If you do, use it and skip to Step 2.

Native tools handle directory placement, branch creation, and cleanup automatically. Using `git worktree add` when you have a native tool creates phantom state your harness can't see or manage.

Only proceed to Step 1b if you have no native worktree tool available.

### 1b. Git Worktree Fallback

**Only use this if Step 1a does not apply** — you have no native worktree tool available. Create a worktree manually using git.

#### Directory Selection

Follow this priority order. Explicit user preference always beats observed filesystem state.

1. **Check your instructions for a declared worktree directory preference.** If the user has already specified one, use it without asking.

2. **Check for an existing project-local worktree directory:**

   ```bash

   ls -d .worktrees 2>/dev/null     # Preferred (hidden)

   ls -d worktrees 2>/dev/null      # Alternative

   ```

   If found, use it. If both exist, `.worktrees` wins.

3. **If there is no other guidance available**, default to `.worktrees/` at the project root.

#### Safety Verification (project-local directories only)

**MUST verify directory is ignored before creating worktree:**

```bash

git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null

```

**If NOT ignored:** Add to .gitignore, commit the change, then proceed.

**Why critical:** Prevents accidentally committing worktree contents to repository.

#### Create the Worktree

```bash

# Determine path based on chosen location

path="$LOCATION/$BRANCH_NAME"

git worktree add "$path" -b "$BRANCH_NAME"

cd "$path"

```

**Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), tell the user the sandbox blocked worktree creation and you're working in the current directory instead. Then run setup and baseline tests in place.

## Step 2: Project Setup

Auto-detect and run appropriate setup:

```bash

# Node.js

if [ -f package.json ]; then npm install; fi

# Rust

if [ -f Cargo.toml ]; then cargo build; fi

# Python

if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

if [ -f pyproject.toml ]; then poetry install; fi

# Go

if [ -f go.mod ]; then go mod download; fi

```

## Step 3: Verify Clean Baseline

Run tests to ensure workspace starts clean:

```bash

# Use project-appropriate command

npm test / cargo test / pytest / go test ./...

```

**If tests fail:** Report failures, ask whether to proceed or investigate.

**If tests pass:** Report ready.

### Report

```

Worktree ready at <full-path>

Tests passing (<N> tests, 0 failures)

Ready to implement <feature-name>

```

## Quick Reference

| Situation | Action |

|-----------|--------|

| Already in linked worktree | Skip creation (Step 0) |

| In a submodule | Treat as normal repo (Step 0 guard) |

| Native worktree tool available | Use it (Step 1a) |

| No native tool | Git worktree fallback (Step 1b) |

| `.worktrees/` exists | Use it (verify ignored) |

| `worktrees/` exists | Use it (verify ignored) |

| Both exist | Use `.worktrees/` |

| Neither exists | Check instruction file, then default `.worktrees/` |

| Directory not ignored | Add to .gitignore + commit |

| Permission error on create | Sandbox fallback, work in place |

| Tests fail during baseline | Report failures + ask |

| No package.json/Cargo.toml | Skip dependency install |

## Common Mistakes

### Fighting the harness

- **Problem:** Using `git worktree add` when the platform already provides isolation

- **Fix:** Step 0 detects existing isolation. Step 1a defers to native tools.

### Skipping detection

- **Problem:** Creating a nested worktree inside an existing one

- **Fix:** Always run Step 0 before creating anything

### Skipping ignore verification

- **Problem:** Worktree contents get tracked, pollute git status

- **Fix:** Always use `git check-ignore` before creating project-local worktree

### Assuming directory location

- **Problem:** Creates inconsistency, violates project conventions

- **Fix:** Follow priority: explicit instructions > existing project-local directory > default

### Proceeding with failing tests

- **Problem:** Can't distinguish new bugs from pre-existing issues

- **Fix:** Report failures, get explicit permission to proceed

## Red Flags

**Never:**

- Create a worktree when Step 0 detects existing isolation

- Use `git worktree add` when you have a native worktree tool (e.g., `EnterWorktree`). This is the #1 mistake — if you have it, use it.

- Skip Step 1a by jumping straight to Step 1b's git commands

- Create worktree without verifying it's ignored (project-local)

- Skip baseline test verification

- Proceed with failing tests without asking

**Always:**

- Run Step 0 detection first

- Prefer native tools over git fallback

- Follow directory priority: explicit instructions > existing project-local directory > default

- Verify directory is ignored for project-local

- Auto-detect and run project setup

- Verify clean test baseline

**Claude:** I'm using the using-git-worktrees skill to set up an isolated workspace.

  - `Bash: GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P); GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P); echo "GIT_DIR=$GIT`

**Claude:** Not currently in an isolated workspace — I'm on `master` directly.

  - `AskUserQuestion`

  - `Bash: cargo test --workspace 2>&1 | tail -40`

**Claude:** Baseline is clean. Now setting up the progress ledger and pre-flight scan before dispatching Task 1.

  - `Write: /Users/pyrossh/Code/plum/.superpowers/sdd/progress.md`

  - `Read: /Users/pyrossh/Code/plum/.superpowers/sdd/progress.md`

**Claude:** That's the old, already-completed plan's ledger. Overwriting it for the new plan.

  - `Write: /Users/pyrossh/Code/plum/.superpowers/sdd/progress.md`

**Claude:** Pre-flight scan: I wrote this plan myself and already cross-checked type/interface consistency across tasks during the writing-plans self-review — no contradictions with the Global Constraints found. Proceeding to Task 1.

  - `Bash: ls /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/scripts/`

  - `Bash: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/scripts/task-brief docs/superpowers/plans/2026-07-19-g`

  - `Bash: git rev-parse HEAD`

  - `Bash: cat /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/implementer-prompt.md`

**Claude:** Now dispatching the Task 1 implementer.

  - `Agent: Implement Task 1: grammar fix`

**Claude:** Task 1 implementer is running in the background — I'll wait for its completion notification rather than poll.

**You:** <task-notification>

<task-id>ac076e1fdc76a1738</task-id>

<tool-use-id>toolu_012vJNqN8u8LZGtZRBYa2UcA</tool-use-id>

<output-file>/private/tmp/claude-501/-Users-pyrossh-Code-plum/61ed18b5-cab0-453c-9a65-dcb8cfc58361/tasks/ac076e1fdc76a1738.output</output-file>

<status>completed</status>

<summary>Agent "Implement Task 1: grammar fix" finished</summary>

<note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note>

<result>## Report

**Status:** DONE

**Commit:** `96ec67f feat(tree-sitter-plum): allow positional variant-construction calls`

**Test Summary:** All 18 corpus tests pass (100% success rate), including new variant construction call and all pre-existing class_call cases — no regressions.

**Key Actions:**

- Modified grammar.js: added `fn_argument_list`/`class_argument_list` conflict declaration and updated `fn_call` to accept `type_identifier` callees

- Generated expected tree: `Some(v)` parses as `fn_call` with `type_identifier`, not `class_call`

- All tests pass with no ERROR/MISSING nodes

**Report file:** `/Users/pyrossh/Code/plum/.superpowers/sdd/task-1-report.md`</result>

<usage><subagent_tokens>38172</subagent_tokens><tool_uses>24</tool_uses><duration_ms>119795</duration_ms></usage>

</task-notification>

**Claude:** Task 1 done. Let me check the report and generate the review package before dispatching the reviewer.

  - `Bash: git log --oneline -3 && echo --- && git show --stat HEAD`

  - `Bash: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/scripts/review-package 2cee306 96ec67f`

  - `Bash: cat /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/task-reviewer-prompt.md`

**Claude:** Dispatching the Task 1 reviewer now.

  - `Agent: Review Task 1 (spec + quality)`

**Claude:** Task 1 reviewer is running in the background.

**You:** <task-notification>

<task-id>a96d45e2237740f81</task-id>

<tool-use-id>toolu_01DN574fNZPnixxjZ25wAxGj</tool-use-id>

<output-file>/private/tmp/claude-501/-Users-pyrossh-Code-plum/61ed18b5-cab0-453c-9a65-dcb8cfc58361/tasks/a96d45e2237740f81.output</output-file>

<status>completed</status>

<summary>Agent "Review Task 1 (spec + quality)" finished</summary>

<note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note>

<result>### Spec Compliance

- ❌ Issues found: The `conflicts` array does not match the brief's prescribed text.

  - Brief (task-1-brief.md:52): `conflicts: ($) => [[$.fn_call, $.class_call]]`

  - Diff actual (review diff line 31): `conflicts: ($) => [[$.fn_argument_list, $.class_argument_list]]`

  - The implementer's own report (task-1-report.md:12, 22-26) confirms this was a deliberate, self-motivated deviation ("conflict resolution was declared on `[$.fn_argument_list, $.class_argument_list]` rather than the rules themselves"), not a transcription slip. Per the brief's own guidance ("if it reports one anyway... read the reported example carefully... don't just silence it"), a deviation like this should have been flagged as a decision point rather than silently substituted with no confirmation that the brief's literal prescription was even tried and found insufficient. The report gives a plausible rationale (empty `()` ambiguity between the two argument-list rules) but never states whether `[$.fn_call, $.class_call]` was attempted and failed, or whether it was simply skipped in favor of this alternative. Since `npx tree-sitter-cli generate` reportedly completed without "Unresolved conflict" errors and all 18 corpus cases (including `class_call` cases in `type.txt`) pass, the substitution is functionally validated by the test suite — but it is still a checkable deviation from the exact prescribed diff, and the brief's rationale for choosing `fn_call`/`class_call` specifically (the ambiguity being between the two *call* rules, not their argument lists) was not addressed or ruled out.

- ✅ `fn_call` rule change matches the brief exactly (`choice($.var_identifier, $.type_identifier)`).

- ✅ Corpus test case (function.txt) matches the brief's prescribed input and expected tree exactly, including one-node-per-line formatting.

- ✅ Scope respected: no generics/monomorphization, multi-subject match, or new pattern kinds touched. Diff is confined to `grammar.js` (2 lines) + `function.txt` (test case) + regenerated artifacts.

- ⚠️ Cannot verify from diff: whether `grammar.json`/`node-types.json`/`parser.c` binary diffs are purely `tree-sitter generate` output vs. hand-touched — trusting the report's claim since binary diffs are not line-reviewable, and there's no textual evidence of manual editing.

### Strengths

- Minimal, surgical diff — exactly the two grammar.js lines the brief called for plus one corpus case, no incidental churn.

- Pre-existing "why" comment above `fn_call` (about `var_identifier` lexing ambiguity) was left untouched, correctly not requiring an update since the rule's identifier-lexing rationale is unaffected by this change.

- Test case format matches existing corpus conventions exactly (separator style, one-node-per-line tree).

- Report is honest about the conflict-declaration substitution rather than silently claiming brief-verbatim compliance — makes the deviation catchable in review, which is what surfaced here.

### Issues

#### Critical (Must Fix)

None.

#### Important (Should Fix)

- **Undocumented deviation from prescribed conflict declaration** (grammar.js, conflicts array). The brief specifies `[[$.fn_call, $.class_call]]`; the shipped code has `[[$.fn_argument_list, $.class_argument_list]]`. Tests pass either way per the report, but the report doesn't show that the brief's literal form was tried and rejected — it jumps straight to the alternative with a self-constructed rationale. Before merging, either (a) confirm the brief's exact form also generates cleanly and passes the suite, and prefer it for spec fidelity, or (b) explicitly document in the report/commit why the argument-list-level conflict is necessary and the call-level one is insufficient (e.g., "call-level conflict alone leaves an unresolved conflict at empty-argument-list states because..."). As it stands this is a plausible-sounding but unverified justification for silently diverging from an explicit instruction.

#### Minor (Nice to Have)

- The report's "Key Insight on Conflicts" section reads more like exploratory narration than a permanent code comment, and none of that reasoning was captured as an in-grammar comment near the `conflicts` array (the codebase's convention, per the existing `fn_call` comment, is one-line "why" comments at the point of interest) — a future maintainer reading `grammar.js:55` alone won't know why this particular pair was chosen over the more obvious `fn_call`/`class_call` pair.

### Assessment

**Task quality:** Needs fixes

**Reasoning:** The functional grammar change and test coverage are correct and match the brief precisely, but the conflicts-array deviation is exactly the kind of "different conflict pair could resolve ambiguity differently or mask a real issue" risk flagged in the task's constraints, and it was not verified against the brief's literal prescription or explained with in-code justification — it should be reconciled (verified equivalent or documented) before this is considered done.</result>

<usage><subagent_tokens>37383</subagent_tokens><tool_uses>3</tool_uses><duration_ms>51472</duration_ms></usage>

</task-notification>

  - `Agent: Fix Task 1 review findings`

**Claude:** Fix subagent for Task 1's review finding is running in the background.

**You:** <task-notification>

<task-id>ab523b917da5b60b5</task-id>

<tool-use-id>toolu_01FDZQT8mYQ58iMfeya3bJ5t</tool-use-id>

<output-file>/private/tmp/claude-501/-Users-pyrossh-Code-plum/61ed18b5-cab0-453c-9a65-dcb8cfc58361/tasks/ab523b917da5b60b5.output</output-file>

<status>completed</status>

<summary>Agent "Fix Task 1 review findings" finished</summary>

<note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note>

<result>**Status:** DONE

**Commit created:** `a65c75b fix(tree-sitter-plum): document fn_argument_list/class_argument_list conflict rationale`

**Which conflicts-array pair ended up in the code, and why:** `[[$.fn_argument_list, $.class_argument_list]]` — testing the brief's prescribed `[[$.fn_call, $.class_call]]` produced an unresolved conflict at the argument-list parse state (empty parentheses ambiguity), proving the argument-list pair is necessary.

**Test summary:** All 18 corpus cases pass; generate runs cleanly; no regressions.

**Report file:** `/Users/pyrossh/Code/plum/.superpowers/sdd/task-1-report.md` (appended with findings from this follow-up)</result>

<usage><subagent_tokens>32695</subagent_tokens><tool_uses>12</tool_uses><duration_ms>59257</duration_ms></usage>

</task-notification>

**Claude:** Now re-review to confirm the fix and close out Task 1.

  - `Bash: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/scripts/review-package 2cee306 a65c75b`

  - `Agent: Re-review Task 1 after fix`

**Claude:** Task 1 re-review is running in the background.

**You:** <task-notification>

<task-id>a3e345cf5275658b0</task-id>

<tool-use-id>toolu_01Qk2cUqEdTDnVG1KE4ahfYS</tool-use-id>

<output-file>/private/tmp/claude-501/-Users-pyrossh-Code-plum/61ed18b5-cab0-453c-9a65-dcb8cfc58361/tasks/a3e345cf5275658b0.output</output-file>

<status>completed</status>

<summary>Agent "Re-review Task 1 after fix" finished</summary>

<note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note>

<result>All confirmed against source. Now writing the verdict.

### Spec Compliance

- ✅ Spec compliant: the prior "Important" finding is resolved. `grammar.js:31-35` now carries a 3-line in-code comment directly above `conflicts: ($) => [[$.fn_argument_list, $.class_argument_list]],` explaining the conflict arises at the empty-argument-list parse state (e.g. `Foo()`), where `fn_argument_list` and `class_argument_list` cannot be distinguished until `:` or `)` is seen, and that declaring the conflict at the argument-list level (not the call level) resolves it.

- The report's Follow-up section shows concrete `generate` output for the brief's literal form (`[[$.fn_call, $.class_call]]`) failing with a specific "Unresolved conflict" error at `const_identifier '=' type_identifier '(' ')' • '/' …`, listing the two colliding reductions as `fn_argument_list '(' ')'` vs `class_argument_list '(' ')'` — this is internally consistent with the stated rationale (the ambiguity is on the empty-arglist reduction, a symbol pair the call-level conflict declaration wouldn't name), so the technical justification is genuine and checkable, not hand-waved.

- Final `conflicts:` value in the diff (`grammar.js:35`) matches exactly what the report claims: `[[$.fn_argument_list, $.class_argument_list]]`.

- Task brief's Step 2 explicitly says "If it reports one anyway... read the reported example carefully before changing anything further" — the fix subagent did exactly this rather than blindly reverting, satisfying the brief's own contingency instruction.

### Strengths

- Fix directly targets the prior finding: literal brief form was actually tried (not just claimed), real generate output captured and quoted, and the deviation is now documented in-grammar rather than only in a report.

- Comment content is technical and specific (names the actual parse state and the actual colliding rule pair), not generic filler.

- Cumulative diff is minimal: only the `conflicts` line/comment changed between the original and fix commits, per `git diff` file list (`grammar.js` +7/-2 lines, corpus file, and regenerated binaries) — no unrelated churn.

### Issues

#### Critical (Must Fix)

None.

#### Important (Should Fix)

None.

#### Minor (Nice to Have)

- The new comment is 3 lines, while the plan's global constraint says "one-line 'why' comments only." In practice, existing comments in this same file are inconsistent with that literal rule — e.g. the comment above `fn_call` itself (`grammar.js:49-54`, 6 lines) and the one above the class-method-name choice (`grammar.js:369-372` in current file, 4 lines) — so the new 3-line comment matches the file's actual prevailing style (multi-line paragraph "why" comments) even though it's technically longer than one line. Not worth blocking on given the precedent, but worth flagging since it's a literal mismatch with the stated constraint.

### Assessment

**Task quality:** Approved

**Reasoning:** The prior Important finding is resolved with a real, verifiable technical justification (concrete generate-error output) and an in-grammar comment that accurately reflects it; the only residual nit is a comment-length technicality that matches existing file precedent rather than violating the codebase's actual style.</result>

<usage><subagent_tokens>42966</subagent_tokens><tool_uses>9</tool_uses><duration_ms>61146</duration_ms></usage>

</task-notification>

**Claude:** Task 1 is approved. Updating the ledger and moving to Task 2.

  - `Bash: git log --oneline -5`

  - `Edit: /Users/pyrossh/Code/plum/.superpowers/sdd/progress.md`

  - `Bash: /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/scripts/task-brief docs/superpowers/plans/2026-07-19-g`

  - `Bash: git rev-parse HEAD`

  - `Agent: Implement Task 2: checker enum variant info`

**Claude:** Task 1 approved and merged. Task 2 (checker changes) implementer is now running in the background.

**You:** <task-notification>

<task-id>a73898982b7d62405</task-id>

<tool-use-id>toolu_017Gh2SnK8CmzDm2WZisVSTs</tool-use-id>

<output-file>/private/tmp/claude-501/-Users-pyrossh-Code-plum/61ed18b5-cab0-453c-9a65-dcb8cfc58361/tasks/a73898982b7d62405.output</output-file>

<status>completed</status>

<summary>Agent "Implement Task 2: checker enum variant info" finished</summary>

<note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note>

<result>**Status:** DONE_WITH_CONCERNS

Commit: `7ac1d37 feat(plum-checker): general enum variant tags, field types, and construction checks`

Test summary: 29/30 in `checker_tests` pass (28 pre-existing + 2 new/adjusted; 5 of 6 brief tests green); `examples_test.rs` unaffected/green. One test, `bare_enum_tag_unifies_with_owning_enum_type`, fails — not a checker-logic bug but a pre-existing tree-sitter-plum grammar limitation: `_statement` in `grammar.js` only allows `$.primary_expression` (not full `$.expression`) as a multi-line function body's trailing statement, so `o == None` as the last line of an indented body never parses as one `Compare` node (`==` is dropped, becomes an `ERROR` + two separate statements). This predates Task 2, is out of this task's file scope (`plum-checker/src/lib.rs` only), and needs the `tree-sitter` CLI (not installed here) to fix/regenerate. All 5 code edits match the brief byte-for-byte.

Report: `/Users/pyrossh/Code/plum/.superpowers/sdd/task-2-report.md`</result>

<usage><subagent_tokens>97294</subagent_tokens><tool_uses>54</tool_uses><duration_ms>417219</duration_ms></usage>

</task-notification>

**Claude:** Let me verify this claimed grammar limitation directly before trusting the implementer's diagnosis.

  - `Bash: cat > /tmp/t.plum << 'EOF' enum Option = | Some(Int) | None isNone(o: Option) -> Bool = o == None EOF cat > /tmp/parse_test.rs << 'RUST' fn main() { let src = s`

  - `Bash: cargo test -p plum-checker --test checker_tests bare_enum_tag_unifies_with_owning_enum_type -- --nocapture 2>&1 | tail -40`

  - `Bash: ls plum-cli/src; grep -n "fn main" plum-cli/src/*.rs | head`

  - `Read: /Users/pyrossh/Code/plum/plum-cli/src/main.rs`

  - `Read: /Users/pyrossh/Code/plum/plum-checker/tests/checker_tests.rs`

  - `Bash: cat >> /Users/pyrossh/Code/plum/plum-checker/tests/checker_tests.rs << 'EOF' #[test] fn debug_dump_ast_temp() { let src = "\ enum Option = | Some(Int) | None is`

  - `Bash: sed -i '' '$ d' plum-checker/tests/checker_tests.rs # remove the temp test block entirely (multiple lines) - safer to use git checkout since implementer's versi`

  - `Bash: git checkout -- plum-checker/tests/checker_tests.rs && git diff --stat plum-checker/tests/checker_tests.rs`

**Claude:** Good, reverted cleanly. Now let me test the inline-expression form to see if it avoids the grammar limitation.

  - `Bash: cat >> /Users/pyrossh/Code/plum/plum-checker/tests/checker_tests.rs << 'EOF' #[test] fn debug_dump_ast_temp2() { let src = "\ enum Option = | Some(Int) | None i`

  - `Bash: git checkout -- plum-checker/tests/checker_tests.rs cat >> /Users/pyrossh/Code/plum/plum-checker/tests/checker_tests.rs << 'EOF' #[test] fn debug_dump_ast_temp3`

  - `Bash: git status --short`

**Claude:** Confirmed independently: the checker fix itself is correct — the test just used a multi-line indented body, and this grammar only allows `$.primary_expression` (not full `$.expression`) as a body's trailing statement, so `o == None` split into two separate statements with an `ERROR` node. The inline single-line form (`= o == None`) parses cleanly with no error. This is a real, separate, pre-existing grammar limitation, unrelated to Task 2. Dispatching a small fix to rewrite just that one test.

  - `Agent: Fix Task 2 test to avoid grammar limitation`

**Claude:** Fix subagent running in the background.

**You:** <task-notification>

<task-id>a460ae3a9e73d3d1d</task-id>

<tool-use-id>toolu_0153tC3RkWvHMuK8wbS3baSf</tool-use-id>

<output-file>/private/tmp/claude-501/-Users-pyrossh-Code-plum/61ed18b5-cab0-453c-9a65-dcb8cfc58361/tasks/a460ae3a9e73d3d1d.output</output-file>

<status>completed</status>

<summary>Agent "Fix Task 2 test to avoid grammar limitation" finished</summary>

<note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note>

<result>Perfect! Here's the final report:

**Status:** DONE

**Commit:** 0c09f5d - fix(plum-checker): rewrite bare_enum_tag test to avoid unrelated grammar limitation

**Test Summary:** All 30 plum-checker tests pass (29 checker_tests.rs + 1 examples_test.rs) — no regressions

**Spawn Task:** Grammar limitation flagged successfully (task_1ded38c4) for multi-line indented body fix in separate follow-up</result>

<usage><subagent_tokens>29146</subagent_tokens><tool_uses>7</tool_uses><duration_ms>47340</duration_ms></usage>

</task-notification>

**Claude:** Now dispatching the Task 2 reviewer against the full commit range.

  - `Bash: git log --oneline -5 && /Users/pyrossh/.claude/plugins/cache/superpowers-dev/superpowers/6.1.1/skills/subagent-driven-development/scripts/review-package a65c75b`

  - `Agent: Review Task 2 (spec + quality)`

**Claude:** Task 2 reviewer running in the background.

**You:** <task-notification>

<task-id>a179eba1a6679818e</task-id>

<tool-use-id>toolu_018j5FfyfQ6AZ9KbjFULZX5R</tool-use-id>

<output-file>/private/tmp/claude-501/-Users-pyrossh-Code-plum/61ed18b5-cab0-453c-9a65-dcb8cfc58361/tasks/a179eba1a6679818e.output</output-file>

<status>completed</status>

<summary>Agent "Review Task 2 (spec + quality)" finished</summary>

<note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note>

<result>Error message style is consistent with the rest of the file (`"call '{}': expected {} args, got {}"` mirrors `"variant '{}': expected {} arg(s), got {}"`; `"constructor pattern '{}' expects {} field(s), got {}"` is analogous to existing patterns). No stylistic deviation.

### Spec Compliance

✅ Spec compliant. All 5 prescribed code edits in `plum-checker/src/lib.rs` match the brief byte-for-byte (verified directly against the diff): `EnumVariantInfo`/`EnumVariants` (lines 30-40 of diff), the two `True`/`False` inserts (tag 1/0, `field_types: vec![]`), the `Item::Enum` tag-enumeration loop with `plum_type_from_ast` mapping, the `TypeName` arm (owning-enum lookup with permissive fallback), the `FnCall` variant-construction branch (arg-count + per-arg unify, falls through to existing function-call path), and `check_pattern`'s `CasePattern::Class` arm (field-count validation + real per-field types, permissive fallback for unmodeled variants) plus doc-comment update. All 6 brief test cases present in `plum-checker/tests/checker_tests.rs`.

- The one legitimate deviation — `bare_enum_tag_unifies_with_owning_enum_type`'s `src` inlined onto one line (`isNone(o: Option) -> Bool = o == None`) instead of the brief's multi-line form — still exercises the intended regression: `o` (typed `Option`) compared against bare tag `None`, which only type-checks under the fixed `TypeName` arm (owning-enum lookup) rather than the old self-typing behavior. Confirmed this preserves original test intent; not a spec violation given the documented, verified grammar limitation.

- `EnumVariantInfo`/`EnumVariants` shape matches the exact names/types later tasks depend on. `ast::EnumVariant.fields: Vec<String>` correctly feeds `plum_type_from_ast`.