Spec Growth Engine and traceSDD: Auditing the Evidence

In Brief

Five 2026 arXiv preprints attack spec-code drift from five distinct directions, yet none cites another — and the one piece of vocabulary any of them share, a three-rung rigor ladder used by two of the five, traces to a Thoughtworks blog post from October 2025. Read them as independent design proposals, not a cumulative literature.
The portable part is the enforcement machinery: a blocking two-graph drift gate, a one-grep orphan-citation check, read-only probes with post-phase validators, and a regression-oracle pause gate can each be lifted without adopting the framework around it.
The measured effects are small and disagree in sign: context-grounding hooks gained +0.15 on a 1-to-5 LLM-as-judge composite, while the blinded human raters, on a six-task sample, leaned toward the un-augmented full workflow.
Per-line requirement citations buy automated hallucination detection at a measured cost in output determinism — a penalty concentrated on easy and small tasks, which points toward tiering citation discipline by change size.
The two most ambitious claims carry the least evidence: the Spec Growth Engine ships no evaluation at all, and the Kitchen Loop’s zero-regressions figure is scoped by its own authors to what its regression oracle can see.

Why This Matters

Spec-anchored workflows and self-evolving codebases are the practitioner bet on keeping intent intact across long autonomous runs. Between January and late June 2026, five arXiv preprints converged on that bet from five directions: a rigor ladder, a hook-instrumented multi-agent pipeline, per-line requirement citations, a blocking merge gate driven by static analysis, and a self-evolving loop policed by a regression oracle. The useful part is the enforcement machinery, not the methodology framing — and the evidence is thinner than the framing suggests. The findings below keep the two separate.

Key Findings

Five papers, one problem, zero cross-citations

Read side by side, the five look like a school. Read as a literature, they are not one yet. The corpus, in submission order:

Paper	Author(s)	arXiv	Submitted
Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants	Deepak Babu Piskala	2602.00180	30 Jan 2026
The Kitchen Loop: User-Spec-Driven Development for a Self-Evolving Codebase	Yannick Roy	2603.25697	26 Mar 2026
Spec Kit Agents: Context-Grounded Agentic Workflows	Pardis Taghavi, Santosh Bhavani	2604.05278	7 Apr 2026
The Spec Growth Engine: Spec-Anchored, Code-Coupled, Drift-Enforced Architecture	Hartwig Grabowski	2606.27045	25 Jun 2026
Citation Discipline in Spec-Driven Development	Subham Panda	2606.30689	28 Jun 2026

How these five were selected. arXiv cs.SE preprints submitted between 1 January and 30 June 2026, surfaced by searching spec-driven development, specification drift, spec-code divergence and traceability — then narrowed by one rule: the paper’s central concern must be keeping specification and implementation aligned across AI-assisted development. Read strictly — a mechanism that detects or prevents spec↔code divergence — that rule captures only Grabowski’s gate and Panda’s citation check cleanly. Taghavi and Bhavani’s hooks police artifact-repository compatibility rather than a spec-code delta, Roy polices behavioral alignment through a regression oracle rather than a spec document, and Piskala contributes a decision framework, not a mechanism at all. The five are a curated set with a stated boundary, and that boundary is what makes them a “drift-control school” rather than an SDD reading list. It excludes in-window SDD work of other kinds; two exclusions are worth naming so it stays visible:

Constitutional Spec-Driven Development (arXiv:2602.02584, 31 Jan 2026) embeds CWE-derived security constraints into the specification layer so generated code is secure by construction. The exclusion is a closer call than it first looks: the paper’s compliance traceability matrix maps principles to code for gap detection, change-impact analysis, and regression prevention — divergence machinery, operating over time. What keeps it out is its object. The traced surface is a fixed security constitution rather than the evolving feature specification, and the matrix is one of five listed contributions in a paper whose primary claim is security by construction — property-specific traceability, not general spec↔code drift control. Its evidence is also a single author-run banking case.
One Developer Is All You Need (arXiv:2605.18461, 18 May 2026) reports a staff engineer plus four agents delivering a brownfield initiative under an SDD workflow. It is evidence about SDD’s organizational effect, not a drift mechanism — but it bears directly on the brownfield question below, and is cited there.

