@open-agent-toolkit/cli 0.2.58 → 0.2.59

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

@@ -1,6 +1,6 @@
 ---
 name: oat-project-import-plan
-version: 1.4.12
+version: 1.4.13
 description: Use when you have an external markdown plan to execute with OAT. Preserves the source plan and normalizes it into canonical plan.md format.
 argument-hint: '<path-to-plan.md> [--provider codex|cursor|claude] [--project <name>]'
 oat_gateable: true
@@ -307,6 +307,25 @@ This Phase gate review setup is independent from HiLL checkpoints. Do not read o
 change HiLL fields here, and do not add a provider/model `--target` to any
 lifecycle command.
 
+### Step 4.35: Configure Lifecycle Gate Posture
+
+After normalization has produced stable phase IDs and before Step 4.5 starts
+the import-aware plan artifact review, invoke the `Shared Lifecycle Gate Posture Setup Contract` from
+`oat-project-plan-writing`: load the current
+`oat-project-plan-writing/SKILL.md` and follow that contract as written. This
+runs adjacent to, but independently from, the phase gate review setup above.
+
+If `"$PROJECT_PATH/state.md"` already contains an explicit
+`oat_skill_gate_overrides` map, preserve it through the shared contract without
+probing, prompting, or mutation. Otherwise let the contract probe the configured
+gate-aware skills and offer a keep-or-disable choice for each configured gate
+independently.
+
+Persist only disabled choices, and only in `"$PROJECT_PATH/state.md"`. Keeping
+every gate leaves the map absent. Never modify the shared, local, or user
+configuration layers, and never prompt or write a new map in non-interactive
+mode.
+
 ### Step 4.5: Run Import-Aware Plan Artifact Review Loop
 
 Before dispatching the artifact reviewer, invoke the `Managed Dispatch
@@ -452,13 +471,19 @@ fi
 
 Before reporting this skill as complete, run the configured gate as the final step after artifact review, state sync, dashboard refresh, and the import artifact commit:
 
-1. Resolve the gate for this skill:
+1. Resolve the gate for this skill with project context:
 
    ```bash
