Tabrix v2.7.0 Release Notes

v2.7.0 is the MKEP product-surface pruning and browser-read reliability release. It removes retired assistant/workflow/local-model surfaces, tightens Browser Hygiene around real Chrome sessions, and improves generic page-read fail-fast behavior for unreadable documents.

The release remains backward compatible for the supported MCP read/control tools except for the explicitly removed experimental surfaces listed below. The removed tools were not part of the current MKEP product boundary.

Removed

• Removed the embedded Smart Assistant / Quick Panel / Element Picker stack from the extension and native server. Upstream AI clients remain the intended drivers.
• Removed Record-Replay / Workflow builder surfaces and the retired run_flow / list_published_flows MCP tools.
• Removed local semantic search/model surfaces including search_tabs_content, ONNX/WASM model assets, local vector-search dependencies, and related popup pages.
• Removed Element Marker management and Visual Editor v2 surfaces. markedElements remains an empty compatibility field in chrome_read_page responses.
• Rebuilt the sidepanel around MKEP placeholder tabs: Memory, Knowledge, and Experience.

Fixed

• chrome_close_tabs now requires explicit tabIds or url; empty-argument cleanup no longer closes the active user tab.
• read_page and chrome_get_web_content now surface Chrome error pages / unreadable documents as structured success=false, reason=page_unreadable, pageType=browser_error_page payloads.
• Navigation/read guidance now distinguishes stale pages, readable pages, loading pages, and unreadable/error pages instead of encouraging unsafe reads.
• read_page can recover visible DOM/text rows when structured extraction returns no business rows, preserving a generic fallback without adding site-specific GitHub/XHS/Douyin logic.
• Production logging governance and LF line-ending enforcement were tightened to reduce CI/release drift.

Release Gate Summary

Gate B strict PASS evidence is required before publishing this release. The release gate checks the maintainer-private real-browser benchmark report and validates API/DOM fallback behavior, operation-log writes, primary-tab reuse, latency gates, competitor deltas, and sensitive-data persistence.

Public-safe summary of the accepted Gate B contract:

• evidence kind: real MCP / real browser
• API knowledge hit rate above threshold
• read-page avoidance and token-saved counters present
• operation-log write rate above threshold
• primary tab reuse above threshold
• max concurrent benchmark tabs within limit
• competitor behind count is zero
• latency gate failures are zero
• sensitive persisted count is zero
• seed_adapter remains a transitional source lineage and is disclosed here intentionally

Known Boundaries

• v2.7.0 does not claim arbitrary-platform API/interface reuse. API reuse remains evidence-bounded; broader observed-endpoint reuse and lifecycle sensing continue after this release.
• Same-profile browser reuse is a core Tabrix requirement, but it is not unique to Tabrix. Other extension-backed browser tools can also operate against the user's real Chrome profile.
• The release does not claim full competitor superiority. Competitor comparison remains evidence-bounded by tool path, profile mode, data source quality, and scenario coverage.
• DOM fallback success is not claimed as API/CDP parity.
• Private real-browser artifacts and raw benchmark JSON stay outside public docs by design.

Tabrix v2.6.1 Release Notes

Release date: 2026-04-27.

Summary

v2.6.1 is the releaseable patch for the v2.6 line after the initial
v2.6.0 tag exposed a fresh-checkout release-gate issue in GitHub Actions.
The product behaviour is the v2.6 knowledge-assisted reading mainline:
generic network-observe classifier, Endpoint
Knowledge lookup, a Knowledge-driven on-demand reader, a Policy-aware
data-source router, and explicit endpointSource lineage
(observed / seed_adapter / manual_seed / unknown).

GitHub and npmjs seed adapters remain part of the v2.6 transition and
validation path. Their hits are reported as seed_adapter evidence
instead of being presented as generic observed endpoints. Broader
observed-endpoint reuse across arbitrary site families remains a v2.7
scope item. DOM L0+L1 fallback stays the safe recovery path when an
API route is unavailable, times out, or fails semantic validation.

The release also formalises verified-empty API results. When a
knowledge-driven endpoint succeeds with zero rows, Tabrix emits
emptyResult: true with an emptyReason, so downstream consumers do
not confuse a valid empty list with an API failure.

v2.6 is backward-compatible with v2.5 callers. Public MCP input schemas
are unchanged; new output fields are additive and optional.

Highlights

• Direct API execution path: read-only search/list/detail tasks can
  execute through the Knowledge-driven API route without forcing a
  browser navigation first.
• Execution vs learning mode split: production execution does not
  run foreground network capture by default; learning mode is explicit.
• Generic network-observe classifier: observed requests are
  classified into closed semantic buckets such as search, list, detail,
  pagination, and filter candidates.
• Endpoint Knowledge reader: endpoint lookup and request planning
  happen through Knowledge first; seed adapters are compatibility
  sources, not generic observed-endpoint proof.
• Unified Layer Contract: API, DOM JSON, Markdown, and Experience
  replay are normalised into a shared layer contract so the router can
  choose the lowest sufficient data source.
• Operation log explainability: operation logs include structured
  decision and fallback context, enabling later replay of why a step
  used API, DOM, or fallback.
• Verified empty results: empty API lists are explicit successful
  results, not silent failures.
• Latency and competitor gate: the v26 benchmark transformer tracks
  per-scenario latency budgets, competitor deltas, resilience wins, and
  strict release-blocking evidence.
• Short-lived compact result cache: repeated identical read-only API
  reads in one runtime window reuse compact in-memory rows. This is not
  persisted Knowledge or Experience data.

Real-Browser Acceptance

Gate B strict PASS was completed in the maintainer-private acceptance
repository on the v2.6 release-candidate product build. v2.6.1 adds the
fresh-checkout release-gate fix needed for GitHub Actions publication; it
does not change the validated runtime behaviour.

Public-safe evidence summary:

Private artifacts include the raw NDJSON, transformed v26 benchmark
report, Gate B summary, and per-scenario evidence. Raw evidence and raw
per-scenario timings are intentionally not committed to the public
repository.

Compatibility

Additive output fields include emptyResult, emptyReason,
emptyMessage, endpointSource, cache telemetry, and layer-contract
metadata on existing envelopes.

Verification

Commands run on the release candidate:

pnpm -C app/native-server test:ci -- --testPathPattern "api-knowledge|direct-api-executor|choose-context-direct-api|v26-benchmark"
pnpm -r typecheck
pnpm -C app/native-server build
pnpm -C app/chrome-extension build
pnpm run docs:check
pnpm run size:check
pnpm run extension:reload
pnpm run acceptance:v2.6.0:gate-b -- --run-id gate-b-release-candidate-2026-04-27-r4

