@open-agent-toolkit/cli 0.1.62 → 0.1.64

package/assets/skills/oat-project-implement/references/completion-and-closeout.md

@@ -162,6 +162,28 @@ echo "$FINAL_ROW"
 
 - Tell user: "All tasks complete. Final review required before PR."
 
+**Autonomous final-review path (before prompting):**
+
+If `OAT_AUTONOMOUS=1`, do not present a review-execution choice. Resolve the
+exact reviewer target through the project dispatch substrate, select the
+highest target-preserving route before launch, and run
+`oat-project-review-provide code final` followed immediately by
+`oat-project-review-receive`.
+
+- If receive creates fix tasks, return through the normal bounded implement and
+  re-review loop.
+- Continue to Step 15 only when the final Reviews row is `passed`.
+- A failed blocking review, unresolved Critical finding, exhausted route, or
+  missing credential with no adequate fallback is an autonomy boundary. Persist
+  the review state and report the exact resume action instead of falling
+  through to the prompt.
+- Record gate `IMPLEMENT-11`, the selected route, achieved independence, and
+  dispatch-record reference in `implementation.md`.
+
+After this autonomous branch succeeds, skip the workflow preference,
+fresh-session guidance, and standard prompt below. When `OAT_AUTONOMOUS` is not
+exactly `1`, this branch is inert.
+
 **Workflow preference check (before prompting):**
 
 First resolve the final reviewer target with the same target-first contract as
@@ -273,20 +295,40 @@ legacy or structured preference, normalize legacy values before snapshotting:
 ["summary", "pr"], postApproval: [] }`, and `docs-pr` → `{ preApproval:
 ["summary", "document", "pr"], postApproval: [] }`.
 
+If `OAT_AUTONOMOUS=1` and the preference is unset, use the inventory's
+autonomous lifecycle-tail default:
+
+```yaml
+preApproval: [summary, document, pr]
+postApproval: []
+```
+
+Treat this as an in-memory effective preference and create the same immutable
+sequence snapshot as a configured structured value. Add
+`source: autonomous-default` to that snapshot. A configured legacy or
+structured preference remains authoritative and uses `source: configured`;
+preserve its normalized arrays and stored order exactly.
+
 Persist this immutable state before dispatching a child:
 
 ```yaml
 oat_post_implement_sequence:
   status: pre_approval # pre_approval | awaiting_approval | post_approval | failed | complete
+  source: configured # configured | autonomous-default
   final_phase: pNN
   pre_approval: [summary, document, pr]
   pre_approval_completed: []
   approval: pending # pending | approved | not_required
+  approval_source: null # null | user | oat-autonomous
   post_approval: []
   post_approval_completed: []
   failure: null
 ```
 
+`source` and `approval_source` are additive provenance fields. A resumable
+snapshot created by an older skill version remains valid when either field is
+absent; do not rewrite its stored pre/post arrays merely to backfill provenance.
+
 The snapshot is immutable for this closeout: never re-resolve
 `workflow.postImplementSequence` while it is incomplete. Iterate
 `pre_approval` and `post_approval` in their stored array order; do not sort or
@@ -313,8 +355,8 @@ exact resume command: `oat-project-implement`.
 awaiting_approval` with `approval: pending` before asking for final HiLL
    approval.
 3. Record explicit approval as `approval: approved` and `status: post_approval`
-   before any post-approval dispatch. Then dispatch incomplete `post_approval`
-   steps in stored order.
+   before any post-approval dispatch. Record `approval_source: user` in the same
+   commit. Then dispatch incomplete `post_approval` steps in stored order.
 4. A decline or defer keeps `status: awaiting_approval` and `approval: pending`;
    record neither approval nor failure and run no post-approval step. State the
    boundary and exact resume command: `oat-project-implement`.
