# Build Handoff Candidate

This reference expands the five-section Post packet from `plan-review-integrity.md`. It is authoring
guidance, not a second admission checklist.

## Objective / Evidence

Record the Authorizing User's objective, authority state, relevant repository facts, motivating issue or
evidence, and recommendation. Keep verified facts distinct from inference. Never fabricate user
feedback, telemetry, peer review, or experience evidence.

## Outcomes / Proof

State observable acceptance outcomes and map each to proof. Cover meaningful user and developer
surfaces, including explicit no-change claims when they matter. Outcomes describe behavior and
contracts; they do not prescribe exact files, commands, or commit partitions.

## Scope / Boundaries

Name included work and material non-goals. Record public API/schema/protocol, security, privacy,
data, migration, release, runtime-dependency, repository, platform, and temporary-link boundaries
when applicable. Avoid exhaustive file lists that would make harmless implementation adaptation
look like drift.

## Risks / Rules

Record the risk tier and rationale, applicable repository rules, material assumptions, fail-fast
stance, known risks, and any explicitly approved fallback. Identify user-owned release, migration,
deployment, registry, or link-finalization work.

## Execution / QA

Give enough implementation direction to establish feasibility. Record current prerequisites and QA
intent, while allowing Build to select exact tactics and one authoritative final QA manifest from
the completed diff. State whether external credentials, services, tools, or baseline failures are
currently relevant.

## Optional Supplemental Evidence

If the Authorizing User requested peer review, include the findings that affect the objective. Reviewer
identity, capability proof, receipt schema, digest, availability, lifecycle, and verdict are not
required candidate fields. Review absence needs no explanation.

The handoff adds the Authorizing User authority source, risk tier, and `pbs-admit` digest when available.
Managed Workspace PBS v1 may internally map this content to thirteen provider identities; portable
plans never repeat them as human-visible labels or statuses.