Bridge 0.17.0

Bridge 0.17.0 adds users, roles, project management and the optional team hub with its browser dashboard (the first slice of requirements 4 to 7). It also makes checking elective, so Greek Room runs only when asked, and lets Bridge install its own Paratext connector. The workbench database moves to v9 and the workspace database to v5, both by forward migration. The semantic database stays at v16. No translationCore project file changes shape.

This is the build for the field-laptop measurements (#232) and the two-laptop LAN walk (#281).

Choose the checks a run includes; Greek Room on demand (#251, #252)

A Checks ▾ menu in the editor toolbar has six boxes: Translation Notes, Translation Words, Alignment, USFM and text, Language QA and Greek Room. The selection is saved per installation and defaults to all but Greek Room. Opening a chapter, the re-check after an edit, Run chapter and Run whole book all use it, and the engine now runs only the ticked checks. Greek Room (Wildebeest, the USFM structural checker and names spelling) no longer runs on chapter open, after an edit or on verse selection. Run it from the Review panel for the verse, or from the Checks menu for the verse, the chapter or the book; it runs last, with progress and Cancel. A run of some checks keeps the other checks' findings. A verse's ✓ means every selected check ran clean, and its title says what ran and "Greek Room not run". Collection QA has its own boxes, with Greek Room on by default.

Measured on the Tamil IRV Luke fixture, on a development machine:

Run	0.16.0	0.17.0
First chapter of a session	16.1 s	11.7 s
A later chapter	1.19 s	0.10 s
Re-check after an edit (median)	24 ms	2 ms

Users, roles and project management (#236, #237, #238, #239, #240, #182)

• Users and roles: a startup name picker and Settings › Users. There are three roles, and one authorization rule runs before every engine method. Every write carries the chosen user.
• Projects list: progress columns, last opened by, rename, archive and unarchive.
• Assignments: assign a book or a chapter to a user. The dashboard has "My work", and assigned chapters carry a ● mark.
• Progress: aligned verses and Language QA are counted on the totals.

The team hub and dashboard, first slice (#79, #80, #81)

• The hub: an optional sync peer on the local network (--serve, a pip [server] extra). It uses join codes and device tokens, pushes and pulls review state, and keeps a conflict queue. The desktop never waits on it.
• The dashboard: a browser page the hub serves, with team progress, users and assignments.
• Not yet tested on two machines: that walk is #281.

Bridge installs its own Paratext connector (#282, Benz)

The installer offers to install the connector when Paratext 9 is present, and Settings › Connections has Install or Update Paratext connector. Both compile the connector on the user's PC and ask for one UAC prompt. Bridge → Paratext and Logos navigation works again (#110).

Also in this release (Benz)

• Language QA: requirement 3's coverage target is met: 20 framework items Checked and 20 Not checked (#253–#270). Every finding is drawn behind the Settings slider, with Why in the menu (#250). A live pass updates the dashboard's clean count (#280).
• Source text panel: a side panel shows the source text beside the translation (#67).
• Cross-verse: the pass is shown from the job status, with a plain provider-timeout message (#243). Rows M50, M51 and M59 pass on the installed 0.16.0 (#159).
• Engine: a never-opened sibling book is prepared on a worker (#210).

Responsiveness table

Not yet measured on the reference laptop (Intel Core i3-1115G4, 2 cores, 8 GB, 1366x768). It is measured on this build on 15 October and added here (#232).

Known

• Not yet seen on the installed desktop: the Checks menu and Greek Room on demand (QA matrix M61, M62), users and roles, the hub and the dashboard (#281).
• CI's Language QA latency gate failed once on 99aa9ab. verse.decide (languageQa) measured p95 530 ms over 10 samples against a 300 ms budget. The same gate passed on the five later runs.

Bridge v0.16.0

Bridge 0.16.0 is the responsiveness release on 0.15.0: the four slow calls that held the engine's single request thread now run as background jobs or on a worker, and the app starts measuring its own click-to-paint times. Nothing on disk changes shape: the three databases stay at their current schema versions (semantic v16, workbench v7, workspace v2) and no project file is written by anything new.

Import is a cancellable background job (#231)

Importing a file, a folder or a Paratext project shows a progress banner at once (phase, book x of y, chapter for the first book, percent) with a working Cancel, and Project Home stays usable while it runs. Cancel leaves nothing on disk. Two defects fixed on the way: a collection import used to move each book into place as soon as it was written, so a failure on book 40 left 39 behind (every book is now staged and the set is moved at the end), and the project registry had no lock.

"Align automatically" on a window no longer freezes the app (#242)

The cross-verse page's two provider calls run on a worker. Status polls, verse reads and navigation keep answering meanwhile (on 0.14.0 this was 275 s of "Language QA: unavailable"), the job reports which pass is in flight, and a cancel writes nothing. The modal's own pass text from that state is #243.

Opening a book returns before the semantic runtime is built (#112)

project.open comes back once the translationCore project is loaded, registered and recovered; the passage-semantic runtime (0.3 to 1 s of a cold open) is built on a worker, and anything that needs it, an edit, an alignment write, a semantic analysis, waits for it rather than racing it.

Click-to-paint timing and the responsiveness table (#232)

Every Tier A and B action of requirement 1 is timed from the click to the paint and written to the diagnostics log. Engine diagnostics gained a Responsiveness section with this session's p95 table, "Copy table" and "Measure 20× each"; scripts/perf_table.py prints the same table from the log. NFR-PERF-001 in the SRS now states the three tiers.

Responsiveness table: not yet measured on the reference configuration (Intel Core i3 8th gen, 8 GB, 512 GB HDD, 15-inch 1366x768). The table is added to these notes when the first measurement is taken on that class of machine; until then the expectation from the development machine's traces is in #232.

Also in this release (Benz)

Language QA: spacing.extra offers its fix and the human-review round 3 labels (#230), section-heading rules (#244), footnote text without \ft (#245), note callers (#246).

Known

• word.select is the one Tier A action without a timing mark yet (its selection lives in the verse editor).
• Under a parallel test run on a loaded machine two pre-existing tests are flaky; see #247 and BUILD_LOG 2026-10-14. They do not affect the installed app.

Bridge v0.15.0

Bridge opens on a real loading screen, a verse aligned across verses can earn its tick, the engine's database work is several times faster, and the Tamil Language QA pack reaches 1.3.0 with the native reviewer's wording.

Highlights

A startup screen instead of a blank window (#233). The window opens on the Bridge name, the version and what the engine is actually doing, stage by stage: starting the process, loading Python, loading the engine modules, starting the engine, ready. If the engine cannot start, or does not answer within 30 seconds, you see a plain error with Retry, Show details (the engine's log) and Copy diagnostics, which puts the version, the paths Bridge used, the startup stages and the log on the clipboard for a bug report.

The verse ✓ for cross-verse alignment (#228). A verse whose words are aligned through a cross-verse link could never show the tick, because translationCore itself cannot mark it complete. The verse list now has a fifth alignment state, "complete (cross-verse)": every remaining word is accounted for by a link or a reasoned null decision, the ✓ shows, and the chapter tallies count it. Export is unchanged.

Faster everywhere the engine touches its databases (#113). The engine used to open and close a fresh SQLite connection for every operation. It now keeps one per thread and reuses it within a request. The semantic pipeline's profiled test went from 95 seconds to 10; the packaged Language QA stages roughly halved; the whole engine test suite runs in two thirds of the time. Durability is NORMAL under WAL: every committed change survives an application crash.

Tamil Language QA pack 1.2.0 and 1.3.0 (#234, #235). The pack now carries a changelog and every change to it bumps the version. 1.3.0 takes the native reviewer's corrections to every Tamil string on screen, exported for review as one list with the English alongside (#235), and stops offering an ஒற்று verdict after கூட, சொந்த and கள்ள.

The Language QA panel stays usable at 1366×768 (#177, #178). Close, Pause/Resume and the Findings / Re-check / False positives switch are pinned under the tab bar instead of scrolling away, and the "checks / does not check" coverage list sits behind an ⓘ.

Also in this release

• The editor gets a panel rail on the right: Review, Language QA and Reference open as resizable columns that close by dragging (#236, UI part).
• A checks.status poll that times out while the sidecar is busy now waits instead of failing the check (#210).
• Cross-verse alignment re-tested: offline corpus suggestions come from the project's own completed alignments (#208); the AI path re-tested against a real provider (#188).
• The dead TA_DOUBLE_SPACE check was resolved by the USFM parser work (#191).
• Decisions recorded: full user management and the team hub are version-1 scope, the dashboard is a browser app inside the hub (#226); the engine always stamps the acting user itself and a request can no longer name one (#183).

Before upgrading

Bridge is pre-release and projects are re-imported, not migrated. Nothing in this release changes the project folder layout or the database schemas.

Bridge 0.13.0

Offline Tamil Language QA arrives, and Bridge reads USFM with one real parser instead of five regexes.

Highlights

Offline background Language QA for Tamil (#169). A background scan of the open book against the bundled ta-irv rule pack: vallinam (வல்லினம்) sandhi, spacing, known splits, divine-name typos, terminology and misspellings, each with a confidence and a layer. High-confidence findings are drawn inline in the verse with suggest / edit / ignore; the rest wait in the panel. Ignoring can be scoped and is learned as house style. Everything runs on the machine; nothing leaves it.

Termbase rules from Settings (#171). Add an approved or rejected rendering without a backend script, and Language QA rescans to pick it up.

One USFM parser (#91). The USFM Technical Committee's reference parser, usfmtc, now decides where every verse starts and ends and which lines are headings, and one Bridge fragment reader decides what each verse shows. Import, export, checks, alignment tokens, Language QA, the semantic pipeline and the reader all read through those two.

• Verses whose \v does not start its line (\q1 \v 1, how the ESV opens poetry) are imported instead of lost; a \v with no number no longer becomes a verse called \x.
• The reader shows clean text: notes are buttons, and literal \it, \nd, \q1 markers are gone.
• Finding and Language QA underlines map onto the displayed text exactly.

Export keeps its structure (#190). Section headings between verses are no longer dropped on export, and edits to mid-line verses are written back. An unedited project now exports byte-identical to its source.

Redundant markup check (#203). \wj*\wj pairs that close and reopen a style with nothing between them, which glue words together in readers, are flagged with a one-click fix. scripts/normalize_usfm_markup.py repairs reference texts in bulk.

Also in this release

• A stable user id on every write, not a display name (#78).
• Align Words: the interlinear wraps instead of scrolling sideways (#72); the book in the title, an honest chapter tally, less banner chrome (#148).
• Imported manifests carry the real Bridge version (#176), and the sidecar reports it (#170).
• A 66-book import no longer times out on the alignment scan (#99).
• The release smoke test is a hard gate again (#130).
• Language QA project guard and latency gate fixes (#184, #186, #189).
• Software Requirements Specification added (#168).

Before upgrading

Bridge is pre-release and projects are re-imported, not migrated. Verse boundaries and headings are decided at import, so a project imported with an earlier build keeps the old ones until it is re-imported.

Known

• The installed-app regression pass (#150) is still open; several new desktop rows in docs/QA_TEST_MATRIX.md (A89–A92) are marked desktop not run.
• #191 (a double-space check that can never fire), #192 (import preview parser cost) and #193 (a flaky test under parallel runs) are filed.

Bridge 0.12.0

Cross-verse alignment gets suggestions — from the project's own completed alignments, and optionally from an AI provider.

Highlights

Cross-verse suggestions (#137–#139). alignment.gapScan gives one definition of an alignment gap, chapter-wide, and the Suggest strip ranks where each unmatched source word was probably realized in a neighbouring verse. The evidence is this project's own completed alignments — translation probability, PMI, a Strong's-keyed index and a phonetic edit-distance boost. Accepting stays an ordinary cross-verse link.

Suggest with AI, with an agreement gate (#146). A second button asks the configured OpenAI-compatible provider the same question. The model is handed opaque handles for the gap words only, so it cannot invent a word — every id it returns is resolved back against Bridge's own list, and an unknown one is refused. A pair is linked without a click only where the model and the offline statistical scorer independently choose the same uncontested pair; the model's own confidence is never the gate. Auto-applied links carry origin: "ai-auto" on the append-only audit trail, are removable like any other link, and never touch alignmentData/. With no API key the feature is simply absent and everything else works unchanged.

Source words are labelled in English (#145). The line under a Greek or Hebrew word in both alignment views is now the lexicon's rendering list — "condemn, damn" rather than another word in a script you may not read. Lemma, Strong's number and the full definition moved to the hover tooltip. Cross-verse rows also stack the word above its drop cell, so more of the range fits on screen.

Dashboard fixes (#143, #144). Opening a project no longer builds the whole QA report (measured at ~113 s on a real 1533-verse Genesis import), and "no AI review yet" is no longer counted as a verse needing attention.

Please read before using the AI feature

No Bridge AI path has ever been sent a request to a real provider (#131, QA matrix D12/D14). Every test uses a fake transport. The plumbing is verified — invented ids are refused, proposing writes nothing, a missing key is handled — but prompt quality, how often the agreement gate actually fires, and the cost estimate of roughly $0.03 per click are all unmeasured. Treat the first real run as an experiment, on a book you are willing to re-import.

Related: estimate_cost bills any model outside the four gpt-5.6-* names at the most expensive tier, so the lifetime usage figure over-reports for e.g. gpt-4o-mini (#147).

Verification

CI green on ed1c48f: engine 1287 passed, frontend 461 passed, Rust 10 passed, production build clean.

docs/QA_TEST_MATRIX.md is the release gate beyond CI and carries 49 NOT RUN rows — one more than 0.11.0, the new one being D14 for the AI feature above. The manual desktop rows (M01–M44) remain largely unrun, as at previous releases. scripts/smoke_sidecars.py is continue-on-error in the release workflow because of a known project.inspectImport classification mismatch, so a green build is not by itself evidence the frozen sidecars are healthy.

Windows (x86_64-pc-windows-msvc) is the only verified target.

Bridge 0.11.0

Bridge 0.11.0

Bridge 0.11.0 is a feature release on 0.10.3. It adds the Cross-verse alignment
page — a side-by-side view of several verses of a chapter where a source word can be
aligned within its verse as before, or recorded as realized in another verse — and
teaches the passage-aware QA pipeline to read those records as evidence. It also
completes the protocol simplification started in 0.10.3.

One on-disk change to know about: the per-project bridge-workbench.sqlite3 moves
from schema v2 to v3 the first time 0.11.0 opens a project. The migration is automatic
and keeps a backups/pre-workbench-v3-* copy, but it is one-way: 0.10.x cannot open a
project that 0.11.0 has opened. Nothing else on disk changes shape; the semantic
database stays at v16, the app-level workspace database at v2, and translationCore's own
alignmentData/ is never written by the new feature.

Cross-verse alignment (#116, #117, #118, #119)

translationCore alignment groups are verse-local, and Bridge never fakes a cross-verse
link inside them. Until now that meant a word realized in the next verse looked like an
omission here and an addition there, with nothing showing the two together.

• The page (#116). Open it from the editor toolbar ("Cross-verse alignment", beside
  "Alignment Review") or from the link inside Align Words. A range picker (from/to plus
  per-verse chips, default the selected verse ±1) drives two vertically scrolling columns:
  source tokens with lemma, lexicon tooltip and popup on the left, each verse's word bank
  on the right, and a gap overview across the top that filters both columns to one verse's
  gaps. Dragging a word onto a source cell of its own verse aligns it exactly as Align
  Words does and reruns that verse's local checks. No horizontal scrolling.
• Cross-verse links (#117). Dragging a word onto a source cell of another verse
  records a Bridge-private link in the workbench database, keyed by the two words'
  translationCore token signatures plus their verses. The source cell shows "realized in
  v.N", the word stays in its own verse's bank marked "↔ v.N", either side's × removes
  the link, and a text edit that removes the linked word marks the link invalid with the
  reason. A verse whose only remaining gaps are linked drops the "not fully aligned" flag
  and shows how many words are linked across verses. translationCore's own status
  (partial / untouched, pending) is unchanged on purpose: aligned USFM cannot
  express the link, so completion stays with translationCore. Links are refused when
  either word is already aligned within its own verse, or when both are in the same verse.
• Finding the range (#118). The page widens its default range with the verses the
  last chapter analysis marked as cross-verse realization, and says so. "Cross-verse
  alignment" is offered on possible-omission and possible-addition findings, in the QA
  queue's row menu and in the finding pane, opening the page on the finding's verses
  (switching chapter first if needed). In the verse list, Ctrl-click and Shift-click
  build a multi-selection that the toolbar button opens directly.
• The pipeline reads the links (#119). Stage 6B now treats an active cross-verse link
  as word-alignment evidence at the same weight as completed same-verse alignment, and a
  link change re-analyses what depended on it, so a passage a team has linked across
  verses raises fewer false omission and addition findings. No weight or threshold was
  tuned; the Stage 6B golden did not move. One measured limitation is recorded as #123.

Protocol simplification (#115)

Every engine call now goes through one generic engine_call command; the 86 Rust
forwarders are gone and adding a protocol method is an engine handler plus one TypeScript
line. Verified in the app by the cross-verse work above, which exercised alignment,
lexicon, analysis-job and QA-review calls through it.

Filed, not fixed

• #122 — in Align Words, pressing "Undo last change" twice re-applies the change,
  because each undo restores the latest backup and writes a new one. Pre-existing.
• #123 — a cross-verse link can tie with the split pseudo-span that pairs the linked
  word with its neighbour, leaving the relationship AMBIGUOUS instead of LOCATED.

Unchanged

The correction ledger, both goldens, the confidence thresholds, the semantic database
schema (v16), the workspace database (v2), aligned USFM export and translationCore's
completion state are all as in 0.10.3. Offline operation is unchanged.

Verification

Per issue: npm run check 0/0, npm run test (33 files, 419 tests at #118),
npm run build; pytest -n auto -m "not slow" (1030 passed at #119) plus the touched
test files and the Stage 6B golden by name; a real-app check at 1366×768 for #116, #117
and #118 with real pointer drags, recorded step by step in docs/BUILD_LOG.md
(2026-09-16 entries).

Bridge 0.10.3

Bridge 0.10.3

Bridge 0.10.3 is a patch release on 0.10.2 that carries out Group A of the
September simplification audit: dead protocol layers, unused modules and
point-in-time documents are removed, and two small performance fixes land.
Nothing about the on-disk project shape, the three schema ladders, the
correction ledger, the goldens or the confidence thresholds changes; a project
created by 0.10.0, 0.10.1 or 0.10.2 opens unchanged.

What was removed

Every item below had no caller in the UI, no importer in the engine, or both.
Each was re-verified against the code before deletion; the ones where the audit's
claim turned out to be incomplete are noted.

• 13 engine methods no Tauri command could reach (#102):
  project.sweepStart/Status/Cancel, semanticMapping.getForVerse/confirm/rerunForVerse,
  versification.detect/orgRef/backVersificationMap,
  alignment.corpusStats.summary/forVerse, verse.evidence, and the sweep job
  manager behind the first three. The modules they wrapped stay: versification
  (used by the Stage 4 runtime), alignment statistics (behind the live
  inconsistent-rendering finding, whose cache and invalidation are untouched)
  and the Stage 3 modules.
• ai.explain (#105), a synchronous duplicate of what the ai.review job
  does per verse, with no UI caller. Its selection-gate tests now drive the live
  ai.review.start job instead, with unchanged assertions.
• 47 protocol methods' Rust and TypeScript layers (#103): every Stage 4 to 8
  direct-access method except the two range getters the Alignment Review
  passage view uses, plus saveAlignment, completeAlignment,
  alignmentBackups, logos.*, paratextSetReference, triageClear,
  scanProject and projectCollectionReport. The Rust shell goes from 137 to
  90 commands, the client from 137 to 90 methods. The 1,491-line Rust mirror of
  the passage-semantic types (passage_semantic_wire.rs) is gone; the JSON
  schema it mirrored stays. The engine handlers all stay: the Stage 5 to 8 tests
  drive them by method string, and Logos remains reachable through
  navigation.*.
• Five engine modules with no importer (#104): the two machine-proposed
  benchmark evaluators, the Paratext registry HTTPS client, the Tk caret helpers
  from the legacy tool, and the Git identity reader. The benchmark datasets stay
  bundled.
• The corpus-discovery generator behind the finished IRVTam review (#101),
  and the dead showSource store (#106).
• Docs: six point-in-time review documents and HANDOFF.md moved to
  docs/archive/ with an index (#107). About 5.9k lines leave the reading
  path; nothing is deleted, and every inbound link is re-pointed.

Performance

• The desktop navigation poll no longer round-trips while sync is off
  (#110). The 800 ms tick used to cross Rust, stdio and Python about 75 times a
  minute even with neither Paratext nor Logos enabled. It now returns before the
  request unless a connector is enabled. Enabling sync in Settings starts the
  round-trips on the next tick, as before. This is verified from the code and
  the test suites, not yet in the installed app; the issue stays open for that
  check.
• project.open has a 180 s timeout (#112 step one) instead of the 30 s
  default, the same class as project.inspectImport, so a slow or scanned disk
  cannot make the shell give up while Python is still opening a book.

What stayed, on purpose

• The Stage 3 semantic-mapping engine and the AI alignment-proposal path.
  Their removal is a separate recorded decision (#109) and is not in this
  release.
• The four collection-report entry points (#108), likewise.
• verse_evidence.py now has no importer outside its tests; whether it is
  the intended shared evidence shape or dead is #120.
• Six more caller-less client methods and sixteen unused TypeScript exports
  the audit did not name are recorded in #121, not removed here.

Known limitations

• One commit reached main with a failing engine test (the #103 batch
  deleted a Rust file that one Python test read as text); the fix followed in
  the same session and main is green again at the commit this release is cut
  from. The lesson is recorded in docs/BUILD_LOG.md.
• The frozen-sidecar smoke check lost its versification, corpus-stats and
  ai.explain blocks with their methods; it still stops at the pre-existing
  project.inspectImport duplicate-classification mismatch, so the release
  workflow's smoke step remains continue-on-error.
• 0.10.0's upgrade rules still apply: a project holding any pre-cutover file
  store refuses to open and must be re-imported. See RELEASE_0.10.0.md.

Bridge 0.10.2

Bridge 0.10.2

Bridge 0.10.2 is a patch release on 0.10.1 that removes one finished
research workflow from the app: the Validate semantic mappings screen and
everything behind it. Nothing about the on-disk shape, the three schema
ladders, or the 0.10.0 upgrade rules changes; a project created by 0.10.0 or
0.10.1 opens unchanged.

What was removed

The project dashboard carried a Validate semantic mappings button (shown
as Enable semantic validation outside Advanced mode). It opened a review
queue of 40 machine-proposed cross-verse mappings in the Tamil IRV Luke and
Philippians corpus, built to check the Stage 3 semantic-mapping engine
against a human. That review was completed on 2026-08-31 (38 confirmed, one
corrected, one rejected) and the queue had no further purpose, so issue #100
removed it end to end:

• the dashboard button and the validation screen;
• the semanticValidation.list and semanticValidation.decide protocol
  methods, their Tauri commands and the engine service behind them;
• the bundled validation manifest: the installer no longer carries
  resources/semantic_mapping/validation/, and the sidecar build script no
  longer fails when it is absent;
• the generator script that produced the manifest, and its tests.

The Settings toggle Allow manual override stays. It still gates the
translation-helps review panel; it just no longer unlocks a second screen.

What stayed, on purpose

• The Stage 3 semantic-mapping engine underneath the queue. The optional
  AI review still builds its prompt context from it and still shows a
  semantic_mapping block on AI check reviews. Removing that engine is a
  separate, recorded decision (see docs/SIMPLIFICATION_AUDIT_2026-09.md,
  item B1) and is not part of this release.
• No schema change. The semantic_validation_runs table remains in the
  workbench database's v1 block, empty and unused, because the migration
  ladder is never edited in place. A future workbench bump may drop it.
• The pre-cutover guard. A project holding a pre-0.10.0
  semanticValidation/ directory still refuses to open and must be
  re-imported, exactly as in 0.10.0 and 0.10.1.

Record of the review

The per-project audit files that held the 40 raw decisions no longer exist
on any machine; the Tamil IRV projects were re-imported after the 0.10.0
data reset. The summary table in docs/DEVELOPER_GUIDE.md ("Historical
Beta 15 developer handoff") and docs/validation/README.md are the surviving
record, and the generated candidate manifest stays in docs/validation/ as
evidence. QA matrix rows M29 to M35 are retired.

Also in this release

• docs/ARCHITECTURE.md is rewritten as a current-state map of the code
  (process boundary, the three databases, pipelines, UI surfaces), and
  docs/SIMPLIFICATION_AUDIT_2026-09.md records what is slowing development
  down and what is slated for removal. Documentation only; no behaviour
  change.

Known limitations

• This is the first release build to run the trimmed sidecar build script.
  The change is a pure deletion of a copy step, and the frontend, Rust and
  Python gates passed on the source; the installer itself is the evidence
  that the frozen pair is unaffected.
• The frozen-sidecar smoke check still stops at the pre-existing
  project.inspectImport duplicate-classification mismatch, so the release
  workflow's smoke step remains continue-on-error.
• 0.10.0's upgrade rules still apply: a project holding any pre-cutover
  file store refuses to open and must be re-imported. See
  RELEASE_0.10.0.md.

Bridge 0.10.1

Bridge 0.10.1

Bridge 0.10.1 is a patch release on 0.10.0 with one purpose: importing a
whole Bible, and opening a large book for the first time, no longer time
out. Nothing about the on-disk shape, the three schema ladders, or the
0.10.0 upgrade rules changes; a project created by 0.10.0 opens unchanged.

What was wrong

The first import after the 0.10.0 data reset (hin-irv, 66 books) reported
sidecar request 'project.import' timed out although the import itself had
finished in about seven seconds. The next five minutes went into opening the
first book, Genesis, inside two places in the semantic runtime that each did
one SQLite commit, and therefore one fsync, per record:

• The alignment compatibility scan. A raw import writes every unaligned
  source word as its own alignment group with an empty target side. The scan
  quarantines each of those as LEGACY_EMPTY_BOTTOM_WORDS_AMBIGUOUS, one
  commit each: 20,612 commits for Genesis, 5m11s.
• Verse revision setup. The first open establishes a
  current_target_revisions row per verse, one read connection and one
  commit each: 1,533 commits for Genesis, about 21 seconds.

Neither was new. Both date from Stages 3 and 4 and surfaced now because a
whole-Bible import always opens Genesis first. Against the 30 second
project.open timeout, every first open of a book over roughly 2,000 source
words, which is most of the Bible, would have failed the same way and then
succeeded on a retry once the memoized work had finished in the background.
Issue #99 has the full timeline and evidence.

What changed

• Both writers batch. The scan collects its quarantine records and writes
  them in one transaction; verse revisions are read once for the book and
  every new one is established in one transaction. The single-record methods
  remain and delegate to the batch ones, so every other caller is unchanged.
• project.open and project.import each write one [trace] line to
  stderr with wall-clock seconds per phase. The Rust shell relays it into
  the diagnostics panel and engine-events.log under the app's log folder.
  It currently shows at level "warn" because the relay only distinguishes
  tracebacks; that mapping is a follow-up on #99.

Measured in the desktop app on the same laptop, same 66-book import:

Request	0.10.0	0.10.1
project.import, 66 books	timed out at 300s	7.5s
Open of the first book inside the import	5m11s	0.9s
Exodus, first open	about 22s	2.0s
Exodus, re-open	3.0s	0.4s

Safety properties retained

• No schema change in any of the three databases. migration_quarantine
  and current_target_revisions are the same tables with the same rows;
  only the number of transactions producing them changed.
• The scan's crash-safety is unchanged: both digests are still plain
  content-addressed idempotency checks, and a crash between the batch and
  its migration_runs row simply redoes the scan.
• A verse whose text changed outside Bridge still takes the per-reference
  prepare/apply intent pair; only the establish-new path is batched.
• Nothing auto-applies, nothing touches Scripture or native alignment data.

Known limitations

• The frozen-sidecar smoke check still stops at the pre-existing
  project.inspectImport duplicate-classification mismatch, so the release
  workflow's smoke step remains continue-on-error. The checks before it
  (info, resource provenance, a 66-project import, open, registry) pass on
  the 0.10.1 sidecar.
• Whether the scan should quarantine the raw-import empty-alignment shape
  at all, rather than merely quarantine it quickly, is an open design
  question on #99. This release does not change what is quarantined.
• 0.10.0's upgrade rules still apply: a project holding any pre-cutover
  file store refuses to open and must be re-imported. See
  RELEASE_0.10.0.md.

Bridge 0.9.7

Bridge 0.9.7 lets Stage 6B's location engine consult completed
translationCore Word Alignment as location evidence, closes three defects
a follow-up review found in that change before it ever reached a release,
and removes a pointless Edit→Save round-trip before a manually written
correction proposal can be applied.

Companion storage moves from schema v14 to v15 (additive; a v14
database opens and migrates automatically, and every pre-existing record
reads back unchanged). Correction verification remains
correction-verification-policy-v2.

Highlights

• Stage 6B now scores a WORD_ALIGNMENT evidence component from any
  same-verse translationCore alignment group already marked completed,
  at the same weight (0.65) the existing HUMAN_PRECEDENT component
  uses — a source verse a translator has already aligned to its target
  now helps Stage 6B locate a QA finding correctly, rather than that
  alignment work going unused by location search. Cross-verse alignment
  and any embedding-provider direction remain future work under #54.
• Fixed a casefolding bug that could silently drop this new evidence for
  any target text containing a cased word pair (most scripts with
  separate upper/lower case) — word/occurrence identity now compares
  exact NFC text, never casefolded, matching how occurrences are counted
  everywhere else in Bridge.
• The new alignment-evidence dependency edge is now written in the same
  transaction as the location run it protects, closing a crash window
  that could otherwise leave a run permanently immune to invalidation.
• A verse-bridge alignment group (e.g. one spanning "PHP 1:2–3") is now
  actually excluded from this evidence, matching what was already
  documented — previously nothing enforced it.
• Alignment state changes made through a scripture edit, a correction
  application, or completing an alignment now all correctly refresh the
  memo Stage 6B's invalidation check compares against — previously two of
  those three paths could leave a just-published, still-correct location
  run spuriously marked stale on the next time the project is opened.
• A manually written correction proposal is now usable immediately —
  "Review application" no longer requires an Edit→Save round-trip first.
  That round-trip was already unchecked self-review with no distinct
  reviewer required, so this removes a step that added no real review,
  not a safety control. Existing proposals stuck in this state are
  repaired automatically, in place, the next time they're opened.

Safety properties retained

• No Scripture is changed without explicit human Apply confirmation.
• A wrong or unresolved Word Alignment match never becomes location
  evidence — anything but exactly one clean match on both the source and
  target side is dropped entirely rather than guessed at, costing that
  one alignment group's contribution, never a whole search.
• Nothing in this release ever writes to translationCore's own alignment
  data or completion markers; Bridge only reads them.
• Every automatic reseed of a stuck correction proposal's review status
  is attributed to a MIGRATION actor, never the named human reviewer,
  and is fully audited as its own event.
• The optimistic-concurrency revision a reviewer's session has cached
  is never invalidated behind their back by an automatic reseed.
• No weight, threshold, or scoring formula changed for any existing
  evidence component; the Stage 6B golden fixture is byte-identical.

Known limitations

• Cross-verse Word Alignment evidence and any embedding-provider-backed
  location matching remain future work (#54 follow-on).
• The author-≠-reviewer distinction for correction proposals is
  deliberately not built yet; a human-authored proposal is approved by
  its own author today, same as before this release, just without the
  Edit→Save ceremony. A dedicated reviewer field is planned for the
  #74–#81 team-workflow milestone.
• The Windows installer is unsigned and may show a SmartScreen warning.
• Windows x64 is the verified target; macOS and Linux remain unverified.
• Installed acceptance Cases A–D (Tamil negation, NFC/NFD equivalence,
  the Stage 9B.4 correction loop, and Greek/Hebrew source safety) were
  not run before this release was published — see
  docs/ACCEPTANCE_TEST_GUIDE.md and docs/V1_1_UNICODE_ACCEPTANCE.md.

Windows installer

Bridge_0.9.7_x64-setup.exe (attached below), built by this repo's own
CI (.github/workflows/release.yml).

SHA-256: CDB662CF6211988AC6637D6FE34FFBF06C1037959CAA6CA122EBB389A331D78F

Full verification numbers and build details are in
docs/RELEASE_0.9.7.md.