Skip to content

chore(release): version packages#1380

Open
openspec-release-bot[bot] wants to merge 1 commit into
mainfrom
changeset-release/main
Open

chore(release): version packages#1380
openspec-release-bot[bot] wants to merge 1 commit into
mainfrom
changeset-release/main

Conversation

@openspec-release-bot

@openspec-release-bot openspec-release-bot Bot commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

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

Minor Changes

  • #1399 27b22ab Thanks @clay-good! - Add skip_specs: true change metadata for work with no spec-level behavior change (pure refactors, tooling, docs). openspec validate accepts a zero-delta change that declares the marker (honored only when the metadata parses under the shared change-metadata schema and names a schema that loads) and errors when the marker and delta specs are both present, the artifact graph no longer blocks tasks on spec files for such changes, openspec status renders the specs stage as explicitly skipped, and the propose/specs guidance points to the marker instead of contradicting the validator.

Patch Changes

  • #1404 a84ae70 Thanks @clay-good! - Generated skills for tools without a command adapter (Kimi Code, Mistral Vibe, Hermes, ForgeCode, CodeArts) no longer reference /opsx:* commands that were never generated: skill cross-references, the init getting-started hint, and the profile-migration message now use each tool's documented skill invocation (Kimi Code: /skill:openspec-*; others: /openspec-*), and Codex — skills-invocable with no slash surface — gets a syntax-neutral hint that names the skill. Selections that mix invocation syntaxes print one labeled hint per distinct form, so every advertised instruction is usable by the tool it names. When delivery: commands would generate nothing for a selected tool, init prints a configuration correction naming that tool, even when other tools did get commands or skills. The committed skills.sh distribution is regenerated with skill references (default /openspec-* form, as that channel installs skills only).

  • #1363 5199f41 Thanks @clay-good! - ### Features

    • One default store for every repo on your machineopenspec config set defaultStore <id> sets a machine-level fallback root: any command run outside a planning root, with no --store flag and no project store: pointer, resolves to that store. It sits at the bottom of the precedence list, so --store, a local root, and a project pointer all still win. The root banner and JSON root block report the distinct provenance source: "global_default", so users and tooling can tell a machine-wide default from a repo's own pointer. A stale id degrades to the underlying store error with a fix that names openspec config unset defaultStore.
  • #1435 6a5171e Thanks @clay-good! - openspec new change now accepts numeric-prefixed names like 100-add-feature or 00001-add-auth, useful for ordering or tiering changes. Change names now use the same kebab-case grammar as store ids and change metadata (a leading digit is allowed); archive already treated date-prefixed names as a supported convention. Uppercase, spaces, underscores, and leading/trailing or consecutive hyphens are still rejected, and every previously valid name stays valid.

  • #1425 040a869 Thanks @clay-good! - Compare config key guards literally instead of through a helper.

    setNestedValue and deleteNestedValue rejected prototype-reaching key segments through a helper that did a Set lookup. That is correct, but static analysis could not follow it, so CodeQL kept reporting prototype-pollution on the very assignments the guard protects. The segments are now compared literally in the same function, still checked across the whole path before anything is written. Behavior is unchanged for every input, verified against the previous implementation across 400,000 generated cases.

  • #1431 6a4f0d7 Thanks @clay-good! - A delta spec that introduces a brand-new capability can now open with a ## Purpose, and openspec archive uses it as the Purpose of the main spec it creates instead of writing the TBD - created by archiving change <name>. Update Purpose after archive. placeholder over it. The specs artifact instruction, its example, the delta template and the openspec-sync-specs skill all tell authors and agents to write one, so the CLI and agent-driven sync paths produce the same main spec.

    Archive keeps the placeholder when the delta has no usable ## Purpose:

    • no ## Purpose header outside a code fence or HTML comment, or a body that is only a code fence or only a comment
    • a body that would leave a spec its own parser cannot read — a heading or requirement header that truncates a section, an unterminated fence, or any HTML comment
    • in the second case archive also says why, and still completes rather than aborting

    A carried Purpose under 50 characters is kept but warned about, since openspec validate --strict reports it as too brief. The Purpose of an existing main spec is never touched; archive warns when it ignores a delta's Purpose there.

  • #1437 19d4171 Thanks @clay-good! - openspec archive no longer aborts when a REMOVED delta's requirement is already gone from the main spec (the early-sync pattern the sync skill teaches): it warns, treats the removal as already applied, and reports applied-only totals. In --json mode those warnings are carried in a new optional warnings array on the archive result. When every operation for a spec was already synced, archive skips rewriting that file instead of churning normalization differences into it. A delta that both RENAMEs and REMOVEs the same requirement is now rejected explicitly, by both validate and archive — the two spellings are compared case- and whitespace-insensitively — and a REMOVED header that differs only in case or whitespace from an existing requirement still aborts (that is a typo, not an early sync). Also fixed: the archive delta gate matches section headers case-insensitively like the parser; symlinked specs/<capability>/spec.md files are discovered instead of silently dropped; openspec show <change> no longer prints a spurious "scenarios" flag warning; files generated for qwen and bob reference commands by their real hyphenated names (/opsx-<id>), and init's getting-started hint follows suit; apply/update/onboard guidance names the CLI fallback for profiles that don't install /opsx:continue or /opsx:new.

  • #1411 c439a4e Thanks @clay-good! - Fix phantom requirements parsed from delta specs, which made openspec archive warn about problems openspec validate never reported.

    A header inside a delta section that is not a ### Requirement: header — a divider such as ### Documentation Requirements — was read as a requirement with no scenario. openspec archive warned that it was missing a scenario, and openspec show <change> --json and openspec change list counted it as an extra delta. The change parser now ignores those headers, matching the delta reader, so the phantom is gone from the warnings and from the JSON. Main spec parsing is unchanged.

    openspec archive also no longer repeats requirement-level issues from the delta specs in its non-blocking "Proposal warnings in proposal.md" block. Each defect was printed twice there, and a ## REMOVED Requirements entry — names-only by design — was reported as missing a scenario on every correct removal. Delta spec validation still reports and blocks on genuine defects, and proposal-level warnings are unchanged.

  • #1394 b474f81 Thanks @clay-good! - ### Bug Fixes

    • Archive no longer races the spec sync, or reports a sync that never landed — the generated openspec-archive-change skill (and the matching opsx:archive command) handed the spec sync to a background task and then moved the change folder immediately. The archive could move the delta specs out from under the running sync: the change ended up archived, openspec/specs/ was never updated, and the summary still reported Specs: ✓ Synced. The sync now runs inline, and the archive only proceeds once every capability with a delta spec has been checked against it — ADDED present, MODIFIED changes applied, REMOVED gone, RENAMED under the new name and not the old. If the sync fails or a capability doesn't match, the archive stops and reports what differs instead of claiming success; nothing has moved, so you can fix it and retry.
  • #1398 97d441a Thanks @clay-good! - ### Bug Fixes

    • Bulk archive now stops when you pick "Cancel" — the generated openspec-bulk-archive-change skill (and the matching opsx:bulk-archive command) offered a "Cancel" option at the confirmation prompt but never told the agent what to do with it, so the next step archived every selected change anyway. The prompt now routes each answer by intent: "Cancel" stops without archiving anything, the archive options proceed (the ready-only option archives just the changes the status table marks Ready or Ready*), and any other answer re-asks instead of archiving. The single-change archive skill already routes Cancel this way; this brings the bulk variant in line.
  • #1375 52a8bce Thanks @clay-good! - --change now accepts any change name that exists on disk (e.g. date-prefixed names like 2026-07-04-voice-copilot-v1), matching what list, validate, and archive already resolve. Lookup still rejects unsafe names (path separators, .., hidden entries); the kebab-case naming rule still applies when creating a change.

  • #1364 f58b445 Thanks @clay-good! - Fix openspec completion install detecting the wrong shell for fish (and other)
    users whose interactive shell differs from their login shell. Detection now
    consults the parent process before falling back to $SHELL, so running the
    command from fish installs fish completions instead of defaulting to bash.

  • #1377 285dfd7 Thanks @clay-good! - ### Bug Fixes

    • Config rules: keys are no longer reported as Unknown artifact ID when they belong to a different schema. The global rules map is now validated against the union of artifact IDs across every available schema, so multi-schema projects stop seeing spurious warnings on every command (#1322).
  • #1401 b33b15d Thanks @clay-good! - Stop design.md from restating the proposal. In the default spec-driven schema, the design instruction asked for "Background, current state, constraints, stakeholders" and "What this design achieves and excludes" without saying that motivation and scope already live in proposal.md, so agents restated the proposal's Why and What Changes instead of adding the design's own value - approach, alternatives, and trade-offs. The instruction and the design template now state the boundary explicitly (the proposal covers why and what, design covers how) and tell the agent to reference those documents rather than repeat them (#1382).

  • #1408 378d468 Thanks @clay-good! - Explore now reads the project's context and rules from openspec/config.yaml (or config.yml) at the start of a session, so it reasons with the same tech stack and conventions the artifact-creating workflows already receive.

  • #1396 60f720c Thanks @clay-good! - Fix openspec feedback failing when the repository does not define the feedback label. The command now retries without the label and notes that it was not applied, instead of exiting with an error and discarding the feedback.

  • #1151 18cbf5d Thanks @javigomez! - ### Fixed

    • Ignore Markdown structure (requirement headers, delta sections, scenarios, REMOVED/RENAMED entries) that appears inside fenced code blocks when parsing delta specs. Previously a fenced ### Requirement: example was parsed as a real (phantom) requirement, producing spurious validate errors and risking incorrect archive output. Fenced-code detection is now shared across the Markdown parsers so validate and archive behave consistently.
  • #1316 9b70481 Thanks @mc856! - ### Bug Fixes

    • archive no longer stacks a second date prefix — archiving a change whose name already starts with a YYYY-MM-DD- prefix (a common authoring convention) keeps the name as-is instead of prepending today's date. Previously openspec archive 2026-07-04-voice-copilot-v1 --yes produced 2026-07-06-2026-07-04-voice-copilot-v1, and when run on a later day the folder sorted under a day on which the change did not happen. Names without a full date prefix (including partial dates like 2026-07-feature) are dated as before, and the naming is now idempotent.
  • #1374 da3907b Thanks @clay-good! - fix(completion): make the PowerShell completion script parse and load again

    The generated OpenSpecCompletion.ps1 contained 18 empty switch ($positionalIndex) { } blocks — emitted for commands whose positionals are all path-typed (PowerShell completes paths natively, so those cases produce no clauses). A switch with no clauses is a PowerShell parse error ("Missing condition in switch statement clause"), and PowerShell parses the whole file before running it, so the script never loaded and completions never registered. The generator now skips the positional-index block entirely when no positional produces completions, so the script parses clean (18 → 0 errors) and tab completion works.

  • #1388 9b5d2cd Thanks @mc856! - ### Bug Fixes

    • Archive workflow templates no longer teach agents to stack a second date prefix — the openspec-archive-change and openspec-bulk-archive-change skill/command templates (and the onboarding walkthrough's archived-path example) now mirror the openspec archive rule: a change whose name already starts with a YYYY-MM-DD- prefix is archived under its own name, while other names get the current date prepended as before. Previously an agent following the workflow instructions on a change named 2026-07-04-voice-copilot-v1 produced archive/2026-07-07-2026-07-04-voice-copilot-v1, whatever the CLI did.
  • #1403 2d6c447 Thanks @clay-good! - ### Bug Fixes

    • Propose and fast-forward skills no longer name the Claude-only TodoWrite tool — the generated openspec-propose and openspec-ff-change skills (and their /opsx:propose / /opsx:ff commands) told every agent to "Use the TodoWrite tool", which only exists in Claude Code. Codex, Cursor, Gemini, Copilot, and the other supported tools have no such tool, so agents either errored or stalled looking for it. The instruction is now runtime-neutral ("Use a todo list to track progress"), which works everywhere — including Claude Code.
  • #1415 e2f748c Thanks @clay-good! - Reject config key paths that reach the prototype chain, and update the bundled yaml dependency.

    openspec config set --allow-unknown __proto__.polluted <value> reported success and assigned onto Object.prototype for the rest of the process. --allow-unknown was meant to relax the known-key check only, but it skipped every key check, so __proto__, constructor, and prototype segments reached the nested-write helper. Those segments are now rejected in config set whether or not --allow-unknown is passed, and setNestedValue / deleteNestedValue refuse them regardless of caller. Ordinary keys such as featureFlags.myFlag behave exactly as before.

    The yaml runtime dependency moves from 2.8.2 to 2.9.0, picking up the fix for a stack overflow on deeply nested input (GHSA / advisory patched in 2.8.3).

  • #1376 7958924 Thanks @clay-good! - ### Bug Fixes

    • Archive after early syncopenspec archive no longer fails with ADDED failed … already exists when a change's specs were already synced to the main specs before archiving (the early-sync pattern from the sync workflow). If an ADDED requirement already exists in the target spec with identical content, applying it is treated as a no-op; a same-named requirement with different content still aborts the archive as a genuine conflict (#1332).
  • #1386 b419e96 Thanks @mc856! - ### Bug Fixes

    • Archive after early sync (RENAMED)openspec archive no longer fails with RENAMED failed … source not found when a change's renames were already synced to the main specs before archiving (the early-sync pattern from the sync workflow). If a RENAMED requirement's source header is gone but the target header exists in the spec, applying the rename is treated as a no-op; a rename whose source and target are both missing still aborts the archive as a genuine error, and reported counts reflect only renames actually applied.
  • #1405 5dfef4b Thanks @clay-good! - ### Bug Fixes

    • Custom schema instructions are no longer overridden by hard-coded spec-driven patterns — the openspec-continue-change skill/command embedded one-line "common artifact patterns" for proposal.md, specs, design.md, and tasks.md, so agents followed those shortcuts instead of the schema's instruction field whenever a custom schema reused familiar artifact names. The templates now state that the instruction field is the authoritative guidance, and the propose, continue, and ff workflows direct the agent — both in the artifact-creation step and in the guidelines — to invoke a skill when the instruction delegates artifact creation to one, verifying the artifact exists afterward (fixes #777).
  • #1415 e2f748c Thanks @clay-good! - Parse spec headings in linear time when the title is padded with whitespace.

    Building the reference index read the first Purpose line with a regex that backtracked quadratically on a heading full of spaces: 10,000 characters of padding took 60ms, and 100,000 would have taken roughly six seconds. The heading scan is now hand-rolled and linear. Behavior is unchanged — the replacement was checked against the old implementation across 303,000 generated inputs, including CommonMark closing sequences (## Purpose ##), seven-hash lines, and headings with no space after the hashes.

  • #1428 81d5109 Thanks @taltas! - Update current Roo Code product references to its community successor, Zoo Code.

  • #1410 b3b05e1 Thanks @clay-good! - Only advertise onboarding commands that will actually exist. The openspec init welcome screen and the openspec update "Getting started" summary listed /opsx:new and /opsx:continue, which the default core profile never generates, so users were told to run commands that did not exist. Both surfaces now list the commands for the installed workflows. The init and update completion hints also name the skill (/openspec-propose) instead of a command for tools that receive no command files — Codex, and any tool under skills-only delivery.

  • #1412 1dc670d Thanks @clay-good! - ### Fixed

    • /opsx:propose and /opsx:ff no longer finish a change with no spec written. The workflows listed only proposal/design/tasks and treated the apply phase's tasks artifact as the stop condition — but status marks an artifact done as soon as a matching file exists, so writing tasks.md early satisfied the loop while specs/<capability>/spec.md was never created (a spec-less change in a spec-driven tool). The loop now derives the full required set — every apply dependency plus everything it transitively requires — from a single status call, creates each missing artifact, and only skips one when its own instruction field marks it conditional. (#1260, #788)

    Changed

    • openspec status --json now reports each artifact's requires edges. Every entry in the artifacts array carries a requires array of the ids it directly depends on, present for every status (including done) so agents can compute the transitive required set from status alone. Additive and backward-compatible — existing fields are unchanged.
  • #1191 7704702 Thanks @mc856! - Generate Markdown commands for Qwen Code instead of deprecated TOML format. Qwen Code now recommends Markdown custom commands with YAML frontmatter; the old .qwen/commands/opsx-*.toml files are cleaned up as legacy artifacts on update.

  • #1368 de78c31 Thanks @clay-good! - ### Fixes

    • Regenerated artifacts now pick up your manual edits — the continue, propose, and fast-forward workflows (and the openspec instructions dependency block) now tell the agent to re-read dependency artifacts from disk before creating the next one, instead of trusting whatever version it saw earlier in the conversation. Previously, editing spec.md and deleting design.md/tasks.md to regenerate them could silently produce artifacts based on the stale, pre-edit content.
  • #1392 a13abea Thanks @clay-good! - ### Fixed

    • Stop a delta spec written directly at a change's specs/ root from being silently dropped. validate accepted specs/spec.md and counted its deltas, but the apply/archive merge only reads capability folders (specs/<capability>/spec.md), so the change could pass validation and be archived while its requirements never reached openspec/specs/. validate now uses the same discovery rules as the merge path and reports the misplaced file with a fix hint, and archive blocks instead of completing.
  • #1433 26f009d Thanks @clay-good! - Change lookup no longer requires proposal.md. openspec show, openspec change list/show/validate, and shell completion now resolve a change by its directory, matching openspec list, status, instructions, and validate.

    Previously a change created by openspec new change — which scaffolds only .openspec.yaml — was reported as Unknown item by openspec show and was missing from completions and openspec change list until a proposal was written, and a change from a schema with no proposal artifact was never resolvable. openspec change list now reports the same set as openspec list, keeps task counts for a change that has no proposal yet, and labels it (no proposal.md yet) rather than (unable to read). Showing such a change explains that the proposal is not written yet and points at openspec status --change <name>.

  • #1194 b7c85c7 Thanks @mc856! - Fix skills-only delivery emitting /opsx:* command references. SKILL.md files generated by init, update, and workspace skill setup now reference the corresponding skills (e.g. /openspec-apply-change) when delivery: 'skills' is configured, instead of commands that were never generated.

  • #1402 0da5f98 Thanks @clay-good! - Show the main spec format in the sync-specs skill so agents stop leaving delta operation headers (## ADDED/MODIFIED Requirements) in openspec/specs/ — merged main specs with those headers parse as 0 requirements in openspec view (#1120).

@openspec-release-bot
openspec-release-bot Bot requested a review from TabishB as a code owner July 17, 2026 17:04
@openspec-release-bot
openspec-release-bot Bot force-pushed the changeset-release/main branch 29 times, most recently from 08ee775 to 25aa316 Compare July 20, 2026 19:48
@openspec-release-bot
openspec-release-bot Bot force-pushed the changeset-release/main branch 24 times, most recently from 0e7e2c3 to 9f6e2f5 Compare July 23, 2026 16:23

@alfred-openspec alfred-openspec left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 1.7.0 candidate is green in-repo, but it still reproduces #1390 for downstream consumers: the packed manifest publishes posthog-node as ^5.46.0, and a Dependabot-style lock generated without the age policy resolved posthog-node@5.46.1, @posthog/core@1.45.1, and @posthog/types@1.398.0; pnpm@11.16.0 install --frozen-lockfile with minimumReleaseAge: 1440 then fails on those exact three entries.

Please fix the published dependency tree before release and add a packed-consumer regression for this policy. Pinning only posthog-node is not sufficient because its manifest still ranges over @posthog/core, which ranges over @posthog/types.

@openspec-release-bot
openspec-release-bot Bot force-pushed the changeset-release/main branch 3 times, most recently from e9fa1a8 to f193524 Compare July 23, 2026 20:10
@openspec-release-bot
openspec-release-bot Bot force-pushed the changeset-release/main branch from f193524 to 8128f87 Compare July 23, 2026 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

openspec-continue-change hard-coded artifact patterns override schema instruction field

1 participant