writeonce/docs/examples/employee-list
shoney.arickathil a798cf6698 docs: pending iterations renumbered by dependency + priority
- developer directive: pending iteration IDs now ARE the priority order;
  LANDED iterations keep historical numbers (code comments and commit
  history cite them — records, not a queue); 8/11 (the half-landed
  arc), 17 (parked, artifacts on a branch), 18 (next, artifacts named)
  also frozen
- mapping (recorded in 00-story): 19<-20 Float+Bytes, 20<-9c attach,
  21<-9d keypair, 22<-9e benchmarks, 23<-9f io_uring WAL, 24<-19 chat,
  25<-10 services, 26<-12 blue-green, 27<-9g query corpus,
  28<-14 skillhost, 29<-13 metaprogramming
- 11 story files renamed; every doc reference re-numbered (word-boundary
  sweep for the lettered 9x ids, phrase-level for numeric ones); the
  iterations table rewritten with Seq == priority and "(was N)" notes;
  story-scoped link check: zero broken
- merge-recovery folded in: the partial master merge had dropped the
  chat story, the fibers exploration note, the arc spec+plan, the
  framework-v2 plan, and the iteration-17 spec+plan — all restored from
  their branches and renumbered consistently

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-20 14:31:09 +02:00
..
main.wo docs: employee-list sample -- program B's manifest pair (9c/9d target) 2026-08-15 12:34:19 +02:00
README.md docs: pending iterations renumbered by dependency + priority 2026-08-20 14:31:09 +02:00
wo.toml docs: employee-list sample -- program B's manifest pair (9c/9d target) 2026-08-15 12:34:19 +02:00

employee-list — program B: attach, authenticate, read

Status: target workload — does not compile on today's toolchain. Written ahead of iterations 20 (cross-program tables) and 21 (keypair attach auth), the way every acceptance sample here precedes its features. It also leans on 9/9b (the employee sample it attaches to must run first).

Two programs, one database, one writer:

employee (A)                          employee-list (B)
  owns WO_DATA + WAL                    no database of its own
  [share] listen = unix:...sock         [connect.employee] ipc = unix:...sock
  [[share.clients]]                     public_key = <A's fingerprint, pinned>
    public_key = <B's fingerprint>      project    = ../employee  (shapes)
    rights     = "read"
        ▲                                     │
        └── every statement executes here ◄───┘   (typed, over the wire)

The manifests are the design: A grants, B pins. A's [share] names B's public-key fingerprint with rights (read here); B's [connect.employee] names A's IPC string AND A's fingerprint, so neither side talks to an impostor. Fingerprints are printed by each program's --identity after first boot (keys are generated into WO_DATA, never written into a toml) and pasted — the PASTE-…-HERE placeholders mark exactly where. The connect-section name is the code's namespace: [connect.employee] is why the source says employee.Employee.

Mode What it proves
employee-list list typed reads over the wire, e.dept.name ref navigation executing inside A
employee-list report byte-identical output to A's own report — attach + GroupBy compose, the wire changes nothing
employee-list staff <dept> unique-name index probe + staff backlink scan, both in A
employee-list probe-write the rights matrix: registered read-only, so the insert traps with access-denied (caught, DENIED …, exit 4) and A's row count is unchanged

The 21 acceptance drives the rest from the outside: wrong key, no key, same-uid-wrong-key, impostor socket, handshake replay, key rotation — see the iteration's criteria; this sample is the workload they run against.