ictrp-mcp-server 0.1.0

package/CHANGELOG.md

@@ -0,0 +1,65 @@
+# Changelog
+
+Notable changes to the npm package `ictrp-mcp-server`. The Python package
+`ictrp-mcp-service` is versioned separately in `pyproject.toml`.
+
+## 0.1.0
+
+First release.
+
+**MCP tools** — ten, matching the Python service one for one:
+
+- `ictrp_search` — runs the three-step chain and materializes the whole result
+  set, returning a page plus a `set_id`. The only expensive call.
+- `ictrp_filter`, `ictrp_field_query`, `ictrp_registry_summary`,
+  `ictrp_find_duplicates`, `ictrp_export`, `ictrp_cache_status`,
+  `ictrp_snapshot`, `ictrp_bundle_status` — local, no upstream request.
+- `ictrp_check_environment` — reports what is ready, and what to do about what
+  is not.
+
+**Packaging** — a Node MCP server with a bundled Python sidecar. The sidecar is
+stdlib-only apart from `httpx`, so no browser and no Chromium are involved
+anywhere in the stack; ICTRP needs no JavaScript execution to yield data. A
+private virtualenv is created on first run rather than at install time, because
+packaged desktop applications do not execute npm's `postinstall`.
+
+The package is self-contained: the full Python source ships under
+`sidecar/vendor/` together with a generated `pyproject.toml`, so `ictrp-setup
+setup` builds the wheel from the tarball itself. It does not depend on a
+matching release existing on PyPI, and the Python that runs is always the same
+commit as the JavaScript around it.
+
+**Offline path** — `ICTRP_BUNDLE_PATH` / `ICTRP_BUNDLE_DIR` let a desktop build
+ship a snapshot so the first launch works with no network. Snapshots carry a
+creation date and are reported stale past `ICTRP_BUNDLE_MAX_AGE_DAYS`,
+defaulting to 28 days against WHO's weekly refresh. A snapshot-served response
+says so: `provenance.offline_snapshot` is `true` and `snapshot_path` /
+`snapshot_age_days` identify the file it came from, so snapshot data is never
+mistaken for a live query.
+
+**Refresh semantics** — `refresh: true` forces an upstream search and is always
+attempted, even inside the failure-backoff window. A forced refresh that fails
+does not discard the cached set; the cached data is served with the failure
+recorded in `provenance.notes`. Automatic refreshes are the ones that back off.
+
+**Documentation** — the README is bilingual: `README.md` in English and
+`README_ZH.md` in Chinese, each linking to the other from the top.
+
+**Reasons this release exists at all** — the ICTRP CSV export is incomplete and
+fails silently, measured at 0.4% to 29.0% depending on the keyword. Accordingly:
+
+- a failure never returns zero rows; it raises, so it cannot be read as
+  "no such trial exists";
+- `total_matched` does not exist, only `rows_returned` and
+  `upstream_reported_total`, never merged;
+- every response carries `records_incomplete` and an `incompleteness_notice`;
+- absence from a result set is never evidence of nonexistence.
+
+### Known limitations
+
+- `rows_returned` counts retrieved rows. It is never the number of matching
+  trials, and no tool will present it as such.
+- The sidecar's default port is 8849, deliberately not the 8848 used by other
+  trial-registry MCP servers, so both can be installed together.
+- Materialized sets live in the sidecar process. Restarting it invalidates
+  every `set_id`; callers get `set_expired` and re-search.

package/LICENSE

@@ -0,0 +1,37 @@
+MIT License
+
+Copyright (c) 2026 ictrp-mcp-service contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+---
+
+This license covers the software only.
+
+The DATA this software retrieves is subject to WHO's terms for the ICTRP
+database, which are separate and take precedence for any use of that data.
+See ATTRIBUTION.md in the source repository. In summary:
+
+- Attribute the source as WHO ICTRP.
+- Clearly display the date the data were processed by WHO ICTRP.
+- Do not assert proprietary rights over any portion of the ICTRP database.
+- Do not use the WHO name or emblem in association with use of the data.
+- No marketing, promotional or commercial use.
+
+This project is not affiliated with or endorsed by WHO.

package/README.md

