delegated-work-acceptance

Topics in the source

• Delegated work acceptance
• 0. Know what acceptance means here
• 0.5 Dispatching the bounded batch (the other half of the loop)
• 1. Verify from the diff, not from the receipt
• 2. Re-derive every number that the deliverable depends on
• 3. Judge a corpus or graph finding on its mechanism
• 4. Keeping the change inside the boundary
• 5. Correct the deliverable's own report when it is imprecise

A teammate's completion message is a claim, not a delivery. This skill is the pass that decides whether to accept it, and it is the same pass whether the work is a repair, a report, a corpus scan or a writing handoff. Acceptance has two halves: the artifact matches the claim, and the change stayed inside the sender's write surface and out of the reserved lanes. Both are verified by you. Nothing the teammate says about its own verification transfers — it is a witness, not evidence. Before you answer, re-open the role contract: your own write list, the sender's write list, and what needs operator approval. Your job in this loop is verify + rule + route, almost never repair. Acceptance presupposes a bounded dispatch. Send the work as a request FILE, not a chat prompt, so the sender works from a fixed scope and the acceptance criteria exist before the work starts: Request file in the owning task dir ( / -request.md): Context (exact files to read) → Scope (explicit write surface, named exclusions, "no scheduled-job / config / profile / repo write" clauses, rollback expectations) → Deliver (numbered, each item with its gate and the real baseline numbers) → output artifact requirements (r

This is an excerpt. Refer to the complete source and its current requirements.