Approval decided: one shared mechanism; calendar writes exempt

docs/ask-contract.md

@@ -125,15 +125,22 @@ POST /notify
 
 ## Approval (write actions)
 
-A write action needs a human yes. This is one shared pattern, not one per project.
+Some write actions need a human yes. This is one shared pattern, not one per
+project.
 
-1. The project sends an approval request: what, who, why, and a one-time id.
+1. The project (or the Hub) sends an approval request: what, who, why, and a
+   one-time id.
 2. The admin app shows **"Did you ask for this?"**.
 3. On tap, the admin app calls the project to execute.
 4. The project executes once and returns the result.
 
-Approval is required for: parental control changes, calendar writes from email or
+Approval **is required** for:
-school, and any Paperclip job.
+
+- a parental control change (cut or restore the kids' internet, change a schedule),
+- a Paperclip job.
+
+Approval is **not required** for a calendar write. Email and school may add events.
+These are not dangerous.
 
 **A spoken keycode is not the lock.** Only the admin app confirms.
 

hub_brief.md

@@ -192,6 +192,8 @@ Each project is a **peer**. These are talk directions, not ownership.
 - **Approval is required** for parental controls and Paperclip jobs.
 - **One identity: Sam.** The Hub serves Sam only. The `/ask` contract keeps the
   `asker` field, so a second person can be added later.
+- **One approval, on the admin app.** Only parental control changes and Paperclip
+  jobs need a yes. Calendar writes do not.
 - **Voice is spoken aloud.** With one identity, anyone in the house could imitate
   Sam. Consequential actions are protected by the admin-app tap, not by the voice.
 
@@ -218,27 +220,24 @@ Each project is a **peer**. These are talk directions, not ownership.
 
 ## What is still open
 
-1. **Approval service.** One shared mechanism, or one per project? (See below.)
+1. **Service tokens.** One bearer token per project, stored in `environment.d`.
-2. **Service tokens.** One bearer token per project, stored in `environment.d`.
+2. **Job contract.** Exact fields for a Paperclip job (title, brief, project, agent).
-3. **Job contract.** Exact fields for a Paperclip job (title, brief, project, agent).
+3. **Artemis voice.** Stream or file. When does phone TTS get used?
-4. **Artemis voice.** Stream or file. When does phone TTS get used?
+4. **Paperclip layout.** One company or several. Which projects.
-5. **Paperclip layout.** One company or several. Which projects.
+5. **Routing rules.** The first draft of `routing.md`.
-6. **Routing rules.** The first draft of `routing.md`.
 
-### The approval question
+## Approval (decided)
 
-Three things need a human "yes":
+One shared approval, on the admin app. One place to say no.
 
-- cutting the kids' internet (admin app),
+The request says **what**, **who**, and **why**. You tap. It runs.
-- filing a Paperclip job (Hub → Paperclip),
-- a project writing to the calendar (email adds an event, school books an
-  interview).
 
-Two options:
+Approval **is required** for:
 
-- **One shared approval.** The Hub (or a tiny approvals service) sends the request
+- a parental control change (cut or restore the kids' internet, change a schedule),
-  to the admin app, you tap, it runs. One mechanism, one UI.
+- a Paperclip job.
-- **One per project.** Each project asks in its own way. Simpler now, more to
-  maintain later.
 
-Recommended: **one shared approval.** The admin app already exists.
+Approval is **not required** for:
+
+- a calendar write. Email and school may add events. These are not dangerous.
+  Let them run.