Stating the rule matters more than the two papers do. Without it, the set looks hand-picked and every additional in-window SDD paper reads as an omission. With it, the boundary can at least be argued with — though rerunning the search means remaking the same judgment calls at its edges, so treat the corpus as a defensible selection rather than a mechanically reproducible one.

All five are cs.SE preprints, all single- or two-author. The structural fact that matters most for how you read them: they do not cite each other.

The bibliographies confirm it. Grabowski’s twenty-nine-item bibliography names GitHub Spec Kit, Tessl, and AWS Kiro as tools, and Böckeler as the framing, but no arXiv SDD paper (arXiv:2606.27045). Panda’s twenty-three references cover requirements traceability, LLM hallucination, and code-generation evaluation, and name only traceSDD, Spec Kit, and OpenSpec as frameworks — no prior academic SDD framework work (arXiv:2606.30689). Taghavi and Bhavani’s references end at 2025 (arXiv:2604.05278).

Within these five, that is a convergent cluster rather than a conversation: none of them replicates or argues with another, and they share no benchmark.

The qualifier matters, because the wider 2026 literature is further along than the five suggest. From Prompt to Process (arXiv:2606.04967, submitted June 3, inside this window) cites both Piskala and Taghavi and Bhavani, and compares six operational frameworks — Spec Kit, OpenSpec, BMAD, GSD, Spec Kitty, and Reversa — against a six-dimension process taxonomy. One disclosure to carry alongside it: Reversa is the taxonomy author’s own framework, a conflict of interest the paper itself declares. Cross-citation and systematic comparison exist; they just do not run through the five papers selected here.

Three of the five define drift or context failure in their own words, and no two definitions are quite the same object. Grabowski’s silent spec-code drift is a static-analysis divergence between two graphs. Taghavi and Bhavani’s context blindness is an artifact that is internally coherent but incompatible with the repository. Roy’s Drift Control is a time-series quality-degradation signal that has nothing to do with a spec document at all.

Treat each paper as an independent design proposal with an argument attached. Be skeptical of any framing — including the one implied by reading them in a batch — that presents them as cumulative.

The shared vocabulary is practitioner-sourced

The three-rung ladder — spec-first, spec-anchored, spec-as-source, the one vocabulary two of these papers share — came from Birgitta Böckeler’s October 2025 piece on Kiro, spec-kit, and Tessl, where the definitions are: spec-first, “A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand”; spec-anchored, “The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature”; spec-as-source, “The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.”

Piskala’s paper reproduces the same three levels with near-identical semantics — spec-anchored is the specification “maintained alongside the code throughout the system’s lifecycle”, spec-as-source is the specification as “the only artifact humans edit directly” (arXiv:2602.00180).

Grabowski goes further. He builds a comparison table that positions his framework against Spec Kit, Kiro, and Tessl on Böckeler’s spec-first → spec-anchored → spec-as-source axis, naming her as the source of the axis (arXiv:2606.27045).

So where the corpus has settled terminology at all, it entered through a practitioner blog and was adopted by the papers that use it — Piskala and Grabowski; the other three never touch the ladder — not the reverse. If you are deciding whether to track this literature, that is the tell: the academic side is currently downstream of practitioner vocabulary, and the papers are contributing mechanisms rather than concepts. Skim the framing sections; read the mechanism sections.

The enforcement machinery is the part worth stealing

Strip the methodology wrappers and four mechanically distinct drift detectors remain. Each is cheap, each is independent of the framework it ships inside, and each catches a different failure.

