webhook 触发的是自定义脚本而非 composer 或 satis 自身；需部署可访问端点（如 webhook.php），在脚本中手动执行 satis build 等命令，并严格校验签名、设置正确事件类型（tag push）、content-type 及权限路径。

Webhook 触发的是脚本，不是 Composer 或 Satis 自身

Composer 本身不接收 Webhook，Satis 也没有内置 HTTP 服务。所谓“自动同步”，本质是你在服务器上部署一个可访问的端点（比如 webhook.php），GitHub/GitLab/Gitee 推送时调用它，脚本里手动执行 satis build 或 composer install 等命令。

常见错误现象：Webhook 显示 delivery 成功（200），但 packages.json 没更新、新 tag 不出现——大概率是脚本没运行、路径错、权限不足或没切工作目录。

• 必须用 chdir() 切到 satis.json 所在目录再执行 exec('php bin/satis build ...')，否则配置读不到、输出路径错
• 脚本运行用户（如 www-data）需有 Git 权限、composer 命令可用、对输出目录（如 /var/www/satis/）有写权限
• Nginx/Apache 必须能正确 serve 输出目录，且 URL 以 / 结尾（否则请求 packages.json 会 404）

Git 平台 Webhook 配置必须勾选 Tag push events

Packagist 和 Satis 类工具只响应 tag 创建事件，不是普通 push。只勾选 “Pushes” 是无效的，必须单独启用 “Tag push events”（GitHub/GitLab）或 “代码推送”+ 解析 ref 是否为 tag（Gitee）。

常见错误现象：执行了 git tag v1.2.0 && git push origin v1.2.0，但镜像没更新——检查 GitHub/GitLab 的 Webhook delivery 日志，看是否收到 create 事件且 ref_type === "tag"。

• GitHub：Settings → Webhooks → Edit → Events → 勾选 “Tag push events”
• GitLab：Settings → Webhooks → Trigger → 勾选 “Tag Push Events”
• Gitee：管理 → Webhooks → 勾选「代码推送」，并在接收脚本中用 $data['ref'] 判断是否为 refs/tags/v1.2.0
• Content-Type 必须设为 application/json，否则 PHP 无法用 file_get_contents('php://input') 正确读取 payload

Satis 脚本必须校验签名，不能裸奔执行

GitHub 发 X-Hub-Signature-256，GitLab 发 X-Gitlab-Token，Gitee 发 X-Gitee-Token。不校验就等于开放任意人 POST 即可触发构建，存在严重安全风险。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

常见错误现象：Webhook 被恶意调用导致磁盘写满、CPU 跑满、甚至被植入后门——因为脚本没做任何验证就直接执行 git pull && satis build。

• GitHub 示例校验：hash_hmac('sha256', $payload, $secret) === substr($_SERVER['HTTP_X_HUB_SIGNATURE_256'], 7)
• GitLab 示例校验：hash_equals($secret, $_SERVER['HTTP_X_GITLAB_TOKEN'] ?? '')
• Gitee 示例校验：hash_hmac('sha256', $payload, $secret) === $_SERVER['HTTP_X_GITEE_TOKEN']
• Secret 字符串不要硬编码在脚本里，建议从环境变量或配置文件加载

Private Packagist 和 Packeton 的 Webhook 地址不能手写

Private Packagist 的 Webhook URL 是后台生成的唯一地址（形如 https://packagist.com/webhook/abc123），填错字符、多加斜杠、少一位都会返回 403 或静默失败。Packeton 同理，其 Webhook endpoint 是安装后自动生成的，不可猜测。

常见错误现象：填完 URL 点测试，返回 403；或完全无响应——不是网络问题，是地址本身非法。

• Private Packagist：只能在后台「Repositories → Add Repository」流程中复制，不能拼接、不能修改、不能带 trailing slash
• Packeton：登录后台后，在仓库设置页找 “Webhook URL” 字段，复制整条 URL
• 两者都不需要你填 Secret（Private Packagist 用 IP 白名单校验，Packeton 可选 Token 验证），但 Git 平台侧 Content-Type 仍需设为 application/json
• 别试图用 GitHub Actions 或 curl 模拟触发——它们不会被 Private Packagist 或 Packeton 认作合法事件源

最常被忽略的一点：Satis 的 require-all: true 会导致 packages.json 文件爆炸式增长，加载超时甚至内存溢出；而 Private Packagist 默认只同步稳定 tag（vX.Y.Z），dev 分支和非语义化 tag（如 release-1.2）会被跳过——这些行为差异不体现在 Webhook 日志里，得查构建日志或输出文件才能发现。