diff --git a/openspec/changes/add-cargo-package-manager/.openspec.yaml b/openspec/changes/archive/2026-05-10-add-cargo-package-manager/.openspec.yaml similarity index 100% rename from openspec/changes/add-cargo-package-manager/.openspec.yaml rename to openspec/changes/archive/2026-05-10-add-cargo-package-manager/.openspec.yaml diff --git a/openspec/changes/add-cargo-package-manager/design.md b/openspec/changes/archive/2026-05-10-add-cargo-package-manager/design.md similarity index 100% rename from openspec/changes/add-cargo-package-manager/design.md rename to openspec/changes/archive/2026-05-10-add-cargo-package-manager/design.md diff --git a/openspec/changes/add-cargo-package-manager/proposal.md b/openspec/changes/archive/2026-05-10-add-cargo-package-manager/proposal.md similarity index 100% rename from openspec/changes/add-cargo-package-manager/proposal.md rename to openspec/changes/archive/2026-05-10-add-cargo-package-manager/proposal.md diff --git a/openspec/changes/add-cargo-package-manager/specs/agent-catalog/spec.md b/openspec/changes/archive/2026-05-10-add-cargo-package-manager/specs/agent-catalog/spec.md similarity index 100% rename from openspec/changes/add-cargo-package-manager/specs/agent-catalog/spec.md rename to openspec/changes/archive/2026-05-10-add-cargo-package-manager/specs/agent-catalog/spec.md diff --git a/openspec/changes/add-cargo-package-manager/specs/agent-update/spec.md b/openspec/changes/archive/2026-05-10-add-cargo-package-manager/specs/agent-update/spec.md similarity index 100% rename from openspec/changes/add-cargo-package-manager/specs/agent-update/spec.md rename to openspec/changes/archive/2026-05-10-add-cargo-package-manager/specs/agent-update/spec.md diff --git a/openspec/changes/add-cargo-package-manager/tasks.md b/openspec/changes/archive/2026-05-10-add-cargo-package-manager/tasks.md similarity index 100% rename from openspec/changes/add-cargo-package-manager/tasks.md rename to openspec/changes/archive/2026-05-10-add-cargo-package-manager/tasks.md diff --git a/openspec/changes/fix-release-target-resolution/.openspec.yaml b/openspec/changes/archive/2026-05-10-fix-release-target-resolution/.openspec.yaml similarity index 100% rename from openspec/changes/fix-release-target-resolution/.openspec.yaml rename to openspec/changes/archive/2026-05-10-fix-release-target-resolution/.openspec.yaml diff --git a/openspec/changes/fix-release-target-resolution/design.md b/openspec/changes/archive/2026-05-10-fix-release-target-resolution/design.md similarity index 100% rename from openspec/changes/fix-release-target-resolution/design.md rename to openspec/changes/archive/2026-05-10-fix-release-target-resolution/design.md diff --git a/openspec/changes/fix-release-target-resolution/proposal.md b/openspec/changes/archive/2026-05-10-fix-release-target-resolution/proposal.md similarity index 100% rename from openspec/changes/fix-release-target-resolution/proposal.md rename to openspec/changes/archive/2026-05-10-fix-release-target-resolution/proposal.md diff --git a/openspec/changes/fix-release-target-resolution/specs/release-workflow/spec.md b/openspec/changes/archive/2026-05-10-fix-release-target-resolution/specs/release-workflow/spec.md similarity index 100% rename from openspec/changes/fix-release-target-resolution/specs/release-workflow/spec.md rename to openspec/changes/archive/2026-05-10-fix-release-target-resolution/specs/release-workflow/spec.md diff --git a/openspec/changes/fix-release-target-resolution/tasks.md b/openspec/changes/archive/2026-05-10-fix-release-target-resolution/tasks.md similarity index 100% rename from openspec/changes/fix-release-target-resolution/tasks.md rename to openspec/changes/archive/2026-05-10-fix-release-target-resolution/tasks.md diff --git a/openspec/specs/agent-catalog/spec.md b/openspec/specs/agent-catalog/spec.md index d393c83..9962c7a 100644 --- a/openspec/specs/agent-catalog/spec.md +++ b/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 ` + +#### 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 diff --git a/openspec/specs/agent-update/spec.md b/openspec/specs/agent-update/spec.md index ce2bbd0..5459e6c 100644 --- a/openspec/specs/agent-update/spec.md +++ b/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 ` 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 + diff --git a/openspec/specs/release-workflow/spec.md b/openspec/specs/release-workflow/spec.md index 4d0c7bb..359859c 100644 --- a/openspec/specs/release-workflow/spec.md +++ b/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 ` commit - **AND** the corresponding `v` 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 ` 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/` 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/` +- **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 +