Optimike Obsidian MCP 3.19.0 — FDM-dated notes unblocked and vault agent instructions

3.19 unblocks governed edits of notes that Frontmatter Date Manager dates from their real file creation time, and makes the vault's AGENTS.md files reach agents that see the vault only through MCP. See the changelog and the release notes in English and French.

• Notes dated by FDM no longer stay locked (#147): FDM 1.6.0 fills création from the file creation time, earlier than the plan; 3.18 rejected it with date_preparation_unverified. Atomic Write Bridge 0.9.2 now returns the file stat it observed before the FDM command, and the MCP checks each date by its role (text patch, frontmatter patch, note replacement, Base rows). FDM still writes every date; the MCP never writes one.
• Install Atomic Write Bridge 0.9.2 with the MCP: with an older Bridge, a plan that needs a date preparation is refused before any lock or change with date_preparation_bridge_upgrade_required (mutationMayHaveApplied: false). date_preparation_unverified now carries a closed sub-cause, preparationCheck.
• Notes already locked by 3.18 or earlier stay locked after the upgrade: follow notes locked by a date preparation (obsidian_operation_close with datePreparationPaths, dry run first).
• Vault agent instructions (AGENTS.md cascade): for every governed plan and direct write, the server reports in vaultInstructions the instruction files that apply to the paths it really writes (vault root, then each parent folder of each target) and whether this reader has read each one in its current version, proven by the SHA-256 of the content obsidian_read_note served. MCP_VAULT_INSTRUCTIONS = off (as before) / advise (default, never refuses) / enforce (refuses until the files are read; refuses apply or recover when the rules changed after the plan). MCP_VAULT_INSTRUCTIONS_MIN sets an administrative minimum, MCP_VAULT_INSTRUCTIONS_FILES the file names (Markdown only, default AGENTS.md). See vault agent instructions.
• Known limits: the server proves the agent received the instructions before writing, not that it follows them. Notes Operon writes on its own after a mutation are not checked.

Bridge change. Install MCP 3.19.0 with the Bridge bundle of this release (Atomic Write Bridge 0.9.2, Operon Bridge 0.9.7, Bases Bridge 1.2.2), after draining pending operations and date preparation fences. No setting or grant changes. To keep the previous behaviour exactly, set MCP_VAULT_INSTRUCTIONS=off.

Evidence: green CI on #149, #150 and #151; npm run test:mcp-2026:all on Windows 178/178 (two Linux-delegated gates not counted); Atomic Write Bridge check 139/139, Operon Bridge check 120/120; real end-to-end on Windows with Obsidian, Local REST API and isolated vaults: FDM fix 5/5, AGENTS.md cascade 8/8 including a folder stored in NFD; independent reviews of #149 and #150, and the Codex review on #150 (non-Markdown instruction names, fixed). Not tested: macOS, live Operon creation with a parent only.

Assets: Bridge bundle (Atomic Write Bridge 0.9.2, Operon Bridge 0.9.7, Bases Bridge 1.2.2) with manifest and SHA256SUMS, built by npm run package:bridge-bundle from the merged commit ac1bc8f (zip SHA-256 e74992eb9b666fe27cac75c450baa74718237a07e5f29a4c0f4b322db8ed06cd).

---

En français

La 3.19 débloque les modifications gouvernées des notes que Frontmatter Date Manager date avec la vraie date de création du fichier, et fait parvenir les fichiers AGENTS.md du coffre aux agents qui ne voient le coffre qu'à travers le MCP.

• Les notes datées par FDM ne restent plus verrouillées (#147) : FDM 1.6.0 remplit création avec la date de création du fichier, antérieure au plan ; la 3.18 la refusait avec date_preparation_unverified. Atomic Write Bridge 0.9.2 renvoie maintenant l'état du fichier observé juste avant la commande FDM, et le MCP vérifie chaque date selon son rôle. FDM écrit toujours les dates ; le MCP n'en écrit jamais.
• Installer Atomic Write Bridge 0.9.2 avec le MCP : avec un Bridge plus ancien, un plan qui demande une préparation de dates est refusé avant tout verrou ou changement, avec date_preparation_bridge_upgrade_required (mutationMayHaveApplied: false).
• Les notes déjà verrouillées par la 3.18 ou avant le restent après la mise à jour : suivre la procédure des notes verrouillées par une préparation de dates (obsidian_operation_close avec datePreparationPaths, d'abord en dry run).
• Instructions d'agent du coffre (cascade AGENTS.md) : pour chaque plan gouverné et chaque écriture directe, le serveur indique dans vaultInstructions les fichiers d'instructions qui s'appliquent aux chemins réellement écrits (racine du coffre, puis chaque dossier parent) et si ce lecteur les a lus dans leur version actuelle. Modes off (comme avant), advise (par défaut, ne refuse jamais) ou enforce. Voir les instructions d'agent du coffre.

Installer le MCP 3.19.0 avec le bundle des Bridges de la même release (Atomic Write Bridge 0.9.2, Operon Bridge 0.9.7, Bases Bridge 1.2.2), après avoir vidé les opérations en attente et les fences de préparation de dates. Aucun réglage ni grant ne change. Pour garder exactement l'ancien comportement : MCP_VAULT_INSTRUCTIONS=off.

Optimike Obsidian MCP 3.18.0 — Operon 4.4 and semantic search parity

3.18 makes the refusals an agent receives readable and keeps Operon task revisions stable across updates. It also brings semantic search in line with Smart Connections re-indexing. See the changelog and the release notes in English and French.

• Operon 4.4.0 (compatible-provisional): a stale expectedRevision returns revision_conflict with currentRevision, a native refusal operon_rejected, an unconfirmed elevated apply consent_required and a declined plan consent_denied, instead of a generic Bridge error. The task revision now hashes the task only: an Operon or Bridge upgrade, or an edit to a sibling task, no longer makes every revision stale. Revisions read before 3.18 are stale once: re-read, then plan again.
• Simpler task calls: operon_transition_task accepts intent (complete, cancel, reopen); operon_query_tasks accepts fieldIncludes for list membership, for example { assignees: "Claude" }. operon_status reports firstUseCapabilities, operon_get_diagnostics reports bridgeSession.
• Faster Operon Bridge 0.9.7: the task snapshot is reused while Operon's context revision is unchanged, and established sessions stay usable during a refresh, so a request right after a write no longer fails as mutation_unavailable.
• Note moves: a refused native move says why, with a reasonCode and a fixed hint; Atomic Write Bridge 0.9.1 adds move_reference_limit (more than 200 links around the source; the bound is unchanged).
• Semantic search: a note re-embedded by Smart Connections without a new import stays searchable; a note deleted in Smart Connections leaves the index; an unreadable cache is rebuilt instead of blocking search; the derived cache stores exact Float64 vectors (local measurement on 7,578 vectors: half the payload, persistence 5.45 s → 2.50 s) and rebuilds once after the upgrade. Semantic search is no longer reported unavailable right after a restart: while the cache loads it is degraded with semantic_index_loading, then ready; a stuck probe reports semantic_probe_timed_out.
• Security: follow-redirects and @hono/node-server updated (#143).

Bridge change. Install MCP 3.18.0 with the Bridge bundle of this release (Atomic Write Bridge 0.9.1, Operon Bridge 0.9.7, Bases Bridge 1.2.2), after draining pending operations. No setting or grant changes. The first start after the upgrade rebuilds the semantic cache once (several seconds on a large vault). Upgrade every MCP client of the same vault at the same time: two versions sharing one cache rebuild it in turn.

Evidence: green CI on every PR of the release; npm run test:mcp-2026:all on Windows 172/172 (semantic changes) and 171/171 (release branch), two Linux-delegated gates not counted; an independent review of #144 (unreadable cache, deleted notes, probe and test fixes applied); PRs #141, #142, #143, #144 and #146; Operon 4.4.0 smoke on the pilot vault (Bridge 0.9.4 → 0.9.7, zero pending recovery, byte-exact restore); move refusal verified live on 29 October 2026; semantic changes running in the maintainer's local runtime since late October 2026.

Assets: Bridge bundle (Atomic Write Bridge 0.9.1, Operon Bridge 0.9.7, Bases Bridge 1.2.2) with manifest and SHA256SUMS, built by npm run package:bridge-bundle from the merged commit ad55070 (zip SHA-256 c63b9125de7de6be749a9237c54c90a5abc224d4f8573b8fac6f58c55a2404f1).

---

En français

La 3.18 rend lisibles les refus renvoyés à l’agent et garde stables les révisions des tâches Operon d’une mise à jour à l’autre. Elle aligne aussi la recherche sémantique sur la réindexation de Smart Connections.

• Operon 4.4.0 (compatible-provisional) : une expectedRevision périmée renvoie revision_conflict avec currentRevision, un refus natif operon_rejected, une application élevée non confirmée consent_required et un plan refusé consent_denied, au lieu d’une erreur générique du Bridge. La révision d’une tâche ne hache plus que la tâche : une mise à jour d’Operon ou du Bridge, ou la modification d’une tâche voisine, ne périme plus toutes les révisions (les révisions lues avant cette version sont périmées une fois : relire, puis replanifier).
• Appels de tâches plus simples : operon_transition_task accepte intent (complete, cancel, reopen) et le résout vers le statut correspondant du pipeline de la tâche ; operon_query_tasks accepte fieldIncludes pour l’appartenance à une liste, par exemple { assignees: "Claude" }. operon_status indique firstUseCapabilities et operon_get_diagnostics indique bridgeSession.
• Operon Bridge 0.9.7 plus rapide : un rafraîchissement réutilise l’instantané des tâches tant que la révision de contexte d’Operon ne change pas, et garde les sessions établies utilisables pendant le rafraîchissement ; une requête juste après une écriture n’échoue plus en mutation_unavailable.
• Déplacements de notes : un déplacement natif refusé dit maintenant pourquoi, avec un reasonCode et une indication fixe. Atomic Write Bridge 0.9.1 ajoute move_reference_limit (plus de 200 liens autour de la source).
• Recherche sémantique : une note réindexée par Smart Connections sans nouvel import reste trouvable ; une note supprimée dans Smart Connections sort de l’index ; un cache illisible est reconstruit au lieu de bloquer la recherche ; le cache dérivé stocke des vecteurs exacts dans environ deux fois moins de place et se reconstruit une fois après la mise à jour ; la recherche sémantique n’est plus déclarée indisponible juste après un redémarrage : pendant le chargement du cache, elle est degraded avec semantic_index_loading, puis ready ; une sonde bloquée renvoie semantic_probe_timed_out. Voir l’encodage du cache de vecteurs (en anglais).
• Sécurité : follow-redirects et @hono/node-server mis à jour.

Installer le MCP 3.18.0 avec le bundle des Bridges de la même release (Atomic Write Bridge 0.9.1, Operon Bridge 0.9.7, Bases Bridge 1.2.2), après avoir vidé les opérations en attente. Aucun réglage ni grant ne change. Le premier démarrage après la mise à jour reconstruit une fois le cache sémantique (plusieurs secondes sur un gros coffre). Mettre à jour en même temps tous les clients MCP d’un même coffre : deux versions qui partagent un cache le reconstruisent tour à tour. Voir le changelog.

Optimike Obsidian MCP 3.17.0 — complete governed Bases and Canvas

3.16 let an agent create a Base or a Canvas in governed mode. 3.17 lets it edit them completely, still in governed mode. See the changelog and governed Base configuration (français).

• Bases: bases_config_patch_plan → _apply → _status (_recover after an uncertain outcome) edits a whole existing Base: global filters (and / or / not), formulas, property settings such as displayName, custom summaries, and views (add, delete, move, rename, type, filters, order, sort, grouping, summaries, limit, any view or plugin key). Comments and untouched values are kept, documented view keys are checked, and the result must be a valid Base. A plugin view type such as kanban needs pluginViewType: true, so a typo like tabel is refused.
• Canvas: the governed Canvas patch covers every JSON Canvas option: file nodes with a # section, link nodes, groups with label and background, node colors and fields (null removes an optional one), edge labels, colors, sides, arrows and endpoints.
• Profiles: authoring 54, operational 97, full 102 live tools; catalogue 109 names.

No Bridge change. Install MCP 3.17.0 with the Bridge bundle of this release (Atomic Write Bridge 0.9.0, Operon Bridge 0.9.3, Bases Bridge 1.2.2; same Bridge bytes as 3.16.0). Base edits use Allow atomic Base CAS in the Bases Bridge; Canvas edits use Allow atomic Canvas writes in the Atomic Write Bridge. bases_upsert_config stays a whole-file compatibility path, off by default.

Evidence: 74/74 CI checks on #140; an independent review and a Codex review (prototype-key finding fixed); a live disposable-vault cycle run twice (Base created then fully edited and read back by the Bases Bridge; Canvas file, link and group nodes, field removal and edge update).

Assets: Bridge bundle (Atomic Write Bridge 0.9.0, Operon Bridge 0.9.3, Bases Bridge 1.2.2) with manifest and SHA256SUMS.

Optimike Obsidian MCP 3.16.0 — governed Base and Canvas creation

An agent can now create a Base or a Canvas in a live vault through a governed lifecycle, as it already creates a note. Before this release, bases_create was refused by the Bases Bridge in its default configuration, and no MCP tool could create a Canvas outside headless-filesystem. See the changelog and governed Base and Canvas creation (français).

• bases_create_plan → bases_create_apply → bases_create_status create one new .base file.
• obsidian_canvas_create_plan → obsidian_canvas_create_apply → obsidian_canvas_create_status create one new .canvas file; its graph is validated, so obsidian_canvas_patch_* can edit it afterwards.
• The plan validates and seals the exact bytes; apply creates the file only if it is still absent, never overwrites it and never creates its folder; status confirms the exact bytes. Refusals carry closed reasons (create_format_invalid, file_create_target_exists, file_create_parent_missing, file_create_disabled, create_bridge_unsupported), never the content.
• Profiles: authoring 50, operational 93, full 98 live tools; catalogue 105 names.

Install MCP 3.16.0 with the Bridge bundle of this release as one pair: Atomic Write Bridge 0.9.0 (changed), Operon Bridge 0.9.3 and Bases Bridge 1.2.2 (unchanged). Drain pending operations first. Then, only where you want it, enable Allow exclusive Base creation and/or Allow exclusive Canvas creation in the Atomic Write Bridge settings; both are off by default, and the server also needs MCP_WRITE_MODE guarded or full. The other governed families still accept Atomic Write Bridge 0.8.4 or later.

Not included: editing views or filters of an existing Base; recovery or undo (an uncertain creation is observed with status and closed with obsidian_operation_close).

Evidence: 72/72 CI checks on #139; a live disposable-vault cycle (13 steps: create, verify, index, Bases query, refusals, grant off, Canvas create then patch) run with the published Bridge bytes and the merge-commit build.

Assets: Bridge bundle (Atomic Write Bridge 0.9.0, Operon Bridge 0.9.3, Bases Bridge 1.2.2) with manifest and SHA256SUMS.

Optimike Obsidian MCP 3.15.2 — Operon reads after an outage

This release corrects two limits of 3.15.1 found in review. See the changelog and audit follow-ups, section 6.

No Bridge changes: keep Atomic Write Bridge 0.8.5 and Operon Bridge 0.9.3. Install it like 3.15.1, as one pair with Atomic Write Bridge 0.8.5.

• When Obsidian or the Bridge is gone (connection refused, no HTTP answer), a read no longer waits: it answers at once from the persisted snapshot, marked stale, with the missing-mutation limitation. Retries remain for transient failures only (index settling or moving, Bridge 503), within 15 seconds including the last attempt, once per pending mutation, and they stop when the client cancels the request.
• A stale fallback reloads the persisted snapshot first, so it returns the newest committed state.

Guarantee: a read made after a receipt in the same process either sees that mutation, or is marked operon-cache / stale: true; while the mutation is still uncovered, that fallback adds a limitation stating that it misses a confirmed mutation. Across processes or after a backend restart, only the index generation protects, as in 3.15.0.

The user docs now cover 3.15 (README, OPERATIONS, installation choices, capability matrix), with tests for both fixes (#138).

This release also carries everything since 3.14.0: see 3.15.0, 3.15.1 and the changelog.

Assets: Bridge bundle (Atomic Write Bridge 0.8.5, Operon Bridge 0.9.3, Bases Bridge 1.2.2) with manifest and SHA256SUMS.

Optimike Obsidian MCP 3.15.1 — Operon latency

This release shortens Operon calls on the MCP side. Mutation receipts no longer wait for the full snapshot refresh, operon_get_task reads a single task when the snapshot is behind, and a refresh makes fewer sequential Bridge calls. See the changelog and audit follow-ups, section 6.

No Bridge changes: keep Atomic Write Bridge 0.8.5 and Operon Bridge 0.9.3. Install it like 3.15.0, as one pair with Atomic Write Bridge 0.8.5.

If the index is still settling right after a mutation (for example a second writer such as a date manager), the next read waits up to 15 seconds for it instead of returning the previous snapshot.

Guarantees kept: a receipt states only what the Bridge proved; every read declares source, stale and snapshotAt; a read made after a receipt in the same process either sees that mutation or is marked operon-cache / stale: true; when it falls back while the mutation is still uncovered it adds a limitation stating that it misses a confirmed mutation. Two known limits of 3.15.1, corrected in 3.15.2: while the Bridge stays unreachable after a mutation, every read waits about 15 seconds before that fallback; and in a narrow race a stale fallback can omit the limitation. The measured gains come from a test vault with 159 tasks and are not an SLA. About 0.7 s per Bridge call remains, spent in the Bridge's Operon session renegotiation; only a Bridge release can remove it.

This release also carries everything since 3.14.0: see 3.15.0 and the changelog.

Assets: Bridge bundle (Atomic Write Bridge 0.8.5, Operon Bridge 0.9.3, Bases Bridge 1.2.2) with manifest and SHA256SUMS.

Optimike Obsidian MCP 3.15.0 — audit follow-ups

This release adds governed note deletion, WAL maintenance, journal hygiene and corrected inline tag extraction. It also adds opt-in ChatGPT tool-result compatibility and operational diagnostics. See the changelog and audit follow-ups.

Install MCP 3.15.0 and Atomic Write Bridge 0.8.5 together; drain pending operations and preparation fences, and verify artifact hashes before switching or rolling back the pair. The Bridge setting requiring a fence for every write remains off by default.

Governed deletion is disabled by default in the Bridge, requires MCP_WRITE_MODE=full, and refuses a Bridge without the deletion capability. It uses Obsidian trash, refuses permanent deletion, and refuses incoming links unless explicitly acknowledged. See governed note deletion.

Administrative closure does not establish whether an uncertain historical effect occurred. The remote ChatGPT path and other environments require their own qualification.

Assets: Bridge bundle (Atomic Write Bridge 0.8.5, Operon Bridge 0.9.3, Bases Bridge 1.2.2) with manifest and SHA256SUMS.

Optimike Obsidian MCP 3.14.0 — FDM date preparation before sealing

Optimike Obsidian MCP 3.14.0 lets the Frontmatter Date Manager (FDM) date a note that has no création property before a protected modification plan is sealed. FDM remains the author of dates; the MCP never calculates them.

What changes

• A note without création is dated by FDM during plan, then the plan is sealed on the exact bytes read back after preparation. The requested modification itself still waits for apply.
• Templates under X/Modèles/**, the configured Templater folder and paths excluded by FDM stay undated: this workflow neither requires nor adds dates to them. FDM exclusions, their exceptions and their filter order are respected.
• Without an active date manager, preparation is refused with a clear instruction: open the note in Obsidian, save it once, then retry.
• CRLF/LF line endings normalized by Obsidian during date preparation are accepted, including mixed files, and the receipt reports the normalization. Changes to text, spaces, the number of line breaks, lone CRs or non-date properties remain conflicts; CAS keeps the exact hash of the fresh read.
• Security: follow-redirects is updated to 1.16.1 to fix credential-header exposure risks during redirects (#123).

Limits

• Qualified with FDM 1.6.0 only; other date managers are not qualified.
• Preparation may date the note during plan, before apply. If an already dispatched FDM command completes after a timeout, reread the note before retrying.
• Verification describes the observed state; it does not guarantee against a later independent modification.

Validation

• An isolated Obsidian run (Obsidian 1.13.7, FDM 1.6.0), documented in PR #124, covered FDM dating, reported normalization, refusal of a stale plan, committed/verified settlement, protected dates, single-effect replay, and templates/excluded paths still undated after 38 seconds. The Atomic Write Bridge main.js rebuilt from the published commit is byte-identical to the binary used in that run.
• Linux/Windows CI passed 62/62 on PR #125 and 46/46 on the merge commit. The full local suite passed 149/149 groups on Windows on the release head, whose tree is identical to the published commit.

Bridges

Atomic Write Bridge 0.8.2 ships with this release: install MCP 3.14.0 and Atomic Write Bridge 0.8.2 together. Bases Bridge 1.2.2 and Operon Bridge 0.9.3 are unchanged; their files and the installer are byte-identical to the 3.13.0 bundle. The bundle was rebuilt from the clean published commit. Verify the archive against SHA256SUMS and its manifest before installation.

Full changelog · Release notes (EN) · Notes de version (FR) · Text patch contract · Bundle upgrade and rollback

Published source: 0a72f58.

Optimike Obsidian MCP 3.13.0 — built-in model semantic search

Optimike Obsidian MCP 3.13.0 restores semantic search for vaults indexed with the Smart Connections built-in model (provider_key: transformers, BGE Micro by default). Since 3.0 these indexes were readable but could not be queried by agents.

What changes

• A local query embedder uses @huggingface/transformers, the library Smart Connections itself ships. Query pooling, normalisation, prefix and revision follow the plugin's profile for each of its six built-in models; an unknown built-in model is refused rather than queried with a guessed profile.
• The package is an optional peer: install it next to the MCP with npm install @huggingface/transformers. It adds about 470 MB (ONNX Runtime) and is never installed by default; Ollama and OpenAI-compatible setups do not need it. Without it, the capability doctor reports the embedder as unavailable and names the package.
• The model (about 66 MB for BGE Micro) is downloaded from Hugging Face once, during the background startup prewarm, then runs locally on CPU. Diagnostics never load it.
• The former @xenova/transformers dependency stays removed: it is unmaintained and its ONNX/protobuf chain fails npm audit (1 critical, 4 high). @huggingface/transformers 4.3.1 reports no known vulnerability.

Validation

• On a vault indexed by Smart Connections 4.7.2 with BGE Micro, 10 French queries compared with the plugin's own lookup: same first result 10/10, same top 3 30/30, maximum score difference 0.0000 in fp32. q8 reordered the top 3 (20/30), so fp32 is pinned. scripts/compare-transformers-query-ranking.mjs repeats this check on another vault.
• Affected contract tests pass with and without the optional package; Linux/Windows CI passed 62/62 on PR #120 and PR #121.

Bridges

Unchanged: Atomic Write Bridge 0.8.1, Bases Bridge 1.2.2, Operon Bridge 0.9.3. The bundle was rebuilt from the clean published commit; all 8 Bridge and installer artifact hashes are identical to the qualified 3.12.0 artifacts, so the 3.12.0 Pilot 2 evidence is reused. Verify the archive against SHA256SUMS and its manifest before installation.

Full changelog · Embedders

Published source: 8696687.

Optimike Obsidian MCP 3.12.0 — governed performance

Optimike Obsidian MCP 3.12.0 makes governed writes practical as the default workflow: deferred replies after CAS, compact receipts, combined body/frontmatter intentions and the operational catalog. Final success still requires committed / verified.

Measured local gains

Path	Before	After, median	Scope
Combined edit, full certification	37.71 s	1.52 s	After n=5, 1.23–1.80 s
Blocking verified apply	37.53 s	1.54 s	Before n=1, after n=3
Existing Markdown Base row apply	38.00 s	1.73 s	Before n=1, after n=3
Forced Operon refresh	6.74 s	5.03 s	n=3 per campaign
Terminal receipt JSON	4,217 bytes	1,065 bytes	Three combined statuses; about 75% fewer bytes

The certification gains require the optional Frontmatter Date Manager (FDM) completion add-on, qualified for one audited FDM 1.6.0 build. It signals when FDM has completed its own automatic date processing; the MCP still verifies final bytes, rejects concurrent drift and preserves replay safety. Without a qualified signal, the conservative settlement window remains. These successive small local campaigns are not an SLA or a general performance guarantee.

Installation choices

The optional FDM installer is opt-in and exact-build fenced, with an external backup, a durable receipt and guarded rollback. Close the target Obsidian vault before applying. MCP startup never patches FDM automatically. See installation and rollback.

operational prioritizes governed paths; full preserves explicit compatibility. A dedicated read-only obsidian_get_frontmatter reads one key. Shared-identity HTTP quota tuning remains installation-specific; it does not isolate clients or change the default quota.

Local REST API 5.4.0 was exercised for the documented reads and governed writes, including its configuration-file protections. This does not certify every MCP tool or plugin. Plain Markdown reads avoid unrequested statistics work, independent Operon reads overlap, and expired capability probes remain negative rather than being presented as available.

Production dependencies were updated to MCP SDK 2.3.1, Axios 1.20.0 and source-map-js 1.2.2; the production audit reports zero vulnerabilities.

Bridges and validation

The attached bundle contains Atomic Write Bridge 0.8.1, Bases Bridge 1.2.2 and Operon Bridge 0.9.3. Verify the archive against SHA256SUMS and its manifest before installation. The FDM add-on is a separate optional integration, not an upstream FDM release or part of automatic bridge installation.

Affected contracts, real Pilot 2 install/restart/rollback, SDK read diagnostics, governed edits and concurrent-conflict refusal were exercised. The synthetic note was restored byte-for-byte and deleted. The optional FDM install/rollback also restored the original plugin exactly and left settings unchanged. Linux/Windows CI qualifies the published candidate; native MCP 2026 Skills on an external host remain a separate qualification.

Full changelog · Benchmark conditions · PR #118

Published source: e74581b, with a tree identical to candidate 40bb459 (76/76 CI checks passed). The release manifest and checksums were rebuilt from the clean published commit; qualified Bridge artifact hashes are unchanged.