@@ -0,0 +1,208 @@
+# ictrp-mcp-server
+
+[简体中文](./README_ZH.md) | English
+
+An MCP server for the **WHO International Clinical Trials Registry Platform
+(ICTRP)**, packaged for npm. Node MCP surface, Python sidecar, plain HTTP
+underneath — no browser, no headless Chromium, no automation runtime.
+
+```bash
+npx ictrp-mcp-server
+```
+
+The Python side of this package is the same code as the
+[`ictrp-mcp-service`](https://github.com/opencare-skillhub/ictrp-mcp-service) Python
+distribution. The npm package wraps it so a desktop host can declare one stdio
+command and get a working trial-registry data source.
+
+## Why the sidecar exists
+
+The ICTRP access logic is already implemented and tested in Python, and its
+hard-won details matter: which HTML controls to carry through the postback
+chain, which redirect means "blocked" rather than "contract drift", how a
+legitimately empty CSV differs from a failed one. Reimplementing that in
+TypeScript would produce a second version that drifts from the first.
+
+So the split is: **Node owns the MCP protocol, Python owns the domain.** They
+talk over a small local JSON API.
+
+```
+MCP client  ──stdio──▶  Node (this package)  ──HTTP──▶  Python sidecar  ──HTTPS──▶  ICTRP
+```
+
+The sidecar is standard library only, plus `httpx`. Nothing here downloads a
+browser.
+
+## Install
+
+The first run creates a private virtualenv and installs the Python sidecar into
+it. This is deliberately *not* done at install time: packaged desktop
+applications do not execute npm's `postinstall`, so anything that has to happen
+before first use must happen at first use.
+
+```bash
+npx ictrp-setup doctor      # what is ready, what is not (exit 0/1/2)
+npx ictrp-setup setup       # create the venv and install the sidecar
+npx ictrp-setup sidecar     # run the sidecar in the foreground
+```
+
+`doctor` uses exit codes as its contract, so an installer can drive a UI from
+them:
+
+| Code | Meaning | What a UI should do |
+|---|---|---|
+| 0 | Ready | Enable the data source |
+| 1 | Not ready, needs the user | Show the suggested actions |
+| 2 | Setup failed | Show the error; offer to retry |
+
+Requires Node 20+ and Python 3.10+. The Python source ships inside this package
+under `sidecar/vendor/`, so `setup` builds it locally — no PyPI release of
+`ictrp-mcp-service` is needed for the tool itself, only for its dependencies.
+
+Behind a slow or unreachable network, `setup` tries PyPI mirrors in order —
+`aliyun`, `tencent`, `tsinghua`, then the official index — and falls back on
+failure. Some mirrors report a missing package rather than an error when they
+cannot serve it, so falling back is the only reliable strategy. Point it at your
+own mirror with `--mirror=<name|url>` or `ICTRP_PIP_MIRROR`.
+
+## Configure your MCP client
+
+```json
+{
+  "mcpServers": {
+    "ictrp": {
+      "command": "npx",
+      "args": ["-y", "ictrp-mcp-server"]
+    }
+  }
+}
+```
+
+## Tools
+
+Network-backed:
+
+- **`ictrp_search`** — runs the full chain and materializes the entire result
+  set locally. Returns a page plus a `set_id`. The only expensive call.
+
+Local, no upstream request:
+
+- **`ictrp_filter`** — filter, sort and page a materialized set.
+- **`ictrp_field_query`** — distinct values plus population coverage for a field.
+- **`ictrp_registry_summary`** — composition by registry/phase/status/year/country.
+- **`ictrp_find_duplicates`** — identifier cross-reference duplicates.
+- **`ictrp_export`** — CSV / JSON / JSONL / Markdown with a provenance header.
+- **`ictrp_cache_status`** — list or purge cached sets.
+- **`ictrp_snapshot`** — write a set to an offline snapshot file.
+- **`ictrp_bundle_status`** — report which snapshot can answer a keyword.
+- **`ictrp_check_environment`** — readiness report and next actions.
+
+Materialize once; refine for free.
+
+A worked example lives in the [project README](https://github.com/opencare-skillhub/ictrp-mcp-service#usage):
+one search for `ibi343` returns 12 trials spread across **three** registries
+(ClinicalTrials.gov 10, JPRN 1, ChiCTR 1) — the cross-registry case that a
+single-registry search would miss.
+
+## The finding that shapes every response
+
+**The ICTRP CSV export is incomplete, and it fails silently.** Measured against
+the portal's own reported match counts:
+
+| Query | Portal reports | CSV delivers | Shortfall |
+|---|---|---|---|
+| `ChiCTR` | 14,197 | 14,147 | 0.4% |
+| `pancreatic` | 10,354 | 9,273 | 10.4% |
+| `pancreatic cancer` | 6,952 | 6,262 | 9.9% |
+| `KRAS` | 1,243 | 882 | **29.0%** |
+
+This is not a counting artifact: paginating the HTML results for `KRAS` yielded
+108 distinct trial IDs, **8 of which were absent from the CSV** — records
+visible on the results page and missing from the export. The cause is unknown;
+duplicate records, a fixed row cap, and pagination limits have all been ruled
+out.
+
+So this server never presents retrieved counts as match counts:
+
+- A failure raises; it never returns zero rows. An empty list would be
+  indistinguishable from "no such trial exists", which is exactly the mistake
+  this package exists to prevent.
+- There is no `total_matched`. There is `rows_returned`, and separately
+  `upstream_reported_total`, and they are never merged.
+- Every response carries `records_incomplete` and an `incompleteness_notice`.
+
+## Environment variables
+
+| Variable | Default | Purpose |
+|---|---|---|
+| `ICTRP_HOME` | package root | Where writable state goes — the venv, snapshots, caches. Set this to a private, writable directory when the package itself is read-only (an asar archive, a system-path global install). It does not affect where the sidecar script is read from. |
+| `ICTRP_VENV` | `<root>/.venv` | Where the private virtualenv lives |
+| `ICTRP_SIDECAR_URL` | `http://127.0.0.1:8849` | Where the Node layer finds the sidecar |
+| `ICTRP_SIDECAR_PORT` | `8849` | Sidecar listen port |
+| `ICTRP_SIDECAR_TIMEOUT_MS` | `30000` | Per-call timeout for local tools |
+| `ICTRP_USE_SIDECAR` | `1` | Set `0` to run without a sidecar and fail loudly instead |
+| `ICTRP_AUTOSTART_SIDECAR` | `1` | Set `0` to require an externally managed sidecar |
+| `ICTRP_PIP_MIRROR` | `aliyun` | First mirror for `setup`; accepts a name or URL |
+| `ICTRP_CACHE_DIR` | `~/.cache/ictrp-mcp-service` | Where raw CSV exports are cached |
+| `ICTRP_BUNDLE_PATH` | — | Explicit offline snapshot file |
+| `ICTRP_BUNDLE_DIR` | — | Directory of `<keyword-slug>.json` snapshots |
+| `ICTRP_BUNDLE_MAX_AGE_DAYS` | `28` | Age beyond which a snapshot is reported stale |
+
+## Data providers
+
+ICTRP does not register trials; it republishes the registries below, each on its
+own import cadence. Which registry a record came from is always available as
+`source_register`.
+
+| Registry | Last data file imported |
+|---|---|
+| Australian New Zealand Clinical Trials Registry | 2026-09-21 |
+| Brazilian Clinical Trials Registry (ReBec) | 2026-09-14 |
+| Chinese Clinical Trial Registry | 2026-09-21 |
+| Clinical Research Information Service — Republic of Korea | 2026-09-21 |
+| Clinical Trials Information System (CTIS) | 2026-09-21 |
+| Clinical Trials Registry — India | 2026-09-14 |
+| ClinicalTrials.gov | 2026-09-21 |
+| Cuban Public Registry of Clinical Trials | 2026-09-14 |
+| EU Clinical Trials Register (EU-CTR) | 2026-09-21 |
+| German Clinical Trials Register | 2026-09-14 |
+| International Traditional Medicine Clinical Trial Registry (ITMCTR) | 2026-08-03 |
+| Iranian Registry of Clinical Trials | 2026-06-01 |
+| ISRCTN | 2026-09-21 |
+| Japan Registry of Clinical Trials (jRCT) | 2026-09-14 |
+| Lebanese Clinical Trials Registry (LBCTR) | 2026-02-02 |
+| The Netherlands National Trial Register | 2026-09-21 |
+| Pan African Clinical Trial Registry | 2026-09-14 |
+| Peruvian Clinical Trials Registry (REPEC) | 2026-03-30 |
+| Sri Lanka Clinical Trials Registry | 2026-09-14 |
+| Thai Clinical Trials Registry (TCTR) | 2026-08-03 |
+
+The import dates span six months. A trial registered last week in a registry
+last imported in June is genuinely absent from ICTRP — not missing from this
+package, and not a bug.
+
+## Attribution and terms of use
+
+WHO ICTRP data are publicly available for download at no charge, subject to
+WHO's terms:
+
+- Attribute the source as **WHO ICTRP**.
+- Clearly display the date the data were processed by WHO ICTRP. ICTRP is
+  updated **weekly**.
+- Do not assert proprietary rights over any portion of the ICTRP database.
+- Do not use the WHO name or emblem in association with use of the data.
+- No marketing, promotional or commercial use.
+
+Chinese trials appear with `source_register = "ChiCTR"`. Attribute these as
+**"ChiCTR via WHO ICTRP"** — this is data as synchronized by WHO, not live
+ChiCTR data.
+
+`ictrp_export` prepends this attribution header by default. Keep it on unless
+your consumer adds its own.
+
+**This project is not affiliated with or endorsed by WHO.**
+
+## License
+
+MIT for the code. The **data** is subject to WHO ICTRP terms, which are
+separate and take precedence for any use of the data.

package/README_ZH.md

@@ -0,0 +1,189 @@
+# ictrp-mcp-server
+
+[简体中文](./README_ZH.md) | [English](./README.md)
+
+一个查询 **WHO 国际临床试验注册平台（ICTRP）** 的 MCP 服务器，以 npm 包形式分发。
+上表面是 Node MCP，底下是 Python sidecar，全程纯 HTTP——不需要浏览器，
+不需要无头 Chromium，不需要任何自动化运行时。
+
+```bash
+npx ictrp-mcp-server
+```
+
+本包的 Python 部分与
+[`ictrp-mcp-service`](https://github.com/opencare-skillhub/ictrp-mcp-service) Python
+发行版是**同一份代码**。npm 包把它包起来，让桌面宿主只需声明一条 stdio 命令，
+就能得到一个可用的试验注册库数据源。
+
+## 为什么要有 sidecar
+
+ICTRP 的访问逻辑已经在 Python 里实现并测试过了，其中那些**来之不易的细节很要紧**：
+postback 链里要携带哪些 HTML 控件、哪一种重定向意味着「被拦截」而不是「接口变了」、
+一个合法的空 CSV 与一个失败的 CSV 如何区分。用 TypeScript 重写一遍，只会得到
+第二份会与第一份逐渐漂移的实现。
+
+所以分工是：**Node 负责 MCP 协议，Python 负责领域逻辑。** 两者通过一个小型本地 JSON API 通信。
+
+```
+MCP 客户端  ──stdio──▶  Node（本包）  ──HTTP──▶  Python sidecar  ──HTTPS──▶  ICTRP
+```
+
+sidecar 只用标准库，外加 `httpx`。这里没有任何东西会去下载浏览器。
+
+## 安装
+
+首次运行会创建一个私有虚拟环境，并把 Python sidecar 装进去。这一步**刻意不放在安装时**做：
+打包后的桌面应用不会执行 npm 的 `postinstall`，所以任何必须在首次使用前完成的事，
+都得放到首次使用时去做。
+
+```bash
+npx ictrp-setup doctor      # 哪些就绪、哪些没有（退出码 0/1/2）
+npx ictrp-setup setup       # 创建 venv 并安装 sidecar
+npx ictrp-setup sidecar     # 前台运行 sidecar
+```
+
+`doctor` 以退出码作为契约，安装器可据此驱动 UI：
+
+| 退出码 | 含义 | UI 应如何应对 |
+|---|---|---|
+| 0 | 就绪 | 启用该数据源 |
+| 1 | 未就绪，需要用户动作 | 展示建议的操作 |
+| 2 | 自举失败 | 展示错误；提供重试 |
+
+需要 Node 20+ 与 Python 3.10+。Python 源码随本包一起发布在 `sidecar/vendor/` 下，
+因此 `setup` 是在**本地构建**它——工具本身不需要 PyPI 上有 `ictrp-mcp-service` 的发行版，
+只有它的依赖需要。
+
+在网络缓慢或不可达时，`setup` 会按顺序尝试 PyPI 镜像——`aliyun`、`tencent`、`tsinghua`，
+最后是官方源——失败则回退。有些镜像在无法提供包时**报告包不存在而不是报错**，
+所以回退是唯一可靠的策略。可用 `--mirror=<name|url>` 或 `ICTRP_PIP_MIRROR` 指向你自己的镜像。
+
+## 配置你的 MCP 客户端
+
+```json
+{
+  "mcpServers": {
+    "ictrp": {
+      "command": "npx",
+      "args": ["-y", "ictrp-mcp-server"]
+    }
+  }
+}
+```
+
+## 工具
+
+联网：
+
+- **`ictrp_search`** — 跑完整条链，并把整个结果集**本地物化**。返回一页数据加一个 `set_id`。
+  唯一昂贵的调用。
+
+本地，不发起上游请求：
+
+- **`ictrp_filter`** — 对已物化的结果集做筛选、排序、分页。
+- **`ictrp_field_query`** — 某字段的去重取值及其填充覆盖率。
+- **`ictrp_registry_summary`** — 按注册库／分期／状态／年份／国家的构成。
+- **`ictrp_find_duplicates`** — 通过标识符交叉比对找出重复。
+- **`ictrp_export`** — 导出 CSV / JSON / JSONL / Markdown，带 provenance 头。
+- **`ictrp_cache_status`** — 列出或清除已缓存的结果集。
+- **`ictrp_snapshot`** — 把结果集写成离线快照文件。
+- **`ictrp_bundle_status`** — 报告哪个快照可以回答某个关键词。
+- **`ictrp_check_environment`** — 就绪状态报告与后续操作。
+
+**物化一次，之后随便筛。**
+
+完整示例见[项目 README](https://github.com/opencare-skillhub/ictrp-mcp-service#用法)：
+一次 `ibi343` 检索返回 12 条试验，**散落在三个注册库**（ClinicalTrials.gov 10、JPRN 1、
+ChiCTR 1）——正是只查单一注册库会漏掉的情形。
+
+## 决定每个响应的那个发现
+
+**ICTRP 的 CSV 导出并不完整，而且它是静默失灵的。** 对照门户自己报告的命中数实测：
+
+| 关键词 | 门户报告 | CSV 实际给出 | 缺口 |
+|---|---|---|---|
+| `ChiCTR` | 14,197 | 14,147 | 0.4% |
+| `pancreatic` | 10,354 | 9,273 | 10.4% |
+| `pancreatic cancer` | 6,952 | 6,262 | 9.9% |
+| `KRAS` | 1,243 | 882 | **29.0%** |
+
+这不是统计口径的差异：对 `KRAS` 的结果页做 HTML 分页得到 108 个互不相同的试验 ID，
+其中 **8 个在 CSV 里不存在**——它们在结果页上可见，却没有出现在导出中。原因未知；
+重复记录、固定行数上限、分页限制均已排除。
+
+所以本服务**从不把取回的条数当作命中数**来呈现：
+
+- 失败会抛错，绝不返回零行。一个空列表与「不存在这样的试验」无法区分，
+  而后者恰恰是本包存在的意义所在——防止这个误判。
+- 不存在 `total_matched`。只有 `rows_returned`，以及与之**相互独立**的
+  `upstream_reported_total`，两者永不合并。
+- 每个响应都带 `records_incomplete` 与 `incompleteness_notice`。
+
+## 环境变量
+
+| 变量 | 默认值 | 作用 |
+|---|---|---|
+| `ICTRP_HOME` | 包根目录 | 可写状态的去向——venv、快照、缓存。当包本身只读时（asar 归档、系统路径下的全局安装），把它设为一个私有可写目录。**它不影响 sidecar 脚本从哪里读取。** |
+| `ICTRP_VENV` | `<root>/.venv` | 私有虚拟环境的位置 |
+| `ICTRP_SIDECAR_URL` | `http://127.0.0.1:8849` | Node 层到 sidecar 的地址 |
+| `ICTRP_SIDECAR_PORT` | `8849` | sidecar 监听端口 |
+| `ICTRP_SIDECAR_TIMEOUT_MS` | `30000` | 本地工具的每次调用超时 |
+| `ICTRP_USE_SIDECAR` | `1` | 设为 `0` 则不使用 sidecar，并**响亮地失败** |
+| `ICTRP_AUTOSTART_SIDECAR` | `1` | 设为 `0` 则要求外部自行管理 sidecar |
+| `ICTRP_PIP_MIRROR` | `aliyun` | setup 时优先尝试的镜像；接受名称或 URL |
+| `ICTRP_CACHE_DIR` | `~/.cache/ictrp-mcp-service` | 原始 CSV 导出的缓存位置 |
+| `ICTRP_BUNDLE_PATH` | — | 指定离线快照文件 |
+| `ICTRP_BUNDLE_DIR` | — | 存放 `<keyword-slug>.json` 快照的目录 |
+| `ICTRP_BUNDLE_MAX_AGE_DAYS` | `28` | 超过此天数即把快照标记为过期 |
+
+## 数据提供方
+
+ICTRP 自己并不登记试验；它重新发布下列注册库的内容，每个库有各自的导入节奏。
+一条记录来自哪个注册库，始终可通过 `source_register` 获知。
+
+| 注册库 | 最后导入数据文件 |
+|---|---|
+| Australian New Zealand Clinical Trials Registry | 2026-09-21 |
+| Brazilian Clinical Trials Registry (ReBec) | 2026-09-14 |
+| Chinese Clinical Trial Registry | 2026-09-21 |
+| Clinical Research Information Service — Republic of Korea | 2026-09-21 |
+| Clinical Trials Information System (CTIS) | 2026-09-21 |
+| Clinical Trials Registry — India | 2026-09-14 |
+| ClinicalTrials.gov | 2026-09-21 |
+| Cuban Public Registry of Clinical Trials | 2026-09-14 |
+| EU Clinical Trials Register (EU-CTR) | 2026-09-21 |
+| German Clinical Trials Register | 2026-09-14 |
+| International Traditional Medicine Clinical Trial Registry (ITMCTR) | 2026-08-03 |
+| Iranian Registry of Clinical Trials | 2026-06-01 |
+| ISRCTN | 2026-09-21 |
+| Japan Registry of Clinical Trials (jRCT) | 2026-09-14 |
+| Lebanese Clinical Trials Registry (LBCTR) | 2026-02-02 |
+| The Netherlands National Trial Register | 2026-09-21 |
+| Pan African Clinical Trial Registry | 2026-09-14 |
+| Peruvian Clinical Trials Registry (REPEC) | 2026-03-30 |
+| Sri Lanka Clinical Trials Registry | 2026-09-14 |
+| Thai Clinical Trials Registry (TCTR) | 2026-08-03 |
+
+导入日期跨度达六个月。某个上周才在某库登记的试验，若该库最后一次导入是在六月，
+那么它就是**真的不在 ICTRP 里**——不是本包漏了，也不是 bug。
+
+## 归属与使用条款
+
+WHO ICTRP 数据可免费公开下载，但须遵守 WHO 的条款：
+
+- 注明数据来源为 **WHO ICTRP**。
+- **清晰展示 WHO ICTRP 处理该数据的日期。** ICTRP **每周**更新。
+- 不得对 ICTRP 数据库的任何部分主张专有权利。
+- 不得将 WHO 名称或徽标与数据的使用相关联。
+- 不得用于营销、推广或商业用途。
+
+中国试验以 `source_register = "ChiCTR"` 出现。请把这些标注为
+**「ChiCTR via WHO ICTRP」**——这是**经 WHO 同步后**的数据，不是 ChiCTR 的实时数据。
+
+`ictrp_export` 默认会前置这段归属头。除非你的下游会自行添加，否则请保留它。
+
+**本项目与 WHO 无隶属关系，亦未获其背书。**
+
+## 许可证
+
+代码为 MIT。**数据**受 WHO ICTRP 条款约束，该条款独立存在，且对任何数据使用具有优先效力。

package/dist/cli/setup-cli.d.ts

@@ -0,0 +1,14 @@
+#!/usr/bin/env node
+/**
+ * Setup CLI.
+ *
+ * Exit codes are contractual -- installers and desktop hosts branch on them,
+ * so they must not drift:
+ *
+ *   0  success, or the environment is ready
+ *   1  not ready, and the user needs to do something
+ *   2  self-setup failed with a definite error
+ *
+ * Every subcommand is read-only except `setup`, `sidecar` and `clean`.
+ */
+export {};