refactor(core): better error handling & Backblaze CORS fix

AGENTS.md

@@ -56,7 +56,7 @@ This is the monorepo for an extensible Obsidian syncing plugin to sync vault fil
 - When any function or class needs to use `Context` as argument, prefer structural typing instead of direct `Context`.
 - Excluding main plugin, shared utils and documentation site, all packages are Sync Engine modules, they use the SDK and follow unified module structure.
 - `null` forbidden, use `undefined` consistently.
-- Lint warnings must be cleared, except time-bounded ones (TODO with date, deprecated API for compat)
+- Lint warnings in scope must be addressed, except conditional ones (TODO with date, upstream issue)
 - SDK types (`**/*.d.ts` in `packages/plugin/dist/`) are committed to satisfy Obsidian automated linting. Never edit, delete, restore, clean, or otherwise alter these files, even when builds or checks create uncommitted changes. Leave their existing worktree state unchanged.
 
 ## Documentation

CHANGELOG.md

@@ -2,6 +2,25 @@
 
 All notable changes to this project will be documented in this file.
 
+## Sync Engine v3.2.0 - 2026-09-28
+
+### Core
+
+- Unified sync strategy, inclusion rules, and exclusion rules into an ordered lost of sync strategies, providing granular control of syncing decisions.
+- Supported brace expansion syntax in sync strategy Glob rules.
+- Replaced remote migration wizard with a confirmation pop-up reminding manual migration since the set of files to upload can no longer be reliably determined on a single device.
+- Fixed local operation failure caused by moving a file onto an existing file.
+- Improved internal error handling and logging.
+- Fixed minor UI issues on mobile.
+
+### S3 Module
+
+- Fixed Backblaze multipart upload initiation failure caused by server CORS filtering.
+
+### Google Drive Module
+
+- Fixed sync creates multiple same-name files under the same folder when moving a file onto an existing path.
+
 ## Sync Engine v3.1.9 - 2026-09-21
 
 ### Core

README.md

