implement-spec: Surface manual acceptance prerequisites before dispatch

## What to build In implement-spec, surface user-owned acceptance prerequisites before dispatching implementation, but only when the spec actually requires them. Identify missing credentials, consent to use and dispose of private data, verified test identities and explicit operational approvals early enough for the human to handle them while code work proceeds. Batch requests through the environment's documented secure intake instead of requesting secrets in chat. Observed in a five-ticket run: one ticket required a real read-only historical evaluation, and another required runtime classifier evidence. The code and automated checks could finish without the dedicated credentials and private-data consent. The credential request came late and timed out, leaving live acceptance outstanding after the implementation was otherwise complete. The final handoff reported that distinction correctly, but the human prerequisites should have been surfaced at kickoff. This is a small improvement to the existing skill, not a new skill, a universal checklist or a harness-specific command branch. Use the environment's documented secure-intake capability; destination validation belongs to that capability rather than more implementation-agent reminders. ## Acceptance criteria - [ ] Before implementation dispatch, derive any user-owned acceptance prerequisites from the supplied spec and tickets. An entirely automated task adds no manual intake ceremony. - [ ] Report a concise list of missing prerequisites and their owners, separating facts discoverable from code/configuration from decisions or permissions only the human can supply. - [ ] Batch credential requests through guarded secure intake. Values never enter chat, logs, tickets or handoffs, and credential destinations stay outside Git repositories. If a suitable secure intake is unavailable, report the blocker rather than inventing an unsafe fallback. - [ ] Consent covers private data ownership, the allowed snapshot/cutoff and disposal; test identities and required permissions are verified before private reads or operational exercises. - [ ] Code completion, operational rollout, live acceptance and enabling an automated action remain separate authorization/evidence states. A merge or deploy approval does not imply credential provisioning, historical evaluation or action enablement. - [ ] Missing prerequisites do not prevent independent safe code work. The final handoff names the remaining acceptance evidence without claiming that fixtures or synthetic labels satisfy real acceptance. - [ ] Verification covers an all-automated task and a task with unavailable private data/credentials and separate activation approval. The latter produces the prerequisite report at kickoff, performs no unauthorized operation and retains the blocker at closeout. Human-facing skill documentation remains aligned. ## Blocked by https://github.com/get-bb/bb/issues/5430 (the secure-intake destination guard used by the originating environment must exist before the guarded request path can be verified). ## Related work #943 concerns verification material missing from isolated worktrees. #1060 concerns changing or weakening acceptance requirements. This slice concerns early discovery and safe intake of user-owned prerequisites, without changing either ticket's requirements. **Readiness:** ready-for-agent. > AI-drafted feedback based on an observed run; publication approved by the user.