v1.0.0-rc.8

The documentation site carries both versions, with a picker at the top left and a page of what 1.0 adds; the pipelines are fewer and clearer — one CI, one release, one scheduled workflow — and npm audit and the licence check pass again.

Added

• The site carries both versions (REQ-400, REQ-401). The documentation site showed only the stable line, so a reader had no way to see that a 1.0 candidate existed or what it adds. Built with --channel stable|next --versions stable=…,next=…, every page and the landing page have a version picker at the top left: the stable entry opens the stable docs, the candidate's opens what 1.0 adds. The candidate's pages, published under next/, say they document a candidate, lead back to the stable docs and edit next/1.0. Built without --versions, the badge is as it was.
• What is new in 1.0 (REQ-402). docs/whats-new-1.0.md explains each feature of 1.0 with its commands, and names every candidate; a test fails when a candidate in this changelog is missing from it.

Changed

• One release workflow. release.yml replaces publish-npm.yml, publish-docker.yml and publish-github-packages.yml: a v* tag runs the whole of ci.yml on the tagged commit, then publishes to npm with provenance, then pushes the image, which now waits for npm instead of publishing on its own. The version and the dist-tag are decided once; a prerelease is still published under next and its image tagged with the version only (REQ-281). New versions are no longer published to GitHub Packages; the versions there stay installable.
• CI calls the E2E journeys, and runs the OS-independent checks once. e2e.yml is now only called (by ci.yml, and so by the release) or run by hand. The agent-contract check, the self-validation, the registry build and the snapshot tests run once on Ubuntu instead of on all six matrix legs, and the core unit suite no longer runs a second time after the coverage run that already includes it.
• The weekly checks are one workflow. scheduled.yml replaces docs-nightly.yml, mutation.yml and openspec-compat.yml, runs only in this repository, not in forks, and checks the terminal recordings on the Node major they were made with: on Node 22 against recordings made on Node 24, every recording read as out of date, which is why the nightly check failed every night.
• The workflows follow one set of rules. Read-only permissions unless a job needs more, one concurrency group per workflow and ref, a timeout on every job, third-party actions pinned to a commit (Dependabot bumps them). Security also runs on next/**, and its SBOM job no longer fails on argparse 3, whose PSF-2.0 licence is now allowed; overrides for qs, fast-uri and zod clear npm audit. On a pull request that touches the docs, pages.yml builds the site without deploying it.

v1.0.0-rc.7

After the sixth microservices run of truck-flote: a part that uses the contracts is written after them, and a requirement still being drafted that waits for another repository is the order the story is built in, not a failure of the workspace check.

Fixed

• A part is written after the contracts it uses (REQ-395). The parts of a story were written at the same time, and tracking, finding nothing in contracts, designed an API of its own that web then used directly (truck-flote, MS6-1). change author now refuses the specs, design or tasks of a part that shares a criterion with the contracts repository while the contracts' part specifies nothing (author_contracts_first); --force writes it anyway.
• A waiting requirement of an open change is the build order (REQ-396). Before the build, workspace check failed with workspace_dependency_pending for every requirement waiting for another repository, though the story harness builds them in that order (MS6-2). For a requirement still in an open change it is now a warning; a delivered requirement whose dependency is not still fails.

v1.0.0-rc.6

After the fifth microservices run of truck-flote: the architect who decides that a requirement waits for another repository writes it into the requirement, so the story harness builds the parts in order, and a quoted placeholder operation is no longer taken for a citation.

Fixed

• The design carries its dependencies into the traces (REQ-390). The specs of a layered change are written before its design, so an architect who decided that a requirement waits for contracts:REQ-002 wrote it only in design.md, and the story harness, which orders the parts from the traces, built them all at once (truck-flote, MS5-1). The rules of change instructions design, and so the prompt of change author design, now say that a depends= or api= the design decides goes into the requirement's specgate:trace under specs/ too, and the story context of a sub-change's design says the same.
• A placeholder operation is no citation (REQ-391). A design quoting api=contracts/fleet.openapi.yaml#<operationId> as guidance was reported as layer_design_dependency_untraced; an api= whose operation is a placeholder is now guidance (MS5-2).

v1.0.0-rc.5

After the fourth microservices run of truck-flote: a contract cited by a requirement not yet built is a warning until it is delivered, so the contracts repository builds its requirements one by one, and a service or web requirement of a story that cites nothing of the contracts repository is pointed out.

Fixed

• A contract is written one requirement at a time (REQ-385, REQ-335): validate failed api_contract_missing for a requirement still Draft that cites a contract file it will write, so the contracts repository's first requirement was refused for its later ones (truck-flote, MS4-2). A citation that does not resolve is now an error only for a delivered requirement or the one being delivered, and a warning otherwise.
• A part that shares a criterion with the contracts cites them (REQ-386): in a story with a contracts repository, change validate warns layer_no_contract_cited for a requirement of another repository that cites none of its requirements or operations (MS4-1).

v1.0.0-rc.4

After the third microservices run of truck-flote: an agent that ticks its own task is no longer refused for touching the specification, the dependencies and operations a design names are checked against the traces, and the contracts repository's agent writes the contract its requirements describe.

Fixed

• What a design says a requirement waits for reaches its trace (REQ-380, REQ-381): in the third microservices run the panel's design named depends=contracts:REQ-002, depends=tracking:REQ-002 and the operations it uses, its traces carried none, and change validate said ✔. Each depends= or api= design.md names and no specgate:trace carries is now a layer_design_dependency_untraced warning, naming the requirement on that line.
• The contracts repository writes its contracts (REQ-382): its agent described them in requirements and wrote no file, so nothing could cite an operation. The story context now asks the contracts member for the OpenAPI or AsyncAPI file under contracts/ and api=contracts/<file>#<operationId> on each requirement, and the other members to cite it with depends= and api=.
• Ticking a task is not an edit of the contract (REQ-375): an agent that marked the task it had just delivered was refused as agent_touched_protected_path, every attempt, though the harness writes the same tick itself (truck-flote microservices run 3). A change to a change's tasks.md that only changes the box of its tasks is now accepted; any other edit of it is still refused, and the prompt says the harness ticks the tasks.
• A quoted story title is read whole (REQ-376): workspace draft listed "Optimización de rutas — the front matter was split at the comma inside the quotes.

v1.0.0-rc.3

After the second microservices run of truck-flote: a tick in tasks.md no longer withdraws an approval, so a change is built past its first requirement; the workspace's agent proposes the stories, a story says which criteria each repository answers and keeps its questions, the agents that write a sub-change see the whole story, and the story is built only as far as its dependencies are delivered.

Fixed

• A delivered requirement no longer un-approves its change (REQ-370, REQ-371): delivering a requirement ticks its task in tasks.md (REQ-353), and the tick changed the hash the tasks' approval was bound to, so the harness refused the change's second requirement as "not approved: tasks". A layer is now hashed with every task box read as open: a tick, by the harness or a person, keeps the approval, and any other edit still asks for it again. Approvals recorded by 1.0.0-rc.1 and rc.2 keep counting.
• A prompt file Windows still holds never fails the command (REQ-372): four change author runs side by side ended in EBUSY … unlink after their agents had written their layers. Removing a prompt file now retries briefly and then leaves it to the system — in change author, the drafting agents and the harness.
• An agent proposes the brief's stories (REQ-360): workspace draft --agent with no story named ran no agent and said nothing; the agent now fills the front matter's stories:, writing only docs/brief.md, and the client's text is put back if it moved. With stories named, --agent without a story id is refused.
• Each criterion names its repositories (REQ-361, REQ-362): a story's ## Repositories lists the criteria each answers (- fleet: AC-1, AC-2); each Discover says which are its own and which the others', and workspace check warns about a criterion no repository answers or two claim.
• A story's questions wait for their answers (REQ-363): they go in docs/stories/<id>/questions.md; workspace propose refuses while one is open, unless --allow-open-questions.
• A drafted story keeps none of its form's hints (REQ-364).
• The Discover stays business (REQ-365, REQ-344): the guidance on depends= and api= that tripped layer_discover_technical in every repository moves to the sub-change's design.md.
• change author hears of the story (REQ-366): story.json in each sub-change names its workspace, and the prompt for any layer carries the story's other parts and their requirements.
• A requirement waits for what it depends on (REQ-367): workspace harness run --story starts only the requirements whose dependencies are delivered, names the others waiting, and exits 1.

v1.0.0-rc.2

After the first microservices run of truck-flote (five repositories, one story across three of them, nine requirements delivered in parallel): the workspace takes the client's brief and drafts its stories, a story's intent and criteria reach every repository, the story is built in the order of its dependencies, and init --yes adopts the folder it is run in.

Breaking

• specgate init --yes adopts a folder that already has code (REQ-249, modified): it scaffolded a separate project inside it (my-spec-driven-app/), so a scripted init in a repository made a second one. --yes now only skips the questions; --new, --out, --config, --multi-stack and --forja still scaffold.

Fixed

• change validate reports what change approve refuses (REQ-350): a layered change validated, then approval refused it for requirements with no kind. Validation now fails with change_not_approvable for each finding approval would block on.
• The agent writing a change's requirements is told what they need (REQ-351): kind=, actor=, and a feature file of its own.
• Two requirements naming one feature file are reported (REQ-352): change validate and change archive refuse with change_feature_shared; archiving would have kept only one's scenarios.
• A delivered requirement ticks its tasks (REQ-353): done, which the harness runs, ticks the tasks of the open change that name the requirement.
• change --help describes the three layers (REQ-354), and docs/migrating-to-1.0.md says how to install a candidate just published (--prefer-online) and how to move a forja project to it.
• The workspace takes the client's brief (REQ-339..341): specgate workspace draft puts a root brief.md below a front matter that names the brief's stories and their repositories, workspace draft <story> --agent "<cmd>" drafts a story's intent and criteria from the brief, confined to the story, and specgate status in a workspace repository shows the workspace and the next step instead of failing on a missing matrix.
• Every repository receives the story (REQ-342..344): workspace propose takes a drafted story, copies its intent and criteria into each sub-change's discover.md and names the story's other repositories and how to write depends= and api=; workspace check warns workspace_story_diverged when a repository's criteria are not the story's; each harness is told the story's other parts.
• A story is built in dependency order (REQ-345): workspace harness run --story starts a repository whose part waits on another's undelivered requirement after that repository has finished; the dry run shows the levels.
• The live view and the story's cost (REQ-346, REQ-347): every JSON document of the studio says charset=utf-8, and a story's cost counts its archived parts.
• Short repository names, and the logs ignored (REQ-348, REQ-349): workspace init names truck-flote-fleet as fleet, prints name, path and role in their own columns, and ignores .specgate/workspace-runs/.

v1.0.0-rc.1

The first candidate of the 1.0 line, for teams of several repositories and roles: a change in three layers with their owners, a workspace of repositories with stories across them and its own live view, approvals per layer and harness packages per role, the backlog following the phases, the two gaps measured, principles, drift and API contracts checked, and specgate migrate 1.0 to move a 0.27 project. Published under the npm dist-tag next; latest stays 0.27. See Migrating to 1.0.

Breaking

• depends=<repo>:REQ-NNN is a dependency on another repository (REQ-294): inside a repository it is no longer an unknown_dependency; the workspace judges it.
• A change has three layers, each with its owner (REQ-282..REQ-289, ADR-0042): change new, propose, propose --from-brief and --from-ticket write discover.md (product: context, use case, acceptance criteria - AC-1: …), design.md (architect) and tasks.md (developer) under the new layered schema, and no longer write proposal.md. change new --schema spec-driven keeps the 0.27 layout. A change written with 0.27 stays valid: its proposal.md is read as its Discover, and a missing design.md is a warning naming specgate migrate 1.0.
• depends=<repo>:REQ-NNN is a dependency on another repository (REQ-294): inside a repository it is no longer an unknown_dependency; the workspace judges it.
• A 1.0 change is built once it is approved (REQ-315, ADR-0043): harness run skips a requirement of an open change of the layered schema until every written layer has its approvals, with harness_not_approved. approvals: { required: never } in harness.config.yaml keeps the 0.27 behaviour, always asks it of 0.27 changes too.
• A change has three layers, each with its owner (REQ-282..REQ-289, ADR-0042): change new, propose, propose --from-brief and --from-ticket write discover.md (product: context, use case, acceptance criteria - AC-1: …), design.md (architect) and tasks.md (developer) under the new layered schema, and no longer write proposal.md. change new --schema spec-driven keeps the 0.27 layout. A change written with 0.27 stays valid: its proposal.md is read as its Discover, and a missing design.md is a warning naming specgate migrate 1.0.

Added

• specgate migrate 1.0 (REQ-325..REQ-329): on a committed 0.27 project, moves each open change into the three layers — proposal.md to discover.md word for word, a design.md drafted from it, tasks.md kept, schema: layered — never touching the archive, and writes docs/specs/migration-1.0.md with what it did and what is left to a person. --dry-run changes nothing and prints the same report; a second run does nothing; a dirty tree is refused. specgate status names the command while an open change is still written for 0.27. Every breaking change, and how to stay on 0.27: Migrating to 1.0.
• The workspace, live (REQ-320..REQ-324): specgate studio in a workspace repository serves its /live — a panel per repository with the requirement in flight, its gate step and the agent's last step; each story with its parts open, building, archived or missing, and the parts waiting on another repository's undelivered requirement named; the cost per repository and per story. specgate workspace harness run --story <id> starts every repository's harness for its part at once, and none when one repository's base already fails the gate. workspace live --json prints the model.
• The organization's principles (REQ-330..REQ-332): docs/specs/principles.md with principles_version and source (a principles file, or pack:<pack_id> when a domain pack delivers it). specgate check names the version and warns principles_behind when the source has a newer one; a principle with run= or forbid= … in= is checked by the gate (principle_failed; level=warn for advice).
• Behaviour changed without a specification (REQ-333, REQ-334): check warns spec_drift for each commit since the base that changes production code and names no requirement in its message or in a test it changes; specgate drift reports it for CI, and drift: gate in harness.config.yaml fails both.
• A requirement points at an API operation (REQ-335, REQ-336): api= in its trace comment, a JSON pointer or an operationId of an OpenAPI or AsyncAPI contract; validate fails when it does not resolve, and specgate contract check lists the operations no requirement cites.
• specgate adopt --scope <path> (REQ-337, REQ-338): specify one area of a large repository; adoption warns adopt_too_big when it finds more areas than the eight it proposes.
• The two gaps (REQ-300..REQ-304): harness report says, for each requirement that needed rework, whether the spec was clear and the code diverged (spec → implementation) or the spec missed part of the use case (intent → spec). It suggests one from what it recorded — a rejection the agent fixed, naming the check that caught it; an answered question, a review note or a modified delta — and a person sets it with --classify REQ-NNN --gap spec-impl|intent-spec --reason "...". The report shows both shares overall and per module and what to strengthen; the studio's report shows both shares. The run ledger now records the gate stage that rejected each attempt.
• The board follows the change (REQ-305): alm sync moves each change's ticket — its ticket: or origin: alm:<key> — to the state of its phase: proposed, building once a requirement has a harness/REQ-NNN branch or is Implemented, archived. Each provider has a default (Jira status category, Azure Boards state, a GitHub label or a closed issue, a Linear state type) and phases: in alm.config.yaml names a board's own. A move already made is not made again (.specops/alm-phases.json), and --dry-run prints each move. mirror: false keeps alm sync from creating an issue per requirement where the tickets are the source.
• What the ticket gains comes back as notes (REQ-306): alm pull brings each open change's new comments, and a note when the ticket's description changed, into its review.md — never into the proposal or the delta.
• One sub-issue per repository (REQ-307): a change that lists repositories: gets a sub-issue of its ticket for each, created once.
• Linear (REQ-308), a fourth built-in provider through its GraphQL API: team_key and token_env.
• alm phase and alm move (REQ-309): where a change stands, without the network, and its ticket moved there now; both are MCP tools (specgate_alm_phase, specgate_alm_move). New provider capabilities (phase, subIssues, comments, readText) are optional, so a community provider written for 0.27 still loads.
• A workspace of repositories (REQ-290..298, ADR-0041): specgate.workspace.yaml names the repositories of one product, and specgate workspace init|status|check|propose say where the product stands, run every repository's gate at once, resolve ids qualified with their repository (tracking:REQ-012), hold a requirement back until the one it depends on in another repository is delivered, and split a business story into a change in each repository it touches — done when every one is archived. See docs/workspace.md.
• Roles and an approval per layer (REQ-310..REQ-315, REQ-319, ADR-0043): roles: in harness.config.yaml names who holds each role; change approve <id> --layer discover|design|tasks records an approval by the layer's owner — product, architect, developer — with approvals.quorum for how many people a layer needs. Each approval goes in the change's approvals.json with a hash of the layer, kept in the archive; editing an approved layer asks for its approval again. The studio's Review shows each layer's approvals and approves the layer the viewer owns.
• Role packages (REQ-316..REQ-318, ADR-0043): harness/<role>.md, with applies-to by kind, capability or tag, reaches the prompt of the requirements it concerns under "Role constraints"; the prompt event, the run record, the live view and harness report name each package as role@version, and the review check gives one line of advice per package.
• The layer rules (REQ-284..REQ-287): change validate warns when the Discover names a technology, when the design does not answer an acceptance criterion, when a task names no requirement, and when the Discover differs from the version it was agreed at. change validate --strict fails on them.
• The layers are named where people look (REQ-288, REQ-289): change status lists discover, specs, design and tasks with their owner ("Write discover.md (product)"), the drafting guides say which layer the agent writes, and the studio's review lists each layer with its owner and whether it is written.

Fixed

• A release candidate is never installed by default (REQ-281): every publish workflow treated a pushed v* tag as latest, so a v1.0.0-rc.1 would have become the default npm install and the latest image. A version with a prerelease part is now published under the dist-tag next, and its image is tagged with its version only.

v0.27.9

After the seventh truck-flote run: the harness checks Docker before it starts, the report names scenarios as the spec does, a date is one value, and the kept agent is seen live.

Fixed

• D6 reads a date or a time as one value (REQ-277): "at 2026-10-29 10:00:00" was read as the numbers "29", "00" and so on, and the agent had to list each one in assumptions.md before the draft could be reviewed. An ISO date, a time and a date-time are now one value each.
• The agent config set agent keeps for Claude Code is seen live (REQ-278): the command status suggests, claude -p < {prompt_file}, is now kept with --output-format stream-json --verbose and piped into specgate harness events --from claude, so the studio's live view shows the agent and not only the gate. A command that already pipes or sets an output format is kept as it is.
• A stopped Docker is said before any agent runs (REQ-279): with Docker Desktop stopped, harness run passed the specification and the architecture, then spent its three attempts on tests that failed in fifteen seconds with "Could not find a valid Docker environment", each handed to the agent as a failing test. harness run and the studio's Build now check Docker first when a quality check runs in it or the tests use Testcontainers, and refuse with the fix; a test command that cannot reach Docker stops the requirement and is told to the person, not the agent.
• The studio's report titles each scenario from the specification (REQ-280): a delivered requirement of a draft showed SCN-002 � <what happens>, the template line of the draft's DRAFTING.md. Titles now come from the open changes' deltas, the capability specs and spec.md only.

v0.27.8

0.27.7 as it was meant to ship. Its publish stopped on four new tests whose repositories had no git identity on the CI runners; the Docker image 0.27.7 was published, the npm package was not.

Fixed

• The tests of REQ-264, REQ-267, REQ-269 and REQ-271 give their repositories a git identity, as the other harness tests do.
• The REQ-266 test compares real paths as Windows names them (RUNNER~1 and runneradmin are one folder), and the coverage run in CI has a larger heap: on macOS it ran out once every test had passed.

[0.27.7] � 2026-10-28

After the sixth truck-flote run: the harness agent can write, a Docker check works in a worktree, every gate step is seen while it runs, and a reviewed draft no longer turns the branch red.

Fixed

• The client's brief at the root goes below the front matter (REQ-259): with brief.md pushed first and forja's template in docs/brief.md, draft --agent wrote the front matter over the "Paste the client's brief here" placeholder and the person pasted the text by hand. draft now puts the root file's text there first, keeps the root file, and says so; a body the person wrote is left alone.
• BRIEF-SETUP.md is removed once the front matter is complete (REQ-260): it stayed untracked, and the harness refuses a tree that is not clean.
• D6 reads a value made of listed parts (REQ-261): "1234-BCD � Ejes" and "Luc�a Mart�n � E000001234567890" were unlisted although every part was; a value joined with �, � or � is listed when each part is.
• An answer in questions.md no longer leaves its requirement blocked unnoticed (REQ-262, REQ-263): the draft said Ready to review and status kept four answered requirements "Waiting for an answer". The checklist now reports each answered question whose requirement is still Needs Clarification, with the fix and --agent, and status lists it under "Answered � update the spec".
• The sbom check writes the bill of materials of a Quarkus application (REQ-276): its pom skips deploy, and CycloneDX then wrote nothing ("Skipping CycloneDX goal, because module skips deploy"), so the dependency scan had nothing to read. It now runs with -Dcyclonedx.skipNotDeployed=false.
• Every gate step is seen while it runs (REQ-273..REQ-275): harness run printed attempt 1/3 and nothing more for 19 minutes, and /live stayed empty, while a semgrep check hung. The setup command, validate --strict, the end-to-end test, the architecture check, the test command and each quality check are now a gate-start event and a gate event with its ms, written as each happens � the quality checks used to be reported only once every check of the stage had run � and a started � and passed � in 3m 05s line of the run, without --verbose and whatever the agent command is. /live names the step that is running, with its image and how long it has run, and the studio's Build moves to Revisa la calidad when a quality check starts.
• The harness gives Claude Code permission to write (REQ-264): claude -p < {prompt_file}, the command the docs gave, wrote nothing in print mode and spent three attempts on "the agent produced no files". The harness now adds --permission-mode acceptEdits right after claude, as the drafting commands do, and says so; an attempt that writes nothing ends the requirement instead of running the same command again, pointing at docs/agent-setup.md.
• A ./ inside quotes stays as written on Windows (REQ-265): an agent's allowance 'Bash(./mvnw:*)' reached Claude Code as 'Bash(.\mvnw:*)'.
• Docker checks work in the harness's worktrees (REQ-266): a worktree's .git names a host folder the container does not have, so semgrep failed to list files and hung until its 15-minute timeout. The repository's git folder is now mounted read-only, with GIT_DIR and GIT_WORK_TREE pointing at the worktree.
• A check that could not run is reported to you, not to the agent (REQ-267): a gate check that is to write SARIF and wrote none � it timed out or failed first � stops the requirement with its output, instead of telling the agent to "fix what the check found" for two more attempts.
• The reviewer and the adversary read a draft's requirement (REQ-268): their prompts said spec.md had no section for a requirement of a reviewed, unarchived draft; they are now built from the project as the harness judges it, like the implementer's.
• harness report counts each requirement once (REQ-269): a failed run and a passing one of the same requirement read "1 of 2 passed". The latest outcome counts, every run's time stays in the cost, and a run stopped by hand is in the ledger, its requirement reported as stopped.
• The studio's report judges the project as check does (REQ-270): after --chain delivered a draft's requirement, the report said "No pasa" for a feature the written matrix has no row for until the draft is archived.
• The agent is kept once (REQ-271): specgate config set agent "<command>" writes it to harness.config.yaml, with the permission above; status names the step while it is missing, and a harness run --agent � ends with the command that keeps it.