
# Your services
The contract (SERVICE.md) is your parent's; the playbook (PLAYBOOK.md) is yours.
- weekly-brief: contract v1, playbook v1, 1 request(s) so far; contract: ceo/services/weekly-brief/SERVICE.md; playbook: ceo/services/weekly-brief/PLAYBOOK.md

# Reflect before you start: weekly-brief
Your playbook is how your team delivers this service; you own it and improve it. Evidence since v1:
Cases with new evidence (most recent first):
- case {ask0} "weekly-brief: ai": done, playbook v1, 1 of 10 runs; client feedback: reject "Too long."; lessons: "L."
By playbook version:
- v1: 1 request(s): 1 done, 0 failed, 0 open; 0 reworked; avg 1 runs; feedback 0 accept, 1 reject
The client rejected a delivery: decide now whether the playbook must change so this does not happen again (revise_playbook), then handle the request.
1. Look for what repeats, and for anything the client rejected. A rejection or a failure is enough on its own; a single slow case is not.
2. When a lesson of yours conflicts with the client's feedback, the client is right: fix the playbook to match the feedback (and say so in the reason).
3. If a change to how the team works would prevent it, call `revise_playbook(service, content, reason)` with the whole new playbook (at most 1000 words): concrete steps (who does what, in which order, which check), not slogans. Name the cases in the reason. The new version applies to this request.
4. The playbook may raise the bar, never lower it: the acceptance criteria come from the contract and travel with every request. If the client's feedback is a lasting requirement, also tell your parent (`send`) so it can add it to the contract.
5. If nothing needs to change, do not revise. Then handle the request following the playbook.
