NDDev-OpenNetwork · rldyourmnd · Sep 7, 2026 · Sep 7, 2026
@@ -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:

@@ -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

@@ -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"

@@ -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/<dir> --json
 ```
 

@@ -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"

@@ -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

@@ -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."

@@ -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/<harness>-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.
@@ -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`

@@ -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.