@open-agent-toolkit/cli 0.2.28 → 0.2.30

package/assets/bundle-metadata.json

@@ -0,0 +1,4 @@
+{
+  "schemaVersion": 1,
+  "oatVersion": "0.2.30"
+}

package/assets/docs/cli-utilities/configuration.md

@@ -568,7 +568,11 @@ Workflow preference keys live under the `workflow.*` namespace:
 - `workflow.hillCheckpointDefault` — `every` or `final`. Default HiLL checkpoint behavior in `oat-project-implement`: pause after every phase or only after the last phase. When unset, the skill prompts.
 - `workflow.archiveOnComplete` — boolean. Skip the "Archive after completion?" prompt in `oat-project-complete`. When unset, the skill prompts.
 - `workflow.createPrOnComplete` — boolean. Skip the "Open a PR?" prompt in `oat-project-complete`; when true, completion auto-triggers PR creation. When unset, the skill prompts.
-- `workflow.postImplementSequence` — legacy `wait`, `summary`, `pr`, or `docs-pr`, or `{ "preApproval": [...], "postApproval": [...] }`. Legacy values remain strings; structured arrays contain ordered, globally unique `summary`, `document`, and `pr` steps. Pre-approval steps run after final review and before final HiLL approval; post-approval steps run only after that approval. Plain retrieval keeps legacy strings and prints structured values as compact JSON; `--json` returns the raw value.
+- `workflow.postImplementSequence` — legacy `wait`, `summary`, `pr`, or `docs-pr`, or `{ "preApproval": [...], "postApproval": [...] }`. Legacy values remain strings and keep their existing mappings. Structured arrays contain ordered, globally unique `summary`, `document`, `pr`, and `retro` steps. `retro` is post-approval only: a structured value containing it in `preApproval` is rejected. Pre-approval steps run after final review and before final HiLL approval; post-approval steps run only after that approval. Plain retrieval keeps legacy strings and prints structured values as compact JSON; `--json` returns the raw value.
+- `workflow.retro.filing.repo` — `issues`, `backlog`, or `none`; unset by default. Selects the repo-lane filing destination.
+- `workflow.retro.filing.upstream` — `issues` or `none`; unset by default. Selects the upstream-lane filing destination.
+- `workflow.retro.apply` — `auto` or `ask`; defaults to `ask` behavior when unset. `auto` authorizes bounded promotion application in non-interactive runs; `ask` is propose-only when no interaction is possible.
+- `workflow.retro.upstreamRepo` — `owner/repo`; unset in CLI configuration. Retro guidance defaults it to `voxmedia/open-agent-toolkit`.
 - `workflow.reviewExecutionModel` — `subagent`, `inline`, or `fresh-session`. Default final-review execution model in `oat-project-implement`. `subagent` and `inline` run automatically. `fresh-session` is a soft preference: the skill prints guidance to run the review in another session but still offers escape hatches to `subagent` or `inline` if you change your mind. When unset, the skill prompts.
 - `workflow.autoReviewAtHillCheckpoints` — boolean. Automatically run the extra lifecycle review when a HiLL checkpoint is reached. This does not control Tier 1 per-phase `oat-reviewer` gates, which run after each phase in Tier 1 regardless of this setting. When unset, the skill prompts.
 - `workflow.autoNarrowReReviewScope` — boolean, default `true`. Re-reviews automatically use the guarded range after the prior matching review's recorded head. Unset and `true` enable narrowing without a prompt; set `false` to opt out and use the nominal full scope.
@@ -585,6 +589,12 @@ Workflow preference keys live under the `workflow.*` namespace:
 - `workflow.gates.skills` / `workflow.gates.execTargets` — structured per-skill final gate commands and exec-target registry. Use `oat gate set`, `oat gate target set`, `oat gate review`, and `oat gate cross-provider-exec`; do not use `oat config set` for these objects.
 - `workflow.gateTimeouts.code` / `workflow.gateTimeouts.artifact` — validated default gate-review budgets in milliseconds. Both resolve through `local > shared > user`.
 
