---
name: post-build-ship/post
description: Investigate and produce Authorizing User-approvable outcome packets for Build.
---

# Post

Use `post` to turn a request into a launchable outcome envelope. Post investigates the repository,
resolves product decisions, classifies risk, and defines proof. It does not freeze exact files,
commands, implementation tactics, commit partitions, or future process state.

Authorizing User approval is the only authority to enter Build. Never infer approval from a digest,
agent verdict, reviewer receipt, issue label, or plan formatting. Do not routinely ask whether peer
review is wanted. Launch review only when the Authorizing User explicitly requests it, and record its
substantive findings as supplemental evidence rather than authority.

## Intake And Investigation

Before substantial work, inspect repository instructions, the worktree, relevant implementation,
tests, package scripts, and workspace QA launchers. Separate verified facts from recommendations.
Resolve any product decision that would change observable acceptance, scope, public contracts, or
risk. Classify the packet under `references/risk-tiers.md`.

If an external prerequisite is currently required, verify it. Do not defer a known missing
credential, tool, service, dependency state, required command capability, or failed required QA to
Build.

For temporary links, load `temporary-pnpm-package-links`; publication, replacement installation and
validation, unlinking, staging, and the replacement commit are user-owned `manual release
finalization`. Exclude those manual actions from agent steps, acceptance outcomes, and commit
partitions. For React Native Web-to-DOM ownership, read
`post-build-ship/references/react-native-web-to-dom.md`.

## Lean Post Packet

Use five compact sections. Natural equivalent headings are acceptable; repair presentation in Post
instead of rejecting substantive planning later.

1. **Objective / Evidence** — the user goal, Authorizing User authority state, repository facts, and
   evidence motivating the recommendation.
2. **Outcomes / Proof** — observable acceptance outcomes and how each will be proven.
3. **Scope / Boundaries** — included work, material non-goals, public-contract and release boundaries,
   and affected surfaces.
4. **Risks / Rules** — risk tier and rationale, repository rules, material assumptions, safety/data/
   migration/release constraints, and approved fallbacks.
5. **Execution / QA** — an implementation direction, current prerequisites, and proportionate QA
   intent. Exact files, commands, tests, and commit boundaries remain adaptable in Build.

The packet must be substantive, internally consistent, and free of unresolved product decisions.
It does not need roadmap wording, thirteen visible Business Brief labels, future reviewer process
metadata, exact commit counts, or explanations for unused optional gates.

## Admission

When available, run the source-compatible executable against the exact packet:

```sh
pbs-admit --mode portable --tier <1|2|3> --file <packet>
```

For stdin, omit `--file`. Managed Workspace workflows use `--mode managed` and the provider mapping
in `references/workspace-pbs-enforcement.md`. The digest is transport identity only.

Hard-block only a safety-, authority-, or implementation-relevant deficiency:

- missing Authorizing User authority
- unresolved product decisions
- absent acceptance outcomes or material boundaries
- contradictory scope or risk
- unmet current external prerequisites
- unavailable command execution that is required now
- failed required QA

Missing roadmap prose, compact presentation differences, future-stage process information, and
unused optional gates are repaired, defaulted, or warned about in Post. They do not become Build
blockers. If `pbs-admit` is unavailable in an older package, apply these direct checks and proceed;
do not block on executable absence.

## Approval And Handoff

Before approval, label the packet as a proposal. Once the Authorizing User explicitly approves the
final packet, record that authority with the approved objective and hand the same substantive packet
to Build. A copy/paste launch remains authorized only when it includes an honest Authorizing User
authority record; Post never fabricates one.

The handoff includes the packet, risk tier, input digest when available, current prerequisite state,
known optional-review findings, and the Authorizing User authority source. No peer-review metadata or
receipt is required.

If same-window execution was requested and approval is present, load `build` immediately. Otherwise
return the self-contained packet for approval or later launch.