-   oat gate resolve <this-skill> --json
+   oat gate resolve <this-skill> --project "$PROJECT_PATH" --json
    ```
 
-   If the command returns JSON `null`, no gate is configured; the skill is complete.
+   Handle all three `resolution` values explicitly:
+   - `not_configured`: no gate is configured; the skill is complete.
+   - `configured_disabled_by_project`: the operator disabled this configured gate for this project. Do not launch any process. Emit `configured but disabled by project override`, including the project path and the `projectOverride` source from the envelope, then the skill is complete. A project-disabled gate never enters the passed, missing, or failed branches, and its `configuredGate` is evidence only, never executed.
+   - `configured`: continue with the steps below, executing `effectiveGate` exactly as configured.
+
+   A null, missing, malformed, or unrecognized result is an operational failure
+   that fails closed as unresolved. Never treat it as "no gate configured."
 
 2. Export the resolved project path into the command shell:
 

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

@@ -1,6 +1,6 @@
 ---
 name: oat-project-next
-version: 1.0.13
+version: 1.0.14
 description: Use when continuing work on the active OAT project. Reads project state, determines the next lifecycle action, and invokes the appropriate skill automatically.
 disable-model-invocation: true
 user-invocable: true
@@ -302,7 +302,8 @@ unresolved or stale — resume with `oat-project-implement` before
 post-implementation routing."
 
 Only an `allowed` and fresh exit-gate disposition falls through to the normal
-post-implementation checks.
+post-implementation checks. Every other combination keeps its current
+fail-closed routing.
 
 Validate freshness from the complete persisted transition, not from `status`
 alone:
@@ -316,6 +317,32 @@ alone:
   `implementation_fingerprint`, configured gate-run provenance, and any eligible
   receive durably completed. Qualified state also requires the complete rolling
   freshness fields.
+- `allowed/configured` with `disposition: project_disabled` is the third valid
+  combination. Null gate-run and artifact provenance is required here, not
+  merely tolerated: nothing launched, so any non-null launch provenance is
+  contradictory and fails closed. It additionally requires a matching
+  `config_fingerprint`, `reviewed_head`, and `implementation_fingerprint`, a
+  `project_override` sub-record recording the disabled value and its
+  `state.md:oat_skill_gate_overrides` source, and the same rolling-freshness
+  rules as every other allowed result. The complete accepted shape is
+  `resolved_command` set to the configured command, `launch_state:
+not_started`, null `launch_attempt_id`, `launch_started_at`,
+  `launch_result_receipt`, `gate_run_marker`, `gate_run_id`, `envelope_status`,
+  `artifact`, and `handoff`, plus `receive_state: not_started`,
+  `receive_correlation`, `receive_source_artifact`,
+  `receive_archived_artifact`, `receive_event_identity`, `receive_pre_head`,
+  and `receive_commit` all null, `receive_eligible: false`,
+  `receive_completed: false`, `attempts_completed: 0`, and `failure: null`.
+  Any populated launch, receive, attempt, or failure field contradicts a gate
+  that never ran and fails closed.
+- Because the override lives in the state carrier the implementation
+  fingerprint excludes, a persisted `project_disabled` result is never accepted
+  on its stored value alone. Re-resolve the gate with project context and
+  require that the current resolution is still `configured_disabled_by_project`
+  and that `config_fingerprint` recomputed from that current resolution equals
+  the persisted one. A re-enabled gate changes the resolution and the
+  fingerprint, so an override-era transition routes as stale and a fresh
+  configured run is required.
 - `pending`, `blocked`, malformed, contradictory, or legacy-absent state never
   falls through. Pending and blocked generations resume their persisted
   configuration; configuration-fingerprint mismatch fails closed.

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

@@ -1,6 +1,6 @@
 ---
 name: oat-project-plan
-version: 1.4.7
+version: 1.4.8
 description: Use when design.md is complete and executable implementation tasks are needed. Breaks design into bite-sized TDD tasks in canonical plan.md format.
 oat_gateable: true
 disable-model-invocation: true
@@ -483,6 +483,25 @@ This Phase gate review setup is independent from HiLL checkpoints. Do not read o
 change HiLL fields here, and do not add a provider/model `--target` to any
 lifecycle command.
 
+### Step 12.35: Configure Lifecycle Gate Posture
+
+After the confirmed plan has stable phase IDs and before Step 12.5 starts the
+plan artifact review, invoke the `Shared Lifecycle Gate Posture Setup Contract` from
+`oat-project-plan-writing`: load the current
+`oat-project-plan-writing/SKILL.md` and follow that contract as written. This
+runs adjacent to, but independently from, the phase gate review setup above.
+
+If `"$PROJECT_PATH/state.md"` already contains an explicit
+`oat_skill_gate_overrides` map, preserve it through the shared contract without
+probing, prompting, or mutation. Otherwise let the contract probe the configured
+gate-aware skills and offer a keep-or-disable choice for each configured gate
+independently.
+
+Persist only disabled choices, and only in `"$PROJECT_PATH/state.md"`. Keeping
+every gate leaves the map absent. Never modify the shared, local, or user
+configuration layers, and never prompt or write a new map in non-interactive
+mode.
+
 ### Step 12.5: Run Plan Artifact Review Loop
 
 Before dispatching the artifact reviewer, invoke the `Managed Dispatch
@@ -540,13 +559,19 @@ Apply the shared loop exactly:
 After the plan artifact is finalized and reviewed, run the configured gate as
 the last check before the completion boundary:
 
-1. Resolve the gate for this skill:
+1. Resolve the gate for this skill with project context:
 
    ```bash
-   oat gate resolve <this-skill> --json
+   oat gate resolve <this-skill> --project "$PROJECT_PATH" --json
    ```
 
-   If the command returns JSON `null`, no gate is configured; proceed directly to the completion steps in Step 13 below.
+   Handle all three `resolution` values explicitly:
+   - `not_configured`: no gate is configured; proceed directly to the completion steps in Step 13 below.
+   - `configured_disabled_by_project`: the operator disabled this configured gate for this project. Do not launch any process. Emit `configured but disabled by project override`, including the project path and the `projectOverride` source from the envelope, then proceed directly to the completion steps in Step 13 below. A project-disabled gate never enters the passed, missing, or failed branches, and its `configuredGate` is evidence only, never executed.
+   - `configured`: continue with the steps below, executing `effectiveGate` exactly as configured.
+
+   A null, missing, malformed, or unrecognized result is an operational failure
+   that fails closed as unresolved. Never treat it as "no gate configured."
 
 2. Export the resolved project path into the command shell:
 

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

