@open-agent-toolkit/cli 0.1.62 → 0.1.64

package/assets/skills/oat-project-implement/references/plan-and-resume.md

@@ -118,6 +118,35 @@ Determine whether this is a first implementation run:
 - If `"$PROJECT_PATH/implementation.md"` does not exist, treat as first run.
 - If it exists but still has template placeholders and no completed task evidence, treat as first run.
 
+#### Autonomous checkpoint resolution
+
+If `OAT_AUTONOMOUS=1`, resolve checkpoint state before the workflow preference
+or standard prompt paths below:
+
+1. Validate any existing `oat_plan_hill_phases` value using the normal rules.
+   A valid `[]` still means every phase; a valid explicit phase array still
+   means exactly those phases. Preserve either value unchanged and treat it as
+   confirmed for this run.
+2. On a first implementation run where the field is absent, determine the
+   final phase ID and write
+   `oat_plan_hill_phases: ["<final_phase_id>"]`. This is the existing
+   `hillCheckpointDefault: final` resolution, made explicit without prompting.
+3. Write `oat_auto_review_at_hill_checkpoints: true`. Autonomous checkpoints
+   always review and receive before continuing, even if an earlier interactive
+   setup had disabled automatic checkpoint review.
+4. Record gate `IMPLEMENT-03` and the selected final phase (or preserved
+   explicit value) in `implementation.md`. Do not persist either autonomy
+   environment signal.
+
+An invalid value remains a validation boundary; do not replace it
+autonomously. A missing value on a resumed implementation is bookkeeping drift,
+not a first-run default, and is also a boundary until the durable artifacts can
+be reconciled from authoritative evidence.
+
+After this branch succeeds, skip the workflow preference, standard checkpoint
+prompt, and auto-review preference prompt below and continue to Step 2.6.
+When `OAT_AUTONOMOUS` is not exactly `1`, this branch is inert.
+
 #### Workflow preference check (before prompting)
 
 Before presenting the checkpoint prompt to the user, check if a workflow preference has been configured:
@@ -184,6 +213,33 @@ review; Tier 1 always runs `oat-reviewer` after each phase.
 
 **On resume:** If `oat_auto_review_at_hill_checkpoints` is already present in plan.md frontmatter, skip Touchpoint A entirely — do not re-ask, do not re-read config, do not print the auto-review note. The stored value is authoritative. If only legacy `oat_auto_review_at_checkpoints` is present, treat it as authoritative for this run and write the new `oat_auto_review_at_hill_checkpoints` key on the next plan frontmatter update.
 
+#### Autonomous checkpoint review and receive
+
+When `OAT_AUTONOMOUS=1`, a configured checkpoint never waits for a user:
+
+1. Use the scope calculation in `phase-execution.md` and dispatch
+   `oat-project-review-provide` with `oat_review_invocation: auto` through the
+   project dispatch substrate.
+2. Validate the returned artifact and invoke `oat-project-review-receive`
+   immediately. Its auto-review disposition path must run without user
+   prompts.
+3. If receive creates fix tasks, execute them through the normal implement
+   route and repeat the same bounded review/receive cycle. Do not mark the
+   checkpoint complete while blocking findings remain.
+4. After a passing disposition, commit the review and HiLL bookkeeping. For a
+   non-final checkpoint, continue directly to the next schedule entry. The
+   final checkpoint routes to the Final HiLL Closeout Sequence instead of
+   waiting here.
+
+An unresolved Critical finding, failed blocking review, invalid receive
+artifact, or exhausted review route is a reported autonomy boundary. Every
+launch and receive must reference its structured dispatch record; record gate
+`IMPLEMENT-10`, the review scope, selected route, and achieved independence in
+`implementation.md`.
+
+This block replaces only the checkpoint wait while autonomy is active. The
+interactive pause and manual receive paths remain unchanged otherwise.
+
 ### Step 2.6: Validate Optional Phase Review Gate
 
 Read `oat_phase_review_gate` from `"$PROJECT_PATH/plan.md"` frontmatter when present.

