release: 发布 Database 0.1.2 预览版

.github/workflows/release.yml

@@ -3,6 +3,8 @@
 # community package without a Lithe signature: Lithe Store lists the
 # release's archive by its SHA-256, and its release tracker picks up later
 # versions on its own.
+# Tags listed in PRERELEASE_TAGS are published as pre-releases, which the
+# tracker skips. docs/releases/<tag>.md, when present, is the release notes.
 name: Release
 
 on:
@@ -17,6 +19,13 @@ concurrency:
   group: release
   cancel-in-progress: false
 
+env:
+  # v0.1.2 needs a host offering litheLogging 1, which stable Lithe 0.6.7
+  # lacks. Space-separated tags.
+  PRERELEASE_TAGS: v0.1.2
+  # Exact preview commit containing the litheLogging 1 host API (1lck/Lithe-IDEA#1699).
+  CORE_REF: 4dd3165912a7ef4ccfd7240890a33b63751c9b3e
+
 jobs:
   release:
     name: Release ${{ github.ref_name }}
@@ -43,7 +52,7 @@ jobs:
       - name: Build the package
         run: node scripts/package.mjs
       - name: Run the backend through Rust Core
-        run: node scripts/e2e.mjs --source https://github.com/1lck/Lithe-IDEA.git --ref preview
+        run: node scripts/e2e.mjs --source https://github.com/1lck/Lithe-IDEA.git --ref "$CORE_REF"
       - name: Verify the archive users download
         run: |
           id=$(node -p "require('./plugin.json').id")
