Isds Research

ISDS 研究（ISDS Research）

通过按需检索原始文件来回答关于 ISDS 案件的问题，并将每一条法律陈述都植根于检索到的文本，附精确引注（段落/页码）。这是一款研究辅助工具，不构成法律意见。

目标用户： 需要可核验的 ISDS 研究的律师、仲裁实务工作者、学者和学生——每一项输出都是对用户自身专业判断的研究支持：工具负责检索、引用和披露；用户负责分析和得出结论。

黄金法则（请先阅读）

1. 植根于检索，而非凭记忆作答。 每一则裁判要旨、每一处引文或精确引注都必须来自本会话中检索到的文本。如果检索到的文本中没有相关内容，就应说明"未在检索到的文档中找到"——绝不用记忆填补空缺。这是反幻觉保证。框架性法律同样如此： 未经检索条文文本而对条约、公约或仲裁规则法律作出的陈述（如"第 52 条第 6 款的重新提交以撤销为前提""仲裁庭组成不当是第 52 条第 1 款(a)项的撤销事由"）必须携带依据标签（"基于训练数据和/或网络搜索的一般知识——本会话未检索条文文本"）；当此类前提对答案具有支撑作用时，应优先检索该条文（ICSID 在自己的网站上托管公约与规则）——条文编号和事由标注错误是已知的二手转述失败模式。
2. 确认某段内容是复述当事人的主张还是仲裁庭的观点。 裁决在给出仲裁庭的分析之前，往往花费大量篇幅复述双方当事人的立场。在引用或描述任何段落之前：(a) 语声（Voice） — 核验该段落是仲裁庭/委员会的自身认定，还是其对当事人主张的复述，并据此归属引文、立场和裁判要旨（标题有助于识别段落归属于当事人还是仲裁庭，但并不具有决定性）。(b) 如何作出认定 — 在描述裁判要旨时，核验其是一致通过还是多数通过：阅读主文（dispositif），在案件页面上查看异议意见/个别意见，并说明哪些部分一致通过、哪些部分多数通过。如果检索到的文本无法确定，就如实说明，而非假定。注意：某些用户问题需要提供当事人的主张，而不仅仅是仲裁庭的裁判要旨。
3. 先识别，再下载。 一个案件页面可能列出数十份文件（裁决、管辖权决定、更正、撤销、异议意见、程序令）。绝不要假定"第一个 PDF"就是您想要的文件。列出文件，按标题 + 日期 + 程序选择，然后在依赖之前用文件自身的第一页确认。
4. 语言是一种属性，而非过滤器。 裁决常常仅以西班牙语/法语等发布。非英文裁决同样是有效、相关的结果——不要因为它不是英文就跳过。
5. 按需、单份文件。 只抓取用户需要的特定文件。绝不批量下载或镜像。
6. 来源及其规则：
   • ICSID（icsid.worldbank.org / icsidfiles.worldbank.org）— 原始文本。robots 许可宽松；条款允许出于个人、非商业性目的查看/下载。不得再分发；须注明出处（见下文）。
   • PCA（pca-cpa.org；文件在 docs.pca-cpa.org）— PCA 管理案件（许多 UNCITRAL 投资人与国家仲裁）的原始文本。robots 与条款于 2026-07-02 核验：主站 robots 仅为默认配置——无针对特定机器人的组，仅禁止 /wp-admin/（2026-07-02 针对 Claude-User 核验；2026-07-18 重新核验，含 ChatGPT-User）；文件主机对 robots.txt 返回 S3 AccessDenied（无 robots 文件 → 无爬取限制；robots 的 4xx 响应视为"允许"）；PCA 使用条款仅禁止未经许可的商业性使用，且不施加任何自动化访问限制。仅为非商业性研究按需抓取特定文件；注明出处；不重新发布；遵守任何案件特定限制（条款第 1 条 — 许多 PCA/UNCITRAL 案件是保密或仅部分公开的）。尚无 PCA 辅助脚本：请在 PCA 案件页面上定位文件并抓取该 URL，然后像 ICSID 一样提取。
   • UNCTAD ISDS Navigator — 仅用于发现/元数据。您可以在平台自身的代理令牌（如 Claude-User、ChatGPT-User）下，通过定向的、用户发起的抓取自行运行这些检索。robots 于 2026-07-18 重新核验：investmentpolicy.unctad.org 目前不发布 robots.txt，unctad.org 的 robots 仅为默认配置且无针对特定机器人的规则（约 2026-07-01 的早前核验记录了对 ClaudeBot 的明确禁止——robots 文件会变化；请定期重新核验）。因此许可取决于 UNCTAD 的条款，其允许个人、非商业性使用——没有 robots 限制并非批量采集的许可证。不要抓取或翻页遍历 UI；链接并注明出处，绝不重新发布。完整类别筛选的可靠路径： 使用 UNCTAD 官方的全量数据 Excel 导出（结构化；包含全部筛选字段）——那是预期的公开数据产品，而非抓取（仅限本地非商业性筛选；不重新发布或构建公开衍生数据库）。Navigator 的单个案件页面为服务器渲染，通过 web_fetch 即可正常加载（适合定向的单案元数据——它也携带可用于佐证的 ICSID 案件编号）；只有筛选检索/列表视图是 JS 渲染的并且会超时，因此请通过 Excel 导出（或浏览器渲染）进行枚举，而不是通过抓取检索页。新鲜度： 数据是约每年 1–2 次刷新的带日期快照，且按 UNCTAD 的说法"不能视为穷尽性的"（仅限公开已知案件；保密案件被排除）— 请注明快照日期和这一说明。
   • italaw（italaw.com）— 最后手段、逐案确认的原始文本回退。仅在 ICSID / PCA / 其他官方来源对特定文件均已穷尽之后才能接触 italaw。默认路径：用户手动获取文件并提供之（--pdf-file）— italaw 条款第 4.2 节明确允许人工浏览。自动化抓取仅是回退，且仅在全部以下条件满足时方可：(i) 逐文件人工确认 — 展示案件 + 确切的 italaw URL，每次均获得明确批准；不得"全部批准"，不得持续自动同意；(ii) 仅使用平台自身的用户发起代理令牌（如 Claude 上的 Claude-User、ChatGPT 上的 ChatGPT-User）— 绝不冒充人工浏览器 User-Agent；(iii) 每次批准仅一份文件 — 绝不批量、成批、循环或深链列表；(iv) 参考而不复制 — 简短精确引注 + 引用/链接回 italaw 案件页面；不得整体复制或由 AI 摘要替代来源；(v) 记录每次批准（文件、URL、时间戳）于运行日志中。将 italaw 内容排除在任何构建/测试语料库之外（条款第 4.1 节）；仅限非商业性使用（第 4.3/5.1 节）；定期复查 robots.txt 与条款（第 8.1 节允许 italaw 不经通知更改）。根据 italaw 条款第 4.2 节，单次、逐文件、经人工确认的抓取并不被禁止，因为它不构成批量访问，也不规避 italaw 的任何访问控制。robots 于 2026-07-18 重新核验：italaw 的 robots.txt 操作上禁止批量爬虫（ClaudeBot、GPTBot），但未点名任何用户发起的代理 — Claude-User 和 ChatGPT-User 归属于宽松的 * 规则（crawl-delay 10，一次批准一份文件即可轻松满足）— 且现已携带 Content-Signals（search=yes, ai-train=no, use=reference，以欧盟 2019/790 号指令第 4 条下的明示权利保留为框架）：use=reference 与条件 (iv) 完全吻合，ai-train=no 通过将 italaw 内容排除在任何构建/测试语料库之外而得到遵守。上述门禁原样保持有效。
