@synopackageland/cli 0.10.2 → 0.10.4

package/CHANGELOG.md

@@ -1,1705 +1,268 @@
 # Changelog
 
-## 0.10.2 (2026-10-14)
-
-Builds with SDK 0.10.2 and templates 0.10.2: `init` writes SDK v0.10.2 (Go
-module, Rust crate tag and `backend.sdk`) and `@synopackageland/sdk` 0.10.2.
-The executor digest table adds SDK 0.10.2 and keeps 0.10.0 and 0.10.1. SDK
-0.10.2's executor changed (it adds `check-policy`), so an App rebuilt on it
-carries a new executor digest; when its policy digest does not change, the
-upgrade puts the new executor in place without approval. The lifecycle
-digests equal 0.10.1.
-
-繁中摘要：使用 SDK 0.10.2 與 templates 0.10.2；digest 表新增 SDK 0.10.2（保留
-0.10.0、0.10.1）。executor 變更（新增 check-policy），policy digest 不變的 App
-升級時自動換 executor，不需重新核准；lifecycle digest 與 0.10.1 相同。
-
-- `check` and `build` have the App's SDK executor validate the executor policy
-  (`executor check-policy`, SDK 0.10.2 and later, which `init` now writes; built for this host from the
-  App's SDK version, or from `SYNOPKGLAND_SDK_DIR`). A policy the executor
-  would refuse fails with `EXECUTOR_POLICY_REJECTED`, the executor's reason and
-  the dsm-package.yaml part to fix, instead of failing only at approval on the
-  NAS. Apps without delegate or rootOps, and SDKs before check-policy, are not
-  checked.
-- Fix: `inspect` reports an SDK it cannot download as `SDK_DOWNLOAD_FAILED`
-  with the GOPRIVATE hint. It was `SPK_INSPECTION_FAILED` ("Executor inventory
-  invalid", "do not install an SPK that fails inspection"), which blamed a
-  valid SPK for the machine's Go setup.
-- Fix: a DSM window (and a Portal or standalone launch) passes the App
-  `ctx.displayName` in the DSM language: the translated `i18n.info.<locale>.displayname`,
-  the name DSM shows in the window title, else the English `displayname`. It
-  was always the English name, so a narrow-window header and the title bar
-  disagreed under a translated DSM.
-
-## 0.10.1 (2026-10-13)
-
-Builds with SDK 0.10.1 and templates 0.10.1: `init` writes SDK v0.10.1 (Go
-module, Rust crate tag and `backend.sdk`) and `@synopackageland/sdk` 0.10.1.
-The executor digest table adds SDK 0.10.1 and keeps 0.10.0. SDK 0.10.1's
-executor changed, so an App rebuilt on it carries a new executor digest and
-its pins are approved again; the lifecycle digests equal 0.10.0. The bridge
-manifest schema is synced from the SDK (`capabilities.root` also serves
-`executor.status` and `executor.control`).
-
-繁中摘要：使用 SDK 0.10.1 與 templates 0.10.1；digest 表新增 SDK 0.10.1（保留
-0.10.0）。executor 變更，改用 SDK 0.10.1 重建的 App 要重新核准 executor digest，
-lifecycle digest 與 0.10.0 相同。
-
-- A Python, Node.js or Rust App with root-ops and a Vue UI borrows
-  `native-go-root-ops/frontend`, as a Go App gets it from its overlay: its
-  `ExecutorGate.vue` holds the App's pages until an administrator approves
-  the executor (templates 0.10.1).
-- Fix: in a DSM window with root operations (`capabilities.rootOps`, and so a
-  `portal` App), the App root now fills the window body below the root panels.
-  It had no height, so an App root asking for `height:100%` collapsed to its
-  content: a loading overlay covered only the top of the window, and a dialog
-  centred on the App root was placed above the window. Windows without root
-  operations are unchanged.
-
-## 0.10.0 (2026-10-13)
-
-Builds with SDK 0.10.0 and templates 0.10.0: `init` writes SDK v0.10.0 (Go
-module, Rust crate tag and `backend.sdk`), `@synopackageland/sdk` 0.10.0 and
-`@synopackageland/ui` 0.9.4, and the Vue templates use the SDK's `AppShell`.
-CLI 0.10 builds only SDK 0.10.x: the executor digest table records SDK
-0.10.0 and no longer lists 0.9.x, so an App on SDK 0.9.x is refused
-(`SDK_UNSUPPORTED`) and stays on CLI 0.9.7. SDK 0.10.0's executor changed, so
-a rebuilt App carries new executor and lifecycle digests and its pins are
-approved again; the policy digest changes only for a policy that uses root
-program settings, jobs, `stop` or `state`.
-
-繁中摘要：使用 SDK 0.10.0 與 templates 0.10.0（UI 0.9.4），Vue 範本改用 SDK 的
-`AppShell`；新增 Python、Node、Rust App（bridge runtime）、root programs 設定、
-`ui.window`、`backend.timeout_seconds`（預設 60 秒），CLI 輸出全改英文。CLI 0.10
-只接受 SDK 0.10.x，digest 表移除 0.9.x；executor 變更，重建的 App 要重新核准
-executor 與 lifecycle digest。
-
-- Breaking: every CLI message is English. Error descriptions and suggestions,
-  `--help` text, and check, inspect, build and deploy output no longer carry
-  Chinese. Only the multilingual data shipped to DSM end users keeps its
-  translations: the install/upgrade/uninstall wizard copy, the App UI catalogs
-  and the INFO `displayname`/`description` translations. A test now fails on
-  CJK in any other `src/` file.
-- Behavior change: every App's backend request deadline is 60 seconds instead
-  of the SDK's 20. `bridge.json` always carries `timeout_seconds`, so the
-  runtime's deadline and the `deadline_ms` it sends the App follow it; a Go
-  CGI gets it as `-X main.requestTimeout` and keeps the SDK's 20 seconds
-  until its main reads that variable into `api.Timeout`. The DSM window sets
-  `ctx.requestTimeout` to the deadline and gives up two seconds past it (62
-  seconds instead of 22), also for a prebuilt binary CGI.
-- `backend.timeout_seconds` (1–3600) sets another deadline for go, python,
-  node and rust backends. A Go main that does not read `requestTimeout` into
-  `api.Timeout` is refused (`STANDALONE_TIMEOUT_UNSUPPORTED`); a binary
-  backend refuses it.
-- `ui.window: {width, height, minWidth, minHeight}` sets the DSM window's
-  size; omitted fields keep 960×640, at least 700×420, and a standalone
-  launch keeps its 320 px minimum width. Sizes outside 320–3840 × 240–2160,
-  or a minimum larger than the size, are refused
-  (`STANDALONE_UI_WINDOW_INVALID`).
-- The generated DSM window knows a standalone (Portal) launch,
-  `_S("standalone") === true`: its minimum width drops from 700 to 320 px so
-  a phone can show it, and `mount` gets `ctx.fullPage` and `ctx.appIcon` (the
-  package's 64 px window icon) for a full-page layout and brand.
-- `init -t native-python | native-node | native-rust` creates the native-go
-  App with a Python, Node.js (TypeScript) or Rust backend: the Go template's
-  UI, frontend and root program, the language's capability overlays for
-  `--with jobs,root-ops,delegate` (jobs also declares `files: session`, which
-  its example reads; delegate opens `app.status` and `report.save` to
-  signed-in users; Rust lists the added methods in `backend.methods`), and the
-  App SDK its tests import in `backend/vendor`. `--shared-folder` stays
-  native-go only. Capability overlays carry their permission rules.
-- Breaking: `backend.kind: rust` (the Rust full SDK) is removed, and
-  `init -t native-rust` now creates the thin Rust App behind the bridge
-  runtime instead.
-- `backend.runtime: python | node | rust` builds an App in another language
-  behind the SDK's Go runtime (spec/bridge/v1). `build` compiles
-  `bridge/cmd/runtime` of the App's SDK release as `ui/cgi/api.cgi` with the
-  sha256 of `bridge.json` and `permissions.json` bound, and ships the App in
-  `target/app`: Python with the SDK in `vendor/`, Node with the SDK in
-  `node_modules/@synopackageland/app` and an `install_dep_packages` on
-  Package Center's Node.js, Rust cross-compiled with `cargo zigbuild`.
-  Methods come from `backend.methods` or the App's `--describe`. `inspect`
-  checks the manifest schema, the digests, the entry, that the App is not
-  under `ui/`, and the Node dependencies. The `bridge` gate builds all three
-  for every architecture.
-- Bridge Apps may declare `jobs`, `rootOps`, `portal` and an
-  `until-revoked` `delegate` for `files.moveFromStaging`, plus
-  `backend.transfers` and `backend.max_upload_bytes`; `bridge.json` carries
-  them. With jobs or delegate the runtime is also installed as
-  `target/background/worker` and DSM runs it with `--worker` as the package
-  account. `inspect` refuses delegate digests that are not the SPK
-  executor's. The Node SDK is copied as its `package.json` and `dist/`, so
-  the SDK checkout must be built.
-- `root` in dsm-package.yaml configures root programs for the executor's
-  root programs, root jobs, package stop step and root state directory:
-  `programs.<name>` gives a params `schema` and `run` or `job` limits,
-  `kind: binary` takes `root/<arch>/<name>` (an ELF for each architecture,
-  so the policy digest differs per architecture), `stop` names the program
-  the executor runs at package stop and upgrade, and `state: true` asks for
-  the root state directory. Programs without settings keep the bare digest,
-  so existing policies and their digests do not change. Jobs add
-  `root.start` and the `root.jobs` operations. A build whose SDK executor
-  predates these refuses them (`EXECUTOR_ROOT_PROGRAMS_UNSUPPORTED`).
-- `preupgrade` stops the executor with `executor/lifecycle stop --upgrade`;
-  an installed helper without the flag gets a plain stop.
-
-- The DSM window icons are named after their content,
-  `images/app_<hash>_<size>.png`, and `ui/config` points at that name. DSM and
-  the browser cache an App icon by its URL, so after an icon change DSM kept
-  showing the old one (the blue square in t-0391) until the cache expired; a
-  new icon now has a new URL, and an unchanged icon keeps its cached one. DSM
-  7.4 passes the config's icon path, with `{0}` for the size, to
-  `SYNO.Core.Synohdpack getHDIcon` for every `webman/3rdparty/` App, so any
-  file name works.
-- `ctx.call(method, params, {signal})` aborts its fetch when the signal does,
-  so a page the user leaves really stops its request, and rejects
-  `{code: "request_canceled"}`. It also gives up after the SDK's
-  `clientTimeout(ctx.requestTimeout)`, two seconds past the backend deadline
-  (the backend deadline unless the App sets `ctx.requestTimeout` in ms, read
-  on every call), aborts the fetch and rejects `{code: "request_timeout"}`.
-  Before, a call waited as long as the browser did. The portal and root
-  panels use the same call.
-- preuninst waits for the App's uninstall hook by looking it up in `/proc`
-  instead of `kill -0`. DSM's bash logs a failed builtin to syslog even with
-  `2>/dev/null`, so every uninstall with a hook logged `BASH_ERR ... kill: No
-  such process` twice (t-0383 B8). The wait, the timeout and the result are
-  unchanged; a host without `/proc` still uses `kill -0`.
-- preuninst stops an uninstall hook past its timeout, and prestart waits for
-  a stale package user manager to exit, without a `kill` that can fail: the
-  hook's process group and the manager are looked up in `/proc` first, so
-  neither logs `BASH_ERR ... kill: No such process` once the process has
-  exited.
-- The Application Portal panel's Italian instructions use the infinitive like
-  DSM ("Riprovare o usare il Pannello di controllo."), the same text as the
-  SDK's `i18n/portal` catalogs.
-- `ctx.portal.status()` waits for a register or unregister in progress to
-  end, whatever its result, like the SDK's `createPortalAccess`. Before, a
-  status read during a slow change could show "The Application Portal entry
-  was not fully removed".
-
-## 0.9.7 (2026-10-13)
-
-Builds with SDK 0.9.8 and templates 0.9.7: `init` writes SDK v0.9.8 (Go
-module and Rust crate tag), `@synopackageland/sdk` 0.9.8 and
-`@synopackageland/ui` 0.9.2. SDK 0.9.8 fixes `BackgroundPanel`, whose controls
-to choose a file and submit it were hidden on DSM. The executor digest table
-records SDK 0.9.8 with the same executor and lifecycle digests as 0.9.7, and
-the policy digest does not change, so a rebuilt App keeps the pins it was
-approved with.
-
-繁中摘要：使用 SDK 0.9.8 與 templates 0.9.7（UI 0.9.2）。SDK 0.9.8 修正
-`BackgroundPanel` 在 DSM 上看不到選檔與送出按鈕。digest 表加入 SDK 0.9.8，
-executor 與 lifecycle digest 與 0.9.7 相同，policy digest 也不變，重建的 App
-沿用原本核准的 pins。
-
-## 0.9.6 (2026-10-12)
-
-Builds with SDK 0.9.7 and templates 0.9.6: `init` writes SDK v0.9.7 (Go
-module and Rust crate tag), `@synopackageland/sdk` 0.9.7 and
-`@synopackageland/ui` 0.9.2. The executor digest table records SDK 0.9.7,
-whose executor and lifecycle binary changed, so a rebuilt App carries new
-executor digests. The policy digest changes only for an App that declares
-`uninstall.purge.root`, and such an App asks for approval again after the
-upgrade; `bg.jobs.pause` and `bg.jobs.resume` reach the CGI route table, not
-the policy. Whether new executor digests alone ask for approval again has not
-been checked on a DSM yet.
-
-繁中摘要：使用 SDK 0.9.7 與 templates 0.9.6（UI 0.9.2）。executor digest 表加入
-SDK 0.9.7；executor 與 lifecycle 都有變更，重建的 App 會帶新的 executor digest。
-只有宣告 `uninstall.purge.root` 的 App 的 policy digest 會變，升級後需要重新核准；
-`bg.jobs.pause`、`bg.jobs.resume` 只進 CGI route 表，不影響 policy。只換 executor
-digest 時是否需要重新核准，尚未在 DSM 上驗證。新增解除安裝 hook（`uninstall.purge`）。
-
-- Uninstall hook: `uninstall.purge` in dsm-package.yaml (`exec`, `args`,
-  `env`, `timeout` 2..120 s, optional `root`) names the App's own command,
-  and `uninstall.state.items` lists the state it can delete, each with an
-  `uninstall.state.<key>` text. On a real uninstall preuninst stops the
-  worker and the daemon, runs the hook as the package account with
-  `SYNOPKGLAND_DELETE_STATE` and `SYNOPKGLAND_REMOVE_DATA`, then asks the
-  executor to purge; a failing or timed-out hook is logged and never blocks
-  the uninstall, and an upgrade skips it. The wizard gains an unchecked
-  "delete state" box after the item texts. `purge.root` names a rootOps
-  script the executor runs as root only while its approval stands; the
-  policy's `purge` member records it, so such an App asks for approval
-  again. Build refuses a hook outside the package or one that tries to
-  become root. inspect checks an executor SPK's preuninst and wizard against
-  the hook recorded in sdk-package.json, and that record's root step against
-  the policy's `purge`.
-- `init` and `add` change only the dsm-package.yaml keys they set
-  (`capabilities`, `portal`, `os_min_ver`); the template's comments, such as
-  the commented `uninstall` example, and its formatting stay as written.
-- With `SYNOPKGLAND_SDK_DIR`, init also drops the released SDK from the
-  frontend's package-lock.json, so npm installs the local ts package.
-
-## 0.9.5 (2026-10-12)
-
-Builds with SDK 0.9.6 and templates 0.9.5: `init` writes SDK v0.9.6,
-`@synopackageland/sdk` 0.9.6 and `@synopackageland/ui` 0.9.2. The executor
-digest table records SDK 0.9.6, whose executor registers the portal entry
-and checks a grant's background work from the browser address it recorded,
-so a rebuilt App carries new executor digests. The policy digest changes
-only for an App whose executor registers its portal entry (a portal and
-os_min_ver below 7.2): after the upgrade it asks for approval again. Other
-Apps keep their policy digest.
-
-繁中摘要：使用 SDK 0.9.6 與 templates 0.9.5（UI 0.9.2）。executor digest 表加入
-SDK 0.9.6，重建的 App 會帶新的 executor digest。只有由 executor 註冊入口的
-portal App（宣告 portal 且 os_min_ver 低於 7.2）policy digest 會變，升級後需重新
-核准；其他 App 的 policy digest 不變。DSM 7.1 起可用 portal（executor 模式）。
-
-- The generated DSM window stays inside the desktop: its width is at most the
-  viewport's and its height at most the viewport's less the DSM taskbar. This
-  applies to the default 960×640 and to the size DSM restores from
-  `restoreSizePos`, which may have been saved on a larger screen. Position and
-  maximized state are restored as before.
-- Native root authorization (`createRootAccess` from
-  `@synopackageland/cli/authorization-sdk`): the first `run` after an `authorize`
-  runs the task that `authorize` just read back as exactly ours, instead of
-  reading the TaskScheduler list and task again. Any later run, a repair, and
-  a run after `remove` still read DSM first; `authorize` still reads the task
-  back after creating it and checks its identity and script.
-- Native root authorization polls the task history every 0.5 s, then at most
-  once a second (was up to every 2 s), so a finished root task is seen up to
-  1 s sooner.
-- A portal works from DSM 7.1-42661 on. Below 7.2-64570 (executor mode) the
-  SPK carries no web-config resource, `etc/portal.*`, alias wizard step or
-  alias lifecycle; the executor policy carries `portal: {application, alias}`
-  and the `portal.register` / `portal.unregister` operations, and the CGI is
-  built with `-X main.portal=executor`. A package name or displayname the
-  executor would refuse fails with `STANDALONE_PORTAL_ENTRY_INVALID`; below
-  7.1 `STANDALONE_PORTAL_MIN_DSM` still refuses the portal, and `add portal`
-  raises os_min_ver only to 7.1-42661. inspect reports the policy's entry
-  and flags an INFO os_min_ver below 7.1. Needs templates 0.9.5 and SDK 0.9.6.
-- `ctx.portal` in executor mode: `status()` carries `entry`, administrators
-  get `register()` and `unregister()`, and the plain panel offers "Enable
-  entry", "Remove entry" or the alias form by entry state. New texts in nine
-  languages, including `PORTAL_FAILED`. The panel's Korean texts use the
-  formal -십시오 register.
-- The uninstall wizard and the cleanup list of an executor-mode portal App
-  warn that a stopped or never-approved executor leaves the entry, and give
-  the root cleanup commands.
-- native-layout: `portal: {}` or `{alias}` (DSM 7.1-42661+) writes
-  `synopkgland_portal_alias` into INFO for the product's own root helper;
-  inspect checks it against `native-layout.json`.
-- DSM's web-config portal registration now needs `os_min_ver` 7.2-64570 or
-  later instead of 7.3.2-86009. DSM 7.1's package manager marks the web-config
-  worker Synology-only and refuses it in an unsigned SPK (error 320); synopkg
-  from DSM 7.2 on drops that mark, the only change to its worker table. The
-  7.2 floor comes from that source and is not yet verified on a 7.2 NAS.
-  inspect flags a web-config portal SPK whose INFO os_min_ver is lower, with
-  this reason.
-
-## 0.9.4 (2026-10-12)
-
-Builds with SDK 0.9.5 and templates 0.9.4: `init` writes SDK v0.9.5 and
-`@synopackageland/sdk` 0.9.5, and the Vue App's `AppRoot` lets Dialogs leave
-a DSM window. The executor digest table records SDK 0.9.5, whose executor
-equals 0.9.4's; the policy digest stays the same, so an installed App needs
-no new approval. AI guidance for DSM-window Dialogs matches the Vue App.
-
-繁中摘要：使用 SDK 0.9.5 與 templates 0.9.4。SDK 0.9.5 只改 TypeScript（NAS
-picker 改用 UI 0.9.1 元件），executor digest 與 0.9.4 相同，policy digest 不變，
-已安裝的 App 不需重新核准。ui-vue 與 ui-json 指引改為在 DSM 視窗內給 `AppRoot`
-`dialog-bounds="viewport"`，並把 `activate` 接到 `ctx.host.activateWindow()`：
-Dialog 可拖出 App 視窗，點 Dialog 會把視窗帶到最前；600px 以下為底部 sheet。
-
-- `ui-vue` and `ui-json`: in a DSM window (`ctx.host.platform().host === 'dsm'`),
-  give `AppRoot` `dialog-bounds="viewport"` and connect its `activate` event to
-  `ctx.host.activateWindow()`, so Dialogs can be dragged out of the window and
-  pressing one brings the window to the front. Below 600px they are bottom
-  sheets. Standalone web, Portal and previews keep Dialogs inside the App.
-- A host-window test pins that the mounted App's `activateWindow` fronts only
-  its own DSM window.
-
-## 0.9.3 (2026-10-12)
-
-Builds with SDK 0.9.4 and templates 0.9.3: `init` writes SDK v0.9.4 and
-`@synopackageland/sdk` 0.9.4. The executor digest table records SDK 0.9.4,
-whose executor asks DSM's native `SLIBAppPrivUserHas` for App Privileges
-instead of the `SYNO.Core.AppPriv.App` preview. An App rebuilt with SDK 0.9.4
-gets the new executor; the policy digest stays the same, so an installed App
-needs no new approval.
-
-繁中摘要：使用 SDK 0.9.4 與 templates 0.9.3。executor 改以 DSM 原生
-`SLIBAppPrivUserHas` 判斷應用程式權限，digest 表加入 0.9.4；policy digest 不變，
-重新建置後已安裝的 App 不需重新核准。限定 IP 的應用程式權限規則改為依瀏覽器位址
-判斷；自行組 `auth` 的呼叫端必須帶 `remote_addr`，否則 executor 回 `APP_DENIED`。
-
-- Behavior change: an Application Privileges rule limited to IP addresses
-  applies to the browser's address; with SDK 0.9.3 or earlier the executor
-  refused every request under such a rule. Work no browser asked for is
-  checked as coming from 127.0.0.1. The generated CGI sends the address
-  through `api.DSMSession`; code that builds the executor `auth` itself must
-  add `remote_addr` or the executor refuses with `APP_DENIED`.
-- The fake-DSM executor flow tests host the 0.9.4 executor's embedded bridge
-  and check the online grant against the browser's address and the offline
-  write against 127.0.0.1.
-
-## 0.9.2 (2026-10-12)
-
-Builds with SDK 0.9.3 and templates 0.9.2: `init` writes SDK v0.9.3 and
-`@synopackageland/sdk` 0.9.3. The executor digest table records SDK 0.9.2 and
-0.9.3 (the same digests; 0.9.3 changes only translations). An App rebuilt
-with SDK 0.9.2 or 0.9.3 gets the new executor; the policy digest stays the
-same, so an installed App needs no new approval.
-
-繁中摘要：`check` 與 `build` 的錯誤訊息每個錯誤碼只出現一次；`build --json` 的 SDK
-下載失敗附上 GOPRIVATE 提示；有 executor 並宣告 `install.sharedFolder` 的 App 通過
-`inspect` 的 postinst 檢查。重新安裝後的核准只需輸入一次密碼：共用資料夾讀回等 40 s，
-沒到達 executor 的選擇任務在同一次核准內再跑一次，啟動後的健康檢查等 30 s。
-
-- `check` and `build` name each error code once. 0.9.1 printed the first code
-  twice, for example
-  `[STANDALONE_PORTAL_REQUIRES_EXECUTOR] [STANDALONE_PORTAL_REQUIRES_EXECUTOR] …`.
-- A `--json` error without its own hint takes the registry suggestion of its
-  code. `build --json` now answers `SDK_DOWNLOAD_FAILED` with the GOPRIVATE and
-  git-credential step instead of the generic hint.
-- `inspect` accepts an App with `capabilities.rootOps` or `delegate` that
-  declares `install.sharedFolder`. Its `postinst` and `postupgrade` start the
-  executor before the shared-folder script, and 0.9.1 reported them as not
-  matching.
-- Re-approval after a reinstall takes one password submission for both the
-  executor and an install-selected share. The DSM window now reads the share
-  selection back for 40 s instead of 20 s, runs a selection task that missed
-  the restarting executor once more without a new confirmation, and waits
-  30 s instead of 10 s for a started executor before withdrawing the tasks an
-  approval created.
-
-## 0.9.1 (2026-10-12)
-
-Fixes from the 0.9.0 acceptance on DSM (t-0294, t-0290, t-0292).
-
-繁中摘要：`build` 重複 `--arch` 時每個架構都建置；SDK 下載失敗回報
-`SDK_DOWNLOAD_FAILED`（不再包成 `STANDALONE_API_PERMISSIONS_INVALID`），`check`
-顯示每個錯誤碼自己的建議；`status` 列出 portal；Vue App 只在 SDK 的
-ExecutorSettings 核准，plain UI 的 DSM 視窗面板改為有樣式、跟隨 DSM 語言並在面板內
-輸入密碼。更正 0.9.0 的核准說明：policy 不變的升級不需重新核准，只有
-install-selected 的 scope 需要管理員確認一次。記錄 SDK 0.9.1 executor digests（只換
-executor、policy digest 不變，免重新核准）。App 分兩層：有 executor（rootOps 或
-delegate）的 App 解除安裝時自動移除應用程式權限規則，宣告 portal 時再 reload nginx，
-精靈與 cleanup 清單只把它們列為自動清除失敗時的後備；無升權 App 任何階段都不用 root，
-應用程式權限規則仍由管理員手動移除。破壞性變更：portal 只限 executor 層級，無升權
-native App 以 `STANDALONE_PORTAL_REQUIRES_EXECUTOR` 拒絕，Compose App 以
-`CONTRACT_PORTAL_REQUIRES_EXECUTOR` 拒絕。並附 0.9.0 安裝殘留的清理步驟。
-
-### Build and check
-
-- `build --arch x86_64 --arch aarch64` builds every family named; 0.9.0 built
-  only the last one. Repeated values and comma lists combine.
-- An SDK version Go cannot fetch is reported as `SDK_DOWNLOAD_FAILED` with the
-  GOPRIVATE and git-credential hint. 0.9.0 wrapped it as
-  `STANDALONE_API_PERMISSIONS_INVALID`.
-- `check` shows the registry suggestion of each error code. It no longer
-  replaces every `dsm-package.yaml` error's suggestion with "fix the schema 2
-  fields".
-- `STANDALONE_ENTRY_UNSUPPORTED` names the `main.go` of the project's
-  `backend.main`, not always `cmd/app/main.go`.
-
-### Status
-
-- `status` lists `portal` for an App with `portal: {}`. It reads the App's
-  `portal.status`: `ready` with the URL when an administrator set an alias,
-  `needs-admin-approval` when none is set, and `blocked` before install or
-  when the status cannot be read.
-
-### DSM window approval
-
-- A Vue App approves the executor only in the SDK's `ExecutorSettings`. The
-  DSM window no longer adds its own approval panel to a Vue App with
-  `rootOps` or a fixed delegate scope. That panel used unstyled English
-  buttons, and its password prompt was appended below the App, so approving
-  from it never reached PasswordConfirm.
-- A plain-UI App keeps the window panel. It now uses the panel styles, shows
-  its text in the DSM language (the nine SDK locales), and asks for the
-  administrator password inside the panel. The password goes to
-  `authorize` the same way as in `ExecutorSettings`.
-- Breaking: `confirmPassword` without a password fails with
-  `password_required` and sends nothing; the masked form it appended is gone.
-
-### Portal needs the executor tier (breaking)
-
-- DSM removes a portal App's Login Portal alias at uninstall but does not
-  reload nginx (DSM 7.4, t-0294), so `/<alias>/` kept opening a DSM page.
-  Only root can reload it, so a `portal` now needs `capabilities.rootOps` or
-  `capabilities.delegate`. A no-privilege native App with `portal` fails
-  `check`/`build` with `STANDALONE_PORTAL_REQUIRES_EXECUTOR`; `add portal`
-  refuses it unless the same call adds `root-ops` or `delegate`; `inspect`
-  flags such an SPK with `PORTAL_REQUIRES_EXECUTOR`.
-- A Compose App has no executor: `integration.web.portal` now always fails
-  with `CONTRACT_PORTAL_REQUIRES_EXECUTOR` and the schema no longer describes
-  its shape. `CONTRACT_PORTAL_INVALID`, `CONTRACT_PORTAL_UNSUPPORTED` and
-  `CONTRACT_PORTAL_MIN_DSM` are gone, and `inspect` reports a Compose SPK's
-  `web-config` as an unknown resource.
-- Fix: add `root-ops` or `delegate`, or remove the portal and let an
-  administrator set up a reverse proxy in DSM.
-
-### Uninstall
-
-- An App with the executor (rootOps or delegate) cleans up after DSM itself:
-  SDK 0.9.1's root purge deletes the App's rules in Control Panel >
-  Application Privileges and, for a portal App, reloads nginx once DSM has
-  removed the alias. The uninstall wizard says so in the nine languages, and
-  `status`/`inspect` list both only as fallbacks: "Only if automatic cleanup
-  failed after uninstall; see the system log entry synopkgland-executor."
-- A no-privilege App never uses root, not even at uninstall. Its wizard keeps
-  saying that DSM keeps the App's rules in Control Panel > Application
-  Privileges, that a later install under the same name applies them again,
-  and that an administrator can remove them; the cleanup list keeps that
-  item. It never mentions a Login Portal alias, because it cannot declare one.
-  A test builds plain, files, jobs, identity and `entry: app-privilege` SPKs
-  and checks they run as the package account, ship no executor or root
-  tasks, and that their scripts never call synowebapi, nginx or a system
-  unit.
+## 0.10.4 (2026-10-14)
+
+Builds with SDK 0.10.4 and templates 0.10.4: `init` writes SDK v0.10.4 (Go
+module, Rust crate tag and `backend.sdk`), `@synopackageland/sdk` 0.10.4 and
+`@synopackageland/ui` 0.9.6. `check` and `build` still accept SDK 0.10.3 or
+later: nothing in this CLI needs 0.10.4, and an App on 0.10.3 never sees the
+stop and start codes the window now repeats. The executor digest table adds
+SDK 0.10.4, whose executor and lifecycle digests equal 0.10.3, so an App
+rebuilt on it keeps its approval unless its own root programs change. The
+gate refuses a stale SDK `ts/dist` and builds the executor flow's race binary
+before its timeout.
+
+繁中摘要：使用 SDK 0.10.4 與 templates 0.10.4（UI 0.9.6）；`check`／`build` 仍接受 SDK
+0.10.3 以上。`ctx.call` 自動重試套件停止／啟動中的碼；非管理員的
+`ctx.executor.status()` 可讀到已核准的 executor。digest 表新增 SDK 0.10.4（與 0.10.3
+相同），重建的 App 不需重新核准（除非自己的 root 程式改變）。
+
+- `ctx.call` repeats a call the package refused with `APP_STOPPED`,
+  `APP_STARTING` or `EXECUTOR_STARTING` (the executor op was not sent): after
+  0.5 s, doubling to at most 8 s, for 30 s of waiting in all, so an App comes
+  back by itself once the package has started. Other codes reject at once; past
+  the budget the last refusal rejects; leaving the page cancels the wait.
+  繁中：套件停止／啟動中時 `ctx.call` 自動有界重試（最多等 30 s）。
+- The window approval of an upgrade (outdated tasks) makes 11 scheduler calls
+  instead of 12: the outdated boot task is deleted by the approval's own first
+  EventScheduler get, made moments before the password, instead of a second
+  get (2.9 s on vt-nas in t-0484). The control task is still read again by id
+  before its delete (spec/scheduler/v1). A fresh approval stays at 8.
+  繁中：升級核准的排程呼叫由 12 降為 11（boot 任務不再於刪除前重讀）。
+- A scope approval reads the executor's selection back every second at most
+  (it backed off to 2 s), so the window sees the landed scope within a second
+  of `scope.confirm` (the Dialog closed 4.8 s after it in t-0482). Removing
+  the temporary selection task still lists Task Scheduler first, as
+  spec/scheduler/v1 requires of a delete.
+  繁中：範圍核准讀回間隔上限 2 s → 1 s，confirmed 後 1 s 內看到結果。
+- `ctx.executor.status()` for a user who is not an administrator asks the
+  App's `executor.status` (open to every signed-in user) instead of refusing
+  before any request: the pinned, running executor reads `ready`; anything
+  else stays `blocked` with `admin_required`. Task Scheduler is still read only
+  for administrators. A user no longer sees an approved executor as waiting
+  for approval (t-0482 F7).
+  繁中：非管理員的 `ctx.executor.status()` 會向 App 的 `executor.status` 詢問，已核准且
+  執行中即為 `ready`，不再一律回 `admin_required`。
+
+## 0.10.3 (2026-10-14)
+
+Builds with SDK 0.10.3 and templates 0.10.3: `init` writes SDK v0.10.3 (Go
+module, Rust crate tag and `backend.sdk`), `@synopackageland/sdk` 0.10.3 and
+`@synopackageland/ui` 0.9.5. **Incompatible:** `check` and `build` need SDK
+0.10.3 or later. The executor digest table adds SDK 0.10.3 and keeps 0.10.0
+to 0.10.2, so `inspect` still recognizes their SPKs. SDK 0.10.3's executor
+records the package version at every start, so an App rebuilt on it carries
+a new executor digest; when its policy digest does not change, the upgrade
+puts the new executor in place without approval. An App that declares
+`root.start` changes its policy and is approved again. The lifecycle digests
+equal 0.10.2.
+
+繁中摘要：使用 SDK 0.10.3 與 templates 0.10.3（UI 0.9.5）；`check`／`build` 需要 SDK
+0.10.3 以上（不相容）。digest 表新增 SDK 0.10.3（保留 0.10.0～0.10.2）。policy digest
+不變的 App 升級時自動換 executor；宣告 `root.start` 的 App 需要重新核准。lifecycle
+digest 與 0.10.2 相同。
+
+### Added
+
+- `root.start` in dsm-package.yaml names a `root/` program as the executor's start step: the
+  executor runs it as root once at the first start after each install or upgrade (`install`,
+  or `upgrade` and the previous version), only while the approval is live, for at most 60
+  seconds, and a failure never blocks the start. `build` writes it into the policy as `start`;
+  `check` refuses a name outside `root/` and a program that also declares `run` or `job`
+  (`STANDALONE_ROOT_PROGRAMS_INVALID`); the SDK executor's `check-policy` checks the rest.
+  `inspect` lists the root steps. Declaring it changes the policy digest, so the App needs
+  approval again; Apps without it keep their policy.
+
+  繁中摘要：`root.start` 指定一個 root 程式，executor 在每次安裝或升級後第一次啟動時以 root 執行一次；
+  失敗只記 log、不擋啟動。宣告後 policy digest 改變需重新核准，沒有宣告的 App 不受影響。
+
+- Lifecycle scripts: a project's `dsm-scripts/<DSM script name>` (`preinst`, `postinst`,
+  `preupgrade`, `postupgrade`, `preuninst`, `postuninst`, `start-stop-status`) is packed as
+  `scripts/app/<name>` and called from the generated script of the same name: after the SDK
+  steps, and before them for `preupgrade`, `preuninst` and `stop`. It runs as the package
+  account with DSM's arguments, environment and exit codes; a failed App `start` stops the SDK
+  again. Native and Compose projects. `check` refuses other names (`APP_SCRIPT_UNKNOWN`),
+  non-executable files and files without `#!`; `inspect` lists the App scripts. Projects
+  without `dsm-scripts/` build unchanged. Guide: `synopkgland skill show lifecycle`.
+
+  繁中摘要：專案 `dsm-scripts/` 下以 DSM 原生檔名放的腳本會被打包，並在 CLI 產生的同名腳本中於
+  SDK 步驟之後（preupgrade／preuninst／stop 在之前）以套件帳號執行；沒有該資料夾時行為不變。
+
+- Login Portal style: a portal App's launcher now carries DSM's `loginStyle` and `loginIcon`,
+  so Control Panel > Login Portal > Applications shows a thumbnail instead of a blank box, and
+  the alias login page gets a wallpaper, a button colour and the App icon. The CLI ships a
+  neutral default (`assets/login-style/`); `login_style` in dsm-package.yaml overrides
+  `color`, `wallpaper` with `wallpaper_thumbnail`, and `title`. `check` validates the images
+  (`STANDALONE_LOGIN_STYLE_INVALID`, `STANDALONE_LOGIN_STYLE_IMAGE_INVALID`) and prints the
+  style; `inspect` prints it and flags a portal SPK without one (`LOGIN_STYLE_MISSING`).
+  Rebuilding an existing portal App with this CLI adds the default; no change to the project.
+
+  繁中摘要：有 portal 的 App 重新 build 後會自動帶入預設登入樣式，「登入入口 › 應用程式」縮圖不再
+  空白，別名登入頁有桌布、按鈕色與 App icon；可用 `login_style` 換主色、桌布與標題圖。
+
+### Changed
+
+- **Incompatible:** the CLI needs SDK 0.10.3 or later. `check` and `build` refuse an App
+  whose backend requires SDK 0.10.0, 0.10.1 or 0.10.2 (`SDK_UNSUPPORTED`, naming 0.10.3);
+  raise the Go module, Cargo tag or `backend.sdk` and the frontend's
+  `@synopackageland/sdk` to 0.10.3. The CLI no longer carries the fallbacks for those
+  releases: the pre-`timeouts.json` timeouts, skipping `executor check-policy` for an SDK
+  without it, and `EXECUTOR_START_STEP_UNSUPPORTED`.
+
+  繁中摘要：CLI 需要 SDK 0.10.3 以上；App 若仍用 SDK 0.10.0～0.10.2，`check`／`build` 會以
+  `SDK_UNSUPPORTED` 拒絕。移除為舊版保留的逾時退回值、check-policy 略過與 start 步驟檢查。
+
+- `check` and `build` refuse a request deadline that ends before a root program `root.run`
+  may run would answer (`STANDALONE_REQUEST_TIMEOUT_SHORT`): `backend.timeout_seconds`
+  (60 by default) must be at least the program's `run.timeout_s` (20 by default) + 20, the
+  executor's 10 seconds and its client's 10 (SDK `spec/protocol/v1`, Timeouts). The default
+  covers programs of up to 40 seconds; a 120-second program needs `timeout_seconds: 140`.
+  A program with only `job`, `start` or `stop` is not affected.
+- The request default, the window's wait past the request deadline and the `root.run`
+  deadline check read their values from the App's SDK, `spec/protocol/v1/timeouts.json`,
+  instead of the CLI's own copies, so they follow the SDK the App builds with. An App
+  without the SDK keeps 60 seconds, 2 seconds, and a `run.timeout_s` of 20 + 20. The
+  generated values do not change with SDK 0.10.3.
+
+  繁中摘要：request 預設逾時、視窗多等的時間與 root.run 逾時檢查改讀 App 所用 SDK 的
+  timeouts.json，不再用 CLI 手抄的值；沒有 SDK 的 App 沿用 60 秒、2 秒、20 + 20。
+- The DSM window's approval and `control start` wait for an executor that answers
+  `state: "starting"` while it runs its start step, for up to 75 seconds, instead of giving
+  up after 30 seconds; past that the result is blocked with code `executor_starting`, and the
+  plain-UI panel and the SDK settings say the service is still starting. The plain-UI panel
+  says it is waiting for the background service while a request runs.
+
+  繁中摘要：核准與 control start 會等待回報「starting」的 executor（最多 75 秒），超過則以
+  `executor_starting` 阻擋並說明仍在啟動。
+
+- The DSM window's approval asks DSM's schedulers 8 times instead of 15, following the SDK's
+  `spec/scheduler/v1`. The boot task is read with one EventScheduler `get` by its name
+  (DSM keeps event task names unique) and never listed; Task Scheduler is listed once before
+  and once after the writes, and the control task is then read by its listed id. A step reads
+  each task once and reuses that read; a delete still reads the task again first. After the
+  boot task runs, only `executor.status` is asked: the tasks were read back exactly just
+  before, and the executor's pins answer for the rest. `executor.status` is asked every
+  500 ms for the first 4 seconds, then backs off to 2 seconds. `status` (and `check`) gets the
+  boot task by name instead of listing EventScheduler. Measured on a DSM 7.4 x86_64 NAS with
+  a fresh install: ready came 1.1-4.9 s after the boot task ran instead of 6.3-10.9 s, and
+  10.1-21.8 s after Approve instead of 16.3-26.9 s (DSM's scheduler calls vary by seconds).
+
+  繁中摘要：視窗核准對 DSM 排程 API 的呼叫從 15 次降為 8 次：boot 任務改用名稱 get、不再 list
+  EventScheduler；Task Scheduler 在寫入前後各 list 一次，之後用 id get；執行 boot 任務後只問
+  `executor.status`，前 4 秒每 500 ms 問一次。安全檢查（重複、內容逐字比對、pins）都保留。
+
+### Fixed
+
+- The DSM window's `openFileManager` and `revealFile` take a `/volumeN/...` path as the SDK's
+  `fileStationPath` does: a DSM volume mount (`/volumeN`, `/volumeUSBN`, `/volumeSATAN`) is
+  stripped instead of refused, and the reveal recovery follows the path File Station got.
+  Anything but one canonical shared-folder path is still `invalid-input`.
+- Executor approval results carry a structured `code` beside the English `reason`, and an
+  `outcome` when the approval rolled back: a refused administrator password is
+  `password_rejected` (DSM 3121), other PasswordConfirm refusals `password_required`,
+  `session_ended` or `password_confirm_failed`; scheduler, task and executor failures have
+  codes of their own (`scheduler_denied`, `task_missing`, `executor_unreachable`, …) and the
+  outcomes are `restored`, `withdrawn`, `restore_failed` and `withdraw_failed`. The SDK's
+  `ExecutorSettings` reads `code`. The plain-UI window panel now shows the code and outcome in
+  the DSM language, followed by the DSM code (`dsm_3121`), instead of the English reason.
+  Rebuild the App to pick this up.
+
+  繁中摘要：核准結果新增結構化 `code`（例如 `password_rejected`）與回復結果 `outcome`，`reason`
+  仍保留英文細節；純 UI 視窗面板改以 DSM 語系顯示原因，不再直接顯示英文；需重新 build App。
+
+- Executor approval: a scheduler write that fails partway no longer leaves the earlier
+  approval half deleted. The approval stops at the first failed write, withdraws the tasks
+  it created and recreates the earlier boot and control tasks it removed, then offers
+  approval again. DSM cannot hold two same-named tasks, so the old task is still deleted
+  before its replacement is created. When the rollback itself fails, the window says so, and
+  the next approval converges from what is left. A DSM session that ended (`dsm_106`,
+  `dsm_107`, `dsm_119`) asks the administrator to sign in to DSM again.
+
+  繁中摘要：核准半途寫入失敗時，會撤回這次建立的排程並重建先前核准的舊排程，再提供重新核准；
+  還原失敗時會明白說明，下次核准可自動收斂。DSM session 失效時提示重新登入。
+
+- An App opened through its Application Portal alias (`https://nas/<alias>/`) reaches its
+  backend again. The generated window posted `ctx.call` and `ctx.files` to the absolute
+  `/webman/3rdparty/<package>/cgi/api.cgi`, which DSM answers with 403 on the alias, so every
+  call failed with `bad_response` and an approved executor read as unavailable. The path is
+  now relative to the page, as the App's own assets are; the DSM desktop resolves it to the
+  same URL as before. Rebuild the App to pick this up.
+
+  繁中摘要：從應用程式入口別名網址開啟 App 時，`ctx.call`／`ctx.files` 改用相對路徑，不再被
+  DSM 以 403 拒絕（原本顯示 `bad_response`、已核准的 executor 顯示無法使用）；需重新 build App。
+
+- `check` and `build` refusing a `root.start`, `root.stop` or `uninstall.purge` program that
+  also declares `run` or `job` (`EXECUTOR_POLICY_REJECTED`) now say what to do: give the step
+  another program name in `root.programs`, one without `run` or `job`.
+
+  繁中摘要：start／stop／purge 的 program 同時宣告 run／job 而被拒時，提示改用另一個沒有
+  run／job 的 program 名稱。
+
+- `init` and `build` of a Python App whose SDK has no Python SDK (`python/synopkgland_app`)
+  report `STANDALONE_PYTHON_SDK_MISSING` with the path, instead of a bare `ENOENT`.
+
+  繁中摘要：找不到 Python SDK 時改回專屬錯誤碼 `STANDALONE_PYTHON_SDK_MISSING`，不再是 `ENOENT`。
+
+### Removed
+
+- `@synopackageland/cli/authorization-sdk` is gone: `ROOT_RUNTIME` and
+  `AUTHORIZATION_RUNTIME`, the window runtimes of a native product with its own pinned root
+  tasks, ship unchanged in `@synopackageland/sdk/native`. A native product imports them from
+  the SDK; generated Apps are not affected.
+
+  繁中摘要：native 產品的 root／authorization 視窗 runtime 改由 SDK（`@synopackageland/sdk/native`）提供，
+  CLI 不再匯出 `authorization-sdk`；一般產生的 App 不受影響。
+
+- The CLI's copy of the Application Portal panel text (19 keys in 9 languages) is gone:
+  `build` reads it from the App's SDK (`ts/i18n/portal/<locale>.json`, in every SDK 0.10.x),
+  the same text the SDK's `PortalSettings` shows. The built window is unchanged; a fix to the
+  text reaches an App with its next SDK.
+
+  繁中摘要：Application Portal 面板文案改從 App 的 SDK 讀取，CLI 不再保留一份；建出的視窗不變，文案修正隨 SDK 更新。
+
+- `dist/runtime/delegate-contract.js` keeps only the operation names the build checks; the
+  background-save DTOs, route table and limits, which nothing in the CLI used, and the frozen
+  v1 vector now live only in the SDK (`ts/src/delegate/long-running.ts`).
 
-### SDK 0.9.1
 
-- Depends on `@synopackageland/templates` 0.9.1: `init` scaffolds Apps that
-  require SDK 0.9.1 (`backend/go.mod` and `@synopackageland/sdk`).
-- The CLI records the SDK 0.9.1 executor digests, rebuilt with the
-  uninstall cleanup (x86_64 `5d75af3c…`, aarch64 `b0e1f817…`, armv7
-  `17db613a…`; lifecycle digests equal 0.9.0). SDK 0.9.1 only replaces the
-  executor: the policy format, task scripts and permissions are unchanged,
-  so the policy digest stays the same and no App needs a new approval. An App moved from SDK
-  0.9.0 to 0.9.1 in `backend/go.mod` keeps its approval; the installed
-  executor re-pins the new executor by itself.
-
-### Cleaning up after 0.9.0 installs
-
-An App built with SDK 0.9.0 could leave root tasks behind at uninstall
-(t-0294 bugs 1 and 3). If the App is still installed, rebuild it with SDK
-0.9.1, install that build and then uninstall it: the 0.9.1 purge rebuilds the
-task inventory from the approved policy and deletes the tasks. Otherwise an
-administrator removes them by hand:
-
-- Control Panel > Task Scheduler: delete `<package> executor control` and
-  `<package> executor selection`.
-- The boot event, which DSM's web API refuses to delete over HTTP (error
-  119): as root, run
-  `/usr/syno/bin/synowebapi --exec api=SYNO.Core.EventScheduler method=delete version=1 task_name="<package> executor boot"`.
-- Control Panel > Application Privileges: remove the App's rules. Control
-  Panel > Login Portal: if its alias still opens, save an application alias
-  there to reload nginx, or restart the NAS. The 0.9.1 rebuild-and-uninstall
-  route above does both for you.
-
-### Approval after upgrading (correction to 0.9.0)
-
-- 0.9.0 said a delegate App rebuilt with it needs one new approval. Measured
-  on DSM 7.4 (t-0294): a `files.moveFromStaging` App upgraded from 0.8.0 to
-  0.9.0 kept the same policy digest. The installed executor re-pinned the new
-  executor by itself, with no new approval. Only an `install-selected` scope
-  needed one administrator confirmation (PasswordConfirm) of the shared
-  folder.
-- A new approval is needed only when the executor policy changes, for
-  example new operations, another scope or changed root scripts.
-
-### Release tooling
-
-- `node scripts/executor-digests.mjs <sdk>/release/vX.Y.Z.json` records a
-  released SDK's executor and lifecycle digests in
-  `src/runtime/executor-digests.json`. It checks the three architectures,
-  go1.26.9 and the CLI minor. A tagged release (`commit` set) never changes
-  a recorded version; a release not yet tagged (`commit: null`) replaces its
-  own entry. SDK 0.9.1's digests were recorded this way.
-- `test/fixtures/executor-setup/` holds the `executor/setup.json` this CLI
-  writes for delegate, time-limited delegate with jobs, root-ops and
-  install-selected Apps, for the SDK executor's contract test.
-  `UPDATE_EXECUTOR_SETUP_FIXTURES=1 npm test` regenerates them.
-- The npm gate runs `scripts/smoke-exports.mjs`, the export check of
-  `smoke-pack.sh`. In 0.9.0 that check still imported the removed
-  `authorizationTemplateDirectory`, so `gate.sh docker` always failed.
-
-## 0.9.0 (2026-10-11)
-
-The CLI, the SDK and the project templates are now three repositories, and
-the CLI only packages, deploys and checks. An App names its SDK version once,
-in `backend/go.mod`. Background saves can create subfolders and choose what
-happens on a name conflict, and time-limited delegate jobs gain read, rename,
-copy, move and delete.
-
-繁中摘要：CLI 移到 github.com/synopackageland/syno-pkg-land-cli，只負責打包、部署與檢查；
-範本改由 `@synopackageland/templates`（精確 pin）提供；SDK 是
-`github.com/synopackageland/syno-pkg-land-sdk`（Go）與 `@synopackageland/sdk`（前端，含
-`./vue`），版本只寫在 `backend/go.mod`。`build` 依該版本 `go mod download`
-executor 並比對 CLI 內建的 sha256 表。`check` 新增 `SDK_REQUIRED`、
-`SDK_VERSION_MISMATCH`、`SDK_UNSUPPORTED`。`files.moveFromStaging` 的 `name`
-可帶子資料夾，新增 `conflict: fail|overwrite|rename`；有時限的 delegate 新增
-`files.read`、`files.rename`、`files.copy`、`files.move`、`files.delete`。
-管理員只在 executor policy 改變時需要重新核准；0.9.0 的 policy 有改變。
+## 0.10.2 (2026-10-14)
 
-### Repositories and the SDK version
+First release of the changelog. `@synopackageland/cli` (`synopkgland`)
+builds Synology DSM 7 packages (SPK) from a template, checks them, and
+installs them on a NAS. It builds with SDK 0.10.2 and templates 0.10.2.
 
-- The CLI is github.com/synopackageland/syno-pkg-land-cli, published as
-  `@synopackageland/cli`. The SDK is github.com/synopackageland/syno-pkg-land-sdk: the Go
-  module `github.com/synopackageland/syno-pkg-land-sdk` and the npm package
-  `@synopackageland/sdk`, which includes the Vue components at
-  `@synopackageland/sdk/vue`.
-- The `require github.com/synopackageland/syno-pkg-land-sdk` line in `backend/go.mod` is the
-  only SDK version. `dsm-package.yaml` has no SDK field.
-- `check` and `build` report `SDK_REQUIRED` when `capabilities.delegate` or
-  `rootOps` is declared without that line (an `entry` mode without it fails
-  with `STANDALONE_ENTRY_UNSUPPORTED`), `SDK_UNSUPPORTED` when its minor version is not the CLI's (CLI 0.9.x builds
-  SDK 0.9.x), and `SDK_VERSION_MISMATCH` when the frontend's
-  `@synopackageland/sdk` differs from it. A `file:` frontend dependency is
-  compared through that folder's `package.json` version.
-- `build` reads the SDK version from `backend/go.mod`, runs `go mod download`
-  for the executor of that version, and builds it with go1.26.9. Its sha256
-  must match the table shipped in this CLI, or the build fails with
-  `EXECUTOR_DIGEST_MISMATCH`. A version Go cannot fetch fails with
-  `SDK_DOWNLOAD_FAILED`. While the SDK repositories are private, set
-  `GOPRIVATE=github.com/synopackageland/*` and give git a credential for
-  github.com; the error says which of the two is missing. Root task scripts
-  and `sdk-permissions.json` come from the same SDK version.
-- The CGI binds both policy digests at link time:
-  `<module>/internal/api.expectedPermissionsDigest` for the App and
-  `github.com/synopackageland/syno-pkg-land-sdk/api.expectedSDKPermissionsDigest` for the
-  SDK.
-- `@synopackageland/cli/authorization-sdk` exports `AUTHORIZATION_RUNTIME`
-  and `ROOT_RUNTIME`. `authorizationTemplateDirectory` is removed;
-  `AuthorizationGate` is in `@synopackageland/sdk/vue`.
+繁中摘要：`synopkgland` 從模板建立 DSM 7 套件（SPK），檢查、打包並安裝到
+NAS；搭配 SDK 0.10.2 與 templates 0.10.2。
 
 ### Templates
 
-- `init` and `add` read the templates from `@synopackageland/templates`, a
-  dependency pinned to an exact version. `SYNOPKGLAND_TEMPLATES_DIR` points
-  them at a templates checkout; without either, `TEMPLATES_MISSING`.
-- `init` fills the placeholders in every generated file; the Go module path
-  of a new backend is the package id. The next steps say
-  `(cd frontend && npm install)`: the templates ship no lockfile.
-- `init` and `add` share one capability overlay table (`root-ops`, `jobs`,
-  `delegate`).
-
-### Local SDK checkout
-
-- With `SYNOPKGLAND_SDK_DIR`, `init` adds
-  `replace github.com/synopackageland/syno-pkg-land-sdk => $SYNOPKGLAND_SDK_DIR` to
-  `backend/go.mod` and sets the frontend dependency to
-  `file:$SYNOPKGLAND_SDK_DIR/ts`; install it with
-  `(cd frontend && npm install --install-links)`, which packs the SDK like the
-  released package. npm does not build a `file:` package, so a Vue project
-  needs `(cd $SYNOPKGLAND_SDK_DIR/ts && npm ci && npm run build)` first, and
-  again after SDK changes; `init` refuses a checkout without `ts/dist`, or
-  without a root `go.mod`, with `SDK_DIR_NOT_READY`.
-- `build` uses `$SYNOPKGLAND_SDK_DIR/executor`, skips the digest table and
-  warns with `EXECUTOR_DIGEST_UNVERIFIED`. Do not
-  publish such an SPK; the release script refuses to run while
-  `SYNOPKGLAND_SDK_DIR` or `SYNOPKGLAND_TEMPLATES_DIR` is set.
-
-### Delegate: subfolders and conflict policy
-
-- `files.moveFromStaging` (Go: `delegate.MoveParams.Name`) accepts folders
-  below the destination, for example `Album/CD1/01.flac`. The executor's move
-  child creates missing folders as the user, after the final revoke check, so
-  a canceled move leaves none behind. Existing folders are reused. Limits: 16
-  folders, 255 bytes per name, 1024 bytes in total. A name without folders
-  behaves exactly as before.
-- New `conflict` field for `files.moveFromStaging` and the time-limited
-  `files.write`: `fail` (default, unchanged), `overwrite` (atomic replace of a
-  regular file the user can write) or `rename` (`name (1).ext` up to
-  `name (99).ext`; the receipt path reports the name used).
-- New error codes: `invalid-path`, `path-too-deep`,
-  `destination-not-directory`, `name-too-long`.
-
-### Delegate: file operations for time-limited grants
-
-- New operations `files.read`, `files.rename`, `files.copy`, `files.move` and
-  `files.delete`, each declared on its own; a write operation never implies
-  delete. Go: `job.Files()` returns `delegate.JobFiles` with `Read`, `Rename`,
-  `CreateFolderAll`, `Copy`, `Move`, `Delete`, `TaskStatus` and `CancelTask`.
-- `files.createFolder` takes `parents` (`CreateFolderAll`, like `mkdir -p`).
-- Except `files.write` and `files.read`, the executor calls File Station as the
-  user through one root-side allowlist of methods, and re-checks the paths File
-  Station reports against the grant. `files.read` copies the file into staging
-  in a child that drops to the user and never follows symlinks.
-- Copy, move and delete run as File Station background tasks followed with the
-  implied `files.taskStatus` and `files.taskCancel`; revoking the grant stops
-  them. Delete needs `recursive` for folders and goes to the recycle bin; a
-  Shared Folder without one needs `permanent`.
-- File Station refusals now report SDK codes (`PERMISSION_DENIED`,
-  `not-found`, `destination-exists`, `NO_SPACE`, `invalid-path`,
-  `name-too-long`) instead of `DSM_FAILED`. New codes: `not-a-file`,
-  `recursive-required`, `recycle-bin-disabled`, `task-not-found`,
-  `too-many-tasks`, `READ_FAILED`.
-
-### Approval
-
-- An administrator approves the executor policy (operations, scope and root
-  tasks), not the executor binary. When an upgrade keeps the policy and the
-  new executor matches the `INFO` anchor, it installs without a new approval.
-  When the policy changes, the App stays at `needs-admin-approval` until an
-  administrator approves again.
-- The 0.9.0 policy changes (new operations and `conflict`), so a delegate App
-  rebuilt with this CLI needs one new approval after the upgrade.
-  Moving the SDK to its own repository does not add one. Apps not rebuilt are
-  not affected.
-
-## 0.8.0 (2026-10-11)
-
-Faster builds, one SPK checker for any package, and a guide for scripts and
-interpreted languages. `validate` is merged into `inspect`.
-
-繁中摘要：toolkit 改用使用者層級共用快取；新增 `build --jobs` 多架構並行與
-`build --verify-reproducible` 可重現檢查（可用依賴指紋略過）；`inspect` 對任何
-SPK 檢查 DSM 7 格式，synopkgland 建置的 SPK 另查建置合約；native layout 的
-aarch64 INFO arch 改寫機型清單、拒絕無執行權限的 script、toolkit 可用 GNU tar
-或 bsdtar 解開；新增腳本／直譯語言打包指南。無圖示的 native layout SPK 現在會
-因 `SPK_ICON_MISSING` 無法通過 inspect。
-
-### Shared toolkit cache
-
-- Native layout toolkit archives now default to one per-user cache shared by
-  every project and worktree: `$XDG_CACHE_HOME/synopkgland` or
-  `~/.cache/synopkgland` on Linux, `~/Library/Caches/synopkgland` on macOS.
-  `SYNOPKGLAND_CACHE_DIR` still overrides it. The project's
-  `.synopkgland-cache` folder is no longer used by default; delete it or point
-  `SYNOPKGLAND_CACHE_DIR` at it. The private-folder and `sha256` checks are
-  unchanged, and concurrent builds may share the cache.
-
-### Parallel architecture builds
-
-- `synopkgland build --jobs <n>` builds up to `n` architectures at the same
-  time for native-go, binary, native layout and Compose gateway projects. The
-  default stays `1`. Output files and names are byte-identical to a sequential
-  build; with `n` above 1 each output line is prefixed with its architecture.
-- SPK files now reach the output folder only after every architecture
-  succeeds, also with `--jobs 1`. A failed architecture is named in the error,
-  for example `[aarch64]`, and no SPK from that build is written. Before, the
-  architectures built before the failure stayed in `dist/`.
-- Native layout compile hooks get `SYNOPKGLAND_WORK_DIR`, an empty scratch
-  folder per architecture. `--jobs` above 1 requires `layout.payload` to
-  contain `{arch}`. Architectures that pin the same toolkit archive download it
-  once.
-- New error code `CLI_JOBS_INVALID`.
-
-### Reproducible build check
-
-- `synopkgland build --verify-reproducible [changed|always]` keeps this
-  build's SPKs as the first round, builds once more into a temporary folder
-  with an empty `GOCACHE` after removing the manifest's `reproducible.clean`
-  paths, and fails with `BUILD_NOT_REPRODUCIBLE` listing the payload and
-  metadata files that differ. Works for every project type.
-- New optional manifest block `reproducible: {inputs, clean}` in
-  `dsm-package.yaml` (native-go, binary, native layout) and
-  `synology-app.yaml`. The SHA-256 of the `inputs` files, the CLI version and
-  native layout toolkit pins form a dependency fingerprint. A passing check
-  writes it to `reproducible-fingerprint.json`; `changed` (the default) skips
-  the second build while it is unchanged. New error code
-  `REPRODUCIBLE_INVALID`.
-
-### `inspect` checks any SPK
-
-- `synopkgland inspect <spk>` now checks any SPK against the DSM 7 package
-  format, whether `synopkgland` built it or not, without installing it: the
-  outer archive, `INFO` fields, formats and `checksum`, path and link safety in
-  `package.tgz`, `ui/config` JSON and its `"texts"` declaration, ELF files
-  against `arch` (none in `noarch`), lifecycle scripts and their execute bit,
-  `conf/privilege` and `conf/resource`, icons, `LICENSE`, wizards and
-  `syno_signature.asc`. Every finding has a stable `SPK_*` code listed in the
-  errors reference.
-- Only an SPK that `synopkgland` built (top-level `sdk-package.json` or
-  `native-layout.json`, or `synology-app.yaml` in the payload) is also checked
-  against the build contract. Other SPKs are no longer rejected by it.
-- The output has a DSM format section and, for `synopkgland` SPKs, a
-  `synopkgland` contract section. An error in either exits 1 with
-  `SPK_INSPECTION_FAILED`; warnings alone exit 0. `--json` keeps every earlier
-  field and adds `synopkgland` (boolean) and `dsm: {ok, errors, warnings}`.
-- There is no `validate` command; the DSM rules it had during 0.8.0
-  development are part of `inspect`. The project check is `check`.
-
-### Native layout fixes
-
-- `arches: [aarch64]` now writes the same `INFO` `arch` as native-go and
-  binary (`armada37xx rtd1296 rtd1619 rtd1619b`) instead of `aarch64`, which
-  the Developer Guide arch table does not list.
-- `build` refuses a lifecycle or replace script in `layout.metadata` without
-  the execute bit with `NATIVE_LAYOUT_SCRIPT_NOT_EXECUTABLE`; run `chmod +x`.
-  Before, the SPK was built and DSM could not run the script.
-- `native.toolkits` archives extract with GNU tar and with bsdtar (the macOS
-  default). Other tar programs fail with `NATIVE_TOOLKIT_TAR_UNSUPPORTED`.
-  Members with absolute or `..` paths are refused.
-
-### Scripts and interpreted languages guide
-
-- New guide: package a shell, Node.js, Python, Bun or Deno program by
-  compiling it to one executable, bundling the interpreter through
-  `native.toolkits`, or running it in a Compose container, with measured sizes,
-  architectures and glibc needs, and a hand-packed `noarch` shell SPK. The CLI
-  cannot declare `install_dep_packages` for Package Center's Node.js or Python
-  packages; the guide says so.
-
-### 繁體中文摘要
-
-- `synopkgland build --jobs <n>` 可同時建置多個架構（native-go、binary、native layout、
-  Compose gateway），預設仍為 1；產出與依序建置逐位元組相同。所有架構成功後才寫入
-  SPK，失敗時錯誤標明架構且不寫入任何 SPK。native layout hook 新增
-  `SYNOPKGLAND_WORK_DIR`；`--jobs` 大於 1 時 `layout.payload` 必須含 `{arch}`。
-- `synopkgland build --verify-reproducible` 以這次建置為第一輪、從乾淨狀態再建一次比對，
-  不同時列出 payload 檔案並以 `BUILD_NOT_REPRODUCIBLE` 失敗。manifest 新增
-  `reproducible: {inputs, clean}`；依賴指紋未變時略過（記錄在
-  `reproducible-fingerprint.json`）。
-- native layout 的 toolkit 快取預設改為每位使用者一份、所有專案與 worktree 共用
-  （Linux `$XDG_CACHE_HOME/synopkgland` 或 `~/.cache/synopkgland`，macOS
-  `~/Library/Caches/synopkgland`）；`SYNOPKGLAND_CACHE_DIR` 仍可覆寫。專案內的
-  `.synopkgland-cache` 不再預設使用。
-- `synopkgland inspect <spk>` 改為不安裝、依 DSM 7 套件格式檢查任何 SPK（不限本 CLI 建置），
-  涵蓋外層封存、`INFO` 欄位與 `checksum`、`package.tgz` 路徑與連結安全、`ui/config` 的
-  `"texts"`、ELF 與 `arch`（`noarch` 不得有 ELF）、生命週期指令碼與執行權限、`conf/privilege`
-  與 `conf/resource`、圖示、`LICENSE`、精靈與簽章。每個問題有固定 `SPK_*` 代碼，列在錯誤碼參考。
-- 只有 `synopkgland` 建置的 SPK（最上層有 `sdk-package.json` 或 `native-layout.json`，或 payload
-  有 `synology-app.yaml`）另查建置合約；其他 SPK 不再因合約被拒。任一區段有錯誤時以
-  `SPK_INSPECTION_FAILED` 結束碼 1 失敗，只有警告時結束碼 0。`--json` 保留原有欄位，新增
-  `synopkgland` 與 `dsm: {ok, errors, warnings}`。
-- 沒有 `validate` 指令；0.8.0 開發期間的 DSM 規則已併入 `inspect`。專案檢查請用 `check`。
-- native layout 以 `arches: [aarch64]` 建置時，INFO `arch` 改為與 native-go／binary 相同的
-  `armada37xx rtd1296 rtd1619 rtd1619b`。`layout.metadata` 的指令碼沒有執行權限時 `build` 以
-  `NATIVE_LAYOUT_SCRIPT_NOT_EXECUTABLE` 拒絕，請 `chmod +x`。`native.toolkits` 可用 GNU tar 與
-  bsdtar 解壓，其他 tar 以 `NATIVE_TOOLKIT_TAR_UNSUPPORTED` 失敗。
-- 新增「封裝指令碼與直譯式語言」指南：編譯成單一執行檔、經 `native.toolkits` 附帶直譯器、或以
-  Compose 容器執行，附實測大小、架構與 glibc 需求，以及手動打包的 `noarch` shell SPK。CLI 無法宣告
-  `install_dep_packages` 依賴套件中心的 Node.js／Python 套件，指南已明確說明。
-
-## 0.7.3 (2026-10-11)
-
-Rebuild every package built with 0.7.2 that has `i18n.info` translations. In
-0.7.2 its DSM main-menu entry, desktop shortcut and window title showed the raw
-key `synopkgland:app_title` in every language.
-
-### Translated DSM title fix
-
-- `ui/config` entries that use the `synopkgland:app_title` and `app_desc`
-  strings now declare `"texts": "texts"`: the main-menu `app` entry, its window
-  `lib` entry and the `.url` entry of a `synology-app.yaml` app. DSM loads
-  `ui/texts/<DSM language>/strings` only for entries that declare `texts`, so
-  0.7.2 titles never resolved (seen on DSM 7.4 and 7.1.1). Without `i18n.info`
-  `ui/config` is unchanged.
-
-### Correction to 0.7.2
-
-- 0.7.2 said `synology-app.yaml` `i18n.info` localizes the DSM window title.
-  It localizes the DSM main-menu and desktop label only. `launch: dsm-window`
-  adds a main-menu and desktop entry that DSM always opens in a new browser
-  tab, as it does for every URL entry; the app has no DSM window and no window
-  title. This is not caused by DSM's CSRF protection setting. The container app
-  guide and the `synology-app.yaml` reference now say so.
-
-### 繁體中文摘要
-
-- 修正 0.7.2 的在地化標題：有 `i18n.info` 翻譯時，`ui/config` 中使用 `synopkgland:` 字串的
-  `app`、`lib` 與 `.url` 項目都加上 `"texts": "texts"`。0.7.2 少了這個欄位，DSM 不會載入
-  `ui/texts/<語言>/strings`，主選單、桌面捷徑與視窗標題在各語言都顯示 `synopkgland:app_title`。
-- 用 0.7.2 建置且含 `i18n.info` 的套件，請以 0.7.3 重新建置並遞增 build 後重新發佈；沒有
-  `i18n.info` 的套件不受影響。
-- 更正 0.7.2：`synology-app.yaml` 的 `i18n.info` 只翻譯 DSM 主選單與桌面標籤，沒有視窗標題。
-  `launch: dsm-window` 的項目一律由 DSM 在新的瀏覽器分頁開啟（DSM 對所有網址項目都如此），
-  與 CSRF 防護設定無關；容器 App 指南與 `synology-app.yaml` 參考已更正。
-
-## 0.7.2 (2026-10-11)
-
-Rebuild packages to pick up the new default icon. Packages without `icon` now
-show the SDK default icon instead of a solid blue square.
-
-### Package icon
-
-- `dsm-package.yaml` and `synology-app.yaml` accept `icon`: a square PNG of at
-  least 256×256 inside the project, or a folder of `icon_<size>.png` (16, 24,
-  32, 48, 64, 72, 256; `icon_256.png` required, missing sizes scaled from it).
-  `build` writes `PACKAGE_ICON.PNG` (64×64), `PACKAGE_ICON_256.PNG` and every
-  DSM window size `ui/images/app_<size>.png` from it. SVG is not accepted, so
-  the CLI gains no image dependency. `check` refuses an icon outside the
-  project, a non-PNG, a non-square or smaller image, and one whose Package
-  Center icons exceed the package source's 256 KiB limit
-  (`STANDALONE_ICON_INVALID`, `CONTRACT_ICON_INVALID`).
-
-- A native layout may set `icon` too; `build` then writes both Package Center
-  icons and refuses a metadata folder that also ships them. Without `icon` the
-  layout keeps owning its icons.
-
-- `check` reports which icon a build uses: `圖示：自訂 <path>`, or `圖示：SDK
-  預設圖示` with an info hint about `icon:` (not an error). It warns when an
-  icon is a single colour. `check --json` reports it in `data.icon`.
-
-- `inspect` reports `icon` as `default`, `custom` (with the SHA-256 of
-  `PACKAGE_ICON_256.PNG`) or `none`, and lists a Package Center icon over
-  256 KiB, of the wrong size or not a PNG as a finding.
-
-- The SDK default icon replaces the solid blue square in Package Center, the
-  DSM main menu and the window. Sources are in `assets/default-icon/`.
-
-### Translated DSM title
-
-- With `i18n.info` translations, the DSM main-menu entry and window title
-  follow the DSM language. `ui/config` refers to `synopkgland:app_title` and
-  `app_desc` in `ui/texts/<DSM language>/strings`, written for English and each
-  translated language; a language without its own text shows the English one.
-  Without translations `ui/config` keeps the literal English title.
-
-- `synology-app.yaml` accepts the same `i18n.info` block. It writes INFO
-  `displayname_<lang>` / `description_<lang>` and, with `launch: dsm-window`,
-  localizes the DSM window entry. Once a translation exists, the English
-  `displayname` and `description` must also be one line without `"` or `\`
-  (`CONTRACT_I18N_INVALID`).
-
-### Delegate window
-
-- A DSM window built for a `scope: install-selected` delegate no longer
-  contains the dead `if (panels && false)` check. The window leaves out the
-  approval panel code instead, and other scopes generate `if (panels)`. The
-  behavior is unchanged: this scope is approved only in the app's
-  **Administrator setup** panel, because that approval carries the scope the
-  administrator picks and the window panel has no scope picker. The delegate
-  guide now says so.
-
-### 繁體中文摘要
-
-- 升級後重新建置套件即可換上新的 SDK 預設圖示（不再是純藍方塊）。executor digest 不變，不需重新核准。
-- `dsm-package.yaml`、`synology-app.yaml` 與 native layout 新增 `icon`：專案內至少 256×256 的正方形
-  PNG，或含 `icon_256.png` 的 `icon_<size>.png` 目錄；不接受 SVG。`check` 顯示使用的圖示並檢查格式與
-  256 KiB 上限，`inspect` 回報 `default`／`custom`／`none`。
-- 有 `i18n.info` 翻譯時，DSM 主選單與視窗標題會跟著 DSM 語言切換；缺翻譯的語言顯示英文。
-  `synology-app.yaml` 也支援 `i18n.info`。
-- `scope: install-selected` 的 DSM 視窗不再產生 `if (panels && false)` 死碼；此 scope 仍只在 App 的
-  「管理員設定」核准。
-
-## 0.7.1 (2026-10-10)
-
-Rebuild packages to pick up template, hook and executor changes. The executor
-digest changed. A package built with CLI 0.7.0 needs one administrator approval
-after upgrading to a 0.7.1 build: the 0.7.0 executor opened the package
-`target` link without following it, so it cannot install the anchored executor
-itself. Executor-only upgrades between 0.7.1 or later builds need no approval.
-
-### Executor upgrade and daemon timeouts
-
-- During an INFO-anchored executor-only upgrade the executor log said
-  `executor paused: package pins require administrator approval` about two
-  seconds before the new executor was ready. That line now appears only when
-  the pins differ; an anchored handover logs only `executor upgrade:
-  INFO-anchored executor installed under the approved policy`. The executor
-  digest changes.
-
-- `executor_status_mismatch` in the app window and the app's settings names
-  its cause: `the approved executor is not answering (<reason>)`, `the running
-  executor reports other digests than this package pins`, or `the executor
-  status request failed` with the request's own code, instead of `scheduler
-  readback or operation failed` for all three. The Data and removal
-  troubleshooting table explains each.
-
-- After approval or control start the window asked `executor.status` every
-  500 ms for up to 10 s. The wait now doubles from 500 ms to 2 s within the
-  same 10 s budget: at most 7 requests instead of 20.
-
-- For live upgrade tests, the repository's `scripts/test/executor-bump.py`
-  makes an executor-only build+1 SPK and now rewrites the window script's
-  embedded pins with the INFO anchor and `executor/setup.json`. The earlier
-  out-of-tree copy left the window pins behind, so the panel reported
-  `executor_status_mismatch` after every such upgrade while CGI and CLI
-  status were ready.
-
-- On kernel 3.10 (DSM 7.1, for example DS416 armv7) an executor-only
-  upgrade, and approving again while the executor runs, no longer fail
-  with "pid executable mismatch". That kernel names a running executor
-  replaced by a rename after the rename source (`runtime/.executor
-  (deleted)`), and root control accepted only `runtime/executor`. Root
-  control now identifies the monitor by inode: the current
-  `runtime/executor`, or an unlinked root-owned inode on the runtime's
-  device whose last name was `executor` or `.executor*` in the runtime.
-  The fix runs in the new executor, which the installed one starts: an
-  upgrade from a package built with the target-link fix below needs no
-  approval; from 0.7.0 it still needs the one approval described there.
-  The executor digest changes.
-
-- When the approved tasks are ready but the executor does not answer
-  (`executor_status_mismatch`), the app window offers Approve background
-  access again. With the tasks approved, it restarts the executor without
-  a password.
-
-- `executor.status` (root-ops) names approval, not "Start the package", as
-  the next step when the package's last lifecycle request was start.
-  Regenerate or copy `backend/internal/app/executor.go`.
-
-- An executor-only upgrade (same policy, new executor matching the INFO
-  `synopkgland_executor_sha256` anchor) no longer fails with "executor
-  upgrade refused: INFO-anchored executor could not be installed". The
-  installer opened `/var/packages/<pkg>/target/executor` without following
-  the DSM `target` link, which the executor refuses, so every such upgrade
-  stayed paused. The fix runs in the executor that is already installed:
-  an upgrade from a package built with an earlier SDK still needs one
-  administrator approval. The executor digest changes.
-
-- `executor.status` (root-ops and delegate projects) no longer answers
-  `internal` while the executor is paused (package stopped, or pins waiting
-  for approval). It answers `{ready: false, state: "paused", reason:
-  "executor_not_listening", next}`, and `synopkgland status` shows the
-  reason and next step. Regenerate or copy
-  `backend/internal/app/executor.go` into existing projects.
-
-- `daemon.timeouts` defaults are now `{start: 30, stop: 30, status: 5,
-  uninstall: 60}` (were `start: 5, stop: 10, status: 2`). On vt-nas under
-  IO load a boot start took more than 5 s and a Connect revoke more than
-  9 s. The new `timeouts.uninstall` (2–120) bounds `uninstall_args`
-  separately; it used to get `stop - 1`, so an app had to raise the SIGKILL
-  wait to give its revoke time. DSM's package unit allows 3600 s for start
-  and stop. `inspect` still accepts SPKs built before `timeouts.uninstall`.
-  The manifest reference explains how to pick values from a loaded NAS.
-
-### Approval, identity and uninstall fixes
-
-- `identity: standalone`: "Continue with DSM" and every live revalidation
-  failed with `session_required` after a DSM web login, because DSM web
-  sessions enable SynoToken and DSM answers the `id` cookie alone with 119.
-  The backend now forwards the request's single `X-SYNO-TOKEN` header, which
-  the DSM window's `ctx.call` already sends, when it checks the DSM session.
-  Sessions without SynoToken still verify with the cookie alone. The token is
-  never put in a URL, logged or stored. This also unblocks root-ops approval
-  in an `identity: standalone` package, which stopped at `executor.control`.
-  Existing projects need the updated `internal/identity` files.
-- When approval created and read back both tasks but the executor then did
-  not start or report healthy, the window left the tasks behind, and with no
-  running executor there was no task inventory for uninstall to delete them.
-  The window now withdraws the tasks that approval created; tasks from an
-  earlier approval stay.
-- After a wrong password or a withdrawn approval, the window panel showed
-  only "Check status". It and the app's settings now keep the approve action.
-- Uninstall no longer logs `task cleanup unconfirmed` for every successful
-  delete: EventScheduler `delete` v1 and TaskScheduler `delete` v2 answer
-  `{"success":true}` without data, which now counts as confirmed. The task
-  definitions are unchanged, so no new approval is needed; the executor
-  digest changes.
-- The native root window (`@synopackageland/cli/authorization-sdk`) gave up
-  after about 30 s with `root_timeout`, while a loaded NAS ran the bootstrap
-  task for up to 4.5 minutes. It now keeps waiting while the task is queued or
-  running, up to 10 minutes, reports `{op, state, elapsedMs}` through
-  `options.progress`, and the authorization flow accepts the backend's ready
-  grant after `root_timeout` or `root_task_failed`.
-- A DSM certificate that Node does not trust failed with only
-  `fetch failed`. The CLI now reports `DSM_TLS_UNTRUSTED` with the origin and
-  certificate error and points to `NODE_EXTRA_CA_CERTS`; certificate checks
-  stay on.
-- Docs: on DSM 7.1 the purge timing lines are only in the journal
-  (`journalctl -t synopkgland-executor`); `init -t native-go` does not include
-  `armv7` in `arches`, so add it for an armv7 NAS.
-
-### Deploy and status fixes
-
-- `status` no longer reports `blocked` for every `identity: standalone`
-  project. It opens a short-lived App session from the administrator's DSM
-  session, reads `executor.status`, then logs out. That needs an `https://`
-  host; over `http://` the capability stays `blocked` and the reason says so.
-- `deploy` accepts the install wizard values of an `install-selected`
-  delegate: `--param delegate_share=<Shared Folder>` or
-  `--param delegate_home=true`. A first install without one now fails with
-  `DEPLOY_PARAM_REQUIRED` and a usage line before anything is built, instead
-  of failing inside DSM. Invalid values fail with `DEPLOY_PARAM_TYPE_INVALID`.
-- `deploy` and `status` work on a native layout (existing native product).
-  `deploy` builds the NAS architecture only; an `aarch64` NAS uses a declared
-  `armv8`.
-- The deploy note no longer says every upgrade needs approval: an
-  executor-only upgrade stays ready; a policy digest change needs approval.
-- Uninstall logs per-phase purge timing with the package name to the system
-  log (`synopkgland-executor`): `task cleanup timing` per task and
-  `purge timing` for the task and file phases. The executor digest changes.
-- `add root-ops` and `add portal` print a notice on stderr when they raise
-  `os_min_ver`.
-- `inspect` on an executor SPK describes the root boot and control tasks
-  instead of saying the package needs no root privileges.
-
-### DSM 7.1: root-ops and delegate approval work
-
-- DSM 7.1.1 has no `SYNO.Core.TaskScheduler.Root` or
-  `SYNO.Core.EventScheduler.Root`, TaskScheduler stops at v3 and
-  PasswordConfirm at v1, so approval failed with "Background file access is
-  unavailable" and `status`/`deploy` showed `rootOps: unsupported — DSM 103`
-  or `DSM 104`. DSM 7.1.1 answers a version above the API's maximum with 104
-  (PasswordConfirm v2, TaskScheduler `get` v4) and a method missing at an
-  existing version with 103 (TaskScheduler `list` v3). When DSM answers a
-  scheduler read or the password check with 103 or 104, the app now uses
-  PasswordConfirm v1, TaskScheduler `list` v2/`get` v3 and creates
-  the tasks with EventScheduler `create` v1 and TaskScheduler `create` v3.
-  The password is still confirmed first and both tasks are still read back
-  exactly before anything runs. Other errors (such as 105, 119, 102 or a
-  wrong password, 3121) never fall back, and a create is never retried. DSM
-  7.1 does not bind task creation to the password check; see the root-ops
-  guide.
-- `status` and `deploy` read the control task the same way.
-- Uninstall on DSM 7.1 now removes the boot and control tasks. The executor
-  looked the control task up with TaskScheduler `get` v4, which DSM 7.1.1
-  refuses with 104, so it wrote no task inventory and left both tasks behind.
-- If approval stops after it created a task (for example, the boot task was
-  created and the control task was not), the app deletes the tasks it created
-  in that attempt instead of leaving an enabled root boot task that nothing
-  owns. Tasks from an earlier approval stay.
-- A failed approval shows its reason and DSM error code in the app's settings
-  instead of only "Background file access is unavailable", and a refused
-  password reads as a password failure, not a scheduler failure.
-- After the app's settings approve, the window's status line no longer shows
-  "needs-admin-approval: Task is missing" until a reload; the window panel and
-  the settings now follow each other's results.
-
-### DSM 7.1: jobs import and file downloads
-
-- DSM 7.1.1 sends `SYNO.FileStation.Download` v2 replies without
-  `Content-Disposition`, so `bg.jobs.submit` and downloads failed with
-  `unavailable`. With no such header, a body of at most 4 KiB that decodes
-  as a DSM reply is still refused as that reply; any other body is the file.
-
-### Docs: build your own armv7 Go code with Go 1.26.9
-
-- On armv7 DSM 7.1.1 (kernel 3.10), a program built with Go 1.26.0 crashed
-  at start (`futexwakeup returned -22`, SIGSEGV) and Go 1.26.9 ran. Other
-  1.26 releases were not tested.
-
-### init: next steps install frontend dependencies
-
-- `init -t native-go` with a Vue frontend now lists `(cd frontend && npm ci)`
-  before `synopkgland build`; without it the build fails with
-  `STANDALONE_UI_BUILD_FAILED`. `build` still does not install dependencies.
-
-### Executor, daemon and gateway build with exactly Go 1.26.9
-
-- The CLI builds the executor, lifecycle helper, daemon controller and gateway
-  with `GOTOOLCHAIN=go1.26.9`, ignoring your `GOTOOLCHAIN`, `GOFLAGS`,
-  `GOEXPERIMENT`, `GOWORK` and `GOAMD64`/`GOARM64`, so every builder produces
-  the same executor digest. Go 1.21 or later downloads go1.26.9 when needed;
-  offline without it the build fails and names go1.26.9. A binary whose Go
-  build info names another release is refused.
-- Template go.mod files now say `toolchain go1.26.9`. The executor digest
-  changes; it is anchored in INFO, so an upgrade with an unchanged policy needs
-  no new approval.
-
-### INFO arch: four more DSM platforms
-
-- x86_64 SPKs now also list `broadwellntb`, `coffeelake` and `skylaked`, and
-  aarch64 SPKs list `rtd1619` (DSM Developer Guide Appendix A family members).
-  INFO `arch` now matches the platforms the package source maps to each family.
-
-### 繁體中文摘要
-
-- 升級後重新建置套件；executor digest 改變。**從 0.7.0 建的套件升級需管理員再核准一次**（0.7.0 的
-  executor 開啟套件 `target` symlink 時未跟隨連結，無法自行安裝錨定的 executor）；之後 0.7.1 起的
-  executor-only 升級不需核准。
-- executor：kernel 3.10（DSM 7.1，如 DS416 armv7）上 executor-only 升級與執行中再核准不再出現
-  `pid executable mismatch`；INFO 錨定升級不再誤報 `executor upgrade refused`，也不再先印
-  「paused: 需管理員核准」；`executor.status` 暫停時回 `paused`／`executor_not_listening` 與下一步。
-- 面板：executor 不回應時可再按一次「Approve background access」免密碼重啟；
-  `executor_status_mismatch` 會寫出原因（不回應／digest 不同／status 請求失敗）；
-  啟動後的 `executor.status` 等待改為 500 ms→2 s 退避，10 s 預算不變。
-- `daemon.timeouts` 預設改為 `{start: 30, stop: 30, status: 5, uninstall: 60}`，新增 `timeouts.uninstall`。
-- `identity: standalone`：DSM 網頁 session（SynoToken）下「Continue with DSM」與 root-ops 核准修正；
-  核准建立 task 後 executor 未啟動時自動撤回本次建立的 task；卸載不再誤記 `task cleanup unconfirmed`。
-- 原生 root window 等待上限改為 10 分鐘並回報進度；`DSM_TLS_UNTRUSTED` 指向 `NODE_EXTRA_CA_CERTS`。
-- `status`／`deploy`：standalone 專案的 status 改用短期 App session；`deploy` 接受
-  install-selected delegate 的精靈參數；支援 native layout；卸載記錄 purge timing。
-- DSM 7.1：無 Root API 時改走 PasswordConfirm v1／TaskScheduler v2–v3／EventScheduler create v1，
-  卸載會移除 boot／control task；`SYNO.FileStation.Download` v2 無 `Content-Disposition` 的下載修正。
-- 建置：executor、lifecycle、daemon、gateway 一律以 Go 1.26.9 建置（armv7 kernel 3.10 上 1.26.0 會當機）；
-  INFO `arch` 新增 `broadwellntb`、`coffeelake`、`skylaked`、`rtd1619`。
-- 測試工具：`scripts/test/executor-bump.py` 收進 repo，會一併改寫視窗腳本內嵌的 executor pin。
-
-## 0.7.0 (2026-10-10)
-
-Rebuild packages to pick up template, hook and executor changes. The executor
-digest changed: apps approved under an earlier CLI need one administrator
-approval after upgrading.
-
-### Delegate: save destinations that last until revoked
-
-- `init --with delegate` / `add delegate` now declare `operations:
-  [files.moveFromStaging]`, `destinations: [save]`, `lifetime: until-revoked`,
-  `scope: install-selected`. Existing TTL declarations (`files.list` …
-  `files.write`, `scope: home`) keep their API and limits.
-- The install wizard pre-selects home or a local share and an administrator
-  confirms it once. Choosing a destination in the SDK NasPicker grants it until
-  revoked, after fresh DSM session, UID and write checks; administrators run as
-  their own UID, never root. Read the choice from `delegate.status`
-  `selection`, `sdk.destination(key)` or Go `Service.Destination`.
-- Daemon and export producers save through Go `Service.MoveFromStaging`. The
-  generated Background saves page (`createBackgroundSaveFacade`) lists, cancels
-  and revokes them and includes a working example (`ExportExample`). Daemon can
-  combine with an until-revoked delegate worker.
-- Retrying `MoveFromStaging` with the same params never copies twice. Journal
-  errors `canceled`, `jobs_busy` and `jobs_unavailable` are retryable;
-  `spool_unsafe` and `journal_corrupt` are terminal.
-- Cancel is idempotent per reference and survives executor crash, package
-  restart and logout. Revoke, scope change and disable settle copies in flight
-  as `canceled` with that reason (for example `scope-changed`); a scope change
-  no longer restarts the executor. Poll `ctx.executor.status()` while a change
-  answers `blocked`.
-- Full device lifecycle acceptance (install → setup → reboot → upgrade → revoke
-  → uninstall) is still pending.
-
-### Executor
-
-- Upgrades keep approval: each SPK writes its executor SHA-256 into INFO
-  (`synopkgland_executor_sha256`), and a new executor that matches it installs
-  without PasswordConfirm as long as the policy is unchanged. Policy changes
-  (operations, scope, destinations, root scripts) still need approval. `inspect`
-  refuses a missing, duplicated or different anchor.
-- A root supervisor restarts the monitor after a crash or kill (1–60 s
-  backoff), so delegate and rootOps recover without a reboot.
-- Every write publishes only through the executor handshake. A copy whose
-  executor died stops within 1 MiB and removes its `.part`; a lost publish
-  receipt settles `committed` without copying again.
-- A package without an executor can add one in place on upgrade. Upgrade does
-  not approve an install-selected scope; confirm it in Settings.
-- Uninstalling a stopped package no longer leaves root tasks and the monitor
-  running for ten minutes; the hook waits at most 50 s for the executor to clean
-  up.
-
-### Native layout: per-architecture INFO trust anchors
-
-- `layout.anchors` maps `<key>_sha256` to a payload file. `build` writes that
-  architecture's SHA-256 of the file into INFO, so a product root helper can
-  trust a new build through the root-owned INFO instead of reapproval. Keys
-  match `^[a-z][a-z0-9_]{0,48}_sha256$`, the `synopkgland_` prefix is reserved,
-  and at most 16 are allowed. `inspect` refuses a changed, duplicated, missing
-  or undeclared anchor.
-
-### App entry and Application Privileges
-
-- `entry: admin-only` admits administrators only, on every route including the
-  SDK routes; ordinary users get `admin_required`. `entry: app-privilege`
-  registers the app in Control Panel > Application Privileges and gates every
-  route on DSM's decision (`app_privilege_denied`). Omitting `entry` keeps the
-  previous behaviour and byte-identical SPKs.
-- With an `entry`, an app route marked `authenticated` or `public` fails with
-  `STANDALONE_ENTRY_WIDENED`. `inspect` prints the entry mode and flags
-  `ENTRY_LAUNCHER_MISMATCH`.
-- The executor applies the same rule: moves for a user DSM no longer allows are
-  refused (`APP_DENIED`).
-- `ctx.user = {name, isAdmin}` lets UIs hide administrator settings; guard them
-  on the server with Go `api.RequireAdmin(caller)`.
-- On Linux 3.10 kernels without `memfd_create` (DSM 7 on x86_64 avoton,
-  braswell, bromolow, grantley) the administrator and App Privileges bridges run
-  from an unlinked file in the package's own tmp instead of failing. That path
-  has no memfd seal. Verified on DSM 7.1.1 with an armv7 build only; no x86_64
-  Linux 3.10 model has been tested.
-
-### Application Portal
-
-- `portal: {}` or `portal: {alias}` (native) and `integration.web.portal`
-  (Compose DSM-window apps); `synopkgland add portal` adds it. The install
-  wizard prefills the alias, upgrades keep it and an administrator activates it.
-- `ctx.portal.mountPanel(element)` shows the link, or the alias form to
-  administrators; the Vue and plain starters mount it.
-- A portal needs `os_min_ver` 7.3.2-86009 or later (DSM 7.1.1 rejects it with
-  error 320; 7.2 is untested). validate/build fail with
-  `STANDALONE_PORTAL_MIN_DSM` / `CONTRACT_PORTAL_MIN_DSM`, and `add portal`
-  raises a lower `os_min_ver`.
-
-### Catalog metadata
-
-- An optional `metadata:` block (contact/support email, homepage, source and
-  issues URLs, license, localized long description, changelog, screenshots) is
-  validated and written to INFO for the package catalog.
-- `metadata.changelog` may be a per-language map. Package Center shows one line
-  in the NAS language, so put the most important change first.
-
-### Native authorization
-
-- `authorization_required` gains `reason: upgrade_reapproval` when an upgrade
-  revoked the old grant; the Gate template explains the next step in nine
-  languages. Products that sync the Gate need their helper to write and clear
-  the reason-only tombstone, which grants nothing.
-
-### Lifecycle
-
-- Background packages restart a package user systemd manager that lost its
-  runtime socket; a failed worker start names the unit, exit code and socket
-  state.
-- Stopping the worker is idempotent, fixing uninstall failure 314 for
-  delegate+daemon+jobs.
-
-### Templates in nine languages
-
-- All template UI text and install, upgrade and uninstall wizard messages come
-  from catalogs in the nine DSM languages and follow DSM glossary wording. Sizes
-  use DSM's 1024-based KB/MB/GB. Rebuilt Vue and binary SPKs change bytes;
-  plain-UI SPKs are unchanged.
-- Vue templates pin public `@synopackageland/ui@0.8.1`; the upload FilePicker
-  states `max 16 GB`.
-
-### armv7 (32-bit ARM) for native-go and binary packages
-
-- `arches` accepts `armv7` (INFO `alpine alpine4k armada38x monaco`, DSM 7.2+);
-  the default stays `[x86_64, aarch64]`. It covers the Go CGI (plain or Vue UI),
-  `backend.kind: binary`, jobs, daemon, root-ops and delegate. Container
-  projects refuse it with `CONTAINER_ARCH_UNSUPPORTED`.
-- The plain native-go CGI was verified on a DS416 (DSM 7.1.1, `alpine4k`).
-  armv7 jobs, daemon, executor and lifecycle helper are built and checked but
-  not yet verified on a NAS; `armada38x` and `monaco` are untested.
-- `deploy` detects armv7 from an Annapurna Labs CPU and asks for `--arch` on a
-  Marvell CPU. x86_64 and aarch64 bridge, executor and lifecycle bytes are
-  unchanged by the armv7 work.
-
-### Packaging
-
-- The npm tarball includes this CHANGELOG.md.
-
-### 繁體中文摘要
-
-- 升級後重新建置套件；executor digest 改變，舊版 CLI 核准過的 app 需要管理員再核准一次。
-- delegate：預設改為長期存檔目的地（`files.moveFromStaging`、安裝時選 scope、管理員確認一次、
-  在 NasPicker 選目的地即授權至撤銷）；Background saves 頁、`MoveFromStaging` 重送不重複複製、
-  取消跨重啟保留。完整裝置生命週期驗收仍待完成。
-- executor：INFO 錨定 executor SHA-256，policy 不變的升級免再核准；root supervisor 異常後自動重啟；
-  卸載已停止的套件不再殘留 root task。
-- 原生 layout：`layout.anchors` 依架構把 payload 檔 SHA-256 寫進 INFO，作為產品 root helper 的信任錨點。
-- `entry: admin-only | app-privilege`（DSM 應用程式權限）、`ctx.user.isAdmin`、`api.RequireAdmin`；
-  未宣告 entry 的 SPK 不變。Linux 3.10 無 memfd_create 時 bridge 改由套件 tmp 執行（無 memfd seal）。
-- Application Portal（`portal:`、`add portal`、`ctx.portal`），需 os_min_ver 7.3.2-86009 以上；
-  目錄 `metadata:` 寫入 INFO，`metadata.changelog` 可依語言分開。
-- 授權契約新增 `reason: upgrade_reapproval`；背景套件 user manager 恢復、卸載 314 修正。
-- 範本與安裝精靈全部九語系並依 DSM 用語；Vue 範本固定 UI 0.8.1。
-- armv7（DSM 7.2+）支援 native-go 與 binary；plain CGI 已在 DS416 實機驗證，jobs／daemon／executor 尚未實機驗證。
-- npm 套件附 CHANGELOG.md。
-
-## 0.6.1
-
-- Restore native product packaging as a formal schema 2 `backend: {kind: native}`
-  route. Keep project-owned multi-binary payload/metadata layout, prepare/compile
-  argv hooks, HTTPS/SHA-256 toolkit acquisition and x86_64/aarch64/armv8/armv7.
-  `check`, `build` and `inspect --json` preserve package-only lifecycle/systemd
-  registration and reject root service accounts, privileged execution prefixes,
-  symlinks, setuid files and corrupt toolkit/payload inventories.
-- Restore `@synopackageland/cli/authorization-sdk` as an explicit native-product
-  adapter with exact pinned-task identity, fresh administrator approval and
-  withdrawal-before-task-removal; do not change generated Go executor semantics.
-  Export `./native-layout` and retain direct `./dist/*` imports.
-- Document field migration from schema 1 without changing product bootstrap pins,
-  per-build revocation/reapproval or dynamic DSM ABI declarations. Schema 1 remains
-  rejected; no compatibility aliases for retired CLI commands. Generated schema 2
-  check/build/status/logs and Connect/Gopeed APIs remain unchanged.
-- Align SKILL.md with the shipped delegate/rootOps executor implementation and
-  its documented device acceptance boundaries.
-- 正式補回 schema 2 原生產品 layout／hooks／toolkit／三架構及 authorization SDK。
-  lifecycle／systemd 維持 package account；root 僅由產品明確核准 digest，
-  不自動授權、不取消逐 build 撤權再授權。新增 Reclaim 欄位 migration 指引。
-
-## 0.6.0
-
-- Adopt UI 0.8.0 and its renamed `syno-pkg-land-ui` executable (no old alias).
-  Pin generated Vue apps and all overlays to the public npm artifact and integrity.
-  Skills discover the installed prompt/catalog/describe contract with
-  `npx --no syno-pkg-land-ui`; one-off use explicitly selects the npm package.
-  Render defaults to `syno-pkg-land-ui-render`. CSS/data selectors use the
-  `syno-pkg-land-ui` namespace without old aliases (including select attributes).
-  Add a regression audit for executable names and retired CSS/data selectors in
-  skills, templates, source, tests, docs and scripts; only released history is exempt.
-  跟進 UI 0.8.0 的 CLI 改名及公開 npm integrity；AI 指引維持版本無關，
-  使用已安裝契約，並防止指令名與 selector 回退。預設截圖目錄改為
-  `syno-pkg-land-ui-render`；CSS／data selector 全面使用新 namespace，不保留 alias。
-
-- Add version-independent Vue UI guidance alongside JSON UI guidance. All
-  generated projects include AGENTS.md and a CLAUDE.md pointer to discover the
-  bundled skills and run local check/build/inspect before authorized NAS work.
-  Template design notes use installed UI contracts while dependency pins remain.
-  新增 Vue UI skill；所有 scaffold 提供 AI 入口與本機驗證流程，設計文件依已安裝
-  SDK 契約，依賴鎖定不變。
-
-- **Breaking: remove `./authorization-sdk` and the legacy root authorization
-  templates and adapters.** Use delegate/root-ops capabilities and the protected
-  executor with one-time administrator approval; no compatibility exports remain.
-  **不保留相容**：移除 `./authorization-sdk` 與舊 root authorization 模板／adapter，
-  改用 delegate／root-ops 能力及受保護 executor 的一次管理員核准。
-
-- Pin generated Vue apps to public `@synopackageland/ui@0.8.0` with its npm
-  integrity; keep bounded app-local modal roots, embedded CSS and unique mount
-  ID prefixes, and explicitly retain DSM window layout at wide sizes.
-  Add `skill show ui-json` with installed prompt/catalog/schema discovery,
-  strict validation and screenshot/layout checks through the published `syno-pkg-land-ui`
-  package bin. Update the template
-  DOM test dependency and website configuration to remove gate warnings.
-  Vue 模板固定公開 UI 0.8.0 與 integrity，維持 DSM 的 app scope、embedded CSS、
-  唯一 mount ID 與 window layout；新增不固定版本的 JSON UI skill，依已安裝
-  catalog／schema 產生、嚴格驗證並 render，直接使用套件的 `syno-pkg-land-ui` bin。
-
-- **Delegate (C), P2/v10 (through 26030e74):** `init --with delegate` / `add delegate` imply jobs;
-  manifest operations use the five fixed files.* IDs with home/shared scope.
-  The worker stages downloads and writes as the consenting user after browser
-  close, without overwriting existing files or retaining DSM credentials.
-  C/R share one-password boot/control task setup and digest approval; stop pauses,
-  start resumes identical pins, changed policy requires reapproval, and uninstall
-  requests asynchronous own-task/protected-state purge (normally seconds with a
-  healthy monitor), with manual cleanup guidance. Task deletion requires byte-for-byte
-  equality with canonical scripts regenerated from package identity and approved pins.
-  Purge reapproval recreates tasks and writes `start` before boot; mailbox failure
-  blocks boot. Local fake-DSM/real-executor lifecycle tests cover this recovery.
-  Package-directory/INFO identity absence immediately pauses the socket/requests,
-  retaining the monitor, approved runtime, delegations and tasks. Polling every
-  500 ms must confirm 10 continuous minutes of absence before fallback purge;
-  reappearance or unverifiable absence resets the timer, with uncertainty staying paused.
-  Recovery rereads even an unchanged mailbox: matching-pin `start` resumes,
-  changed pins stay paused/needs-admin-approval, `stop` stays paused, and `purge`
-  immediately clears state. Temporary DSM-upgrade gaps preserve protected state;
-  preuninst purge remains immediate, with asynchronous cleanup. Boot's absent-package
-  retained-pin purge remains immediate. Local tests cover upgrade gaps, recovery,
-  timer/reset rules and immediate preuninst purge; device acceptance remains separate.
-  Malformed AppPriv responses fail closed, including duplicate keys/target entries,
-  null/missing data and nested error keys. Matching token header aliases are allowed;
-  conflicting/repeated headers, duplicate id cookies and controls are refused.
-  Empty/partial caller auth never falls back to worker revoke. Job admission reserves
-  before creating grants outside the journal lock; retry `jobs_busy` with the same key.
-  Writes fsync an exclusive hidden temporary then publish a hard link without overwrite;
-  cancellation cleans the temporary and leaves no partial final file.
-  Add bilingual developer and administrator guides covering typed Files, stable
-  errors, AppPriv defaults/denies and DSM-retained directories/accounts.
-  Full device lifecycle acceptance remains separate from source/local tests.
-  Delegate 隱含 jobs；以本人身分離線寫檔、不覆寫、不保存 DSM 憑證。
-  C／R 共用一次密碼設定與 digest 核准；中英文文件說明委託／撤銷、
-  typed Files、穩定錯誤碼、paused／purge、手動清理與 DSM 保留界線。
-  AppPriv 異常回應 fail-closed；token alias 同值允許、衝突／重複及控制字元拒絕，
-  空／不完整 caller auth 不降級為 worker。`jobs_busy` 沿用相同 key 重試。
-  隱藏暫存檔 fsync 後以 hard link 發布，不覆寫、取消不留半個正式檔。
-  特權清理非同步，monitor 正常時通常數秒完成；刪 task 前完整 script 須逐字相符。
-  Purge 後重新確認密碼、重建 task，boot 前 mailbox 重設 `start`；寫入失敗不執行 boot。
-  套件目錄／INFO identity 消失立即關 socket、取消／drain 請求並暫停，保留 monitor、
-  核准 runtime、委託與 task；每 500 ms 輪詢確認連續消失達 10 分鐘才後備 purge。
-  重新出現或無法確認消失皆重設計時；無法確認時維持 paused。
-  恢復時重讀未變 mailbox：`start` 且 pins 相同才恢復，pins 改變維持 paused／
-  needs-admin-approval，`stop` 維持暫停，`purge` 立即清理。DSM 升級短暫空窗不誤清；
-  preuninst purge 仍立即處理、非同步清理；boot 套件不存在時驗 retained pins 立即 purge 不變。
-  本機測試涵蓋升級空窗、恢復、計時／重設及 preuninst 立即 purge，不代表裝置驗收。
-
-- **Breaking: schema 2 and task-based CLI, with no compatibility layer.**
-  Native-go and binary now use dsm-package.yaml schema 2 with backend.kind and
-  declared capabilities. Use init → check → build → deploy → status, positional
-  inspect <spk> and logs. The former build-spk/validate/info/log commands, native
-  layout/native.yaml, native privilege/background/fileStation fields and old
-  capability flags are removed; there are no aliases or migration shims.
-  Schema 2 uses --with files,jobs,delegate,login,root-ops or add to extend native-go:
-  private owner-bound data/jobs (A), live caller-session files/tree/transfers (B),
-  standalone identity (I), offline delegation (C), and fixed administrator
-  operations (R). C/R share one-time protected executor approval.
-  Manifest delegate.operations uses
-  files.list/files.info/files.createFolder/files.checkPermission/files.write
-  directly. Check/build/inspect/deploy/status support structured JSON results.
-  Compose retains its separate contract and uses init -t compose, optionally
-  importing with --from. No publish or signing command is added.
-  **不保留相容**：native-go／binary 改用 schema 2；CLI 依工作流程改名，
-  移除舊欄位、旗標、指令與 native layout，不提供 alias 或 shim。
-  A／B／I／C／R 以能力宣告選用；C／R 共用 executor 一次核准。
-
-- Generate background submit/schedule keys with cryptographic getRandomValues,
-  which works on DSM HTTP; do not require secure-context randomUUID.
-  背景工作及排程以 getRandomValues 產生請求鍵，可在 DSM HTTP 使用；
-  不再依賴僅限安全環境的 randomUUID。
-
-- Give interactive File Station uploads their own bounded twenty-minute
-  response-header deadline without changing the shared metadata transport.
-  互動 File Station 上傳使用獨立的二十分鐘回應標頭期限，不修改共用查詢 transport；
-  保留目前 session、不覆寫、不重試及寫入結果不確定契約。
-
-- Frame native-Go CGI JSON with exact byte lengths, including Unicode and
-  refusal/serialization failures; retain DSM's HTTP-200 JSON error convention.
-  native-Go CGI JSON（含 Unicode、拒絕及序列化失敗）提供精確位元組長度，
-  並保留 DSM 的 HTTP 200 JSON 錯誤契約。
-
-- Replace R2 publication with a private GitHub catalog and streamed Release SPKs.
-- Serve live bilingual catalog pages and architecture-specific manual downloads.
-- Remove the two web demo templates; retain native-go, binary and the single compose template.
-
-## 0.5.3
-
-- Ship the native-go root authorization template with build-pinned plans,
-  the canonical Vue gate and nine language catalogs, explicit native approval,
-  exact disabled tasks, bounded legacy terminal proof and lifecycle withdrawal.
-- Export `@synopackageland/cli/authorization-sdk` for reviewed native-layout
-  adapters to consume the same host runtimes and canonical template resources.
-- Let an explicitly supplied native-layout withdrawal callback finish before
-  removing tasks; failed or missing callbacks abort withdrawal.
-- Legacy DSM authorization has no server-enforced one-use create token;
-  modern DSM keeps its native one-use PasswordConfirm token contract.
-- Isolate packed Docker runtime smoke in temporary share directories and its
-  own Compose project, including owned-volume cleanup. The 0.5.1 release tag
-  did not publish because the existing smoke omitted installer share values.
-- Use a pinned long-running imported runtime fixture for readiness smoke;
-  the default hello-world demo exits immediately. The 0.5.2 workflow was
-  cancelled before publication when CI exposed that fixture race.
-- Retain bounded artifact-test diagnostics up to eight MiB and propagate
-  real frontend test failures rather than hitting Node's default buffer limit.
-
-## 0.5.0
-
-- Add opt-in native layout packaging for existing products: argv-only build hooks,
-  checksum-pinned HTTPS toolkit caching, custom package-user metadata/payload
-  layouts, explicit ELF linkage assertions, DSM armv8/armv7 and build overrides.
-- Inspect native layouts with complete payload hash/mode and INFO checksum checks;
-  generated templates retain their existing privilege and architecture contracts.
-
-- **GitHub CI and tag-based npm releases** (CI-LAND). Add shared full gates, Docker
-  runtime/tarball smoke and credential-free release dry runs for both npm packages.
-  Version tags require matching metadata, default-branch ancestry, an unpublished
-  version and versioned CHANGELOG notes. Push scripts now use the existing GitHub
-  origin; `push:all` preserves the separate Community Apps synchronization.
-
-- **Vue templates pin UI 0.5.7 and let the UI text follow the app locale**
-  (TEMPLATE-UI-057). Every `native-go --ui vue` project pins
-  `@synopackageland/ui@0.5.7` (integrity `sha512-egHKoU4J...`). Each app root now wraps
-  its content in `ConfigProvider locale`, set from the DSM language by the template's
-  existing `uiLocale()` mapping, so the UI's built-in text follows it in the nine
-  built-in locales. The template drops the per-control `FilePicker` locale and the
-  `Link` `download-label` that only repeated those defaults; a template test requires
-  the provider and rejects those overrides. 0.5.7 also resolves `FormItem`
-  `direction="auto"` by the item's own width, stacks `SettingsRow` below 520px and
-  keeps `KeyValueRow` values wrapping; the template needed no mitigation for any of
-  these. Existing 0.5.6 projects upgrade by regenerating, or by changing the pin and
-  re-running `npm ci`.
-- **Vue templates use the UI controls instead of native form elements**
-  (TEMPLATE-SELECT). The job form's worker and operation pickers and the
-  background schedule interval are now `Select`; the schedule consent is a
-  `Checkbox`; the job, schedule, sample-note and folder forms are `Form` +
-  `FormItem` + `FormActions` (vertical, controls capped at `md`), and the
-  hand-written `.integration-field` label CSS is gone. Labels are wired to
-  `Input` and `Textarea` through the FormItem control id. A template test now
-  fails when any `.vue` file renders a native `<select>`, `<option>`,
-  `<textarea>` or `<label>`, or a `FormItem` outside a vertical `Form`. Three UI
-  gaps remain and are not worked around with custom components: `Select` does
-  not take the FormItem control id (each Select carries a labelled
-  `role="group"` so it keeps an accessible name), the upload stays a native
-  `<input type="file">` because `FilePicker` hard-codes English "Choose files" and
-  "max" text, and the file download keeps a native `<a>` (no link component).
-  Existing projects pick this up only by regenerating; nothing changes in the
-  manifest, routes or backend.
-- **Tarball smoke covers the default Vue UI and explicit plain UI**
-  (SMOKE-PACK-VUE). Install each generated Vue frontend with its lockfile before
-  building; keep both architectures and explicit root fixtures, then binary and
-  container packaging. The container smoke now selects `--arch x86_64` for
-  `-o app.spk` and its deployment plan, as explicit output requires one arch.
-  Docker runtime QA is opt-in with `smoke-pack.sh --docker`
-  and is explicitly skipped otherwise. Failed npm UI builds without installed
-  dependencies now name the UI directory and suggest `npm ci` (or `npm install`
-  without a lockfile) before retrying `build`; builds never install implicitly.
-
-- **Vue templates pin UI 0.5.5 and use PageContent** (TEMPLATE-UI-055). Every
-  `native-go --ui vue` project pins `@synopackageland/ui@0.5.5` (integrity
-  `sha512-pLQmZqNH...`). The sidebar shell now wraps the page header and the page
-  content in the library `PageContent`, so a maximised window keeps both on the
-  same left and right edges; the page area scrolls inside it. 0.5.5 also adds
-  `CardGrid`, `FormActions`, `RepeatRows` and `fieldWidth`; the template has no
-  card lists or custom width CSS, so it needs none of them. Default change to
-  know when upgrading: form controls are capped at `md` (320px) unless you pass
-  `field-width="full"`. Existing 0.5.4 projects upgrade by re-running `npm ci`
-  after the pin change.
-
-- **Vue templates pin UI 0.5.4** (TEMPLATE-UI-054). Every `native-go --ui vue`
-  project now pins `@synopackageland/ui@0.5.4` (integrity `sha512-mzuGUO+8...`).
-  0.5.4 is visual only and changes nothing in the template source: under the
-  embedded theme, Card, EmptyState, PageHeader and WizardStep titles no longer
-  carry a default margin, the expand buttons of SettingsSection, Card and
-  ExpandableItem lose their grey box, and dashed separators draw only the bottom
-  edge. Existing 0.5.3 projects upgrade by re-running `npm ci` after the pin change.
-
-- **Root tasks retain DSM 7.1 support.** Probe `list v3` and use the legacy
-  `create v3`, `list v2`, `get v3`, `run/delete v2`, and `view v1` only on code
-  103. Preserve native password confirmation while distinguishing tokenless
-  success from cancellation; DSM 7.1 has no server-side root-creation password
-  token. Require a new successful completion record within a bounded deadline,
-  exact task identity, and no mutation retries. Root init, validation, and build
-  keep a consistent minimum of DSM 7.1-42661.
-- **Vue templates pin UI 0.5.3** (TEMPLATE-UI-053). Every `native-go --ui vue`
-  project pins `@synopackageland/ui@0.5.3` in `frontend/package.json` and its
-  npmjs lockfile (integrity `sha512-ieKdf0nB...`). 0.4.2 to 0.5.3 is additive for
-  the template: new components (Select search and groups, Combobox,
-  MultipleSelect, SuperboxSelect, Grid/Row/Col, Space, Affix, Breadcrumb,
-  Pagination, SegmentControl, Card, Panel, Fieldset, Form, Notification, and more),
-  DataGrid grouping/expansion/reorder, checkable and draggable TreeView, DropdownMenu
-  submenus, and `Input`/`Dialog`/`SettingsSection`/`Callout` options with unchanged
-  defaults. Visual changes: Tabs and SectionTabs share a sliding marker with a
-  160ms panel fade, the Spinner is a full rotating ring (both honour
-  `prefers-reduced-motion`), selected tab labels are blue, and the DataGrid footer
-  draws both borders and fills its flex container. The template needed no API
-  change; it now uses the library `Checkbox` and `Input` for the consent and limit
-  fields instead of native inputs. Existing 0.4.2 projects upgrade by re-running
-  `npm ci` after the pin change.
-
-- **Templates never copy a local `node_modules`/`dist`** (TEMPLATE-COPY). A
-  template checkout used for development could leak its own install directory or
-  build output into a generated project, shadowing the project's `npm ci`.
-
-- **Vue templates pin UI 0.4.2** (TEMPLATE-UI-042). Every `native-go --ui vue`
-  project pins `@synopackageland/ui@0.4.2` in `frontend/package.json` and its
-  npmjs lockfile. 0.4.1/0.4.2 are visual, backward-compatible control changes with
-  no API change: controls share the `--ui-control-*` tokens and
-  `--ui-radius-control`, so overriding `--ui-radius-sm`/`--ui-radius-md` no longer
-  reshapes them; a disabled grey button keeps its surface, a loading button keeps
-  full strength, and the Switch track padding is reset. Existing 0.4.0 projects
-  upgrade by re-running `npm ci` after the pin change.
-
-- **Private-copy background schedules (S1-a)**: hourly/daily/weekly owner-scoped
-  creation, disable/delete, 8-definition limit, durable atomic trigger checkpoints,
-  missed-without-catch-up recovery, revision mismatch disable and explicit admin
-  re-enable. The Vue panel covers nine locales. Imported/pinned copies count toward
-  quotas; completed results never replay and owner purge also removes schedules.
-  Package account only, no stored credentials or offline personal ACL access.
-  Evidence: local gates and vt-nas DSM 7.4 x86_64 controlled-due-time tests
-  (two runs per owner, stop/start, +1 upgrade, disable and fresh normal1 browser
-  readback). This is not an hour-long cadence or reboot guarantee.
-
-- **Minimum DSM 7.1 and multiple architectures** (DSM-COMPAT). Every template now declares
-  `os_min_ver: "7.1-42661"` (DSM 7.1; before: `7.2-64570`, `7.2-69057` or `7.2-60000`).
-  `init --min-dsm` and `build --min-dsm` take `7.0`, `7.1`, `7.2` or a full
-  `7.x-build` to override it. `build --arch` accepts a comma-separated list
-- **Per-runtime minimum DSM and multiple architectures** (DSM-COMPAT, DSM-COMPAT-2).
-  `native-go` and `binary` declare `os_min_ver: "7.1-42661"` (DSM 7.1; before:
-  `7.2-64570`, `7.2-69057` or `7.2-60000`). The container templates declare
-  `7.2.1-69057` (DSM 7.2.1), and `init --min-dsm`/`build --min-dsm` refuse a
-  container value below it (`MIN_DSM_CONTAINER_FLOOR`) because Container Manager's
-  docker-project worker only exists from DSM 7.2.1; `inspect` reports the same
-  gap on an already-built container SPK. `--min-dsm` takes `7.0`, `7.1`, `7.2`,
-  `7.2.1` or a full `7.x-build`. `build --arch` accepts a comma-separated list
-  (`x86_64,aarch64`); without it every family is built, one SPK per family (binary and
-  gateway container Apps used to require `--arch`). `inspect` flags an INFO `arch`
-  that mixes families or names an unknown platform, a CGI built for another family than
-  INFO declares, and an `os_min_ver` that is not a DSM 7 `<version>-<build>`. The
-  x86_64 INFO platform list now includes `kvmcloud`, `epyc7003` and `epyc7003ntb`.
-  Only DSM 7.4 x86_64 has been run.
-- **Ordinary-user background jobs (U1)**: administrators may independently enable
-  `allowOrdinaryUsers`. Fresh DSM username/UID ownership isolates list/get/cancel/result,
-  counts and idempotency keys; unknown UIDs fail closed. Per-owner admission is bounded
-  to 2 pending jobs and 1 MiB including reserved results, under the same spool lock.
-  Administrators can cancel all jobs and explicitly purge an exact owner with durable
-  audit and running-job drain. The Vue panel and all nine locales cover both roles.
-  No root or stored user credentials; S1-a adds private-copy schedules below.
-
-- **Container gateway directory groups** (GW-DIRECTORY-GROUPS). Accounts absent
-  from `/etc/passwd` now resolve groups through DSM NSS using the fixed `/usr/bin/id`
-  as the package account. Qualified `DOMAIN\group` and `group@domain` names retain
-  their exact domain and case, including internal spaces; lookup failure denies.
-  The SDK caches nothing (TTL 0); DSM NSS caches and already-open streams remain
-  limitations. AD resolver allow/deny checks passed in a non-root DSM 7.4 package
-  CGI; LDAP, AD-user browser login and group-removal propagation remain unverified.
-  Rebuild container SPKs to obtain the change.
-
-- **`synopkgland images pin` resolves and writes container image digests**
-  (IMAGE-DIGEST-CLI). It reads every service image in `compose.yaml`, asks the
-  registry for the current multi-arch manifest digest over the OCI Distribution
-  API (anonymous Bearer token flow for Docker Hub and ghcr; no Docker daemon or
-  `buildx`), and rewrites the reference to `tag@sha256:…` in place, keeping
-  comments and file layout. `--check` reports unpinned and stale pins without
-  writing and exits non-zero. `inspect`'s unpinned-image finding now points at
-  the command. Evidence: local unit tests against a fake registry plus one manual
-  Docker Hub resolution of `busybox:1.36`; not verified on a real DSM.
-- **Container upgrade wizard no longer breaks on an untouched Run-as control; numeric
-  command arguments are rejected for every Compose route** (WIZARD-LIVE-CHECK).
-  Measured on vt-nas (DSM 7.4-90069) with the `compose-import` template: an untouched
-  upgrade submitted `RUN_AS` pre-filled with the name of the first Shared Folder, `preinst`
-  failed, and DSM, which removes the old version before it runs the new `preinst`, left the
-  package not installed (data kept). A `dsm_user` now has the same "Change Container Run-as"
-  box as a Shared Folder: on an upgrade the submitted user only counts when that box (or
-  `deploy --run-as`) is set; otherwise the installed user is kept. Also on vt-nas: the
-  Docker Project worker drops YAML quotes, so `command: ["sleep", "3600"]` ended the
-  install as broken (`failed to acquire postinst worker`). `synopkgland check` and
-  `build` already rejected that on the static route; the dynamic route (install
-  parameters, which includes `compose-import`) now rejects it too
-  (`COMPOSE_NUMERIC_COMMAND_ARG_FORBIDDEN`).
-- **`install.sharedFolder`** (T-0120): native-go packages can declare a Shared Folder (`select` wizard or `create`
-  via DSM `data-share`), stored by name in `var/config.json`; `init --shared-folder select|create` and an `inspect`
-  check are included. In `select` mode the administrator grants the package account access afterwards.
-- **Container gateway accepts a query SynoToken; known limit with DSM CSRF protection on**
-  (GW-QUERY-TOKEN). On `GET`, `HEAD` and `OPTIONS` with an empty `X-SYNO-TOKEN`, the
-  gateway hands a `?SynoToken=` value to `authenticate.cgi` (header wins; still stripped
-  upstream); state-changing methods are unchanged. Measured on DSM 7.4 with "Improve
-  protection against cross-site request forgery attacks" on: opening a container App
-  from the DSM desktop sends no token at all, so the gateway answers `401`
-  `session_required`. Known limitation: turn the setting off or use the `native-go`
-  template.
-- **Container gateway: readable errors, SSE and WebSocket** (GW-ERRORS-WS). DSM's web
-  server replaces the body and headers of any CGI reply with status `403`, `404`,
-  `500`, `502`, `503` or `504` by its generic error page (measured on DSM 7.4-90069;
-  every other status passes whole). The gateway therefore no longer sends those
-  statuses itself: `forbidden` and `token_required` arrive as `401`, a stopped
-  container as `521` with `Retry-After`, a timeout as `524`, an invalid reply as
-  `520`; every gateway error carries `X-Synopkgland-Error` (the code) and, for a
-  stand-in, `X-Synopkgland-Status` (the status it replaces). **Behaviour change:**
-  those statuses were `403`/`503`/`504`/`502`/`500` before. A request header
-  `X-Synopkgland-Keep-Error-Body: 1` makes the same swap for the container's own
-  error replies so an App can read its JSON error bodies. Server-Sent Events pass
-  through unbuffered and **WebSocket now works** (it answered `501`): DSM hands both
-  directions of an upgraded connection to the CGI, which the gateway uses; the
-  handshake must pass the same same-origin check as a state-changing request
-  (`cross_site_blocked`), because a browser cannot add `X-SYNO-TOKEN` to a handshake. Other protocol upgrades stay
-  `501`. See [Container access control](/docs/guides/container-access/).
-- Fix: **`dsm-groups` with `groups: [users]` let nobody in.** DSM keeps no member
-  list for `users` (every local account has it as its primary group), so the gateway,
-  which only read member lists from `/etc/group`, answered `403` to everyone, including
-  administrators (reproduced on vt-nas). The gateway now also counts the primary gid
-  from `/etc/passwd` as membership and fails closed if it cannot read that file.
-  Rebuild the SPK to pick it up. Real-account `dsm-groups`/`dsm-admins` checks passed on
-  vt-nas (x86_64); the aarch64 gateway is verified in an arm64 Linux VM only, not on an
-  aarch64 DSM NAS.
-- **Gateway CSRF check no longer relies on the SynoToken value** (GW-TOKEN). On a NAS
-  where DSM's "Improve protection against cross-site request forgery attacks" is off (vt-nas: `enable_syno_token="no"`), DSM
-  issues one fixed placeholder token to every session and validates nothing. The container
-  gateway now also requires `Sec-Fetch-Site: same-origin` and/or an `Origin` equal to the
-  request `Host` for `POST`/`PUT`/`PATCH`/`DELETE` (answer `cross_site_blocked`, sent as `401` because DSM replaces `403` bodies) and a
-  well-formed `X-SYNO-TOKEN`; safe methods are unchanged. Browsers that send neither
-  header on a state-changing request are refused. Verified on a real DSM 7.4 as an
-  administrator and an ordinary user (foreign `Origin`, `null`, `Sec-Fetch-Site`
-  cross-site/same-site, missing evidence refused; same-origin passes). The token path with
-  the DSM setting on is untested. Rebuild container SPKs to pick it up. See
-  [Container access](/docs/guides/container-access/).
-- **Container templates pin their image by digest** (CONTAINER-PULL): `hello-files` and `compose-import` now use
-  `image: <tag>@sha256:…`. `build` writes `force_pull: false` into the
-  `docker-project` resource when every service image is digest-pinned and keeps
-  `force_pull: true` while any image is a bare tag, so an install no longer
-  re-resolves a moving tag that other containers share. `inspect` reports each
-  service whose image is not digest-pinned. Behaviour for projects with unpinned
-  images is unchanged. Not verified on a real DSM.
-- **Breaking: container Apps are DSM-authenticated by default.** A container App
-  with an `adminport` is now served through a gateway CGI
-  (`/webman/3rdparty/<package>/cgi/gateway.cgi/…`) that runs as the package
-  account, checks the DSM session and forwards to the container. Without a valid
-  session it answers `401`; unsafe methods need `X-SYNO-TOKEN`; a stopped container
-  gives `521` with `Retry-After` (not `503`: DSM would replace its body). New `integration.web.access`: `dsm-users`
-  (default), `dsm-admins`, `dsm-groups` (+ `groups`), `public`. No Web Station
-  portal is registered unless `public`. The container port must be bound to
-  loopback (`127.0.0.1:<adminport>:<port>`): `check` fails with
-  `COMPOSE_GATEWAY_PORT_EXPOSED`, and `inspect`/`inspect` report
-  `CONTAINER_PORT_EXPOSED` and `CONTAINER_ANONYMOUS_PORTAL`. The gateway is
-  compiled Go, so building such an App needs Go and `--arch`, and the SPK is no
-  longer `noarch`. Privilege stays `run-as: package` with no root task.
-  **Migration:** bind the Compose port to `127.0.0.1`, rebuild with a higher
-  `build` and an `--arch`, then upgrade (the old `/<alias>/` portal and bookmarks
-  go away); or set `integration.web.access: public` to keep the anonymous
-  behaviour. See `website` guide “Container access control”.
-- Add best-effort `revealFile` selection recovery using File Station 1.4.x
-  private structures, with feature detection and silent cancellation on absent or
-  throwing APIs. One AppLaunch binds its callback receiver; only that receiver's
-  model may be selected once. Interaction, navigation away, close, disposal and
-  replacement requests cancel observers. Named bounds are 5000 ms total, 100 ms
-  checks and 300 ms quiet time, without device latency proof. `requested` still
-  does not mean `selected`. Actual effectiveness on DSM 7.4 / File Station 1.4.4
-  awaits a rebuilt-SPK device matrix; no device fix is claimed.
-
-- Fix `ctx.host.activateWindow()` to prefer DSM `toFront()`, calling `show()`
-  first for hidden/minimized windows; `activate()` remains a compatibility
-  fallback. `requestClose()` follows DSM standalone truthiness: falsy values
-  (including desktop `undefined`) permit the normal close path, while a truthy
-  standalone-main check refuses it. `canClose === false` and host listeners still
-  veto. Both methods return `requested`, not completion proof; rebuilt-SPK DSM
-  validation remains pending. Source: `7553c24`, `2842634`.
-- Add opt-in package-owned foreground `daemon` to native manifests, with
-  generated supervision and lifecycle hooks. Daemon-free packages keep their
-  existing lifecycle; no machine-wide service is required.
-- Add per-mount `ctx.host` platform/title adapters, guarded window activation
-  and close requests, app/external-URL navigation, resize/reopen subscription
-  cleanup, and File Station folder navigation/file reveal. Standalone web uses
-  explicit fallbacks; file reveal is not preview. File preview/details/settings
-  and host theme/language subscriptions remain unsupported. Final DSM runtime
-  behavior and ordinary-user navigation permissions still need NAS validation.
-- Fix SPK inspection to read the build-specific unique window bundle.
-
-### Known limitations
-
-- **File reveal remains a request:** on DSM 7.4-90069 with File Station
-  1.4.4-2221, one `ctx.host.revealFile()` call was observed opening the correct
-  folder without selecting/highlighting the file. A new synthetic fixture retest
-  selected the file with both `/home` and `/homes/admin` inputs, once each
-  (confidence **high**). The earlier non-selection was not reproduced; its cause
-  remains **unknown**. `requested` only means a selection request was issued;
-  it does not guarantee selection, preview, existence or ACL access. No runtime
-  fix is claimed. Source: V1 device validation and fixture retest, 2026-10-04.
-- Vue templates pin public `@synopackageland/ui@0.4.0`, including app-scoped
-  modals and unique mount IDs, with npmjs-only lockfiles and imports. External
-  developers do not need an internal registry account.
-- CLI 0.4.0 targets npmjs `latest`; versions 0.1.0–0.3.10 remain available without
-  deprecation or unpublishing.
+- `native-go`: a Go backend with a Vue UI (or `--ui plain`).
+- `native-python`, `native-node`, `native-rust`: the same App with a Python,
+  Node.js (TypeScript) or Rust backend behind the SDK's Go runtime.
+- `binary`: a static Linux program you build yourself.
+- `compose`: an existing Docker Compose app (`--from compose.yaml`).
+- Existing native products keep their own payload layout with
+  `backend: {kind: native}`.
+
+### Capabilities
+
+`init --with …` or `add` adds `files`, `jobs`, `login`, `delegate`,
+`root-ops` and `portal`. `delegate` and `root-ops` run through the SDK's
+executor, which an administrator approves once by digest; `check` and
+`build` have the App's executor validate its policy first
+(`EXECUTOR_POLICY_REJECTED`).
+
+### Commands
+
+- `init`, `add`: create a project and add capabilities.
+- `check`, `build`: validate the manifest and build the SPK for one or more
+  architectures, with the executor checked against the digests shipped in the
+  CLI.
+- `inspect`: check any SPK against the DSM 7 package format without
+  installing it.
+- `deploy`, `status`, `logs`: install on a NAS and read its state.
+- `dev`, `test`, `images`: run, test and pin images for Compose projects.
+- `skill`: the bundled guidance for AI assistants.
+
+`--json` prints one JSON object on stdout; failures carry a stable `code`
+and a `hint`.