---
name: physical-service
description: 通过实物服务管理硬件目标、需求材料、服务请求、状态和问题。新会话先发现服务并读取项目；只在真实授权范围内提交。当前入口为个人私有试点，正式接单、付款与工程履约未开放。
---

公开介绍：https://thingweave.com

业务入口：https://thingweave.com/account（仅经核实的站点所有者）

## 服务是什么

服务是在确认的范围、计价、交期条件和授权内，由明确责任方完成约定成果，并负责交付、验收、异常和售后。阶段可行性评估与完整硬件交付有不同的成果和验收。建记录、上传、查询只是操作，不能宣称已经完成服务。

## 首次与新会话

1. 本站业务仅向经核实的所有者开放。原生远程客户端使用 HTTPS `/mcp`，按 OAuth 元数据发现授权端点；通过 Google 登录，再由用户明确批准 ThingWeave 的客户端连接。要求 S256 PKCE、正确的资源 audience 和 `thingweave` 范围。需要续期时同时请求 `offline_access`。Google 只请求 openid、email、profile，不含 Drive 权限。部署与真实客户端验收仍是独立门槛；本地测试通过不代表线上可用。
2. 用户在 `/account` 选择项目及权限；Google 登录或 OAuth 连接本身不创建项目权限。不要读取、复制或让用户粘贴 Cookie、密码或令牌。浏览器内工具及同源 `/api/agent` 诊断使用该浏览器自己的 Google 会话；不要把此端点当作原生 MCP 或导出浏览器凭据。无法完成客户端 OAuth 时报告具体限制，不用其他客户端身份绕过。旧 Sites 账户和记录不会按邮箱自动合并。
3. `connections_list` → 由用户消歧选择 → `project_get`。不要硬编码 ID；没有历史上下文也从服务端恢复需求、证据、待办、版本与下一动作。授权失效则重新连接，不借别人的账户。
4. 需求摘要写清用户确认、Agent 建议、待验证假设和未知项。只提交授权项目的相关信息。有效范围内连续整理、上传摘要，不逐消息重新确认；范围变化时重新授权。
5. 使用 `requirements_submit` 建立或修改结构化需求，传完整 `requirements`：purpose、budget（amount + currency）、quantity、delivery_date（YYYY-MM-DD）、specifications，另可含 constraints 和 materials。未知核心字段用 null；服务返回 missing_fields 和 intake_status，允许先保存再补充。先 `project_get` 读取当前 expected_version；同一请求重试复用 request_key，409 先读回再合并。网页「需求与资料」可补充同一版本化记录；旧 brief_submit 仅保留自由文本摘要。资料齐全也不代表服务已受理。
6. 文件只处理用户指定的确切路径或附件；先算名称、大小、SHA-256，调用 `attachments_prepare`。用户在网页批准后再 `attachment_upload`；不扫描整段对话或整个工作区。CLI `attach` 可完成指纹计算并在批准后上传，同一命令可重试。当前仅支持 UTF-8 纯文本 .txt，单文件限 5 MiB。不上传二进制、网页、压缩包或原始研究材料。
7. 需要变更、取消、验收缺陷或售后时使用 `case_open`。创建申请不等于已取消、已退款或已修复。

## 不可跳过的业务边界

- 先看服务的 `availability`。当前只有请求收集；未落实经营责任方/工程签核人，不编造报价、合同或交期，不把“已提交”称为“已接单”。
- 正式报价必须有责任方、交付物、验收、排除项、金额币种、有效期、日期条件和取消规则。确认绑定精确版本；现阶段没有下单或支付工具。
- 本站尚未配置、未批准真实支付；尚无商户与正式报价，不收集卡号。测试与生产分开，网页返回不是到账证据。
- 交付只有约定成果真实完成且依约验收通过才能成功。研究结论与工程验收分开；签收、上传、脚本通过不能替代验收。
- 通用文档仅使用虚构的桌面温度提示器示例，不代表真实客户项目。器件和项目 ID 不写死到通用服务。预算、尺寸、时间不知道就保持未知。
- 此 Skill 按调用运行，不能承诺后台常驻推进或提醒。当前后台记录持续保存，但人工履约、工程服务商与调度尚待落实。