Draft Adr

User perspective analysis: Evaluate the decision from each user persona's viewpoint:

a. Newcomer (learning Beamtalk, coming from Python/JS/Ruby):

• Is this intuitive? Would they guess the syntax?
• What error messages would they see if they get it wrong?
• Can they discover this feature through REPL exploration?

b. Smalltalk developer (experienced, opinionated about Smalltalk purity):

• Does this feel like Smalltalk? If not, is the departure justified?
• Would they find this in Pharo/Squeak? If not, why are we adding it?
• Does this preserve message-passing semantics?

c. Erlang/Elixir developer (using Beamtalk for BEAM interop):

• Does this work naturally with OTP patterns?
• Can they call this from Erlang/Elixir? Can Beamtalk call their code?
• Does this generate predictable, debuggable BEAM code?

d. Production operator (running Beamtalk in production):

• Does this affect hot code reloading?
• Performance implications at scale?
• Observable/debuggable with standard BEAM tools? (observer, recon, dbg)

e. Tooling developer (building IDE support, LSP, debugger):

• Can the LSP provide completions/diagnostics for this?
• Does this make static analysis easier or harder?
• Is the AST representation clean enough for tooling?

DevEx validation: Before finalizing options, check each against the DevEx checklist:

• Can you demonstrate this in 1-2 lines of REPL code?
• What does the error look like when used incorrectly?
• Is the feature discoverable (via tab completion, help, reflection)?
• Does it compose well with existing features?

If you can't write a compelling REPL example, the design needs more work.

Identify options: List 2-4 concrete approaches with trade-offs:

For each option:

• Description: What would this look like in practice?
• Code example: Show how it would appear in Beamtalk syntax or implementation
• REPL example: 1-2 lines showing the feature in use interactively
• Error example: What happens when used incorrectly?
• Pros: Benefits, alignment with principles
• Cons: Costs, complexity, limitations
• User impact: How each persona (newcomer, Smalltalker, Erlang dev) would experience this
• Comparison: Which reference language is this closest to? Where does it diverge?
• Affected components: Which layers of the pipeline? (parser, codegen, runtime, REPL)
• Effort: Rough size estimate (S/M/L/XL)

Steelman each option: For each option, argue for it from every user cohort's perspective. The goal is to find the strongest possible case for options you might otherwise dismiss.

For each option, write the best argument a member of each cohort would make:

Rules for steelmanning:

• Argue genuinely — find the real strength, not a strawman
• If you can't steelman an option from any cohort, it's probably a weak option
• If an option you planned to reject gets a compelling steelman, reconsider
• Note when different cohorts would choose different options — that tension is valuable signal

Present the steelman summary to the user:

## Steelman Analysis

### Option A: [Name]
- 🧑‍💻 **Newcomer**: "This is most intuitive because [X] — I'd guess this syntax without reading docs"
- 🎩 **Smalltalk purist**: "This stays true to message-passing because [Y]"
- ⚙️ **BEAM veteran**: "This maps cleanly to OTP because [Z]"
- 🏭 **Operator**: "This is observable and predictable because [W]"
- 🎨 **Language designer**: "This composes well because [V]"

### Option B: [Name]
- 🧑‍💻 **Newcomer**: "This matches what I know from Python/JS because [X]"
- ...

### Tension Points
- Newcomers prefer Option B but Smalltalk purists strongly prefer Option A
- BEAM veterans and operators agree on Option A
- Language designers are split: A is more elegant, B is more pragmatic

Present options to user: Show the options with steelman analysis and a clear recommendation:

## Option A: [Name] (Recommended)
[Description, code example, pros/cons]

## Option B: [Name]
[Description, code example, pros/cons]

## Steelman Summary
[Condensed from step 6]

## Recommendation
Option A because [reasoning informed by steelman analysis].

Wait for the user to choose or discuss before writing the ADR.

Determine next ADR number:

ls docs/ADR/*.md | grep -v README | sort | tail -1

Increment from the highest existing number.

Write the ADR: Copy docs/ADR/TEMPLATE.md to docs/ADR/NNNN-kebab-case-title.md and fill in all sections using the research, options analysis, and steelman results from previous steps.

cp docs/ADR/TEMPLATE.md docs/ADR/NNNN-kebab-case-title.md

Fill in every section. Remove Migration Path if not applicable. The Prior Art, User Impact, and Steelman Analysis sections should draw directly from steps 2d, 3, and 6.

Update the ADR index: Add the new ADR to docs/ADR/README.md.

Commit the ADR: