plan: the model that writes a plan learns this week's keys

`does`, `shows`, `mail`, `mails`, `invites_by`, `events`,
`attended_by`, and the measured guidance on doors: the plan reference
the model reads lagged the builder by a week, so a planned site had no
opener, no mails and no onboarding.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

src/plan.rs

@@ -31,13 +31,27 @@ language: en                  # the intake's language code
 contact: { name: <who answers for the site>, email: <their email> }
 about: >
   What the business does, in its own words.
+mail: { from: "<name> <post@their-domain>", reply_to: <their inbox> }
+                              # who every mail the site sends comes from; required as soon
+                              # as any need has `mails`
 
-doors:                        # a first question before the forms, when more than four or
-  - id: kebab-case            # five needs would otherwise sit on the front door: one door
-    who: who comes through it # per kind of visitor, two or three needs behind each
+does:                         # the front door's first card: what the business does, one
+  - id: kebab-case            # or two features, one role each, no button. Say it for the
+    for: <need id>            # role the business exists for and the next one it serves.
+    text: what it does for them, in the intake's own words
+
+shows:                        # things a visitor may look at before asking for anything;
+  - id: kebab-case            # each `resource` is portal's resource block, verbatim
+    text: one line on what it is
+    resource: { public: true, source: { kind: url, url: https://... } }
+
+doors:                        # a first question before the forms, only when the offers
+  - id: kebab-case            # are more than one page holds (measured: four doors beat
+    who: who comes through it # ten offers on one page; six offers on one page beat doors)
 
 groups:                       # groups with a label the public may see: the committees
-  - { id: traffic, label: Traffic }   # a person can ask to join (optional)
+  - { id: traffic, label: Traffic, invited_by: [board] }   # a person can ask to join (optional)
+invites_by: [board]           # groups whose desk may invite people into every desk
 
 needs:
   - id: kebab-case            # ASCII only
@@ -62,6 +76,14 @@ needs:
                               # form; the form must then collect a required `email`)
     watched_by: [<group>]     # groups that see these cases and move nothing; `public` opens a
                               # read-only page of the bucket to everyone (contact details hidden)
+    mails: { open: submitter, <end>: submitter, <stage>: <address> }
+                              # who hears when a case enters a stage: `submitter` (the form
+                              # must then collect a required `email`) or one address. Tell the
+                              # person on arrival and on every decision that is about them.
+    events: { open: applied } # ONLY when rebuilding a live site: the event names its
+                              # aggregates.yaml already has, so its records keep replaying
+    attended_by: >            # ONLY for a stage no desk button moves: the automation that does
+      what moves it, in a sentence
     max_fields: 4             # how many required fields THIS person will tolerate, from what
                               # the intake says about them: someone on a phone with gloves
                               # on gets 3, a first enquiry 4 to 6, a firm's paperwork 5 to 6
@@ -81,9 +103,15 @@ Rules:
   business counts: a role recording or posting something is a need
   with `enters_as`. The intake's "what slows us down" usually names one.
 - Groups are the roles the intake names, as snake_case identifiers.
-- The front door holds at most five alternatives: doors plus needs
+- The front door opens with `does` (at most two features, one role
+  each) and `shows`, then holds at most seven offers: doors plus needs
   with no door. A door with no need behind it, or a door on a need with
-  `enters_as`, is refused.
+  `enters_as`, is refused. A role `does` speaks for must have a move
+  of its own after sending (`moves_by` with `submitter`) or a public
+  view, or it is a spectator.
+- Every need whose form collects an email should tell the person on
+  arrival and on the decisions about them (`mails`); the plan then
+  needs `mail: { from }`.
 - Needs that land in the same bucket must have the same stages,
   done_when, skippable, moves_by, watched_by and handled_by.
 - Every required field is one the business will use to act on the