# BF51.4 Public Change Log CMS

## Objective

BF51.4 adds a public, database-backed `/change-log` page so TeXise users can see recent product changes without requiring a source release for every content update. Administrators manage the page copy and dated change events from `/admin/change-log`.

## Data model

Migration 24 creates two MySQL tables:

- `cms_change_log_settings` — singleton page title and Markdown introduction.
- `cms_change_events` — dated change events with title, Markdown/HTML content, Draft/Published status and publication timestamps.

The application stores sanitized rendered HTML alongside the authoritative Markdown. Only Published events are returned by the public API and they are ordered newest-first by `change_date`.

## Public experience

`/change-log` is a first-class public route. It is linked from the external footer, included in public search, emitted in the sitemap and receives route-specific canonical/OG metadata plus substantive initial server-rendered HTML.

The configurable Free-plan token `{{TEXISE_FREE_PLAN_LIMIT}}` is resolved consistently in both the live public API and crawler-visible server prerender.

## Administration

`/admin/change-log` allows administrators to:

- edit the public page title;
- edit the introductory Markdown;
- create dated change events;
- set Draft or Published state;
- edit events;
- delete events;
- open the public page for verification.

Admin mutations use the existing authenticated same-origin/CSRF protections and write audit events for settings updates and event create/update/delete operations.

## Release and search integration

BF51.4 adds `/change-log` to production SEO verification and uses the app-shell identity:

`texise-app-shell-r14-28-20-buildfix51-4-v1`

Installer, deployment and release-quality execution run the cumulative BF51.4 source guard after the previous BF50/BF51.x guards.

## Verification

Source-side certification completed for BF51.4:

- focused BF51.4 regression: 8/8 PASS;
- BF50/BF51/BF51.1/BF51.2/BF51.3/BF51.4 cumulative guards: PASS;
- public SEO tests: 21/21 PASS;
- public index/sitemap tests: 3/3 PASS;
- SaaS migrations: 2/2 PASS;
- SaaS router tests: 7/7 PASS;
- static release audit: 393/393 PASS;
- changed JS/MJS syntax: PASS;
- changed shell syntax: PASS;
- changed TS/TSX transpile syntax: PASS;
- BF51.3/BF51.4 `ProjectCompileService` hash parity: PASS.

Provisioned-server TypeScript 6, Biome, full workspace tests, production build and browser E2E remain deployment-time gates.


## Fix 3 — on-demand Ollama local-network permission

Chrome/Chromium can display a Local Network Access permission prompt when a secure TeXise page first contacts the user's loopback Ollama service. Earlier BF51.2/BF51.3 behavior probed `localhost:11434` when the AI Assistant or AI Settings opened, which could surface that browser prompt even when the user intended to keep using Local AI or BYOK AI.

Fix 3 removes those unsolicited probes, including passive startup probing when Ollama was saved previously. TeXise now accesses Ollama only after an explicit Ollama action (**Use Ollama**, selecting **Ollama · Local + Cloud**, **Refresh Ollama**) or when the user actually starts an AI request while Ollama is already the selected provider. Migration 25 updates untouched canonical AI/Ollama documentation and records the behavior change in the public Change log. The browser E2E contract asserts zero Ollama discovery requests before the explicit **Use Ollama** action.

Current focused BF51.4 regression coverage is 8/8 PASS, including the strict TypeScript row-source fix, self-contained trusted-runtime comparison registry and on-demand Ollama Local Network Access contract.

## Fix 3 — on-demand Ollama permission + styled Change log prerender

- TeXise does not probe `localhost:11434` during passive app startup or merely because the AI Assistant or AI Settings opens. The first probe is initiated only when the user explicitly chooses/refreshes Ollama, or starts an AI request while Ollama is already the selected provider.
- This prevents Chrome/Edge Local Network Access permission from appearing during ordinary TeXise browsing.
- `/change-log` keeps substantive server-prerendered HTML for SEO, but wraps it in a CSS-readiness guard. The prerender is hidden with browser-default styling and becomes visible as soon as the production SaaS stylesheet defines `--texise-prerender-visibility: visible`; React then replaces it normally. This removes the flash of raw unstyled text without deleting the initial HTML.