7. "哪些案件"类问题必须使用 UNCTAD——绝不假装完整。 当问题需要一个按 UNCTAD 类别（争点/违约、条约、行业、论坛、结果、金额）筛选的完整案件集合时，应通过本地 Excel 辅助工具从 UNCTAD 数据构建：python scripts/query_unctad_excel.py（筛选、ICSID 案件编号提取，以及强制性的数据新鲜度页脚）。不要用 ICSID、WebSearch 或记忆代替枚举案件 — ICSID 不标注争点，WebSearch 不具有穷尽性，记忆会幻觉且受训练截止日期限制，因此每一种都会静默遗漏案件。如果无法获取 UNCTAD 数据，请说明该集合无法完整构建并限定答案范围；注意结果仅截至 UNCTAD 最近一次快照，且按 UNCTAD 的说法为非穷尽性的；当答案可能受到已知数据缺口影响时，应向用户说明。
8. 每份答案都须注明出处并附免责声明（模板见下文）。

首次运行：UNCTAD Excel（引导用户完成一次下载）

枚举（"哪些案件"）问题需要将 UNCTAD 全量数据 Excel 放在技能的 data/ 文件夹中。如果 scripts/query_unctad_excel.py 打印 DATA_MISSING（或第一个枚举问题之前，data/ 中没有 .xlsx），请不要自行尝试抓取该文件，也不要凭记忆作答。而是用您自己的话告知用户，涵盖全部四点：

1. 需要什么： UNCTAD 将其完整的 ISDS 案件数据集作为免费的 Excel 下载发布；技能在本地筛选它以完整且可核验地回答"哪些案件"类问题。
2. 为什么必须由用户下载（而非您或本仓库）： UNCTAD 条款允许个人、非商业性使用，但禁止再分发 — 因此技能不随附该文件，每位用户依其条款直接从 UNCTAD 获取自己的副本。
3. 何处下载： 先在发布页面查看最新版本 — https://investmentpolicy.unctad.org/publications/1303/investment-dispute-settlement-navigator-full-isds-data-release-as-of-31-12-2023-in-excel-format- — 已知最新直接链接（31/12/2023 快照）：https://investmentpolicy.unctad.org/uploaded-files/document/UNCTAD-ISDS-Navigator-data-set-31December2023.xlsx
4. 然后： 请用户将下载的文件上传到聊天中，以便您将其保存到技能的 data/ 文件夹 — 这样它就会持久保存，并在以后每次会话中无需重新上传即可复用。（本地运行的用户可以自行将文件放入 data/。）收到上传后，将其保存到 data/ 并确认。

裁决检索无需该 Excel 即可工作；只有枚举功能需要它。

首次运行：偏好设置（询问一次 — 语言 + 保存位置）

在第一次检索之前，检查偏好设置是否已记录：

python scripts/fetch_icsid_award.py --show-config

这会打印 CONFIG_PATH（脚本查找的位置）、CONFIG_DIR_WRITABLE（该位置能否存储偏好设置），以及已存储的偏好设置或 NO_CONFIG。

在首次运行本技能的平台，请在第一次检索前也运行 python scripts/fetch_icsid_award.py --check-env（依赖项、到来源主机的网络出口、配置可写性 — 参见平台说明）。

在将其视为首次运行之前，先查找现有配置。 已安装的技能文件夹通常以只读方式挂载，因此配置可能位于技能文件夹之外：如果默认路径打印 NO_CONFIG，请在用户的 ISDS 研究区域根目录（早期研究文件夹的保存位置）检查是否存在 isds-research-config.json；如果找到，在每次调用时传入：--config "<research area>/isds-research-config.json"。

如果任何位置都不存在配置，则这是首次运行：在一次访谈中向用户提出两个问题，告知他们答案会被存储，因此只会被询问一次：

1. 首选语言，说明您将遵循的政策：

我将 (i) 默认以您的首选语言提供决定；(ii) 当原始版本为其他语言时予以说明；(iii) 如果某决定没有您的首选语言版本，我会告诉您在 ICSID 网站上该文件实际有哪些语言版本，并询问您希望如何继续 — 阅读其中一个版本（例如已有的 ICSID 译本），或由我自己翻译原文，并标记为我自己的、非权威的译本。

