workflow: drop docs/WhatsNew.md (Notify carries done-state on its own)

WhatsNew.md duplicated the Notify text into a file the only reader
(the user) does not consult. Removed the file and trimmed every
reference in the live control docs (CLAUDE.md, skills/boss,
skills/implement). The editorial rules (no internals,
telegram-pragmatic, factual) are preserved in skills/boss as
notify-text discipline. Historical specs/plans/journals are not
rewritten — they show the contemporaneous state.
This commit is contained in:
2026-05-20 10:27:33 +02:00
parent ac4d545570
commit 55ad0fa37f
5 changed files with 16 additions and 284 deletions
+11 -24
View File
@@ -57,7 +57,6 @@ NO AUTONOMOUS DISPATCH OUTSIDE A `/boss` SESSION.
DONE-STATE = QUEUE EMPTY, NOT SUB-GOAL COMPLETE.
BOUNCE-BACK ONLY ON THE FOUR NAMED TRIGGERS.
A NEW MILESTONE NEVER STARTS AUTONOMOUSLY — IT IS A BOUNCE-BACK.
WHATSNEW.MD + NOTIFY ARE ONE TEXT, NOT TWO.
```
Universal rules (only-Boss-commits, main-is-sacrosanct, language,
@@ -119,10 +118,9 @@ For each dispatched skill's result, decide:
ratified (audit clean, fieldtest clean if applicable). Go to
Step 5.
### Step 5 — On done-state: WhatsNew.md + Notify
### Step 5 — On done-state: Notify
Run the procedure named in "Done-state notifications: WhatsNew.md"
below. The two outputs share one verbatim text.
Run the procedure named in "Done-state notifications" below.
## Direction freedom
@@ -212,22 +210,17 @@ and likely respond by returning to the session.
By default, I act autonomous. The notification is the
exception, not the rule.
## Done-state notifications: WhatsNew.md
## Done-state notifications
When the trigger is **done-state** (autonomous work has wrapped
up, nothing left to do for the user to react to), the procedure
is two-step and the two outputs share one text:
1. Append a new entry to `docs/WhatsNew.md` (newest at the bottom,
append-only — same chronological convention as the per-iter journals).
2. Send the same text via `~/.claude/notify.sh`.
up, nothing left to do for the user to react to), send one text
via `~/.claude/notify.sh`.
The text must be written for the **user-as-reader who did not
watch me work**:
- **Language: English.** Same as the rest of the repo; both
WhatsNew.md and the Notify push are permanent enough to be
treated as project content.
- **Language: English.** Same as the rest of the repo; the
Notify push is permanent enough to be treated as project content.
- **No technical internals.** Don't name crates, function
identifiers, type names, agent names, or iteration codes
(`ct.1.7`, `18a`, etc.). Describe the *change in the project*
@@ -242,12 +235,8 @@ watch me work**:
successfully…". Just "X works now, Y is fixed, Z is new".
**Bounce-backs** (asking the user for a design judgement or
checkpoint) are *not* done-state and do **not** produce a
WhatsNew entry — they stay as Notify-only.
Format of a WhatsNew entry: a `## YYYY-MM-DD — <short title>`
heading followed by the message body. The body must match the
Notify text verbatim.
checkpoint) follow the same editorial rules but carry the
actionable ask, not a wrap-up summary.
## Common Rationalisations
@@ -257,8 +246,7 @@ Notify text verbatim.
| "Sub-goal of the milestone is done, that counts as done-state" | Done-state is queue-empty, not sub-goal-complete. If the next iter is obvious and substantive, keep dispatching. |
| "Top of roadmap has two equally good options, I'll just pick one" | If both are substantive and the choice is non-obvious, that's a real fork — bounce back. The cost of a wrong pick (working-tree discard) is higher than the cost of one short ping to the user. |
| "User said 'until X then notify', X just completed, notify now" | Check whether X was actually the last actionable thing. If hitting X leaves an open milestone with obvious follow-up, the user's intent was "wake me when there's nothing else to do" — continue. |
| "Done-state hit, send notify, append WhatsNew later" | WhatsNew + notify are one text. Append first (atomic), send second. Splitting them is how the WhatsNew gets forgotten. |
| "WhatsNew can name the iter code — user will figure out what it means" | No. WhatsNew is for the user-as-reader who did not watch me work. Iter codes, crate names, function identifiers, type names — all internal, all banned. |
| "Notify can name the iter code — user will figure out what it means" | No. The notify text is for the user-as-reader who did not watch me work. Iter codes, crate names, function identifiers, type names — all internal, all banned. |
| "The previous milestone closed cleanly and the next roadmap item is obvious — just dispatch `brainstorm` and keep going" | No. Starting a new milestone is itself a bounce-back. A fresh `brainstorm` is high-context work, and I cannot compact my own context — only the user can decide whether the next milestone wants a fresh session or a continuation of this one. The "obviousness" of the candidate is irrelevant; the *cross-milestone hop* is the checkpoint, not the topic choice. |
| "It's the same broad area as the milestone I just closed, that's not really a new milestone" | If there is no `docs/specs/<...>.md` file for it yet and it would route through `brainstorm` to get one, it IS a new milestone for this rule's purposes. The rule keys on "needs a fresh spec", not on subjective continuity. |
@@ -267,9 +255,8 @@ Notify text verbatim.
- About to send a notify on an internal-progress event (test suite landed, audit clean before close-fixes, iter N done with N+1 in scope).
- About to dispatch the next skill without checking that the previous output was actually good.
- About to autonomously dispatch in a session where the user did NOT type `/boss`.
- About to write a WhatsNew entry that names a crate, an iter code, or an agent.
- About to send a notify that names a crate, an iter code, or an agent.
- About to bounce back at every iter boundary "just to be safe" — that's reactive deference, not direction freedom.
- About to send the WhatsNew text and the Notify text with different wording — they must be one verbatim text.
- About to dispatch `brainstorm` on a roadmap item that does not yet have a spec file, without first bouncing back to the user. New milestones never start autonomously.
## Cross-references
+2 -4
View File
@@ -140,10 +140,8 @@ unstaged changes. Nothing is committed yet.
5. Append one line to `docs/journals/INDEX.md` and include it in
the same commit (or a follow-up commit):
`- YYYY-MM-DD — iter <iter_id>: <one-line title> → <YYYY-MM-DD>-iter-<iter_id>.md`
6. If trigger is done-state and the user is away, write a
`docs/WhatsNew.md` entry + run `notify.sh` per
`skills/boss/SKILL.md` "Done-state notifications: WhatsNew.md"
subsection.
6. If trigger is done-state and the user is away, run `notify.sh`
per `skills/boss/SKILL.md` "Done-state notifications" subsection.
### Step 4 — Boss handling (on BLOCKED)
@@ -29,9 +29,9 @@ context and dies with it.
Read these before doing anything else, in this order:
1. `CLAUDE.md` — orchestrator framing (agent role boundaries,
commit discipline). Note: the "Done-state notifications:
WhatsNew.md" procedure has moved to `skills/boss/SKILL.md`;
WhatsNew is Boss-side regardless of mode, NOT this agent's job.
commit discipline). Note: the "Done-state notifications"
procedure lives in `skills/boss/SKILL.md`; the notify is
Boss-side regardless of mode, NOT this agent's job.
2. `design/INDEX.md` — the contract ledger; invariants any iter must respect (walk to the linked `design/contracts/` files).
3. `docs/journals/INDEX.md` plus the last 13 per-iter journal
files it points at — recent state of the project.