Public roadmap: SpecSync 6.0, and what adoption is deciding next

[0xLeif]

SpecSync 6.0 is at 6.0.0-rc.9. 5.2.0 remains the latest stable release. This post replaces the "after 5.0" roadmap, which predates the 6.0 line entirely.

The honest framing of this release: rc.1 through rc.9 were not planned, they were driven. Almost every fix below came from adopting the tool in anger on a real repository — increasingly, on somebody else's — and recording what broke, rather than from a feature list. The roadmap below is therefore mostly what adoption has already decided, plus a short list of questions it has raised and not yet answered.

Breaking, and the thing to read first

Windows is no longer a supported target as of 6.0. No Windows binary is published (#722, in rc.8). 6.0 ships five artifacts: linux-x86_64, linux-x86_64-musl, linux-aarch64, macos-x86_64, macos-aarch64. Run SpecSync under WSL, or build from source — cargo install specsync still works on Windows. The packaged GitHub Action now refuses a Windows runner with that message instead of requesting an asset that no longer exists.

Two facts decided it, and the second matters more — which is worth stating plainly, because the first on its own does not carry the argument. Across five weeks of v5.2.0 the Windows asset was downloaded once, against 462 for macos-aarch64 and 447 for linux-x86_64. But linux-aarch64 was downloaded zero times over the same window and is deliberately retained, so a download count alone would prove too much. What separates them is the second fact: every job in ordinary CI runs on ubuntu-latest, so the Windows executable was published without ever being exercised, while linux-aarch64 is built from the same source the Linux lane exercises end to end.

That is how #715 happened: specsync view failed with "Cannot parse frontmatter" on every spec in the project, in any checkout with core.autocrlf=true, and it survived for weeks on the one platform that shipped a binary nothing tested. It was found by an adopter, not by us.

No Windows correctness was removed, and none may be. A teammate on Windows commits CRLF files and a colleague on Linux reads them; that case is fully supported and guarded. CRLF frontmatter tolerance, the single canonical strip_frontmatter, the .gitattributes eol=lf pins, Windows-reserved and Windows-invalid filename guards, MAX_SLUG_BYTES and its MAX_PATH justification, junction and reparse-point rejection, and every #[cfg(windows)] block are unchanged. Requirement wording that had scoped those guarantees to "every platform SpecSync ships a binary for" is rebound to the platforms a repository may be checked out on — read literally, the old phrasing would have narrowed each guarantee the moment the shipped set narrowed, which is the opposite of the intent.

The release-candidate qualification lane still runs Ubuntu, macOS and Windows. It is the only place the retained #[cfg(windows)] code is compiled and run, and removing it would recreate exactly the condition that produced the view defect.

What 6.0 changes structurally

• Slug identities replace CHG-NNNN ordinals. Identity comes from state.json, never from the shape of a name (fix(6.0): identity must come from state.json, never from the shape of a name #658), succession is ordered by when a change happened rather than how it is named (refactor(6.0): succession must be ordered by when a change happened, not by how it is named #659), slugs are legal directory names on every platform a repository may be checked out on (fix(6.0): a slug must be a legal directory name on every platform we ship #661), and the ordinal is retired so the ledger stays readable forever (refactor(6.0): retire the ordinal and keep the ledger readable forever #665). This removes numbering collisions from the identity path. Nothing allocates into .specsync/change-sequence.json any more. It is still written, though: floor_sequence_ledger_to_committed raises a stale working-tree copy to the committed high-water mark before staging and merges acknowledged_collisions (bug(change): change check --commit self-commits change-sequence.json backwards, regressing the high-water mark #533). An earlier version of this post said "nothing writes it" — that was wrong, and it came from taking an error message in the source literally rather than reading the function beside it.
• The lessons loop closes (feat(lessons): close the lessons loop at proposal, build, and archive #697, rc.6). What a change learned is folded back into the module's own context at proposal, at build, and at archive, so the next change to that module starts from the last one's dead ends rather than rediscovering them. ship names the fold-back too (fix(lessons): ship must name the fold-back too, and fold #697's bundle #700, docs(lessons): say how the fold-back terminates, and that ship names it too #710).
• The trust anchor is where evidence entered history, not any commit that re-introduces it (security(6.0): a trust anchor must be where evidence entered history, not any commit that re-introduces it #663), and a reopen extends the committed ledger rather than merely counting itself (security(6.0): a reopen must extend the committed ledger, not merely count itself #666).
• A semantic delta is bound to the approval that signed it (fix(change): a semantic delta must not change after the approval that signed it #711, rc.7), and no later approval may withdraw that binding (a portable v5.0.1 approval downgrades the delta binding to "no claim" and lets a swapped delta through #719, on main).
• Forward and backward compatibility inside the 6 line is a stated property: a newer 6 is readable by an older 6 (fix(6.0): a newer six must be readable by an older six #652), and the forward-compatibility valve is true everywhere it is claimed (fix(6.0): the forward-compatibility valve must be true everywhere it is claimed #655).
• Release candidates are installable without release-grade provenance (fix(release): a release candidate must be installable without release-grade provenance #669), on every platform that ships a binary (fix(release): the lane must be able to read the tag that triggered it #668, fix(release): the Windows RC sidecar must be readable by the tool that verifies it (#670) #670).

What the release candidates fixed, and where each landed

release	fix
rc.3	The anchor predicate recognises squash-merged archives (#677). It previously asked whether a change's active workspace path appeared on the default branch, which a workflow-v2 change squash-merged in one PR never has. #677 stays open for its remaining half.
rc.3	An orphaned verification commit is reopenable again (#673). reopen now admits commit unreachability as a staleness axis in its own right, instead of only content drift.
rc.3	init and change new name the lifecycle you are on (#678). An upgraded 5.x repository silently stayed on workflow v1 and only found out at ship.
rc.4	A schema that cannot be parsed no longer reports every declared table as missing (#672), and an ADD COLUMN that agrees with an existing column is a no-op.
rc.4	docs/ADOPTING.md names the remedy for path ownership, not just the trap: --spec and --no-spec-change coexist (#682).
rc.5	db_tables declared without a configurable schema_dir is a notice, not a strict-gating warning (#684). Gating a release on advice the reader cannot take is not drift detection.
rc.6	Ship readiness is a content question, not a history one (#689). This is the big one for squash-merging repositories — see §1 below.
rc.6	The merge-before-finalize warning names what merging early actually costs (#687): not one stranded record, but every earlier accepted change sharing a delivery input.
rc.6	The lessons loop closes at proposal, build and archive (#697), and a CRLF project is no longer told every scaffold already has lessons (#701).
rc.7	A Windows clone could not view a single spec (#715). One canonical frontmatter reader, CRLF-tolerant, plus .gitattributes eol=lf pins.
rc.7	A delta heading is classified before the open item is flushed (#705) — a populated ## MODIFIED block could be silently dropped.
rc.7	A semantic delta may not change after the approval that signed it (#711).
rc.8	Windows binary dropped (#722, breaking — see above).
rc.8	A configured source_dirs survives a manifest discovery failure, and an in-repo Gradle includeBuild is judged by its path rather than refused on its token prefix (#723).
rc.9	A trailing Gradle includeBuild configuration block is skipped, not refused (#725).

rc.8 and rc.9 came from one adopter's two reports, days apart, on a real Gradle build. That is the most useful kind of contribution this project gets.

The recurring shape, stated plainly because it should guide what comes next

Many of the above are the same defect wearing different clothes: a category is empty for want of input, and the code reads it as a verdict.

• A schema that could not be parsed produced an empty table set, read as "no tables exist" (Schema validation rejects the standard SQLite idempotent ADD COLUMN back-fill, failing the whole spec #672).
• A predicate looked for a path that a squash-merge guarantees is absent, read as "not recorded" (6.0 regression: orphaned verification evidence is reported as AuthenticatedHistory — the anchor check is unreachable on workflow-v2 #677).
• A check that cannot be satisfied at all gated a release, read as a spec defect (db_tables cannot be satisfied when the schema lives in code: declaring it is a permanent strict-blocking warning with no workaround #684).
• An ancestry walk that cannot run after a squash reads as a violated guarantee rather than an unavailable one (verification.commit ancestry is incompatible with squash-only repositories, and there is no available workaround #689) — that was the rejected first design; the shipped fix asks a content question instead.
• A ruleset field the GitHub API returns only to callers with repo-settings admin access came back absent to a workflow token, and absent-and-empty read as "no bypass granted, verified" (fix(release): bypass_actors is unobservable to a workflow token, so absence must read as unverified #720).
• And, one level up in the model rather than in any function: a requirement whose implementation was entirely deleted has nothing left to measure against, so it produces no finding at all and can survive a whole release (the drift check cannot see a requirement that no longer describes the code, whether it lost its implementation or was contradicted by its successor #728).

Where this recurs, the fix is not to relax the check. It is to distinguish cannot answer from answered no, and to say which one happened.

What is open, and what decides it

These are not commitments to a schedule. They are the questions currently blocking, ordered by how much they change what the tool promises.

1. What verified may depend on, given that squash-merge is the norm. This repository is squash-only; measured at d6f266a4, 21 of 198 archived changes have a verification commit reachable from origin/main, and 3 of 515 commits on main are merges. Commit ancestry is not an occasionally-unavailable guarantee here, it is an unavailable one.

• The readiness half shipped in rc.6 (verification.commit ancestry is incompatible with squash-only repositories, and there is no available workaround #689): ship_status_report was the one caller still asking a history question that every other currency path had stopped asking. Squash, rebase, and merge-commit all reach ready to finalize.
• The remaining half is the scoped-review descendant walk fails closed forever after a squash, and its guarantee is unavailable rather than violated #694, and it is a real decision rather than a bug. The scoped-review descendant walk polices .specsync/changes/ and .specsync/archive/, exactly the region workspace_digest deliberately excludes, so content digests cannot replace it. Measurement corrected the framing: of 107 archived reviews only 2 cite a commit that is an ancestor of origin/main, and 0 of 107 would pass the walk at all — archiving relocates the workspace out from under the walk's own allowlist. The walk also never reads a blob, so it asserts history shape rather than content.
• Also unresolved on 6.0 regression: orphaned verification evidence is reported as AuthenticatedHistory — the anchor check is unreachable on workflow-v2 #677: AuthenticatedHistory currently means "I checked the evidence" on one path and "this went through the process" on the other, with no way for a reader to tell them apart.

2. Line endings in the delta binding (#730), and it affects you if your team is mixed-OS. The digest binding a delta to its approval hashes raw bytes, while the code that applies a delta explicitly treats line-ending style as not part of the content. A change approved on Linux and checked out on Windows with core.autocrlf=true therefore fails its own gate with nothing edited. This repository is immune only because it pins eol=lf; we fixed our instance and shipped the class. Open and specified.

3. Lifecycle dead ends, and telling the user which door is open. #685, #690, and #688 are one family: the tool names a verb it will then refuse, and the working alternative goes unmentioned. A deliberate constraint worth preserving in any fix: reopen requires --actor and --reason, so the only door out of a wedged state cannot be opened by an agent acting alone. The goal is to name that door, not to make it easier to walk through unattended.

4. Gates that are weaker than they look. #708 — change check does not run clippy at all, and the clippy that CI does run omits --all-targets, so the ~2,800 tests in this repository have never been linted. #712 — the merge-before-finalize warning reaches only operators who run the verb that prints it, which the mistaken operator by definition does not. #714 — a folded lesson that is wrong is worse than no lesson, and nothing checks one.

5. Records whose work has already shipped. #679: audit reports an affirmative pass while changes sit in implementing with their deliverables live in the default branch. A record whose affected_paths are all present in the comparison base is not stalled, it is finished-and-unrecorded, and those want different messages.

6. Adoption ergonomics. #674 (a v1 change that merges during adoption), #554 (no way to withdraw a draft, and scope freezes at the interview), #541 (cancellation as a first-class terminal state that keeps its lessons).

7. Parser depth, driven by fixtures rather than by language checklists. The open half of #672 is embedded DDL: statements written as string literals without trailing terminators, which is valid for db.Exec and is how most Go and TypeScript projects carry their schema.

70 issues are open. This is the subset that adoption made load-bearing, not the whole board.

How to influence this

The single most useful contribution right now is a measurement of your own repository, not a feature request. Counts by state, which archives are anchored, which paths are present on your default branch, what your merge strategy actually is. Three separate explanations of one coupling were wrong in a single day of work on this, and every one of them was killed by somebody running a command instead of reading source. That pattern has held: three issues in this release were filed with diagnoses that were directionally right and specifically wrong, and each was caught only when an implementer re-derived from the diff.

Concretely:

• the delta binding is byte-exact over content the rest of the module defines as line-ending-agnostic, so a cross-OS checkout refuses honest work #730 needs adopters on mixed-OS teams to say whether they have hit it. If you have a Windows contributor and a Linux CI, you are the case.
• the scoped-review descendant walk fails closed forever after a squash, and its guarantee is unavailable rather than violated #694 needs adopters who rely on the scoped-review guarantee to say so. The question has narrowed: the walk is inert in practice.
• Q&A #336 carries a written-up set of adoption traps and their escapes. Corrections to it are more valuable than agreement.
• Ideas #338 is where parser fixtures go. Include one declaration the suspect construct cannot possibly affect, so a cascade is distinguishable from a correct single error.

React or reply with the outcome you need rather than a feature name, so these decisions stay evidence-led.