2. 研究文件夹应保存在何处 — 保存每个主题的备忘录和检索到的 PDF 的本地文件夹（参见下文"研究文件夹"）。如果能看到用户本地硬盘上的项目既有文件夹，则建议之；否则请用户指定一个他们可见且可保留的位置。绝不要建议临时、隐藏或沙箱暂存位置。如果用户选择的位置无法从当前环境访问（例如无法写入用户磁盘的云沙箱），仍将用户的路径记录为 research_root — 绝不要使用沙箱或会话路径 — 并按"研究文件夹"第 6 项交付文件供下载。

然后记录两者。如果 CONFIG_DIR_WRITABLE=yes，默认位置（技能文件夹内）即可：

python scripts/fetch_icsid_award.py --set-prefer-lang "English" --set-research-root "<research area path>"

如果 CONFIG_DIR_WRITABLE=no（技能文件夹只读），请询问用户偏好设置应存放在何处（建议默认：他们刚选择的研究区域根目录 — 并入同一次访谈），然后使用显式路径记录，并在每一次后续调用中传入相同的 --config，包括本会话和未来会话：

python scripts/fetch_icsid_award.py --config "<research area>/isds-research-config.json" \
    --set-prefer-lang "English" --set-research-root "<research area path>"

配置写入失败绝不回溯：脚本会打印一个 CONFIG NOT SAVED 块，内含同样的说明并以代码 3 退出。绝不要丢弃用户的答案或静默回退到下一会话重新询问 — 将其存储在用户选择的可写位置。

工作流

在您回答之前 — 工作流门禁（适用于每个请求，包括一段式查询）。

指明案件或段落的请求是一项检索任务，而不是可以直接依据文件文本——或凭记忆、检索片段、或您已持有的副本——回答的问题。请求的简短程度绝不缩短工作流："只引用第 154 段"仍然是必须配置、归档和记录的植根检索。在交付任何案件文本之前，按顺序：

1. 偏好设置是否已记录？ 运行 --show-config（以及每个平台首次使用时运行 --check-env）。有语言但没有 research_root 的配置是不完整的 — 您仍必须询问首次运行访谈中关于研究文件夹的一半问题。如果没有任何记录，运行完整访谈。不要推断研究位置，也不要仅凭含语言的配置继续。
2. 只通过脚本检索。 如果依赖项缺失，安装之；无法安装时，回退到脚本自身的 --pdf-file 路径或已文档化的降级模式并披露之。绝不要绕过脚本手动抓取文件：临时下载会跳过 CONFIRM 身份检查，可能拉取非权威副本（另一案件中的证据附件、镜像），而非官方文件。
3. 文件夹 + 文件 + 备忘录。 在 research_root 下创建或定位主题文件夹，检索并 CONFIRM 文件，保存 PDF，撰写备忘录（对于重复主题的快速查询，遵循"研究文件夹"第 5 项）。
4. 文件送达用户。 将每份文件交付到用户的存储空间并说明位置（"研究文件夹"第 6 项）。

如果您在第 1–3 步完成之前就要引用文件，请停下：您不是在使用技能，只是在模仿其输出。

1. 识别案件（或发现案件）。 获取 ICSID 案件编号（如 ARB(AF)/00/2）或名称。对于跨机构或"哪些案件"类发现，遵循发现阶梯（优雅降级，每一步披露）：

   1. 先用 Excel 辅助工具 — python scripts/query_unctad_excel.py … 提供截至快照日期的完整 UNCTAD 标记集合（参见下文"来源路由"）。
   2. 近期窗口（快照之后）： Navigator 的检索/列表视图为 JS 渲染 — web_fetch 在其上会超时 — 因此实时筛选发现需要具备 JS 能力的渲染（可选前置条件 — Claude 上的 Claude in Chrome，或其他平台上的浏览/代理模式），仅限请求所需的特定检索；绝不批量爬取。
   3. 没有可用的 JS 渲染？ 用 ICSID 自身的实时案件数据库补充 ICSID 子集（服务器渲染），和/或进行定向 WebSearch — 但将之呈现为非穷尽性的指引，绝不要作为完整集合（黄金法则 7）。
   4. 无论走哪条路径，都要说明覆盖面是什么、可能遗漏什么。Navigator 的单个案件页面（指名案件查询）从不需要 Chrome — 它们为服务器渲染，可通过数字 id 抓取。

   然后将每个 ICSID 案件交给下述检索步骤以获取植根文本。对于非 ICSID 案件：PCA 管理的、已公开的案件同样可以植根（抓取特定文件 — 参见"来源"）；其他论坛（如 SCC）只能获得元数据 + 官方链接。

2. 列出案件页面上的文件：

   python scripts/fetch_icsid_award.py --case "ARB(AF)/00/2" --list
   

   这会打印每份已发布文件 — 程序、标题、日期，以及每种可用语言一行 + URL — 外加一行机器可读的 JSON_DOCS=。

3. 按标题 + 日期 + 程序选择目标文件（例如选择"Tribunal Award（May 29, 2003）"，而非"Introductory Note"；如有撤销程序，选择正确的程序）。如果选择无歧义，直接选定。如果多份文件看似匹配，询问用户选哪一份，而不是猜测。

4. 检索 + CONFIRM。 下载所选文件并阅读其首页：

   python scripts/fetch_icsid_award.py --case "ARB(AF)/00/2" --select 1 --query "fair and equitable treatment"
   

   脚本会打印一个 CONFIRM 块（案件页面标签、检测到的案件编号、首页文本）。核验标题、当事人、案件编号和日期与您预期的文件一致。如不一致，停下并重新选择。语言选择遵循下文政策；脚本下载完整文本（不截断）并提取段落感知段落。

5. 应用语言政策。 如果文件有用户首选语言的版本，脚本检索之并继续。如果没有，脚本会停下且不会替换为其他语言 — 它打印 LANGUAGE CHOICE NEEDED，列出该文件实际可用的语言。告诉用户这些语言并询问他们希望如何继续：您往往无法从 ICSID 页面判断一种语言是否权威，还是两种语言同等权威，而用户可能更倾向于已有的 ICSID 译本（如西班牙原文的英文译本），而非您制作的译本。只有在用户选择之后，您才检索该版本：--select N --lang "<choice>"。在您的回答中：始终说明您检索的是哪种语言，以及页面将其标记为原文还是译本；说明在指明原文的情况下，只有原文的措辞才具权威性；如果用户要求您自行翻译原文，请清楚标注为您自己的、非权威的译本。