@@ -1,6 +1,6 @@
 ---
 name: oat-project-plan-writing
-version: 1.2.21
+version: 1.2.22
 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
@@ -403,6 +403,100 @@ This setup is independent from HiLL checkpoints. It must not read or change
 choice is offered; normal lifecycle gate commands remain provider-neutral.
 They must not add a provider/model `--target` argument.
 
+## Shared Lifecycle Gate Posture Setup Contract
+
+Every plan-producing workflow invokes this procedure after the complete plan
+has stable phase IDs and before the plan artifact review begins, which is the
+same boundary the phase gate review setup uses. It runs adjacent to, but
+independently from, that setup: neither contract reads, writes, or
+satisfies the other's setting. The calling skill owns the prompt and the write
+to `"$PROJECT_PATH/state.md"`; this section owns the shared eligibility,
+preservation, validation, and non-interactive behavior.
+
+This contract governs the configured lifecycle gates declared with
+`oat_gateable: true` in skill frontmatter. It never reads or writes
+`oat_phase_review_gate`, HiLL policy, or any autonomous design-gate setting.
+
+### 1. Preserve an explicit existing map
+
+Inspect `"$PROJECT_PATH/state.md"` frontmatter before probing configuration. If
+an explicit `oat_skill_gate_overrides` key is present, preserve the complete
+value unchanged. Do not probe, prompt, or mutate it. This applies equally to
+resumed and imported projects. Report:
+
+```text
+Lifecycle gate posture: preserved existing oat_skill_gate_overrides setting.
+```
+
+A malformed map is never silently repaired, replaced, or dropped. Stop and
+report the offending project state path so the operator can correct it.
+
+### 2. Probe configured gate-aware skills
+
+When no explicit map exists, probe each gate-aware skill read-only. The probe
+resolves configuration and never launches a gate:
+
+```bash
+oat gate resolve <gate-aware-skill> --project "$PROJECT_PATH" --json
+```
+
+A gate qualifies for a choice only when `resolution` is literally `configured`.
+`not_configured` means no gate is configured for that skill: offer no choice and
+never fabricate configuration from an override alone.
+
+If the probe fails, emit exactly this concise warning and continue planning
+without writing a map:
+
+```text
+Warning: Lifecycle gate posture probe failed; configured gates remain enabled.
+```
+
+If no gate is configured, emit:
+
+```text
+Lifecycle gate posture: no configured lifecycle gates; nothing to disable.
+```
+
+### 3. Offer one choice per configured gate
+
+When at least one gate is configured and an interactive user-response channel is
+available, present each configured gate separately and let the user keep or
+disable it independently. Granularity is per skill; no single answer disables
+every gate at once.
+
+For each configured gate, show the skill name, its configured command, and the
+config source reported by the probe, then offer exactly these outcomes:
+
+1. **Keep** - run this configured gate for this project.
+2. **Disable** - skip this configured gate for this project only.
+
+Persist only the disabled choices, as a strict map whose sole permitted value is
+the literal `disabled`:
+
+```yaml
+oat_skill_gate_overrides:
+  oat-project-implement: disabled
+```
+
+Keeping every gate leaves the map absent; an explicitly empty map is equivalent.
+Never write an `enabled` value, a boolean, or a list. Write the map only to
+`"$PROJECT_PATH/state.md"`; the shared, local, and user configuration layers are
+never modified. Disabling here records project posture, not gate outcome: it
+never marks a gate passed, failed, or missing.
+
+### 4. Handle non-interactive planning
+
+Non-interactive mode includes `OAT_NON_INTERACTIVE=1` and any environment with
+no user-response channel. Never prompt in this mode, and never write a new map,
+even when configured gates exist. Leave the setting absent and emit:
+
+```text
+Lifecycle gate posture: configured gates unchanged (non-interactive; no selection recorded).
+```
+
+An explicit map that already exists is still preserved unchanged in this mode
+under section 1.
+
 ## Auto Artifact-Review Loop
 
 This is the canonical contract for bounded automated reviews of generated OAT artifacts. Calling skills own the concrete edits, progress indicators, and commits; this section defines the shared loop they must follow.