Constitution principles should compile to executable architecture tests (fitness functions), not rely on LLM review alone

[bodote]

Context

The constitution is Spec Kit's mechanism for non-negotiable principles, and enforcement today is LLM-mediated: /speckit.analyze checks artifacts against it, and review-style extensions (e.g. the recently registered architecture-guard extension, #2696) detect violations via agent review. Issue #2459 showed how fragile that chain is — /speckit.implement didn't even load the constitution, so code generation ran unaware of governance.

LLM adherence to prose is probabilistic. But a large subclass of constitutional principles — layer boundaries, dependency direction, forbidden imports, cycle bans, module naming — is deterministically checkable with mature, boring tooling that exists in every major ecosystem (ArchUnit for Java, dependency-cruiser / eslint-plugin-boundaries for JS/TS, import-linter for Python, NetArchTest for .NET). An agent can ignore a Markdown principle; it cannot ignore a failing CI gate.

Proposal

Make structural constitution principles compilable:

1. A command — sketch: /speckit.architecture — that reads the constitution and plan.md, extracts structural rules, and scaffolds the matching enforcement config for the project's stack, plus a CI job.
2. /speckit.implement (and a future /speckit.review, Add /speckit.review as a final, constitution-aware quality gate #1323) treat failures of these architecture tests as non-negotiable blockers — the same semantics /speckit.analyze already assigns to constitutional violations, but enforced by the build instead of by model compliance.

This turns "constitutional drift" prevention from a prompt-engineering concern into a deterministic gate: whatever agent or model implements the tasks, the boundaries hold.

Question to maintainers

Given that #2362 (governance preset) was closed pointing toward pluggable presets (#1708), and given the extension registry: do you see this belonging in core, as a preset, or as an extension?

Mainly I'd like to know whether maintainers consider deterministic, executable enforcement of structural constitution principles a direction Spec Kit wants to support first-class. Review-based detection (as in architecture-guard) and executable enforcement complement each other well, so extending the scope of an existing extension might also be a viable route.

Prior art

• "Fitness functions" (Ford/Parsons/Kua, Building Evolutionary Architectures) — executable architecture constraints as first-class artifacts.
• ArchUnit, ArchUnitTS, dependency-cruiser, import-linter — per-ecosystem enforcement tooling this would generate configs for, not reimplement.

[mnriem]

@bodote Since this seems to rely on 3rd party tooling as per your rough sketch I would suggest an extension and/or preset

[bodote]

@mnriem Thanks for the quick reply. I think the "relies on 3rd party tooling → extension/preset" framing separates two questions that need to stay apart, and it skips the one I'm actually raising.

The concrete tool is deliberately not the point. Which enforcer runs (ArchUnit, dependency-cruiser, import-linter, …) is an implementation detail — I only listed them to show the capability already exists everywhere. My core claim is about the methodology, not the tooling: a spec-driven framework that never surfaces the category of deterministically checkable architecture constraints during the constitution/plan phase has a gap in the method itself. The constitution invites principles like "domain must not depend on infrastructure" or "no cyclic dependencies" — and today those are captured only as prose the model is hoped to follow, when a whole subclass of them could be hard gates. The framework doesn't have to enforce them; but it should at minimum recognize when a principle is structurally verifiable, tell the user, and recommend a deterministic gate over probabilistic LLM adherence. That recommendation is tool-agnostic and belongs on the default path.

"Relies on 3rd party tooling" can't be the criterion for what's core — it proves too much. Spec Kit already orchestrates 3rd party tooling throughout: the AI agent, git, and the test runners behind every functional test (pytest, jest, Playwright). By that logic, generating tests and the whole TDD emphasis would also be "an extension," yet they're rightly central to SDD because verification is the method. Deterministic architecture checks are the same species of thing — executable verification — just structural instead of behavioral. The reliance on an external runner is exactly as true for pytest as for dependency-cruiser.

What I'm proposing as core is minimal and tool-agnostic:

1. During constitution/plan, detect principles that are structurally checkable.
2. Surface them to the user and recommend a deterministic gate instead of leaving them as prose.
3. Emit a stable, tool-neutral rule representation.

What I fully agree can be an extension/preset: the stack-specific config generation and CI wiring (the ArchUnit/dependency-cruiser/import-linter adapters). That's the right home for the tool-coupled part.

The reason the split matters is discoverability. If the entire concern — including whether the framework ever mentions deterministic enforcement — is relegated to an opt-in extension, then the default SDD workflow silently steers every user toward the weaker, probabilistic form of governance. A user writing "no dependencies from domain to infrastructure" into their constitution will never be told it could be a build-breaking gate instead of a hopeful instruction. The happy path shapes behavior; leaving this off it is itself an architectural decision — and, I'd argue, the wrong default for a framework whose whole premise is making intent enforceable.

So the question I'd like to land: does Spec Kit consider it in scope for the core workflow to guide users toward deterministic verification of structural principles (adapters aside)? If yes, the extension/preset route for the tool-specific parts is exactly right and we agree on delivery. If no, that's the more fundamental gap I wanted to name.

[mnriem]

@bodote This is a thoughtful rebuttal, but I'd push back on the framing that "relies on 3rd-party tooling" is a category error. It isn't — it's a real and deliberate constraint, and your own analogy actually runs the other way.

Every external binary is a standing maintenance point — version drift, cross-platform behavior, install and support surface, breakage we inherit. Spec Kit minimizes these on purpose. The clearest signal: even git — about as universal as a dependency gets — was pulled into its own extension (still shipped with core) precisely so that dependency is isolated and independently maintained rather than woven through the core. When even git gets extracted, adding a whole family of architecture linters (ArchUnit, dependency-cruiser, import-linter, NetArchTest…) into core runs directly against the grain.

And the pytest/jest/Playwright comparison doesn't hold: those aren't core dependencies either. Core never invokes them — it emits tool-agnostic prose telling the agent to write tests. Core depends on zero test-runner binaries. Your proposal is different in kind: to be "core," the rule IR + adapters would make core know about and generate configs for specific binaries — a genuine new maintenance point, exactly the thing the git extraction shows we move out of core, not into it. So "verification is the method, therefore this is core" doesn't follow; the TDD emphasis is core precisely because it stayed tool-agnostic prose and pulled in no binaries.

That said — the deeper thing is that this isn't a core-vs-extension question at all. Spec Kit has four composable primitives, and every part of your proposal already has a purpose-built home:

• Awareness (your items 1–2) — surfacing "this principle is structurally checkable, prefer a gate" during constitution/plan — is a preset. Presets override the constitution/plan templates by design, so the awareness lands on the default path for anyone who installs it. This directly answers your discoverability concern: putting it on the happy path does not require core.
• The command + tool-neutral rule representation (item 3) + the stack adapters/CI are an extension — new runtime behavior, and the right home for the tool-coupled maintenance.
• Making a failing architecture test a non-negotiable blocker is a workflow: chain constitution → plan → architecture → implement with a gate step, and you get build-breaking semantics without modifying /speckit.implement.
• Discoverability of the whole thing is a bundle: ship the preset + extension + workflow as one versioned, catalog-searchable, one-step install. Discoverability is a catalog property — not a reason to move anything into core.

So the only residue that would actually require core is reaching users who install nothing. And that's an ROI trap: such a core nudge is non-actionable — "this could be a gate" does nothing until the user installs the extension/preset/workflow that builds the gate. Core would take on permanent cost to display a one-time advertisement for capability that still lives outside it:

• a tool-neutral rule IR maintained in core with no in-core consumer (versioned, tested, kept backward-compatible indefinitely);
• fitness-function prose in every constitution/plan run, paid by the majority who don't want structural gates;
• precedent creep → death by a thousand papercuts — if structural checkability earns core awareness, so do coverage gates, license checks, security scanning, perf budgets, dependency-freshness, and every other deterministically-checkable category. Each arrives with the same "verification is the method" argument, and each drags in its own family of external binaries. Concede the first and you've lost the principle that lets you decline the rest — and now core carries a thousand reasonable nudges and the thousand maintenance points behind them. That's precisely the slow death the "keep core lean, keep binaries out" rule exists to prevent.
• loss of neutrality — the constitution is deliberately open, user-authored prose; teaching core to classify principle types and prefer one enforcement philosophy makes core take a methodology stance, which is exactly what presets exist to keep out of core.

Meanwhile the actionable value you want — default-path awareness, deterministic gates, discoverability — is fully deliverable today via preset + extension + workflow + bundle, at zero core surface. And even the opt-out-nothing reach is better served by a featured bundle in the catalog or a docs line than by mutating the constitution engine.

So to land your question directly: yes, Spec Kit should absolutely support guiding users toward deterministic verification of structural principles — the framework is built to do that through these primitives. The methodology gap you're naming is real; the fix is a bundle, not a core change. Want to sketch that solution together?

---

Disclosure: I drafted this reply with GitHub Copilot (model: Claude Opus 4.8) as a collaborative writer; the position and final wording are my own.