文档代码基线：
codex/next-internet-v01@729113b89e6dea59033b64c2aab3dca0c28f5fc3，远端核对时间2026-10-03 12:32 UTC。版本号仍是alpha.29，但不能据此把所有alpha.29报告归为同一源码。
你已经有一个 Agent 和若干服务。现在要解决三个具体问题：没有权限的请求不能到业务函数里；主服务不可用时，备用路径不能获得更多权限；结果丢失或失败时，系统不能假装成功，也不能盲目重复执行。
当前版本：
0.1.0-alpha.29；状态：VERIFIED_LOCAL_CANDIDATE / NOT_DEPLOYED对外许可与发行资格：NOT_ADJUDICATED，见 许可审计
TINP 当前提供候选运行时，已有本机多进程验证，也已有本地优先 Wi-Fi/LAN 承载实现；这里的最短示例使用本机 TCP。现有代码不等于已经完成真实物理双机的生产验收。它在受控执行入口检查身份、权限、会话和路由，执行后核对结果与请求的绑定。独立 Provider SDK 尚未稳定发布，接入自己的业务仍需要源码级 PoC。
前置条件：Node.js 22+、可运行 OPP 依赖的 Python（OPP 要求 3.10+）。在 TINP 仓库根目录执行：
python -m venv .venv-doc-demo
$py = Join-Path $PWD '.venv-doc-demo/Scripts/python.exe'
& $py -m pip install -r adapters/requirements.txt
$env:NEXT_INTERNET_PYTHON = $py
node scripts/business-demo.mjs --out .runs/business-demo-doc.jsonNEXT_INTERNET_PYTHON 明确告诉 Node 子进程使用刚安装依赖的 Python，避免“依赖装进一个环境、适配器调用另一个环境”。macOS/Linux 使用虚拟环境的 bin/python 并导出同名环境变量。请使用新的输出文件名保存每次结果。
此命令会启动三个本机节点进程，发送真实本地 TCP 请求，并人为关闭 Provider 或阻断链路。演示文字写的是客户订单请求，但实际 Provider 是确定性的 counter，没有连接 CRM，也没有读取真实订单。
| 步骤 | 代码施加的条件 | 应观察的执行路径 | 服务等级 |
|---|---|---|---|
| 正常 | C 可用，链路正常 | A → B → C；C:counter | Full |
| Provider 故障 | 关闭 C 的 Provider | A → B；B:counter | Essential |
| 链路故障 | 恢复 C，双向阻断 A-B | A → C；C:counter | Reduced |
这三步都应显示 executed。核对主体、会话和权限租约根是否保持一致，并分别保存新的回执根和证据根。会话、端口和根是运行时值，不应要求它们等于另一台电脑的常量。
“所有 Provider 不可用”不在这个三步脚本里；它来自独立的 tests/profiles.test.mjs 测试，应明确返回不执行/延后状态，而不是写成 business-demo 已经输出的第四步。
- 定义该能力的输入、输出、版本与权限要求
- 提供 Provider manifest 和实际处理函数
- 把处理函数放在执行端检查之后，不能先执行再拿回执补验收
- 把结果与请求、主体、会话、租约、路由和 Provider 绑定
- 覆盖未授权、撤权、契约漂移、重复请求、Provider 故障、结果丢失等负例
当前入口是 InternetSuite.start() / suite.use(...) 及内部 Provider 路径；不要把设计中的 registerProvider 等接口写成已经发布的 API。现有真实服务如果还有绕过受控入口的凭据或直接访问路径，TINP 不会自动阻止那个旁路。
执行前检查失败：拒绝当前受控业务执行。执行后回执失败：不接受为已验证结果，但不能撤销此前已经发生的动作。节点失联或响应丢失不等于业务必然未执行；需要按对应恢复路径核对，不可把重试理解为天然安全。
OPP 生成 native interop result → TINP 校验其结构和各层 root → 生成 acceptance binding。
在 TINP 仓库根目录运行下面的只读校验示例。它读取已有证据，不重新调用 OPP 或任何业务 Provider：
node --input-type=module -e "import fs from 'node:fs'; import {makeOppNativeInteropAcceptance,validateOppNativeInteropAcceptance} from './src/opp-native-interop.mjs'; const interopResult=JSON.parse(fs.readFileSync('evidence/OPP_NATIVE_INTEROP_2026-09-12.json','utf8')); const acceptance=makeOppNativeInteropAcceptance({interopResult}); console.log(JSON.stringify({acceptance,verified:validateOppNativeInteropAcceptance(acceptance,{interopResult})},null,2));"预期 verified:true、acceptance 的 status:'PASS'、authorityGranted:false、sideEffects:false。这说明该验收动作没有新增执行权限或副作用；不是说 OPP 此前绝对没有执行任何动作，也不是把任意 OPP bridge 自动接入 TINP 在线授权执行链。
当前仍为 alpha.29 / 本地验证候选，不承诺生产 SLA、独立安全认证或跨设备生产部署。对外许可与发行资格仍按 docs/LICENSE_AUDIT.md 的 NOT_ADJUDICATED 状态处理。
adapters/requirements.txt 声明 jsonschema>=4.23。从 729113b 开始，npm test 通过 scripts/test.mjs 运行：未指定 NEXT_INTERNET_PYTHON 时创建项目内 .tinp-python 并安装依赖；指定时只检查该解释器，不替你修改它，缺依赖就明确失败。
npm test前面的业务demo仍显式设置自己的虚拟环境，因为自动引导属于测试入口，并不自动修改之后任意终端命令的环境。可单独运行 npm run python:bootstrap 建立测试环境；旧的无引导测试入口是 npm run test:raw。
历史 alpha.29 INTEGRATION_COURT 记录209/209；新提交的 tinp.txt 记录223/223。这是两份不同的运行材料，不是相互替代的“当前测试总数”。729113b 又增加了原型链负例。现收到第二轮报告，明确在后续文档提交 db6ab547 上重跑并记录225/225；这一数字来自报告实测记录，不是从新增测试数量推算。
使用者新提交的《OPP / TINP 兼容性与性能测试报告（第二轮）》明确记录了对 OPP main@e3dec213、TINP codex/next-internet-v01@db6ab547 的重新测试。以下是该报告的实测记录摘要；不能继续将这些项目写成“尚未复测”。
| 复测项目 | 第二轮报告结果 | 来源 |
|---|---|---|
| TINP干净环境依赖引导与完整套件 | 隐藏系统Python的jsonschema后，自动建立项目虚拟环境，225/225通过、0失败 | §2.1 |
| 第一轮26个篡改探针 | 26/26检出；原继承属性漏检现被拒绝 | §2.2、§3.2 |
| 新增9个原型相关探针 | 8个非法输入被拒绝；1个允许的null-prototype对象通过，不计为漏检 | §3.2 |
| 合格结果与验收绑定 | 合格样本2/2接受；验收绑定篡改7/7拒绝 | §3.2 |
| OPP握手、协商、显式降级 | 150/150、180/180、30/30；包括应拒绝的预设场景，不是任意请求全部执行 | §3.1 |
| OPP→TINP联合链 | 15/15完成并验证一致；验收均为authorityGranted:false |
§3.3 |
第一轮记录中的依赖故障和25/26篡改识别率保留为历史观察；第二轮说明对应问题在被测版本与测试范围内已通过回归。第二轮没有重跑OPP的Windows符号链接权限测试，不能把上一轮66项结果当成新的完整OPP套件结果。
性能记录也限定于报告的ASUS TUF Gaming F16 / i9-14900HX、Python3.14.7、Node24.19.0环境：
- 库内：OPP ADAPT协商平均4.513ms；TINP诚实回执校验平均58.6µs（§4.1）
- 进程端到端：OPP interop run平均233.6ms；联合链15次平均228.9ms（§4.3）
- 宽接口：100/500/1000字段平均132.87/641.57/1280.28ms（§4.4）
这些数值不能当成其他机器的门槛或生产SLA。报告把字段扩展称为“平方级”，但所列100–1000字段整体耗时接近线性；源码虽有逐目标字段扫描源字段的匹配部分，整体复杂度仍需更多规模样本和剖析确认。§4.3的“TINP联合侧126.9ms”与正文约0.06ms口径不一致，本文不据此推导耗时分摊比例。
证据层次：第二轮报告明确记载已跑过，不等于本文作者又独立重跑了一次。 报告列出原始JSON、TAP与五个测量脚本，但此次只收到报告正文，尚未独立核对那些原始文件；完整复跑命令也未逐条给出。另一项本机基准与这份第三方复测分别记录，不互相替代。
以下第一轮材料尚未连同其全部原始数据在本仓库归档，未给出可核对的源码commit。它们不覆盖上面已有明确版本的第二轮复测，保留是为了呈现变化经过。
| 来源与精确位置 | 材料显示什么 | 能支持到哪里 |
|---|---|---|
opp.txt L6–134、L139–218、L219–258 |
初次先运行后安装报ModuleNotFoundError；安装后66项：64通过、1跳过、1个WinError1314；业务demo为PASS |
该终端环境里的安装、测试与固定demo；不是完整测试全部通过 |
tinp.txt L9–68、L70–71、L314–323 |
alpha.29三步故障demo；旧式test入口；223项通过、0失败 | 该次本机运行；源码commit未知，不能当729113b完整复测 |
OPP-TINP兼容性测试报告.pdf p4–9 |
补依赖后TINP223/223；OPP64通过/1失败/1跳过；握手150/150、协商180/180、联合12/12；篡改检测25/26 | 报告自述的受控样本，包含负例；不是通用可靠性或独立认证 |
report.md L3–16、L42、L63–77 |
每场景1000次、25,000记录；HTTP完整链1000/1000、均值45.248ms；自述33/33复核 | Ryzen9700X/Python3.12.14、单机合成数据与本地HTTP；未随附samples/summary/manifest，未在本次重算 |
PDF p4/p10 的缺依赖失败需要保留为当次观察。其“未声明依赖”的解释与已查源码中存在requirements不同：旧代码通过默认python调用，声明依赖并不保证该解释器安装了依赖。新TINP测试引导是后续代码变化，不能用来否认报告当时失败。
性能口径也不能混用：PDF p6 的CLI进程端到端约230.0ms（n=12），p8 的TINP校验47.11µs；report.md 的本地HTTP全链路45.248ms（n=1000）来自另一台机器和另一条路径。它们不能组成“优化前后”的结论。恢复样本是调用者显式切换健康Provider后的重新调用，不是生产自动恢复率。
- 三步业务demo：证明固定本地受控能力在指定故障下的路径与证据变化，不证明真实订单系统接入
- 执行前/执行后测试：区分前置拒绝、合法执行与回执篡改，不把“全拒绝”当成正确实现
- OPP验收证据：证明指定结果的验收绑定，不授予执行权限
- 数字只能描述其场景与样本；本地负例通过不能外推公网可靠性或生产安全
PDF报告记录一个原型链篡改漏检。旧基线 1164705d 的 exact() 没有显式检查原型，与该观察方向一致。729113b 已增加递归 assertCanonicalJsonData()，限制对象/数组原型、属性描述符、有限数值和循环引用，并新增顶层/嵌套继承属性的负例测试。第二轮报告现明确在 db6ab547 上复跑原26个探针并记录26/26检出，另给出原漏洞拒绝输出；历史25/26保留为修复前观察。原始探针文件尚未随报告提供，本文未另行重算该结果。
TINP 不是用来取代这些工具的。
| 技术 | 主要解决什么 | TINP 补在哪里 |
|---|---|---|
| MCP | Agent 怎么发现和调用工具 | 调用前后的身份、权限、失败和证据 |
| A2A | Agent 与 Agent 怎么通信协作 | 执行治理、节点、权限和恢复 |
| gRPC / REST | 服务怎么发请求和收响应 | 不替代 RPC；关注请求背后的主体和执行状态 |
| OAuth / OIDC | 认证与授权委托 | 可以一起使用；TINP 不替代 OAuth/OIDC |
| Temporal | 持久工作流和重试编排 | 有恢复问题交集，但 TINP 不是工作流引擎 |
| Kafka / RabbitMQ | 消息传输、队列和缓冲 | TINP 不重新发明消息队列 |
| OPP | 能力是什么、两个系统能不能接 | TINP 接管身份、权限、路由、恢复和证据 |
更完整的说明见 docs/COMPARISON.md。
flowchart LR
A[请求与会话] --> B[传输到执行节点]
B --> C{执行前准入检查}
C -->|拒绝| D[不进入业务执行]
C -->|允许| E[执行能力]
E --> F[结果与签名回执]
F --> G{调用端核对}
G -->|不通过| H[拒收结果或保留未决状态]
G -->|通过| I[记录已验证结果]
当前准入检查在 src/node-process.mjs 中调用 RCL 路由规则和事务规则，之后才进入业务计算。调用端的 verifyReceipt 则核对签名、请求、会话、租约、结果等绑定关系。
回执不是“事情绝对正确”的证明：签名用于核对来源与完整性；字符计数示例还会独立核算结果。任意业务的正确性仍需要各自的验收条件。
仓库已有 Wi-Fi/LAN 本地优先承载、非loopback绑定、发现候选和RCL门控实现。发现候选不自动成为可信节点；这些代码和本机测试不代替真实双物理设备的独立验收。
| 术语 | 一句话解释 |
|---|---|
| Continuity Root | 表示“还是同一个主体连续状态”的根标识；不是现实身份证明 |
| Authority Registry | 当前规则下哪些签署方、公钥和角色被认可的候选注册结构 |
| Evidence Ledger | 按顺序保存执行证据，并用哈希链连起来的账本 |
| Recovery Anchor | 外部保留的已知恢复锚点，用来帮助发现回退或旧状态替换 |
| Pending | 无法确认请求是否已经完成时留下的未决状态；默认不盲目重发 |
完整术语表见 docs/GLOSSARY.md。
- 正在做多个 Agent / 服务互相调用的平台团队；
- 需要“谁能做什么、多久有效”这类权限边界的企业内部系统；
- 需要故障切换、恢复和未决状态管理的自动化；
- 需要执行回执、审计证据或失败闭合的试点；
- 边缘、本地、私有网络和弱网络环境的研究验证。
- 只需要简单 API 调用的普通应用；
- 想找成熟生产级 Service Mesh、消息队列或 OAuth 平台的团队；
- 需要现成云控制台、商业 SLA、HSM 托管和大规模生产案例的客户；
- 需要已经完成第三方安全认证的系统。
| 方向 | 现在能看到的价值 | 当前成熟度 |
|---|---|---|
| 企业 / 商业 | Agent/服务调用治理、权限边界、恢复和审计 | 适合原型、PoC、试点 |
| 高保障 / 受监管环境 | fail-closed、断连、恢复、操作员批准、证据 | 有研究价值，但不能宣称生产或认证级能力 |
| 个人 / 生活化 | 本地 AI 的一次性权限、操作历史、跨节点恢复 | 目前只是长期产品化方向，还不是消费产品 |
当前路线不是“alpha 再改几个版本号就生产”，而是有明确验收门：
当前：VERIFIED_LOCAL_CANDIDATE
↓
稳定第三方集成接口
↓
真实两台设备闭环
↓
生产 Authority + 密钥生命周期
↓
可信时间 + 独立第三方接入
↓
独立安全评估
↓
才讨论生产部署
最关键的未完成项包括：
- 稳定第三方 Caller / Provider 接口；
- 真实物理多机验证；
- 生产 Authority Owner；
- 完整密钥生成、托管、轮换、撤销与恢复；
- 可信外部时间与透明历史；
- 独立第三方 consumer；
- 独立安全评估。
完整路线见 ROADMAP.md 和 docs/NEXT_GAP.md。
当前没有被证明的能力包括：
- 公网规模部署；
- 两台真实物理设备之间的生产级运行；
- 无引导节点的公网发现；
- 生产 Authority Provider；
- HSM / 专用硬件密钥托管；
- 可信外部时间；
- 全网分布式共识和互联网规模状态收敛；
- 高影响外部动作的 exactly-once 保证；
- 完整跨设备密钥迁移；
- 第三方或军用安全认证。
当前 TLS、恢复、分发和收敛证据主要来自本机受控环境。
BUSINESS_DEMO.md— 业务故障 Demo：Provider / 链路切换与运行证据导出DEMO.md— 技术最小 Demodocs/ENFORCEMENT_AND_EVIDENCE.md— 执行前拒绝、执行后核对及测试docs/INTEGRATION.md— 怎么接自己的 Agent / Providerdocs/COMPARISON.md— 和 MCP / A2A / OAuth / Temporal / MQ 的关系docs/GLOSSARY.md— 术语翻成普通话docs/USE_CASES.md— 什么时候值得用 TINPdocs/REAL_WORLD_EXAMPLES.md— 现实业务映射docs/ARCHITECTURE.md— 架构和模块分工docs/NEXT_GAP.md— 当前最短真实缺口docs/EXTERNAL_ACCEPTANCE_GATES.md— 外部验收门ROADMAP.md— 从试点到生产的路线SECURITY.md— 安全边界与报告方式docs/LICENSE_AUDIT.md— 当前许可审计
当前仓库的对外许可与发行资格仍是 NOT_ADJUDICATED。
公开仓库不等于所有历史组件都自动拥有统一开放许可。特别是 vendor/ 中的固定历史快照不能因为上游后来出现新许可证，就自动追溯获得同一结论。
如果要对外打包、再分发或商业发行，请先完成各来源组件的许可核对与裁决。详见 docs/LICENSE_AUDIT.md。
新增 @taowind/tinp-suite/sdk/v1.mjs，公开现有只读 Provider 与回执入口，仍是未发布候选，非通用 Provider 注册 SDK。独立安装包实测 Open-Meteo 请求与离线复核成功；httpbingo 的 HTTP 402 作为失败保留。OPP 三个真实库的回执由 Node 复核通过，但两边仍是同一操作员。
SDK 接入 · 五项目实测 · ROADMAP。此前章节描述 alpha.29 基线，本节为当前候选增量；未解除真实双机、Authority Provider、可信时间或独立审计门。
GitHub 远端执行 34692267549 的 Linux 生产端及 Linux / Windows 复核端全部成功。真实库运行与证据交接已离开当前电脑；仍不代表双物理设备、独立操作员或真实 Authority Provider。
Final code replay: 34692507409, all three hosted jobs PASS; OPP 7c4970c, TINP 692c0e4. The earlier run is retained as historical evidence.