Spots 
A reader of my article on keeping AI an optional capability asked the best question of the whole comment thread: how do you keep an architectural seam from eroding as features accumulate — do you enforce it with tests, or with another kind of guardrail?
The honest answer starts with admitting the question contains two different propositions. "The code works" and "the architecture holds" are not the same claim, and they do not admit the same proof. A test suite can be fully green while the architecture quietly rots — tests sample behavior, and behavior can stay correct for months after the structure that was supposed to constrain it has been bypassed. In WorldScript Studio, the open-source writing app this series dissects, one seam is protected by both layers and another — candidly — by only one. The contrast is the lesson. Code references are from the repository at commit 8b329633 (2026-09-28), release v1.28.8. 1. What a working boundary looks like
The project is a web app that also ships as a Tauri desktop app. The architectural rule: application code must reach desktop capabilities through a desktopPlatform contract, so a future Qt or GPUI adapter slots in without touching consumers. This rule is not documented and hoped for — it is enforced by a CI step running a small checker with three design decisions worth stealing.
First, zero tolerance. Any real @tauri-apps/* import specifier in application source outside the approved locations fails the build. The script's header explicitly contrasts this with the project's suppression ratchet elsewhere: boundaries don't ratchet, because a ratcheted boundary is a schedule for losing it.
Second, parse real imports, not text. Whole-line comments are masked before scanning, so a JSDoc mention of @tauri-apps/api doesn't fail the build — only actual import, import(), and require() specifiers count. The header even documents the residual edge case (a block comment placed mid-line on real code is not masked and would flag) — the maintainers know exactly where their parser is conservative, and chose the direction that fails loud rather than the one that fails silent.
Third, the allowlist is the documentation. Approved locations plus a short list of exceptions, and every exception carries a written reason — two files are marked PERMANENT because the HTTP facet is deliberately not part of the platform contract, with a pointer to the roadmap section. An exception without a reason doesn't exist. Reviewing the boundary means reviewing a twenty-line allowlist, not re-auditing the codebase — and the gate runs as an ordinary CI step, so the review happens on every pull request for free. 2. What a strong behavioral layer looks like
The project's AI seam has no such gate. What it has instead is a behavioral layer that is genuinely strong — worth describing precisely, because "we have tests" is usually where the erosion conversation gets sloppy.
Application features reach AI only through a unified provider service; the factory that constructs provider clients is imported by nothing outside the provider layer — verifiable in the import graph in one grep. The factory's mapping table is fail-closed: providers nobody has vetted map to unsupported, and one test pins that a superficially OpenAI-compatible provider gets its own kind instead of being folded into the generic path. Policy gates (cloud-allowed, local-only) and the null-returning fallback registry each have their own suites — in total over two hundred cases across service, factory, policy, outbound-request shape, and fallback semantics.
This is real enforcement. It is also exclusively behavioral: it proves what happens when code uses the seam. It says nothing about code that routes around it. 3. The leak that proves the point
Here is where I get to be honest in the way the reader's question deserves. Nothing mechanically stops a new file from importing a vendor SDK directly. Today the inventory is small and known — six runtime files, four of them deliberate services-layer surfaces. The other two are the interesting ones. One is a feature thunk that imports Type from @google/genai — not to call a provider, but to use Gemini's schema vocabulary (Type.OBJECT, Type.STRING) when declaring the shape of a structured response; the actual generation request still goes through the shared service, through the policy gates, through everything. The other is a React hook that imports useCompletion from @ai-sdk/react — but points it at a virtual worldscript-internal://completion URL whose transport is the seam itself. Neither calls a provider directly. No bypass, no bug.
A reader of my article on keeping AI an optional capability asked the best question of the whole comment thread: how do you keep an architectural seam from eroding as features accumulate — do you…