文档重新梳理：README 精简成介绍和索引，细节按主题拆进 docs/zh-CN 与 docs/en（17 篇一一对应），英文文档不含中文

README.zh-CN.md / README.md 只留：这是什么、为什么用它、主要功能（按领域一行一条，链到文档）、快速开始、部署、文档索引、
开发与测试、许可（原文不动）。原来的每一节按读者和任务分到 17 篇主题文档：ask-data、workflows、evidence、
data-sources（新增：接入数据库、只读保证、上传表格、跨库合并、遮罩列）、data-catalog、tools（新增：工具、审批档位、
能力登记、端点、网络规则——它们管所有工作流，不只应用）、apps、evaluation-and-ledger、schedules（含通知）、deployment、
configuration、postgresql-and-scaling、identity-and-security、architecture、development、upgrade-notes（按时间倒序，
每波先写要做的事）、faq。删掉的只有模块名（api/copilot_gen.py、chat/drive.py、data/schema_view.py）、重复的话和
「以前…现在…」的叙述；操作步骤、命令、配置名、限制、权限边界都有归宿。中文是原文，英文按新的中文写；英文里界面文字
只写英文名，开头注明界面目前只有简体中文，中文占位符换成英文占位符，中文数字的例子改成不依赖中文的说法。
数据剖析可以同时剖析 2–3 张表（baf23998）收进 data-catalog。
新增 scripts/check-docs.py：英文文档（README.md、docs/en/**）不许有中日韩字符和全角符号（代码块也算），
README、docs/**、deploy/README.md 的相对链接和锚点都要通，docs/zh-CN 与 docs/en 文件一一对应、标题层级相同。
中文提示里指向 README 章节的地方改指新文档：cluster/guard.py、cluster/version.py、db/base.py 两处报错，
data/schema_view.py 文档串，.env.example 三处，scripts/prod.sh、scripts/test-postgres.sh，terms.ts 两处、
DataSourcesTab.tsx、check-manage.mjs 注释，deploy/README.md 三处链接。deploy/agentlab.env 未动。
验收：check-docs 0 问题（英文文档 18 个 0 处中文，相对链接 369 条 0 断链，18 对标题层级一致）；相关后端测试
117 通过、7 跳过；tsc -b、check-copy 通过。

docs/en/schedules.md

@@ -0,0 +1,69 @@
+English | [Simplified Chinese](../zh-CN/schedules.md)
+
+# Schedules, Event Triggers, and Notifications
+
+This page covers how to run workflows automatically on a schedule or when an event happens, and how results and reminders reach people. It is for builders and admins. The user interface is currently available in Simplified Chinese only.
+
+## Schedules
+
+A schedule starts formal runs on time, and the origin of each run is recorded as the schedule.
+
+- The target can be a workflow, a data source (that is, scheduled maintenance of the data source; see [Data Catalog](data-catalog.md#scheduled-maintenance)), or a test suite (that is, a scheduled evaluation; see [Regression evaluation](evaluation-and-ledger.md#scheduled-evaluations)).
+- App views prefer to bind to existing schedules. A dashboard reads the schedule's latest sealed formal run, and its stamp names the schedule and the run number.
+- When a run is rejected by a person, the schedule pushes "Not issued (rejected)".
+- Schedules that target a data source or a test suite don't accept webhooks (they return 422); their notifications go through channel subscriptions under Settings → Notifications.
+- For run concurrency, schedules belong to the scheduled class (see [Run concurrency](postgresql-and-scaling.md#run-concurrency)).
+- The scheduler loop ticks every `AGENTLAB_SCHEDULER_TICK_S`, 15 seconds by default.
+
+## Event triggers
+
+A schedule can choose Event trigger and run when one of these events happens:
+
+- an uploaded spreadsheet gets a new period;
+- a formal run of an upstream workflow finishes successfully;
+- a data source has changes that need action.
+
+Rules:
+
+- Events are recorded where they happen, and the scheduler loop starts runs after debouncing; each period is debounced separately.
+- Downstream input templates read the event content with `{{ event.* }}`.
+- Saving checks that chains don't form a cycle; at run time, chains are limited to 5 levels.
+- Runs that passed through a rejection, and runs that come from app backfills, don't trigger downstream by default; you can tick a box to let them.
+- This follows the `AGENTLAB_SCHEDULER` switch: when the switch is off, events are kept but not dispatched.
+
+## Notifications
+
+### Channels
+
+Notifications go to channels, which are either global or personal; subscribe to them under Settings → Notifications. Webhooks can be delivered too.
+
+Tasks, notifications, and webhooks state plainly where a rejection went ("Rejected, routed to X", "This path ends here").
+
+### Email
+
+An admin configures SMTP under Settings → Notifications → Mail Service; the password is stored encrypted. After that, email channels can be created.
+
+- Email only confirms handoff to the mail server; bounces aren't tracked.
+
+### Subscribable events
+
+| Event | Sent to | Notes |
+|---|---|---|
+| "Instance finished" | Subscribed channels | Includes runs rejected by a person |
+| "Scheduled evaluation regressed" | Subscribed channels | Only the test suite name, pass count, number of regressed questions, and a link |
+| "Data source has changes to handle" | Global channels | Only the source name, the count, and a link; no table names, column names, or values |
+| "Caliber version bumped, answer numbers changed" | Global channels and the answer owner's personal channels | No numbers; `ledger.recall` is pushed at the same time |
+| Daily task digest | Personal channels subscribed to it | Sent at `notify.digest_at`, default 09:00 (server time zone) |
+| Access key expiry reminder | — | Once 7 days and once 1 day before expiry |
+
+The daily digest and access key reminders are sent only when login is on.
+
+## The scheduler switch
+
+When `AGENTLAB_SCHEDULER` is turned off (set to 0):
+
+- process time limits aren't checked: no reminders, no escalation, no automatic verification;
+- events are kept but not dispatched;
+- the retroactive caliber matching of the last 7 days at startup doesn't run, and neither do the automatic caliber recall batches after publishing or their continuation at startup.
+
+In a multi-process deployment, claiming schedules, dispatching events, delivering webhooks, process time limits and verification, and the daily digest all happen only in the process that is the scheduler leader (see [Scheduler leader](postgresql-and-scaling.md#scheduler-leader)).