@open-agent-toolkit/cli 0.3.13 → 0.3.15

package/assets/docs/workflows/projects/autonomy.md

@@ -1,196 +0,0 @@
----
-title: Autonomous Project Execution
-description: 'Session-scoped autonomy signals, gate boundaries, review requirements, and execution-learnings behavior for OAT projects.'
----
-
-# Autonomous Project Execution
-
-OAT autonomy is an explicit session policy for driving a project through its
-lifecycle without waiting at ordinary interactive gates. It does not bypass the
-gate-owning skills: each skill still applies its own checks, records provenance,
-and either resolves the gate or reports a boundary.
-
-The provider-agnostic entry point is `oat-project-autonomous`. Invoke it
-deliberately with a goal, project slug, ticket reference, or active project. A
-restart does not silently resume autonomy; invoke the skill again and it resumes
-from the persisted project state.
-
-## Activation contract
-
-An autonomous session uses both signals:
-
-```bash
-export OAT_AUTONOMOUS=1
-export OAT_NON_INTERACTIVE=1
-```
-
-`OAT_AUTONOMOUS=1` implies and sets `OAT_NON_INTERACTIVE=1` for the current
-run. The distinction is intentional:
-
-- `OAT_NON_INTERACTIVE=1` selects existing safe no-prompt paths for one
-  workflow.
-- `OAT_AUTONOMOUS=1` additionally enables lifecycle chaining, defined gate
-  resolutions, boundary stops, and provenance requirements.
-
-Both signals are session-scoped. Never write them to `state.md`, `plan.md`,
-repository config, user config, or any other durable artifact. A later
-interactive session therefore needs no autonomy cleanup and behaves
-interactively around the state the autonomous run left behind.
-
-## Gate outcomes
-
-Every interactive lifecycle gate has one of two autonomous outcomes:
-
-1. **Auto-resolve** using an existing safe path, then record the decision and
-   evidence.
-2. **Boundary stop** with a structured blocker and a resumable next step.
-
-The main boundary classes are:
-
-- **Product judgment** — repository evidence cannot resolve material scope or
-  requirements ambiguity.
-- **Destructive-change risk** — an action could discard work, delete data,
-  rewrite history, or broadly restructure an unapproved surface.
-- **Unresolved Critical findings** — a blocking review has not passed.
-- **Repository-policy approval** — protected operations require authority the
-  session does not have.
-- **Missing credentials** — a required external action has no authenticated
-  route or offline equivalent.
-
-A boundary is a successful fail-closed outcome, not permission to continue with
-a guessed answer. The run reports what stopped, the evidence, and the operator
-action needed to resume.
-
-The canonical autonomy contract and exhaustive gate inventory
-(`.agents/docs/autonomy-contract.md`, vendored into each consuming skill at
-`references/docs/autonomy-contract.md`) map each prompt to its autonomous
-resolution and provenance.
-
-### Dispatch-ladder scope selection
-
-An incomplete reusable dispatch ladder is auto-resolvable when an authorized
-adoption-compatible config scope is available. Autonomous planning checks
-config-file existence in this fixed order without prompting or reordering from
-effective value or matrix-cell provenance:
-
-1. user config (`~/.oat/config.json`);
-2. repo-local config (`.oat/config.local.json`);
-3. shared config (`.oat/config.json`), only when repository policy already
-   authorizes that write.
-
-Before writing, planning rejects a candidate that would preserve a
-provider-level scalar in that scope or remain shadowed by one at higher
-precedence. It always tries the next authorized compatible candidate and stops
-without mutation only when none remains.
-
-The planner runs exactly one matching `oat config adopt dispatch-matrix --keep-existing`
-command, records file-existence and compatibility evidence plus the selected
-scope, and re-runs dispatch preflight. Existing explicit cells remain unchanged;
-their provenance does not select the persistence scope. No authorized
-compatible scope, or a ladder that remains incomplete after adoption, is still
-a repository-policy boundary. `OAT_NON_INTERACTIVE=1` without
-`OAT_AUTONOMOUS=1` does not select a scope and continues to fail closed.
-
-## Review contract
-
-Autonomous execution preserves independent review:
-
-- Discovery, design, and plan artifacts run their configured exit gates.
-  Quick-start reviews the discovery, optional lightweight design, and plan as
-  one bundle when those artifacts exist.
-- Review routing is selected before launch through the dispatch substrate.
-  A configured gate target is preferred when available; otherwise policy may
-  choose a target-preserving subagent route. Any reduced independence is
-  explicit in the dispatch record.
-- Once a launch is accepted, it is terminal for route selection. Failures use
-  bounded recovery with the same payload; they do not silently fall through to
-  a cheaper or less independent reviewer.
-- Eligible review artifacts are received immediately. Fix tasks use the normal
-  bounded implement-and-re-review loop.
-- Critical findings and failed blocking reviews stop progression. High
-  findings follow the configured gate policy.
-- A normal phase or final lifecycle review cannot satisfy a configured
-  implementation exit gate. Only gate invocation provenance with the matching
-  run ID can authorize that boundary.
-
-Project review artifacts and review rows reference launcher-owned dispatch
-records. The configured invocation is authoritative evidence; child
-self-reporting is optional corroboration. See [Evidence
-Layers](evidence-layers.md) and [Reviews](reviews.md).
-
-## HiLL and lifecycle closeout
-
-If checkpoint selection is unconfirmed when autonomy starts implementation,
-OAT takes the existing `workflow.hillCheckpointDefault: final` path explicitly:
-
-```yaml
-oat_plan_hill_phases: ['<final-phase-id>']
-oat_auto_review_at_hill_checkpoints: true
-```
-
-An existing valid explicit list is preserved. An existing `[]` is also
-preserved and means every phase, never no phases. At each configured checkpoint,
-autonomy runs and receives the review without waiting.
-
-At final closeout, autonomy follows the same authoritative order as an
-interactive run: final verification, mandatory final lifecycle review,
-configured implementation exit gate, pre-approval sequence, final HiLL
-approval, post-approval sequence, then implementation completion and success
-output. A `not_configured` resolution persists an explicit no-gate allowance
-before the sequence starts; a null, missing, or unrecognized resolver result
-fails closed as unresolved. A gate this project disabled persists an
-`allowed/configured` result with `disposition: project_disabled` and never
-launches the configured command.
-
-Autonomy does not turn an ordinary independent review into configured-gate
-provenance. A configured review must produce a gate-originated artifact with
-the matching run ID, and eligible receive must be durably reconciled. Blocked,
-ambiguous, malformed, or stale gate state is a boundary stop: the run remains
-resumable through `oat-project-implement` and cannot continue to approval,
-completion, or output.
-
-The default autonomous tail is summary, documentation, and final PR when no
-post-implementation sequence is configured; stored legacy or structured
-sequences retain their documented meaning.
-
-## Execution-learnings loop
-
-Autonomous runs keep an append-only project-local
-`oat-execution-learnings.md`. Dated entries record an observation, impact, and
-recommendation under the source taxonomy: `gotcha`, `efficiency`,
-`documentation-gap`, `candidate-skill-content`, `decision`, or
-`environment-limited`.
-
-When the file exists, `oat-project-summary` synthesizes actionable
-recommendations into `## Autonomous Execution Learnings`, grouped as:
-
-- agent-instruction updates;
-- cloud-environment improvements;
-- code follow-ups;
-- workflow issues.
-
-Each recommendation links back to its source entry. Projects without the
-learnings file render normal summaries with no autonomous-learnings section.
-The summary export keeps the synthesized recommendations after project
-archival.
-
-## Taking over interactively
-
-After an autonomous session ends:
-
-1. Start a normal session without the autonomy environment signals.
-2. Open the same project from its repository-local `.oat` directory.
-3. Resume the owning lifecycle skill.
-
-Persisted review rows, task state, explicit HiLL checkpoints, and dispatch
-provenance remain valid. Interactive prompts and checkpoint pauses return
-normally because autonomy itself was never persisted.
-
-## Related
-
-- [HiLL Checkpoints](hill-checkpoints.md) — checkpoint field semantics and
-  interactive behavior.
-- [Implementation Execution](implementation-execution.md) — phase execution,
-  review, fixes, and closeout.
-- [Cursor Cloud](cursor-cloud.md) — project-home and environment-readiness
-  guidance for cloud runs.

