diff --git a/.github/workflows/publish-crates.yml b/.github/workflows/publish-crates.yml index 2f690c6..4c38ec5 100644 --- a/.github/workflows/publish-crates.yml +++ b/.github/workflows/publish-crates.yml @@ -48,7 +48,7 @@ jobs: - name: Mint a short-lived crates.io token id: crates - uses: rust-lang/crates-io-auth-action@82864bf380abd3e242c564a5ba58dd29d6265b00 + uses: rust-lang/crates-io-auth-action@c6f97d42243bad5fab37ca0427f495c86d5b1a18 # v1.0.5 - name: Publish cursor-setup-system env: diff --git a/CHANGELOG.md b/CHANGELOG.md index fc66b25..73daf34 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,17 @@ cut and that this clone does not carry. ## [Unreleased] +## [0.0.67] - 2026-09-07 + +nddev-builder creates complete native tool collections: select and author +components, compose exact setups across declared roots, document capabilities, +and verify installation, native invocation and recovery. Provider maintenance +checks are separate from ordinary setup authoring. The toolkit includes the +consumer's exact digest-approval steps and preserves the active environment. +Product artifacts are refreshed from verified vendor bytes, with previous +pins retained for rollback. Release authentication uses the tagged upstream +action release. + ## [0.0.66] - 2026-09-07 Reset is an optional protocol operation: it empties declared native diff --git a/Cargo.lock b/Cargo.lock index 77688df..ec6a616 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -49,7 +49,7 @@ dependencies = [ [[package]] name = "cursor-setup-system" -version = "0.0.66" +version = "0.0.67" dependencies = [ "harness-runtime", "provider-v3", @@ -76,7 +76,7 @@ checksum = "877a4ace8713b0bcf2a4e7eec82529c029f1d0619886d18145fea96c3ffe5c0f" [[package]] name = "harness-runtime" -version = "0.0.66" +version = "0.0.67" dependencies = [ "provider-v3", "serde", @@ -147,7 +147,7 @@ dependencies = [ [[package]] name = "provider-v3" -version = "0.0.66" +version = "0.0.67" dependencies = [ "serde", "serde_json", @@ -209,7 +209,7 @@ dependencies = [ [[package]] name = "setup-core" -version = "0.0.66" +version = "0.0.67" dependencies = [ "miniz_oxide", "serde", diff --git a/Cargo.toml b/Cargo.toml index ac3857f..70b36c2 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -8,7 +8,7 @@ members = [ ] [workspace.package] -version = "0.0.66" +version = "0.0.67" edition = "2024" rust-version = "1.89" license = "AGPL-3.0-or-later" @@ -23,9 +23,9 @@ sha2 = "0.11" # `setup-core::archive`); an inflate loop is not, because its bugs are # memory-safety bugs and it is not improved by being hand-written here. miniz_oxide = "0.9" -setup-core = { path = "crates/setup-core", version = "0.0.66" } -provider-v3 = { path = "crates/provider-v3", version = "0.0.66" } -harness-runtime = { path = "crates/harness-runtime", version = "0.0.66" } +setup-core = { path = "crates/setup-core", version = "0.0.67" } +provider-v3 = { path = "crates/provider-v3", version = "0.0.67" } +harness-runtime = { path = "crates/harness-runtime", version = "0.0.67" } [workspace.lints.rust] unsafe_code = "forbid" diff --git a/README.md b/README.md index b96a661..1f40d78 100644 --- a/README.md +++ b/README.md @@ -179,7 +179,7 @@ release is a convenience, not the authorised copy. ```bash docker run --rm -v "$HOME/.config:/config" \ - ghcr.io/nddev-opennetwork/cursor-setup-system:0.0.66 \ + ghcr.io/nddev-opennetwork/cursor-setup-system:0.0.67 \ status --target /config/ --json ``` diff --git a/install.ps1 b/install.ps1 index 21827a6..82d2658 100644 --- a/install.ps1 +++ b/install.ps1 @@ -7,7 +7,7 @@ # powershell -ExecutionPolicy Bypass -File install.ps1 -Version 0.1.0 [CmdletBinding()] param( - [string]$Version = "0.0.66", + [string]$Version = "0.0.67", [string]$InstallDir = "$env:LOCALAPPDATA\Programs\cursor-setup-system" ) $ErrorActionPreference = "Stop" diff --git a/install.sh b/install.sh index 7551204..7bfe1be 100644 --- a/install.sh +++ b/install.sh @@ -14,7 +14,7 @@ set -eu REPO="NDDev-OpenNetwork/cursor-setup-system" BINARY="cursor-setup-system" -VERSION="${1:-0.0.66}" +VERSION="${1:-0.0.67}" PREFIX="${CURSOR_INSTALL_DIR:-$HOME/.local/bin}" case "$(uname -s)" in diff --git a/references/cursor-baseline.json b/references/cursor-baseline.json index 10d5db0..2cf057a 100644 --- a/references/cursor-baseline.json +++ b/references/cursor-baseline.json @@ -173,7 +173,7 @@ "product_projection": "observed-by-manager" } }, - "verified_at": "2026-09-03T14:16:54+00:00", + "verified_at": "2026-09-07T03:18:13+00:00", "native_surfaces": { "verified_at": "2026-08-31", "config_home": "~/.cursor", @@ -480,7 +480,7 @@ } }, "version": "2026.09.02-c22c1a3", - "verified_at": "2026-09-03T14:16:54+00:00" + "verified_at": "2026-09-07T03:18:13+00:00" }, "previous_software_artifacts": { "command": "agent", @@ -528,7 +528,7 @@ "version": "2026.08.31-4057e58", "verified_at": "2026-09-02T00:41:54+00:00" }, - "setup_catalogue_digest": "sha256:51067fdc2870f178e31418e12d6ed022237da190a4be6433713ec5277ab3fb2a", + "setup_catalogue_digest": "sha256:2339c03bbb648890de5d7f15aaa8e8a7ba262f38ae5d5e9179f127e0833ea9a6", "previous_pin_recovery": { "measured_at": "2026-08-31", "note": "The vendor exposes no release index, but this repository had already measured the immediately preceding release before the pin moved: exact version plus the four Unix URLs, lengths and digests. All six derived immutable URLs still answer; the two Windows archives were downloaded and hashed now, and their command-script members were read from the ZIPs. This is recovered measurement, not a second independently moving pin, and the next ordinary refresh replaces it through the same outgoing-current rotation as every other harness." diff --git a/setups/nddev-builder/home/plugins/local/nddev-builder/agents/nddev-builder.md b/setups/nddev-builder/home/plugins/local/nddev-builder/agents/nddev-builder.md index fac28af..3d9855c 100644 --- a/setups/nddev-builder/home/plugins/local/nddev-builder/agents/nddev-builder.md +++ b/setups/nddev-builder/home/plugins/local/nddev-builder/agents/nddev-builder.md @@ -1,11 +1,34 @@ --- name: nddev-builder -description: Reviews NDDev Cursor CLI setup changes for lifecycle, safety, and native projection correctness. +description: Build or review a complete native Cursor tool collection, including component selection, setup composition, capabilities and recovery. --- -Review setup system changes for explicit target handling, backup and restore -binding, rollback behaviour, symbolic-link rejection, and native Cursor -projection through plugin rules, skills, agents and commands. Check that a -posture is a setup rather than a second axis crossing one, and that a target -still carrying the frozen estate's stamp is taken over by `adopt` -- a command -someone types -- rather than by an install acting behind them. +Build or review a complete setup for the harness served by +`cursor-setup-system`: a native collection of tools for the user's tasks. +Work on the explicitly delegated authoring tree, components and setup graph. +Do not assume the user is developing the provider itself. Prefer existing +components, fill demonstrated gaps, explain capabilities, and validate native +discovery, installation and recovery in disposable targets. + +Return the setup location, component/capability inventory, exact versions and +digests, invocation examples, checks run and remaining evidence gaps. Stay +within delegated paths and authority. Do not mutate a live configuration or +publish merely because an authoring task mentioned those later lifecycle steps. + +Hold to these, in this order: + +1. **Measure before declaring.** Run the product, read its own bytes, and only + then read its pages. Where the two disagree the product wins, and both get + written down. +2. **Every declared path cites its source.** In a provider implementation + checkout, use `references/-baseline.json`. An installed toolkit + uses its routed or inline references and `provider-info`; it does not assume + that the provider source checkout is available. An unsourced row comes out. +3. **Every declared kind is a promise of a rollback.** Declaring one the product + cannot route is a promise nothing can keep. +4. **Never weaken a check to buy green.** Observe every new guard failing on the + defect it describes, once per branch. +5. **Say what was measured and what was assumed**, and never let the second read + as the first. + +Start from `skills/nddev-builder/SKILL.md` in this plugin. Use its ai-stp lifecycle workflow and native reference routes. diff --git a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/SKILL.md b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/SKILL.md index 2c41fc2..1a21f7c 100644 --- a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/SKILL.md +++ b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/SKILL.md @@ -1,12 +1,13 @@ --- name: nddev-builder -description: Build, review, or validate a Cursor CLI setup: permissions, lifecycle, plugins, rules, skills, agents, commands, MCP and release surfaces. Use when changing or checking cursor-setup-system behaviour or the native Cursor artifacts a setup carries. +description: Create, improve or review a complete Cursor CLI setup -- a native collection of tools. Use to select and author components, compose exact setups, explain capabilities, and validate native placement, installation and recovery. --- # NDDev Builder -Use this skill as the entry point for `cursor-setup-system` work. Keep edits -target-explicit, reversible, and backed by this tree's checks. +Start with `references/ai-stp-lifecycle.md` to turn the user's tasks into a complete setup: inventory components, fill capability gaps, compose, evaluate and deliver a usable tool collection. + +Read the native references below for this harness's formats and activation rules. Provider implementation changes use the additional provider checks; ordinary setup authoring needs no Rust checkout. ## Workflow @@ -34,8 +35,7 @@ target-explicit, reversible, and backed by this tree's checks. cross-harness half of it is the part no vendor page carries. - **The instruction file, and which products read a neighbour's**: read `references/authoring-instructions.md`. Also generated. -- **The second target this harness owns, and why a setup cannot carry a - component for it**: read `references/second-target.md`. Generated from the +- **Additional roots this harness owns and how a setup coordinates them**: read `references/second-target.md`. Generated from the baseline's scoped block. - **Configuration and setup/profile model**: read `references/configuration-profiles.md`. @@ -63,10 +63,11 @@ target-explicit, reversible, and backed by this tree's checks. ## Boundaries -- Do not write private harness artifacts or live user configuration from this - public toolkit. -- Do not install software, start MCP servers, activate hooks, approve MCPs, push, - tag, or mutate team marketplace state. +- Validate with disposable homes, prefixes and targets. Exercise native + activation only for the components and accounts authorized by the task. +- Publishing or applying to a live target requires that effect in the task; + authoring alone does not imply it. Use the exact provider lifecycle and + preserve the running agent's own active configuration. - A target the frozen estate still stamps is taken over by `adopt`, which is a command someone types and never something `install` does behind them. Nothing is deleted: the old stamp moves aside and the pre-adoption state is one `mv` diff --git a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/ai-stp-lifecycle.md b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/ai-stp-lifecycle.md index e658e0e..b5e235a 100644 --- a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/ai-stp-lifecycle.md +++ b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/ai-stp-lifecycle.md @@ -1,34 +1,104 @@ -# The ai-stp CLI lifecycle - -Native install, select and restore of this provider are the lifecycle section -of this toolkit. This page is the consumer path: author a component, compose a -setup, install it, read it back, release an immutable version, and request -publication. - -Resolve every flag from `ai-stp help --agent --json`. Do not invent options. -Start with `ai-stp doctor --json`. - -## Exercise from a blank authoring directory - -1. **Scaffold** a real skill with `ai-stp component scaffold plan` then - `ai-stp component scaffold apply`. Replace every draft marker before - compose or release. -2. **Passport.** `ai-stp component passport validate` and - `ai-stp component skill validate` on the package directory (the directory - with `SKILL.md` at its root), not the whole tree. -3. **Harness semantics.** This harness's surfaces table says where the kind - lands. Do not invent a path the declaration does not carry. Adaptations are - those native files, not a second copy of the passport. -4. **Compose a setup.** `ai-stp select propose` then `ai-stp select confirm`, - or `ai-stp setup compose plan`. Confirm only the proposal just returned. -5. **Install and read back.** `ai-stp install plan`, then `ai-stp install apply` - with that plan's digest, then `ai-stp target status` with the same provider. - Trust `pending_authorization`, not the apply exit code. -6. **Immutable release.** `ai-stp component version release`. -7. **Requested publication.** `ai-stp component publish` or - `ai-stp setup publish plan`. Publicity is a separate user decision. - -## What this page does not name - -- Private authoring gates, repository coordinates, or unpublished tools. -- Flags other than `ai-stp doctor --json` and `ai-stp help --agent --json`. +# Build a complete setup with ai-stp + +A setup is a complete configuration of one chosen harness: a working collection +of tools for a user outcome. It is more than one plugin or a set of unrelated +files. Use this workflow to create a new setup, improve an existing collection, +or recast it for another harness. Provider development is a separate task. + +Start with `ai-stp doctor --json` and resolve command arguments from +`ai-stp help --agent --json` in the installed consumer. Do not invent options or +assume a newer development command is available in a released CLI. + +## 1. Define the outcome and inspect existing tools + +Record the intended tasks, chosen harness, operating systems, installation +scopes and the user's existing authority. Name concrete acceptance scenarios, +such as building a tested application, reviewing a change, or maintaining an +MCP integration. Inspect the explicitly named authoring directories with +`ai-stp component inventory`; use `ai-stp component discover` for native +configuration. Discovery does not adopt files or establish ownership. + +Build a capability inventory: the outcome each component enables, its source, +exact version, native entry point, scope, dependencies, external accounts, +activation needs and evidence. Reuse a suitable existing component before +creating another. Explain overlap and omitted capabilities. Choose only the +tools the intended tasks need; a large file count is not completeness. + +## 2. Author native components + +Use `ai-stp setup scaffold plan` / `ai-stp setup scaffold apply` for a complete +authoring tree, or `ai-stp component scaffold plan` / `ai-stp component scaffold apply` for a missing member. Replace every draft marker with useful content. +Keep authored sources and generated harness projections distinct. + +Read this harness's surfaces and per-kind references before choosing paths or +keys. Put durable context in instructions, repeatable procedures in skills, +external tool connections in MCP, lifecycle callbacks in hooks, and narrowly +scoped delegation in native agents where supported. A plugin packages the +capabilities its own harness supports; it is not itself the whole setup. +Shared executables use the consumer's `cli` component lifecycle and are not +slash commands. Do not create a new component kind for a descriptive category. + +Use `ai-stp component passport validate` for metadata and +`ai-stp component skill validate` for a skill package. Validate the native file +format and demonstrate discovery in the actual product separately. Passing a +parser does not prove the harness discovers, trusts or executes the component. +Keep credential values out of the artifact; document only required variable +names or the product's account connection procedure. + +## 3. Compose one exact graph + +Freeze authored components with `ai-stp component version release`. Compose +exact sources through `ai-stp setup compose plan` / `ai-stp setup compose apply`, +or select registered components through `ai-stp select propose` / +`ai-stp select confirm`. Apply the exact returned plan, after revalidating its +preconditions. Inspect dependency closure, path and key conflicts, scope +compatibility, executable prerequisites and conversion losses with the +consumer's graph and report commands. Resolve conflicts before installation. + +A setup stays bound to one harness. To derive another, use `ai-stp setup recast plan` / `ai-stp setup recast apply`; inspect the destination's native files, +semantic losses and provenance. Do not relabel the original or copy one +harness's config into another. A shared instruction or skill format does not +make permissions, hooks, agents or plugin manifests interchangeable. + +## 4. Prove the collection works + +Use `ai-stp eval plan` / `ai-stp eval run` for the setup's own adaptations, and +`ai-stp eval component plan` / `ai-stp eval component run` when evaluating all +adaptations of a component. Local static evaluation is not a security scan or +an authenticated product run; retain those evidence distinctions. + +Build and review the exact bundle. For a single scope use `ai-stp install plan`, +`ai-stp install approve` with the returned digest, then `ai-stp install apply`. +For a setup spanning roots use `ai-stp install transaction plan`, +`ai-stp install transaction approve`, and its matching apply/recovery commands. +These approval commands record the exact effect already authorized by the +task; they do not require another user question for that same effect. +Exercise this first +in disposable homes, targets and prefixes. Read `ai-stp target status`, diff +and backups; an exit code alone is not a verified effect. Preserve any pending +authorization, refusal or unknown outcome as such and follow its recovery +path. Demonstrate restore and verify that pre-existing files survive. + +Run each acceptance scenario through the real harness, including one implicit +and one explicit invocation where supported. Check missing dependencies and +conflicting components as well as the happy path. Record the exact harness, +provider and consumer versions, OS/architecture, artifact digests and results. +An unavailable credential or platform is unmeasured, never a passing cell. + +## 5. Deliver a usable setup + +Write a concise setup guide with its purpose, supported tasks, component and +capability inventory, native activation/invocation examples, required accounts, +scope, compatibility, evidence limits, update path and backup/restore path. +Separate built-in harness features from features supplied by this setup. +Use current vendor documentation and the measured product version; cite the +source for a feature claim instead of promising parity across harnesses. + +Use `ai-stp setup export` for a reviewable tree. For a requested publication, +use `ai-stp component publish` or `ai-stp setup publish plan` followed by +`ai-stp setup publish confirm` on the reviewed exact set. Preserve immutable +versions. Task authority is separate from verification; changing an existing +object's visibility or access rights needs the user's decision. Report what +was created, where it is, how to invoke it, what passed and what remains +unmeasured. Deliver authoring artifacts without modifying the running agent's +own active configuration. diff --git a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/second-target.md b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/second-target.md index 47fbef1..9a256bd 100644 --- a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/second-target.md +++ b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/second-target.md @@ -26,12 +26,13 @@ The one root in this estate that belongs to a convention rather than to a produc Relative to this scope's own root the path is `skills`, not `.agents/skills`: the root is what the scope names, and writing it into the path again would put the skills at `~/.agents/.agents/skills`. -**A setup cannot carry one of these.** A setup is installed into one -target and its payload is relative to that target, so a component -for this scope is installed by the consumer against that root -- not -by a setup aimed at the configuration home. If you are looking for -where to put one by hand, it is the path above joined to the root -above, and nowhere under the home. +**A complete setup may include these scoped components.** Each +provider request still reaches one root. The consumer coordinates +the roots with `ai-stp install transaction plan`, exact digest +approval, apply and recovery. A shipped configuration-home preset +cannot reach this root by nesting a path inside its home payload. +Declare the component's actual scope and bind the matching root +explicitly in the transaction. **The root is shared, and that changes what removal means.** Several products read it. Under this scope `remove`, the backup and a @@ -80,12 +81,13 @@ The hooks path table (member `190.index.js`) names four tiers: `enterpriseConfig The skill-root table's first row `{configDir: ".cursor", subdir: "skills", thirdParty: false}` is joined to each workspace path by `Hr(e, t)` with `scope: "project", source: "workspace"`, the same table the home read maps through `Yr` with `scope: "user"`. measured 2026-09-02 in the 2026.08.31-4057e58 linux/x64 bundle (sha256:7e306db5..., digest verified against the artifact table before reading), every one of the package's 137 JavaScript members and not only `index.js`. -**A setup cannot carry one of these.** A setup is installed into one -target and its payload is relative to that target, so a component -for this scope is installed by the consumer against that root -- not -by a setup aimed at the configuration home. If you are looking for -where to put one by hand, it is the path above joined to the root -above, and nowhere under the home. +**A complete setup may include these scoped components.** Each +provider request still reaches one root. The consumer coordinates +the roots with `ai-stp install transaction plan`, exact digest +approval, apply and recovery. A shipped configuration-home preset +cannot reach this root by nesting a path inside its home payload. +Declare the component's actual scope and bind the matching root +explicitly in the transaction. **The root is shared, and that changes what removal means.** Several products read it. Under this scope `remove`, the backup and a diff --git a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/validation-release.md b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/validation-release.md index 5e4a949..dba36da 100644 --- a/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/validation-release.md +++ b/setups/nddev-builder/home/plugins/local/nddev-builder/skills/nddev-builder/references/validation-release.md @@ -1,9 +1,10 @@ -# Validation Before Handing Off +# Before Handing Off -Use this reference before handing off work on a setup system. +For setup authoring, run the component validators, composition/evaluation and +disposable product scenarios described in the ai-stp lifecycle guidance. A +setup containing Python tools does not require a Rust provider checkout. -Run the checks this tree's CI runs, in order, and report what each one said -rather than that it passed. +When changing provider implementation, run that checkout's CI checks: ```bash cargo fmt --all --check @@ -11,7 +12,8 @@ cargo clippy --workspace --all-targets -- -D warnings cargo test --workspace ``` -If a command here is not present, say so rather than working around it. +Report each result and any unavailable check. The cargo commands apply only +to the provider implementation workspace. ## A lifecycle smoke test against a disposable target @@ -36,19 +38,44 @@ before anyone types it. ## Conformance against the consumer -The wire surface is checked by the consumer's own runner, not by anything here: +Use this additional check when changing or qualifying the provider itself. +The wire surface is checked by the consumer's own runner, not by anything here. +Ask `cursor-setup-system provider-info` for `harness_id`; that is the value +`--harness` takes, and it is not always the directory name. ```bash -ai-stp provider conformance --harness cursor \ - --executable target/release/cursor-setup-system \ +ai-stp provider conformance --harness \ + --executable \ --target --protocol-version 3 --json ``` -An empty target and a populated one are different questions. A defect that only -appears against a real home is the kind this project has already shipped. +Report the verdict with the consumer version that gave it. An empty target and a +populated one are different questions. A defect that only appears against a real +home is the kind this project has already shipped. -## What this toolkit does not do +## The rule that does not move -- It does not push, tag, or release. -- It does not write a live configuration home. -- It does not install software or start a product. +Never weaken an invariant, raise a threshold, silence a check or delete a test +to buy green. + +Every new guard is observed **failing on the defect it describes** before it is +kept -- and once per branch, not once per guard. A guard whose test has never +been red proves nothing, and this estate has twice found a new guard's first +test passing under a mutation because every case it named exercised the same +branch. + +## Classifying a finding is not silencing it + +A false positive dismissed with its reasoning recorded is correct. Rewriting +code until a checker goes quiet is not. The difference is whether the change +stands on its own merits: if the code was worse for a reason that has nothing to +do with the checker, fix it; if it was not, dismiss the finding and say why. + +## Task scope and disposable verification + +Authoring includes creating files and running the required checks in disposable +homes, targets and prefixes. Installing verified prerequisites and launching a +product there are valid validation steps. Keep credentials and live state out +of those copies. Publishing or applying to a user's live target happens only +when the task includes that effect, through the exact reviewed lifecycle. +Never change the running agent's active configuration in place. diff --git a/setups/nddev-builder/setup.json b/setups/nddev-builder/setup.json index 8ebe89b..85c9649 100644 --- a/setups/nddev-builder/setup.json +++ b/setups/nddev-builder/setup.json @@ -1,7 +1,7 @@ { "schema_version": 1, "id": "nddev-builder", - "description": "The native Cursor full-auto posture plus the NDDev builder plugin: autonomous implementation with product-native rules, skills, agents, commands, MCP guidance, lifecycle checks and release handoff.", + "description": "Build complete native tool collections: select and author components, compose exact setups, document capabilities, and verify installation and recovery with ai-stp.", "sources": [ "https://cursor.com/docs/cli/reference/configuration", "https://cursor.com/docs/cli/reference/permissions",