@@ -54,9 +54,9 @@ Sync Engine is a vault syncing plugin to **synchronize vault files in multiple d
 **Features**:
 
 - [Client-side encryption](https://sync.consensia.cc/deep-dive/modules/encryption)
-- Bidirectional / mirror remote / mirror local syncing.
+- Granular sync strategy configuration (bidirectional / mirror remote / mirror local / don't sync) using Glob rules.
 - Startup / periodic / save-on-change syncing.
-- Conflict resolution strategies ([smart merge](https://sync.consensia.cc/deep-dive/modules/smart-merge) / keep both / latest survive / keep remote / keep local / skip).
+- Conflict resolve strategies ([smart merge](https://sync.consensia.cc/deep-dive/modules/smart-merge) / keep both / latest survive / keep remote / keep local / skip).
 - Rate / memory control options.
 - Custom headers.
 
@@ -115,7 +115,7 @@ Below is a list of planned features and improvements, the faster this plugin is
 
 - [x] v3.0: Rewrite entirely, dynamic module loading, module store, asymmetric storage, and rebrand
 - [x] v3.1: Migrate settings to Obsidian v1.13 API
-- [ ] v3.2: Granular sync strategy selection / exclusion inclusion rule refactor based on ordered glob match rules.
+- [x] v3.2: Granular sync strategy selection / exclusion inclusion rule refactor based on ordered glob match rules.
 
 Sync Engine has a [wishlist of features](https://github.com/hesprs/sync-engine/issues/214), you can react with **thumbs up** 👍 on feature comments you would like to have. And the features with more votes will have higher priority.
 

README.zh.md

@@ -54,7 +54,7 @@ Sync Engine 是一款用于**多设备间同步 Vault 笔记文件**的插件，
 **核心特性**：
 
 - [客户端端到端加密](https://sync.consensia.cc/deep-dive/modules/encryption)
-- 支持双向同步、镜像远端、镜像本地等多种模式。
+- 使用 Glob 规则进行精细化的同步策略配置（双向同步 / 镜像远程 / 镜像本地 / 不同步）。
 - 支持启动时同步、定时同步以及变更自动保存时同步。
 - 灵活的冲突解决方案（[智能合并](https://sync.consensia.cc/deep-dive/modules/smart-merge)、保留两者、保留最新版、覆盖为远端、覆盖为本地、直接跳过）。
 - 速率与内存占用调优选项。
@@ -115,7 +115,7 @@ Sync Engine 正好填补了这一空白：让您自由选择存储服务；插
 
 - [x] 3.0 版本：全盘重构、支持动态模块加载、上线模块商店、引入非对称存储，并完成品牌全新升级
 - [x] 3.1 版本：设置项全面适配 Obsidian 1.13 版本新 API
-- [ ] 3.2 版本：精细化同步策略选择，基于排序 Glob 匹配规则重构文件包含与排除机制
+- [x] 3.2 版本：精细化同步策略选择，基于排序 Glob 匹配规则重构文件包含与排除机制
 
 Sync Engine 设立了[功能需求清单](https://github.com/hesprs/sync-engine/issues/214)，欢迎为您期待的特性点赞 👍 投票。得票越高的功能将获得更高的开发优先级。
 

docs/.vitepress/config.ts

@@ -71,6 +71,7 @@ const localeConfig = configGenerator<ThemeConfig>((t) => {
 							items: [
 								{ link: `${usage}/settings`, text: t('settings') },
 								{ link: `${usage}/modules`, text: t('modules') },
+								{ link: `${usage}/remote-migration`, text: t('remoteMigration') },
 							],
 							text: t('usage'),
 						},

docs/.vitepress/i18n.ts

@@ -34,6 +34,7 @@ const en = {
 	nativeName: 'English',
 	permissions: 'Permissions',
 	registration: 'Registration',
+	remoteMigration: 'Remote Migration',
 	request: 'Request',
 	requestMiddleware: 'RequestMiddleware',
 	s3: 'S3',

docs/src/pages/en/deep-dive/architecture.md

@@ -58,14 +58,14 @@ SynthKernel also supplies reactive primitives used across module boundaries. `Re
 3. **`Storage`** owns the Uni-KV memory database and IndexedDB database. It exposes persistent record stores, module metadata storage, and per-local/remote-pair namespaces.
 4. **`Extensibility`** discovers module metadata, validates sources and integrity, loads enabled JavaScript modules, persists metadata, and manages enable, disable, update, and unload operations. Its security and trust rules are documented in the [Extensibility Contract](./extensibility).
 5. **`Setting`** owns the native Obsidian settings tab, nested setting-definition tree, module setting registration, labels, and settings-page refreshes.
-6. **`Registrar`** is the capability and registry layer. It creates local and remote file systems, applies request middleware and wrappers, selects optimizers, deciders, and conflict resolvers, reduces trigger entries, and exposes registration functions to modules.
+6. **`Registrar`** is the capability and registry layer. It creates local and remote file systems, applies request middleware and wrappers, selects optimizers and conflict resolvers, buckets stats by strategy and dispatches them to deciders, reduces trigger entries, and exposes registration functions to modules.
 7. **`Sync`** executes one sync run: initialize infrastructure, traverse both sides, filter stats, create and transform tasks, request confirmations, execute tasks, and publish lifecycle events. See [Core Sync Routine](./sync).
 8. **`Observability`** converts events into user-visible status, progress, notices, commands, ribbon controls, and exported logs. Its reactive values are consumed by the progress modal.
 9. **`Scheduler`** turns manual, startup, scheduled, realtime, and vault-change triggers into queued sync requests. It waits for idle state, batches pending requests, reduces the batch's triggers to the highest-priority registered entry, and resolves every request in a batch with the same result.
 10. **`ProgressModal`** handles progress display, task confirmation, deletion confirmation, cancellation, and failed-task details. SynthKernel `computed()` values and `hook()` cleanup keep modal state scoped to the modal lifecycle.
 11. **`Bootstrap`** installs built-in sync capabilities through `Registrar` and supplies core translations. Settings are registered by `Setting`, which starts before `Bootstrap` completes the plugin lifecycle.
 
-The dependency direction is intentionally visible in the constructors. For example, `Sync` receives `initializeSync`, `getDecider`, and `getConflictResolver`; it does not know which backend, wrapper, or middleware supplied them. `Bootstrap` assembles those policies without changing the sync algorithm.
+The dependency direction is intentionally visible in the constructors. For example, `Sync` receives `initializeSync`, `decideTasks`, and `getConflictResolver`; it does not know which backend, wrapper, or middleware supplied them. `Bootstrap` assembles those policies without changing the sync algorithm.
 
 ## Extensibility Framework
 
@@ -86,7 +86,7 @@ Examples include `registerRemoteFs`, `registerRemoteFsWrapper`, `registerRemoteR
 
 Registration entries are consumed according to their role:
 
-- **Factories and ID maps:** the selected remote backend, decider, and conflict resolver are looked up by the ID in settings. Missing IDs fail with an explicit error.
+- **Factories and ID maps:** the selected remote backend and conflict resolver are looked up by the ID in settings, while deciders are looked up by strategy name during planning. Missing IDs fail with an explicit error.
 - **Wrappers:** request and file-system wrappers are grouped by numeric priority and applied in ascending priority order. Within one priority, the first wrapper that returns a replacement wins; returning `undefined` declines the current value.
 - **First-match pipelines:** optimizers are also priority ordered. The first entry that returns a result supplies the implementation for that operation.
 - **Triggers:** trigger entries are keyed by trigger name. A flushed sync batch is reduced to its highest-priority entry, whose options customize the run.

docs/src/pages/en/deep-dive/modules/encryption.md

@@ -77,7 +77,7 @@ Encryption implementation in this module welcomes volunteer auditing.
 
 ## Enabling and Disabling
 
-The function is toggled via the **Encryption** setting. The password is stored in Obsidian's keychain. When a record store exists, changing the toggle opens a migration confirmation, which is similar to [the migration of asymmetric storage](../../usage/settings#asymmetric-storage).
+The function is toggled via the **Encryption** setting. The password is stored in Obsidian's keychain. When a record store exists, changing the toggle opens a confirmation prompt, similar to [asymmetric storage](../../usage/settings#asymmetric-storage); confirm only after your remote data has been migrated as described in the [Remote Migration guide](../../usage/remote-migration).
 
 ## Sync Routine
 

docs/src/pages/en/deep-dive/modules/s3.md

@@ -131,4 +131,4 @@ The final part may be smaller than 5 MiB. On failure, active part uploads finish
 
 ### Batch Deletes
 
-The S3 optimizer groups delete atoms into `DeleteObjects` requests with at most 1000 keys each. Requests contain XML and a `Content-MD5` header. The service result is handled per key: successful keys resolve, while keys reported in an S3 error result reject individually. If the whole batch request fails, each key is retried with an individual `DELETE` request and handled independently.
+The S3 optimizer replaces delete atoms with a single custom atom, whose `batchDelete()` splits the keys into `DeleteObjects` requests with at most 1000 keys each. Requests contain XML and a `Content-MD5` header. The service result is handled per key: successful keys resolve, while keys reported in an S3 error result reject individually. If the whole batch request fails, each key is retried with an individual `DELETE` request and handled independently.