@open-agent-toolkit/cli 0.1.60 → 0.1.63

package/README.md

@@ -40,6 +40,20 @@ Additional useful entry points:
 - `oat repo archive sync`
 - `oat doctor`
 
+## Update Notifications
+
+On ordinary interactive command runs, OAT may print a passive notice when npm's stable `latest` CLI version is newer than the installed version. The cache normally limits checks to once every 24 hours and same-version notices to once every 72 hours; overlapping CLI processes can each perform a check or print a notice.
+
+`oat init`, `oat tools install`, and `oat tools update` are different because they copy tools bundled with the running CLI. Before an eligible interactive mutation, a known newer CLI triggers a warning that the current CLI can only install its own bundled tool versions and that the available CLI may bundle newer versions. OAT then offers, defaulting to no, to run `npm install --global @open-agent-toolkit/cli@<validated-version>` for the exact validated stable version. Acceptance updates the CLI package, stops before changing tools, and asks you to rerun the original command. Declining or aborting continues with the current bundle after a warning. An installer failure stops the tool mutation and reports the command you can retry.
+
+This warning does not mean tools installed from the current bundle are incompatible with the current CLI; it only identifies that a newer CLI release may include newer bundled tool versions. Dry-run, JSON, non-interactive, CI, test, source-development, and ephemeral package-runner invocations do not prompt or install. Ordinary eligible commands remain passive.
+
+Set `NO_UPDATE_NOTIFIER` to a truthy value (for example, `1`, `true`, `yes`, or `on`) to suppress checks for one process; empty, `0`, and `false` do not suppress them. Or persist the user-level preference:
+
+```bash
+oat config set updateNotifications false --user
+```
+
 ## Inspection Commands
 
 Use these commands when you want structured runtime/project state out of the CLI:

package/assets/docs/cli-utilities/config-and-local-state.md

@@ -113,6 +113,26 @@ Use `oat config` for repo runtime config inspection and supported key mutation.
 
 Use `oat config dump --json` when you need the whole resolved config in one machine-readable response rather than a single key or a human-oriented list view.
 
+### Update notifications
+
+OAT can passively report when npm's stable `latest` CLI version is newer during an ordinary interactive command run. The cache normally limits checks to once every 24 hours and same-version notices to once every 72 hours; overlapping CLI processes can each perform a check or print a notice. Ordinary eligible commands only show update guidance and do not prompt.
+
+Before eligible interactive `oat init`, `oat tools install`, or `oat tools update` mutations, a known newer stable CLI receives special handling. These commands copy tool versions bundled with the running CLI, so OAT warns that the older CLI can only install its own bundle and that the available CLI may contain newer bundled tools. The default-no prompt offers to install the exact validated version with:
+
+```bash
+npm install --global @open-agent-toolkit/cli@<validated-version>
+```
+
+If accepted, OAT updates the CLI package, stops before changing tools, and asks you to rerun the original command under the new CLI. If declined or the prompt is aborted, OAT warns and continues with the current bundle. If npm fails, the requested tool mutation does not run and the error includes a command to retry. The warning describes possible bundle freshness; it does not claim that tools installed by the current CLI are incompatible with that CLI.
+
+Checks, notices, and the update offer are skipped for JSON, non-interactive, CI, test, source-development, and ephemeral package-runner invocations. Guarded dry-run commands also skip the prompt and installer. Set `NO_UPDATE_NOTIFIER` to a truthy value (for example, `1`, `true`, `yes`, or `on`) to suppress checks for one process; empty, `0`, and `false` do not suppress them. Or disable checks persistently in user config:
+
+```bash
+oat config set updateNotifications false --user
+```
+
+The preference defaults to `true`; run the same command with `true` to re-enable it. Cached check and notice timestamps live in `~/.oat/update-check.json`, separate from the user-authored preference in `~/.oat/config.json`.
+
 Dispatch policy keys are part of this surface, but provider-specific generation
 still belongs to provider commands. Use `oat config describe
 workflow.dispatchPolicy.policy` to inspect capped managed, managed uncapped,

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

