# Hotfix9 / Build Fix 40 TeXise Branding & Provenance Audit

## Policy

TeXise is the product identity. Users, search engines, social crawlers, PWA/desktop/mobile metadata and ordinary runtime diagnostics should encounter **TeXise/texise**, not inherited names from projects whose code or ideas contributed to the implementation.

At the same time, TeXise must not falsify dependency ownership or remove legally/technically necessary provenance. A third-party package name, required download endpoint, migration key or required attribution remains unchanged when changing it would break software, data compatibility or attribution obligations.

The release therefore uses an **allowlist model**: upstream-name matches fail by default on production-facing source. Every allowed residual class must have a narrow reason.

## Completed TeXise-owned identity migration

- Local workspace packages were moved from inherited `@bangle.io/*` naming to `@learnitive/*` where the package is TeXise-owned.
- The inherited internal editor workspace was renamed to `@learnitive/prosemirror-editor` and the directory/import/dependency/lockfile graph was updated.
- TeXise-owned environment/config identifiers use `TEXISE_*`.
- TeXise-owned CSS variables, DOM/test identifiers, editor symbols, global names and protocol names use TeXise naming.
- Desktop identity uses TeXise product names, `texise://app/`, `com.texise.desktop`/nightly identity and TeXise updater configuration.
- Mobile identity uses TeXise schemes/package identifiers and the canonical TeXise web fallback.
- Product-facing TeXlyre-derived collaboration/editor component names were renamed to TeXise equivalents while narrow source-level adaptation comments were retained where they aid provenance/maintenance.
- TeXise-owned documentation for current desktop/service/release behavior was updated so it does not describe the current product as an upstream project.
- Public HTML, server SEO, public indexing/RSS, PWA metadata and the SaaS UI have a zero-upstream-brand exception policy.

## Persisted browser-data safety

The primary browser database is now `texise-db`.

The historical database name `bangle-io-db` is intentionally retained **only** in the migration layer. On startup, if the new TeXise database is empty, TeXise checks the historical database and copies known records into the TeXise stores. The migration is non-destructive: failures leave the old database untouched rather than risking local project loss.

This is a compatibility identifier, not product branding, and must remain until a future release intentionally retires the migration window.

## Approved residual upstream reference classes

The automated guard currently permits only these classes in production-facing source:

| Class | Why it remains | Exposure |
| --- | --- | --- |
| `bangle-io-db` legacy IndexedDB key | Required to migrate existing local browser data safely | Internal migration only |
| `@bangle.io/config-template` | Real third-party package specifier/patch target; renaming would break package resolution | Build/source only |
| `@bangle.dev/pm-markdown` and `@bangle.dev/*` tooling handling | Real third-party dependency namespace | Build/source only |
| `texlyre-busytex` | Real compiler package identifier used by the current browser compiler provisioning path | Build/runtime dependency identifier |
| `texlive2026.texlyre.org` | Required current TeX Live asset endpoint until TeXise hosts an equivalent distribution | Compiler network endpoint |
| TeXlyre BusyTeX build release URL | Required pinned compiler compatibility/provisioning source | Build/runtime provisioning |
| Narrow TeXlyre adaptation comments in collaboration/listing/toolbar sources | Source provenance/maintenance context for directly adapted code | Source only |
| `THIRD_PARTY_NOTICES.md`, license notices and historical release/provenance records | Legal/historical attribution | Repository/legal only |

No exception allows an upstream identity to become a TeXise page title, site name, publisher, application name, Open Graph identity, Twitter identity, PWA name, current user-facing UI label or current product description.

## Automated enforcement

`scripts/verify-texise-branding.mjs` scans production-facing source/configuration for:

- `bangle`
- `texlyre`
- `texpile`
- `prefix.dev` and inherited `Prefix-inspired`/`Prefix-reference` comparison labels
- `ai latex editor`

Matches fail unless both the exact file and the exact expected reference pattern are allowlisted. Broad directory exclusions are not used to excuse production code.

The following crawler/user-facing files are also rechecked with **zero exceptions**:

- `packages/tooling/browser-entry/index.html`
- `packages/tooling/browser-entry/pwa-manifest.template.json`
- `packages/core/app/src/saas/saas-app.tsx`
- `server/public-seo.mjs`
- `server/public-index.mjs`
- root/desktop/mobile package metadata
- current desktop/service/release-checklist/implementation-ledger/validation documentation

The branding audit is called from `scripts/repair-buildfix40-source.mjs`, making it a release gate rather than a one-time cleanup.

## Historical documents and frozen provenance

Historical changelog entries, old implementation-state documents, archived plans and legal notices can legitimately describe where a feature was adapted from or the state of an earlier release. Rewriting such history to pretend the upstream project never existed would reduce provenance quality and can be misleading.

The policy is therefore:

- current product/operations docs: TeXise identity;
- current public/runtime/SEO surfaces: TeXise identity, zero exceptions;
- real external dependency names/endpoints: preserve exactly as required;
- legal/source attribution: preserve;
- archived/historical descriptions: preserve only where they actually document history/provenance, not as current branding.

## Validation checklist

A release is acceptable only when:

1. the production branding guard passes;
2. all local workspace dependency names resolve consistently after the scope migration;
3. the pnpm lockfile is synchronized with workspace manifests;
4. public package barrels remain valid;
5. the BF40 source guard passes;
6. public SEO/PWA/client surfaces contain no unapproved upstream names;
7. the final packaged ZIP is extracted and the same guards are rerun against the archive, not only the working tree.

## Future retirement work

The two largest legitimate upstream runtime remnants are the BusyTeX package/distribution endpoint and the legacy browser database migration key. They can be removed only when:

- TeXise owns/hosts an equivalent compiler artifact/distribution path and provisioning has been migrated and tested; and/or
- the product intentionally ends support for migrating browser data created under the old database name after a documented compatibility window.

Until then, retaining these narrow references is safer and more truthful than blind replacement.