docs(openspec): archive Cargo and release resolver changes

openspec/specs/agent-catalog/spec.md

@@ -321,3 +321,26 @@ Quantex SHALL include VTCode in the supported agent catalog with lifecycle-focus
 - **WHEN** Quantex plans an update for a VTCode installation that supports the built-in updater
 - **THEN** the catalog exposes `vtcode update` as the agent self-update command
 
+### Requirement: Cargo install methods MUST be supported lifecycle metadata
+
+Quantex SHALL allow supported agent catalog entries to declare Cargo-managed install methods and crate package metadata when an upstream agent is distributed as a Rust crate.
+
+#### Scenario: Registering Cargo package metadata
+
+- **WHEN** Quantex defines or updates a supported agent entry that is distributed as a Rust crate
+- **THEN** the entry can identify the crate through `packages.cargo`
+- **AND** the entry can include Cargo managed install methods on platforms where the crate is supported
+- **AND** Cargo package metadata is treated as lifecycle metadata, not descriptive marketing copy
+
+#### Scenario: Rendering Cargo install guidance
+
+- **WHEN** Quantex renders install methods for an agent with a Cargo managed install method
+- **THEN** the install method is labeled as a managed Cargo install
+- **AND** the command guidance uses `cargo install <crate>`
+
+#### Scenario: Registering DeepSeek TUI Cargo metadata
+
+- **WHEN** Quantex defines the supported DeepSeek TUI agent entry
+- **THEN** the entry identifies `deepseek-tui-cli` as Cargo package metadata
+- **AND** the Cargo install method includes the upstream-documented `--locked` argument
+- **AND** the entry continues to identify `deepseek-tui` as npm package metadata

openspec/specs/agent-update/spec.md

@@ -182,3 +182,28 @@ The supported agent catalog SHALL expose verified canonical names, lookup aliase
 - **THEN** Quantex resolves the same catalog entry
 - **AND** lifecycle commands operate on that agent without requiring a separate duplicate definition
 
+### Requirement: Cargo-managed agent lifecycle MUST use Cargo commands
+
+Cargo-managed agent lifecycle operations SHALL install, update, batch update, uninstall, and diagnose agents through the Cargo installer when the recorded or selected install source is Cargo.
+
+#### Scenario: Updating Cargo-managed agents
+
+- **GIVEN** an agent has recorded install state with install type `cargo`
+- **WHEN** the user runs `quantex update <agent>` or `quantex update --all`
+- **THEN** Quantex selects the Cargo managed update path
+- **AND** it runs Cargo with the recorded crate name and `--force` instead of guessing another package-manager source
+- **AND** it preserves any recorded Cargo install arguments such as `--locked`
+
+#### Scenario: Grouping Cargo-managed updates
+
+- **GIVEN** multiple installed agents have recorded Cargo install state
+- **WHEN** the user runs `quantex update --all`
+- **THEN** Quantex groups those updates by the Cargo installer
+- **AND** it executes Cargo-managed batch update work without mixing the crates into npm, Bun, Homebrew, or winget groups
+
+#### Scenario: Reporting Cargo installer availability
+
+- **GIVEN** the user runs `quantex capabilities` or `quantex doctor`
+- **WHEN** Quantex reports managed installer availability
+- **THEN** the output includes Cargo availability alongside Bun, npm, Homebrew, and winget
+

openspec/specs/release-workflow/spec.md

@@ -5,41 +5,43 @@ Define how Quantex reconciles protected-branch release state from successful CI
 ## Requirements
 ### Requirement: Release Workflow Skips Non-release Pushes
 
-The Release workflow SHALL evaluate release relevance only after merge-gating CI has completed successfully for a protected-branch push, and it SHALL skip release-please for pushes that cannot create a release.
+The Release workflow SHALL evaluate release relevance only after merge-gating CI has completed successfully for a protected-branch push, and it SHALL reconcile the next release action from protected-branch state instead of trusting a single raw workflow event SHA.
 
 #### Scenario: release-worthy merge reaches main
 