@@ -468,6 +468,35 @@ Workflow preference keys live under the `workflow.*` namespace:
 - `workflow.dispatchCeiling.recommendationVersion` — version of the adopted recommended matrix.
 - `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.
 
+### HiLL plan-field semantics
+
+`workflow.hillCheckpointDefault` controls the first implementation run's
+checkpoint choice, but the confirmed selection is stored in `plan.md` as
+`oat_plan_hill_phases`. The plan field has three distinct states:
+
+| `oat_plan_hill_phases` state | Meaning                                                                                                                                                     |
+| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Field absent                 | Checkpoint selection is unconfirmed. This is valid before the first implementation run; a resumed run treats it as bookkeeping drift that must be resolved. |
+| `[]`                         | Checkpoint after every phase boundary.                                                                                                                      |
+| `["p02", "p04"]`             | Checkpoint only after the listed phases complete.                                                                                                           |
+
+**Never write `[]` to mean no checkpoints.** It means every phase. To select
+only the final checkpoint, store the final phase ID explicitly:
+
+```yaml
+oat_plan_hill_phases: ['p04']
+```
+
+With `workflow.hillCheckpointDefault: every`, the first implementation run
+writes `[]`. With `workflow.hillCheckpointDefault: final`, it writes
+`["<final-phase-id>"]`. An autonomous run with an absent field takes that same
+explicit final-default path and enables checkpoint auto-review; it preserves an
+existing valid empty or explicit list. Because autonomy itself is never
+persisted, a later interactive run pauses at the stored checkpoints normally.
+
+See [HiLL Checkpoints](../workflows/projects/hill-checkpoints.md) for timing and
+approval behavior.
+
 ### Auto artifact-review preferences
 
 `workflow.autoArtifactReview.*` controls the artifact-quality loops that run before downstream workflow steps consume generated artifacts. Both keys are default-on. Only an explicit `false` disables the matching loop:

package/assets/docs/cli-utilities/tool-packs.md

@@ -49,6 +49,25 @@ skills can use the utility engine directly.
 
 The `oat tools` command group provides a unified interface for managing installed tools (skills and agents) across scopes.
 
+### CLI updates before bundled-tool mutations
+
+Tool packs ship inside the OAT CLI package. An older CLI can therefore install or update only the tool versions in its own bundle, while a newer stable CLI release may contain newer bundled versions. This is a bundle-freshness warning, not a claim that tools installed by the current CLI are immediately incompatible with it.
+
+Before an eligible interactive `oat init`, `oat tools install` (including pack subcommands), or `oat tools update` mutation, OAT checks the cached stable CLI availability. If a newer version is known, it explains the bundle difference and offers, with a default answer of no, to install that exact validated version:
+
+```bash
+npm install --global @open-agent-toolkit/cli@<validated-version>
+```
+
+- Accepting updates the CLI package only, stops before changing bundled tools, and asks you to rerun the original command under the new CLI.
+- Declining or aborting warns that the current bundle may be older, then continues the requested command.
+- If npm fails, OAT does not run the tool mutation and reports how to retry the CLI installation.
+- Dry-run, JSON, non-interactive, opted-out, CI, test, source-development, and ephemeral package-runner invocations do not prompt or install.
+
+Set `NO_UPDATE_NOTIFIER` to a truthy value (for example, `1`, `true`, `yes`, or `on`) to suppress checks for one process; empty, `0`, and `false` do not suppress them.
+
+Other eligible commands keep the passive update notice and never launch the installer.
+
 ## Install vs. initialize
 
 The `project-management` pack has two lifecycle steps:
@@ -131,7 +150,7 @@ Key behavior:
 - Pack-oriented install subcommands: `core`, `docs`, `ideas`, `workflows`, `utility`, `project-management`, `research`, `brainstorm`
 - Interactive installs show each pack's current install location in the picker so already-installed packs are visible before you submit
 - Installing is **additive**: choosing a scope for a pack never removes it from another scope. A user-eligible pack installed at user scope plus a project install ends up at `project + user`, not moved
-- For each user-eligible pack (`ideas`, `docs`, `utility`, `research`, `brainstorm`), the interactive flow offers a per-pack end-state selector (`project`, `user`, or `both`) defaulting to the pack's current placement; leaving the default makes no changes for that pack
+- For each user-eligible pack (`ideas`, `docs`, `workflows`, `utility`, `research`, `brainstorm`), the interactive flow offers a per-pack end-state selector (`project`, `user`, or `both`) defaulting to the pack's current placement; leaving the default makes no changes for that pack
 - `oat init --setup` uses this same additive scope resolver. In guided setup, choosing to customize scope reaches the per-pack selector; choosing the recommended defaults, or running non-interactively, applies additive per-pack defaults without removals
 - The `brainstorm` pack defaults to user scope on fresh installs (driven by `PACK_METADATA[brainstorm].defaultScope = 'user'`); existing installs keep their current placement on re-install, so a re-install never moves a pack between scopes
 - Removing a pack from a scope happens only when you explicitly choose a narrower end-state in the interactive flow (e.g. a pack at `both` set to `project` only). All staged removals are shown in a single change summary and applied only after one batch confirmation — declining makes no changes
@@ -154,6 +173,7 @@ Key behavior:
 - Accepts a tool name, `--pack <pack>`, or `--all` (mutually exclusive)
 - Compares installed versions against bundled versions and copies updated assets
 - For `--pack <pack>` and `--all`, an already-installed pack is reconciled to include newly added bundled skills or agents in that same scope
+- Pack-targeted updates intentionally rewrite bundled template and script companions in place, even when the pack's installed skills are already current
 - For `--pack <pack>` and `--all`, shared repo config is also reconciled from an installed-pack scan so `tools.*` reflects what is actually available and stale `true` flags are cleared
 - Dry-run mode with `--dry-run`; auto-sync after mutations by default
 - Use `--no-sync` to skip auto-sync
@@ -183,6 +203,33 @@ Tool-pack lifecycle commands now persist pack availability in shared repo config
 
 This matters because other workflows can now check `oat config get tools.<pack>` instead of inferring capabilities from directory existence alone. For example, `oat-project-document` checks `tools.project-management` before auto-running repo-reference refresh work.
 
+## Workflows pack
+
+The workflows pack is installable at project scope, user scope, or both. A
+user-scope install carries the complete versioned asset set:
+
+- skills and agents → `~/.agents/skills/` and `~/.agents/agents/`;
+- templates → `~/.oat/templates/`;
+- executable helper scripts → `~/.oat/scripts/`.
+
+Use either the direct or aggregate form:
+
+```bash
+oat tools install workflows --scope user
+oat init tools workflows --scope user
+```
+
+User scope intentionally skips project-root scaffolding: it does not create a
+home-level `.oat/projects-root`, `.oat/projects/` tree, or projects-root config.
+Projects remain anchored in the target repository. Project-scope installation
+retains its existing scaffolding and local-path setup.
+
+`oat tools update --pack workflows --scope user` refreshes all four asset
+classes in place, including newly bundled skills and agents. Pack removal and a
+confirmed aggregate scope reduction remove those same user-level assets.
+Companion template and script removal is user-scope-only; project-scope removal
+leaves repo-local `.oat/templates/` and `.oat/scripts/` assets intact.
+
 ## Core pack
 
 The `core` pack contains foundational diagnostic and documentation skills:

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

@@ -0,0 +1,154 @@
+---
+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.
+
+## 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. Important
+  findings follow the configured gate policy.
+
+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, pre-approval lifecycle steps run first. After a passing final
+review, autonomy records final HiLL approval and then runs post-approval steps.
+A failed blocking review stops before approval. 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/cursor-cloud.md

@@ -0,0 +1,151 @@
+---
+title: OAT in Cursor Cloud
+description: 'How Cursor Cloud agents resolve the OAT project home, verify provisioned tooling, and use cloud-specific execution surfaces safely.'
+---
+
+# OAT in Cursor Cloud
+
+Cursor Cloud is a harness environment for the same repository-rooted OAT
+workflow used locally. Cloud context does not change project artifact formats,
+gate ownership, or autonomy boundaries.
+
+The `oat-cursor-cloud-projects` orientation skill owns cloud-specific setup and
+routing guidance. It should surface when OAT is used in a Cursor Cloud
+environment, and it can also be invoked explicitly. Use
+`oat-project-autonomous` separately when the user explicitly requests an
+end-to-end autonomous run; being in Cursor Cloud does not activate autonomy by
+itself.
+
+## Resolve the project home first
+
+All tracked project artifacts belong to a repository, not to the workspace
+container or user home.
+
+### Multi-repository workspace
+
+1. Identify the **primary repository** whose branch, commits, and final PR own
+   the requested work.
+2. Run OAT from that repository root.
+3. Keep the project under that repository's configured projects root, normally
+   `<primary-repo>/.oat/projects/shared/<project>/`.
+4. Keep checkout-specific state such as `activeProject` in the primary
+   repository's `.oat/config.local.json`.
+5. Treat sibling repositories as research or integration context unless the
+   approved plan explicitly assigns them work. Do not create a workspace-level
+   `.oat` directory to coordinate multiple repositories.
+
+For cross-repository work, choose one primary repository as the artifact and
+provenance anchor. Record external repository assumptions and evidence in its
+project artifacts rather than splitting one OAT project across unrelated
+workspace roots.
+
+### Single-repository workspace
+
+The checked-out repository is the project home. Run OAT at its root and use its
+`.oat/` tree exactly as in a local checkout. Do not introduce multi-repository
+path assumptions.
+
+In both layouts, never store tracked projects under `~/.oat/projects`, a
+workspace aggregator such as `/workspace/.oat`, or another repository merely
+because it also contains OAT assets.
+
+## Orientation and cloud detection
+
+The orientation skill confirms cloud context from environment markers and,
+when available, Cursor Cloud run metadata. Run metadata is also the preferred
+source for the current model family; model self-report is not dispatch
+evidence.
+
+If cloud metadata is unavailable, the skill degrades to verified environment
+signals and reports the missing evidence. It does not invent run identity or
+block repository-local OAT work that otherwise has the required tooling.
+
+## Provisioning expectations
+
+A ready cloud environment provides:
+
+- the latest published OAT CLI on `PATH`;
+- OAT packs and skills installed at user scope;
+- user-level `~/.oat/config.json` defaults for the dispatch candidate ladder
+  and gate execution targets, with availability probes;
+- `cursor-agent` installed for configured headless routes;
+- headless authentication supplied from a Cloud Agents secret;
+- repository-local config overrides only where a specific repository needs
+  cloud behavior that differs from its shared config.
+
+Provisioning must be idempotent and must not require an
+`open-agent-toolkit` source checkout. A practical readiness pass verifies at
+least:
+
+```bash
+oat --version
+oat config dump
+cursor-agent --version
+```
+
+It also verifies that required user-scope packs are present, configured gate
+targets resolve or degrade through their availability probes, and the harness
+auth probe succeeds. A missing optional gate CLI may permit a documented
+degraded route. A required route with no adequate fallback is a boundary.
+
+Secrets stay in the environment or the platform's secret broker. Never write
+`CURSOR_API_KEY` or another credential into OAT config, project artifacts,
+dispatch records, prompts, logs, or the VM image.
+
+## User-scope asset precedence
+
+In provisioned cloud environments, the user-scope installation is the execution
+source for every OAT asset class: skills, templates, and scripts. The user tier
+is refreshed from the published package during environment setup; repository
+copies are compatibility context, not an override.
+
+For skills, compare frontmatter versions as a freshness check:
+
+- user version at or above the repository version is the expected state;
+- a higher repository version is an environment anomaly;
+- even in that anomaly, keep the user copy as the execution source, log the
+  mismatch in `oat-execution-learnings.md`, and refresh the user tier before
+  safety-critical work.
+
+Version comparison verifies provisioning. It never switches execution to the
+repository copy.
+
+## Cursor execution surfaces
+
+Cursor Cloud native subagents, Cursor IDE subagents, the Cursor CLI subagent
+enum, and the Cursor CLI full model catalog are separate dispatch surfaces.
+Each can expose a differently named subset.
+
+Snapshot the catalog for the surface being used before dispatch. Do not infer
+that a model available to a native cloud task is available to `cursor-agent`,
+or the reverse. The dispatch substrate owns route mechanics and records the
+selected surface, exact configured model string, selection reason, and accepted
+launch. See [Programmatic Execution](programmatic-execution.md) and
+[Orchestration Model](orchestration-model.md).
+
+## Autonomous runs
+
+For an explicitly autonomous cloud run:
+
+1. Resolve the primary repository and project home.
+2. Verify the provisioned OAT and Cursor surfaces.
+3. Invoke `oat-project-autonomous`; it activates the session-scoped autonomy
+   signals.
+4. Use the same policy boundaries and review contract as local autonomy.
+5. Append cloud setup gaps, degraded checks, and freshness anomalies to the
+   project-local execution-learnings log.
+
+Missing credentials, repository-policy approval, destructive changes,
+unresolved blocking reviews, and material product ambiguity remain boundaries.
+See [Autonomous Project Execution](autonomy.md).
+
+## Related
+
+- [Autonomous Project Execution](autonomy.md) — activation, boundaries, review,
+  and learnings.
+- [Programmatic Execution](programmatic-execution.md) — Cursor CLI and native
+  execution surfaces.
+- [Dispatch Policy](dispatch-ceiling.md) — candidate ladders and exact route
+  selection.
+- [Configuration](../../cli-utilities/configuration.md) — user, shared, and
+  repository-local config ownership.

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

@@ -12,6 +12,8 @@ Projects are where the workflow layer becomes concrete: lifecycle phases, `state
 ## Contents
 
 - [Lifecycle](lifecycle.md) - End-to-end flow from discovery through completion.