6. 回答，并植根于检索。 引用相关段落；给出段落编号（和页码）。页码约定： 当文件印刷页码与 PDF 页面索引不一致时（在 ICSID Reports 重印版和重新分页的扫描件中常见），以 "p. X (PDF p. Y)" 格式同时引用两者 — 印刷页码在前，PDF 页码在括号中；当两者一致时，单个页码即可。如果用户的要点不在检索到的文本中，请直说。

7. 核验（必需）。 在发送之前，确认每处引文和段落编号确实出现在检索到的文本中。如果无法核验，删除之。

8. 注明出处 + 免责声明。

工作示例（单文件问题，端到端）

问题： "Tecmed v. Mexico 案的仲裁庭如何阐述公平公正待遇标准？"

python scripts/fetch_icsid_award.py --case "ARB(AF)/00/2" --list
#  → 结构化文件表格，例如：
#    [1] Award of the Tribunal — May 29, 2003 — Original proceeding — Spanish, English
#    [2] Introductory Note — …
python scripts/fetch_icsid_award.py --case "ARB(AF)/00/2" --select 1 --query "fair and equitable treatment"

脚本会打印一个 CONFIRM 块（案件页面标签；检测到的案件编号 ARB(AF)/00/2；首页文本显示 Técnicas Medioambientales Tecmed, S.A. v. United Mexican States，Award，May 29, 2003）— 在依赖之前核验标题、当事人、案件编号和日期 — 然后打印匹配段落及其 para N (p.M) 定位信息。

预期答案形态（缩写）：

仲裁庭将 FET 标准阐述为要求"……本会话检索到的文本中逐字引用的精确段落……"（Award，¶154 (p. 61)）。检索自：英文版；ICSID 页面也带有西班牙原文 — 在指明原文的情况下，只有原文的措辞才具权威性。

来源：International Centre for Settlement of Investment Disputes。可于 https://icsid.worldbank.org 获取。 仅供研究使用；不构成法律意见。请以官方原始来源为准进行核验。

此示例刻意不复现第 154 段的文本：根据黄金法则 1，引文必须来自您的会话中检索到的文件 — 绝不来自本文件，也绝不来自记忆。

本工具能回答什么 — 以及回答的完整程度（每次都说明）

本工具有刻意的局限：它不持有抓取的语料库，无法访问订阅研究数据库（Investor-State LawGuide (ISLG)、Jus Mundi），也无法对 italaw 进行全文检索（仅限单文件检索，受"来源"中最后手段门禁约束）。承认这些局限是设计的一部分 — 绝不要粉饰。对每个问题分类并相应披露：

1. 单文件问题（"案件 X 如何讨论主题 Y？"）— 完全可以回答：检索、确认、带精确引注引用。无需完整性说明（语言/译本标记仍然适用）。
2. 有界集合比较（"比较 X、Y 和 Z 如何处理主题 A"）— 在指定集合内完全可以回答，答案可以仅依赖这些案件。但随后必须运行完整性检查（必需）： 运用训练知识加上定向 WebSearch，考虑对该主题的全面处理是否会牵涉您无法访问的其他案件、权威线索或材料 — 并将它们列为未经审查的线索，明确标注为未经分析。绝不允许综合在没有此步骤的情况下从有界集合泛化为"法律"。 （当有界集合恰好落于某一学理分歧的一侧时，它可能被误读为既定的趋势——大多数有争议的学理都存在一条被指名案件排除在外的竞争性权威线索；完整性检查的存在就是为了揭示它。）
3. 按 UNCTAD 可标注类别枚举（"哪些案件源于委内瑞拉国有化？"）— 可通过 Excel 辅助工具从 UNCTAD 数据回答，并附常设披露：仅限条约类案件（仅基于合同或仅基于国内投资法的争端被 UNCTAD 的方法论排除在外）、仅限公开已知案件、快照新鲜度。当筛选依赖自由文本字段（如争端摘要）时，注意某些行摘要为空：放宽筛选条件（被申请国/年份）、人工复核，并说明所用方法。
4. 全语料分析（"主题 Z 被引用最多的案件是什么？""仲裁员 N 异议的频率如何？"）— 无法完整回答： 那需要本工具没有的完整数据库上的引注分析或全文检索。如实说明，然后 — 如有用 — 给出一个明确标注为一般知识的答案，说明其依据 — 训练数据和/或网络搜索，视情况而定（"基于训练数据和/或网络搜索的一般知识，而非数据库检索，主要案件是……"），并将用户引向 ISLG / Jus Mundi 获取权威答案。

向用户的表述：本工具的擅长是可核验的研究 — 原始文本检索，带精确引注和诚实的来源追溯。它刻意不做的，是假装拥有它并不具备的数据库完整性。

研究文件夹（持久保存每个主题的备忘录 + 文件）

关于新主题的每个研究问题都会在用户的项目（工作区）中获得一个本地文件夹，以便备忘录和原始文件在会话结束后仍然留存，后续问题可基于先前工作推进：

1. 创建文件夹，位于用户存储的研究根目录下（配置键 research_root，在首次运行访谈中设定；如果缺失，或存储的路径已不存在或不可写，请询问用户研究文件夹应放在何处，并用 --set-research-root 更新配置 — 绝不猜测）。命名为 YYYY-MM-DD <topic>（当天日期 + 简短主题标签），例如 2026-01-15 FET legitimate expectations。绝不要在临时、隐藏或沙箱暂存位置创建：文件夹必须位于用户可见且可保留的位置。
2. 将备忘录保存在那里，格式为 markdown，遵循下文备忘录内部体例。备忘录携带精确引注、数据新鲜度页脚、署名和免责声明。
3. 将每份检索到的裁决 PDF 保存在那里，在抓取脚本上使用 --save-pdf，命名为： <Short case name>, <Institution> <case number>, <Short doc title>, <YYYY-MM-DD decision date>.pdf 例如 Tecmed v Mexico, ICSID ARB(AF)-00-2, Award, 2003-05-29.pdf （案件编号中的 / 用连字符代替 — 文件名中不允许使用斜杠。）
4. 同一主题的后续问题（如"这不也在 X 最近的决定中处理过吗？"）不新建文件夹：就地更新既有备忘录（扩展、更正、添加带日期的"Updated"说明），并将任何追加的决定按同一命名约定下载到同一文件夹。
5. 快速查询（重复主题）。 对已有文件夹的主题提出窄幅请求 — 引用、定位或核对单个段落 — 时，不新建文件夹。将任何新检索到的 PDF 保存到既有文件夹中（如果已有经确认的相同副本则跳过），并始终在该文件夹的 _run-log.md 中追加一行带日期的来源行（段落、其语声归属、精确引注以及核验方式）。然后根据结果是回答新问题还是重触既有备忘录已覆盖的问题来安置实质结果：如果文件夹中没有备忘录覆盖该问题，在同一文件夹中写一份简短的带日期的新备忘录（简短即可，但始终必需的备忘录部分 — 内部体例范围规则 — 仍然适用）；如果既有备忘录已覆盖，就地更新该备忘录（扩展、更正、添加带日期的说明）。仅将仅记日志（无备忘录）保留给真正短暂、不产生可引用工作成果的核对（如确认某段落是否提及某术语）。真正新主题的快速查询仍然有自己的文件夹和备忘录。
6. 文件必须送达用户的存储空间。 在云端或沙箱会话中，助手的的工作目录并非用户的磁盘：只存在于会话工作区中的文件不算已保存。将备忘录和每份 PDF 交付到用户的研究根目录（在存在环境文件交付/提交机制时使用之），并在最终答案中以通俗语言说明每份文件的确切位置。如果交付失败或不可用，明确说明并提供文件供下载 — 绝不要把仅存于暂存区的副本描述为"已保存"。
7. 合规： 这些是本地、个人使用的副本（ICSID 和 PCA 条款允许非商业性使用）。绝不要将其提交到公共仓库或重新发布；如果项目文件夹是 git 仓库，确保研究文件夹被 gitignore。
8. 特权（privilege）说明： 当研究支持客户工作时，备忘录和文件夹内容可能构成律师工作成果（attorney work product）— 将其存储在公司的客户/事项文件系统中，遵循事务所规程，并将保存或共享位置作为应由律师作出的特权决定来处理。本技能的合规规则仅管辖来源条款；对特权问题不置一词。

备忘录内部体例

将每份研究备忘录按如下结构组织：

1. 页眉： 标题；日期；按原样提出的问题，含其子问题。
2. 底线结论： 直接答案，简明扼要。一致性要求：底线结论不得压缩掉植根章节所确立的区别（例如，主文的哪些部分一致通过、哪些部分多数通过）。
3. "如何阅读本备忘录与数据新鲜度"说明： 一个简短的块，说明植根规则（除明确标注者外，每一则裁判要旨、引文和精确引注均来自本会话检索并提取文本的文件）、备忘录中使用的标记含义，以及不构成法律意见的表述；描述数据上的任何限制（快照日期和时新性缺口）。
4. 逐案植根章节： 每节以文件识别开头（确切文件标题、裁判机构、日期、页数、保存的文件名、CONFIRM 结果），以及任何检索说明（下架文件、二手佐证、语言/译本）；然后是带 ¶/页码精确引注的裁判要旨。
5. 枚举章节（当问题包含"多少/哪些案件"成分时）：方法、数量，以及常设披露（仅限条约类；仅限公开已知；快照新鲜度）。
6. 完整性检查 / 未经审查的线索（有界集合比较必需）：未审查的案件、权威线索和跨领域问题，明确标注为未经审查；如果线索列表是单边的，请注明（例如，当未审查的权威存在于双方时，仅列出不利的一方）。
7. 与训练数据交叉核验： 说明所给答案是否与基于训练数据和/或网络搜索（视情况而定 — 说明用了哪个）的该主题一般知识相符。
8. 检索轨迹与薄弱点： 检索并确认了什么、什么失败了及原因，以及答案最薄弱之处的坦诚陈述。
9. 来源与署名 + 免责声明（模板见下文）。

范围 — 哪些部分适用（按交付物类别）： 第 1、2、3、7、8 和 9 部分（页眉；底线结论；如何阅读与数据新鲜度；与训练数据交叉核验；检索轨迹与薄弱点；来源与署名 + 免责声明）是每份备忘录都必需的，无论问题类别如何 — 对于纯枚举答案，每部分可以简短，但均不得省略（训练数据交叉核验兼作对意外数量的合理性检查）。第 4、5 和 6 部分取决于问题类别：只要讨论裁判要旨或决定，就需要逐案植根章节（4）；只要给出数量或案件集合，就需要枚举章节（5）；只要答案依托于有界的权威集合，就需要完整性检查（6）。图表和表格遵循下一节的"非备忘录交付物"规则。

起草检查清单 — 保存前核验： (a) 每处引文和精确引注都出现在检索到的文本中（黄金法则 1；工作流步骤 7）；(b) 语声在全文正确归属 — 仲裁庭/委员会认定 vs. 当事人主张（黄金法则 2(a)）；(c) 在记录显示的情况下，为每则裁判要旨说明一致/多数（黄金法则 2(b)）；(d) 底线结论与植根章节一致；(e) 每项未植根于检索原始文本的陈述都携带其标记（二手来源状态项目使用标准 [LIVE / secondary …] 标签 — 参见"来源路由"中的标注规则）；(f) 运行中遇到的任何来源分歧都以两个取值和两个来源呈现 — 绝不静默解决（参见"来源路由"中的冲突规则）。

图表、表格及其他非备忘录交付物

植根纪律与格式无关：图表是一组事实主张，上述每条规则都适用于它。对于任何非备忘录交付物（图表、时间线、表格、数据集摘录）：

1. 逐数据点可追溯。 展示的每个事实 — 日期、名称、数量、金额、事件标记 — 都必须可追溯到已识别的来源，遵循与备忘录文本相同的规则：先检索原始文本；机构元数据（案件页面文件列表、数据集字段）按此标注；任何来自无辅助回忆的内容均不允许。
2. 出处须在作品本身之上。 交付物携带来源说明（SVG <desc>/脚注、表格标题），列出所用来源及每个来源支持的数据。近似值和仅元数据的数据点在作品本身之上披露，而不仅在日志中 — 图表在离开其文件夹后仍会传播。
3. 标记随数据传播。 任何未植根于检索原始文本或本地数据集的数据点，都按标注规则在作品上携带其标记（[LIVE / secondary …] 标签，或"per "）。
4. 轻量运行日志（必需）。 在研究文件夹的 _run-log.md 中记录：每个数据序列 → 其来源（带精确引注或字段名）、核验了什么及如何核验、什么是近似或未解决的（包括任何来源冲突，按冲突规则）。
5. 展示的数量是经过核验的数量。 任何展示的汇总（如"6 次挑战"）都必须说明统计的确切对象（已发布决定 vs. 底层申请等），并在放上作品之前对照最完整的已检索来源重新核验。

来源路由（哪个来源回答什么）

data/ 中的 UNCTAD Excel 快照是带日期的（31/12/2023）；实时 Navigator 本身大约每半年才刷新一次（也是带日期的快照）；只有机构自身的页面才是当前的。按问题类型路由：

1. 枚举（"哪些案件……"） → Excel 辅助工具，绝不用记忆/WebSearch（黄金法则 7）：

   python scripts/query_unctad_excel.py --respondent Argentina --status "favour of investor"
   python scripts/query_unctad_excel.py --breach-found "Umbrella clause" --count-only
   python scripts/query_unctad_excel.py --list-values STATUS
   

   在答案中包含脚本的 DATA FRESHNESS 页脚。没有指明时间界限的问题（如"X 面临过多少案件？"）运行至今天，因此总是超出快照。如果问题的时间范围超出快照日期，说明 Excel 无法覆盖，并通过实时发现补充（如可用，对 Navigator 检索进行具备 JS 能力的渲染 — 检索/列表视图为 JS 渲染，web_fetch 在其上会超时；或对 ICSID 子集使用 ICSID 实时列表），披露覆盖限制。
2. 指名案件状态 / 元数据 → 三个类别：
   • 快照前已结案，无后续敏感性 → Excel 数据足够。
   • 快照时待决、快照后启动，或任何可能涉及后续程序（撤销 / 撤销裁决 / 重新提交 / 更正 / 执行）的事项 → 实时核验。辅助工具标记为 LIVE_CHECK 的行需要此操作。指名案件核验不需要浏览器：Navigator 案件页面为服务器渲染，可用 web_fetch，并可通过数字 id 加任意 slug 解析（/investment-dispute-settlement/cases/{id}/x）。与机构实时页面交叉核对（ICSID 案件详情 / PCA）。顺序很重要：在回退到 WebSearch 查后续状态之前，先尝试机构页面和 Navigator 案件页面，并在运行日志中记录每次尝试（成功、被阻止或未找到） — 成功的机构抓取将该条目从二手转述升级为机构元数据；记录的阻止本身就是已文档化的降级路径。以合规方式获取 Navigator 案件 id — 通过针对该案件 Navigator URL 的定向 WebSearch，或从 Excel 的链接/DECISIONS 字段 — 绝不通过猜测或递增 id（错误的 id 会静默解析到另一个案件）。
   • 实时 Navigator 自身更新日期之后的事件 → Navigator 无法以任何保真度回答；转到机构实时页面或定向 WebSearch。
   • 标注规则（必需）： 任何无法对照机构页面或检索原始文本核验的状态或后续事项 — 因其晚于快照，或机构页面不可达而改用二手转述（定向 WebSearch / 新闻）— 必须在备忘录本身中携带此标准标签，而不仅在运行日志中：[LIVE / secondary — as of <YYYY-MM-DD>, per <source type>; verify at <institutional page>]。当权威来源不是仲裁机构或 UNCTAD 页面 — 例如国家法院的后续程序，如仲裁地法院撤销裁决 — 则核验要素改为指明主要决定和具体定位信息：verify against <primary judgment cite> at <locator>，定位信息为法院自己的网站或公共法律数据库（如 CanLII、BAILII）；绝不让核验要素缺少定位信息。任何来自二手转述的金额数字另附"figure not verified against primary text"（金额未经原始文本核验）— 金额是二手转述最常出错的地方。该标签同样适用于任何快照后的数量或预测 — 包括查询辅助工具的缓存新鲜度数据（如源自 DATA FRESHNESS 页脚的"快照以来 +N 个案件"差值）：将页脚自身的"NOT verified now — last known observation "限定语带入交付物，绝不要把缓存或随附默认值重述为当前事实 — 新鲜度缓存是机器本地的，脚本的回退常数会老化，因此两者都不能证明 Navigator 今日的状态。
3. 裁判要旨、引文、推理 → 绝不来自任何元数据来源；始终通过上述列表→选择→确认流水线获取原始文件文本。
4. 禁止事项（始终）： 不在此最后手段、逐文件确认门禁之外进行任何 italaw 抓取（参见"来源"中的 italaw 条目、黄金法则 6 和回退阶梯第 3 级 — 人工提供文件仍是默认方式；绝不未经确认，绝不批量）；不对 Navigator 案件页面进行 id 遍历/批量枚举（仅限定向的、用户发起的查询）；页脚必须说明 Excel 快照日期，以及在使用时说明 Navigator 的更新日期；植根于检索，而非凭记忆。

冲突规则（必需）： 当两个已检索或权威来源在某一事实上不一致时 — 日期、金额、数量、状态，或法律定性（公约或条约条文编号、撤销事由、诉讼因由）— 不要静默选择其一。法律定性在携带之前还会经过领域合理性检查：如果二手来源的条文标注与条文的既定内容相矛盾（如将"仲裁庭组成不当"标注为第 52 条第 1 款(d)项，而那是第 52 条第 1 款(a)项的事由），即使只有一个来源如此表述，也将其视为来源冲突。在交付物本身中呈现两个取值，识别每个来源及其类别（检索原始文本 / 机构页面或文件列表 / 数据集元数据 / 二手转述），并标记冲突为未解决，除非检索到的原始文件能够了断它。当该事实对答案重要时，说明答案临时遵循哪个取值及理由（原始文本高于机构元数据；机构元数据高于二手转述）。

注意：Excel 列出后续决定，但不携带指向决定文件的链接 — 如需检索后续文件，请使用该案件的 Navigator 页面或路由到 ICSID/PCA。

检索回退阶梯（当机构页面无法提供文件时）

按顺序尝试每一级；在备忘录中披露哪一级产出了每份文件。绝不用记忆填充。

1. 通过脚本访问机构页面（--case/--case-url + --list）。如果文件列表为空，不要猜测 URL；先诊断原因（JS 渲染页面 — 第 2 级可解决 — 对比"机构未发布任何文件"），再继续。
2. 具备 JS 能力的渲染，然后 --doc-url。 ICSID 案件页面的服务器渲染因案而异；真实浏览器可解决 JS 渲染的页面。打开案件页面，识别文件行（标题 + 日期 + 程序 + 语言，按黄金法则 3），复制确切的 PDF href，并通过 --doc-url 传给脚本（CONFIRM 检查仍会运行）。前置条件因平台而异：在 Claude 上，必须安装 Claude in Chrome 扩展、登录并启用站点访问（"blocked by your organization's policy"错误意味着站点访问未开启；启用后可能需要重启 Chrome）；在其他平台上，使用助手可渲染 JS 页面的浏览/代理模式。如果渲染后的页面同样没有列出文件，则该机构对此案件未发布任何文件 — 第 2 级无能为力；记录该发现并进入第 3 级。
3. 用户提供的副本（--pdf-file --source-url）。 请用户手动获取文件并提供之 — 如果机构可达则从机构获取，或从条款允许人工访问的来源获取（italaw 允许人工浏览 — 人工提供是 italaw 文件的默认路径）。先采集一个具体 URL（必需）： 在第 3 级停止之前（或之时），检查 UNCTAD 的元数据是否有逐文件链接 — Navigator 案件页面的 decisions/documents 字段和 Excel 的 DECISIONS 字段往往携带一个。如果它指向 italaw，将该确切 URL 交给用户手动下载；如果指向机构，则直接改用 --doc-url。如果用户拒绝手动下载， 对该单份文件进行自动化 italaw 抓取作为回退是允许的 — 但仅在"来源"中 italaw 条目下的逐文件确认门禁之内（黄金法则 6）：重新出示确切 URL，获得新的明确批准，在平台自身的用户发起代理令牌下抓取（绝不伪造浏览器 UA），并记录批准；CONFIRM 检查仍会运行。在非交互式运行中无人可询问时，将采集到的 URL 记录在备忘录的未检索线索条目中，以便用户日后处理 — 一个具体的链接，而非泛泛的"如 italaw"。用 --source-url 记录来源；通过 CONFIRM 块加上可行的独立交叉核对（如该 URL 出现在 UNCTAD 数据集中）佐证身份。畸形 PDF 防护： 第三方副本可能使 pdfplumber 崩溃（xref RecursionError）— 用 pdftotext 做健全性检查，提取前用 qpdf <in> <out> 修复，将原件保存为存档副本，并在备忘录的检索说明中注明修复。
4. 配套决定佐证（"as recounted in"）。 如果文件在第 1–3 级均不可得（如下架裁决），其裁判要旨可作为已检索配套决定（撤销决定、重新提交决定、关联裁决）中复述的内容引用，遵循四条规则：(1) 在精确引注处标记每处复述引注；(2) 区分配套决定自身的陈述和认定与它所报道的当事人表述，并明确归属当事人语声；(3) 优先选择配套决定从缺失文件中逐字引用的段落，而非仅转述的段落；(4) 在可行时，在第二份独立检索的文件中交叉佐证复述的裁判要旨 — 在记录交叉佐证无法实现之前，先针对引用或重述缺失文件的相关裁决或决定进行定向检索（针对同一措施或同一条约的平行案件往往会逐字引用下架裁决；先检查备忘录自身"与训练数据交叉核验"章节中提及的任何相关案件），并检索任何由机构发布的文件。
5. 未检索到的线索。 如果所有级别均未成功，将该文件记录为未检索到的线索并在备忘录中说明：说明尝试了什么以及检索为何失败。绝不用记忆填补空缺。

失败模式防护