package/assets/skills/oat-project-plan-writing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-plan-writing
-version: 1.2.12
+version: 1.2.13
 description: Use when authoring or mutating plan.md in any OAT workflow. Defines canonical format invariants — stable task IDs, required sections, review table rules, and resume guardrails.
 disable-model-invocation: true
 user-invocable: false
@@ -38,6 +38,26 @@ reference from `.agents/skills/oat-dispatch-subagents/references/`
 (`provider-cursor.md`, `provider-codex.md`, or `provider-claude.md`). Do not
 merge provider mechanics.
 
+## Planning-Time Artifact Formatting Contract
+
+Resolve artifact formatting once while authoring the plan. Read the applicable
+repository instructions (`AGENTS.md`/`CLAUDE.md`) and relevant package
+manifests, then select the repository's documented write/fix formatting
+command. Distinguish write/fix commands from check-only commands, prefer the
+write/fix command, and never infer or hardcode a formatter executable. When the
+documented command supports paths, use a file-scoped invocation covering only
+the files that the task will create or edit.
+
+Bake the concrete repository command into the `Format` step of every task that
+creates or edits artifacts. Downstream agents execute that supplied command
+without repeating discovery. Runtime discovery is fallback-only when the
+supplied command is absent or unusable.
+
+If no documented write/fix command can be discovered, put this exact
+warn-once/no-op instruction into every artifact-writing task:
+Warn once with `no format command discovered in repo instructions; skipping`,
+then continue without formatting.
+
 ## Managed Dispatch Readiness and Review Contract
 
 All plan-producing workflows and their artifact reviews use this contract:
@@ -54,9 +74,18 @@ before each artifact review dispatch.
 
 ### Complete Dispatch Ladder Adoption Contract
 