A blocking merge gate driven by two graphs. Grabowski’s drift gate compares an Intent Graph derived from the repository’s SPEC.md files against an Evidence Graph derived from static code analysis. Four conditions are hard errors that block the merge unconditionally: orphan code, undeclared cross-boundary dependencies, code reaching into another node’s internals, and missing public contracts. A softer tier warns without blocking — declared dependencies with no code evidence, public exports the contract never mentions, spec behaviors with no test evidence.

The invariant is that spec and code “may never diverge silently”: the agent emits a spec delta in the same commit, and review authority scales to blast radius rather than to whether a contract is involved (arXiv:2606.27045).

A HARD gate demands pre-merge approval for root invariants, breaking contract changes, and new container boundaries. A SOFT gate lets additive changes — including additive contract changes — proceed with human review requested asynchronously; an AUTO gate passes internal design changes through untouched. The distinction matters for anyone mapping this onto an existing change-management policy: a contract can be extended without waiting for a human.

A one-grep hallucination check. Panda’s traceSDD requires “mandatory inline citation annotations (# [REQ-XXX.Y.Z]) on every non-trivial line of generated code.” Detection is a set operation: extract every REQ ID cited in the code, subtract the valid IDs from the spec, flag the orphans. Any requirement ID the model invented is now a grep hit.

The paper describes it as running “in O(1) per file (a single grep)” with zero manual effort (arXiv:2606.30689) — that complexity claim is the paper’s, and it is loose: one command is not constant time, since grep still scans bytes proportional to file size. Read it as a single cheap pass, not an O(1) operation.

Read-only probes before each phase, validators after. Spec Kit Agents wraps each stage of the Specify → Plan → Tasks → Implement pipeline with two hooks. Before the phase, a read-only prober gathers repository evidence using globbing, grep, and git history. After it, a validator checks the artifact for internal consistency and repository compatibility (arXiv:2604.05278). The design point is least-privilege: the grounding step can read but not write.

A regression oracle with graduated pause gates. Roy’s Drift Control watches a small set of time-series metrics — test count, test pass rate, oracle pass rate, bug discovery rate, canary escape rate, blocked feature combinations — and five gates respond to them, but only one of the five actually stops the loop.

Regression failure pauses it, and only after N consecutive failures (default three). Backpressure enters a polish-only drain mode and starvation enters monitor-only mode; both are fully automatic and neither halts. Drift thresholds and Tier-1 canary escapes only warn the operator — the paper is explicit that “drift and canary escape currently warn rather than pause” (arXiv:2603.25697). Read the mechanism as one conditional halt plus four graduated signals, not five stop buttons.

None of these requires buying the surrounding methodology. A team already running spec-anchored workflows can add the orphan-REQ grep in an afternoon; the dependency-boundary gate is a build-it-yourself job — Grabowski’s engine is “maintained as an internal design-document set” with a public release only planned (arXiv:2606.27045) — so a sprint is an estimate for reimplementing the gate’s checks, not for installing a tool.

The measured effects are small, and one of them points the other way

Spec Kit Agents runs the set’s only repository-level controlled evaluation of its own intervention, and its numbers deserve a careful read. Across 128 runs covering 32 features in five repositories (FastAPI, Airflow, Dexter, Plausible Analytics, Strapi), context-grounding hooks improved judged quality by “+0.15 on a 1-5 composite LLM-as-judge score (+3.0 percent of the full score; Wilcoxon signed-rank, p < 0.05)” while holding 99.7–100% repository-level test compatibility (arXiv:2604.05278). The full text scopes that move — 3.51 to 3.66 — to the 90-minute workflow family; the 40-minute family’s own effect is 3.46 to 3.50, a +0.04 the abstract never surfaces (arXiv:2604.05278 full text).

On SWE-bench Lite the hooks took Pass@1 from 56.5% to 58.2%, which the abstract reports as a 1.7 percent improvement over baseline (arXiv:2604.05278) — loose wording: the change is 1.7 percentage points, a relative gain of about 3.0%.

Then there is the blinded human preference study. It collected 60 votes across six paired pull-request tasks — not 60 independent evaluations — with raters preferring the un-augmented full workflow 19 times, tying 33 times, and preferring the augmented version 8 times (arXiv:2604.05278). Six tasks is the experimental unit that matters, and votes within a task are not independent of each other.

The LLM judge liked the hooks; the humans, on this sample, leaned the other way. The paper reports the sample as a subset of outputs and flags the size as a limitation, so this is not a refutation. But a team evaluating this pattern should note that the headline metric and the human metric disagree in sign, and that a +0.15 shift on a 1-to-5 composite is the kind of effect that lives or dies on judge calibration.

The ablation is more informative than the headline. Discovery-only hooks bought +0.57%, validation-only +1.71%, and both together +4.27% — that last figure being the headline +0.15 itself, the same 3.51-to-3.66 move re-expressed relative to the Full baseline, not an additional result (arXiv:2604.05278). The post-phase validators do roughly three times the work of the pre-phase probes, and the combination exceeds the sum of the parts — a superadditive result the paper reports without proposing a mechanism. If you are going to implement one half of this, implement the validators.

The costs are real and stated. Latency rose 1.1 minutes in the 40-minute budget family and 13.2 minutes in the 90-minute family (arXiv:2604.05278).

Every experiment used MiniMax-M2.5 as the base model, with quality judged by a separate model — Claude Opus 4.6 as the LLM-as-judge, a generation/evaluation split the paper says “reduces self-evaluation bias” — and the authors are explicit that gains are uneven across SWE-bench repository families — less reliable on repositories such as django and matplotlib “where many failures originate in deeper application/library logic” (arXiv:2604.05278). Grounding hooks help with repository-shaped ignorance. They do not help with domain-shaped difficulty.

Traceability costs determinism — the corpus’s one clean trade-off

Panda’s study is the one paper here with two models, four conditions, and reported effect sizes with p-values attached. It produces the finding most likely to survive replication: per-line requirement citations buy automated hallucination detection at a measurable cost in output consistency.

The design is two studies, four conditions, 840 implementations total — Claude Sonnet 4.6 (N=20 tasks, 240 implementations) and GLM-5-turbo (N=50 tasks, 600 implementations) — comparing traceSDD with citations, traceSDD with an identical spec minus the annotations, Spec Kit’s prose user stories and acceptance criteria, and OpenSpec’s external trace YAML (arXiv:2606.30689).

The results:

Detection is binary across frameworks. Only the cited condition enables automated hallucination detection at all — 0% for every alternative, at a 0% false-positive rate (arXiv:2606.30689). The presence/absence result is the durable finding; the headline rates it reports for the cited condition — 86.4% on Claude, 88.0% on GLM — should be read with care, because the same table records 100% detection for each of the three injected hallucination types individually. An aggregate below every one of its components cannot be reconciled without denominators the paper does not give, so treat the binary result as established and the specific percentages as unsettled.
Citations cost lexical consistency. Against the identical uncited spec, the cited condition scores lower on lexical similarity across independent sessions: d = −0.76 (p = 0.003) on Claude, d = −0.72 (p < 0.001) on GLM. Note that the paper is internally inconsistent on the Claude figures — the abstract gives d = −0.76, p = 0.003, while Table 2 gives d = −0.73, p = 0.004. The direction and rough magnitude hold either way; the exact values should not be quoted without resolving which the authors intend.
But traceSDD still beats Spec Kit on the same axis. d = 0.47 (p = 0.049) on Claude and d = 0.42 (p = 0.003) on GLM, while being statistically indistinguishable from OpenSpec (d = 0.18, p = 0.44; d = 0.14, p = 0.32). The structured REQ decomposition helps determinism; the inline annotations give some of it back.
Nothing breaks. All conditions achieved a 100% true-positive rate on functional correctness — TPR here is the share of each study’s ground-truth tests passed (arXiv:2606.30689) — so citation discipline did not degrade test-measured correctness.
The tax is regressive. In the subgroup analysis — run on the GLM arm only (N=50); the Claude arm has none — the determinism penalty is strongest on easy tasks (d = −1.85) and small tasks (d = −0.95), and not statistically significant on hard tasks (d = −0.34, p = 0.22).

That last point is the actionable one, and it inverts the intuition. The citation overhead is cheapest exactly where you most want an audit trail — on the large, hard changes. Applying per-line REQ citations to every trivial helper function pays the full determinism cost for the least benefit. A tiered policy — mandatory citations above a change-size or risk threshold, optional below it — is what the subgroup data point toward, but as a hypothesis to test rather than a tested result: the study measured where the determinism penalty falls, not what a tiered policy buys, and ran no tiered condition.

The caveats are stated and they matter. Hallucinations were injected as fake REQ-097/REQ-098/REQ-099-family identifiers, so the 86–88% detection rate measures a synthetic failure the mechanism is well-suited to catch; organic hallucinations that reuse valid REQ IDs incorrectly would bypass the grep entirely.

Tasks were Python, 50–1,000 lines. Two models. The similarity metric is lexical, not behavioral — two implementations can be semantically identical and score as divergent. And the Claude arm is underpowered at N=20 for some comparisons (arXiv:2606.30689).

The two most ambitious claims carry the least evidence

The Spec Growth Engine has no evaluation. Grabowski’s paper is design work: a spec graph at four C4 levels with orthogonal contract and design views, a Spine context assembler that deterministically delivers root invariants plus the ownership path plus the current node’s spec plus one-hop declared dependencies (deliberately excluding siblings, dependency internals, transitive dependencies, and ad-hoc search results), a hardest-first vertical-slice growth protocol, the drift gate, and the blast-radius governance model.

It is demonstrated on a worked checkout-system example. There are no benchmarks, no deployment data, and no comparison against an unenforced baseline (arXiv:2606.27045). The design reasoning is careful and the positioning is honest — the paper deliberately refuses the spec-as-source line, stating “we keep code as primary and treat the spec as a verified contract – never as the generative source”.

But a blocking merge gate is precisely the kind of intervention whose cost only shows up in practice, in the form of false-positive blocks that teams route around. Nothing here tells you what that rate is.

The Kitchen Loop’s headline number is scoped by its own authors. Roy reports 285+ iterations producing 1,094+ merged pull requests with zero regressions, across two production systems: a DeFi strategy framework (122+ iterations, 728+ PRs) and a signal intelligence platform (163 iterations, 366 PRs) (arXiv:2603.25697).

Section 6.1 does the thing more papers should do and defines the claim so it can be falsified: it covers regressions detected by the oracle, and “does not claim the codebase is bug-free, nor that latent regressions undetectable by the oracle do not exist.”

Read that way, “zero regressions” is a statement about oracle recall as much as about code quality. The oracle’s coverage is stated — 10,913 unit tests and 62 demo strategies for the SDK; 77 signal types across 22 verifier families, and 2,171 tests across 152 test files, for the second system — which is a substantial suite, and also a bounded one.

The paper’s own scope conditions say the framework only applies where the specification surface is enumerable and testable and where a regression oracle can ground-truth verify outcomes; it explicitly excludes domains where that oracle cannot exist (arXiv:2603.25697).

There is a second thing to notice, and the paper is admirably direct about it. The loop “auto-merges PRs after multi-model review and CI,” and “no human is in the critical path during normal operation” — the human role reduces to initial specification-surface definition, occasional strategic steering, and supervisory intervention when the loop hits failure modes it cannot self-correct (arXiv:2603.25697).

So the 1,094 merges were not human-approved by design, and what stands in for that review is the multi-model tribunal on every PR, plus the adversarial UAT gate the paper makes “mandatory for any change to product code”. This is not an evidentiary gap; it is a stated governance position. The question it hands you is not did a human sign off but does mechanical adversarial verification satisfy your change-management policy in place of a human signature — a harder question, and one to answer before a pilot rather than after.

Where the corpus and the practitioner tooling actually meet

Piskala’s paper is the least mechanistic of the five and the most directly usable as a decision aid, because it is explicit about when SDD is the wrong call. Its guidance: “Use the minimum level of specification rigor that removes ambiguity for your context. Spec-first for AI-assisted initial development; spec-anchored for long-lived production systems; spec-as-source only when generation tooling is mature and trusted.” It names four situations where SDD is overkill — throwaway prototypes, solo short-lived projects, exploratory coding where premature specs constrain learning, and simple CRUD with unambiguous requirements (arXiv:2602.00180).

Its case-study evidence is weaker than its framing. The financial-microservices case reports that “Teams reported a 75% reduction in cycle time for API changes” — self-reported, from one organization, with no methodology attached. Read it as an anecdote, not a benchmark. The paper is listed as eight pages, submitted to AIWare 2026 (arXiv:2602.00180), which is the appropriate weight class for a positioning-and-guidance contribution.

The tooling side has not moved as far as the paper volume suggests. Thoughtworks’ Technology Radar Volume 34, April 2026, places OpenSpec in Assess — the ring Thoughtworks reserves for things worth exploring to understand their effect, not things it recommends adopting. The entry describes it as a lightweight specification layer that aligns human developers and AI agents on what to build before code is generated, and notes its emphasis on “spec deltas rather than defining a complete specification upfront, making it well-suited for existing systems” (Thoughtworks).

That brownfield-first framing is the gap in this corpus: four of the five papers assume a spec surface that either already exists or gets grown greenfield. Deriving one from an existing codebase is the problem most teams actually have, and none of the five attacks it — but the wider window does.

Reversa (arXiv:2605.18684, submitted May 18) is a reverse-documentation pipeline for exactly this, converting legacy software into traceable operational specifications, with an exploratory COBOL-to-Go ATM migration producing 517 confidence-classified claims, 10 registered gaps, and 53 Gherkin parity scenarios. It is a single exploratory case rather than an evaluation, so treat it as a design proposal — but the problem is being attacked, and the gap is in the selection here rather than in the literature.

The operational half of the brownfield question has in-window evidence too. One Developer Is All You Need (arXiv:2605.18461, submitted 18 May) reports a staff engineer with four agents delivering, under an SDD workflow, a brownfield initiative scoped for a four-person squad — in half the planned time, with 90% of AI-generated code accepted on first review. Its own conclusion is the one that matters for this corpus: specification quality and institutional knowledge, not model capability, were the binding constraints. It is a single case study inside one enterprise and reads as such, but combined with Reversa it means brownfield SDD is under-examined rather than untouched.

Practical Implications

Lift the mechanisms, skip the frameworks. All four enforcement mechanics are separable from the methodologies that carry them. In rough order of cost-to-value: the orphan-citation grep (an afternoon), post-phase validation hooks (the ablation’s best single lever), a dependency-boundary drift gate wired into CI, and a regression-oracle pause gate for anything running unattended. None of these obligates you to a spec graph, a REQ hierarchy, or a multi-agent pipeline.
Tier your citation discipline by change size. The determinism penalty is concentrated on easy and small tasks and was not statistically detectable on hard ones — though “not detectable” is not “absent”: the hard subgroup is 13 tasks in the GLM arm — the only arm with a subgroup analysis — and the point estimate stays negative (d = −0.34, p = 0.22). Mandate per-line requirement citations above a risk or size threshold, leave them optional below it, and you buy the audit trail where it pays for itself.
Don’t trust an LLM-as-judge delta this small without your own calibration. A +0.15 shift on a 1-to-5 composite, in a study whose blinded human raters leaned the other way, is not a result you should port into a business case. If you evaluate context-grounding hooks internally, run the human comparison alongside the automated one and expect them to disagree.
Treat “zero regressions” as a claim about your oracle. Before adopting an autonomous-evolution loop, write down what your regression oracle can and cannot see, and price the claim accordingly. The Kitchen Loop’s own framing is the right template — a regression count is only as meaningful as the suite that produced it, and a suite that grew alongside the agent’s output has an obvious blind spot.
Decide whether mechanical review substitutes for a human signature — before the pilot, not after. The most production-scaled framework in this set states plainly that no human sits in the critical path during normal operation; its 1,094 merges were gated by multi-model review tribunals and CI instead, with an adversarial UAT pass additionally mandatory for any change to product code. That is a coherent position, not an oversight, and the question it puts to you is whether your change-management policy accepts the substitution. Whatever you adopt, encode the answer in the gate — Grabowski’s blast-radius model (human approval for contract and root-invariant changes, automatic for internal design changes) is a reasonable starting shape.
Budget grounding latency per workflow family, and instrument selectively. Hooks added 1.1 minutes in the 40-minute-budget family (14.4 → 15.5 min, 15 pairs) and 13.2 minutes in the 90-minute-budget family (24.0 → 37.2 min, 16 pairs) (arXiv:2604.05278). The paper attributes the larger cost to “the longer workflow and repeated hook execution” and is explicit that latency is compared only within each budget family, not across them — it never varies phase count as an independent variable. So instrumenting selectively rather than uniformly is a sensible engineering default, but treat it as a hypothesis to test on your own workflow rather than as a measured scaling law.
Assume brownfield is your problem and the literature’s gap. If your codebase predates the spec, none of these five papers tells you how to derive the spec surface. OpenSpec’s spec-delta model is the nearest thing on offer, and it sits in the Assess ring rather than a recommendation ring.

Open Questions

What is the false-positive rate of a blocking drift gate in a real repository? Grabowski’s gate rejects merges on orphan code, undeclared dependencies, and missing contracts. Every one of those conditions has legitimate instances during refactoring. Without deployment data, the cost of the gate — measured in blocked-but-correct merges and the workarounds teams invent — is unknown.
Do orphan-ID citation checks catch organic hallucinations? The 86–88% detection rate was measured against injected fake REQ IDs (arXiv:2606.30689). A model that miscites a valid requirement — attaching REQ-014.2.1 to code that implements something else — produces no orphan and no grep hit. Whether the mechanism generalizes past its synthetic test case is unestablished.
Why are discovery and validation hooks superadditive? +0.57% and +1.71% individually, +4.27% together (arXiv:2604.05278). The paper reports the effect without proposing a mechanism. If the answer is that validation failures are only recoverable when discovery has already grounded the artifact, that would be a useful design principle; right now it is an unexplained number.
Does drift enforcement survive a codebase the agent didn’t write? The two mechanisms that need an established specification surface — the Spec Growth Engine and the Kitchen Loop — assume spec and code grew together under the gate; Spec Kit Agents was built for feature delivery in existing repositories, but it grounds its artifacts in repository state rather than recovering a spec surface from it, and none of the five demonstrates that recovery. Retrofitting a gate onto an existing repository means either accepting a large initial violation backlog or generating specs from code — and generating a spec from code that then blocks changes to that code is a circularity nobody in this set addresses.
Will this corpus consolidate or fragment? Five frameworks, five vocabularies, no cross-citation among them, and — the thing none of them supplies — no shared benchmark to disagree over. Comparison work has started: From Prompt to Process already sets six frameworks against a common taxonomy (arXiv:2606.04967). What is still missing is the harder artifact — an evaluation running two of these frameworks against each other on the same tasks with reported outcomes, rather than a taxonomic comparison. Until that appears, this remains a cluster of design proposals rather than a field.

Scout: The Drift-Control School — What the 2026 Spec-Driven Development Papers Actually Establish