# TeXise R14.28.20 Build Fix 51.1 — Production Hardening ## Objective Build Fix 51.1 hardens the BF51 growth/search/Ollama release without changing TeXise's core editor or authoritative compile model. It closes two production-correctness findings from the post-BF51 audit and deepens the comparison/search and Live PDF diagnostic boundaries. ## Ollama privacy boundary A browser connection to `127.0.0.1:11434` is not, by itself, proof that model inference remains local. Ollama may expose remote/cloud-backed models through its local API. TeXise therefore reads `remote_model` and `remote_host`, rejects remote/cloud-backed entries from local-service AI, inspects the selected model through `/api/show`, and validates it immediately before configured Ollama inference. Privacy Mode only treats a model as local-service AI after this validation. The first production release remains HTTP-loopback-only (`127.0.0.1` and `localhost`), requires no user API key for Ollama, and never silently falls back from Ollama to BYOK AI. ## Structured AI output Malformed model JSON containing LaTeX can collide with JSON escapes such as `\\n`. BF51.1 removes the finite LaTeX-command recovery allow-list and uses bounded generic control-word collision detection instead. Syntax recovery remains separate from semantic, citation and Paper Memory evidence validation. AI source changes remain reviewable before canonical LaTeX is changed. ## Live PDF R6 R6 remains a disposable accelerator over exact R5. BF51.1 adds viewer-aware diagnostic outcomes for accepted patches, line-count rejection and paint failure, exposes warm-up failures, and provides an isolated `disposeInstant()` lifecycle with idle reclamation. Manual Compile, exact R5 PDF/SyncTeX and export remain authoritative. R6 eligibility is not broadened in this release. The audit identified full project-file copying as a possible future R6 latency optimization. It is intentionally not changed here: the new diagnostics should provide measurements before changing the warm worker filesystem strategy. ## Comparison and search hardening The canonical comparison registry now owns guide membership, guide methodology/verdicts/FAQ and row-level official-source provenance. Comparison sitemap entries use verification dates as `lastmod`. Direct comparison and comparison-guide routes also receive substantive initial HTML generated from the same registry, while React remains the normal interactive application after boot. The comparison audit checks source IDs, row provenance, SEO uniqueness, verification freshness, guide depth and membership. TeXise Free-plan comparison claims no longer hard-code the default project count; the product limit remains deployment-configurable through `TEXISE_FREE_PLAN_LIMIT`. IndexNow keeps its safe canonical BF51 URL set as a fallback and can additionally consume a deployment-generated changed-URL manifest through `TEXISE_INDEXNOW_URLS_FILE`. Off-origin URLs are rejected and IndexNow remains non-fatal after a healthy deployment. ## Release coherency BF51.1 uses the app-shell cache identity: `texise-app-shell-r14-28-20-buildfix51-1-v1` Production dist validation now accepts point-build cache identities such as `buildfix51-1`. Historical cumulative guards were updated narrowly to recognize BF51.1 as a valid later release rather than bypassed with marker comments. The release-quality pipeline now executes the BF51.1 cumulative guard, and the SaaS migration compatibility test explicitly covers migrations 20 and 21 so the provisioned unit suite does not stop on stale release expectations. ## Dependency-free verification The final local release process runs BF50 R6, BF51 and BF51.1 regressions, cumulative source guards, comparison audit, public SEO/sitemap tests, the static release audit and branding audit. Runtime-hardening/R14/SaaS suites are compared against the exact packaged BF51 baseline so historical failures are not misreported as BF51.1 regressions. ## Mandatory production certification The source archive does not contain the provisioned workspace dependency/runtime tree. Production activation must still run the server's authoritative custom validation, TypeScript 6 `tsgo`, Biome, unit/integration tests and production build. Browser certification must include Chromium R4/R5/R6, the BF51.1 Ollama browser E2E and a real Ollama local-model smoke test. Deployment must also verify comparison initial HTML/SEO, favicon responses under a Bingbot user agent, legacy template redirects and IndexNow ownership/submission. ## Release E2E orchestration The BF51.1 deterministic Ollama browser flow is part of the formal `e2e:release` test list, not merely a standalone fixture. `pnpm run release:quality` therefore executes the Ollama settings/model-verification/chat path alongside the established browser release suite. A real locally installed Ollama model remains a separate production smoke-certification requirement because Playwright route interception does not prove host-browser local-network/CORS behavior. ## Production SEO route certification `pnpm run release:seo-production` derives every competitor and guide path from the canonical comparison registry, verifies each page's indexable metadata and substantive initial HTML marker, and also verifies `/docs/ollama`. This avoids certifying only a small sample of comparison pages while the remainder drift or break. ## Real local Ollama smoke certification Run `TEXISE_OLLAMA_MODEL= pnpm run release:ollama-local` on the deployment host/user environment that owns the local Ollama service. The command is intentionally loopback-only. It verifies `/api/version`, `/api/tags`, rejects `remote_model`/`remote_host`, validates `/api/show` completion capability and executes a real `/v1/chat/completions` request. This complements the deterministic Playwright test; it does not replace the browser/CORS certification against the deployed HTTPS site.