-Before any plan becomes implementation-ready, inspect the effective
-`workflow.dispatchCeiling.providers` value and compare its ordered candidate
-ladders with the bundled
+Before any plan becomes implementation-ready, query the merged effective
+configuration exactly once:
+
+```bash
+oat config list --json
+```
+
+Treat that output as the effective-config boundary across shared repository,
+repo-local, user, and bundled-default precedence. Do not inspect or merge raw
+config surfaces. Validate the resolved
+`workflow.dispatchCeiling.providers` provider/tier cells and compare their
+ordered candidate ladders with the bundled
 `packages/cli/config/dispatch-matrix-recommendation.json` source (or the
 installed bundle's `config/dispatch-matrix-recommendation.json` asset). A
 complete custom ladder is allowed, but every supported provider must have valid
@@ -64,8 +93,15 @@ ordered `candidates` cells through the named project ceiling. A legacy scalar,
 single fallback route, missing tier, empty candidates array, or malformed
 ordering is not a complete ladder.
 
-When the effective ladder is missing or incomplete, show the complete bundled
-recommendation before asking to write anything:
+Keep effective ladder completeness separate from project-ceiling resolution.
+When `dispatch-ceiling resolve` returns `matrix: null`, that can mean only that
+the project policy or named ceiling is unresolved; it is not evidence that the
+effective candidate ladders are absent. When every effective provider/tier cell
+is complete, skip adoption and proceed directly to the separate project-ceiling
+choice.
+
+Only when effective provider/tier cells are missing or incomplete, show the
+complete bundled recommendation before asking to write anything:
 
 | Provider        | Economy                                                        | Balanced                                                                                                       | High                                                        | Frontier                               |
 | --------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | -------------------------------------- |
@@ -89,12 +125,12 @@ project's named ceiling is a separate project-state constraint. A
 project-specific active policy or ceiling must not be written to user
 `~/.oat/config.json`.
 
-Adoption preserves explicit cells. Re-run the resolver and re-check the full
-ladder after adoption. If preserved legacy or partial cells still leave the
-ladder incomplete or missing, identify those cells and block; do not overwrite,
-infer, or mark the plan implementation-ready. In non-interactive mode, an
-incomplete or missing ladder blocks readiness without choosing an ownership
-scope.
+Adoption preserves explicit cells. After adoption, repeat the merged
+effective-config query and re-check the full ladder before you re-run the
+resolver. If preserved legacy or partial cells still leave effective cells
+incomplete or missing, identify those cells and block; do not overwrite, infer,
+or mark the plan implementation-ready. In non-interactive mode, incomplete or
+missing effective cells block readiness without choosing an ownership scope.
 
 ### Reviewer Ceiling Contract
 

package/assets/skills/oat-project-pr-final/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-pr-final
-version: 1.4.2
+version: 1.5.1
 description: Use when the user requests or confirms opening the final PR for an active OAT project — e.g. "open the final PR", "ship it", "run oat-project-pr-final", or confirms a previously offered final-PR step. Do NOT auto-invoke when phases are marked complete. Generates the final lifecycle PR description from artifacts and creates the PR.
 disable-model-invocation: false
 user-invocable: true
@@ -38,6 +38,11 @@ Generate a PR-ready summary grounded in canonical OAT artifacts, including:
 
 **Purpose:** Create final PR description and open the PR.
 
+When `OAT_AUTONOMOUS=1`, read `references/docs/autonomy-contract.md` and keep
+`OAT_NON_INTERACTIVE=1` set for this run. Autonomous resolution is limited to
+the explicit branches below; never persist either environment signal. When
+autonomy is inactive, preserve the existing interactive path unchanged.
+
 ## Progress Indicators (User-Facing)
 
 When executing this skill, provide lightweight progress feedback so the user can tell what’s happening after they confirm.
@@ -87,6 +92,14 @@ Run the `oat-project-pr-final` skill and it will ask for:
   - otherwise default: `{type}: {project description}` using conventional-commit style (for example `feat: add review loop` or `docs: reorganize documentation for discoverability`)
 - base branch (resolved from: explicit `base=` arg → `git.defaultBranch` in `.oat/config.json` → `git rev-parse --abbrev-ref origin/HEAD` → fallback `main`)
 
+## Artifact Hygiene
+
+Artifact hygiene contract: Before finishing or committing, format every file you created or edited. Use the concrete write/fix formatting command supplied by the governing plan, task, or brief. If none is usable, discover the repository's documented write/fix command from applicable `AGENTS.md`/`CLAUDE.md` instructions and relevant package manifests; do not infer or hardcode a formatter. Prefer a file-scoped invocation when supported, and avoid rewriting unrelated files. If no command is discoverable, warn once with `no format command discovered in repo instructions; skipping`, then continue.
+
+After formatting, run only repository checks relevant to the files changed;
+writing a PR description or project-state prose does not imply unrelated full
+test suites.
+
 ## Process
 
 ### Step 0: Resolve Active Project
@@ -162,9 +175,23 @@ echo "$FINAL_ROW"
 
 If `FINAL_ROW` is missing or does not contain `passed`:
 
-- Tell user: "Final review is not marked passed. Run the `oat-project-review-provide` skill with `code final` then the `oat-project-review-receive` skill."
-- Ask whether to proceed anyway (allowed, but discouraged).
-  - If the status is `fixes_completed`: fixes were implemented but the re-review hasn't been run/recorded yet; re-run the `oat-project-review-provide` skill with `code final` then the `oat-project-review-receive` skill to reach `passed`.
+- If `OAT_AUTONOMOUS=1`, gate `PRFINAL-03` is a boundary stop. Never select
+  "proceed anyway." Report the current or missing final-review row, record the
+  blocker in project provenance, and stop before writing the PR artifact,
+  pushing, or creating the PR. Route the resumable next step to
+  `oat-project-review-provide code final` followed by
+  `oat-project-review-receive`.
+  - If the status is `fixes_completed`, require that same re-review/receive
+    sequence to reach `passed`; completed fixes alone are not approval.
+- Otherwise:
+  - Tell user: "Final review is not marked passed. Run the
+    `oat-project-review-provide` skill with `code final` then the
+    `oat-project-review-receive` skill."
+  - Ask whether to proceed anyway (allowed, but discouraged).
+    - If the status is `fixes_completed`: fixes were implemented but the
+      re-review hasn't been run/recorded yet; re-run the
+      `oat-project-review-provide` skill with `code final` then the
+      `oat-project-review-receive` skill to reach `passed`.
 
 ### Step 3: Collect Project Summary