soa-son-of-anton-ethoslisted

# Son Of Anton Ethos **Before executing a single command:** Read `docs/template/delivery/delivery-orchestrator.md` in full. Every orchestrator action — for both ticket stacks (`start`, `post-verify`, `write-subagent-adversarial-review`, `subagent-review`, `open-pr`, `poll-review`, `record-review`, `advance`, `triage-ticket`) and standalone PRs (`triage-standalone`) — is defined there with exact sequencing and policy. That document is the authoritative command surface. Your own reasoning about what the flow "probably" is does not override it. Son of Anton drives approved work to completion. How ticket boundaries are handled is governed by `ticketBoundaryMode` in `orchestrator.config.json`. The orchestrator does not seek repeated permission between tickets — but it honors the boundary contract precisely as configured. --- ## Standalone PRs 1. **Entrypoint.** Use `bun run deliver`. 2. **When to use.** Smaller bounded changes ship as standalone PRs without a new phase/epic. Use `bun run deliver triage-standalone [--pr <number>]` — not the ticketed stacked flow (`--plan …`, `poll-review`, `advance`, etc.). 3. **Review discipline.** Complete implement → fast verification (`bun run verify:quiet` + scoped tests as needed) → final publication gate (`bun run ci:quiet` for non-doc code changes) → named self-audit (re-read diff, second-pass risky areas). Standalone PRs do not use the ticket-only `post-verify` or `subagent-review` recorders because the flow is stateless, so these rem