Merge pull request 'Playbook 07 follows report-cadence: the short report every five minutes, the full one every thirty' (#491) from pb/report-cadence into main

00-META/process/07-feature-branches.md

@@ -93,7 +93,7 @@ small fix ([playbook 08](08-small-fixes.md)) while the milestone waits on a chec
 rest are fixed right after the milestone's delivery, before the next milestone starts, together on one branch where
 they share a repository. Either way it stays out of the running milestone's branch and pull request, unless it blocks
 the running milestone, so the scope above holds. Only an issue in another design's milestones (one design is built at
-a time), or one that needs a decision or the operator first, waits, and the report says which and why. Each report's line "Opened along the way" says for every
+a time), or one that needs a decision or the operator first, waits, and the report says which and why. Each detailed report's line "Opened along the way" says for every
 issue whether it is being fixed in between, after the delivery, or waits, and on what.
 
 ## Step 0 — Prepare (the lead, larger model)
@@ -527,56 +527,43 @@ Approve, a Retry or a Release waits for them, it reads `operator-channel.asks` a
 on 2026-10-20 an ask was named to the operator that the router did not hold. A merge the gate passed but whose
 ask is not on the router is the fault of the Approve's wait in the table above.
 
-**Every five minutes (the operator, 2026-10-17, ten then; five since 2026-10-26), every two minutes while a delivery moves (the view says modules `moving`), and at once when something lands, stops or
+**The cadence is the instruction section "report-cadence"** (the operator, 2026-10-28; it replaces the full layout every
-needs the operator,** the lead reports, in one of the two layouts below (the operator, 2026-10-16: an overview
+five minutes of "how-work-is-done"). Times are local and absolute, from the clock (`date`), never guessed; every number
-of the issues, often). Times are local and absolute, from the clock (`date`), never guessed; every number has its
+has its unit and its bound or baseline; an issue is named by its number and a few words, never by its number alone.
-unit and its bound or baseline; an issue is named by its number and a few words, never by its number alone.
 
-**The full layout** (in the session) is the whole design as a tree (the operator, 2026-10-17: always the full
+- **Every five minutes** (ten until 2026-10-26, five since), every two minutes while a delivery moves (the view says
-overview): every milestone of the design with its state, and under the running milestone its repositories and
+  modules `moving`), and at once when something lands, stops or needs the operator, the lead sends the **short
-their issues, each issue under the one it waits for, marked ✓ landed or delivered, ▶ fixing, ⏸ waiting, ✗ stopped:
+  report**: the tree exactly as `knowledge-base.progress` with `of: "design <nn>"` and `detail: minimal` answers it,
+  unedited, with the verb's read-at time, then at most three lines: what changed, what needs the operator, what is next.
+  Once the verb takes `since`, the short report asks `since: 5m`.
+- **About every thirty minutes**, and whenever something stops, the lead sends the **detailed report**: the same verb
+  with `detail: detailed` (or `since: 60m`), then the full layout below.
+- **Every report ends by scheduling the next** (a timer or a watcher set ahead), so that agents' incoming reports
+  never replace it.
+- **An answer to the operator between reports is short and has no tree.**
+
+**The tree is the verb's answer and is never drawn or corrected by hand.** `knowledge-base.progress` answers the
+design's milestones, issues, pull requests and held groups in one call, each with when it last moved (issue 1947).
+What it cannot read for certain from the design's milestone table it says in `warnings`; the lead fixes the table, it
+does not correct the tree by hand.
+
+**The full layout** (the detailed report) is the verb's detailed tree followed by these lines:
 
 ```
-Feature <slug> · milestone <n> of <m> · step <name>, <minutes used> of <bound> min
-Issues: <landed> of <total> landed · <fixing> fixing · <waiting> waiting
-
-Design <nn> · <its title>
-├── ✓ milestone 1  <its outcome, a few words>                 delivered 12:58
-├── ▶ milestone 2  <its outcome, a few words>
-│   ├── mesh-controller (agent: fixing, 2 of 3 landed)
-│   │   ├── ✓ 652  assignments on the bus                      landed 14:02
-│   │   ├── ▶ 736  placement words leave the layers            fixing since 13:51, 23 of 30 min
-│   │   │   └── ⏸ 751  config keys named (mesh-catalog)        waits for 736
-│   │   └── ✓ 654  a file names its template                   landed 13:20
-│   └── mesh-catalog (agent: waiting)
-│       └── ⏸ 751  (above, under 736)
-└── ⏸ milestone 3  <its outcome, a few words>                 <its issues>
-
 Opened along the way: <each issue opened during the feature, its number and a few words, and when it is fixed: in between, after the delivery, or waits on what> — or "none"
 Past its bound: <the wait, how long, what is being done> — or "none"
 Needs you: <one line per question, with my recommendation> — or "nothing"
 Allowance: week <n> % (<+d> since the last report), session <n> %
+Worth it: <what in the last stretch served the goal, and what did not>
 Next: <the next actions up to the delivery, in order>
 ```
 
-**Every report ends by scheduling the next** (a timer or a watcher set for five minutes ahead), so that agents'
+How it is checked: the operator sees a short report at least every five minutes and a detailed one at least every
-incoming reports never replace it. How it is checked: the operator sees a report at least every five minutes.
+thirty; a report's tree that differs from the verb's answer of the same minute is a tree assembled by hand, a report
-**The report starts with the tree, drawn from the verb's answer and never by hand.** `knowledge-base.progress` with `of: "design <nn>"` answers the tree's
+without the verb's read-at time is the same, and a report that does not end by scheduling the next is a breach the
-milestones, issues, pull requests and held groups in one call, each with when it last moved: `detail: minimal` for the
+lead reports.
-five-minute report, `detailed` about every thirty minutes and whenever something stops (issue 1947). What it cannot
-read for certain from the design's milestone table it says in `warnings`; the lead fixes the table, it does not
-correct the tree by hand. How it is checked: a report's tree that disagrees with the verb's answer of the same minute
-is a tree assembled by hand, and a report that does not quote the verb's read-at time is the same.
 
-**The short layout** (on a channel such as Telegram, or when nothing changed but time):
+On a channel such as Telegram the same short report is sent, the tree as a code block.
-
-```
-<slug> milestone <n>/<m> · <step> <used>/<bound> min · <landed>/<total> landed · past bound: <none | what> · needs you: <nothing | what> · week <n> %
-```
-
-A report says what changed since the last one first. In the session every report is the full layout, the whole
-tree of the milestone's issues included, also when only time passed: the operator reads the state from it without
-asking. The short layout is for a channel.
 
 ## The context of the lead's own session