chore(release): version packages

[openspec-release-bot]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@fission-ai/openspec@1.6.0

Minor Changes

• #1090 3f0ca3f Thanks @jjxyxsjr! - ### New Features

  • TRAE command adapter — Added command adapter for Trae IDE, enabling generation of .trae/commands/opsx-<id>.md files for custom slash commands

• #1340 1552731 Thanks @TabishB! - ### New Features

  • Oh My Pi support — Generate native OPSX commands and skills for Oh My Pi projects, including tool detection and the expected .omp directory layout.
  • Update planning artifacts in place — Use /opsx:update to revise an existing change's planning artifacts, reconcile related artifacts, and keep implementation work delegated to /opsx:apply.

  Bug Fixes

  • Fresh store registration — Register and use newly created stores before their empty changes, specs, or archive directories have been committed.
  • Safer requirement archiving — Stop stale MODIFIED requirements from silently deleting scenarios that were added by an earlier archive.

Patch Changes

• #1300 a5bfeda Thanks @clay-good! - ### Features

  • Auto-approve the OpenSpec CLI in generated skills and commands — every generated SKILL.md (all tools) and every Claude Code /opsx:* slash command now carries allowed-tools: Bash(openspec:*) in its frontmatter, so agents that honor the Agent Skills standard run openspec commands without prompting for approval on each call; tools that don't recognize the field ignore it. Scope is limited to the openspec CLI; because allowed-tools pre-approves rather than restricts, every other tool a skill or command uses stays available under your normal permission settings.

• #1311 5956a8e Thanks @danilopopeye! - ### Bug Fixes

  • archive exits non-zero when blocked in human mode — openspec archive <change> -y (and any non---json invocation) no longer returns exit code 0 when validation fails and nothing is archived. The three blocking paths in human mode — delta-spec validation failure, spec rebuild failure, and rebuilt-spec validation failure — now set process.exitCode = 1, matching the existing --json behavior. Previously the command printed "Validation failed" (or "Aborted. No files were changed.") and exited 0, letting scripts and CI believe the archive succeeded. Aligns archive with the same exit-code guarantee already approved for apply instructions (fix(apply): fail with exit 1 when apply instructions are blocked #1250).

• #1280 a325305 Thanks @clay-good! - ### Bug Fixes

  • validate resolves changes like status — openspec validate <change> (and --all/--changes and the interactive selector) now resolves a change by directory existence, matching status/instructions, instead of requiring proposal.md. A scaffolded or still-authoring change is validated rather than reported as Unknown item, and a resolved-but-invalid change now exits non-zero. Delta discovery also recurses the nested specs/<area>/<capability>/spec.md layout. (openspec validate cannot resolve changes in a workspace planning home #1182)
  • Task progress reads nested/glob tasks.md — openspec view, list, and the archive incomplete-task gate now resolve task progress through the tracked-tasks artifact's generates glob (the same file-resolution status uses), so a change whose tasks live in nested tasks.md files is classified correctly and can no longer archive while unfinished. (Feedback: openspec view does not detect nested tasks.md files #1202)
  • SHALL/MUST body-keyword hint applies to main specs — A main-spec requirement whose normative keyword sits only in the ### Requirement: header now receives the same targeted "move it to the body line" remediation as a change delta, emitted exactly once. (1.4.0 clearer SHALL/MUST hint does not apply to main specs #1156)

• #1281 9a0dfb5 Thanks @clay-good! - ### Bug Fixes

  • Requirement reading fidelity — The requirement reader used by validate <change>, validate <spec>, and archive is now unified into one fence-, metadata-, and multi-line-aware extraction, closing the known divergences between the change-delta path and the main-spec path (the remaining ones are documented in the change's design doc):

    • A SHALL/MUST keyword that wraps onto a later body line is detected instead of dropped (Line breaks in headers cause validation issues #361).
    • Metadata lines (**ID**:, **Priority**:) before the description are skipped on the spec path, matching the change path ([BUG] Requirement Validation Fails When Metadata Fields Precede Description #418). A requirement written entirely as metadata (e.g. **Constraint**: The system MUST ...) keeps that line as its text instead of being emptied.
    • A fenced code block before the prose line no longer becomes the requirement text (Parser incorrectly treats hash symbols inside code blocks as markdown headers #312).
    • A #### Scenario: inside a fenced example no longer counts as a real scenario in validate <change>, matching validate <spec>.
    • SHALL/MUST detection uses one whole-word predicate across all readers, and a requirement with no body text falls back to its header title on both paths.

    Displayed requirement text (e.g. in JSON output and delta descriptions) now reflects the full requirement body rather than only its first line. Archived spec content is unchanged — the archive rebuild reads raw ### Requirement: blocks, not the parsed text.

  • Surface non-canonical delta headers — validate <change> now emits an INFO note when an ## ADDED/## MODIFIED Requirements section contains a level-3 header that is not a canonical ### Requirement: header (one the delta reader silently skips, such as a stray ### Documentation Requirements divider). The note never changes the valid result, including under --strict (BUG: openspec validate --strict succeeds, but openspec archive fails validation #498).