Repository navigation
Releases: ARCJ137442/SysTorch
Release list
v0.12.0
SysTorch 0.12.0 — 预发布 / Pre-release
把眼前的问题,变成下一步。
Turn questions into next steps.
SysTorch 0.12.0 将规范的 SysTorch 请求入口与可追踪的路由尝试接到「开始」工作面。本版本以 GitHub prerelease 提供,尚未经维护者人工验收。
SysTorch 0.12.0 brings the canonical SysTorch request endpoint and traceable route attempts into the Start workspace. This is a GitHub prerelease and has not been accepted hands-on by the maintainer.
自动化发布门禁已通过。完整 CI 结果、附件哈希、签名核验和 Pages 状态见0.12.0 发布核验。
Automated release gates have passed. See the 0.12.0 release verification for CI results, asset hashes, signing checks, and Pages status.
下载 / Downloads
本次只发布两个附件:
Exactly two assets are published:
- SysTorch-0.12.0-windows-x64.exe — Windows x64 单文件 Standalone / single-file Standalone.
- SysTorch-0.12.0-android-aarch64.apk — Android arm64 APK,使用现有稳定签名 / signed with the existing stable key.
Windows EXE 暂无 Authenticode 签名,Windows 可能提示发布者未知。Android 显示名称为 SysTorch,applicationId 与稳定签名保持不变,供已安装版本覆盖升级;如果 Android 报签名不一致,请停止安装,不要先卸载旧版。
The Windows EXE is not Authenticode-signed, so Windows may show an unknown publisher warning. Android displays SysTorch and keeps the existing applicationId and signing key for in-place upgrades. If Android reports a signature mismatch, stop and do not uninstall the existing app first.
本版内容 / What's included
-
新增 canonical
POST /v1/systorch/systemone,接受 SysTorch 请求超集并验证问题顺序;TypeSafe-compatible 部分仍按原格式送往上游,旧/v1/systemone保持兼容。 -
「开始」成功回复可展开查看路由轨迹及真实 provider attempts;失败回复按 request ID 延迟读取调用历史,展示失败状态与后续路由策略。
-
中英文 README、图册、发布说明与 GitHub About 统一使用 SysTorch 品牌和口号。
-
既有 DAG、边级辉光、provider lifecycle、普通加密会话、人工作答和 Android daemon 身份继续保留。
-
Adds canonical
POST /v1/systorch/systemone, validates question order, and projects the TypeSafe-compatible core to upstreams. The legacy/v1/systemoneendpoint remains compatible. -
Successful Start replies can reveal their route trace and actual provider attempts. Failed replies load existing call history by request ID and show failure status and retry path.
-
The Chinese and English READMEs, gallery, release notes, and GitHub About use the SysTorch brand and slogan.
-
Existing DAG routing, edge glow, provider lifecycle, encrypted chats, human decisions, and Android daemon identity remain in place.
用户叙事与对照场景 / User story and comparison
一个调用方提交结构化决策问题后,第一家上游可能因额度、网络或服务状态失败;DAG 按既有策略尝试下一家。成功时,「开始」把成功决策显示为主回复,并在路由轨迹中按需呈现前面的失败与最后的成功;完全失败时,用户可展开失败回复,用同一 request ID 对应到调用历史。这样能从“只有一个 HTTP 错误”进一步看清“请求经过哪些真实尝试”,同时保留单个入口父请求与多个上游 attempt 的关系。
After a caller submits a structured decision, the first upstream may fail because of quota, network, or service availability. The DAG then follows its existing policy and tries the next provider. On success, Start presents the decision as the main reply and reveals earlier failures and the successful attempt on demand. If all attempts fail, the failure reply can load call history with the same request ID. This turns a single HTTP error into an inspectable sequence while preserving one parent request and its upstream attempts.
路由轨迹是可追踪的操作元数据,不包含问题正文、回答、密钥或上游原始响应。此 Release 的 CI 与合成测试不等于维护者在 Windows 与 Android 真机上完成验收;真实上游能力还取决于使用者当前的凭据、路由和服务状态。
Route traces are operational metadata; they do not include question text, answers, credentials, or raw upstream responses. CI and synthetic tests do not equal maintainer acceptance on Windows or a physical Android device. Real upstream capability still depends on the user’s credentials, route configuration, and service availability.
v0.11.0
SysTorch 0.11.0 — 预发布 / Pre-release
把眼前的问题,变成下一步。
Turn questions into next steps.
本版本将产品品牌从 Jev Switch 迁移为 SysTorch,并把「开始/决策台」作为普通使用者与自动化调用方都能进入的工作面。v0.11.0 Release workflow 已成功,Windows 与 Android 附件已构建并通过自动校验;它仍是预发布版本,尚未经维护者人工验收。
This release moves the product brand from Jev Switch to SysTorch and makes Start / Decision Desk an entry workspace for people and automated callers. The v0.11.0 Release workflow has passed; the Windows and Android assets have been built and automatically verified. It remains a pre-release and has not been accepted hands-on by the maintainer.
自动发布验证 / Automated release validation: Release workflow 40978835105 · main CI 40978815250 · GitHub Pages 40981197660.
下载 / Downloads
本次 GitHub Release 只公开下列两个附件:
This GitHub Release publishes exactly these two assets:
-
SysTorch-0.11.0-windows-x64.exe — Windows x64 单文件 Standalone。
-
SysTorch-0.11.0-android-aarch64.apk — arm64 Android APK,使用现有稳定签名。
-
SysTorch-0.11.0-windows-x64.exe — single-file Windows x64 Standalone.
-
SysTorch-0.11.0-android-aarch64.apk — arm64 Android APK signed with the existing stable key.
Windows EXE 暂无 Authenticode 签名,因此 Windows 可能提示发布者未知。Android 显示名称为 SysTorch,但 applicationId 与稳定签名保持不变,支持覆盖旧稳定版。若 Android 报签名不一致,请停止安装并保留旧应用数据,不要先卸载。
The Windows EXE is not Authenticode-signed, so Windows may show an unknown publisher warning. Android displays SysTorch but keeps the existing applicationId and stable signing key for in-place upgrades. If Android reports a signature mismatch, stop and keep the existing app data; do not uninstall first.
本版内容 / What's included
-
SysTorch 品牌:火炬 SVG 是唯一图形母版,桌面、托盘、Android launcher、最近任务与启动页从同一来源派生。产品品牌不绑定某一家供应商;Jev / System One 是协议和模型系列。
-
开始与决策台:普通模型对话与持久人工作答使用各自的数据边界。用户可以组织多题消息、共享背景和附件;Agent 可提交人工作答任务后退出,在决策台作答后再取回。
-
保留原有专业能力:DAG 路由、边级请求辉光、入口与提供商配置、提供商服务启停和调用追溯继续在 SysTorch 中提供。
-
原子配置操作:常规图写入按资源事务提交,完整校验通过后再更新 SQLite 与运行中的路由快照。
-
运行时兼容:浏览器平台探测在无 navigator 的 Node 20 自动化环境中安全回退,原生主人凭据仍绑定在捕获的网关地址上。
-
双语对外材料:README、GitHub About、网站和发布说明采用新口号与 SysTorch 品牌;历史版本记录保留其当时的名称与证据。
-
SysTorch brand: the torch SVG is the single graphic source for desktop, tray, Android launcher, recent tasks, and loading UI. The product is not tied to a provider; Jev / System One names a protocol and model family.
-
Start and Decision Desk: ordinary model conversations and durable human answers have separate data boundaries. People can compose multi-question messages with shared context and attachments. An agent may submit a task, exit, then retrieve the answer after a person responds in the Decision Desk.
-
Existing professional capabilities remain: DAG routing, edge-level request glow, entry and provider configuration, provider service lifecycle, and traceable calls remain available.
-
Atomic configuration operations: normal graph writes commit as resource transactions. SQLite and the live route snapshot update only after complete validation succeeds.
-
Runtime compatibility: browser-platform detection safely handles Node 20 automation environments without navigator while keeping native owner credentials bound to the captured gateway.
-
Bilingual public materials: README files, GitHub About, the website, and these notes use the SysTorch brand and slogan. Historical release records keep the names and evidence of their time.
用户叙事与对照场景 / User story and comparison
一次发布判断怎样回到原调用方 / How a release decision returns to its caller
- 起点 / Starting point:一个 Harness 正在安排版本发布,需要确认“是否可以发布”。
- 问题 / Problem:Harness 不能代替维护者做最终判断;若它只能同步等待,进程就必须一直运行,也难以跨重启继续。
- 操作 / Action:Harness 通过 SysTorch 提交带稳定 ID 的结构化问题,并退出。维护者在决策台查看上下文并明确选择。Harness 后续用原身份查询任务。
- 结果 / Result:请求、人的观察与调用方取回结果关联到同一个持久任务;写入会检查身份、修订和幂等状态。
- 对照 / Comparison:普通模型决策仍可从「开始」进入;需要观察 provider 尝试和 route trace 时,可进入原有 DAG 和历史界面。
- 边界 / Boundary:系统不会把人工作答伪装为模型响应,不会自动调整 DAG,也不提供团队分派。此版本未通过维护者人工测试。
验收边界 / Acceptance boundary
自动门禁和附件核验结果记录在 0.11.0 候选核验。它们不等同于 Windows 人工启动、Android 真机升级与权限测试、真实上游多模态推理或维护者对视觉质量的验收。请将使用问题连同版本、平台与复现步骤反馈到 GitHub Issues。
Automated gates and asset checks are recorded in the 0.11.0 candidate verification. They do not equal hands-on Windows launch, Android device upgrade and permission tests, real upstream multimodal inference, or maintainer visual acceptance. Report issues with the version, platform, and reproduction steps in GitHub Issues.
v0.10.3
版本说明
本次为 0.10.3 正式版本。Windows 资产随包提供 windows-signing-status.txt;若仓库变量 WINDOWS_SIGNING_REQUIRED 未开启,该清单会明确标记 Windows 包未使用 Authenticode。Android APK(如签名 Secrets 已配置)随包提供 commit、版本码、签名指纹和 SHA-256 manifest。
本版内容
- 修复 Windows 后台请求未采用系统代理的问题:恢复 reqwest
system-proxy,公网上游调用、API 探测与模型目录发现遵循用户已经配置的代理。 localhost、127/8、IPv6 回环和映射回环的本地服务调用、探测与 readiness 始终直连,避免代理错误页被误判为服务可达。- TypeSafe HTTP 451 保留上游状态码与错误正文,按非重试错误处理;不修改 Jev 请求 JSON、Bearer 鉴权或 TLS 校验。
- 同步代理故障排查与旧版临时恢复指南,保留原子配置写入、路由、历史和生命周期能力。
用户叙事与对照场景
云端上游:让后台请求采用已配置的系统代理
- 起点:Windows 用户已开启系统代理,浏览器使用预期的海外出口;Jev Switch 配置了官方 TypeSafe 地址、API key 和
jev-latest。 - 问题:daemon 关闭 reqwest 默认 features 时漏启用系统代理支持,后台仍然直连;没有正文的 GET 也返回地区不可用的 HTTP 451,容易被误认为模型格式或凭据问题。
- 操作:完整退出旧 APP(包括托盘驻留),安装或启动本版,保持原提供商地址和凭据;先刷新提供商模型目录,再到演练场执行一次实际调用。
- 结果:本地修复对照中,Rust 客户端通过现有代理进入官方鉴权处理;使用现有凭据访问模型目录返回 HTTP 200、2 个模型,未发送付费推理请求。
- 对照:同机直连返回 451,现有代理路径通过地区门禁;本机 Laya、StartLux、OneJev 等回环服务继续直连,不依赖公网上游代理。
- 边界:代理必须由用户正确配置,本版不提供代理节点、不承诺地区持续可用。旧进程必须退出后重新启动,新 EXE 不会更新旧进程已创建的 HTTP 客户端。
验证范围与发布后检查
Rust 默认/ts-rs 测试、Clippy、fmt、本地服务探测和监听回归已通过;本页附件由同一 tag 的 Release workflow 构建。模型目录 HTTP 200 是网络与鉴权证据,不等于模型推理成功。
发行包启动后的真实 TypeSafe 推理、原生 UI 和本地模型状态抽查留到发布后验证,当前尚未完成。 本次没有新增 Android/Linux 的系统代理行为,也没有重复执行先前本地服务的整套人工验收。调查证据见 TypeSafe 系统代理核验,完整变化见 CHANGELOG。
安装
Windows 桌面:下载下方 .msi(或 NSIS .exe)双击安装。
Windows 便携版:下载 .zip 并解压,双击其中的 jev-switch.exe;它与同次构建的安装包共享壳、daemon 与 UI 资源,不运行安装器。
Windows 独立版:下载 jev-switch-standalone-*-windows-x64.exe 并双击;首次启动会把内嵌 daemon/UI 校验后释放到当前用户的版本化运行缓存,应用数据仍保存在 %APPDATA%\\jev-switch。
Headless CLI:下载对应平台的 jev-switch-cli-*;Termux/Android arm64 请在设备上执行 cargo install --path rs/crates/jev-switch-cli --locked,避免把主机二进制误当成 Android 包。
Android:仓库配置四个稳定签名 Secrets 后,Release 会附带 jev-switch-<version>-android-aarch64.apk 与 manifest;未配置时 Android job 会明确跳过,但 Windows/CLI/Docker 仍会正常发布。首次从历史 debug-signed APK 升级到稳定签名包时,需先卸载旧版本一次。
Docker(Bash):先将 JEV_ADMIN_PASSWORD 设置为自己的管理员密码。
下例挂载持久数据卷,并只在宿主机回环地址提供控制台。
: "${JEV_ADMIN_PASSWORD:?请先设置管理员密码}"
export JEV_ADMIN_PASSWORD
docker pull ghcr.io/arcj137442/jev-switch:0.10.3
docker run -d --name jev-switch \
-p 127.0.0.1:11435:11435 \
--restart unless-stopped --stop-timeout 15 \
-e JEV_SWITCH_MODE=cloud -e JEV_BIND=0.0.0.0:11435 \
-e JEV_ADMIN_PASSWORD -v jev-switch-data:/data \
ghcr.io/arcj137442/jev-switch:0.10.3打开 http://127.0.0.1:11435,用管理员密码登录,再到 Token 管理创建调用 Token。
远程部署、反向代理和配置导入见 docs/deployment.md。
发版流程与排查见 docs/RELEASE.md。
Full Changelog: v0.10.2...v0.10.3
v0.10.2
版本说明
本次为 0.10.2 预发布预览版。Windows 资产随包提供 windows-signing-status.txt;若仓库变量 WINDOWS_SIGNING_REQUIRED 未开启,该清单会明确标记 Windows 包未使用 Authenticode。Android APK(如签名 Secrets 已配置)随包提供 commit、版本码、签名指纹和 SHA-256 manifest。
本版内容
- 提供商高级配置支持受控服务的启动、停止、状态探查、readiness、超时、进程策略和生命周期审计。
- Providers 页面保留每个提供商的服务启停面板状态,面板打开时自动探测服务状态;每个提供商可独立关闭 API 自动探测。
- Laya、StartLux 和 OneJev 的外部脚本生命周期已完成多轮状态、启动、就绪、停止验证;云端 provider 继续保持手工管理。
- 公开本地服务脚本指南包含脱敏示例、逐项环境变量说明、UI 配置步骤、跨平台实现原理和故障排查 FAQ。
- 既有路由 DAG、路由活动、统计、演练场、Android 和稳定品牌图标能力保持兼容。
用户叙事与对照场景
本地服务启停:从手工记命令到可回溯的生命周期
用户为本地模型服务分别维护启动、停止和状态脚本,过去需要离开控制台手工执行,也难以判断“进程存在”是否等于“API 已就绪”。现在在 Providers 的服务启停面板登记通用命令,Jev Switch 只负责安全执行、readiness 探测、状态反馈和审计;脚本仍由用户按自己的模型运行时维护。对照场景是云端 provider:没有可控服务配置时,仍只做 API 探测,不会尝试主机命令。
多轮启停:从一次成功到可重复恢复
Laya、StartLux 和 OneJev 分别经历状态→启动→就绪→停止循环;失败时界面保留错误码、请求 ID 和下一步检查方向,避免把“启动器进程退出”误报为“服务运行中”。脚本的路径、权重和运行时依赖不写入公开发布页,统一放在脱敏指南的占位符中。
安装
Windows 桌面:下载下方 .msi(或 NSIS .exe)双击安装。
Windows 便携版:下载 .zip 并解压,双击其中的 jev-switch.exe;它与同次构建的安装包共享壳、daemon 与 UI 资源,不运行安装器。
Windows 独立版:下载 jev-switch-standalone-*-windows-x64.exe 并双击;首次启动会把内嵌 daemon/UI 校验后释放到当前用户的版本化运行缓存,应用数据仍保存在 %APPDATA%\\jev-switch。
Headless CLI:下载对应平台的 jev-switch-cli-*;Termux/Android arm64 请在设备上执行 cargo install --path rs/crates/jev-switch-cli --locked,避免把主机二进制误当成 Android 包。
Android:仓库配置四个稳定签名 Secrets 后,Release 会附带 jev-switch-<version>-android-aarch64.apk 与 manifest;未配置时 Android job 会明确跳过,但 Windows/CLI/Docker 仍会正常发布。首次从历史 debug-signed APK 升级到稳定签名包时,需先卸载旧版本一次。
Docker(Bash):先将 JEV_ADMIN_PASSWORD 设置为自己的管理员密码。
下例挂载持久数据卷,并只在宿主机回环地址提供控制台。
: "${JEV_ADMIN_PASSWORD:?请先设置管理员密码}"
export JEV_ADMIN_PASSWORD
docker pull ghcr.io/arcj137442/jev-switch:0.10.2
docker run -d --name jev-switch \
-p 127.0.0.1:11435:11435 \
--restart unless-stopped --stop-timeout 15 \
-e JEV_SWITCH_MODE=cloud -e JEV_BIND=0.0.0.0:11435 \
-e JEV_ADMIN_PASSWORD -v jev-switch-data:/data \
ghcr.io/arcj137442/jev-switch:0.10.2打开 http://127.0.0.1:11435,用管理员密码登录,再到 Token 管理创建调用 Token。
远程部署、反向代理和配置导入见 docs/deployment.md。
发版流程与排查见 docs/RELEASE.md。
Full Changelog: v0.10.1...v0.10.2
v0.10.1
版本说明
本次为 0.10.1 正式版本。Windows 资产随包提供 windows-signing-status.txt;若仓库变量 WINDOWS_SIGNING_REQUIRED 未开启,该清单会明确标记 Windows 包未使用 Authenticode。Android APK(如签名 Secrets 已配置)随包提供 commit、版本码、签名指纹和 SHA-256 manifest。
本版内容
- 提供商高级配置支持受控服务的启动、停止、状态探查、readiness、超时、进程策略和生命周期审计。
- Providers 页面保留每个提供商的服务启停面板状态,面板打开时自动探测服务状态;每个提供商可独立关闭 API 自动探测。
- Laya、StartLux 和 OneJev 的外部脚本生命周期已完成多轮状态、启动、就绪、停止验证;云端 provider 继续保持手工管理。
- 公开本地服务脚本指南包含脱敏示例、逐项环境变量说明、UI 配置步骤、跨平台实现原理和故障排查 FAQ。
- 既有路由 DAG、路由活动、统计、演练场、Android 和稳定品牌图标能力保持兼容。
用户叙事与对照场景
本地服务启停:从手工记命令到可回溯的生命周期
用户为本地模型服务分别维护启动、停止和状态脚本,过去需要离开控制台手工执行,也难以判断“进程存在”是否等于“API 已就绪”。现在在 Providers 的服务启停面板登记通用命令,Jev Switch 只负责安全执行、readiness 探测、状态反馈和审计;脚本仍由用户按自己的模型运行时维护。对照场景是云端 provider:没有可控服务配置时,仍只做 API 探测,不会尝试主机命令。
多轮启停:从一次成功到可重复恢复
Laya、StartLux 和 OneJev 分别经历状态→启动→就绪→停止循环;失败时界面保留错误码、请求 ID 和下一步检查方向,避免把“启动器进程退出”误报为“服务运行中”。脚本的路径、权重和运行时依赖不写入公开发布页,统一放在脱敏指南的占位符中。
安装
Windows 桌面:下载下方 .msi(或 NSIS .exe)双击安装。
Windows 便携版:下载 .zip 并解压,双击其中的 jev-switch.exe;它与同次构建的安装包共享壳、daemon 与 UI 资源,不运行安装器。
Windows 独立版:下载 jev-switch-standalone-*-windows-x64.exe 并双击;首次启动会把内嵌 daemon/UI 校验后释放到当前用户的版本化运行缓存,应用数据仍保存在 %APPDATA%\\jev-switch。
Headless CLI:下载对应平台的 jev-switch-cli-*;Termux/Android arm64 请在设备上执行 cargo install --path rs/crates/jev-switch-cli --locked,避免把主机二进制误当成 Android 包。
Android:仓库配置四个稳定签名 Secrets 后,Release 会附带 jev-switch-<version>-android-aarch64.apk 与 manifest;未配置时 Android job 会明确跳过,但 Windows/CLI/Docker 仍会正常发布。首次从历史 debug-signed APK 升级到稳定签名包时,需先卸载旧版本一次。
Docker(Bash):先将 JEV_ADMIN_PASSWORD 设置为自己的管理员密码。
下例挂载持久数据卷,并只在宿主机回环地址提供控制台。
: "${JEV_ADMIN_PASSWORD:?请先设置管理员密码}"
export JEV_ADMIN_PASSWORD
docker pull ghcr.io/arcj137442/jev-switch:0.10.1
docker run -d --name jev-switch \
-p 127.0.0.1:11435:11435 \
--restart unless-stopped --stop-timeout 15 \
-e JEV_SWITCH_MODE=cloud -e JEV_BIND=0.0.0.0:11435 \
-e JEV_ADMIN_PASSWORD -v jev-switch-data:/data \
ghcr.io/arcj137442/jev-switch:0.10.1打开 http://127.0.0.1:11435,用管理员密码登录,再到 Token 管理创建调用 Token。
远程部署、反向代理和配置导入见 docs/deployment.md。
发版流程与排查见 docs/RELEASE.md。
Full Changelog: v0.10.0...v0.10.1
v0.10.0
版本说明
本次为 0.10.0 版本。该版本按当前版本策略标记为预发布候选;本预发布的 Windows 包仅用于功能验证,随包 windows-signing-status.txt 明确记录未使用 Authenticode。Android APK 继续使用同一稳定签名,请核对随包 JSON 中的 commit、版本码与 APK SHA-256。
本版内容
- 同一
POST /v1/systemone请求可携带显式extensions或兼容服务所需的未知顶层字段。 - local 模式默认保留扩展;TypeSafe-compatible provider 可显式开启
forward_extensions,官方 TypeSafe 默认剥离并在响应元数据中记录处理状态。 - v0.8.0 的 Graph API、Dashboard 布局、provider attempt 双视图、Android 原生 JSON/剪贴板桥和既有路由能力继续保留。
用户叙事与对照场景
顶级页面快捷切换:像浏览器标签一样比较页面
用户在 Jev Switch 中反复比较 Dashboard、Providers、Routing 和 Playground,需要连续查看多个顶级页面。鼠标往返顶栏会打断对照节奏,而普通浏览器的 Ctrl+Tab 又不应被网页版本抢走。现在 Tauri APP 中按 Ctrl+Tab 顺序切换、Ctrl+Shift+Tab 逆序切换;焦点位于输入控件或可编辑区域时快捷键让位。对照场景是:Tauri APP 接管页面循环,普通浏览器保留浏览器标签切换;只读用户只循环访问可见页面。
多模态与滚轮交互的连续体验
v0.9.x 还让本地多模态 provider 通过同一个 /v1/systemone 入口承载媒体扩展,并让 Routing DAG 普通滚轮上下平移、Shift+滚轮左右平移。媒体转发与视觉质量、滚轮手感与硬件设备分别验证,避免把协议兼容或输入便利误写成模型质量承诺。
用户叙事与对照场景
多模态兼容:同一个 Jev 入口承载图片决策
用户已经有本地 OneJev 图片决策服务,但下游只会调用 /v1/systemone。问题在于官方 TypeSafe 是文本/JSON 边界,把 Base64 塞进 state 无法表达媒体语义。用户把媒体放入 extensions.media 并为本地兼容 provider 开启 forward_extensions,Jev Switch 继续提供同一个入口,同时在 route trace 中记录字段名和 forwarded/stripped 状态。与官方 TypeSafe 对照时,协议不变但媒体被明确剥离;视觉质量与概率校准仍单独验收。
Routing DAG 滚轮平移:从拖拽浏览到滚轮浏览
当路由图变成长地图,用户原本只能拖拽空白区域移动视口。现在普通滚轮上下平移,Shift+滚轮左右平移,触控板 deltaX 优先;Ctrl/⌘+滚轮仍缩放,拖拽节点仍改布局。对照可见滚轮改变“看哪里”、缩放改变“看多大”、拖拽改变“图怎么组织”;输入控件与触摸路径保留原行为。原生硬件手感和多模态模型质量仍需相应设备/模型验证。
安装
Windows 桌面:下载下方 .msi(或 NSIS .exe)双击安装。
Windows 便携版:下载 .zip 并解压,双击其中的 jev-switch.exe;它与同次构建的安装包共享壳、daemon 与 UI 资源,不运行安装器。
Windows 独立版:下载 jev-switch-standalone-*-windows-x64.exe 并双击;首次启动会把内嵌 daemon/UI 校验后释放到当前用户的版本化运行缓存,应用数据仍保存在 %APPDATA%\\jev-switch。
Headless CLI:下载对应平台的 jev-switch-cli-*;Termux/Android arm64 请在设备上执行 cargo install --path rs/crates/jev-switch-cli --locked,避免把主机二进制误当成 Android 包。
Android:仓库配置四个稳定签名 Secrets 后,Release 会附带 jev-switch-<version>-android-aarch64.apk 与 manifest;未配置时 Android job 会明确跳过,但 Windows/CLI/Docker 仍会正常发布。首次从历史 debug-signed APK 升级到稳定签名包时,需先卸载旧版本一次。
Docker(Bash):先将 JEV_ADMIN_PASSWORD 设置为自己的管理员密码。
下例挂载持久数据卷,并只在宿主机回环地址提供控制台。
: "${JEV_ADMIN_PASSWORD:?请先设置管理员密码}"
export JEV_ADMIN_PASSWORD
docker pull ghcr.io/arcj137442/jev-switch:0.10.0
docker run -d --name jev-switch \
-p 127.0.0.1:11435:11435 \
--restart unless-stopped --stop-timeout 15 \
-e JEV_SWITCH_MODE=cloud -e JEV_BIND=0.0.0.0:11435 \
-e JEV_ADMIN_PASSWORD -v jev-switch-data:/data \
ghcr.io/arcj137442/jev-switch:0.10.0打开 http://127.0.0.1:11435,用管理员密码登录,再到 Token 管理创建调用 Token。
远程部署、反向代理和配置导入见 docs/deployment.md。
发版流程与排查见 docs/RELEASE.md。
Full Changelog: v0.9.3...v0.10.0
v0.9.2
版本说明
本次为 0.9.2 版本。Android APK 继续使用同一稳定签名;请核对随包 JSON 中的 commit、版本码与 APK SHA-256。
本版内容
- 同一
POST /v1/systemone请求可携带显式extensions或兼容服务所需的未知顶层字段。 - local 模式默认保留扩展;TypeSafe-compatible provider 可显式开启
forward_extensions,官方 TypeSafe 默认剥离并在响应元数据中记录处理状态。 - v0.8.0 的 Graph API、Dashboard 布局、provider attempt 双视图、Android 原生 JSON/剪贴板桥和既有路由能力继续保留。
用户叙事与对照场景
顶级页面快捷切换:像浏览器标签一样比较页面
用户在 Jev Switch 中反复比较 Dashboard、Providers、Routing 和 Playground,需要连续查看多个顶级页面。鼠标往返顶栏会打断对照节奏,而普通浏览器的 Ctrl+Tab 又不应被网页版本抢走。现在 Tauri APP 中按 Ctrl+Tab 顺序切换、Ctrl+Shift+Tab 逆序切换;焦点位于输入控件或可编辑区域时快捷键让位。对照场景是:Tauri APP 接管页面循环,普通浏览器保留浏览器标签切换;只读用户只循环访问可见页面。
多模态与滚轮交互的连续体验
v0.9.x 还让本地多模态 provider 通过同一个 /v1/systemone 入口承载媒体扩展,并让 Routing DAG 普通滚轮上下平移、Shift+滚轮左右平移。媒体转发与视觉质量、滚轮手感与硬件设备分别验证,避免把协议兼容或输入便利误写成模型质量承诺。
用户叙事与对照场景
多模态兼容:同一个 Jev 入口承载图片决策
用户已经有本地 OneJev 图片决策服务,但下游只会调用 /v1/systemone。问题在于官方 TypeSafe 是文本/JSON 边界,把 Base64 塞进 state 无法表达媒体语义。用户把媒体放入 extensions.media 并为本地兼容 provider 开启 forward_extensions,Jev Switch 继续提供同一个入口,同时在 route trace 中记录字段名和 forwarded/stripped 状态。与官方 TypeSafe 对照时,协议不变但媒体被明确剥离;视觉质量与概率校准仍单独验收。
Routing DAG 滚轮平移:从拖拽浏览到滚轮浏览
当路由图变成长地图,用户原本只能拖拽空白区域移动视口。现在普通滚轮上下平移,Shift+滚轮左右平移,触控板 deltaX 优先;Ctrl/⌘+滚轮仍缩放,拖拽节点仍改布局。对照可见滚轮改变“看哪里”、缩放改变“看多大”、拖拽改变“图怎么组织”;输入控件与触摸路径保留原行为。原生硬件手感和多模态模型质量仍需相应设备/模型验证。
安装
Windows 桌面:下载下方 .msi(或 NSIS .exe)双击安装。
Windows 便携版:下载 .zip 并解压,双击其中的 jev-switch.exe;它与同次构建的安装包共享壳、daemon 与 UI 资源,不运行安装器。
Windows 独立版:下载 jev-switch-standalone-*-windows-x64.exe 并双击;首次启动会把内嵌 daemon/UI 校验后释放到当前用户的版本化运行缓存,应用数据仍保存在 %APPDATA%\\jev-switch。
Headless CLI:下载对应平台的 jev-switch-cli-*;Termux/Android arm64 请在设备上执行 cargo install --path rs/crates/jev-switch-cli --locked,避免把主机二进制误当成 Android 包。
Android:仓库配置四个稳定签名 Secrets 后,Release 会附带 jev-switch-<version>-android-aarch64.apk 与 manifest;未配置时 Android job 会明确跳过,但 Windows/CLI/Docker 仍会正常发布。首次从历史 debug-signed APK 升级到稳定签名包时,需先卸载旧版本一次。
Docker(Bash):先将 JEV_ADMIN_PASSWORD 设置为自己的管理员密码。
下例挂载持久数据卷,并只在宿主机回环地址提供控制台。
: "${JEV_ADMIN_PASSWORD:?请先设置管理员密码}"
export JEV_ADMIN_PASSWORD
docker pull ghcr.io/arcj137442/jev-switch:0.9.2
docker run -d --name jev-switch \
-p 127.0.0.1:11435:11435 \
--restart unless-stopped --stop-timeout 15 \
-e JEV_SWITCH_MODE=cloud -e JEV_BIND=0.0.0.0:11435 \
-e JEV_ADMIN_PASSWORD -v jev-switch-data:/data \
ghcr.io/arcj137442/jev-switch:0.9.2打开 http://127.0.0.1:11435,用管理员密码登录,再到 Token 管理创建调用 Token。
远程部署、反向代理和配置导入见 docs/deployment.md。
发版流程与排查见 docs/RELEASE.md。
Full Changelog: v0.9.1...v0.9.2
v0.9.1
版本说明
本次为 0.9.1 版本。Android APK 继续使用同一稳定签名;请核对随包 JSON 中的 commit、版本码与 APK SHA-256。
本版内容
- 同一
POST /v1/systemone请求可携带显式extensions或兼容服务所需的未知顶层字段。 - local 模式默认保留扩展;TypeSafe-compatible provider 可显式开启
forward_extensions,官方 TypeSafe 默认剥离并在响应元数据中记录处理状态。 - Routing DAG 普通滚轮上下平移,Shift+滚轮左右平移,触控板
deltaX优先;Ctrl/⌘+滚轮仍缩放,拖拽节点仍改布局。
用户叙事与对照场景
多模态兼容:同一个 Jev 入口承载图片决策
用户已经有本地 OneJev 图片决策服务,但下游只会调用 /v1/systemone。问题在于官方 TypeSafe 是文本/JSON 边界,把 Base64 塞进 state 无法表达媒体语义。用户把媒体放入 extensions.media 并为本地兼容 provider 开启 forward_extensions,Jev Switch 继续提供同一个入口,同时在 route trace 中记录字段名和 forwarded/stripped 状态。与官方 TypeSafe 对照时,协议不变但媒体被明确剥离;视觉质量与概率校准仍单独验收。
Routing DAG 滚轮平移:从拖拽浏览到滚轮浏览
当路由图变成长地图,用户原本只能拖拽空白区域移动视口。现在普通滚轮上下平移,Shift+滚轮左右平移,触控板 deltaX 优先;Ctrl/⌘+滚轮仍缩放,拖拽节点仍改布局。对照可见滚轮改变“看哪里”、缩放改变“看多大”、拖拽改变“图怎么组织”;输入控件与触摸路径保留原行为。
边界
Jev Switch 不负责图片缩放、视觉判断或概率校准;多模态模型质量需独立测量。原生硬件滚轮手感、Tauri WebView 和触摸设备仍需按设备证据验收。
安装
Windows 桌面:下载 .msi 或 NSIS .exe 双击安装。
Windows 便携版:下载 .zip 解压后双击 jev-switch.exe。
Windows 独立版:下载 jev-switch-standalone-*-windows-x64.exe 后双击。
Headless CLI:下载对应平台的 jev-switch-cli-*。
Docker:使用 ghcr.io/arcj137442/jev-switch:0.9.1,并按 docs/deployment.md 设置管理员密码。
完整流程见 docs/RELEASE.md,变更清单见 CHANGELOG.md。
v0.9.0
版本说明
本次为 0.9.0 版本。Android APK 继续使用同一稳定签名;请核对随包 JSON 中的 commit、版本码与 APK SHA-256。
本版内容
- 同一
POST /v1/systemone请求可携带显式extensions或兼容服务所需的未知顶层字段。 - local 模式默认保留扩展;TypeSafe-compatible provider 可显式开启
forward_extensions,官方 TypeSafe 默认剥离并在响应元数据中记录处理状态。 - v0.8.0 的 Graph API、Dashboard 布局、provider attempt 双视图、Android 原生 JSON/剪贴板桥和既有路由能力继续保留。
安装
Windows 桌面:下载下方 .msi(或 NSIS .exe)双击安装。
Windows 便携版:下载 .zip 并解压,双击其中的 jev-switch.exe;它与同次构建的安装包共享壳、daemon 与 UI 资源,不运行安装器。
Windows 独立版:下载 jev-switch-standalone-*-windows-x64.exe 并双击;首次启动会把内嵌 daemon/UI 校验后释放到当前用户的版本化运行缓存,应用数据仍保存在 %APPDATA%\\jev-switch。
Headless CLI:下载对应平台的 jev-switch-cli-*;Termux/Android arm64 请在设备上执行 cargo install --path rs/crates/jev-switch-cli --locked,避免把主机二进制误当成 Android 包。
Android:仓库配置四个稳定签名 Secrets 后,Release 会附带 jev-switch-<version>-android-aarch64.apk 与 manifest;未配置时 Android job 会明确跳过,但 Windows/CLI/Docker 仍会正常发布。首次从历史 debug-signed APK 升级到稳定签名包时,需先卸载旧版本一次。
Docker(Bash):先将 JEV_ADMIN_PASSWORD 设置为自己的管理员密码。
下例挂载持久数据卷,并只在宿主机回环地址提供控制台。
: "${JEV_ADMIN_PASSWORD:?请先设置管理员密码}"
export JEV_ADMIN_PASSWORD
docker pull ghcr.io/arcj137442/jev-switch:0.9.0
docker run -d --name jev-switch \
-p 127.0.0.1:11435:11435 \
--restart unless-stopped --stop-timeout 15 \
-e JEV_SWITCH_MODE=cloud -e JEV_BIND=0.0.0.0:11435 \
-e JEV_ADMIN_PASSWORD -v jev-switch-data:/data \
ghcr.io/arcj137442/jev-switch:0.9.0打开 http://127.0.0.1:11435,用管理员密码登录,再到 Token 管理创建调用 Token。
远程部署、反向代理和配置导入见 docs/deployment.md。
发版流程与排查见 docs/RELEASE.md。
Full Changelog: v0.8.0...v0.9.0
v0.8.0
v0.8.0
本版为 v0.7.2 之后的 minor 版本,开始交付统一 DAG 核心和 Dashboard 第一阶段布局能力。
新增与改进
- 新增
GraphDocument、GraphNode和GraphNodeKind领域模型,区分公开入口、内部节点和提供商出口。 - runtime snapshot 可派生节点投影,新增只读
GET /v1/admin/graph,保留既有/v1/admin/routes、/v1/admin/endpoints和/v1/admin/providers兼容接口。 - Graph 校验覆盖未知引用、环路、provider/public ID 冲突和 provider 终端约束。
- Dashboard 第一阶段组件化:布局 registry、规范化、本地存储、显隐、宽度、排序、添加/移除、撤销/重做、取消/完成和设置入口。
- 保留 v0.7.2 的提供商删除级联、表单快捷键和 ARC UI 收口。
当前边界
- Graph API 当前只读;节点 CRUD、原子图写入、回滚和节点顶级页面在后续阶段实现。
- Dashboard 当前为按钮排序式布局编辑;Routing、Settings、Statistics 尚未接入布局编辑器。
- Android 原生 service/tile/通知、后台生命周期和跨设备差异仍需独立真机证据。
下载
- Windows Standalone、Portable、MSI、NSIS
- Linux/Windows CLI
- Docker 镜像
ghcr.io/arcj137442/jev-switch:0.8.0 - 稳定签名 Android arm64 APK及其
idsig/构建元数据