mirror of
https://github.com/Fission-AI/OpenSpec.git
synced 2026-10-02 05:24:34 +08:00
416599a85ea2f9c882db8dade5c5a7041d5d7bcf
887
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Clay Good
|
416599a85e |
docs(copilot): document workflow rediscovery (#1943)
* docs(copilot): document workflow rediscovery * test(copilot): pair discovery claims * docs(copilot): harden workflow recovery guidance |
||
|
Clay Good
|
0dde57b401 | fix(continue): keep active prompts from becoming tool calls (#1944) | ||
|
Clay Good
|
a64303fe1e |
fix(update): report legacy Codex bootstrap failures (#1939)
* fix(update): report legacy Codex bootstrap failures * fix(update): preserve failures after declined migrations * test(update): cover every bootstrap failure exit |
||
|
dependabot[bot]
|
02fade2077 |
ci: bump the github-actions group across 1 directory with 4 updates (#1928)
Bumps the github-actions group with 4 updates in the / directory: [pnpm/action-setup](https://github.com/pnpm/action-setup), [DeterminateSystems/nix-installer-action](https://github.com/determinatesystems/nix-installer-action), [DeterminateSystems/magic-nix-cache-action](https://github.com/determinatesystems/magic-nix-cache-action) and [changesets/action](https://github.com/changesets/action). Updates `pnpm/action-setup` from 6.0.10 to 6.1.0 - [Release notes](https://github.com/pnpm/action-setup/releases) - [Commits](https://github.com/pnpm/action-setup/compare/0977fd99725f1db4007ccb2928dbb4e90d06cc86...ea17c68df8912ef543352723c149a84f56e3d413) Updates `DeterminateSystems/nix-installer-action` from 22 to 23 - [Release notes](https://github.com/determinatesystems/nix-installer-action/releases) - [Commits](https://github.com/determinatesystems/nix-installer-action/compare/ef8a148080ab6020fd15196c2084a2eea5ff2d25...3138316df39ed29be04236d7ffc686fa525866aa) Updates `DeterminateSystems/magic-nix-cache-action` from 14 to 15 - [Release notes](https://github.com/determinatesystems/magic-nix-cache-action/releases) - [Commits](https://github.com/determinatesystems/magic-nix-cache-action/compare/908b263ff629f4cc17666315b7fd3ec127c6244d...84c0677f58dcedf3b91f8223ce36a9ea5b3c84b7) Updates `changesets/action` from 2.1.1 to 2.1.2 - [Release notes](https://github.com/changesets/action/releases) - [Changelog](https://github.com/changesets/action/blob/main/CHANGELOG.md) - [Commits](https://github.com/changesets/action/compare/8488615a623b1b9c987934bb89eae8af6a946ac1...ae32849d5ba541f9ae29e40e22a623bc13562f51) --- updated-dependencies: - dependency-name: pnpm/action-setup dependency-version: 6.1.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: DeterminateSystems/nix-installer-action dependency-version: '23' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: DeterminateSystems/magic-nix-cache-action dependency-version: '15' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: changesets/action dependency-version: 2.1.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Clay GoodandClaude Opus 5
|
518e1a0124 |
fix(legacy-cleanup): read a legacy command through the handle it checks (#1905)
isGeneratedLegacyCommand lstat'ed a path and then re-read it by path, so the file judged "generated" could differ from the file read (CodeQL js/file-system-race, alert #524, added by #1874). Open once with O_NOFOLLOW|O_NONBLOCK, fstat that handle, and read from it. Windows lacks O_NOFOLLOW, so links are still refused there via lstat. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Tabish Bidiwale
|
bae58cf614 | docs: fix Docslab links to unfinished pages (#1903) | ||
|
openspec-release-bot[bot]andgithub-actions[bot]
|
634c557bd0 |
Version Packages (#1896)
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>@fission-ai/openspec@1.13.1 v1.13.1 |
||
|
Clay GoodandClaude Opus 5
|
eb03b9e933 |
chore(changeset): track #1835 security hardening and #1785 nix completions (#1902)
Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
3312af4799 |
fix(templates): open generated artifacts with a top-level heading (#1777)
* fix(templates): open generated artifacts with a top-level heading
Generated proposal.md, design.md, spec.md and tasks.md started on a
section header, so every OpenSpec artifact tripped markdownlint MD041
("first line in a file should be a top-level heading") in editors that
run it. The files were also, literally, documents without a title.
Each packaged template now opens with `# Proposal`, `# Design`,
`# Spec Delta` or `# Tasks` followed by a blank line, and
`openspec schema init` scaffolds custom templates the same way. The
schema's own examples and the customization docs match.
Titles are inert to every reader downstream: the parsers anchor on `##`
and `###`, and archive builds a new main spec from the delta's sections,
so the main spec keeps its own generated `# <capability> Specification`
and only that one.
Closes #1138
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(templates): compare template headings on normalized line endings
The Windows runner checks out CRLF, so splitting the template on "\n"
left the blank second line as "\r" and the new guards failed there while
passing everywhere else. Normalize before splitting; verified against a
CRLF copy of the templates locally.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(templates): pin each template to its own title
Review feedback: the guards accepted any top-level heading, so a wrong
title would have passed, and the archive check counted `# ` lines only,
so a demoted `## Spec Delta` would have slipped through. Assert the exact
heading per artifact, the blank line under it in both guards, and that no
heading of any level named "Spec Delta" survives archive.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(workflows): teach the artifact titles everywhere the shape is shown
The templates were only half the story. The onboarding walkthrough drafts
each artifact in the conversation and then saves what it drafted, so its
previews would have written untitled proposal.md, spec.md, design.md and
tasks.md whatever the template said. The sync workflow's delta format
reference had the same gap, sitting directly beneath a main-spec
reference that does carry a title. Both now show the template's title,
and `docs/opsx.md` no longer documents a `template` value the CLI never
returned.
Guards added:
- The template guard now enumerates every artifact of every packaged
schema from schema.yaml rather than a hardcoded list of four, and the
exact-title table must name every artifact the schema declares.
- A drift guard reads the titles out of the packaged templates and
requires the onboard and sync surfaces to show those same titles, so
guidance and template cannot part ways again.
- Parser tests pin the claim the fix rests on: a title is inert, and a
spec or proposal parses identically with and without one.
Regenerated the skill mirrors and parity hashes for the two workflows
touched; no other hash moved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: move the artifact-title update to the canonical docs-lab tree
The live site builds from docs-lab/, so the exact-format page there is the
one readers see. It still showed all four templates opening on a section
header and described the delta as starting with `## Purpose`.
- reference/schemas/spec-driven/index.md: each template block now matches
the shipped template byte for byte, and the quoted spec/tasks
instructions match schema.yaml again.
- customize/schemas.md: one line telling fork authors to keep the `#`
title on the first line.
Reverts the edits to docs/customization.md and docs/opsx.md: that tree is
no longer published and docs-lab/README.md keeps it as source material
only, so editing it would leave two versions of the same fact.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(show): keep the change id as title for a bare `# Proposal` heading
The packaged proposal template now opens with `# Proposal`, which
`extractTitle` read as the change's title, so `show --json` and
`change list --json/--long` titled every templated change "Proposal"
instead of its id. Treat that bare heading as untitled.
Also re-quote the proposal and specs instructions in the canonical
docs-lab schema page after #1700 changed schema.yaml.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Clay GoodandClaude Opus 5
|
5f5914e7f7 |
fix(skills): match natural "openspec <verb>" phrasing to its workflow (#1852)
* feat(skills): match natural "openspec <verb>" phrasing to its workflow Users and agents say "openspec propose" / "openspec apply", but no workflow skill description contained that phrasing, so an agent hearing it had nothing to match and routinely hand-built the artifacts with the CLI instead of running the workflow. Each workflow skill's description now names the phrasings that should route to it. `openspec update` is deliberately left unclaimed: it is a real CLI command that refreshes generated files, unrelated to the update-change workflow, so that skill claims "openspec update change" instead. Descriptions are emitted as unquoted YAML plain scalars, so the new tests also pin that the generated frontmatter still parses and the description round-trips. Closes #1221 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): derive the CLI-collision guard instead of hardcoding it Review found the guard codified the one exception rather than the rule, so it could never catch the next collision. It now reads every command name the CLI registers and fails on any claimed phrase that shadows one, unless the phrase is listed in DELIBERATE_CLI_PHRASE_CLAIMS with a reason. Two routing fixes fall out of stating the rule: - bulk-archive also claims "openspec archive all", so an exact-phrase match on "openspec archive" no longer pulls a multi-change request to the single-change skill. - update-change now disclaims the openspec update CLI command in prose, not only by avoiding the string. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): drop the trailing clause and close the plural-archive hole Review found the "- follow this skill rather than doing the work by hand" trailer was decoration that contradicted two of the skills it was appended to: sync-specs opens "This is an agent-driven operation - you will read delta specs and directly edit main specs", and explore says "This is a stance, not a workflow. There are no fixed steps." A description is read at selection time, so the clause could not reach the hand-building it targeted anyway; the bodies already carry that guidance. Removing it from all 12 also drops ~800 chars of identical boilerplate that made update-change's CLI redirect read as filler. Routing fixes: - bulk-archive claims the plural phrasings that do not contain "all", so "openspec archive these three changes" no longer loses to the single-change skill on the bare literal. - update-change redirects to the CLI command positively instead of negating ("run that command instead"), which routers honor far better than "not for". - apply also claims "openspec implement", the natural English verb for it, which shadows no CLI command. Corrects the recorded reason for claiming "openspec archive": the CLI command does merge delta specs (docs/cli.md:631, src/core/archive.ts:1402). The real reason is that the workflow confirms and verifies the merge before anything moves, where the bare command does it in one shot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(quickstart): name the verb phrasing that now routes to a workflow Also rewrites the changeset to house style: links the issue, names the commands-only scope limit, and tells a reader they need `openspec update` to pick it up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): walk the real command tree instead of scanning the entrypoint Mutation testing found the collision guard was a strict subset of reality, not the superset its comment claimed. It scanned src/cli/index.ts for `.command('…')`, but seven groups — spec, config, schema, store, doctor, context, workset — are registered from their own modules, so 23 real command names were invisible. A description claiming "openspec doctor" or "openspec spec" passed 18/18 green. It now walks the commander tree from the exported `program` (importing it does not parse argv; runCli does that), and a sanity test pins the seven delegated groups so the blind spot cannot come back. Three more holes the same pass found, all confirmed by re-running the mutations that previously slipped through: - phrase extraction was case-sensitive and double-quote-only, so "Openspec update" and `openspec update` in backticks both evaded every guard. Matching is now case-insensitive and accepts either delimiter. Unquoted prose stays excluded on purpose: the update-change redirect names the CLI command in prose, and prose is not a routing trigger. - prefix shadowing was unguarded, which is the exact shape of the archive/bulk-archive tension. A shorter phrase contained in another skill's longer phrase must now be declared in DELIBERATE_PHRASE_SHADOWING. - both allowlists accepted an empty reason and never flagged stale entries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(skills): let the CLI-collision guard ignore hidden workflow-verb hints PR #1776 registers the workflow verbs (explore, propose, apply, ...) as hidden CLI commands that only point the user at the workflow. Walking the commander tree then saw "openspec explore" as a real command and failed the collision guard for every skill trigger. Skip a subcommand only when it is hidden AND named after a workflow. Visible commands and hidden non-workflow commands are still guarded, pinned by a synthetic commander tree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): drop em dashes from the release note Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): drop the generic by-hand clause from the explore description The other eleven descriptions dropped it; explore is a stance, not a workflow, so telling the agent to follow it instead of doing the work contradicts it. Adds a regression over every workflow description. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
9827762d2d |
fix(skills): stop workflows from adopting a project that never ran init (#1787)
* fix(skills): stop workflows from adopting a project that never ran init Generated skills and commands are installed once per machine and offered in every repository the agent opens, including ones with no OpenSpec at all. Nothing stopped the workflow there: root resolution falls back to an implicit root at the current directory, so `openspec new change` quietly creates `openspec/` in whatever repo the agent happened to be standing in (#1645). Two changes, both in the generated instructions: - Every workflow now carries a shared project check. Before the first step that writes, the agent reads `root.source` from `openspec status --json`; `implicit` (or a `No OpenSpec root found` error) means the project is not set up, and the agent stops and asks the user whether to run `openspec init`, target a store, or drop OpenSpec for that request. It may not initialize the project on its own or let a command create the root as a side effect. - Every deployed skill description now names OpenSpec. Hosts pick skills by description, and "Enter explore mode - a thinking partner..." reads as a generic offer in a repository that has never heard of OpenSpec. Closes #1645 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(changeset): note the uninitialized-project guard Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): let onboarding run init once the user asks for it The guard read as an absolute ban on `openspec init`, which contradicts the option it offers one sentence earlier and the onboard workflow's job. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(troubleshooting): explain an OpenSpec workflow starting in an unset-up project Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): check the root with a command that never fabricates one `openspec status --json` demands --change once a project has changes, so the guard's own check could fail in exactly the projects it should wave through. `openspec list --json` answers in one shape everywhere: a root object when the project is set up, `root: null` both when nothing is set up and when only stores are registered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(skills): pin the guard against every write, not the first fence CodeRabbit's point: checking only the first ```bash fence would miss a write outside a fence. Assert instead that nothing preceding the guard runs a command or writes, and that the guard sits directly under the store-selection guidance - both fail when the guard is moved down a workflow. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(new-change): say when the command had to create the root itself The generated workflows now check for a root before writing, but the guard is instructions - an agent that ignores it, or a human running the CLI directly, still turned an unset-up directory into an OpenSpec project without a word. Creating the root stays zero-config; it is no longer silent. Human output only: --json is unchanged, and `root.source` already carried the same fact for programmatic callers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): tell agents the root check's non-zero exit is the answer `openspec list --json` exits 1 when there is no root. An agent that reads that as a broken CLI is one step from hand-creating `openspec/` instead, which is the failure the guard exists to prevent. Also drops a vacuous assertion: the notice test now checks that the note names the directory it created and that the change really landed there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * style(skills): read the guard back and untangle its two 'in that case' clauses Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): carry the store flag into the root check; pin the notice path exactly CodeRabbit, both valid: - With a store selected the store IS the root, so the check has to run as `openspec list --json --store <id>`. The store-selection paragraph above already says to append the flag to every command it lists, but leaving it implicit here invited a check against the wrong directory. - The notice assertion matched any `openspec/` suffix. It now pins the exact rendered path, and a new case runs the command from a subdirectory to show the note names the directory actually adopted (and that the repo above it is left alone). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: move the no-root contract to the canonical docs-lab pages alfred-openspec on #1787: docs-lab/README.md makes docs-lab/ canonical and the old docs/ tree legacy, and the canonical pages were stale in the two places the review named. - docs-lab/reference/cli.md, 'openspec new': documents the implicit-root notice after the 'Next:' line, with the exact output the CLI prints, that it goes to stdout and never appears with --json, and that JSON carries the same fact as root.source: implicit. Verified against a real run in an empty directory with an isolated HOME. - docs-lab/reference/skills.md: states the shared response and stop behavior once, above the index table, since it now holds for every skill: confirm the resolved root before the first write, stop when there is none, offer init, a store, or dropping OpenSpec, wait for the answer, never create openspec/ on its own. Drops the legacy docs/troubleshooting.md addition. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): make the no-root answer depend on how the workflow was reached alfred-openspec's product call on #1787. One answer could not serve both arrivals: #1645 asks the workflow to get out of the way ('it can go through the normal general propose not the openspec'), while a user who typed the skill's name is owed an answer about OpenSpec. The guard now branches after the same `openspec list --json` check: - Auto-selected: the model picked this workflow without the user naming OpenSpec, naming the skill, or running its command. Drop OpenSpec and answer the request normally, with no setup question and no mention of OpenSpec. - Explicit OpenSpec request: stop before writing and ask whether to run `openspec init`, target a store, or continue without OpenSpec, then wait. Neither branch may create the root as a side effect, stated once for both. One text serves both surfaces rather than a command-only variant, because apply-change and onboard render a single body into the skill and the command alike; a command-only constant would mean threading a surface flag through bodies that deliberately have none (#1515). The bullets scope themselves instead, and a slash command is an explicit invocation, so only the ask branch can apply there. A test pins that branch reaching every generated opsx command. Four regressions: the auto-selected branch (asserting it does not mention `openspec init` or `--store`), the explicit branch, the explicit branch's presence in every command file, and the shared no-side-effect rule. docs-lab/reference/skills.md said every no-root invocation asks. It now carries the same two branches as scan anchors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): keep the root guard off store-only projects and fix its docs A store-only project whose `store:` line names a store this machine has not registered reports `"root": null` from `openspec list --json`, so the guard read a real OpenSpec project as uninitialized. The guard now checks for the `Declared in` status message first and shows the store error instead. A stale global defaultStore reports the same codes in unrelated repositories, which is why the message prefix, not the code, decides. Propose's context step from #1657 offered `openspec init` on `no_openspec_root` regardless of how the workflow was reached. It now defers to the project check, so an auto-selected propose skill stays silent. The changeset names both no-root branches, and the `new change --json` docs separate the initialized example from the verified `implicit` one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skills): keep the root guard off projects with a malformed store line A config-only project whose `store:` line is malformed reports `"root": null` with an `Invalid store declaration in` message, not `Declared in`, so the project check read it as never initialized and would drop OpenSpec or offer `openspec init` there. The guard now names both prefixes, and a root-selection test pins that every declaration failure starts with one of them while a stale global defaultStore starts with neither. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(skills): check guard ordering in the skill body, not its frontmatter A skill's YAML frontmatter is metadata a host reads to choose the skill, not instructions the agent runs, so a description that quotes a command name must not trip the ordering check. Scope the scan to the text after the closing frontmatter delimiter; a command injected into the body ahead of the guard still fails. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
11a9691524 |
fix(tasks): count unrecognised checkbox markers as not done (#1773)
* fix(tasks): count unrecognised checkbox markers as not done A checkbox marker the task parser did not recognise was dropped from progress entirely: it counted toward neither the numerator nor the denominator. A tasks.md whose remaining work was written `- [~] ...` therefore reported `✓ Complete` in `openspec list`/`status`, and `openspec archive` raised no incomplete-task warning for it. Marking open items with such a marker *shrank* the denominator instead of leaving them counted as not-done. Widen the marker to any single non-`]` character and keep `x`/`X` as the only done state, so an unrecognised marker reads as not-done - the fail-safe direction the pattern's own docblock argues for. OpenSpec adopts no new marker semantics; it just stops losing the line. Closes #1761 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(tasks): close the remaining silent-loss holes in checkbox parsing Hardening pass on the #1761 fix. Parser: an empty `[]` and a padded `[ x]` were dropped exactly the way `[~]` was - checkbox-like lines counting toward neither the numerator nor the denominator, so archive stopped warning about them. The marker is now "at most one non-whitespace token", which covers all three. Multi-character brackets stay unmatched on purpose: widening to `[^\]]*` would match `- [Some doc](./doc.md)`, whose `]` is followed by `(` rather than a space, and turn every Markdown link list into phantom unfinished work. The docblock states that boundary and a test pins it. Guidance: archive, bulk-archive and verify told agents to count `- [ ]` vs `- [x]` by hand, which reproduced the same bug one layer up - an agent following it saw no incomplete tasks in a `[~]` file even with the CLI fixed. All six bodies (skill + command per workflow) now state the rule the parser implements; skills/ mirror and parity hashes regenerated. Coverage now spans every consumer of the shared counter: `openspec list`, archive's gate, the apply task list, validate's task-numbering check and the parser itself, including the reported 42-done/17-deferred ratio. Reverting only src/utils/task-progress.ts fails 7 of them. Verified empirically: the widened pattern newly matches 0 lines across all 1090 .md/.ts files in the repo, templates and docs included. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(tasks): state the padded-tick rule in workflow guidance too CodeRabbit review, verified and valid: the new guidance named only exact `[x]`/`[X]` as complete, while the parser also counts `[ x]`, `[x ]` and `[ x ]`. An agent hand-counting by that wording would have reported a padded tick as unfinished work and disagreed with `openspec list` - the same guidance/CLI split this PR set out to close. All six bodies now phrase it as the parser implements it: complete means the box holds only `x`/`X`, spacing inside the brackets ignored; every other marker, including an empty box, is incomplete. skills/ mirror and parity hashes regenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(tasks): keep one-character link bullets out of the task count alfred-openspec on #1773: the widened marker class let a one-character Markdown link label parse as a checkbox, so `- [A](https://example.com)` and `- [1](./one)` read as unfinished tasks and made progress and archive report phantom work. The multi-character guard did not cover them: a one-character label is one token. The closing bracket may now not be followed by `(` or `[`, the only two characters that continue Markdown link syntax. Nothing that used to count is lost: a checkbox is followed by its description or by end of line, and `- [x]done` still parses. Regressions cover both link forms, the reference form, and a link inside a real task description. Also updates the canonical contract, which said tasks not written `- [ ]` are not tracked while this change deliberately tracks `[~]`, `[-]`, `[]` and a padded `x`. Fixed in schemas/spec-driven/schema.yaml and in the docs-lab page that quotes it, so the quote stays faithful. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: say that a done checkbox is case-insensitive CodeRabbit on #1773: the parser lowercases the marker before comparing it with `x`, so `- [X]` is done, but the contract I added said only `- [x]` counts. Corrected in both copies, which are the same text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(tasks): keep empty boxes followed by link syntax in the task count The one-character link guard also dropped `- [ ](...)` and `- [ ][...]`, which the strict pre-#1761 pattern counted as unfinished tasks. A line the parser drops is one archive stops warning about, so a whitespace-only box now bypasses the guard. The canonical tasks instruction also names `[-]` and the padded `x` rule, in schema.yaml and docs-lab in lockstep. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): drop em dashes and state the padded-x done rule Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
62106f40e3 |
fix(explore): name the propose workflow at every handoff (#1788)
* fix(explore): name the propose workflow at every handoff Explore mode refuses to implement, but nowhere named the workflow that turns the discussion into a change. The refusal, the "flow into a proposal" ending, the closing summary, and the do-not-implement guardrail all described the next step as prose. With no named exit, agents answered the discovery questions and then started writing code (#869). All four handoff points now point at `/opsx:propose`, written in the canonical `/opsx:<id>` form so each tool renders the invocation it actually registers. Skill and command bodies are patched together, the skills.sh mirror is regenerated, and parity hashes are refreshed. Closes #869 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(explore): name the continuation after a seamless capture The capture path let explore scaffold a change and write artifacts, then said nothing about what came next. An agent holding a fresh proposal inside explore mode has an obvious wrong next move, and it is the one #869 reported. The capture now ends by naming `/opsx:propose` for the remaining planning artifacts and `/opsx:apply` for implementation, and says plainly that capturing artifacts is not permission to implement them. Widen the rendering guard to walk the real registries instead of a hand-picked few: every registered command adapter and every entry in AI_TOOLS must rewrite every canonical reference in both bodies, with no `/opsx:` form surviving on any skills surface. A new adapter or a changed invocation shape now fails here rather than shipping a command nobody answers to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): cover the capture-path handoff Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(explore): resolve handoffs against the installed workflow set A custom profile can install explore without propose or apply, and the explore skill and command still named both. Handoffs are now authored with optionalWorkflow() and resolved in getSkillTemplates()/getCommandTemplates() against the workflow filter every init/update path already passes. Missing workflows fall back to explore's own capture path and the openspec instructions apply CLI. Output with every workflow installed is unchanged. Uses the same API and marker syntax as #1775 so the two compose. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): drop em dashes from the release note Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
e67ac47f3a |
fix(bulk-archive): check the archive target before moving changeRoot (#1829)
* fix(bulk-archive): check the archive target before moving changeRoot Step 8c ran `mv` with no existence check. POSIX `mv` moves changeRoot inside an existing target directory and exits 0, so a same-day name collision produced archive/<target>/<target>/ and was recorded as a successful archive. The workflow already promised the opposite in three places: the guardrail "If archive target exists, fail that change but continue with others" and both failure output templates listing "Archive directory already exists". The single-change archive workflow implements the check; the bulk path did not. Closes #1827 * fix(bulk-archive): check archive targets before the first spec write The existence check at the move ran after step 8a had already synced the change's delta specs, so a collision still left main specs rewritten for a change that stayed active. `openspec archive` settles the destination before touching any spec; the batch now does the same in step 3 (including two selected changes that resolve to the same target), keeps blocked changes out of sync, conflict resolution, and the archive-everything option, and re-checks just before the move. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): describe the pre-sync archive target check Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(bulk-archive): undo a nested move and keep blocked changes failed The last target check and `mv` are separate steps, so a target created in between still nested the change with exit 0. Step 8c now confirms the move did not land inside the target and moves the change back, recording `Archive directory already exists`, instead of reporting success. The ready-only option recorded every non-Ready change as Skipped, which misreported archive collisions; Blocked changes now stay Failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(bulk-archive): require the move before asserting the nest check follows it Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(bulk-archive): say the guardrail's dated target is the one step 3d recorded The guardrail still read 'uses current date', which invites recomputing the name at the move. It now points to the step 3d value, matching step 8c. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: choi138 <dev@silviahealth.com> Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
605d9e7a2b |
fix(config): leave an unparseable global config untouched (#1876)
* fix(config): leave an unparseable global config untouched A typo in config.json made getGlobalConfig() fall back to defaults, which telemetry read as consent: any command, even a read-only list, minted a new anonymous id and wrote it over the whole file, dropping a telemetry.enabled false opt-out and every other setting. config set, unset and profile likewise saved the defaults over it. saveGlobalConfig() and telemetry's writeConfig() now refuse to overwrite a file they cannot parse, telemetry and the update check treat such a file as opted out, and config set, unset and profile exit with an error pointing to config edit. config reset --all can still replace the file, and the existing warning is unchanged. * fix(config): treat a non-object global config as unreadable Valid JSON that is not an object (null, an array, a string) also makes getGlobalConfig() fall back to defaults, silently, so `config set` still saved those defaults over the user's file. isGlobalConfigUnreadable() now reports such a file as unreadable, which keeps telemetry off and routes every save through the same refusal as a parse failure. This matches how completion-tip already treats a non-object config. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(config): document the refusal to rewrite an unparseable config docs-lab/reference/cli.md said `config unset` always exits 0. With an unparseable global config, `config set`, `config unset` and `config profile` now exit 1 and leave the file unchanged; say so, show the message and the two fixes, and note telemetry and the update check stay off until it is fixed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(config): warn about an unparseable global config once per command Telemetry, the update check and the command each read the global config, and now that none of them rewrites the broken file, the "Invalid JSON" warning printed two or three times per command. Warn once per path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(migration): skip profile migration for a config that is not a JSON object A global config holding [] reached saveGlobalConfig, which now refuses it, so init and update failed. null already crashed on a property read. migrateIfNeeded now skips such a file, as it does for a parse failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(telemetry): refuse to write over a non-object global config The telemetry writer had its own notion of an unreadable config: only a JSON parse failure counted. Valid JSON that is not an object slipped through, so updateTelemetryConfig() merged into it and replaced the file -- an array, a number or a boolean became a bare telemetry object, a string spread into numeric character keys, and null threw a TypeError instead of the actionable refusal every other writer reports. Funnel both notions through one predicate: isConfigRootObject() in core/global-config.ts now backs isGlobalConfigUnreadable() and the telemetry reader, so every shape the global guard rejects is classified invalid on read and refused on write. Both writers report the same one-line message via unreadableGlobalConfigMessage(). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(config): read a non-object global config as plain defaults getGlobalConfig() spread the parsed root into its result before the unreadable predicate was consulted, so the shape of the root leaked to every caller: a config of "abc" returned defaults plus the numeric character keys 0, 1 and 2. Check isConfigRootObject() right after parsing and answer with plain defaults, as for a file that did not parse at all. Reported by CodeRabbit as an outside-the-diff finding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(config): stop `config list` crashing on a null config root `config list` re-reads the raw file to mark each value explicit or default, and assigned JSON.parse() straight to rawConfig. A root of `null` then crashed the command with a TypeError stack trace, the one failure mode this PR is meant to remove, and it did so on a read-only command. Normalize a non-object root to {} through the shared isConfigRootObject() predicate so the listing shows plain defaults. Reported by CodeRabbit as an outside-the-diff finding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(config): show the telemetry notice before the first-run write check Since #1835, nothing is tracked until the notice has been shown, so the first-run test must show it before tracking the command. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
626269ed73 |
fix(templates): stop generated skills naming workflows the profile omits (#1775)
* fix(templates): stop generated skills naming workflows the profile omits The `core` profile installs six of the twelve workflows, but the update and apply templates named `/opsx:continue` (6 times) and `/opsx:new` (twice) regardless. On a default install those became `/openspec-continue-change` and `/openspec-new-change` — skills that were never written — so `update-change` refused to create a missing artifact and handed off to a dead end. The only guard was a sentence asking the model to check availability at runtime, 70 lines above the two places it hits the wall. `command-references.ts` decides how a reference is spelled; nothing decided whether it should be emitted at all. Add that: templates author both wordings with `optionalWorkflow()`, and `getSkillTemplates()` / `getCommandTemplates()` — the one place every generation path already funnels the resolved workflow set through — pick a branch before the reference transformers run. A profile that omits a workflow now gets a concrete `openspec status` / `openspec instructions` fallback instead of a reference to a skill that does not exist. Closes #1734 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(changeset): describe profile-aware workflow references Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(init): assert the core profile names no uninstalled workflow The end-to-end init test pinned the runtime availability hedging that #1734 is about, and asserted `/opsx:continue` appears in the default profile's generated update workflow — the bug itself. Assert the fixed behavior instead: neither `/opsx:continue` nor `/opsx:new` appears, and the CLI fallback is stated outright, for both the update and apply surfaces. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(templates): resolve every cross-workflow reference, not just core's The first commit fixed the two templates the default profile broke on. Every other cross-workflow handoff had the same shape, and arbitrary subsets are reachable: a `custom` profile is whatever the user picked, and `openspec update` re-derives a workflow set from what it finds on disk (legacy tool overrides, inferred Codex workflows) without passing it through getProfileWorkflows. So resolve all of them: - `apply` -> archive; `continue` -> apply, archive; `ff` -> apply; `new` -> continue; `propose` -> apply; `update` -> apply, archive; `archive` and `bulk-archive` -> sync. - `onboard`'s two command-reference tables are built from the installed set rather than printed in full with an "only if installed" caveat, and its explore, resume and next-step prompts are resolved the same way. Two supporting changes: - `onlyWithWorkflow()` plus a whole-line rule in the resolver: a conditional that owns its line takes the line with it when it resolves to empty, so a dropped table row cannot leave a blank line that ends the table in markdown. - `generateSkillContent()` and `generateCommand()` now throw on an unresolved marker. A generation path that skips the choke point fails loudly instead of writing `[[opsx:...]]` into a user's SKILL.md. The propose and ff surfaces keep their deliberate wording difference (#258): the command surface never invites "ask me to implement", so its missing-`apply` fallback names the CLI rather than a conversation. The guard test now runs the property over every subset that could expose a reference — each workflow alone, everything but one, the empty set, and the two shipped profiles — for skills and commands, in both spellings. Twenty-plus of those cases fail against the previous commit. Only `openspec-onboard` changes in the skills/ mirror: with every workflow installed, all other templates render byte for byte as before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(changeset): cover the full cross-workflow reference fix Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(templates): validate conditionals before choosing a branch Resolution discarded the unselected branch and only then checked for residual markers, so a truncated block inside the *missing* branch was accepted for a profile that installs the workflow and rejected for one that does not. Profile-dependent authoring errors are exactly what this module exists to remove. Validate the authored text up front instead: every marker must be one of the three recognized forms, and they must appear as a flat sequence of if / else / end. A malformed block now throws identically for every profile. The post-resolution check stays as a backstop. Caught by CodeRabbit on #1775. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: state the profile-aware handoff rule in the skills reference alfred-openspec on #1775: docs-lab/reference/skills.md described several handoffs as unconditional while this change deliberately emits a CLI or conversational fallback when the profile omits the target. Stated once, above the entries, rather than as a caveat on each of the eleven affected Response and Creates rows: the page's recipe is one fact per row, and repeating the same conditional eleven times would bury the contracts it exists to state. The rows keep naming the skill that owns the next step, which is the fact a reader looks up; the rule above them says what happens when that skill is not installed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(workflows): fold #1735 into the profile-aware references #1735 fixes the same issue (#1734) by removing the optional handoffs outright. This PR resolves them at generation time instead, which is strictly better for the template layer: an install that has `continue` still gets told about it. So the mechanism here wins and #1735's content is folded in, rather than the two competing for the same lines. What #1735 had that this did not: - src/commands/workflow/instructions.ts. The CLI's own runtime strings named the openspec-continue-change skill. Those are chosen at run time, so optionalWorkflow() cannot reach them; taken from #1735 verbatim. - The blocked-state fallback. It was a one-line pointer; it now carries #1735's full CLI recovery (select the next `ready` artifact, not `skipped` or `blocked`, read its rules with `openspec instructions`, keep the selected `--store` on both commands) plus the tracking-file repair path and the `missingArtifacts` field it branches on. The installed branch still names `/opsx:continue`, so neither audience loses. #1735's update-change.ts rewrite is not carried over: this PR already covers all six of those sites conditionally, which is the better answer. Both of #1735's test suites come across, and they are worth more here than there. test/core/templates/profile-handoffs.test.ts asserts that no generated file names an uninstalled workflow across every tool and all three delivery modes, which is the property this PR's mechanism exists to provide, and it passes against it. test/commands/profile-handoffs.test.ts covers the runtime CLI strings. The two guards are complementary: that one is broad on tools and deliveries, this PR's own profile-workflow-references.test.ts is broad on workflow subsets. #1735's command-references.test.ts assertions could not be carried as written, since they assume the reference is gone unconditionally. Replaced with a case that resolves the template against a set without `continue` and asserts the fallback carries the whole recovery. Verified it fails when the fallback is shortened. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: name the core-profile fallback on the two rows that hit it The rule above the entries covers every profile, but apply-change and update-change are Core skills whose rows name openspec-continue-change, which the core profile never installs. On the default install those rows now say what the generated skill points to instead: openspec status and openspec instructions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): drop em dashes from the release note Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
086c93b40b |
chore(deps-dev): bump changesets, eslint and typescript-eslint (#1901)
Applies dependabot #1898 (lockfile-only: @changesets/changelog-github 1.0.1, @changesets/cli 3.0.2, eslint 10.10.0, typescript-eslint 8.70.0) plus the two follow-ups its CI needed: the transitive esbuild 0.28.1 -> 0.28.2 bump in allowBuilds, and the pnpmDeps hash in flake.nix computed by the Nix job. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
7090e16d74 |
fix(schema): validate the apply block against declared artifacts (#1868)
* fix(schema): validate the apply block against declared artifacts parseSchema checked each artifact's requires but never the apply block, so schema validate passed a schema whose apply.requires named an artifact that does not exist or whose apply.tracks named a file no artifact generates. At run time apply skipped the unknown id, turning the apply gate off, or blocked forever on a tracked file nothing produces. Reject both in parseSchema, naming the bad value and what the schema declares. tracks is compared to generates by exact string, the same comparison the tracked-tasks lookups use, so any schema that parses is one they can resolve. * fix(schema): warn instead of failing the load on an unmatched apply.tracks apply.tracks is a path that apply reads as written, not an artifact id. A schema that tracks a hand-written TODO.md, or one file under a glob generates such as tasks/main.md, loads and applies correctly on main. Rejecting it in parseSchema made every command on that schema fail. Keep the unknown apply.requires id as a load error, the same as an unknown artifact requires. Report an apply.tracks path that matches no artifact's generates as a warning from `openspec schema validate`, which still exits 0. Move the docs note from legacy docs/customization.md into docs-lab (schema-yaml.md validation section, cli.md schema validate). The schema-yaml.md table had said unknown apply.requires IDs go unreported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(schema): describe apply.tracks as a generates mismatch, not as ungenerated The apply.tracks check compares `tracks` to each artifact's `generates` with exact string equality, but its warning said the tracked file "is not generated by any artifact". That is false for the case this PR deliberately supports: `tracks: tasks/main.md` under `generates: tasks/*.md`, where the glob really does generate the file and only the strings differ. The diagnostic now names the real condition (the `tracks` value does not exactly match any `generates` value, so OpenSpec cannot tell which artifact's progress it tracks) and keeps both remedies. Both docs-lab pages, the changeset and the JSDoc that repeated the claim are corrected the same way, and a new CLI test pins that the glob case is described as a mismatch and never as ungenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(schema): pin apply.tracks matching across Windows path separators The tracked-tasks lookup compares apply.tracks and generates as plain strings, so a backslash on one side and a forward slash on the other must warn, and the same backslash spelling on both sides must not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
a5bf5c6844 |
fix(validate): report requirements outside delta sections (#1804)
* fix(validate): report requirements outside delta sections * docs(test): document orphaned-requirement test helpers * test(parser): pin orphan reporting to the reader's section rule Cover a header the reader does not match exactly (`## ADDED Requirements`), which must be reported, and a repeated `## ADDED Requirements` header with a non-delta section between the copies, which must not. Add a patch changeset matching the other parser fixes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
6a87a514ec |
test(store): give the git probe cleanup hook the setup's timeout (#1900)
Deleting the 12000 fixture files on the Windows runner outlasts vitest's default 10s hook timeout, so the suite failed after every test passed and knocked PRs out of the merge queue. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
fede536c27 |
fix(update-change): draft the requested edit in step 4, write only in step 5 (#1840)
* fix(update-change): draft the requested edit in step 4, write only in step 5 Step 4 told the agent to "Apply the requested edit" while step 5 and the guardrails told it to write only after the user confirms each revision. "Apply" is a write verb in this very document - step 5 is titled "Confirm and apply" - so the same request either wrote immediately or stopped and showed the revision first, depending on which passage the agent weighed. Step 5 is the workflow's only write path, so its confirmation guarantee was unenforceable whenever step 4 governed. Step 4 now drafts and says explicitly that it writes nothing; step 5 claims every write and shows the drafted edit for confirmation. Both delivery surfaces and the committed skill carry the same wording, and a regression test slices step 4 out of each body so no write verb can reappear there. Closes #1836 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(update-change): keep every edit verb out of the write-free step Adversarial review of the first commit found three gaps. Step 4 still opened a bullet with "Revise only files that already exist" - the same shape as the bug, an imperative edit verb inside the step that now declares it writes nothing. It reads as a scoping rule, but "revise" is the write verb everywhere else in this body ("proposed revision", "Which artifacts were revised"). It now says "Propose revisions only to files that already exist". The guard's `not.toMatch(/\bWrite\b/)` was inert and inverted: it was case-sensitive, so it never matched the wording it was meant to pin, and it could not be made case-insensitive because the fix's own text says "do not write anything yet". It now strips that one sanctioned sentence and rejects any remaining form of write or apply, case-insensitively - so lowercase "write the drafted edit now", the dangerous case, is caught. A second assertion rejects any step 4 bullet opening with Revise/Edit/Update/Rewrite. The changeset claimed no write verb could reappear in step 4, which was not what the old guard did. It now states what the guard checks. Also passes the surface label into section() so a marker drift names the surface that broke. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(update-change): let no passage outside step 5 authorize a write Mutation-testing the first guard found it defeatable: 20 of 25 mutations broke the #1836 contract and still passed. The two worst were structural, not lexical - the guard only sliced steps 4 and 5, so an authorization placed in the intro, in step 3, in the Guardrails or in the Output section governed the agent while no assertion ever saw it; and step 5 carried only positive assertions, so its gate could be kept and then exempted in the next sentence, or the whole-body confirmation guardrail deleted outright, with nothing failing. The guard now pins step 4's draft rule and the whole of step 5 verbatim, requires the whole-body guardrail to survive, and scans every other passage for write verbs and their synonyms (commit/save/persist/ overwrite/reapply/flush/emit), verb-free equivalents (perform, carry out, in place, to disk), consent-bypass phrasing, and imperative edit bullets including ones led by an adverb. All 22 mutations are now caught. Two wording corrections came out of the same review. "nothing earlier writes to disk" was false - every openspec invocation persists a telemetry id via the root preAction hook - so step 5 now claims every artifact write instead. Step 4 says "in the conversation, not in files", borrowing explore.ts's phrasing, so "draft" cannot be read as writing a draft file. docs/commands.md carried the same apply-vs-confirm collision two lines above the confirmation bullet, contradicting the worked example directly below it; it now says "Drafts your requested revision". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(update-change): catch more imperative edit verbs outside step 5 CodeRabbit noted `- Modify the artifact now` slipped past the imperative-bullet guard. Added Modify, Amend, Patch and Replace, each verified to trip the guard. `Change` is deliberately excluded: step 6 already opens a bullet with "Change already implemented ...". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(update-change): prove the write-gate scan trips in every section The outside-step-5 scan was only ever checked against the real body, so nothing showed it could fail. Injecting a verb-free authorization into the intro, Input, steps 1-2, Output or Guardrails passed on both surfaces (7 of 10 sections). The bare "already applied" allowlist entry also erased "treat the requested edit as already applied" before any check ran. - Move the scan into a function and add a mutation table: one injected authorization per section, asserted on skill and command bodies. - Spell every sanctioned mention in full context. - Flag any mention of the requested edit outside the pinned draft rule. - Widen the consent-bypass filter (needs no / exempt from / skip confirm). Also revert the legacy docs/commands.md edit: docs-lab reference/skills.md is the published page and already states the confirm-then-write contract. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): drop em dashes from the release note Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
8fc65b7f70 |
fix(tasks): count checkboxes under every list marker (#1862)
* fix(tasks): count checkboxes under every list marker The task counter behind list, status, view, instructions apply, validate --archived and archive's incomplete-task check read only `-` and `*` bullets. A GFM task is a list item, and CommonMark also allows `+` and ordered `1.` / `1)` markers, so unchecked ordered or plus tasks were dropped from every count: the change read as complete and archive skipped its incomplete-task warning. Accept every CommonMark list marker in TASK_LINE_PATTERN, keeping its existing tolerances (indentation, CRLF, a missing space after the marker). Every consumer goes through parseTaskLines, so this one change fixes them all, and task-numbering validation now sees these tasks too. * docs(tasks): list every counted checkbox marker in schema.yaml reference The apply.tracks section listed only - and * checkbox forms. Task lines under + and ordered markers now count, so show them and name the marker rule. Also use American spelling in the changeset. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
92fb72d1dc |
fix(workflows): create the main spec when a capability is new (#1701)
* fix(workflows): create the main spec when a capability is new The agent-driven archive workflow told agents to "compare each delta spec with its corresponding main spec" and said nothing about the case where that main spec does not exist yet. Comparing against nothing reads as "already synced", so the agent took the archive branch and the new capability's main spec was never written — the change landed in changes/archive/ with openspec/specs/ still empty. `openspec archive` already handles this: buildUpdatedSpec creates the spec from the delta's ADDED requirements, rejects MODIFIED/RENAMED with "only ADDED requirements are allowed for new specs", and warns past REMOVED. The guidance now says the same thing, so the agent path and the CLI path agree: - archive-change: a missing main spec counts as changes needed and is named in the summary as a spec the sync will create — never as already synced. - sync-specs: MODIFIED and RENAMED have no requirement to act on when the main spec is absent, so the sync stops and reports rather than inventing one; REMOVED is skipped with a warning. Guidance text only — no CLI, parser, or archive behavior changes. Closes #1222 Closes #1264 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(sync): never create a main spec with nothing to put in it CodeRabbit caught a gap in the previous commit: step 4b now tells the agent a REMOVED-only delta has nothing to remove, but step 4d still read as "create the main spec if the capability doesn't exist yet" unconditionally. Following both would write a spec whose `## Requirements` section is empty. Verified against the CLI on a REMOVED-only delta targeting a capability with no main spec: Specs to update: parking: create ⚠️ Warning: parking - 1 REMOVED requirement(s) ignored for new spec. Validation errors in rebuilt spec for parking (will not write changes): ✗ Spec must have at least one requirement Aborted. No files were changed. So step 4d is now gated on the delta having ADDED requirements to seed the spec with, and says what the CLI reports when it does not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: define "main spec" and close the no-ADDED archive loop Hardening pass over the two fixes in this branch. Guidance: the archive step's verification pass re-runs the same comparison the fix touched, so a delta that can create nothing — no ADDED requirements, no main spec to merge into — would have been reported as "still needs sync" after a sync that correctly created nothing, and an agent could loop on it. That case now short-circuits with the reason, matching `openspec archive`, which refuses it with "Spec must have at least one requirement". Docs: the glossary defined "delta spec" but never "main spec", which is half of #1647's terminology complaint. It now defines the term and says that for a new capability the main spec is created by the archive rather than written up front; concepts.md says the same in the delta-section table and the archive process. The docs site generates from docs/ at build time, so no website files change. Changeset rewritten in the house style (prose, no commit header; the changelog-github action supplies attribution) and renamed descriptively. All three CLI branches this guidance describes were verified end to end: ADDED against a greenfield repo creates the spec and carries its Purpose; MODIFIED reports "target spec does not exist; only ADDED requirements are allowed for new specs"; REMOVED-only aborts with "Spec must have at least one requirement" and writes nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(glossary): a standalone sync creates the main spec too The "Main spec" entry said the spec is created "by the archive", but the "Sync" entry two sections down says /opsx:sync creates it as well, without archiving — and specs-sync-skill's "New capability spec" scenario is the sync's own behavior. Names both paths so the two entries agree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(workflows): clarify removed deltas for missing specs * fix(workflows): preserve explicitly retired missing specs * fix(archive): preserve explicit skip-sync choice for blocked deltas --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
4c369e022b |
fix(explore): make the capture request the write confirmation (#1832)
* fix(explore): make the capture request the write confirmation
Explore's write-confirmation rule named `openspec new change` as an action
requiring a separate yes/no, while the capture branch told the agent to
transition "seamlessly" into running it. Both readings were defensible, so
the same request either wrote files immediately or stopped and asked.
State the resolution in all three places: an explicit capture request is
the confirmation, for the change and artifacts that request names. The
guardrail keeps its teeth where #1715 reported the problem — an
agent-proposed capture, or work beyond the requested scope, still asks.
Closes #1828
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(explore): guard the capture branch against a re-added confirmation gate
Also disambiguate the scope fence in the IMPORTANT block: "the artifacts
that request names" parses as a relative clause, and it is the sentence an
agent weighs first. Match the article used by both restatements.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(explore): put the capture discriminators where the decision is made
Four hardening findings from review of the first pass:
- A yes to an offer the agent made looks identical to a user-initiated
capture request at the point the branch decides. The discriminator sat
190 lines away in Guardrails. Move it into the branch, and require the
offer to name what it would create.
- "Do not ask for a second confirmation" contradicted step 2 nine lines
below it, which requires asking before expanding the capture. Narrow it
to re-asking for what was already asked for.
- Scope the carve-out to change artifacts, so it cannot be read to reach
the workflow configuration #1715 reported an agent editing.
- The Guardrails bullet restated the whole contract a third time, in a
quick-reference list whose next-longest entry is 43 words. Replace with
a pointer to the branch that owns it.
Tests: the three not.toContain guards could not see a gate phrased in
words they did not anticipate. Replace with a structural check that
collects every consent-bearing sentence and requires each to be sanctioned
— inside the capture branch with no topic filter, since a gate written
there is about the capture whether or not it says so. Mutation testing:
kills 6 of 8 contradiction mutations that survived before, and all three
sites stay independently pinned. The two survivors reverse the resolution
without any consent word and are noted as review-only.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(explore): keep the contact clause in the scope fence
The previous commit reintroduced "the change artifacts that request
names", the garden-path parse that
|
||
|
|
8146be5546 |
fix(list): skip unresolvable entries when dating changes (#1866)
* fix(list): skip unresolvable entries when dating changes To sort changes by recency, list stats every file inside each change, and any entry it could not stat failed the whole command. A dangling symlink, such as the .#file lock Emacs keeps beside every file with unsaved edits, or a symlink loop made list exit 1 and list --json report no changes at all. Skip an entry that no longer resolves (ENOENT or ELOOP) when computing a change's last-modified time. Valid symlinks are dated as before, and any other error still fails the listing. * test(list): pin that a permission error still fails the listing Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
72bf7600a5 |
fix(completion): restore .bashrc byte for byte on bash uninstall (#1872)
* fix(completion): restore .bashrc byte for byte on bash uninstall Uninstall removed the OpenSpec block but kept the blank separator line install adds after it at the top of .bashrc, then popped every trailing blank line and wrote the file back without its final newline. The next tool to append with >> (nvm, conda, rustup) merged its first line into the user's last line. Drop only the separator line install added when the block sits at the top, and leave the rest of the file, including its final newline, trailing blank lines and CRLF line endings, as it was. * test(completion): cover content right after the block and CRLF without final newline Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
388d34473a |
fix(init): keep user files in legacy command folders (#1874)
* fix(init): keep user files in legacy command folders Legacy cleanup removed each pre-skills tool's <tool>/commands/openspec/ folder recursively whenever it existed, deleting any command the user kept there along with OpenSpec's three files. init runs that cleanup unprompted when there is no TTY, so agents and CI lost those files without --force. Directory entries now name the files OpenSpec wrote there. Cleanup deletes only those, removes the folder only once nothing else is left in it, and reports each entry it kept. A folder holding none of OpenSpec's files is no longer treated as legacy, and a folder holding only them is removed exactly as before. * docs: drop legacy migration-guide edit from legacy cleanup fix docs/ is legacy; the canonical docs-lab page (help/legacy/migration.md) is still a skeleton, so there is nothing to update there yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(init): recognize legacy command files by their OpenSpec markers Legacy cleanup treated any regular file named proposal/apply/archive in a <tool>/commands/openspec/ folder as OpenSpec's, so a user-authored file with one of those names, including one swapped in while the upgrade prompt waited, was still deleted. Every legacy slash command was generated with the OpenSpec markers, and OpenSpec refused to update one without them. A file now counts as OpenSpec's only when its content still carries them, and cleanup checks that again immediately before each unlink. A symlinked command folder is never followed. Test fixtures now use marker-wrapped content like the real generated files. Closes #1873 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(init): recheck each legacy command file before the directory cleanup deletes it The directory cleanup loop classified a folder's managed files once and then unlinked every one of them. A file the user swapped in after that scan was deleted and reported as deleted. Each file is now checked for the OpenSpec markers immediately before its unlink; a file that fails the check is kept and reported as kept. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
2ef6fbde3d |
fix(config): run an EDITOR that carries arguments (#1878)
* fix(config): run an EDITOR that carries arguments config edit passed the whole EDITOR/VISUAL value to spawn as the program name with shell: false, so common settings such as `code --wait` failed with ENOENT, and the uncaught rejection printed a raw Node stack trace. Run the value the way git does: through sh -c '<editor> "$@"' with the config path as a positional argument, and through cmd.exe on Windows so .cmd shims resolve. A value that is itself the absolute path of an existing file still runs directly, so unquoted paths with spaces keep working. A failed start, a non-zero exit or a signal is now reported as a one-line error and the command exits 1. * fix(config): split EDITOR into argv instead of running a shell Run the editor without a shell. The EDITOR or VISUAL value is split into a program and arguments (double quotes everywhere; single quotes and backslash escapes on POSIX; literal backslashes on Windows) and the config path is appended as its own argument, spawned via cross-spawn with shell: false so Windows .cmd shims such as code.cmd still resolve. Shell metacharacters in the value are now inert. Show the install hint only when the program is missing (ENOENT), not for EACCES or EPERM. Move the EDITOR documentation from legacy docs/cli.md to docs-lab/reference/cli.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
9f8dec5dd9 |
fix(store): refuse to remove a store that contains another store (#1880)
* fix(store): refuse to remove a store that contains another store store remove deleted the target folder recursively after checking only the target's own metadata. Another registered store living inside that folder, such as a shared store vendored as a git submodule (a layout store register accepts), was deleted with it, uncommitted work included, and its registry entry was left pointing at a missing path. Refuse with store_remove_contains_registered_store when another registration's canonical root is inside the folder. The check runs in the beforeCommit hook, under the registry lock that commits the removal, which now receives the registrations that will remain. * docs(store): move nested-store remove refusal to docs-lab Document store_remove_contains_registered_store on the canonical docs-lab CLI reference instead of legacy docs/cli.md. docs/agent-contract.md keeps the error-code entry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
208b5b5510 |
fix(store): stop a store named specs or changes becoming the root (#1882)
* fix(store): stop a store named specs or changes becoming the root Stores live at ~/openspec/<id>, so a store with the id specs or changes is itself ~/openspec/specs or ~/openspec/changes. classifyOpenSpecDir counted that folder as planning shape, which made $HOME the nearest root for every command under the home tree: defaultStore was never consulted and new changes were written outside the store. A specs/ or changes/ directory that carries store metadata is a store root, not planning content of the directory above it. * test(store): canonicalize phantom-root identities and cover an alias path Compare resolved root paths with fs.realpathSync.native on both sides, and add a symlinked-alias case that must resolve the same canonical store root, per review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
5d221456e5 |
fix(store): let setup --no-init-git run inside a git repository (#1884)
* fix(store): let setup --no-init-git run inside a git repository The nested-repo guard refused a setup path inside another Git repository even with --no-init-git, which creates no repository, so a store at ~/openspec/<id> was impossible for anyone whose home directory is a dotfiles repo. The CLI never passed the existing bypass either: prepareSetupInput ignored its options. Skip the guard when initGit is false, and forward --init-git and --no-init-git into the prepare step. The default setup and an explicit --init-git still refuse. Two store.test.ts cases passed --no-init-git while asserting the refusal; they now run the default setup the guard exists for. * docs(store): move setup nested-repo note to docs-lab The setup --no-init-git explanation belongs on the canonical docs-lab CLI reference, not legacy docs/cli.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(store): compare canonical paths in setup --no-init-git test Canonicalize payload.store.root and the registry local_path with fs.realpathSync.native before comparing, per review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
e01ed070f1 |
fix(archive): refuse delta files the merge path never reads (#1870)
* fix(archive): refuse delta files the merge path never reads validate and archive read a change's deltas only from specs/<capability-path>/spec.md, but the spec-driven artifact graph counts any markdown file under specs/ as written. A delta at specs/user-auth.md was reported done by status and ready by apply, rejected by validate only as having no deltas, and then archived with exit 0 and nothing merged. Name every markdown file under specs/ that carries delta sections but is not a capability's spec.md. validate reports it as an error with the spec.md its requirements belong in, archive runs that validation and refuses the change, and apply lists it in its warnings. --no-validate and changes with no spec files behave as before. * docs(schemas): move delta file placement note to docs-lab The legacy docs/ tree is frozen; the canonical page for the spec-driven delta layout is docs-lab/reference/schemas/spec-driven/index.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dwin Gharibi
|
db560ae33f |
fix(validate): reject a scenario header with no body (#1858)
A requirement whose only scenario is a header with nothing under it passed validate and was then refused by archive. The delta scenario counter counted every #### header, while the spec path that archive uses to validate the rebuilt spec keeps a scenario only when its body has content, so the two verdicts disagreed and the archive error did not name the requirement. Share one rule, hasScenarioBody, between both paths and read a scenario body up to the same boundary the spec path uses, so validate rejects exactly what archive rejects. The error names the requirement and explains that a header with no body does not count. |
||
|
|
46ff91f2d6 |
fix(parser): read change deltas with the archive reader (#1856)
* fix(parser): read change deltas with the archive reader `show --json --deltas-only`, the command OpenSpec's error text recommends for inspecting parsed deltas, read deltas through ChangeParser's own section lookup instead of parseDeltaSpec, the reader archive applies. A bullet-form REMOVED was invisible to it, so it fell back to the proposal's What Changes prose and reported an invented MODIFIED while archive deleted the requirement. A repeated section header was read once, and a RENAMED line written with * or + was dropped. Derive every operation from parseDeltaSpec, keeping the existing section parser for requirement text and scenarios, and describe a change that has delta spec files by those files alone. A change with no delta spec files still falls back to the What Changes bullets. * fix(parser): keep the prose fallback for legacy spec files with no delta section A change whose specs/ held full future-state specs (no ADDED/MODIFIED/REMOVED/RENAMED section) lost its What Changes deltas: show --json reported none, change list counted zero, and archive printed an extra No deltas found warning. The prose fallback now applies whenever no spec file carries a delta section, which is exactly main's behavior for such changes, while a bullet-form REMOVED (which has a REMOVED section) is still read from the delta file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dwin Gharibi
|
4b5c07a0c2 |
fix(parser): drop closing hashes from requirement names (#1860)
CommonMark lets an ATX heading end in a closing run of `#`s, so `### Requirement: Late Fees ###` renders as `Late Fees`. Requirement names kept the run, so a REMOVED written that way missed the requirement and archive exited 0 with a false "treating it as already removed" warning, while a closed MODIFIED or RENAMED heading failed as not found. normalizeRequirementName now strips the closing run with the rule scenario names already use: only a run preceded by a space or tab counts, so `C#` keeps its `#`. Every reader goes through it, and the main-spec duplicate check now does too, so a closed and an open heading of one requirement are reported as duplicates. |
||
|
Dwin Gharibi
|
767d63c926 |
fix(archive): refuse requirement names differing only in case (#1864)
ADDED and the RENAMED target compared requirement names exactly, while REMOVED and the RENAMED source already treated a name that differs only in case or interior whitespace as a mistyped header. An ADDED `late fees` beside an existing `Late Fees`, or a rename to `LATE FEES`, therefore archived cleanly and left two contradicting copies of one requirement in the main spec, which validate then accepted. Both now refuse with an error naming the existing requirement. The source of a rename is exempt from the target check, so a case-only rename of a requirement to its own name still applies, and ADDED is still checked against the spec as it stands after the earlier operations, so a variant of a requirement the same delta removes or renames away is allowed. |
||
|
|
6e62b1d522 |
fix(parser): refuse malformed RENAMED pairs (#1806)
* fix(parser): refuse malformed RENAMED pairs * docs(test): document RENAMED pairing test helpers * test(parser): pin RENAMED pairing across header copies and bullet markers Cover the two shapes main gained after this branch was cut: a FROM in one `## RENAMED Requirements` copy and a TO in another are both reported as unpaired, and unpaired lines written with `*` or `+` are reported like `-` ones. Add a patch changeset matching the other parser fixes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
e571b5b9ae |
fix(security): harden CLI against hostile-repository inputs and clear dependency advisories (#1835)
* fix(deps): upgrade vitest to 4.1.11 and override fflate
Clears GHSA-82fw-gwwq-j7x9 (path traversal / arbitrary file read via
@vitest/mocker redirect mock), the subject of all three open Dependabot
alerts. No patched 3.x exists — 4.1.11 is the first fixed release — so the
major bump is unavoidable.
Two things the plain Dependabot bump (#1823) got wrong, which is why its
tests failed on every platform:
- It left @vitest/ui on 3.x, which dragged vite/esbuild to 0.28.2 and broke
the allowBuilds pin assertion in pnpm-workspace-config.test.ts. Upgrading
@vitest/ui in lockstep keeps esbuild on 0.28.1.
- Vitest 4 no longer lets an arrow function stand in as a constructor
implementation, so the ZshInstaller module mock threw "is not a
constructor" across 8 completion tests. Converted the three mock factories
to function expressions.
Also adds a pnpm override for fflate (GHSA-px8p-9vwx-vf98, infinite loop on
malformed ZIP64), which @vitest/ui 4.1.11 still pulls at 0.8.2.
`pnpm audit` is now clean: 0 vulnerabilities across all severities.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(core): bound schema size and stop prototype keys shadowing worksets
Two low-severity robustness defects found during the security review.
Workset lookups tested membership with `state.worksets[name] !== undefined`
on a plain-prototype object. `constructor`, `toString`, `valueof` and
friends are all valid kebab ids, so `openspec workset add constructor`
reported "already exists" against empty state, `getWorkset` returned a
function off the prototype, and `withoutWorkset` took the found branch for a
workset that was never there. All three sites now use `hasOwnProperty`.
This was never prototype *pollution* — nothing is written through these
keys and Zod's `z.record` drops `__proto__` — only a correctness defect.
`SchemaYamlSchema.artifacts` was unbounded while `validateNoCycles` walks it
with a recursive DFS, so a project-local schema declaring a long `requires`
chain crashed the CLI with an uncaught `RangeError: Maximum call stack size
exceeded` instead of a validation error. Capped at 1000 artifacts, which
also bounds the reference-resolution and graph work.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(security): stop repo-supplied text forging agent instructions
OpenSpec prints a pseudo-XML envelope that an AI coding agent consumes as
instructions, and interpolated repo content went in raw. The tags carry
authority - <project_context> means "background only", <task> means "do
this" - so a value that closes its own block is promoted from data to
directive.
Confirmed against a fresh build: a config.yaml `context:` value containing
`</project_context><system_override priority="critical">` landed a top-level
override block outside every "do NOT treat as instructions" guard. The same
breakout worked from `rules`, `description`, a dependency description, and a
schema `instruction`. A change directory name containing a quote forged
attributes on the <artifact> tag. In markdown output, a `context` line
starting with `##` forged a peer of the printer's own headings.
src/core/references.ts already had sanitizeInline written for exactly this
threat, documented as such, and simply was not applied here - it also only
flattened newlines, which one line of markup is enough to defeat. Extended it
and added three siblings beside it: escapeEnvelopeText, escapeEnvelopeAttribute,
and escapeEnvelopeCloseTags for content that must stay verbatim.
Template bodies deliberately get only their closing tags neutralized: the
shipped templates are full of `<!-- ... -->` comments and <placeholder>
markers that are copied into the generated artifact, so blanket escaping
would write <!-- into every file. A block can only end at a closing tag,
so that is the load-bearing control.
Rules and operation guidance are flattened but explicitly not truncated -
they are instructions an agent must follow in full.
Separately, `openspec update` decided skill freshness from the generatedBy:
line alone and never compared bodies, so appending a step to a generated
SKILL.md still printed "All 1 tool(s) up to date". Skills now get the same
byte-comparison command files already had, and the plan names the reason.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(security): remove super-linear scans and tighten write containment
Three regexes ran over whole repository files with a `\s` class that crosses
newlines under the `m` flag, so `^\s*` re-scanned from every line start. The
blowup is in the *failing* scan - a file with no `generatedBy:` line at all -
which is also the realistic attack file. Measured on this machine:
extractGeneratedByVersion, 63 KB whitespace SKILL.md 3,103 ms -> <5 ms
legacy-skill compare, 63 KB whitespace frontmatter 8,131 ms -> <5 ms
buildUpdatedSpec, 195 KB of `<!--` openers 6,817 ms -> ~90 ms
The first two are reached by `openspec update`, the first command run after
cloning. The third is reached from extractPurposeSection during `openspec
archive`, on the write path.
The scans now use `[ \t]` and walk lines, and maskHtmlComments is an indexOf
scan that visits each character once instead of a lazy regex that re-scans to
EOF from every `<!--`. Both rewrites were fuzzed against the originals -
200,000 random inputs each, 0 mismatches - so the `--!>` terminator and the
"unterminated comment runs to EOF" rule from #1413 are preserved exactly.
resolveTrustedSpecPath treated a failed containment check as permission to
re-root trust on the symlink's own target, on the theory that monorepo
symlinks may be intentional. A repo shipping openspec/specs/<cap> as a link
out of the tree therefore got `openspec archive` to write attacker-controlled
markdown to <external>/spec.md while printing the in-project path. The
fallback root must now still be inside the project, matching retireSpec,
which already refused to delete an external target.
Also: `validate <id> --type spec|change` short-circuited the name guard that
`show` applies, so a traversing id reached a bare path.join; and markTipSeen
wrote the global config through a predictable <config>.<pid>.tmp at default
0644 instead of the repo's existing writeFileAtomically (random name, 0600).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(security): harden subprocess and shell-config write paths
Defense in depth. The audit confirmed there is no shell injection anywhere in
src/ - no `shell: true`, no user value concatenated into a command line - so
none of these are live exploits; they are the sharp edges next to that line.
Completion install wrote the completions directory into .bashrc/.zshrc inside
double quotes, so a `$(...)` or backtick in HOME/XDG_DATA_HOME became command
execution on every future shell start. Both installers now single-quote the
path through a shared helper.
`feedback` shelled out for two probes (`which gh`, `gh auth status`) directly
alongside free-form user title and body text - the most plausible site for a
future injection regression. Both are execFileSync now, behavior unchanged.
Git subprocesses inherited the default 1 MB maxBuffer with no timeout, so a
large dirty tree made `git status --porcelain` throw ENOBUFS, which gitProbe's
bare catch turned into "no git facts" - `openspec doctor` then silently stopped
reporting uncommitted changes. They now share GIT_EXEC_OPTIONS (15s timeout,
16 MB buffer) the way readCliVersion already did, and the catch distinguishes
a resource failure from "git absent" so the degraded path is no longer silent.
The GITHUB_OUTPUT heredoc in validate-changesets used a fixed EOF delimiter
over a list of PR-authored paths; it is now run-unique.
Finally, both package.json files still carried a `pnpm` block. pnpm 10 uses
that block *instead of* pnpm-workspace.yaml rather than merging with it, which
is exactly the override-displacement trap dependabot.yml documents as #1812 -
and it is where Dependabot writes when it bumps an overridden package. The
block only duplicated `allowBuilds`, so removing it leaves both lockfiles
byte-identical with every advisory override intact, and denies Dependabot the
block to write into. The workspace test now asserts `pnpm` is absent entirely.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(security): pin the update check to TLS and honor telemetry opt-out
The update check asked whatever `npm_config_registry` named, over any
protocol. A code comment asserted that file contents deliberately cannot
choose the destination; that was not true. npm exports every config source it
reads, including a `registry=` line in a repository-local .npmrc that travels
with a clone - reproduced: `registry=http://169.254.169.254/` came straight
through `npm run`.
That is a cleartext GET at an address of the repository's choosing, and it
escalates. The attacker's reply says `{"version":"99.0.0"}`, which triggers
the upgrade prompt whose default is Yes; accepting runs `npm install -g`,
which npm resolves against that same attacker registry. Cloning a repository
and answering one prompt installs an attacker-chosen global package.
Both halves are now closed. The registry override is honored only over https,
falling back to the public registry otherwise, and canSelfUpgrade() refuses
when the resolved registry is not the public origin - a private mirror can
still inform the check but can never drive an install prompt. Redirects must
stay https and on the origin resolved up front, not merely the previous hop,
so no single reply can steer the request elsewhere. The comment now describes
what the code actually guarantees.
Separately, the opt-out env vars were exact-string matches, so DO_NOT_TRACK=true
and OPENSPEC_TELEMETRY=false both silently left telemetry ON - the spellings a
user is most likely to reach for, and inconsistent with the tolerant
isCiEnvironment() helper beside them. Parsing is now tolerant, shared between
both call sites, and fails safe: an unparseable value suppresses the request.
The first --json run also sent an event before the disclosure was ever shown -
the notice is correctly deferred so it cannot corrupt machine-readable output,
but trackCommand fired regardless, and agent-driven --json may be a user's only
mode. No event is sent and no anonymous id is created until the notice has
actually been printed.
No existing guard was weakened: the 256 KB body cap, 3-redirect cap, single
budget timer, strict version regex, argv-based spawn, CI/test guards and the
four-field payload are untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(security): make the close-tag escape linear
CodeQL js/polynomial-redos on the escape added in
|
||
|
Clay GoodandClaude Opus 5
|
3b8e5b6616 |
fix(nix): install shell completions with the flake package (#1785)
* fix(nix): install shell completions with the flake package The flake exposed `openspec completion generate SHELL` but installed no completion scripts, so a Nix install had no completions at the standard locations. Generate the Bash, Fish, and Zsh scripts during postInstall and place them with installShellCompletion. Closes #1740 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: note that cross-compiled Nix builds omit completions Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * ci: run the Nix job when the completion generator changes The Nix build now runs `openspec completion generate`, so a change under src/core/completions can break packaging without touching flake.nix. Also drops the cross-compilation caveat from the Nix install docs: every package this flake exposes is native (`legacyPackages.<system>` has buildPlatform == hostPlatform), so `canExecute` is always true and the completions are never omitted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: move the Nix completions note to the canonical pages docs-lab/README.md makes docs-lab/ canonical and the old docs/ tree legacy, so the fact is recorded in the two docs-lab pages that own it and docs/cli.md and docs/installation.md are back to their state on main. - docs-lab/start/installation.md, Nix: the package ships the scripts at the standard locations, so completion install is not needed. - docs-lab/reference/cli.md, openspec completion: the same exception, stated where a reader looking up the command will hit it, linking to the Nix section rather than repeating the paths. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
7de24044ef |
fix(init): make the universal tool target findable in the picker (#1778)
* fix(init): make the universal tool target findable in the picker Closes #653 `openspec init`'s tool picker is a searchable list of product names. The vendor-neutral target every unlisted assistant is meant to use was named "Shared .agents skills" — after the directory it writes, which is not a word anyone in that position searches for. Typing "universal", "other" or "generic" returned "No matches", so the escape hatch was unreachable and the reporter had to open an issue to find it. Rename the entry to "Other / Universal (shared .agents skills)" and give choices optional `searchAliases` the filter also matches. The picker also dropped every non-alphanumeric keystroke: readline reports punctuation only in `key.sequence`, leaving `key.name` undefined, so ".agents" and "amazon-q" could not be typed at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(init): point at the universal target when a tool search matches nothing "No matches" is where someone whose assistant is not on the list gives up — the picker knows the answer and does not say it. Add an optional `emptyHint` to the searchable multi-select, and have init name the vendor-neutral entry there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(init): close every dead end that hides the universal tool target Hardening pass over the same defect. Reviewing the first fix turned up four more places the answer was withheld: - `openspec update`'s tool picker builds its own choices and never passed searchAliases through, so the same search failed there. - `--tools <unknown>` printed a bare list of ids. It now names the fallback, the scripted counterpart of the picker's empty hint. The hint I first put on validateTools sat on an unreachable branch; the path users actually hit is the "Invalid tool(s)" parse error, and a test now pins it. - The search box dropped pasted text as well as punctuation. Any sequence whose characters are all printable is now accepted, which also lets a space reach the box so "claude code" filters. Escape sequences carry control characters and are still rejected, and the `name` fallback stays single-character so readline names like 'tab' are never typed. - docs-lab still taught the old label in two places. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: keep the FAQ a router and finish the alias list - help/faq.md is a one-liner surface (README's "FAQ is one-liners" rule), so the answer points at the support matrix's Other / Universal section instead of restating the picker's search terms. Drops the em dash that writing.md forbids. - reference/supported-tools.md keeps the search terms, now all nine the picker actually matches: `vendor-neutral` and `agents.md` were added to searchAliases after the first draft of this page. Same correction in the legacy docs/supported-tools.md paragraph. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(init): keep the tool-not-listed hint ASCII The non-interactive fallback hint is new terminal output and carried an em dash, an ambiguous-width glyph in the class #983 covered. A colon reads the same and cannot misalign a terminal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: drop the legacy docs/ tool-matrix edit docs-lab/reference/supported-tools.md already carries the label and search terms. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(init): prove picker punctuation through real readline key events The prompt tests fed a multi-character sequence that readline never emits: it splits a paste into one key per character, so a pasted space still toggles. Drive the handler with real emitKeypressEvents output (fails on main with 'amazonq'), pin the space limit, and stop claiming multi-word paste in the changeset and code comment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
8b99c07bd0 |
fix(status): name the command that resumes a change (#1786)
* fix(status): name the command that resumes a change `openspec status` printed the artifact checklist and stopped. The command that moves the change forward was computed already and shipped in the JSON `nextSteps` sentence, but the text surface never rendered it, so anyone resuming a change had to know the next command by heart. Extract `resolveNextStep` so the command and the published sentence come from one place, and print it as a `Next:` line — matching the idiom `openspec new change` already uses to hand off to `openspec status`. The completion case matters most: "All planning artifacts complete!" reads as "you are done" even while implementation tasks remain, and it is now followed by the `openspec instructions apply` command that resumes the work. Closes #906 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * style(status): keep the loadStatus comment on loadStatus The store-flag note landed between the "single definition" comment and the declaration it describes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(status): cover the next-step line, and record it in the spec The behavior change shipped without the OpenSpec change this repo requires of user-facing work, and without coverage for the paths a reviewer would reasonably ask about. Adds `add-status-next-step`, whose delta modifies `Next Artifact Discovery` in `cli-artifact-workflow` - the requirement that already says status is how you learn what comes next. It now also says status names the command. Coverage added: - Unit tests for `resolveNextStep`, pinning the published `nextSteps` sentences verbatim. Confirmed byte-identical to main's output, so the split into command + sentence provably did not reword the contract. - Custom-schema case: the line is built from the resolved artifact id, so a project with neither proposal/specs/design/tasks still gets a usable command. - Skipped artifacts are never named - they satisfy dependents but must not be created. - `--json` stays parseable and carries no `Next:` line. - `--all` gives every change its own line, and a failed entry none. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(status): assert the next-step line closes the output The spec delta says the text output ends with the `Next:` line, but the assertions used toContain, which a later line would still satisfy. Compare the last non-empty line instead, across all four ready/complete cases and the skipped one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(status): read the closing line CRLF-safely Split on /\r?\n/ so a CRLF stream cannot leave a carriage return attached to the line under comparison, and route the parity check through the same helper instead of its own scan. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: move the status Next: line to the canonical CLI page docs-lab/README.md makes docs-lab/ canonical and the old docs/ tree legacy, so the entry now lives under 'openspec status' in docs-lab/reference/cli.md and docs/cli.md is back to its state on main. Both documented outputs were captured from real runs rather than written by hand: the blocked case in a change with proposal and specs, and the complete case with all four artifacts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(status): drop em dashes from the changeset and proposal Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
09a999bbb2 |
fix(changes): report a change nested in a namespace folder (#1849)
* fix(changes): report a change nested in a namespace folder Specs can be nested by domain (`specs/mobile/tutorial-videos/spec.md`), so laying changes out the same way looks reasonable - but a change is only ever a directory directly under `changes/`. `changes/mobile/refresh-token/` left the real change invisible to every command while `mobile`, the folder around it, was reported as an ordinary task-less change. Nothing said so, and `openspec archive mobile` moved the unfinished change into the archive under the namespace's name with none of its deltas applied. A directory under `changes/` is now recognised as a namespace folder when it carries no change-root artifact of its own and wraps a directory that does. The probe is deliberately conservative: a miss behaves exactly as before, and an ordinary change - including a scaffolded one with no artifacts yet, and one whose only content is a root delta spec - is never reported as a folder. - `openspec list` marks it `not a change` and explains the flat-only layout instead of printing `No tasks`; `--json` gains an additive `warnings` entry. - `openspec show` and `openspec status --change` say the same rather than reporting a change that has no proposal yet. - `openspec validate` reports the nesting instead of "must have at least one delta", with next steps that name the fix rather than delta authoring. - `openspec archive` refuses it outright - burying an active change is data loss, not something to warn about. Closes #1846. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(agent-contract): document the list --json nesting warning Agents read 4.1 as the shape contract, so the additive `warnings` array and per-entry `nested` field have to appear there, along with the instruction not to treat a flagged entry as a change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(changes): harden the nested-change probe and cover status --all Adversarial review of the first commit found three holes. A custom schema may generate every root artifact into a subdirectory (`generates: rfc/proposal.md`). Created by hand, such a change carries no `.openspec.yaml`, so the marker probe read it as a namespace folder wrapping a change called `rfc` - a legitimate change that validated clean before, now refused by validate, status, instructions and archive, with no flag to get past it. The same probe missed the case it was written for whenever the nested change started from its delta specs rather than a proposal: `mobile/refresh-token/` holding only `specs/auth/spec.md` still archived as `mobile`, deltas dropped. A nested change is always hand-made - `openspec new change` rejects a name with a separator - so "mkdir the tree, write the deltas first" is a common way to arrive here. Both come from asking one question. A directory is now recognised as a change by a root artifact OR a populated `specs/`, and a directory holding any file of its own is never a namespace folder. The `specs/**/*.md` shape is fixed by the delta format rather than by the schema, which is what makes it safe to lean on. `change show archive` also reached the probe - it has no reserved-name guard - and offered to rename every dated archive entry into an active change. The reserved name is rejected in the probe itself, so no caller can repeat it. `status --all` read each directory straight through `loadStatus`, bypassing the lookup guard, and printed a whole artifact plan for work that is not there. It now carries the same per-change diagnostic a malformed change does, and the sweep continues past it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(changeset): state the nesting-detection bound CodeRabbit asked for the three-level limit in the release note. Stated as a closing sentence rather than a qualifier on the headline, so the note still leads with what changed for users. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(changes): trust the resolved schema before calling a folder a namespace A hand-made change under a custom schema that generates into a subdirectory (rfc/proposal.md), with no .openspec.yaml and no delta specs yet, was read as a namespace folder and refused by status, show, validate, instructions and archive. The probe now also counts a file at any path the resolved schema generates, the same check status uses to mark an artifact done. Move the flat-change-folder docs from legacy docs/ to docs-lab reference/cli.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
09984b8242 |
fix(validate): warn when tracked tasks have no checkboxes (#1774)
* fix(validate): warn when tracked tasks have no checkboxes Progress counts checkboxes and nothing else, so a tasks.md written as plain bullets or a numbered list is worse than an empty one: `openspec list` and `openspec status` report "No tasks", and `openspec archive` has no incomplete task to warn about. The file reads as finished to the tool and unfinished to a human. `openspec validate` now warns when every task file the change's schema tracks contains list items but not one checkbox, pointing at the first offending line. Reported per change, not per file, so a checklist alongside a prose file stays silent, and only files an artifact actually declares are linted - a bare tasks.md no schema tracks is left alone. Closes #354 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(validate): honor fence delimiter length and width CommonMark closes a fence only on the same character, a run at least as long as the opener's, and no info string. Comparing the first character alone let an inner ``` end an outer ```` block, exposing the bullets of a nested code sample as a task list. The delimiter pattern also loses its end anchor: `.` does not match `\r`, so an anchored info-string group matched nothing in a CRLF file and blinded the scan to fences. Adds the nested-fence, annotated-closer, tilde/backtick, longer-closer and CRLF cases, plus an e2e change whose nested task files are all bullets, asserting both reported paths stay POSIX-separated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(validate): scan rendered content and complete evidence only Hardening pass over the checkbox warning. The scan for the offending line now skips YAML front matter and HTML comment blocks alongside fenced code. A list under `tags:` is metadata about the file rather than the work it tracks, and a commented-out list is not work either; each exclusion can only silence a warning, never drop a real task, which is the opposite trade from the task parser. An unterminated `---` opener rewinds to the top, because that is a thematic break and everything below it is still content. Only a comment opening its own line hides that line, so the template's `## 1. <!-- Task Group Name -->` heading cannot swallow the checklist beneath it. A tracked file that exists but cannot be read now withdraws the warning entirely: "no file here holds a checkbox" is a claim about the whole tracked set, and the checkboxes may be in exactly the file that would not open. `validate --archived` stays the surface that reports an unreadable task file loudly (#205). The message leads with the consequence rather than an accusation, since a file may legitimately carry a bulleted note and no tasks yet. New coverage: every packaged tasks template is asserted checkbox-shaped (the guard fails if a template loses its boxes), a schema tracking tasks by artifact id with no `apply` block, the deprecated `change validate` text output, and an unreadable tracked file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(validate): match CommonMark on fence indent and front matter Two block-scanning defects, both of which hid list items. A fence indented four spaces is an indented code block, not an opener. Accepting it left the scan inside a block that never began, so every list below it went unseen. Fence recognition now stops at three spaces. `----` is a thematic break, not a YAML front-matter delimiter. Matching three-or-more dashes let one open a block that swallowed the list under it until the next `---`. Front matter is now exactly three dashes. Two test defects alongside them. The deprecated-command test claimed to assert the reported line, but the text renderer prints no line for any issue; it now asserts the level and path prefix that surface actually emits, with the line left to the JSON assertion that already covers it. The unreadable-file fixture would have passed for the wrong reason had the mode not taken, since the checkbox it hides would have silenced the warning by itself; the read failure is now asserted first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(validate): name task files relative to a canonical change dir Windows CI caught the report naming a task file `../../../../../../../../runneradmin/AppData/.../tasks.md` instead of `tasks.md`. `resolveArtifactOutputs` hands back real paths while `changeDir` carries whatever spelling the caller resolved, and a short 8.3 alias against its expanded form is a difference in spelling, not in location, so the relative path escaped the change. A symlinked project directory reproduces it off Windows. Canonicalizing both sides recovers the relationship. A path that still escapes falls back to the file name, so no report can leak an absolute filesystem path. Numbering issues are named through the same helper and gain the same fix. The deprecated-command test now asserts the `[WARNING] tasks.md:` prefix that exposed this, and the Windows job is its regression guard: the mismatch cannot be staged on POSIX, where the spawned CLI's cwd is already physical. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(validate): keep indented code out of the uncheckboxed-task scan alfred-openspec on #1774: the scan said it reads rendered content, but LIST_ITEM began with \s* and so reported top-level four-space-indented code such as ' - example output' as an uncheckboxed task list. Under --strict that false positive failed validation on a correct file. A list-shaped line is now taken only below four visual columns of indent, the same cut the fence logic already applies, with tabs counting as four. Genuine nested lists are untouched: this scan reports the first list item it finds and a nested item always sits under a shallower parent, so the parent is reported exactly as before. A list-shaped line four columns deep with nothing shallower above it is not nested under anything, which is what makes it code. Regressions cover space-indented, tab-indented and numbered code samples, and pin both the nested-list case (parent still reported) and three-space indent (not code). Verified the guard bites: removing the column test fails them. Also moves the documentation to its canonical home. docs-lab/README.md says the old docs/ tree is legacy and must stay untouched, so the docs/concepts.md line is dropped and the warning is documented under 'openspec validate' in docs-lab/reference/cli.md, beside the archive merge findings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(validate): skip BOM-prefixed front matter and cap ordered markers at nine digits A prose-only task file that opened with a UTF-8 BOM before its front matter was warned about, because the opener never matched and the tags list was scanned. A number longer than nine digits followed by a period also matched as a list item, which CommonMark does not allow. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(changeset): drop the em dash Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(tasks): use a multi-character marker for the unrecognised-checkbox case A single-character marker such as `[~]` becomes a task once #1773 lands, which would flip this expectation. `[ab]` is not a task under either parser, so the test keeps asserting that checkbox-looking list items that count as no task still warn, whichever PR merges first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Clay GoodandClaude Opus 5
|
b928165276 |
docs(explore): stop claiming explore never writes files (#1838)
* docs(explore): stop claiming explore never writes files Sixteen lines across both documentation trees told users that `/opsx:explore` creates no artifacts and writes no files, full stop. That has been false since explore shipped (#467): its capture branch writes the planning artifacts the user asked for, and can edit an existing change's artifacts. #1503 later made it scaffold with `openspec new change` first, closing #668 and #720. The claim appeared in two shapes. Six lines denied the capability outright ("Explore creates no artifacts and writes no code"). Ten more said the same thing as a timing claim ("before any artifact exists"), which reads as ordinary pitch copy and is what escaped the first pass. Every site now carries one guarantee, worded the same way: explore never writes code, and writes nothing else unless you ask, or say yes when it offers. Four sites described only the user-initiated trigger, which left the offer path - the one a reader actually hits - looking like it did not exist. docs/explore.md and docs/commands.md also gain a positive description of capture where the denial used to sit, including what scaffolding creates beyond the artifacts you named, and how capture differs from handing off to propose (propose writes the set your schema requires; capture writes only what you named). Closes #1833 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(docs): keep the retired explore wording retired A flat list of the phrasings that actually carried the claim, swept over the eleven pages that pitch explore. Fails on main with all sixteen offenders; clean on this branch. Modeled on test/vocabulary-sweep.test.ts, and deliberately a list rather than a grammar. An earlier draft built the grammar - section splitting, code-fence tracking, a conditional-marker exemption so "creates no artifacts unless you ask" would pass - and measured against realistic prose it was imprecise in both directions while returning the same verdict on the real input. The list has no exemption logic to get wrong, and any maintainer can extend it. Phrasings that are only wrong in the absolute ("writes nothing", "creates nothing") are left to review, since the conditional form of each is the wording the failure message recommends. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(docs): pin the explore capture contract, not the word The guide check matched any "capture", so "explore automatically captures every artifact" passed. Both explore.md and commands.md now must name the user trigger, `openspec new change`, and the named-artifacts scope, with no capture line claiming it happens unprompted, and keep "never writes code". Also scope the explore.md guarantee to the setup files a new change needs, and make the commands.md offer name the change and its scope, which the template asks for on main and after #1832. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(docs): accept negated unprompted-capture wording, catch non-capture verbs The unprompted check matched "automatically" on any capture line, so the correct "Explore does not automatically capture artifacts" failed, while "Explore automatically writes planning artifacts" was never scanned because it lacks the word capture. Check each clause of lines naming explore or capture for an unprompted write verb with no preceding negation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
openspec-release-bot[bot]andgithub-actions[bot]
|
9d4e5974e5 |
Version Packages (#1822)
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>@fission-ai/openspec@1.13.0 v1.13.0 |
||
|
Clay GoodandClaude Opus 5
|
e4e112d94f |
chore(deps): declare pnpm overrides only in pnpm-workspace.yaml (#1816)
The security overrides were declared twice: in pnpm-workspace.yaml, with the advisory comments explaining each pin, and again under package.json's pnpm.overrides. The copies are not additive — pnpm 10 uses package.json's block instead of the workspace list when both are present — and Dependabot rewrites plain-name entries in package.json whenever it bumps the same package. So a routine bump silently displaces the pins that patch advisories, and fails the equality test that guards them (#1812). Keeps one declaration, in the file that carries the reasoning, and asserts the mirror stays gone. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
aedf4d0c64 |
fix(archive): preserve blank lines inside code fences (#1798)
* fix(archive): preserve blank lines inside code fences * docs(test): document fence-preservation test helpers * chore(changeset): track the fenced blank-line fix The fix changes archive output for any spec documenting a fenced sample with consecutive blank lines, so it belongs in the changelog. Release tracking only validates changesets that exist; it never requires one, which is why CI stayed green without it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
d9e1a28c38 |
fix(update): refresh generated files that drifted (#1808)
* fix(update): refresh generated files that drifted * test(update): isolate command drift from missing files and host config * chore(changeset): track the command-drift fix `openspec update` now reports and repairs tools it previously called up to date, so users will see a behavior change. That belongs in the changelog. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
8251763ecd |
fix(parser): apply every delta section header (#1802)
* fix(parser): apply every delta section header * test(parser): assert section presence for a header after another section * chore(changeset): track the repeated-section fix Deltas that previously applied only part of what was authored now apply all of it, which changes archive output for affected changes. That belongs in the changelog. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
fadac3e1c9 |
fix(parser): accept all CommonMark list markers in deltas (#1800)
* fix(parser): accept all CommonMark list markers in deltas * docs(parser): document the REMOVED and RENAMED readers * chore(changeset): track the list-marker fix A removal or rename written with `*` or `+` now takes effect where it previously did nothing, so existing specs can change on the next archive. That is a user-visible behavior change and belongs in the changelog. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Clay Good <hi@claygood.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |