openworkproof 1.1.0__tar.gz → 1.2.0__tar.gz

{openworkproof-1.1.0/src/openworkproof.egg-info → openworkproof-1.2.0}/PKG-INFO

@@ -1,15 +1,14 @@
 Metadata-Version: 2.4
 Name: openworkproof
-Version: 1.1.0
+Version: 1.2.0
 Summary: Agent work contracts and verifiable execution protocol — Ed25519-signed, offline-verifiable proof-carrying work for AI agents.
-License: MIT
+License-Expression: Apache-2.0
 Project-URL: Homepage, https://github.com/dengyier/OpenWorkProof
 Project-URL: Repository, https://github.com/dengyier/OpenWorkProof
 Project-URL: Issues, https://github.com/dengyier/OpenWorkProof/issues
 Keywords: agent,verifiable,ai,work-contract,mcp,audit,sign,ed25519,proof-carrying,mcp-server
 Classifier: Development Status :: 5 - Production/Stable
 Classifier: Intended Audience :: Developers
-Classifier: License :: OSI Approved :: MIT License
 Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
@@ -35,12 +34,22 @@ Dynamic: license-file
 
 # OpenWorkProof
 
+<!-- mcp-name: io.github.dengyier/OpenWorkProof -->
+
 > Agent 可以生成结果，但凭什么交付？
 > Agent Work Contracts and Verifiable Execution Protocol
 
+<div align="center">
+  <a href="README_en.md">English</a> | <strong>中文</strong>
+</div>
+
+---
+
 项目地址：https://github.com/dengyier/OpenWorkProof
-当前版本：1.0.0
+当前版本：1.2.0
 许可证：Apache-2.0