package/assets/docs/workflows/projects/hill-checkpoints.md

@@ -1,93 +0,0 @@
----
-title: Human-in-the-Loop Lifecycle (HiLL) Checkpoints
-description: 'Checkpoint configuration and behavior for pauseable, human-in-the-loop lifecycle execution.'
----
-
-# Human-in-the-Loop Lifecycle (HiLL) Checkpoints
-
-OAT supports two checkpoint classes:
-
-- Workflow phase checkpoints
-- Plan phase checkpoints
-
-The [Phase gate review](reviews.md#phase-review-gate) (`oat_phase_review_gate`) is a separate, non-pausing mechanism — it does not pause on a passing gate and never modifies the HiLL keys below (`oat_hill_completed`, `oat_plan_hill_phases`).
-
-## Workflow checkpoints (`state.md`)
-
-Frontmatter keys:
-
-- `oat_hill_checkpoints`
-- `oat_hill_completed`
-
-Example:
-
-```yaml
-oat_hill_checkpoints: ['discovery', 'spec', 'design']
-oat_hill_completed: ['discovery']
-```
-
-## Plan phase checkpoints (`plan.md`)
-
-Frontmatter key written after implementation confirmation:
-
-- `oat_plan_hill_phases`
-
-Semantics:
-
-- Field absent: valid before the first `oat-project-implement` run confirms checkpoint selection. Planning may intentionally leave the field unset until that first execution starts.
-- Empty list: checkpoint after every phase boundary, but only after implementation has confirmed the choice and written `oat_plan_hill_phases: []` into `plan.md`.
-- Explicit list: checkpoint only after completing the named phases (`p01`, `p04`, etc).
-
-### Lite checkpoint bypass
-
-Lite projects have no HiLL checkpoints. `oat-project-implement` resolves
-`oat_workflow_mode` from project state before any checkpoint field read, and
-when the mode is `lite` it resolves checkpoint state as `none` without reading
-or interpreting `oat_plan_hill_phases`. An empty list cannot represent lite's
-policy, because for every other mode an empty list means "checkpoint after every
-phase". `oat-project-implement`'s Lite checkpoint bypass writes:
-
-```yaml
-oat_auto_review_at_hill_checkpoints: false # lite: no checkpoints
-```
-
-The workflow preference prompt, the standard checkpoint prompt, and the
-auto-review preference prompt are all skipped in both interactive and autonomous
-runs. Only HiLL approval pauses are absent — the root-owned per-phase review and
-the final review remain required.
-
-The rest of this section applies to `spec-driven`, `quick`, and `import`
-projects.
-
-On the first implementation run, `oat-project-implement` must summarize every plan phase, state the total phase count and final phase ID, and then ask an explicit three-option checkpoint question:
-
-- Stop after each phase
-- Stop after specific phases
-- Stop only after the final phase is completed
-
-It then writes the confirmed value into `plan.md`. If the field is later missing during a resumed implementation run, treat that as bookkeeping drift rather than as an implicit default.
-
-Listed phases are where you stop **after completing them**, not before. `["p03"]` means "complete p03, then pause" — not "pause before starting p03." Setting the last phase ID (e.g., `["p03"]` when p03 is final) means "stop only at the end of implementation."
-
-### Setting a default via `workflow.hillCheckpointDefault`
-
-The first-run checkpoint prompt can be skipped entirely by setting the `workflow.hillCheckpointDefault` preference:
-
-- `every` — automatically write `oat_plan_hill_phases: []` (pause after every phase) without prompting
-- `final` — automatically write `oat_plan_hill_phases: ["<final-phase-id>"]` (pause only at the end) without prompting
-
-When set, `oat-project-implement` reads the preference before the prompt and prints `HiLL checkpoints: <every|final> (from workflow.hillCheckpointDefault)`, skipping the interactive choice. When unset (default), the skill prompts as before.
-
-This is a personal preference — typically set at user scope so it applies to every repo:
-
-```bash
-oat config set workflow.hillCheckpointDefault final --user
-```
-
-See [Workflow preferences in the Configuration guide](../../cli-utilities/configuration.md#workflow-preferences-workflow) for the full list of preference keys and surface guidance.
-
-## Reference artifacts
-
-- `.oat/templates/plan.md`
-- `.oat/projects/<scope>/<project>/plan.md`
-- `.oat/projects/<scope>/<project>/state.md`

package/assets/docs/workflows/projects/picking-up-projects.md

@@ -1,124 +0,0 @@
----
-title: Picking Up Projects
-description: Continue a synced OAT project on another machine or from another user through its dedicated Git ref.
----
-
-# Picking Up a Project on Another Machine or From Another User
-
-Synced projects travel through ordinary Git refs on `origin`. Their artifact
-history is independent from the implementation branch, so a teammate or a
-second machine can continue the project even before the branch carrying its
-record file merges.
-
-## Discover and adopt
-
-From any checkout with access to `origin`:
-
-```bash
-oat project list --remote
-oat project pull <project>
-```
-
-`list --remote` discovers `refs/oat/projects/*` directly. `pull` can adopt a
-remote project that has no local record yet: it writes the record and creates
-the nested checkout. When the selected project is a coordination parent, pull
-also discovers and pulls its child projects by default. Pass `--no-children`
-only when you intentionally want the selected project alone.
-
-Completed projects are not adoption candidates. Their authoritative ref is
-`refs/oat/completed/<project>`; both `pull` and `open` return a terminal
-diagnosis instead of recreating an archived checkout or record. A same-SHA
-active ref may remain as an inert alias and is ignored. Differing active and
-completed SHAs require repair before lifecycle work continues. The same guard
-applies to coordination children: a terminal child discovered while pulling
-its parent is reported and skipped rather than adopted.
-
-After adoption, set or open the project through the normal lifecycle command
-you are using. Arrival-aware project skills pull before reading its artifacts.
-
-An adopted quick-workflow project whose `plan.md` is not implementation-ready
-resumes through `oat-project-quick-start`, which continues it in place without
-re-scaffolding, rather than through `oat-project-implement`. `oat-project-plan`,
-`oat-project-progress`, and `oat-project-next` all route by the single **quick
-plan readiness** predicate that `oat-project-quick-start` defines; readiness is
-never inferred from the presence of tasks alone.
-
-`oat project status` and `oat project list` apply the same predicate. For a
-quick project at the `plan` phase they recommend `oat-project-quick-start`, with
-the unmet clause in the reason, until the plan carries ready frontmatter, a
-durable `## Reviews` disposition, and a substantive task; only then do they
-recommend `oat-project-implement`. Recommendations for lite, spec-driven, and
-import projects are unchanged, because the predicate is quick-workflow policy.
-
-## What travels
-
-- The project ref carries the complete active artifact tree and its history.
-- The tracked JSON record travels once the branch containing it is shared or
-  merged.
-- Coordination relationships travel in the artifacts and records pulled with
-  the project.
-
-## What does not travel automatically
-
-- `local` projects never leave their original machine.
-- GitHub forks copy branches and tags, but not the `refs/oat/*` namespace. A
-  fork collaborator needs access to the upstream remote or an explicit ref
-  transfer.
-- A normal `git clone` fetches branches and tags, not custom OAT refs. OAT
-  handles remote discovery with `ls-remote` and explicitly fetches the selected
-  project ref during sync operations such as `pull`; do not expect a generic
-  clone or `git fetch` to materialize the checkout.
-
-## Why completed refs remain durable
-
-`refs/oat/completed/<project>` is a real Git ref locally and on `origin`. The
-objects reachable from it remain garbage-collection roots even when no nested
-checkout exists. Branch pruning, remote-tracking-ref pruning, and
-`git worktree prune` do not delete the completed ref. Completion deliberately
-retains this terminal reachability root so pinned PR links remain valid.
-
-Only the explicit destructive operation `oat project prune` removes the
-completed ref and any matching active alias. Treat that as permanent Git
-project-history reachability deletion and review its warnings before using
-`--force`. Prune does not remove durable local or S3 archive snapshots, and it
-refuses to delete either ref when their SHAs differ.
-
-## Archive contents
-
-When archive is selected, completion copies a synced project into
-`.oat/projects/archived/<project>/` without the nested checkout's `.git`
-pointer or `reviews/`. S3 snapshots also omit `pr/`, following the existing
-archive policy. When archive is disabled or declined, the active synced
-checkout remains in place. Successful archived closeout instead uploads the S3
-snapshot first when configured, makes the completed ref authoritative, removes
-the checkout, and deletes the tracked JSON record. The local archive metadata
-retains the source-ref identity needed for recordless retries and later S3
-restore without recreating active state.
-
-If closeout is interrupted after terminal archive identity exists, rerun
-completion so it can resume from the completed ref and archive metadata. Do not
-use `pull` or `open` to recreate an active record or checkout.
-
-For a `shared` project, archive moves the project into
-`.oat/projects/archived/<project>/` and removes the source directory, while
-completion keeps the `activeProject` pointer until the receipt validates.
-Rerunning completion after an interruption between the archive and that clear
-recognizes exactly this state — the pointer names a source directory that no
-longer exists and the archive carries `oat_lifecycle: complete` plus the
-`Lifecycle complete; archived locally` phase marker — so it validates the
-discovered archive and clears the pointer without archiving a second time or
-sealing the project log again. An interruption before the archive leaves the
-source directory in place, so completion simply reruns from the start and skips
-the work it already finished.
-
-If the archive cannot be discovered — the source directory is gone and either
-no archived project or several match the name — completion stops and leaves the
-pointer untouched. Recover manually: locate the archive directory under
-`.oat/projects/archived/`, confirm `oat_lifecycle: complete` in its `state.md`,
-then clear the pointer with `oat config set activeProject ""`.
-
-## Related
-
-- [Reviewing OAT PRs](reviewing-oat-prs.md)
-- [Project Artifacts](artifacts.md)
-- [Implementation Execution](implementation-execution.md#synced-projects-in-worktrees)

package/assets/docs/workflows/projects/review-flavors.md

@@ -1,138 +0,0 @@
----
-title: Review Flavors
-description: 'The four OAT project review flavors, when each fires in the lifecycle, and who resolves its reviewer target.'
----
-
-# Review Flavors
-
-OAT projects run reviews at several different lifecycle points, and those points
-have different independence requirements. A self-review that checks a freshly
-written plan does not need the same producer isolation as a lifecycle gate that
-signs off on the final artifact. Rather than force one reviewer-selection rule
-onto every point, OAT recognizes **four review flavors**, each with its own
-target-resolution policy layered on the shared reviewer role class.
-
-The distinguishing question is always _"who resolves this review's target, and
-how independent must that target be from whatever produced the work?"_ The four
-flavors answer it differently while preserving one invariant: the reviewer runs
-**at or above the ceiling** (see [Dispatch Policy](dispatch-ceiling.md)). Gate
-independence is project policy layered on the generic reviewer role class
-described in the `oat-project-dispatch-subagents` lifecycle-role table; this page
-covers _which_ flavor fires _when_ and _who_ resolves its target, and links out
-for the deep review request/receive mechanics.
-
-## Quick Look
-
-- What it does: names the four review flavors and states who resolves each
-  one's reviewer target.
-- When to use it: when you need to know which review fires at a lifecycle point
-  and whether it inherits, pins the ceiling, or requires an independent gate.
-- Primary sources: `oat-project-implement` phase-execution mechanics, the
-  `oat-project-dispatch-subagents` lifecycle-role table, and project design
-  Decision #11.
-
-## Flow map
-
-```mermaid
-flowchart TD
-  subgraph Planning
-    PL["Planning-phase\nartifact self-review"] --> PLR["Inherit planning parent"]
-    PLR --> PLT["Parent model\n(root already at/above ceiling)"]
-  end
-
-  subgraph Implementation
-    IM["Root-owned phase\nself-review"] --> IMR["Resolve dispatch ceiling"]
-    IMR --> IMPIN["At-ceiling pin\n(ceiling final candidate)"]
-    IMR --> IMINH["Inherit\n(only if dispatcher known at/above ceiling)"]
-    IMR --> IMCLI["Exact CLI reviewer\n(selected pre-launch)"]
-  end
-
-  subgraph Gates
-    PG["Phase review gate\n(external)"] --> PGR["Configured cross-family\nexec target (gates.execTargets)"]
-    PGR --> PGT["Independent CLI/exec target\n(host-avoidance; fail closed)"]
-
-    LG["Lifecycle / final gate"] --> LGR["Cross-runtime CLI\nexec target"]
-    LGR --> LGT["Producer-independent target\n(fail closed, no self-review substitute)"]
-    LGT -. may spawn .-> LGN["Nested managed\nreviewer child inside gate"]
-  end
-```
-
-The dotted branch marks the only flavor that may **spawn a nested managed
-reviewer child** inside the gate exec target: the lifecycle/final gate.
-
-## The four flavors
-
-| Flavor                              | Lifecycle point                                                    | Target resolution                                                                                                                                                                                              |
-| ----------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Planning-phase artifact self-review | Auto artifact-review loop for plan/spec/design                     | Inherit the planning parent by default (root is already at/above ceiling)                                                                                                                                      |
-| Implementation-phase self-review    | Phase and final code reviews dispatched by `oat-project-implement` | Resolve the dispatch ceiling; pin the ceiling's final candidate (at-ceiling pin); inherit only when the review-owning dispatcher is known to be at/above ceiling; else select an exact CLI reviewer pre-launch |
-| Phase review gate (external)        | Optional non-pausing gate after a phase passes its self-review     | Independent configured cross-family CLI/exec target (`gates.execTargets`), host-avoidance, unconstrained by native catalog; fail closed if unavailable                                                         |
-| Lifecycle / final gate              | End-of-lifecycle sign-off                                          | Cross-runtime CLI exec target, independent of producer context; fails closed rather than substituting same-context self-review; may spawn a nested managed reviewer child inside the gate exec target          |
-
-The first two flavors are **self-reviews**. Planning review inherits its
-producing parent by default; implementation phase review is dispatched by the
-project root after the phase producer returns. The last two are **gates** — an
-external, configured, producer-independent target. Phase implementation may run
-_below_ the review ceiling for cost reasons, but review must never silently
-inherit the below-ceiling phase agent.
-
-Pre-plan inheritance has a narrow executable guard. When dispatch resolution
-reports `unresolvedReason: policy`, an artifact review of `discovery`, `design`,
-or `spec` deliberately inherits the current planning context and records
-`selection_reason: inherit (pre-plan; no project policy)`. An explicit project
-policy is still honored at those scopes. Missing or incomplete ladders
-(`unresolvedReason: ladder | both`) fail closed, as do plan-scope artifact
-reviews and every code review without a resolved policy. Gate exec-target
-selection is separate and unaffected.
-
-## Independence and fail-closed semantics
-
-The invariant across all four flavors is that the reviewer runs **at or above
-the ceiling**. What changes between flavors is the required _independence from
-the producer_, and that independence is enforced by failing closed rather than
-silently downgrading:
-
-- **Planning self-review** needs the least independence. The planning root
-  already runs at or above the review ceiling, so inheriting the parent model
-  satisfies the invariant without managed re-pinning. Pinning is _possible_
-  once the ceiling is resolved during planning, but it is not the default.
-- **Implementation self-review** needs ceiling-level capability but not
-  cross-family isolation. The root resolves the dispatch ceiling and pins the
-  tier's final candidate after the phase report. Inheritance is allowed only
-  when the root dispatcher is _known_ to be at or above the ceiling; otherwise
-  an exact provider CLI reviewer is selected before launch. Reviewer selection
-  is never delegated to the phase implementer.
-- **Phase review gate** adds cross-family independence. It uses a configured
-  independent exec target from `gates.execTargets` with host-avoidance,
-  unconstrained by the harness's native subagent catalog. If the required
-  independent target cannot be enforced, the gate **fails closed** — it does
-  not downgrade to producer-context review.
-- **Lifecycle / final gate** requires the strongest independence: a
-  cross-runtime CLI exec target chosen independently of the producer context.
-  It fails closed rather than substituting a same-context self-review, and it is
-  the one flavor permitted to spawn a nested managed reviewer child _inside_ the
-  gate exec target when the gate's own contract calls for it.
-
-Gate independence is not a property of the generic reviewer class; it is project
-policy layered on top of it. The dispatch adapter resolves the configured gate
-target before launch and passes it as exact selection input. Fail-closed
-behavior for both gate flavors is deliberate: an unavailable independent target
-blocks the gate instead of quietly reusing whatever produced the work. For the
-gate configuration keys and non-pausing behavior, see
-[Workflow gates](../../cli-utilities/workflow-gates.md) and the
-[phase review gate](reviews.md#phase-review-gate) section of the review doc.
-
-## Related
-
-- [Reviews](reviews.md) — the review request/receive flows and the deep review
-  contract these flavors plug into.
-- [Dispatch Policy](dispatch-ceiling.md) — named ceilings, at-ceiling reviewer
-  selection, and the Dispatch Report V1 / producer-provenance record.
-- [HiLL Checkpoints](hill-checkpoints.md) — how the non-pausing phase review gate
-  relates to pauseable lifecycle checkpoints.
-- [Orchestration Model](orchestration-model.md) — the native-first dispatch
-  topology these reviewer roles run inside.
-- [Workflow gates](../../cli-utilities/workflow-gates.md) — gate configuration
-  and exec-target selection.
-- [Smoke testing](../../contributing/smoke-testing.md) — how the fixture makes
-  these flavors observable and assertable.