The final release gate also validates the private v26 benchmark report
through pnpm run release:check.

Known Limitations

• endpointSource = 'seed_adapter' is expected for live GitHub/npmjs
  seed hits in v2.6. Fully generic observed-endpoint reuse is planned
  for v2.7.
• The API path only handles read-only endpoint reuse. Mutating API calls
  remain out of scope.
• The compact result cache is process-local and short-lived. It is a
  latency optimization, not persistent Knowledge.
• Operation-log replay is read-only. It does not write Experience rows
  or trigger ranking/scoring.
• Resilience-win wording means availability/resilience improvement, not
  an absolute speed lead.

Tabrix v2.5.0 Release Notes

Release date: 2026-04-24.

Summary

v2.5.0 is the first release in which tabrix_choose_context emits a
deterministic, caller-facing layer-dispatch policy signal (chosen
layer, dispatch reason, source route) computed at chooser time. The
chooser delegates the L0 / L0+L1 / L0+L1+L2 selection to a new pure
dispatcher (choose-context-layer-dispatch.ts) that linearly scans
the strategy table from V3.1 §11; chrome_read_page accepts the new
optional requestedLayer field and only emits the layers that were
asked for; and the chosen layer + dispatch reason + source route are
persisted to tabrix_choose_context_decisions so the new sidepanel
Execution tab and the v25 release gate can both consume the same
evidence.

The signal is advisory: the chooser does not itself call
chrome_read_page and does not itself skip it. The upstream
caller (LLM / agent) reads the chooser's output and decides whether
to honour the signal — for example, when sourceRoute is
'experience_replay_skip_read', the caller is expected (per the
contract documented in
packages/shared/src/read-page-contract.ts) to replay the recorded
path directly without first calling chrome_read_page. If the
caller ignores the signal and still calls chrome_read_page, the
extension still serves the request — only the token-saving and
latency-reduction goals captured in the v25 KPIs are forfeited for
that turn.

v2.5.0 dispatcher priority — honest accounting. The strategy
table inside dispatchLayer places the
experience_replay_executable rule at priority 5, AFTER user-intent
overrides (priority 2), task-type overrides (priority 3), and
page-complexity overrides (priority 4). In v2.5.0 the chooser hard-
codes candidateActionsCount = 0 and hvoCount = 0 when calling
dispatchLayer, which means priority-4's simple_page_low_density
rule fires for any non-empty pageRole. As a consequence,
sourceRoute = 'experience_replay_skip_read' only actually surfaces
through tabrix_choose_context when BOTH (a) the caller's intent
classifies to the 'unknown' user-intent bucket (it does NOT match
summary / details / open / select / form / submit keywords), AND
(b) the caller's pageRole is empty. This is intentional — the
chooser respects an explicit user-intent override even when an
Experience candidate is replay-eligible (V25-04 stability binding).
Future versions may extend the chooser to feed real per-page facts
into dispatchLayer (lifting the hard-coded zeros) and may
re-evaluate the priority order; v2.5 does not.

The release is backward compatible with v2.4.x. Every new field on
existing tools is optional. The dispatcher's
experience_replay_skip_read source route only fires when an
Experience candidate is replay-eligible AND safe, so previous-version
callers (which never read the new fields) keep their existing
read-page behaviour by default.

Highlights

V25-01 — v2.5 benchmark substrate

• New transformer app/native-server/src/benchmark/v25-benchmark.ts
  (pure function, no IO). Pinned at BENCHMARK_REPORT_VERSION = 1 and
  cross-source-checked by both v25-benchmark.test.ts and
  release-gate-v25-fs.test.ts.
• New CLI pnpm run benchmark:v25
  (scripts/benchmark-v25.mjs): reads NDJSON, writes
  docs/benchmarks/v25/<runId>.json, supports --gate (gate-then-write
  semantics, hard reasons block the write), and --baseline-v24 <v24-report.json> to auto-emit the v25-vs-v24 baseline table.
• New gate library scripts/lib/v25-benchmark-gate.cjs (independent
  CommonJS file from v23/v24). Hard invariants: reportVersion === 1,
  lane integrity, K3 ≥ 0.85, K4 ≤ 0.10, non-empty scenarios,
  pairedRunCount ≥ 3 per declared KPI scenario, L0 token-ratio
  median ≤ 0.35, L0+L1 token-ratio median ≤ 0.60, K3 / K4 / median
  tool-calls / click-attempts / visual-fallback / JS-fallback
  regression ceilings vs v2.4 baseline, baseline comparison table
  embed in release notes, and no release-note placeholders.

V25-02 — layer dispatch runtime + telemetry migration

• New shared DTO ReadPageRequestedLayer /
  LayerDispatchReason / LayerSourceRoute (closed enums) in
  packages/shared/src/read-page-contract.ts.
• New pure dispatcher dispatchLayer(input) in
  app/native-server/src/mcp/choose-context-layer-dispatch.ts:
  priority-ordered linear scan (safety override → user intent override
  → task type → page complexity → MKEP support → fail-safe default).
  Strategy Table row 8 is locked to chosenLayer = 'L0',
  sourceRoute = 'experience_replay_skip_read'. The dispatcher
  produces a caller-facing signal only; whether
  chrome_read_page is actually skipped is the upstream caller's
  call (the chooser itself never calls or skips read_page).
  Internal errors fall back safely to chosenLayer = 'L0+L1+L2',
  sourceRoute = 'dispatcher_fallback_safe' instead of throwing
  into tabrix_choose_context.
• chrome_read_page schema gains an optional requestedLayer. The
  background tool respects the request: L0 returns no L1
  candidateActions and no L2 details but still populates
  highValueObjects and the per-tab stable targetRef registry, so
  chrome_click_element keeps resolving tgt_* even when the chooser
  asks for the smallest envelope.
• tabrix_choose_context_decisions migration adds 7 nullable
  columns: chosen_layer, layer_dispatch_reason, source_route,
  fallback_cause, token_estimate_chosen,
  token_estimate_full_read, tokens_saved_estimate,
  knowledge_endpoint_family (telemetry only — must not drive any
  v2.5 routing). The migration uses the ensureXxxColumn idempotent
  pattern.

V25-03 — Execution Value UI + native read-only routes