+PyPI：[openworkproof](https://pypi.org/project/openworkproof/)
+MCP Registry：[io.github.dengyier/OpenWorkProof](https://registry.modelcontextprotocol.io/v0.1/servers/io.github.dengyier%2FOpenWorkProof/versions/1.2.0)
 
 ---
 
@@ -144,7 +153,7 @@ running → locally_verified → proof_ready → awaiting_human → accepted
                                                         ↘ rejected
 ```
 
-详细协议 Schema 见 [specs/v0.1](specs/v0.1/)。
+详细协议 Schema 见 [specs](specs/)（当前覆盖 v0.1–v0.5）。
 
 ---
 
@@ -152,7 +161,7 @@ running → locally_verified → proof_ready → awaiting_human → accepted
 
 ### 环境要求
 
-- Python 3.12（`>=3.12, <3.13`）
+- Python ≥ 3.10（支持 3.10 / 3.11 / 3.12 / 3.13）
 - Git
 - macOS 或 Linux
 
@@ -164,14 +173,14 @@ running → locally_verified → proof_ready → awaiting_human → accepted
 pip install openworkproof
 ```
 
-安装后即获得 `owp` CLI 命令和完整的 Python API。
+安装后即获得 `owp` CLI 命令、`owp-mcp` MCP Server 命令和完整的 Python API。
 
 **本地开发环境：**
 
 ```bash
 git clone https://github.com/dengyier/OpenWorkProof.git
 cd OpenWorkProof
-python3.12 -m venv .venv
+python3 -m venv .venv
 ./.venv/bin/python -m pip install -r requirements-lock.txt
 ./.venv/bin/python -m pip install -e .          # 可编辑安装，同步代码修改
 ```
@@ -185,9 +194,106 @@ owp status
 # 运行全量测试（约 5 分钟，需本地开发环境）
 ./.venv/bin/python -m pytest -q
 
-# 预期结果：2283 passed, 7 skipped, 0 failed
+# 精确数量以当前命令输出为准；下方记录最终发布候选的 fresh 验证快照
+```
+
+### Scope-Bound Verification v0.3 与 21 天付费试点
+
+v0.3 把“到底验证了哪些文件、测试与交付对象”纳入签名协议。Manager 冻结
+`EvaluationScopeManifest`，Verifier 分别提交正臂和负臂的 Observed Scope，
+Decision composer 只有在两臂人口一致、必选目标完整、注册负控被捕获时，
+才会形成限定范围的 `VERIFIED`。范围遗漏、选择器漂移或证据不足只能得到
+`UNKNOWN`，不能用局部绿灯冒充完整交付。
+
+```bash
+owp scope-build --claim claim.json --source-revision COMMIT_SHA --rules rules.json
+owp scope-validate scope.json
+owp scope-commit pilot.sqlite3 signed-scope-envelope.json
+owp scope-compare scope.json observed-scope.json
+owp delivery-build --privacy-view customer_private pilot.sqlite3 delivery-package/
+owp audit-replay delivery-package/
+```
+
+v0.3 证明的是代码交付中“声明范围与观察范围精确一致”。它不证明未编码的
+业务意图、客户已经接受、已经付款、资金已释放、自动结算、普遍正确性或
+法规合规。MCP/A2A 继续负责互操作、身份、安全、任务和消息能力；
+OpenWorkProof 作为补充层，把一次工作的授权、范围证据和验收依据冻结下来。
+
+商业验证材料见 [21 天范围可验证交付试点](docs/pilot/scope-bound-verification-offer.md)，
+买方交付样例见 [Scope Coverage Report](docs/pilot/scope-coverage-report.example.md)。
+当前外部付费、客户验收、上游采用与正式部署均为 `not evidenced`。
+
+### 验证完整性 Verification Integrity v0.5
+
+v0.5 在 v0.3 的“声明范围与观察范围一致”之上，把**选择前的合格人口**与
+**负控失败原因**一并冻结进签名协议。v0.3 只能证明“被选中的部分被验证了”；
+v0.5 额外证明“选择之前存在哪些合格人口、选择器实际选中了什么，以及负向
+控制失败是否来自注册的原因”，从而堵住两类此前测不到的盲区：
+
+- **人口盲区**：执行引擎能看到多个合格测试，但选择器选出了零个。运行本身
+  正常结束，v0.5 得出 `UNKNOWN / POPULATION_CAPTURE_FAILED`，不会把局部
+  绿灯当成完整交付。
+- **负控腐化**：注册的变异体仍然失败，但失败原因（错误码 / predicate 签名）
+  与注册签名不一致。v0.5 得出 `UNKNOWN / CONTROL_FAILURE_SIGNATURE_MISMATCH`，
+  不会把“碰巧失败”当成“按预期失败”。
+
+三态边界保持单调：`VERIFIED`（人口 matched + 负控 proven + 正臂满足）、
+`REFUTED`（负控 survived）、`UNKNOWN`（人口 empty/capture_failed/drifted/
+unavailable 或负控 mismatched/unavailable）。`UNKNOWN` 是安全结论，不是系统
+崩溃，也不是失败。
+
+```bash
+owp integrity-observation validate population.json
+owp control-observation validate control.json
+owp delivery-build --privacy-view customer_private pilot.sqlite3 delivery-package/
+owp audit-replay delivery-package/
 ```
 
+退出码：人口 `matched` 为 `0`，其余人口状态为 `3`；负控 `proven` 为 `0`、
+`survived` 为 `4`、`mismatched/unavailable` 为 `3`；输入不合法为 `1`。
+
+离线验证、原因码表与恢复边界见
+[离线验签说明](docs/offline-verification.md)。真实 Issue 演示见
+`tests/integrity-demo/rich-4196/README.md`（Rich #4196）。该演示由
+OpenWorkProof 自建，`upstream_adoption`、`customer_case`、
+`commercial_validation` 均为 `not_evidenced`；它不证明任何客户采用、已经
+付款、资金已释放、自动结算、普遍正确性或法规合规。
+
+### Evidence Lifecycle v0.2 兼容入口
+
+当前 1.2.0 版本保留 v0.2 的 Profile 校验、正负证据提交、验证决定、Delivery
+Package、离线审计和结算就绪度接口：
+
+```bash
+owp profile-validate signed-profile.json
+owp verify-positive pilot.sqlite3 signed-positive-result.json
+owp verify-negative pilot.sqlite3 signed-negative-result.json
+owp verify-compose --mode prepare pilot.sqlite3 decision-request.json
+owp verify-compose --mode commit pilot.sqlite3 signed-decision.json
+owp delivery-build --privacy-view public pilot.sqlite3 delivery-package/
+owp audit-replay delivery-package/
+owp settlement-status pilot.sqlite3
+```
+
+既有运营步骤、信任等级成本和商业证据计分卡见
+[v0.2 可验证交付试点](docs/pilot/README.md)。示例对象只用于本地解析和
+接入演练，不代表真实客户、客户验收、付款、资金释放或正式部署。
+
+1.2.0 本地待发布候选在 source revision
+`d0bec9d2f2c3cf12568fa866d16be1a56de4aa9c` 上完成发布门，并新增不可变
+[候选库存](supply-chain/images/candidates/d0bec9d2f2c3cf12568fa866d16be1a56de4aa9c.json)：
+
+- v0.5 focused：`401 passed、0 failed`；
+- candidate live：`176 passed、0 failed`；
+- required-live 全量：`3494 passed、0 failed、0 skipped`；
+- 冻结执行镜像：
+  `docker.io/openworkproof/execution-test@sha256:6d0dadec750eb498ed4d2260b4de65f33ed1c146adda6e64ec8ba588f7a88097`；
+- Rich #4196 v0.5 交付包离线重放为
+  `VERIFICATION PASSED / VERIFIED / READY_FOR_ACCEPTANCE`。
+
+`READY_FOR_ACCEPTANCE` 表示证据包满足进入验收的协议条件，不等于客户已经
+验收、付款或部署。详细环境、耗时与边界见 [docs/status.md](docs/status.md)。
+
 ### 运行端到端演示
 
 OpenWorkProof 提供两个独立的端到端验证演示，覆盖不同的项目类型和协议场景：
@@ -200,7 +306,7 @@ OpenWorkProof 提供两个独立的端到端验证演示，覆盖不同的项目
 ```bash
 ./.venv/bin/python -m pytest tests/test_delivery_m2.py -q
 
-# 预期结果：5 passed
+# 预期：退出码 0；精确数量以当前命令输出为准
 ```
 
 该演示完整覆盖 9 步证据链：
@@ -227,7 +333,7 @@ OpenWorkProof 提供两个独立的端到端验证演示，覆盖不同的项目
 ```bash
 ./.venv/bin/python -m pytest tests/test_delivery_m3_dify.py -q
 
-# 预期结果：7 passed
+# 预期：退出码 0；精确数量以当前命令输出为准
 ```
 
 该 Bug 发生在 Dify 的 QuestionClassifierNode 节点中——用户在工作流中
@@ -310,17 +416,35 @@ payload.json 示例（run-tests）：
 }
 ```
 
-### 2. MCP 传输层（stdio）
+### 2. MCP Server（stdio）
 
-OpenWorkProof 协调器已封装为 MCP 工具，可被任何 MCP 客户端（如 Claude Desktop、
-Cursor 等）直接调用：
+OpenWorkProof 已注册到官方 MCP Registry（`io.github.dengyier/OpenWorkProof`），
+提供 21 个 MCP 工具，可被任何 MCP 客户端（Claude Desktop、Cursor、VS Code 等）直接调用：
 
 ```bash
-# 启动 stdio MCP 服务器
-./.venv/bin/python -m openworkproof.mcp_transport
+# 启动 MCP Server（pip install 后直接可用）
+owp-mcp
+
+# 或通过 Python 模块启动
+python -m openworkproof.mcp_transport
 ```
 
-提供的 MCP 工具：
+提供的 MCP 工具（21 个）：
+
+**独立验证工具（无需 ledger）：**
+
+| 工具 | 功能 |
+|------|------|
+| `owp_generate_keypair` | 生成 Ed25519 密钥对 |
+| `owp_compute_key_id` | 从公钥派生 key_id |
+| `owp_sign_payload` | 对规范化载荷签名 |
+| `owp_verify_signature` | 验证已签名载荷 |
+| `owp_compute_digest` | 计算 JCS 规范化 SHA-256 摘要 |
+| `owp_verify_work_order` | 验证 WorkOrder 身份绑定 |
+| `owp_verify_nested_claim` | 验证 AgentRequest / HumanDecision 嵌套声明 |
+| `owp_list_domains` | 列出所有规范域名 |
+
+**Ledger 协调工具：**
 
 | 工具 | 功能 |
 |------|------|
@@ -328,19 +452,43 @@ Cursor 等）直接调用：
 | `owp_run_tests(ledger, payload)` | 转发 run-tests 执行 |
 | `owp_repo_read(ledger, payload)` | 转发 repo-read 执行 |
 
+**实用工具：**
+
+| 工具 | 功能 |
+|------|------|
+| `owp_get_schema` | 获取权威 JSON Schema |
+| `owp_get_schema_digest` | 获取 Schema 冻结摘要 |
+| `owp_analyze_repo` | 分析仓库结构 |
+
 在 MCP 客户端配置中添加：
 
+**Claude Desktop**（`~/Library/Application Support/Claude/claude_desktop_config.json`）：
+
+```json
+{
+  "mcpServers": {
+    "openworkproof": {
+      "command": "owp-mcp"
+    }
+  }
+}
+```
+
+**Cursor / VS Code**（`.cursor/mcp.json`）：
+
 ```json
 {
   "mcpServers": {
     "openworkproof": {
-      "command": "/path/to/.venv/bin/python",
-      "args": ["-m", "openworkproof.mcp_transport"]
+      "command": "uvx",
+      "args": ["--from", "openworkproof", "owp-mcp"]
     }
   }
 }
 ```
 
+更多配置方式见 [MCP_SERVER.md](MCP_SERVER.md)。
+
 ### 3. Python API
 
 ```python
@@ -465,7 +613,7 @@ OpenWorkProof/
 │   ├── composition.py         # 因果回放层 + 确定性 CompositionReport
 │   ├── acceptance.py         # 终态验收 + 离线验签器（verify_acceptance_bundle）
 │   ├── mcp_server.py         # 协调器：complete_receipt_publication / compose_proof 等
-│   ├── mcp_transport.py       # MCP stdio 传输层
+│   ├── mcp_transport.py       # MCP Server（既有工具 + v0.2/v0.3 接口）
 │   ├── cli.py                 # CLI 传输层（owp 命令）
 │   ├── execution_adapter.py  # AgentTeams 执行适配层
 │   ├── team_network_client.py # TCP 网络客户端
@@ -476,9 +624,9 @@ OpenWorkProof/
 │   ├── repo_tools.py         # 仓库管道工具
 │   ├── runtime_context.py   # 运行时上下文
 │   ├── trusted_helper.py    # 可信助手请求分发
-│   └── schemas/v0.1/         # JSON Schema 文件
-├── specs/v0.1/               # 协议 Schema（WorkOrder/Grant/Receipt/Acceptance）
-├── tests/                    # 2283 项一致性测试
+│   └── schemas/v0.1..v0.5/   # 多版本 JSON Schema 文件
+├── specs/v0.1..v0.5/         # 公开协议 Schema
+├── tests/                    # 协议、故障注入与端到端测试
 ├── docs/                     # 文档（状态、演示日志、离线验签说明）
 ├── supply-chain/             # 可信构建镜像 + 候选清单
 ├── pyproject.toml            # 打包元数据
@@ -502,13 +650,15 @@ OpenWorkProof/
 - Acceptor 拒绝路径：同权威 Acceptor 签名的 AcceptanceRejectionReceipt
 - 独立 Verifier 结果与确定性 recomposition
 - deny 收据生产入口（`produce_deny_receipt`）
-- CLI（`owp status` / `owp run-tests` / `owp repo-read`）
-- MCP stdio 传输层
+- CLI（既有执行入口 + v0.2/v0.3 范围验证、交付包、审计和就绪度入口）
+- MCP Server（既有工具 + 生命周期聚合接口 + 两个只读 Scope 工具；已注册到 MCP Registry
+  `io.github.dengyier/OpenWorkProof`）
 - AgentTeams TCP 网络客户端 + 执行适配层
 - Docker 生产执行器（STARTED_UNCONFIRMED 恢复）
 - Rich #4196 完整五角色端到端演示（Acceptor TCP 签名 + 离线验签）
 - Dify #33013 完整五角色端到端演示（AI 应用平台类，跨项目类型通用性验证）
-- **全量测试：2283 passed、0 failed、7 skipped**
+- **v0.5 focused：401 passed、0 failed；candidate live：176 passed、0 failed**
+- **1.2.0 本地待发布 required-live 门：3494 passed、0 failed、0 skipped**
 
 **尚未完成：** 其他 ToolCall handler 与 evidence publication 的调用闭包、
 正式赛事提交。
@@ -558,7 +708,8 @@ Dify 是面向终端用户的 AI 工作流平台，与 Rich 的开发者工具
 6. ~~完成 Acceptor 拒绝路径、真实外部 Acceptor 复现~~（已完成）
 7. ~~完成 deny 收据生产入口~~（已完成）
 8. ~~完成 Dify #33013 自包含演示及跨项目类型通用性验证~~（已完成）
-9. 剩余：其他 ToolCall handler 与 evidence publication 的调用闭包、正式赛事提交。
+9. ~~MCP Server 注册到官方 MCP Registry~~（`io.github.dengyier/OpenWorkProof` v1.2.0 元数据已就绪；远端发布以 Registry 回读为准）
+10. 剩余：其他 ToolCall handler 与 evidence publication 的调用闭包、正式赛事提交。
 
 ---
 
@@ -573,8 +724,9 @@ Dify 是面向终端用户的 AI 工作流平台，与 Rich 的开发者工具
 - 真实开源 Issue 的任务封装
 - 安全、隐私和数据治理审查
 
-仓库采用 Apache-2.0 许可证。贡献流程与贡献者协议仍在制定中，
-欢迎先通过 GitHub Issue 提出建议。
+仓库采用 Apache-2.0 许可证。PyPI 包已发布至 [pypi.org/project/openworkproof](https://pypi.org/project/openworkproof/)，
+MCP Server 已注册至 [MCP Registry](https://registry.modelcontextprotocol.io/)。
+贡献流程与贡献者协议仍在制定中，欢迎先通过 GitHub Issue 提出建议。
 
 ## 项目主体
 
@@ -592,3 +744,64 @@ OpenWorkProof 希望让 Agent 工作从「可以生成结果」，迈向：
 
 OpenWorkProof 不提高 Agent 的智力，而是为 Agent 增加进入社会协作所需的
 责任结构。
+
+---
+
+## Judgment-to-Action Binding v0.4
+
+v0.4 为 Agent 交付增加**判断—行动绑定**：用可验证的执行凭证回答
+「Agent 实际做的，是否仍然对应客户原先批准的业务判断」。
+
+### 业务语言（Business-First）
+
+OpenWorkProof 提供的是**可验证的 Agent 执行凭证**。它：
+
+- ✅ 证明「这次执行依据什么授权、做了什么、验证器是否真的能抓到谎言」；
+- ❌ 不成为支付机构、不充当真理预言机、不做法律裁决、不替代客户验收。
+
+### v0.4 状态链与门
+
+```text
+Customer Acceptor 签署 JudgmentCommitment（执行前）
+      ↓
+Manager 提交 ActionBindingManifest（判断↔执行约束绑定）
+      ↓
+Agent v0.4 请求 + ActionReceipt（原生绑定同一 Manifest）
+      ↓
+独立 Verifier 组合 BindingDecision（BOUND / UNBOUND / INDETERMINATE）
+      ↓
+双门：VerificationDecision=VERIFIED ∧ BindingDecision=BOUND ∧ Acceptance=ACTIVE
+      ↓
+READY_FOR_SETTLEMENT_REVIEW（不证明付款或结算）
+```
+
+### 外部权威边界
+
+高风险场景可接入外部 **AuthorityCheckpoint**（客户控制域的独立密钥）。
+OWP 只验证 checkpoint 的格式、签名、链与绑定，**不拥有外部治理与信任根**；
+权威状态只按行动发生时点（as-of）判定，解析器不可用时不伪造 checkpoint。
+
+### 真值边界（Truth Boundaries）
+
+- `BOUND` 只表示「行动与记录判断一致」，**不等于**判断正确、代码无缺陷、
+  客户验收、付款或结算。
+- 未取得的商业状态一律标记 `not_evidenced`（上游采纳、客户使用、付款）。
+
+### 接口
+
+```text
+owp judgment validate
+owp binding-manifest validate
+owp binding compose
+owp binding verify
+owp binding history
+owp package replay --binding
+```
+
+只读 MCP 工具：`owp_validate_judgment_commitment`、
+`owp_validate_action_binding_manifest`、`owp_get_binding_status`、
+`owp_explain_binding_decision`。MCP 验证**拒绝任何 Acceptor/Verifier 私钥
+参数**，只读不签名不提交。
+
+完整实现状态见 [docs/status.md](docs/status.md)，21 天付费试点材料见
+[docs/pilot/](docs/pilot/)。