artlegend/HANDOFF_2026-05-07.md

# Agent Handoff — May 7, 2026

## Session Summary

This session was design-focused, not implementation-focused. Two things were accomplished:

1. The Corridor Scroll module mechanics were fully described and documented.
2. The Vector Drawing module design conversation was started but not finished — bill had to leave mid-discussion.

---

## What Was Accomplished

### Documentation

- Created `MODULES.md` — the authoritative module design reference. This file exists specifically because design decisions were being re-explained from scratch each session. Keep it updated.
- Updated `README.md` — module list now reflects Corridor Scroll (not "Line Corridor"), added Stroke-to-Drawing, updated the vision paragraph to describe the scroll mechanic properly, and linked to MODULES.md.

### Corridor Scroll — design is settled

Full mechanics documented in `MODULES.md`. Summary:
- Guitar Hero-style scrolling corridor, player tracks it with the stylus
- Scroll direction angle changes over time — full 360° range at high difficulty, no angle changes at low difficulty
- Difficulty knobs: scroll speed, corridor width, angle change frequency/severity, lookahead distance
- Scoring: running tally of fill coverage (rewarded) + wall crossings (penalized). No pressure component.
- Early levels: straight corridor only. Later levels: any angle including full reversals.

### Code change from this session

`LineScore` was updated to replace `pressureConsistency` with `anglePrecision` (straightness 60%, angle 40%). This was done before the full corridor scroll mechanic was described — **this scoring model is now likely wrong for the module as designed.** The corridor scroll is real-time tracking, not a single-stroke grade. The scoring architecture will need to be rethought when implementation resumes. Don't build on top of the current `LineScore`/`computeScore()` without revisiting it first.

---

## In Progress: Vector Drawing Module Design

This conversation started but was not finished. Here is where it was left.

### What was proposed (by the agent — not yet agreed with bill)

Three sub-exercises, each isolating a different aspect of vector tool use:

1. **Anchor placement** — target curve shown, player repositions pre-suggested anchor points. Teaches where joints belong (corners, inflection points, extrema).
2. **Handle pulling** — anchors pre-placed, player drags handles to shape the curve against a target. Teaches handle angle/length intuition.
3. **Full trace** — player places anchors and pulls handles from scratch. Scored on fidelity to target AND anchor economy (fewer anchors = better, if fidelity holds).

Difficulty progression proposed:
- Easy: target visible while working, simple open curves, loose tolerance, no economy pressure.
- Hard: target shown briefly then hidden, complex closed shapes, tight tolerance, economy weighted heavily.

### Open questions — bill had not yet answered these

These need to be discussed before MODULES.md is updated with the vector module design:

1. **Simulate a specific tool or abstract it?** Should exercises feel like practicing for Illustrator's pen tool specifically (with its handle-breaking behavior etc.), or be a simplified universal bezier model that transfers to any app?

2. **Anchor economy in scoring?** Good habit to teach, but may frustrate beginners. Should economy only factor in at higher difficulty, or always be part of the score?

3. **Target content** — abstract curves and blobs, or recognizable things like letterforms and simple character shapes? Recognizable is more motivating but harder to generate procedurally.

4. **Target visibility** — should seeing the target while you trace always be available as a beginner/accessibility option, or does the module intentionally remove it as difficulty increases?

5. **Does pressure matter here?** Real vector tools ignore pressure. But this is an S-Pen trainer. Should the module ignore pressure entirely, or is there a creative angle (e.g. calligraphic vector mode where handle length is pressure-driven)?

### Where to pick up

Resume by getting bill's answers to the five questions above. Once agreed, write the Vector Drawing section in `MODULES.md` using the same format as the Corridor Scroll section. Do not write any implementation code until the design is settled and documented.

---

## Broader Reminders for Next Agent

- **Design before code.** Bill has explicitly said assumptions get made when mechanics aren't written out. When something is ambiguous, discuss and document first.
- **Keep MODULES.md updated.** It exists to prevent re-explanation. Every settled design decision goes there.
- **The current `LineCorridorScreen` and `LineScore` are placeholders**, not the real implementation of Corridor Scroll. The real mechanic (scrolling corridor, real-time tracking) is fundamentally different from what's coded (static corridor, single stroke scored on lift).
- Build command: `JAVA_HOME="/Users/blindmouse/Applications/IntelliJ IDEA.app/Contents/jbr/Contents/Home" ./gradlew :android:assembleDebug`
- APK output: `android/build/outputs/apk/debug/android-debug.apk`
- AL-009 (on-device smoke test) is still the only open sprint ticket — needs a physical device.