• New Execution tab in the sidepanel (tabs/ExecutionTab.vue) that
  surfaces: chosen-layer distribution, source-route distribution,
  estimated tokens saved, top action paths, fallback / replay
  reliability signals. Empty state explicitly tells the operator that
  no execution decisions have been recorded yet.
• New native HTTP routes (Fastify, all { status: 'ok', data }):
  GET /execution/decisions/recent?limit=,
  GET /execution/savings/summary,
  GET /execution/action-paths/top?limit=,
  GET /execution/reliability/signals. PII-safe: responses only
  expose explicitly listed safe fields; raw query-string URLs,
  cookies, authorization headers, and user_input columns are never
  serialised.
• Bundle gate raised to JS soft 35 kB / hard 40 kB and CSS soft 25 kB
  / hard 28 kB in the same commit as the Execution tab landed
  (scripts/check-bundle-size.mjs). The CSS lift is documented inline
  with the rationale; future tabs reuse the existing exec- prefix.

V25-04 — Ground stability guard + release diagnostic CLI

• New contract test
  app/chrome-extension/tests/click-resolution-l0-contract.test.ts
  pins that chrome_read_page({ requestedLayer: 'L0' }) still
  populates the stable targetRef registry and that
  chrome_click_element can resolve tgt_* to a live ref_* using
  only the L0 envelope. Markdown ref-free invariant under L0 is
  re-asserted.
• Experience replay no-regression: new tests in
  experience-replay.test.ts pin that rows persisted under reduced L0
  envelopes still get sanitizePortableSteps to drop per-snapshot
  ref_*, tabId, windowId, frameId, coordinates, and
  candidateAction.locatorChain {type:'ref'} entries; ref-only
  rows fail-closed regardless of the envelope.
• New structural pin in click-contract.test.ts: mergeClickSignals
  arity is 3 — no verifier verdict can promote no_observed_change
  into success. Verifier surface (verifierContext + browser readback) remains independent of read-page L-layer envelopes.
• New release-only diagnostic CLI scripts/release-diagnostic-v25.mjs
  prints stability + layer counters from a v25 report (text or
  --json). Hard non-goal: it does NOT enforce thresholds — that's
  the v25 gate library, wired into release-check by V25-05 below.

V25-05 — release gate wiring + release evidence

• scripts/check-release-readiness.mjs adds a benchmarkGateAppliesV25
  branch that preempts the v24 branch (which still applies to v2.4.x).
  The chain is now v25 → v24 → v23, mutually exclusive in
  version-descending order. --allow-missing-notes still does NOT
  bypass the v25 content gate, the baseline-comparison-table embed
  requirement, the pairCount check, or release-note placeholder
  rejection (mirrors V23-06 / V24-05 closeouts).
• New fs-level test release-gate-v25-fs.test.ts covers passing
  reports, missing reports, stale reports, bad report version,
  missing baseline comparison table, link-only table rejection, bad
  L0 token ratio, K3 / K4 regression, median tool-call regression,
  visual / JS fallback regression, and the explicit "release notes
  still contain placeholder text" negative.
• The pre-release notes draft shipped with placeholder text for every
  measured number. This canonical release file replaces those values
  with real v2.5 MCP benchmark evidence.

Compatibility

Tabrix v2.4.0 Release Notes

Release date: 2026-04-23.

Summary

v2.4.0 is the first release whose Experience layer learns from its own replay outcomes. The chooser ranks Experience candidates with a deterministic composite score, the replay engine writes outcome deltas back into the Experience repository through an isolated write-back path, and a new experience_score_step MCP tool lets external clients participate in the same loop. The release also lands the v2.4 benchmark framework + release gate so that future v2.4+ tags must ship with a real-browser pair-aware report under docs/benchmarks/v24/.

The release is backward compatible with v2.3.x. Every new MCP tool is additive; every new field on existing tools is optional. The chooser's experience_replay strategy stays disabled by default until the operator opts in via the existing experience_replay capability (V23-05 brief). The v2.3 release gate path under docs/benchmarks/v23/ remains intact for v2.3.x tags.

