@open-agent-toolkit/cli 0.1.62 → 0.1.64

package/assets/agents/oat-phase-implementer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-phase-implementer
-version: 1.0.7
+version: 1.0.8
 description: Implements one plan phase end-to-end, commits each task separately, self-checks between tasks, and handles bounded review fixes when resumed by oat-project-implement.
 tools: Read, Write, Edit, Bash, Grep, Glob, Task
 color: cyan
@@ -90,6 +90,14 @@ Read each required artifact once at phase start:
 Extract all phase tasks, dependency order, file boundaries, verification
 commands, commit messages, and phase-wide verification before editing.
 
+## 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 the repository's applicable gate set over the produced
+diff, explicitly including artifact writes. This supplements rather than
+replaces every task and phase verification command below.
+
 ## Mode: Implement
 
 ### 1. Verify Phase Base

package/assets/agents/oat-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-reviewer
-version: 1.1.6
+version: 1.1.7
 description: Unified reviewer for OAT projects - mode-aware verification of requirements/design alignment and code quality. Writes a review artifact to disk by default, or returns structured findings in-memory when dispatched in structured-output mode.
 tools: Read, Bash, Grep, Glob, Write
 color: yellow
@@ -84,6 +84,13 @@ Use workflow mode to determine required evidence:
 Do not mark missing optional artifacts as findings.
 If required artifacts for the mode are unexpectedly missing, record a workflow contract gap.
 
+## 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 prose artifact does not imply unrelated full test suites.
+
 ## Process
 
 ### Step 1: Load Artifacts

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

@@ -150,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
@@ -173,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
@@ -202,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/contributing/skills.md

@@ -56,6 +56,28 @@ Skill behavior is defined by frontmatter plus the process contract in each `SKIL
 - Keep `AGENTS.md` skills table synchronized with `.agents/skills`.
 - Require explicit user approval for destructive or state-advancing transitions.
 
+### Artifact-writing hygiene
+
+Every role or skill that creates or edits tracked output must include the
+artifact hygiene contract at its writing boundary. The writer uses a concrete
+write/fix formatting command supplied by its plan, task, or brief. If none is
+usable, it discovers the repository's documented command from applicable
+`AGENTS.md` / `CLAUDE.md` instructions and relevant package manifests.
+
+Contracts must distinguish write/fix commands from check-only commands, prefer
+a file-scoped invocation when supported, avoid unrelated whole-tree rewrites,
+and never infer or hardcode a formatter. If no command can be discovered, the
+writer warns once with
+`no format command discovered in repo instructions; skipping` and continues.
+Run only verification relevant to the changed files unless the role's
+definition of done requires broader gates.
+
+For planned implementation, plan-producing skills resolve this command once and
+place it in every artifact-writing task. Runtime discovery remains the fallback
+for direct lifecycle writers and incomplete or stale plans. When the same
+contract crosses dispatch boundaries, keep each copy self-contained and protect
+equivalence with contract tests.
+
 ## Recommended Starting Points
 
 - Use `create-oat-skill` when the new skill belongs to an OAT lifecycle or maintenance flow.

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

@@ -57,6 +57,36 @@ Manual and auto review artifacts do not require the gate-only fields.
 
 Artifacts are the project system of record; automation and routing should derive from these files, not memory.
 
+### Formatting and verification hygiene
+
+Tracked artifacts are part of the repository diff, so artifact writers format
+them before finishing or committing. During plan authoring, OAT resolves the
+repository's documented write/fix command from applicable `AGENTS.md` /
+`CLAUDE.md` instructions and relevant package manifests. Each task that writes
+an artifact receives a concrete invocation, scoped to that task's files when
+the command supports paths.
+
+Downstream implementers execute that supplied command without repeating
+discovery. Roles and lifecycle skills that write outside a planned task,
+including reviewers and documentation, summary, PR, and quick-start flows, use
+the same discovery procedure as a fallback. Gate-originated review prompts also
+carry the contract so review artifacts follow the same rule across runtimes.
+
+Writers must:
+
+- prefer a documented write/fix command over a check-only command;
+- avoid inferring or hardcoding a formatter;
+- scope the write to created or edited files when supported;
+- avoid whole-tree rewrites that could absorb unrelated changes; and
+- warn once with
+  `no format command discovered in repo instructions; skipping` when no command
+  is discoverable, then continue.
+
+Formatting supplements the applicable verification contract. Phase
+implementation runs repository gates over its produced diff, including
+artifact writes. Prose-only lifecycle work runs only checks relevant to the
+files it changed.
+
 ## Coordination parents
 
 Project splitting introduces a coordination-only parent artifact. It records shared context and child relationships, but it is not an executable lifecycle project.

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/dispatch-ceiling.md

@@ -64,6 +64,19 @@ existing cells. Planning shows the complete recommendation before asking which
 scope should own it. If the resulting ladder is still missing or incomplete,
 planning remains blocked rather than replacing the user's explicit values.
 
+Before offering adoption, planning runs `oat config list --json` once and treats
+its output as the effective boundary across shared, repo-local, user, and
+bundled-default precedence. A complete effective ladder skips adoption even
+when the current project has not selected a policy or named ceiling. Adoption
+is offered only when the resolved provider/tier cells are actually missing,
+empty, malformed, or incomplete.
+
+Ladder completeness and project-ceiling selection are separate checks. In
+particular, `oat project dispatch-ceiling resolve` returning `matrix: null` can
+mean that the project policy or ceiling is unresolved; it does not prove that
+the effective reusable ladders are absent. When ladders are complete, planning
+proceeds directly to the project-specific policy choice.
+
 The ownership boundary is deliberate:
 
 | Source                                     | Config location                | Codex materialization output          |

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.62",
-  "docs-config": "0.1.62",
-  "docs-theme": "0.1.62",
-  "docs-transforms": "0.1.62"
+  "cli": "0.1.64",
+  "docs-config": "0.1.64",
+  "docs-theme": "0.1.64",
+  "docs-transforms": "0.1.64"
 }