@@ -58,8 +67,20 @@ jobs:
           GH_TOKEN: ${{ github.token }}
         run: |
           archive=$(ls dist/*-darwin.zip)
+          notes="$RUNNER_TEMP/notes.md"
+          if [[ -s "docs/releases/$GITHUB_REF_NAME.md" ]]; then
+            cp "docs/releases/$GITHUB_REF_NAME.md" "$notes"
+          else
+            echo "Lithe database plugin $GITHUB_REF_NAME for macOS (Apple silicon and Intel)." > "$notes"
+          fi
+          printf '\nSHA-256: %s\n' "$(cat "$archive.sha256")" >> "$notes"
+          release_flags=()
+          for tag in $PRERELEASE_TAGS; do
+            if [[ "$tag" == "$GITHUB_REF_NAME" ]]; then release_flags+=(--prerelease); fi
+          done
           # Published assets are never replaced: Lithe Store pins their SHA-256.
           gh release create "$GITHUB_REF_NAME" "$archive" "$archive.sha256" \
             --verify-tag \
             --title "Database $GITHUB_REF_NAME" \
-            --notes "Lithe database plugin $GITHUB_REF_NAME for macOS (Apple silicon and Intel). SHA-256: $(cat "$archive.sha256")"
+            --notes-file "$notes" \
+            "${release_flags[@]}"

README.md

@@ -17,6 +17,14 @@ moves that data only into a copy installed from Lithe Store whose listing
 names this repository; a copy installed from disk or another source gets
 none of it.
 
+Version 0.1.2 is a pre-release. It needs a Lithe preview build whose host
+offers structured plugin diagnostics (`litheLogging: 1`); stable Lithe 0.6.7
+installs it but cannot start its backend, so keep 0.1.1 from Lithe Store there.
+Lithe Store's release tracker skips pre-releases, so 0.1.2 is installed from
+[Releases](https://github.com/Lithe-IDEA/lithe-plugin-database/releases)
+with **Install Plugin from Disk…**. Such a copy does not receive the former
+built-in module's data; the move waits until a copy from Lithe Store runs.
+
 ## How it is built
 
 The plugin uses [plugin contract v1](https://github.com/Lithe-IDEA/lithe-plugin-docs/blob/main/contract/v1/README.md)
@@ -104,7 +112,9 @@ otherwise.
    ruleset lets only organization admins create `v*` tags).
 3. The release workflow tests, builds the universal package, runs the
    end-to-end check, verifies the archive, and publishes a GitHub release
-   with `database-<version>-darwin.zip` and its SHA-256.
+   with `database-<version>-darwin.zip` and its SHA-256. Tags listed in
+   `PRERELEASE_TAGS` in `release.yml` are published as pre-releases, and
+   `docs/releases/<tag>.md`, when present, becomes the release notes.
 4. The first release is listed in Lithe Store with a pull request to
    `lithe-plugin-index.json`. After that, Lithe Store's release tracker
    opens the pull request for each new version; a maintainer reviews it
@@ -138,5 +148,5 @@ stdout 保持协议帧专用；日志不写插件包或 app bundle，不影响
 
 新的日志端到端验证要求 Core 已包含 `litheLogging` v1；`scripts/e2e.mjs` 必须显式传入
 `--source` 和 `--ref`，不再默认运行旧的 `e2e/lithe-core.json` 基线。CI 明确选择主仓
-`preview`，需要先合并宿主日志 API；跨仓发布时再把验证引用固定到合并后的精确提交。
+`preview`；Release 工作流把验证引用固定到包含宿主日志 API 的精确 preview 提交（`CORE_REF`）。
 宿主改动未合并时这项检查会真实失败，不跳过，也不把旧协议运行当作新 API 验收。

docs/releases/v0.1.2.md

@@ -0,0 +1,45 @@
+## 中文
+
+Lithe Database 0.1.2（macOS，Apple silicon / Intel 通用）接入 Lithe 的结构化插件诊断（`litheLogging` 1）。这是预发布版本：需要提供 `litheLogging` 1 的 Lithe preview 开发版，稳定版 Lithe 0.6.7 能安装但无法启动后端，请在稳定版上继续使用 Lithe Store 中的 0.1.1。
+
+### 改进
+
+- 后端改用官方 Rust SDK 的结构化日志，诊断写入 Lithe 日志窗口中本次会话的 `plugins/io.github.lithe-idea.database/host` 通道。
+- 每个后端函数由 SDK 记录唯一的成功或失败终态，带函数 ID、耗时和稳定分类；取消不算失败。
+- 工作区加载、历史读写和 DBX 预览的成功不再记 INFO；`database.call` 中元数据、分页浏览和探测类调用只抑制成功记录，显式查询和写入仍记 INFO，所有失败照常记 ERROR。
+- 查询结果超过传输上限被裁剪时，每次后端运行只记一次 WARN `result_size_limited`。
+- 诊断不含 SQL、连接串、服务器地址、用户名、密码、返回行、配置内容或文件路径；后端启动失败不再向 stderr 打印。
+- 官方 Rust SDK 改为仓库内的 vendor 副本，CI 与打包按逐文件 SHA-256 校验。
+
+### 安装与升级
+
+- 预发布版本会被 Lithe Store 自动追踪跳过，暂不收录 Store。下载本版本 ZIP，在「设置 → 插件」的 ⚙ 菜单中选择「从磁盘安装插件…」导入。
+- 从磁盘安装的副本不会接收 Lithe 旧内置数据库模块的连接、文件夹、SQL 历史和密码；这次迁移会保留到以后运行从 Lithe Store 安装的副本时再进行。已经在 0.1.1 完成迁移的用户不受影响。
+- 权限声明与 0.1.1 相同。
+- Release 工作流用 Lithe preview `4dd3165` 的 Core 运行端到端检查，并断言每次调用恰好产生一条日志终态；完整界面交互仍待目标 Lithe 宿主验收。
+
+[查看完整变更](https://github.com/Lithe-IDEA/lithe-plugin-database/compare/v0.1.1...v0.1.2)
+
+---
+
+## English
+
+Lithe Database 0.1.2 for macOS (universal Apple silicon / Intel) adopts Lithe's structured plugin diagnostics (`litheLogging` 1). This is a pre-release: it needs a Lithe preview build that offers `litheLogging` 1. Stable Lithe 0.6.7 installs it but cannot start its backend; keep 0.1.1 from Lithe Store there.
+
+### Improvements
+
+- The backend uses the official Rust SDK's structured logging; diagnostics go to the current session's `plugins/io.github.lithe-idea.database/host` channel in Lithe's log window.
+- The SDK records exactly one success or failure for each backend function, with its function ID, duration and a stable category; cancellation is not a failure.
+- Successful workspace loads, history reads and writes, and DBX previews no longer log INFO. In `database.call`, metadata, paged browsing and probes suppress only their success entries; explicit queries and writes still log INFO, and every failure logs ERROR.
+- When query results are trimmed to the transport limit, one WARN `result_size_limited` is logged per backend run.
+- Diagnostics never contain SQL, connection strings, server addresses, user names, passwords, returned rows, configuration content or file paths. Backend startup failures no longer print to stderr.
+- The official Rust SDK is vendored in the repository; CI and packaging verify every file's SHA-256.
+
+### Installing and upgrading
+
+- Lithe Store's tracker skips pre-releases, so this version is not listed in the Store. Download this release's ZIP and import it with Install Plugin from Disk… in the ⚙ menu of Settings → Plugins.
+- A copy installed from disk does not receive the connections, folders, SQL history and passwords of Lithe's former built-in database module; that move waits until a copy installed from Lithe Store runs. Users who already migrated with 0.1.1 are not affected.
+- Permissions are unchanged from 0.1.1.
+- The release workflow runs end-to-end checks against Core from Lithe preview `4dd3165`, asserting exactly one terminal log entry per call; complete UI interaction still needs target-host acceptance.
+
+[Full changelog](https://github.com/Lithe-IDEA/lithe-plugin-database/compare/v0.1.1...v0.1.2)

plugin.json

@@ -2,7 +2,7 @@
   "schemaVersion": 2,
   "id": "io.github.lithe-idea.database",
   "displayName": "Database",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "pluginAPIVersion": 3,
   "requires": { "backend": 1, "serverProcess": 1, "ui": 2 },
   "vendor": {