Highlights (what's actually new since v2.3.0)

V24-01 — experience_replay v1 (already on main from previous package)

• New native MCP tool experience_replay: re-executes a previously recorded experience_action_paths step list against the current page, fail-closed on the first non-recoverable step, with structured per-step evidenceRefs for downstream Experience scoring. Capability-gated under experience_replay (single capability, single switch).
• Replay engine sanitises step args before dispatch (P1 fix, already on main).
• See docs/B_EXPERIENCE_REPLAY_BRIEF_V1.md and the V24-01 handoff for full surface.

V24-02 — experience_score_step + replay outcome write-back

• New native MCP tool experience_score_step (P1, capability-gated under the existing experience_replay capability — single switch governs replay + score-step). Records the observed outcome of one replay step against an experience_action_paths row using the ClickObservedOutcome enum from packages/shared/src/click.ts (no parallel enum).
• ReplayEngine now hooks an isolated outcome writer: per-step success/failure deltas, last_replay_at, and last_replay_outcome flow into the Experience repository on the same path the new MCP tool uses.
• New experience_writeback_warnings table catches isolated failures: when a write-back fails (e.g. row-not-found, FK violation), the replay primary path is unaffected (evidenceRefs[i] is preserved verbatim) and a structured warning row is recorded for post-mortem. The Experience layer loses one learning sample but the user-visible replay does not regress.
• New session-end composite-score writer (composite-score.ts pure module + SessionCompositeScoreWriter) projects per-session components (accuracy / speed_norm / token_norm / stability) into memory_sessions.composite_score_raw + composite_score_components_blob and into the cached experience_action_paths.composite_score_decayed field via applyRecencyDecay(rawScore, daysSinceRun) = raw * 0.5^(daysSinceRun / 30).
• New Knowledge taskWeights v1 baseline (accuracy: 0.40 / speed: 0.20 / token: 0.30 / stability: 0.10) plus two GitHub seeds (releases/new, search).
• tabrix_choose_context reads but never writes the cached score (V24-03 below).

V24-03 — tabrix_choose_context v2 ranked replay-aware

• tabrix_choose_context now returns a single experience_ranked artifact whenever any Experience candidate surfaces. The artifact carries the deterministic top-3 ranking (EXPERIENCE_RANKED_TOP_N = 3) computed from the cached composite score (with recency decay) and per-task weights.
• New result fields: rankedCandidateCount, replayEligibleBlockedBy, replayFallbackDepth. ReplayEligibilityBlockReason is a closed enum (capability_off | unsupported_step_kind | non_portable_args | non_github_pageRole | below_threshold | stale_locator | none) and the chooser surfaces the FIRST blocker in the documented order so post-mortem grouping is deterministic.
• Strict v2 thresholds for the experience_replay strategy: EXPERIENCE_REPLAY_MIN_SUCCESS_RATE = 0.80 AND EXPERIENCE_REPLAY_MIN_SUCCESS_COUNT = 3 AND a portable-args-and-supported-step-kind check. Below those, the chooser downgrades to experience_reuse (the legacy v1.5 path is unchanged for the reuse branch).
• Chooser is locked OUT of per-step Memory tables via a Memory-not-read invariant test (greps the chooser source for step-repository / session-repository and fails the suite on accidental import).
• Telemetry table schema is INTENTIONALLY UNCHANGED in v2.4: the chooser does NOT persist the new V24-03 fields to tabrix_choose_context_decisions. Long-term ranked-depth statistics ship in v2.5 alongside K6 trend instrumentation; this avoids regressing the v2.3 release gate.

V24-04 — DEFERRED to v2.5

• The K8 token-cache work (V24-04) is deferred per the v2.4.0_p0_chain plan §6.4 conditional. v2.5 picks it up only if the maintainer's real-MCP benchmark shows K8 < 0.40 (i.e. the second-touch saves less than 40 % of first-touch input tokens). Until then, the v2.4 benchmark gate emits WARN: K8 … evidence but does not block on it. (v2.4.0 closeout: K8 is the TOKEN SAVING RATIO (first - second) / first; HIGHER is better; target ≥ 0.40 — the previous "second / first, lower is better" wording was inverted vs. the gate target and has been corrected.)

V24-05 — Real-browser benchmark v2 framework + v2.3 baseline gate

• New benchmark transformer app/native-server/src/benchmark/v24-benchmark.ts (pure function, no IO). Pair-aware: each KPI scenario emits two kind: 'pair' records (first_touch / second_touch) binding tool-call sequence numbers to roles. Computes K1..K4 (carried forward from v23 semantics, unchanged) plus the v2.4 K5..K8:
  • K5 second-touch speedup: firstTouchDurationMs / secondTouchDurationMs, MEDIAN across pairs.
  • K6 replay success rate: per-pair successCount / replayCount for second-touch tool calls tagged chooserStrategy = 'experience_replay', MEDIAN.
  • K7 replay fallback rate: per-pair fallbackCount / totalSecondTouchCount, MEDIAN.
  • K8 token saving ratio: (firstTouchTokensIn - secondTouchTokensIn) / firstTouchTokensIn, MEDIAN. HIGHER is better; the V24-04 trigger is K8 < 0.40 (i.e. second-touch saves less than 40 % of first-touch input tokens). v2.4.0 closeout corrected the prior "second / first, lower is better" wording, which was inverted vs. the documented gate target.
• New replayEligibilityDistribution and replayEligibilityBlockedBy distributions derived from per-tool-call V24-03 chooser metadata (chooserStrategy, chooserBlockedBy). Lets Codex see "we had a candidate but blocked it because: …" at the run level.
• New CLI wrapper pnpm run benchmark:v24 (scripts/benchmark-v24.mjs): reads NDJSON, writes docs/benchmarks/v24/<runId>.json, supports --gate (gate-then-write semantics, hard reasons block the write), and --baseline <v23-report.json> to auto-emit docs/benchmarks/v24/v24-vs-v23-baseline-<date>.md with the canonical metric | v2.3.0 baseline | v2.4.0 median | delta | direction table.
• New release gate scripts/lib/v24-benchmark-gate.cjs (independent CommonJS file from v23): hard invariants are lane-integrity / K3 ≥ 0.85 / K4 ≤ 0.10 / non-empty scenarios / reportVersion === 1 / pairCount ≥ 3 per declared KPI scenario / baseline comparison table embed in release notes; soft (WARN:) reasons cover K5..K8 guidance (K5 ≥ 1.5, K6 ≥ 0.80, K7 ≤ 0.20, K8 ≥ 0.40 — K8 is "higher is better" under the closeout-corrected (first - second) / first semantic). Gate-then-write blocks --gate from leaving a failing JSON on disk.
• scripts/check-release-readiness.mjs adds a benchmarkGateAppliesV24 branch (v2.4.0+) preempting the v23 branch (which still applies to v2.3.x). --allow-missing-notes still does NOT bypass the v24 content gate, the baseline-comparison-table embed requirement, or the pairCount check (mirrors the V23-06 closeout).

Compatibility

Tabrix v2.3.0 Release Notes

Release date: 2026-04-23.

Summary

v2.3.0 is the third minor release on the 2.x line. It is the first release whose release gate is real-browser–anchored: pnpm run release:check now refuses to ship a v2.3.0+ tag without a recent (≤7 days old) docs/benchmarks/v23/<run>.json report that passes the K3 / K4 / lane-integrity gate. v2.1 / v2.2 ship-grade behaviour is unchanged — the gate only applies to 2.3.0+.

The release is backward compatible with v2.2.x. Every new MCP tool is additive and either P0 (read-only) or carries requiresExplicitOptIn: true; every new field on existing tools is optional. The only behavioural default change is the V23-04 chooser branch landing the new read_page_markdown strategy on a hand-curated GitHub whitelist — outside that whitelist callers see no change.

Highlights (what's actually new since v2.2.0)

V23-01 — Execution-Truth Hardening (extension)

• Click-verifier window alignment: chrome.tabs.onCreated observation window in app/chrome-extension/entrypoints/background/tools/browser/interaction.ts is now driven by the exported CLICK_VERIFIER_SETTLE_DELAY_MS constant rather than a private timeout, removing the documented timing drift between new-tab observation and click verifier settle delay.
• Tabrix-owned lane integrity: every successful chrome_click_element response now carries an explicit lane: 'tabrix_owned' marker. The new evaluateBenchmarkGate predicate (V23-06) hard-fails the release if any tool call shows up on the cdp or debugger lane in the run report — silent fallback to the debugger lane is no longer a quiet regression.
• Surgical probe reduction: low-value duplicate read_page probes on the GitHub edit/save flow were trimmed; the v2.3.0 benchmark report tracks readPageProbeCount as a soft signal so a future regression is visible.

V23-02 — Stable targetRef increment hardening

• New app/chrome-extension/tests/stable-target-ref-stability.test.ts exercises three classes of cosmetic DOM mutation (sibling deletion, class change, whitespace-only text change) and one ordinal-collision case against the same HVO; all assert targetRef invariants from B-011 v1.
• tabrix-private-tests gains scenario T5-F-GH-STABLE-TARGETREF-CROSS-RELOAD (read_page → reload → read_page → assert same targetRef resolves through the click bridge). Maintainer must run this scenario as part of v2.3.0 acceptance — see §"Maintainer command list".

V23-03 / B-015 — read_page(render='markdown') + L2 source routing

• packages/shared/src/read-page-contract.ts adds the optional render?: 'json' | 'markdown' input field (defaulting to 'json', no behaviour change for existing callers) plus the new L2 source-routing fields domJsonRef / markdownRef / knowledgeRef so a caller can ask "give me the cheap reading surface" without losing access to the execution truth.
• The extension's read-page.ts now emits an optional markdown projection through the new helper read-page-markdown.ts. Markdown is intentionally a reading surface — HVOs, candidate actions, and targetRef continue to live in the JSON branch, and the markdown projection deliberately omits ref / targetRef values so callers cannot accidentally execute against a markdown view (B-015 invariant from docs/TABRIX_THREE_LAYER_DATA_COORDINATION_V1.md §4.3).
• New tests: read-page-render-markdown.test.ts, read-page-l2-source-routing.test.ts. B-015 flips from pool to done.

V23-04 / B-018 v1.5 — tabrix_choose_context telemetry + outcome write-back + markdown branch

• New SQLite tables tabrix_choose_context_decisions (one row per status='ok' chooser call: decision_id, intent_signature, page_role, site_family, strategy, fallback_strategy, created_at) and tabrix_choose_context_outcomes (one row per write-back, FK to decisions). Idempotent CREATE IF NOT EXISTS — old DBs from before V23-04 pick up the tables on next open without a migration.
• runTabrixChooseContext returns the new opaque decisionId field. Telemetry write failures never poison the chooser result (the decisionId is simply omitted, treated as "telemetry off").
• New MCP tool tabrix_choose_context_record_outcome (P0, pure-INSERT, native-handled). Closed outcome set: reuse | fallback | completed | retried. Three structural statuses: ok | invalid_input | unknown_decision — caller can distinguish "decision lost" from "permission denied".
• New strategy read_page_markdown joins ContextStrategyName. Routed when no experience hit AND no usable knowledge AND siteFamily === 'github' AND pageRole is on the hand-curated MARKDOWN_FRIENDLY_PAGE_ROLES whitelist (today: repo_home; pre-listed for forward-compat: issue_detail, pull_request_detail, discussion_detail, wiki, release_notes, commit_detail).
• New release-evidence script pnpm run release:choose-context-stats aggregates strategy distribution and outcome ratios from the telemetry tables.

V23-05 / B-EXP-REPLAY-V1 — experience_replay v1 owner-lane brief (no implementation)

• New design doc docs/B_EXPERIENCE_REPLAY_BRIEF_V1.md specifies the v1 contract for experience_replay: input/output DTOs, proposed risk tier (P1 + requiresExplicitOptIn + new experience_replay capability), closed failure-code enum, fail-closed step semantics, Memory write-back via the existing memory_sessions + memory_steps shape, and a 3-layer test matrix (unit + integration + private-repo T5-G-experience-replay).
• No code lands in v2.3.0 for experience_replay. The brief enumerates 7 owner-lane open questions that gate any future implementation; per AGENTS.md §"Tiered Execution Model" they cannot be answered by fast-lane.

V23-06 — Benchmark framework + release gate

• New benchmark transformer app/native-server/src/benchmark/v23-benchmark.ts (pure function, no IO) projects an NDJSON tool-call log into a deterministic v2.3.0 release-evidence report covering K1–K4 plus probe count, lane-integrity counters, mean click attempts per step, and scenario completion. BENCHMARK_REPORT_VERSION = 1; bumping is a coordinated change with release:check.
• New CLI wrapper pnpm run benchmark:v23 reads an NDJSON run produced by the maintainer's real-browser session (or by tabrix-private-tests against it), writes docs/benchmarks/v23/<runId>.json, and optionally exits non-zero on --gate failure.
• pnpm run release:check now enforces a v2.3.0+ gate: a recent (≤7 days old) report under docs/benchmarks/v23/ is required and the release notes should reference a benchmarks/v23 path. Older releases (v2.1 / v2.2) are unaffected. The hard numeric thresholds (K3 ≥ 0.85, K4 ≤ 0.10, lane violations = 0) live in evaluateBenchmarkGate with documented defaults; a maintainer can tighten them in a follow-up but loosening them requires a documented decision.

Compatibility

Release verification (CI / unit / integration)

This section is what fast-lane can fill in deterministically (no real Chrome).

• pnpm -r typecheck — green.
• pnpm -C app/native-server test:ci — green; full native-server suite including the new v23-benchmark.test.ts, choose-context-telemetry.test.ts, V23-04 chooser branches, V23-05 brief is doc-only.
• pnpm -C app/chrome-extension test — green; including the V23-01 lane-integrity tests and V23-02 stable-targetRef-stability tests.
• pnpm run docs:check — green.
• pnpm run release:choose-context-stats -- --since 7d — produces a valid report (or refuses on a pre-V23-04 DB, which is the documented behaviour).

Real-browser acceptance evidence

The released v2.3.0 benchmark baseline was exercised against a live Chrome session bound to the maintainer's GitHub account and then projected through pnpm run benchmark:v23 -- --input <ndjson> --gate.

• Run ID: v23-baseline-2026-04-23
• Build SHA: 52b1b260c2c82ac04050d4eeab8fc3730efa9ab6
• Acceptance summary: E:/projects/AI/codex/tabrix-private-tests/artifacts/v23-real-browser-acceptance/v23-real-browser-acceptance-2026-04-22T18-09-05.099Z/summary.json
• Report file: docs/benchmarks/v23/v23-baseline-2026-04-23.json
• Scenario result: 8/8 passed, blocked=false
• Headline numbers:
  • K1 mean input tokens per task: null (current CLI envelope did not surface token usage for this run)
  • K2 click p50: 7340 ms
  • K3 task success: 1.0
  • K4 retry rate: 0
  • K4 fallback rate: 0
  • lane violations: 0
  • meanClickAttemptsPerStep: 1
  • readPageProbeCount: 14
  • totalToolCalls: 29
• Caveats observed:
  • This release uses the final baseline run after extension rebuild + reload. Ear...

Tabrix v2.2.0 Release Notes

Release date: 2026-04-22

Summary

v2.2.0 is the second minor release on the 2.x line. It is the first release that
delivers visible MKEP Stage 3 capability across all four layers — Memory
(read API + Sidepanel surface), Knowledge (UI Map + API capture), Experience
(action-path aggregator + read-side MCP tool), and Policy (capability opt-in
gate) — plus the first stable identity contract for high-value objects in
read_page (B-011).

The release is backward compatible with v2.1.x. All new MCP tools are additive;
all new fields on existing tools are optional; the legacy kind / reason
contract on ReadPageHighValueObject continues to be emitted.

Highlights (what's actually new since v2.1.0)

Stage 3a — Knowledge UI Map + stable HVO identity

• B-010 · Knowledge UI Map (data side) — new KnowledgeUIMapRule schema +
  compile-time validation + lookup/resolve-ui-map.ts. GitHub seed: 5 purposes
  (repo_home.open_issues_tab, repo_home.open_actions_tab,
  issues_list.new_issue_cta, issues_list.search_input,
  actions_list.filter_input). Read-only consumer wiring is intentionally
  deferred (Stage 3a item 6).
• B-011 v1 · stable HVO targetRef — read_page HVOs now carry an
  optional targetRef of shape tgt_<10-hex>, derived deterministically from
  cyrb53(pageRole | objectSubType | role | normalizedLabel | hrefPathBucket | ordinal).
  The click bridge (candidate-action.ts + interaction.ts + computer.ts)
  resolves candidateAction.targetRef = tgt_* through a new per-tab snapshot
  registry (stable-target-ref-registry.ts) and fails closed with
  unresolved_stable_target_ref if the registry has no mapping (e.g. service
  worker eviction or stale tgt_* after navigation). Legacy ref_* /
  selector paths are unchanged.
  • Caveat (1) — executable coverage: only HVOs that also carry a
    per-snapshot ref are end-to-end executable through the click bridge. The
    registry only records mappings when obj.targetRef && obj.ref are both
    present, so a targetRef on a synthetic / seed-derived HVO will surface
    for stability evidence but will fail closed on click. Broadening
    executable coverage is a v2 follow-up (Stage 3a item 6 / UI Map consumer
    cutover).
  • Caveat (2) — historyRef is not yet a strong content anchor: the
    extension layer fills historyRef = read://<host>/<pageRoleSlug>/<sha8>,
    but the native server's snapshot post-processor unconditionally overwrites
    the wire-level value to memory://snapshot/<uuid> (the SQLite snapshot
    row id). Upstream MCP clients therefore see a uuid, not a content hash.
    The B-011 stable targetRef does not depend on historyRef for its
    stability — it stays stable on its own derivation. Promoting historyRef
    to a true contentHash equivalent is its own follow-up, explicitly
    out of B-011 v1.

Stage 3b — Experience action-path replay (read side)

• B-005 — Experience schema seed (experience_action_paths +
  experience_locator_prefs).
• B-012 — Experience action-path aggregator
  (memory_sessions.aggregated_at guarded migration; idempotent re-runs).
• B-013 — experience_suggest_plan(intent, pageRole?, limit?) MCP tool;
  read-only, native-handled, no extension round-trip; rows ranked by
  success_count then net-success margin then recency. The write-side tools
  (experience_replay, experience_score_step) remain explicitly out of
  v2.2.0 and are gated on a Policy review.

Stage 3e — Memory Sidepanel polish

• B-006 — Memory tab status filter chips + search +
  "jump to last failure" button; covered by extension tests.

Stage 3f — Policy capability opt-in (v1 slice)

• B-016 v1 — TabrixCapability enum + TABRIX_POLICY_CAPABILITIES env
  parser, gated alongside the existing TABRIX_POLICY_ALLOW_P3 (no migration /
  no deprecation pressure yet). v1 ships only the api_knowledge capability;
  per-tool capability annotations and the MemoryAction.policyCapabilities
  audit field are intentionally deferred.

Stage 3g — API Knowledge capture v1

• B-017 v1 — GitHub-first, capture-only, capability-gated. New
  knowledge_api_endpoints table (idempotent migration; dedup by
  (site, endpoint_signature) with sample_count / first_seen_at /
  last_seen_at). Pure transformer covers 9 GitHub endpoint families plus an
  unclassified fallback that still respects redaction. Wired through a new
  chrome_network_capture post-processor — no MCP surface change in v1.
  • Hard PII guarantees, regression-tested at three layers (pure transformer,
    repository, post-processor): never persists raw header values, cookies,
    query values, request body values, or response body text. Only header
    names, query keys, body keys, presence flags (hasAuth /
    hasCookie), and a coarse response shape descriptor.
  • Out of v2.2.0: knowledge_call_api, JSON-Schema inference, Sidepanel
    per-site toggle, additional sites. These remain in the pool under the
    same B-017 umbrella.

Stage 3h — Context Strategy Selector (v1 minimal slice)

• B-018 v1 — tabrix_choose_context(intent, url?, pageRole?, siteId?)
  MCP tool wired into the native server with a rule-based selector and three
  shipped strategies (experience_reuse / knowledge_light /
  read_page_required). GitHub-first; siteId only honours github in v1,
  and non-GitHub URLs resolve to read_page_required. Design + scope detail
  in docs/B_018_CONTEXT_SELECTOR_V1.md.
  • Caveat: this is a v1 slice, not the full Stage 3h DoD. The full
    decision table, telemetry-driven self-learning, and multi-site coverage
    are still in pool. The v1 selector is intentionally rule-only (no
    server-side model).

Click contract V2 — verifier hook

• B-023 — chrome_click_element verified-outcome contract:
  dispatchSucceeded / observedOutcome / verification / success (derived,
  never synonymous with "the promise resolved"). Closes the false-success
  defect that v2.1.x exhibited on degraded-bridge / new-tab paths.
• B-024 — Click V2 verifier hook v1: three keys
  (github.repo_nav.issues / pull_requests / actions); fail-closed on
  unknown keys; public click response gains optional postClickState
  (beforeUrl / afterUrl / pageRoleAfter / verifierPassed /
  verifierReason).

Infrastructure guardrails

• B-007 — sidepanel JS bundle-size CI gate (25 / 40 kB).
• B-021 — sidepanel CSS bundle-size CI gate (20 / 22 kB).
• B-008 — extension testing conventions documented
  (docs/EXTENSION_TESTING_CONVENTIONS.md).
• B-009 — schema-cite rule (AGENTS.md); every Memory / Knowledge /
  Experience / shared DTO change must cite the authoritative schema.
• B-022 — backlog cleanup (drop legacy Rule N numbering references).

Acceptance Evidence

The product-level claim for v2.2.0 sits on two layers; this section is
deliberately explicit about which evidence is real-browser and which is
source-level / test-level so upstream readers can calibrate trust.

Real-browser acceptance (private, anchored)

• B-011 golden path — T5-F-GH-STABLE-TARGETREF-ROUNDTRIP in the
  maintainer-held tabrix-private-tests repo, GitHub repo home (no login
  state). Two consecutive read_page calls produce the same tgt_<10-hex>
  for the same logical HVO; a click using only candidateAction.targetRef
  (no per-snapshot ref) lands real navigation.
  • Private-tests anchor commit:
    e5e6b33
    on top of the v2.1.0 anchor (8f47ea7).
  • Evidence sample (per-machine, not committed to the public repo):
    artifacts/t5-fullchain-real-browser-acceptance/.../evidence/t5-f-gh-stable-targetref-roundtrip.json,
    targetRefStable: true, clickResult.ok: true, urlChanged: true.
• The v2.1.0 baseline (15 / 15 scenarios passed, productLevelReady: true)
  on T5 Groups A/B/C/D/E continues to apply for the carry-over surface; no
  v2.1.0 surface was regressed.

Source-level / test-level evidence (this repo's CI gates)

• pnpm --filter @tabrix/extension test — extension test suite
  (≥ 360 tests, including the new
  tests/stable-target-ref.test.ts,
  tests/stable-target-ref-registry.test.ts, expanded
  tests/candidate-action-bridge.test.ts, expanded
  tests/read-page-task-protocol.test.ts).
• pnpm -C app/native-server test:ci — native server suite covering the
  Experience aggregator, experience_suggest_plan, API knowledge capture
  three-layer PII tests, the new context selector, and the Memory read API.
• pnpm -r typecheck clean across all four workspaces.
• pnpm run docs:check clean.
• pnpm run i18n:check clean.
• pnpm run audit clean (in-repo OSV production dependency gate).
• pnpm run release:check clean.

What v2.2.0 does not claim:

• No automated quantification of upstream token savings from B-011 / B-018.
  The structural evidence (stable identity exists, downstream can reuse it
  without re-dumping the HVO list) is real; an end-to-end token-saving
  benchmark is not part of v2.2.0.
• No real-browser acceptance for B-018's selector outcomes — the selector
  itself is exercised through unit/integration tests only in v2.2.0.
• No real-browser acceptance for the Experience aggregator end-to-end loop —
  B-012 / B-013 are validated via native-server unit tests only; a
  multi-session real-browser replay scenario is a v2.3.0 candidate.
• No real-browser acceptance for B-017 capture path — the three-layer PII
  guarantees are validated through unit fixtures only in v2.2.0;...

Tabrix v2.1.0 Release Notes

Release date: 2026-04-20

Summary

v2.1.0 is the first minor release on the 2.x line. It delivers the T5.4
high-value object pipeline in read_page, promoting the real Chrome ->
read -> understand -> act loop from T5.0 task-mode awareness all the way
to T5.4 four-layer object extraction.

The release is backward compatible with v2.0.x. All new fields on
ReadPageHighValueObject are additive and optional; the legacy kind /
reason contract continues to be emitted and is still usable by older
MCP clients.

Highlights

T5.4: Four-layer high-value object pipeline

read_page now returns a structured high-value object layer alongside
the existing candidate list. Each object carries:

• objectType (one of nav_entry / record / control / status_item
  / entry / ...)
• region (coarse page region tag)
• importance (0..1 confidence-weighted score)
• reasons (multi-step explainability; why this object was promoted)
• actions (legacy kind / reason still emitted for compatibility)
• sourceKind (whether the object came from a DOM ref, a candidate
  action, or a page-role seed)

The pipeline is split into neutral core logic plus a GitHub family
adapter, so adding additional family adapters in the future does not
require touching the core scoring path. See
app/chrome-extension/entrypoints/background/tools/browser/read-page-high-value-objects-core.ts.

Neutral noise downranking

Commit hashes, timing durations, commitlint-style prefixes, overly
long labels, and site-shell wording (watch/star/pin, "Search or jump
to...", "Open Copilot...", "Skip to content", footer links on GitHub)
are now consistently downranked so the first object on a page is the
one an assistant would actually want to act on.

Continued: recovery & diagnostics

Everything shipped in v2.0.8 / v2.0.9 — browser executable detection,
unified status / doctor / report / bridge-recovery semantics, real
browser auto-recovery on bridge-degraded paths — still applies in
v2.1.0. No behavior regressions in any of those subsystems.

Acceptance Evidence

This release was verified end-to-end by the maintainer-held
tabrix-private-tests full-chain real-browser acceptance suite.

• Suite: T5_FULLCHAIN_REAL_BROWSER_ACCEPTANCE (15 scenarios across
  Groups A / B / C / D / E)
• Private-tests commit:
  8f47ea73a54c9d8fd449707f20e34dd26f7055cb
• Groups:
  • A (environment health): runtime-consistency with 4-state classification
  • B (legacy core action chain): real chrome_navigate +
    chrome_read_page + chrome_click_element + chrome_screenshot
    against a public GitHub repo
  • C (T5 understanding chain): bridged through pnpm t4:github-baseline
  • D (compatibility chain): T5 highValueObjects.ref clicked via the
    legacy chrome_click_element tool; legacy + T5.4 fields coexist
    on the same object
  • E (recovery chain): tabrix doctor --json idempotency + post-doctor
    understanding replay
• Result: 15 / 15 scenarios passed, productLevelReady: true
• Verdicts: legacyCorePassed: true, t5UnderstandingPassed: true,
  compatibilityPassed: true, recoveryCompatibilityPassed: true

The acceptance suite and its evidence are intentionally kept outside
this public repository (see AGENTS.md §17). The commit SHA above is
the stable anchor.

Lockstep Version Move

All first-party packages move to 2.1.0:

• tabrix-monorepo
• @tabrix/tabrix
• @tabrix/extension
• @tabrix/shared
• @tabrix/wasm-simd

@tabrix/tabrix now depends on @tabrix/shared@^2.1.0.
@tabrix/extension keeps its workspace:* reference.

Compatibility Notes

• Existing MCP clients that consume only kind and reason (singular)
  continue to work unchanged.
• Assistants that want structured object metadata should prefer the new
  fields (objectType, importance, reasons, sourceKind) over the
  legacy singular reason text when both are present.
• No changes to CLI / transport / diagnostics public surface.

Upgrade

• npm: npm install -g @tabrix/tabrix@2.1.0
• Extension: reload the unpacked extension from dist/ after upgrading.

Known Non-Goals In This Release

• Real fault-injection recovery (Group E uses a non-destructive
  idempotency check instead). Tracked in the private-tests v3
  backlog; behind an opt-in --enable-fault-injection flag when it
  lands.
• Nightly CI wiring of the T5 acceptance suite.
• Extension of the acceptance model to logged-in platforms (Douyin /
  BOSS / private consoles) — those stay in their own private suites
  and are not part of this public release surface.

Tabrix v2.0.9 Release Notes

Release date: 2026-04-18

Context

v2.0.9 turns browser recovery from "state visible + manual advice" into a formal product loop: when a real browser automation request arrives and the bridge is not ready, Tabrix now attempts recovery and continues the original request when possible.

Added

• Unified bridge recovery guidance:
  • one shared recovery guidance source now powers MCP tool failure payloads, status, doctor, and report.
  • /status bridge snapshots now include guidance.summary, guidance.hint, and guidance.nextAction.
• Recovery-special smoke path:
  • tabrix smoke --bridge-recovery injects a bridge failure and validates that a real browser request either auto-recovers and succeeds or returns one single next action.

Improved

• Browser automation recovery loop:
  • browser-tool requests now pass through one recovery gate before execution.
  • bridge-degraded, bridge-broken, and command-channel-not-ready states now converge on one retry/recovery path.
  • successful recovery now continues the original request instead of stopping after diagnostics.
• Diagnostics consistency:
  • status, doctor, and report now describe the same recovery truth with one action-oriented recommendation.
  • recovery failures now avoid multi-step manual suggestion lists and instead return one key next action.
• T3/T4 execution quality closure:
  • T3.1/T3.2 structured read_page contract is now used as the stable base for execution-oriented snapshots.
  • T4 public GitHub baseline remains runnable after Douyin private-asset split.
  • workflow run detail baseline path now prefers explicit run URL navigation and dedicated tab resolution, restoring workflow_run_detail baseline stability.

Fixed

• Fixed product gap where recovery stopped at advice text even though runtime state was recoverable.
• Fixed inconsistent wording across status, doctor, and report for the same bridge fault.
• Fixed smoke acceptance gap by adding a formal recovery-specific validation path.

Validation

• pnpm --dir app/chrome-extension exec vitest run tests/native-host.test.ts
• pnpm --dir app/native-server exec jest src/mcp/bridge-recovery.test.ts src/scripts/doctor-bridge-state.test.ts src/scripts/status.test.ts src/server/bridge-recovery-routes.test.ts --runInBand
• node app/native-server/dist/cli.js stdio-smoke --json
• node app/native-server/dist/cli.js smoke --json --protocol-only --url http://192.168.131.217:12306/mcp --auth-token <token>
• node app/native-server/dist/cli.js smoke --json --bridge-recovery
• node app/native-server/dist/cli.js doctor --json
• node app/native-server/dist/cli.js report --json
• node --test scripts/t4-github-baseline.test.mjs
• pnpm run t4:github-baseline -- --owner guodaxia103 --repo tabrix --out-dir .tmp/t4-github-baseline --non-strict (4/4)
• pnpm run t4:post-submit -- --owner guodaxia103 --repo tabrix --commit 2ad1bbf --non-strict

Tabrix v2.0.8 Release Notes

Release date: 2026-04-15

Context

v2.0.8 focuses on browser bridge execution reliability, Windows startup experience, browser-readiness diagnostics, and release hardening before the next public rollout.

Added

• Browser bridge execution channel hardening:
  • daemon status now reports richer bridge state snapshots, including command-channel readiness.
  • Claude acceptance assets and current acceptance matrix were formalized for release tracking.
• Browser readiness persistence:
  • setup, register, and doctor flows now resolve and persist the preferred browser executable path for future launches.

Improved

• Browser automation recovery flow:
  • stronger recovery diagnostics for browser-not-running, bridge-degraded, and command-channel readiness states.
  • safer browser-tool guidance after navigation and tab switching to reduce premature execution on unsettled pages.
• Windows launch behavior:
  • browser auto-start now prefers direct executable launch instead of cmd /c start, reducing visible black-console flashes.
• Browser tool UX:
  • non-web tabs (chrome://, chrome-extension://, similar internal pages) now return structured guidance instead of noisy injection failures.

Fixed

• Stabilized Claude real-session dialog handling:
  • prompt dialog handling now succeeds without leaving blocking desktop popups behind.
  • acceptance cleanup remains responsible for removing temporary tabs and local smoke listeners.
• Fixed CI/platform mismatch in browser-config tests:
  • browser platform detection now uses one consistent platform source, preventing Windows-path tests from failing on GitHub Actions runners.
• Fixed startup/runtime noise:
  • duplicate context-menu runtime errors are consumed instead of polluting extension error pages.
  • CSP-blocked data: image fetches were replaced by direct local decoding.

Validation

• pnpm run typecheck
• pnpm run test:core
• RELEASE_TAG=v2.0.8 pnpm run release:check
• powershell -ExecutionPolicy Bypass -File scripts\\run-claude-acceptance.ps1 -Profile full

Tabrix v2.0.7 Release Notes

Release date: 2026-04-12

Context

v2.0.7 focuses on release pipeline stability and package version consistency.

Added

• Workspace lockstep guardrails in release readiness checks:
  • Enforces aligned versions across tabrix-monorepo, @tabrix/tabrix, @tabrix/extension, @tabrix/shared, and @tabrix/wasm-simd.
  • Verifies native-server dependency pinning for @tabrix/shared matches expected release range.

Improved

• GitHub Actions runtime compatibility:
  • Upgraded workflow actions to Node 24-compatible stable majors (actions/checkout@v5, actions/setup-node@v5, pnpm/action-setup@v5).
• npm release resilience:
  • Hardened shared-package visibility checks with token-aware lookup and longer retry window.
  • Avoids false-negative publish failures when registry visibility propagation is delayed.

Changed

• Lockstep package versions moved to 2.0.7:
  • tabrix-monorepo
  • @tabrix/tabrix
  • @tabrix/extension
  • @tabrix/shared
  • @tabrix/wasm-simd
• @tabrix/tabrix dependency updated to @tabrix/shared@^2.0.7.

Validation

• RELEASE_TAG=v2.0.7 pnpm run release:check