38. Refactoring guided by types (pocket version)

TL;DR (5 lines)

Types are contracts, not decorations.
A small form is a better teaching unit than isolated declarations.
The chapter should connect type names to domain meaning.
Invalid examples should show broken contracts clearly.
Type clarity reduces later diagnostic work.

Concrete Problem

Readers often learn type names but not what type contracts buy them in a real block.

Coherent example

space demo/types

form Report {
  name: string
  retries: int
  ok: bool
}

proc score(r: Report) -> int {
  if not r.ok { give 0 }
  give r.retries + 1
}

Global explanation

The value of the chapter is not the list of types. It is the way each type removes ambiguity from the block: text is text, counters are numeric, flags are boolean, and the compiler can enforce that split.

Short exercise

Take the example form and add one field whose meaning is obviously not numeric. Choose the type that makes the contract clearest.

Next best action

Keep the example small, reproduce it locally, then continue to the full chapter if you need the broader context.