# Rehearsing the exercise with a coding agent + java-refactoring-mcp

How Willem can rehearse the exercise (and test whether an agent can do it)
using [java-refactoring-mcp](https://github.com/pfichtner/java-refactoring-mcp)'s
CLI as the semantic refactoring backend. One-time setup, then a repeatable
session script.

## One-time setup

```bash
# 1. Build the tool (needs Java 21 + Maven 3.8+)
git clone https://github.com/pfichtner/java-refactoring-mcp
cd java-refactoring-mcp && mvn package -DskipTests
# → refactor-mcp/target/refactor-mcp-*-fat.jar

# 2. Install the CLI wrapper (see that repo's README, "CLI (optional)"):
#    gives you the `java-refactor` command.

# 3. Sanctioned dirs for the MCP server (it refuses paths outside this list)
#    — check the repo docs for the exact env var / flag.

# 4. Copy the exercise (NOT the solution folder) to a scratch workspace
cp -r exercise/java ~/scratch/prefactored-longrange
```

## Session script

Run the agent in `~/scratch/prefactored-longrange` with a prompt like:

> You may only change code by invoking `java-refactor` CLI commands
> (`java-refactor --help` lists them). Never edit `.java` files with text
> edits, except lines marked by the CLI as needing manual work.
> After each refactoring, run `mvn -q test` (it may fail — that is expected;
> the dependency on `Scorer` makes the method untestable — but it must
> still *compile*).
>
> Goal: in `LongRangeForecasts.longRangeForecast()`, the loop over `DATES`
> collects weather by calling `scorer` (an unwanted external dependency).
>
> 1. Introduce a lambda for the scorer-dependent code and move its
>    definition to the top of the method, leaving the invocation where it is.
>    (No tool supports this — do it as a minimal manual edit.)
> 2. Extract the weather-collection loop into a new method
>    `collectExpectedWeather` that takes the lambda as a parameter
>    (suggested type `LongFunction<Boolean>`).
> 3. Stop. Report the final diff.

Then compare the agent's end state against `exercise/solution/` (or diff
against it directly) and run `mvn test` with the solution's test + approved
file dropped in: it must pass deterministically.

## What this rehearsal tells you

- The mechanics-with-names prompt (introduce lambda / slide statement /
  extract method + introduce parameter) is unambiguous enough that an agent
  with weak tool-calling (qwen 35B) can follow it — if it can, a human
  pair can too.
- Which steps the agent drifts on (usually step 1, where it tends to skip
  the lambda and just extract a method that closes over `scorer` — the
  exact mistake participants make). Collect these failure modes: they are
  gold for the concept slide and the debrief.
- Time estimate for the exercise: run it twice, once tool-only, once with
  the manual lambda edit. The gap between the two is the "no tool support"
  friction participants will feel.

## Tool coverage cheat sheet

| Mechanic | Tool support |
|---|---|
| introduce lambda | none — manual edit |
| slide statement | none — manual edit |
| extract method | `java-refactor extract` |
| add lambda parameter | `java-refactor introduce-param` / `change-method-signature` |
| move method to another class (step 4, not in scope) | `java-refactor move-method` (call sites not rewritten) |