@@ -325,14 +367,37 @@ awaiting_approval` with `approval: pending` before asking for final HiLL
    implementation state, append the configured final HiLL completion, and
    continue to the existing next-step behavior.
 
-If the preference is unset, do not create a sequence snapshot. When the
-preference is unset, retain the existing next-step prompt only after final
-approval when a final checkpoint is configured.
+**Autonomous final HiLL approval:**
+
+When `OAT_AUTONOMOUS=1`, gate `IMPLEMENT-16` replaces only the approval question
+in steps 2-4:
+
+1. Require the final review row to be `passed` and verify its review artifact
+   and dispatch record. A failed blocking review or unresolved Critical finding
+   stops before approval.
+2. After all `pre_approval` steps succeed, commit `status: awaiting_approval`
+   with `approval: pending` exactly as above.
+3. Without waiting for input, commit `approval: approved`,
+   `approval_source: oat-autonomous`, and `status: post_approval`, referencing
+   the passing final review and dispatch record in `implementation.md`.
+4. Dispatch incomplete `post_approval` steps in stored order, then finish the
+   snapshot normally.
+
+The policy approval occurs after pre-approval work and before any post-approval
+work. It does not waive a failed review, child failure, repository-policy
+approval, destructive-change risk, or missing-credential boundary. When
+autonomy is inactive, the explicit user approval/decline/defer behavior above
+is unchanged.
+
+If the preference is unset and autonomy is inactive, do not create a sequence
+snapshot. Retain the existing next-step prompt only after final approval when a
+final checkpoint is configured. Under autonomy, the default snapshot above
+always resolves the unset case.
 
 ### Step 16: Prompt for Next Steps
 
-Run the standard next-step prompt only when
-`workflow.postImplementSequence` was unset and no sequence snapshot was
+Run the standard next-step prompt only when `OAT_AUTONOMOUS` is not `1`,
+`workflow.postImplementSequence` was unset, and no sequence snapshot was
 created. It occurs after final approval when a final checkpoint is configured.
 A configured legacy or structured preference has already completed through
 **Final HiLL Closeout Sequence**; do not re-dispatch its steps here. When the

package/assets/skills/oat-project-implement/references/dispatch-and-dry-run.md

@@ -49,16 +49,23 @@ block on user-initiated fresh sessions mid-run):
   context; do not rely on forked full-thread context when pinning a
   specialized OAT role.
   - Available without auth → Tier 1.
-  - Available with auth required → fail closed. Ask the user once at skill
-    start before selecting Tier 2 or starting implementation work:
+  - Available with auth required:
+    - If `OAT_AUTONOMOUS=1`, gate `IMPLEMENT-08` authorizes delegation once
+      for this run, covering only `oat-phase-implementer` and `oat-reviewer`
+      within the plan's bounded phase/review scopes. Record the authorization
+      scope in the dispatch record, re-probe, and use Tier 1 when the host
+      accepts it. If the host requires an out-of-band grant that the current
+      run cannot supply, stop at a reported authorization boundary.
+    - Otherwise, fail closed and ask the user once at skill start before
+      selecting Tier 2 or starting implementation work:
 
-    ```
-    This OAT implementation skill normally delegates phase implementation and review to subagents. Authorize subagent delegation for this run?
+      ```
+      This OAT implementation skill normally delegates phase implementation and review to subagents. Authorize subagent delegation for this run?
 
-    Yes authorizes both oat-phase-implementer and oat-reviewer across every phase in this run.
-    ```
+      Yes authorizes both oat-phase-implementer and oat-reviewer across every phase in this run.
+      ```
 
-    Approved → Tier 1. Declined → Tier 2.
+      Approved → Tier 1. Declined → Tier 2.
 
 - If the host does not resolve either generic agent, first attempt the exact
   registered role natively for any concrete managed target. Use the explicitly
@@ -69,8 +76,9 @@ block on user-initiated fresh sessions mid-run):
 **Approval scope rule:** this Tier selection applies to both phase
 implementation and checkpoint review. Do not infer a mixed mode from
 conversational emphasis on review checkpoints. If the user has not explicitly
-approved Tier 1 for the run, stay Tier 2 throughout. Mixed mode is only valid
-when the user explicitly requests it.
+approved Tier 1 for the run, and gate `IMPLEMENT-08` has not supplied the
+bounded autonomous run authorization above, stay Tier 2 throughout. Mixed mode
+is only valid when the user explicitly requests it.
 
 **Codex fail-closed rule:** after this skill is invoked, "user did not
 separately ask for subagents" is not a valid Tier 2 reason. If Codex can spawn