17. Stdlib (pocket version)

TL;DR (5 lines)

Stdlib families exist to separate responsibilities.
A complete scenario teaches more than a flat catalog.
Validation and transport should stay apart.
Family boundaries matter in docs as much as in code.
The chapter should scale to the whole library tree.

Concrete Problem

Readers often see stdlib pages as catalogs with no architectural guidance, so they cannot place new code correctly.

Coherent example

space demo/stdlib

form Manifest {
  name: string
  root_path: string
  targets: int
}

pick Plan {
  case Ready(summary: string)
  case Invalid(code: int)
}

proc normalize_root(root_path: string) -> string {
  if root_path == "" { give "." }
  give root_path
}

proc validate_manifest(m: Manifest) -> Plan {
  if m.name == "" { give Plan.Invalid(11) }
  if m.targets <= 0 { give Plan.Invalid(12) }
  give Plan.Ready(m.name)
}

Global explanation

The stdlib should be taught by ownership. Core helpers, collections, data transforms, path and I/O boundaries, JSON, concurrency, and runtime-facing families all solve different problems. The chapter is useful only if the reader can classify future code with it.

Short exercise

Take the example and say which future step would belong to `json`, which to `io`, and which should remain in pure domain code.

Next best action

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