Skip to content

v1.3.0

Latest

Choose a tag to compare

@stn1slv stn1slv released this 22 Aug 12:55
· 1 commit to main since this release
8a7817b

A compatibility release. Spec-Kit generalized several conventions this extension was written against, and shipped 1.0.0 with an explicit no-stability-promise for extensions. Nothing here changes what archival means; it changes which projects it works in.

Changed

Feature directories in every layout spec-kit produces. Timestamped names (specs/20260814-101500-export) and nested scope layouts (specs/billing/006-invoice-settings) now archive correctly. The three-digit prefix is no longer a signal anywhere: a feature directory is one under specs/ that directly contains spec.md, and the input grammar recognises a reference by path shape. Because nested layouts make basenames ambiguous, a feature is now named everywhere by FEATURE_ID, its path relative to the repository root, so specs/billing/006-invoices can never be mistaken for specs/reporting/006-invoices. Passing a scope directory is a named error rather than something that might expand into a batch run.

Agent context files are discovered, not guessed. Since core 0.12.0 the CLI does not touch these files at all; the opt-in agent-context extension owns them. This command now runs that extension's own lookup: its config first, then the integration key in .specify/init-options.json against its defaults map, then the old three-name probe only as a last resort. Those three filenames are the mapped anchor for twenty of the thirty-seven integrations, so the probe was right more often than not and wrong in two ways for the rest: a Copilot, Cursor or Qwen project was not found at all, and because the probe takes the first name that exists rather than the project's own, a project anchored on AGENTS.md that also carried a stray GEMINI.md was written to the wrong file. Every configured anchor is now updated, a configured marker pair is honoured, and a target that is missing or fully enclosed in its markers is skipped and named rather than created or written into.

The first-party bug extension's report layout. .specify/bugs/<slug>/ is read alongside the feature-scoped specs/###-feature/bugs/BUG-###.md, under the same bounded-read discipline. Repo-level reports are not feature-scoped, so they need attribution, and exactly one channel grants it: a **Bugfix**: annotation in the feature's own artifacts naming the slug. That template carries no field naming a feature, so there is no honest second channel; resemblance, dates and touched files never attribute a report. Attribution costs no file read at all, because a report's slug is its directory name.

Also: a py: script variant so the command uses the runtime the project chose, an .extensionignore that cuts the installed copy from 50 files to 5, category and effect in the manifest, and __SPECKIT_COMMAND_*__ tokens in place of literal /speckit.… references, which named a command that does not exist on hyphen and skills agents.

Requirements

Spec-Kit 0.14.0 or later. The old >=0.1.0 floor was never verified against anything. 0.14.0 is where scripts/python began shipping in the wheel, which the new py: entry needs in order to resolve. There is no upper bound: every lookup added here degrades to previous behaviour when its input is absent. Users on older cores should stay on v1.2.2.

Upgrading

specify extension add archive --from https://github.com/stn1slv/spec-kit-archive/archive/refs/tags/v1.3.0.zip --force

Verification

Every claim about upstream was checked against a local checkout of spec-kit v1.0.1 rather than from memory. The install was smoke-tested with the real CLI: a release zip installs into a clean project, puts exactly five files in .specify/extensions/archive/, and reports v1.3.0.

The fixture round ran 16 invocations across 13 cases, plus 5 re-runs after the final review, expectations registered in a commit before each round. The bounded-read canaries are the sharpest result: not one of the five planted phrases reached main memory or the agent file, including the two sitting inside the section of assessment.md the command legitimately opens, and an unattributed bug report was never opened, classified or listed.

Three rounds of four-model review preceded it. Round 1 found that the repo-level bug support had been written against a format the bug extension does not produce, and that the fixture had invented the same format, so the tests were confirming the rules instead of checking them. Round 3 found a fixture overlay that pre-archived the very feature its own case was meant to archive, which had silently invalidated that case. tests/fixture/BASELINE-v1.3.0.md records both rounds and traces each result to the run that produced it.

Known gaps

The community catalog entry still describes v1.2.2, so specify extension info archive reports the old version and floor until a submission lands upstream. specify extension list reads the installed manifest and is correct.

Three findings are recorded in the baseline and deliberately not addressed here: whether an artifact that already names a feature should still receive its missing sections, whether exact heading matching is the right trade against an upstream rename, and a re-archival case where a feature's retired items return under fresh IDs. The last is not a regression in this release; v1.2.x behaves identically.

Intentional regression

A feature reference is recognised by shape, so any specs/... token in guidance text is rejected as a second feature, where before only numbered forms were. Name a path in prose without the specs/ prefix when guidance must mention one. The path-less form was kept deliberately narrow so it did not widen alongside: it matches only a token opening with three or more digits that then end it or meet a hyphen, so 2FA, 3rd-party, 24/7 and v2 stay guidance, and so do measure tokens such as 90-day and 24-hour.