+- [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.
 - [HiLL Checkpoints](hill-checkpoints.md) - Human-in-the-Loop Lifecycle configuration and approval behavior.
 - [Dispatch Policy](dispatch-ceiling.md) - Managed capped tiers, managed Uncapped, Inherit Host Defaults, and provider-specific enforcement.
@@ -34,6 +36,8 @@ This sub-section is the deep technical surface for how tracked OAT projects exec
 ## Start Here
 
 - Start with [Lifecycle](lifecycle.md) for the end-to-end flow.
+- Use [Autonomous Project Execution](autonomy.md) for unattended lifecycle runs and defined boundary behavior.
+- Read [OAT in Cursor Cloud](cursor-cloud.md) before running OAT in a cloud workspace.
 - Read [Artifacts](artifacts.md) once you need the file contract behind project execution.
 - Use [Project Splitting](splitting.md) when one discovery or brainstorm should become coordinated child projects.
 - Use [HiLL Checkpoints](hill-checkpoints.md) when you want to understand pause/approval behavior.
@@ -49,6 +53,8 @@ This sub-section is the deep technical surface for how tracked OAT projects exec
 ## Go Deeper
 
 - [Lifecycle](lifecycle.md) - End-to-end flow from discovery through completion.
+- [Autonomous Project Execution](autonomy.md) - Session activation, gate outcomes, independent review, HiLL closeout, and learnings synthesis.
+- [OAT in Cursor Cloud](cursor-cloud.md) - Repository anchoring, environment readiness, user-scope assets, and Cursor execution surfaces.
 - [Design Modes](design-modes.md) - How full design balances collaborative, selective collaborative, and draft-and-review interaction.
 - [HiLL Checkpoints](hill-checkpoints.md) - Human-in-the-Loop Lifecycle configuration and approval behavior.
 - [Dispatch Policy](dispatch-ceiling.md) - Managed capped tiers, managed Uncapped, Inherit Host Defaults, legacy dispatch-ceiling compatibility, and provider-specific enforcement.

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.1.60",
-  "docs-config": "0.1.60",
-  "docs-theme": "0.1.60",
-  "docs-transforms": "0.1.60"
+  "cli": "0.1.63",
+  "docs-config": "0.1.63",
+  "docs-theme": "0.1.63",
+  "docs-transforms": "0.1.63"
 }