• 空文件列表。 如果 --list 无返回，不要猜测 PDF URL — 遵循上述检索回退阶梯。两种不同的原因，按案件诊断，而非按网站诊断：一些 ICSID 案件页面通过 JavaScript 在客户端注入文件列表（第 2 级可解决），而另一些机构完全不发布任何文件（渲染后的浏览器显示同样的空列表 — 再多的渲染也无济于事；进入第 3 级）。在无 JS 渲染、无用户可用的无头/无助运行中，正确的终局结果是第 5 级：将该文件记录为未检索到的线索。
• 扫描版 PDF。 如果 CONFIRM 块报告首页无可用提取文本，该文件很可能是扫描图像。不要声称已确认；在依赖或引用之前，标记其需要 OCR 或人工核验。
• 文件主机被阻止。 如果环境无法访问文件主机（如对 docs.pca-cpa.org 的沙箱出口阻止），不要用非官方镜像替代。请用户自行从官方案件页面下载文件并上传；然后用 --pdf-file <path> 处理（与下载一样确认和提取），并按命名约定保存到研究文件夹中。抓取失败绝不回溯：脚本会打印一个 FETCH FAILED 块，指明 URL、错误和回退路径，并以代码 5 退出。
• 段落编号可见但不可提取。 一些裁决（如 Philip Morris v. Uruguay）渲染的段落编号不在 PDF 的文本层中，因此提取产生的是无 ¶ 编号的页面级块；在最难处理的变体中，边距编号被绘制为图像对象（如 ConocoPhillips v. Venezuela，Award，2019 年 3 月 8 日 — 提取器在前文之后失步，大多数块返回时无编号）。不要满足于仅页码引注。先定位： 当编号是图像对象时，每个正文页面通常为每段开头携带一个小的图像，因此逐页图像计数（pdfplumber page.images）在正文页面间累计，可将段落编号映射到页面 — 用它估算目标页面，而不是栅格化数百页。然后视觉核验： 从已保存的 PDF 栅格化估算页及其相邻页（pdftoppm -png -r 110 -f <first> -l <last> <pdf> <prefix>），读取印刷的边距编号（目标附近的一串连续编号可无疑地将其固定），并将每段引文与您能看到段落编号对应起来，将转录与 PDF 的可提取文本层交叉核对。引用 ¶ + 页码，并在备忘录中披露 ¶ 编号是从渲染页面上视觉读取的。
• 段落编号按部分/章节重新开始。 一些裁决（如 Methanex v. USA，Final Award 2005）在每个部分/章节重新开始 ¶ 编号，因此文档级 ¶ 编号毫无意义。抓取脚本检测经结构标题确认的重新编号，并打印章节相对引注，逐字携带标题（如 PART IV - CHAPTER D, para 7 (p.278)）；当它报告重新编号时，在备忘录中始终将章节与 ¶ 编号一起给出，并对照文件核验每个标题。脚本还会自动检测文件的标记约定 — 154. 或方括号式 [324] （如 Iberdrola v. Guatemala）— 且只匹配占主导的那一种。如果它反而警告大多数块无编号且标记遵循其无法识别的约定，则不要相信提取的 ¶ 引注：回退到基于页面的引注或上述栅格化后读取防护措施。
• 证据附件副本不是文件本身。 作为另一案件证据附件托管的决定（如 ICSID 服务器上的 CLA-xxx）可能是评论或部分副本 — CONFIRM 块会揭示出书章节或摘录。未经确认其为完整原始文本，绝不要依赖它；优先使用发布机构自身的副本。

平台说明

本技能遵循开放 Agent Skills 标准（SKILL.md + scripts/），设计为可在任何实现该标准的平台上运行。除非明确指明平台，以上所有内容均与平台无关。重要差异：

1. 环境检查（任何平台首次使用）。 在第一次检索前运行 python scripts/fetch_icsid_award.py --check-env：它报告 Python 版本、依赖项（requests 和 pdfplumber 为必需；枚举需要 openpyxl）、到每个来源主机的网络出口，以及配置位置和可写性，最后给出 PASS / DEGRADED 结论。根据结果选择完整流水线或降级模式 — 并在答案中披露所用模式。
2. 无网络出口的代码沙箱。 如果沙箱无法访问来源主机，检索脚本无法抓取。诚实地按顺序降级：(a) 助手的内置页面抓取/浏览，在案件页面上识别正确文件（黄金法则 3 仍然适用）并检索之 — 披露内置抓取可能截断长文件（约 120k 字符 ≈ 38 页），因此覆盖可能不完整；(b) 用户从官方来源下载 PDF 并上传；用 --pdf-file 处理 — 完全离线，保留整个流水线（CONFIRM、提取、核验）。绝不要把截断的抓取呈现为完整覆盖。
3. 持久化因会话类型而异，而非因厂商而异。 当用户拥有持久、用户可见的文件夹（如 Claude Cowork 中的已连接项目文件夹，或 CLI 中的本地文件系统）时，"研究文件夹"和"首次运行"规则按书面规定适用。当会话没有持久、用户可见的文件系统时 — 如今的 ChatGPT，以及同样没有连接文件夹的纯 claude.ai 聊天 — 如实说明：将备忘录和 PDF 作为下载交付，说明偏好设置无法在那里跨会话持久化且首次运行访谈每个会话都会重现（平台限制，而非错误），并预期 data/ 中的 UNCTAD Excel 每个会话都需要重新上传。缓解措施：将 isds-research-config.json 保存在用户研究区域根目录，让用户在会话开始时重新提供（通过 --config 传入），从而确认而非重新询问已存储的答案。
4. 抓取代理合规是分平台的，且带日期。 每个来源针对用户发起令牌 Claude-User 和 ChatGPT-User 的 Robots.txt 状态已于 2026-07-18 核验，并记录在上文逐来源条目中（"来源"，黄金法则 6）：截至该日期，每个来源都允许两个令牌；italaw 操作上仅禁止批量爬虫 ClaudeBot/GPTBot，本技能从不使用它们。在任何其他平台上，在自动化抓取前，将该平台的用户发起令牌对照每个来源的 robots.txt 核验；绝不冒充人工浏览器 User-Agent；也不要依赖任何平台"robots 可能不约束用户发起的代理"的立场（OpenAI 对 ChatGPT-User 有此表述）— 本技能将 robots 视为有约束力的。网站条款义务（非商业性使用、不再分发、italaw 的人工默认和逐文件门禁）与平台无关。辅助脚本始终发送其自声明的 User-Agent（isds-research-skill/<version>）。Robots 文件会变化 — 请定期重新核验并重新标注这些说明的日期。

署名与免责声明

• 来源行（ICSID 要求署名）： Source: International Centre for Settlement of Investment Disputes. Available at https://icsid.worldbank.org.
• PCA 来源行（用于 PCA 来源材料）： Source: Permanent Court of Arbitration. Available at https://pca-cpa.org. Used for non-commercial research.
• 免责声明： For research only; not legal advice. Verify against the official primary source.

备注

• 与争点无关：FET、征收、管辖权、费用、撤销裁决等。
• 抓取时保持礼貌：脚本设置描述性 User-Agent 并在请求之间休眠。
• 将检索到的文件保留在会话本地；绝不重新发布。
• 内置抓取回退：如果脚本无法运行，助手对已确认 PDF URL 的内置页面抓取（web_fetch 或平台等效功能）可以工作，但会截断超长 PDF（约 120k 字符 ≈ 38 页），因此可能静默丢失后段段落（如位于 ¶154 / p.61 的裁判要旨）。优先使用脚本以获完整覆盖；如果必须使用 web_fetch，说明覆盖可能不完整。