-- **WHEN** merge-gating CI completes successfully for a push to `main`
-- **AND** the pushed commit has a release-worthy conventional commit title such as `feat:`, `fix:`, or `perf:`
+- **WHEN** merge-gating CI has succeeded for a release-worthy protected-branch commit on `main`
+- **AND** there is no newer successful untagged `chore: release ...` commit waiting on that branch
 - **THEN** the Release workflow MUST invoke release-please in Release PR mode
 - **AND** the release-please action version MUST be pinned to a repository-verified tag
 - **AND** it MUST skip GitHub Release creation in that invocation
-- **AND** it MUST derive the next release from the current manifest and published release state instead of a stale repository-pinned baseline override
-- **AND** it MUST resolve that action from successful protected-branch CI history instead of blindly trusting a single raw workflow event SHA
 
-#### Scenario: successful release commit is pending publication
+#### Scenario: successful release commit still lacks a tag
 
 - **WHEN** branch history contains a successful protected-branch `chore: release <version>` commit
 - **AND** the corresponding `v<version>` tag does not exist yet
-- **THEN** the Release workflow MUST publish that release commit before it creates or updates another Release PR
+- **AND** no semver release tag points at that exact commit
+- **THEN** the Release workflow MUST prefer GitHub Release publication for that commit over creating or updating another Release PR
 
-#### Scenario: manual release recovery uses branch-state reconciliation
+#### Scenario: already tagged release commit has stale title version
 
-- **WHEN** a maintainer runs the Release workflow manually for `main` or `beta`
-- **THEN** the workflow MUST resolve the target action from the same successful CI history and branch release state used by automatic runs
-- **AND** it MUST NOT bypass the requirement that publish actions come only from a successful protected-branch CI run for the chosen release commit
+- **WHEN** branch history contains a successful protected-branch `chore: release <version>` commit
+- **AND** a semver release tag already points at that exact commit
+- **THEN** the Release workflow MUST treat that commit as already published
+- **AND** it MUST NOT count the stale title version as a pending untagged release commit
 
-#### Scenario: release target resolver has its runtime before resolution
+#### Scenario: stale successful CI run is older than merged release commit
 
-- **WHEN** the Release workflow checks out a protected branch source on a fresh runner
-- **THEN** it MUST bootstrap the runtime needed by the release-target resolver before invoking repository scripts that decide publish vs Release PR vs skip
-- **AND** it MUST NOT defer that runtime installation until after a release is already created
+- **WHEN** a successful protected-branch `CI` run triggers the Release workflow
+- **AND** current protected-branch state already contains a newer successful untagged `chore: release ...` commit
+- **THEN** the workflow MUST NOT reopen or refresh Release PR mode from the older CI run
+- **AND** it MUST reconcile to the pending publish action instead
 
-#### Scenario: CI run reachability uses reconciled remote branch tip
+#### Scenario: manual recovery uses the same resolver
 
-- **WHEN** the Release workflow has fetched `refs/remotes/origin/<protected_branch>` and tags
-- **THEN** release-target reconciliation MUST treat successful `CI` runs as reachable only if the run `head_sha` is an ancestor of the reconciled remote tip for that protected branch
-- **AND** it MUST NOT rely on a local branch tip that may still point at an older commit after fetch-only updates to `refs/remotes/origin/<protected_branch>`
+- **WHEN** a maintainer runs the Release workflow through `workflow_dispatch`
+- **THEN** the workflow MUST derive the target protected branch from the dispatch input or current ref
+- **AND** it MUST use the same release-target reconciliation rules as automatic runs
+- **AND** it MUST NOT bypass the requirement that publish actions come only from a successful protected-branch `CI` run for the selected release commit
 
 ### Requirement: Generated Release PRs satisfy governance sections
 
@@ -54,3 +56,4 @@ Release PRs generated by release-please SHALL include the same governance sectio
 
 - **WHEN** release-please creates or updates a beta Release PR
 - **THEN** the PR body MUST include a `## Closure Check` section
+