+Explicit `workflow.retro.apply: auto` or `workflow.retro.filing.*`
+configuration counts as consent for the corresponding non-interactive action.
+Without those settings, non-interactive retro generation records proposals but
+does not apply or file them. Interactive runs still present the applicable
+promotion and filing choices before side effects.
+
 The two project-log keys use the standard workflow precedence:
 `local > shared > user > default`.
 

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

@@ -30,6 +30,11 @@ Mode-sensitive notes:
 - `pr/*.md`: generated PR descriptions
 - `references/imported-plan.md`: preserved source plan for import mode
 - `references/split-plan.json`: persisted split plan for a coordination parent, used as the durable resume source when `oat-project-split` is interrupted
+- `references/project-retro.md`: optional post-approval retrospective with
+  machine-scannable repo-improvement (`RP-NN`) and upstream-feedback (`UP-NN`)
+  registers. Promotion and filing rollups let the retro skills resume approved
+  applications and tracker filing without repeating settled work. See
+  [Project Retrospectives](retro.md).
 
 ### Explainer artifacts
 

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

@@ -66,6 +66,31 @@ The canonical autonomy contract and exhaustive gate inventory
 `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`
+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:

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

@@ -12,6 +12,7 @@ Projects are where the workflow layer becomes concrete: lifecycle phases, `state
 ## Contents
 
 - [Lifecycle](lifecycle.md) - End-to-end flow from discovery through completion.
+- [Project Retrospectives](retro.md) - Generate evidence-grounded retros, apply repo improvements, and file tracker feedback.
 - [Autonomous Project Execution](autonomy.md) - Session-scoped autonomy signals, gate boundaries, review requirements, and execution learnings.
 - [OAT in Cursor Cloud](cursor-cloud.md) - Project-home, provisioning, asset-precedence, and execution-surface guidance for cloud agents.
 - [Design Modes](design-modes.md) - How full design balances collaborative, selective collaborative, and draft-and-review interaction.

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

@@ -110,12 +110,35 @@ approval, and only then runs post-approval steps. The snapshot is restart-safe:
 an incomplete sequence routes back to implementation and resumes from its first
 incomplete step.
 
+Structured sequences accept `summary`, `document`, `pr`, and `retro`.
+`retro` is post-approval only: placing it in `preApproval` invalidates the
+structured value. This placement lets the retrospective include the final
+approval and feedback tail while still running before project completion
+freezes lifecycle artifacts. The legacy string mappings are unchanged and do
+not add a retro step.
+
+When a pending post-approval `retro` step runs, OAT dispatches
+`oat-project-retro` in generate mode. Applying repo improvements and filing
+tracker items remain separately consented through interactive confirmation or
+`workflow.retro.*` configuration.
+
 `oat-project-next` checks `oat_implement_exit_gate` before every normal
 post-implementation route. Missing, pending, blocked, malformed, or stale state
 routes back to `oat-project-implement` even when `oat_phase_status` is
 `complete` or `pr_open`. Only an allowed, fresh disposition can continue to
 summary, documentation, PR, or project completion.
 
+### Retrospective completion safety net
+
+Before an interactive completion archives the project,
+`oat-project-complete` checks for
+`{PROJECT_PATH}/references/project-retro.md`. If the artifact is missing, it
+offers to generate one before completion. If the artifact exists, completion
+does not offer another retro; it may note unsettled promotion or filing
+registers. Non-interactive completion skips this offer, so autonomous
+generation occurs only through an explicitly configured post-approval `retro`
+step.
+
 When `workflow.autoReviewAtHillCheckpoints` is enabled or `plan.md` frontmatter sets `oat_auto_review_at_hill_checkpoints`, completing a HiLL checkpoint automatically runs the extra lifecycle review scoped to every implementation phase not already covered by a passed whole-phase code review, through the just-completed checkpoint. Mid-implementation multi-phase reviews use inclusive phase-range scopes such as `p02-p03`; the final implementation checkpoint uses `code final`. The review uses auto-disposition mode (minors auto-converted to fix tasks, no user prompts). Disabled by default. Legacy `autoReviewAtCheckpoints` and `oat_auto_review_at_checkpoints` are still read as fallbacks. This does not control Tier 1 per-phase `oat-reviewer` gates.
 
 ### Phase-review setup during planning

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

@@ -0,0 +1,261 @@
+---
+title: Project Retrospectives
+description: Generate evidence-grounded project retrospectives, apply repo improvements, and file tracker feedback.
+---
+
+# Project Retrospectives
+
+OAT project retrospectives capture how an implementation run went and route
+what should change next. The workflow uses two skills:
+
+- `oat-project-retro` generates
+  `{PROJECT_PATH}/references/project-retro.md` and applies approved repo
+  improvements.
+- `oat-project-retro-file` files tracker-bound feedback into repository or
+  upstream GitHub issues and OAT backlog items.
+
+A configured `retro` post-approval sequence step can generate the artifact
+after final feedback exists and before project completion freezes lifecycle
+artifacts. Interactive completion also offers generation when the artifact is
+missing. Neither path applies or files findings without separate consent.
+
+## Generate a retrospective
+
+Ask to run the project retro, or configure `retro` in
+`workflow.postImplementSequence.postApproval`. Generate mode resolves the active
+project, inventories evidence, renders the retro artifact, and records the run
+in the project log when that log exists.
+
+Evidence is read in this order:
+
+1. `project-log.md`
+2. `oat-execution-learnings.md`, when present
+3. Lifecycle artifacts such as `implementation.md`, `state.md`, `plan.md`,
+   design and discovery artifacts, reviews, and evidence ledgers
+4. The current session or run transcript when the environment makes it
+   available
+
+The artifact identifies every used or unavailable source. Missing transcript
+access is recorded rather than hidden, and runtime claims fall back to durable
+ledgers when transcript output is incomplete. Findings distinguish confirmed
+causes, hypotheses, and inconclusive mechanisms.
+
+Evidence status remains `used | unavailable`. When an evidence family is
+partial, split it into truthful source entries, such as
+`archived-review-markdown: unavailable` and `gate-receipts: used`, rather than
+recording `review-artifacts: unavailable`. Do not add a `partial` evidence
+status. Derivative current-run reconnaissance transcripts are not original
+project-run evidence.
+
+### Scale depth to the evidence
+
+Keep output concise by default. Every section must add distinct information.
+Prefer references to evidence over repeated chronology. For a small project,
+keep core sections brief. Use subsections and tables only for evidence-rich
+projects where they improve decisions. The required core and register
+contracts stay intact; evidence volume controls depth, not a new configuration
+or consent setting.
+
+Each material incident remains understandable without opening another
+artifact. Use stable evidence anchors such as project-log event IDs, artifact
+headings, review paths, decision IDs, and commit IDs. Anchors supplement but
+never replace explanation.
+
+Narrative sections have distinct ownership:
+
+- `Challenges and Struggles` owns the complete incident narrative: what
+  happened, impact, response, and result.
+- `Where We Changed Course` records only the trigger, changed direction, and
+  outcome.
+- `Domain Learnings` abstracts reusable lessons without replaying chronology.
+- `Gotchas for Humans` and `Gotchas for Autonomous Agents` contain
+  future-facing instructions rather than incident summaries.
+
+Every retro contains two machine-scannable registers:
+
+- **Repo Improvements (`RP-NN`)** route each item through
+  `Disposition: apply` for a bounded repo edit or `Disposition: file` for a
+  tracker follow-up.
+- **OAT Upstream Feedback (`UP-NN`)** contains sanitized, tracker-ready
+  suggestions for toolkit improvements. The section remains present with an
+  explicit empty state when no upstream item is warranted.
+
+Per-item statuses and frontmatter rollups make interrupted and repeated runs
+resumable. The promotions rollup covers RP apply-items; the filing rollup covers
+UP items plus RP file-items.
+
+### Project-log receipt
+
+When a project log exists, generate mode appends this one-line structural
+receipt:
+
+```text
+retro artifact=<path> evidence_used=<csv> evidence_unavailable=<csv> promotions=<number> upstream=<number> apply=<performed|declined|skipped|deferred> filing=<performed|declined|skipped|deferred>
+```
+
+Source identifiers are validated, deduplicated, sorted bytewise ascending, and
+joined with commas and no spaces; an empty source list is `none`. Counts
+describe the generated registers.
+
+Before any apply decision or filing dispatch, capture one immutable eligibility
+snapshot for that action. Apply snapshots contain unsettled RP apply-items;
+filing snapshots contain the lane-tagged union of unsettled UP items and RP
+file-items. Do not recompute initial eligibility after an action changes the
+registers.
+
+Derive each outcome from that snapshot with this precedence:
+
+1. An initially empty snapshot is `skipped`.
+2. An action-level interactive rejection before entry is `declined`.
+3. Non-entry, failure, or any snapshot member still unsettled is `deferred`.
+4. An entered action that completes normally with no snapshot member remaining
+   is `performed`.
+
+This makes an all-settled successful action `performed`, even though its
+post-action eligible set is empty. For mixed filing lanes, any initially
+eligible lane left unsettled by absent or `none` routing makes the single filing
+outcome `deferred`; normal completion that settles every initial lane is
+`performed`.
+
+The append uses stable structural identity and the exact rendered body:
+
+```bash
+oat project log append --project "$PROJECT_PATH" --structural \
+  --producer oat-project-retro \
+  --ref project-retro \
+  --body "$RECEIPT_BODY"
+```
+
+## Apply repo improvements
+
+Invoke apply mode directly with wording such as "apply the retro findings."
+Apply mode requires an existing retro and never regenerates it. It processes
+only RP items whose authoritative disposition is `apply` and whose status is
+`proposed` or `approved`.
+
+Interactive runs present each item, target, rationale, and concrete edit before
+approval. Non-interactive runs apply items only when
+`workflow.retro.apply: auto`; an absent value or `ask` leaves proposals
+untouched when no interaction is possible.
+
+Application follows the item type:
+
+- documentation updates the canonical existing page;
+- agent instructions update the narrowest existing instruction surface;
+- rules update the canonical scoped rule;
+- decisions use `oat decision new` after an exact duplicate check; and
+- code follow-ups default to `Disposition: file` and remain outside apply mode.
+
+After a successful application, the skill records `Status: applied` and an
+`Applied-ref`. Re-runs skip settled items and recover an exact prior side effect
+instead of applying it twice.
+
+For a docs item whose safely normalized target canonical path has the exact,
+case-sensitive final component `project-log.md`, apply mode uses
+`oat project log append` and never directly edits the log. Absolute paths,
+traversal, and ambiguous normalization fail closed; suffixes and prefixed
+lookalikes remain ordinary docs targets.
+
+The proposal must identify the prior heading or event being corrected and
+preserve the original entry. The appended judgment uses `--type feedback`,
+`--scope project`, `--area "retro correction $RP_ID"`, and a body whose stable
+identity includes both the RP ID and original-entry anchor. Before appending,
+perform semantic post-side-effect recovery. The skill recovers an exact
+uncommitted or committed correction and stops on partial, divergent, or
+multiple matches before it appends.
+
+The correction is committed first without retro writeback. A later retro-only
+writeback records `Status: applied` and an `Applied-ref` naming the full
+correction commit plus exact generated heading. `Applied-ref` is considered
+recorded only after the correction and retro writeback are durably committed.
+Append failure creates neither commit; correction-commit failure leaves the RP
+unsettled for exact recovery; writeback failure preserves the correction commit
+and retries only the writeback. This remains a bounded docs special case; it
+adds no RP type and does not weaken the normal docs apply contract.
+
+## File tracker feedback
+
+Run `oat-project-retro-file` against the active project's retro or an explicit
+artifact path. It extracts every UP item and each RP item with
+`Disposition: file`; it never mutates apply-items.
+
+Before item approval, the skill reports a lane-by-destination capability
+matrix:
+
+| Lane     | Destination | Preflight                                             |
+| -------- | ----------- | ----------------------------------------------------- |
+| Repo     | Issues      | GitHub issues enabled and `gh` authenticated          |
+| Repo     | Backlog     | Canonical OAT backlog initialized and writable        |
+| Upstream | Issues      | Upstream issues enabled and creation authorized       |
+| Either   | None        | Intentionally disabled; no external capability needed |
+
+Interactive runs confirm or override configured lane defaults and choose a
+disposition for each suspected duplicate:
+
+1. **Strengthen** the existing issue or backlog item with new evidence.
+2. **File as new** despite the candidate.
+3. **Skip** without filing.
+4. **Link existing** without adding content.
+
+Strengthening is the default when applicable, but it is still an external
+write. Non-interactive configuration does not authorize modifying an existing
+destination; an unambiguous duplicate may be linked without an external write,
+while ambiguous candidates remain unsettled for interactive review.
+
+### Local receipts and reruns
+
+Before skipping an already-filed item, the filing skill runs a pre-selection
+integrity pass. A local backlog destination is complete only when its path
+exists, its current contents still represent the retro proposal, its full
+`Destination-receipt` names the latest exact-path commit containing that path,
+and `Remote-visibility` is `pushed` or `unpushed`. A valid exact recovery may
+retain `filed` without mutating the destination. A missing or invalid local
+receipt that cannot be recovered cannot remain `filed`.
+
+New and strengthened local destinations use destination-first ordering: commit
+the destination mutation alone, verify that commit contains the backlog path
+and excludes retro writeback, then record its receipt in a later retro
+writeback commit. A failed destination commit never produces `filed`. A local
+link performs no destination mutation, but must recover and validate the latest
+exact-path commit before it can be filed.
+
+Remote visibility is independent of local durability. No configured upstream
+means `unpushed`; the skill never pushes without separate authorization.
+GitHub destinations use a validated issue URL and explicitly leave
+`Destination-receipt` and `Remote-visibility` as `—`.
+
+Public destinations receive a sanitization check when the source repository is
+private. Filing records the confirmed URL or backlog path in `Destination` and
+updates the filing rollup. Unavailable lanes and missing backlog metadata are
+reported rather than silently rerouted or invented.
+
+## Configure non-interactive consent
+
+The `workflow.retro` namespace controls non-interactive actions:
+
+| Key                              | Values                      | Unset behavior                              |
+| -------------------------------- | --------------------------- | ------------------------------------------- |
+| `workflow.retro.apply`           | `auto`, `ask`               | Propose only                                |
+| `workflow.retro.filing.repo`     | `issues`, `backlog`, `none` | No repo-lane filing                         |
+| `workflow.retro.filing.upstream` | `issues`, `none`            | No upstream-lane filing                     |
+| `workflow.retro.upstreamRepo`    | `owner/repo`                | Guidance uses `voxmedia/open-agent-toolkit` |
+
+Explicit `auto` or filing destinations count as consent only for their bounded
+action. Architecture, security, product-scope, credential, destructive, and
+duplicate-mutation boundaries still require direction. See
+[Configuration](../../cli-utilities/configuration.md#workflow-preferences-workflow)
+for the full key reference.
+
+## Summary versus retrospective
+
+|                       | Summary                       | Retrospective                                    |
+| --------------------- | ----------------------------- | ------------------------------------------------ |
+| Primary question      | What did we build and decide? | How did the run go, and what should change next? |
+| Session transcript    | Optional                      | Required when available                          |
+| OAT upstream feedback | Rare                          | Required section or explicit empty lane          |
+| Tone                  | Institutional memory          | Reflective and operational                       |
+| Default path          | `summary.md`                  | `references/project-retro.md`                    |
+
+Use the summary to preserve the delivered system and its decisions. Use the
+retro to preserve execution lessons, course changes, repo improvements, and
+upstream toolkit feedback.

package/assets/docs/workflows/skills/index.md

@@ -24,6 +24,10 @@ Use this section when you want to choose the right OAT skill for a task. If you
 - Split a broad discovery or brainstorm into child projects: `oat-project-split`
 - Retroactively capture existing work: `oat-project-capture`
 - Run or receive reviews: `oat-project-review-provide`, `oat-project-review-receive`, or the non-project review variants
+- Generate an evidence-grounded project retrospective, apply approved repo
+  improvements, or file tracker feedback: `oat-project-retro` and
+  `oat-project-retro-file`. See
+  [Project Retrospectives](../projects/retro.md).
 - Capture a scoped, shippable backlog item: `oat-pjm-add-backlog-item` directly when the work is already scoped, or `oat-brainstorm` when the thought hasn't converged yet — the brainstorm dispatcher's "scoped backlog item" destination pre-fills the title / description / acceptance criteria / scope estimate / priority from the conversation and then runs `oat-pjm-add-backlog-item` with confirmed inputs
 - Manage the repo backlog and reference docs: `oat-pjm-update-repo-reference`, `oat-pjm-review-backlog`
 - Turn a repo audit, maintainability review, backlog review, backlog directory, or backlog item into standalone external implementation plans: `oat-repo-improve`. Plans land under `.oat/repo/reference/external-plans/`; execute them directly or optionally pass one to `oat-project-import-plan` for tracked OAT execution.
@@ -74,6 +78,8 @@ Use this section when you want to choose the right OAT skill for a task. If you
     - `oat-project-pr-progress`
     - `oat-project-pr-final`
     - `oat-project-document`
+    - `oat-project-retro`
+    - `oat-project-retro-file`
     - `oat-explainer-kit`
     - `oat-wrap-up`
     - `oat-project-complete`

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.2.28",
-  "docs-config": "0.2.28",
-  "docs-theme": "0.2.28",
-  "docs-transforms": "0.2.28"
+  "cli": "0.2.30",
+  "docs-config": "0.2.30",
+  "docs-theme": "0.2.30",
+  "docs-transforms": "0.2.30"
 }

package/assets/skills/oat-project-autonomous/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-autonomous
-version: 1.0.5
+version: 1.0.6
 description: Use when a user explicitly asks to run an OAT project autonomously end-to-end. Activates session-only autonomy, resumes the correct lifecycle phase, and drives the existing OAT skills through final PR or a reported boundary.
 argument-hint: '<goal | project-slug | ticket-ref>'
 disable-model-invocation: true
@@ -72,6 +72,9 @@ waits.
 - Selecting quick or spec-driven mode from the review-density rule.
 - Invoking existing OAT lifecycle and dispatch skills in their required order.
 - Auto-resolving only the gates authorized by the autonomy contract.
+- Selecting the first existing compatible dispatch-ladder config scope through
+  the canonical user → local → authorized-shared order and adopting the bundled
+  matrix once.
 - Committing and pushing completed phase boundaries, subject to repository
   policy, and reporting explicit boundary stops.
 
@@ -297,6 +300,19 @@ Invoke each lifecycle skill by name and let it own its complete workflow,
 artifacts, gates, commits, and state transitions. Re-read project status after
 each return and route to the next earliest incomplete owner.
 
+When planning finds an incomplete dispatch ladder, apply the gate inventory's
+autonomous ownership resolution instead of treating ordinary non-interactive
+behavior as authoritative. Check config-file existence in this fixed order:
+user config, repo-local config, authorized shared config. Do not prompt or
+reorder candidates from effective value or matrix-cell provenance. Before
+writing, test each existing candidate in order, skip any that preserves a
+provider scalar or is shadowed by one at higher precedence, and block without
+mutation only when no authorized adoption-compatible scope remains. Existing
+explicit matrix cells are preserved by adoption; their provenance does not
+choose the persistence scope. Run exactly one matching
+`oat config adopt dispatch-matrix` command and re-run the reviewer preflight.
+Block when the ladder remains incomplete after adoption.
+
 At every required artifact or code review:
 
 1. Resolve the route before launch through