Files
workbuddy_skills/open-design/design-templates/live-artifact/references/refresh-contract.md
T
admin 5afeb6b78a ④段整套同步(六节 + P/S/F/J + 模板)+ open-design 移到技能根
一、④段整套同步(用户选候选 A)
- 新增 `references/stage-proto-doc/assets/产品文档模板.html`(16 KB/247 行,从备份拷、转 LF)。
- ④段 SKILL.md 换成备份 15:28 那版,并按模板口径改齐:
  · 「产品文档框架」从「四块+一附录」改成**六节** —— 页面结构/功能清单/使用场景/操作流程/
    跨页与界面状态/待确认与偏离;与模板同构,⛔ 不从空白页重写结构。
  · 编号从 R/S/F 改成 **P 页面/S 场景/F 功能/J 二级功能**,各自唯一、按展示顺序通排。
  · 保留旧版有价值的要求:每项功能补齐 做什么/入口在哪/输入边界/异常与恢复;重点功能三处标红;
    横向流程图每步写清页面/功能/操作/完成判据。
  · 完成标准「七节」→「六节」,自查清单同步换掉「需求」那批条目,补模板与配图两条。
  · 路径 `designs/<项目>/` → `docs/pm/<项目>/ui/`(2 处)。
  · 补回本机那条「每份产出文档开头都要有一张图」的引用(指向主 skill,段内不复述)。
- 主 skill 同步:四段结构表④行、④段沿革、画图小节(④段画页面结构图 + 用户路径)。

二、open-design 移到技能根(用户选候选 A)
- `git mv product-planning/references/stage-delivery/assets/open-design → open-design/`(4178 文件)。
- `.gitignore` 白名单加 `!/open-design/` —— 否则移出去就不再纳入版本控制。
- 引用改 11 处:路径形态 `assets/open-design/...` → `<技能根>/open-design/...`;
  「随段携带的自带件」改称「同根技能」;「路径怎么找」那条改成自带件(段内相对路径)与
  同根技能(`<技能根>/<技能名>/`)两类分开写。
- open-design 自己的 ATTRIBUTION.md 两处同步(它现在与 oil-ui-pro 同层)。
- 副作用(有益):命名闸门读数由 2063 降到 225 —— 此前它把 open-design 里 919 个第三方 md
  当成规则一起扫了;现在只扫本包 23 个 md。已确认④段的 H1 与 4a/4b/4c 子步仍在检查范围内。

三、验收
- check_naming.py --ws E:/ProgramData/AIProject/contentm_agent = 通过 225 / 失败 0 / 提示 27。
- 活文件里 `assets/open-design` 残留 0;工作区 CRLF 文件 0。
2026-10-15 21:17:28 +08:00

3.6 KiB

Refresh Contract Reference

Refresh updates live artifact data without redesigning the presentation. The refresh runner updates data.json, provenance, and audit history; it does not allow arbitrary template rewrites.

Refreshable source metadata

Refreshable documents use sourceJson:

{
  "type": "connector_tool",
  "toolName": "list_releases",
  "input": {},
  "connector": {
    "connectorId": "github",
    "accountLabel": "example/org",
    "toolName": "list_releases"
  },
  "outputMapping": {
    "dataPaths": [{ "from": "items", "to": "releases" }],
    "transform": "compact_table"
  },
  "refreshPermission": "manual_refresh_granted_for_read_only"
}

Supported source types:

  • local_file
  • daemon_tool
  • connector_tool

Supported output transforms:

  • identity
  • compact_table
  • metric_summary

Source execution model

  • refreshPermission is retained for backward compatibility with older artifacts, but the refresh runner does not require a separate connector approval step.
  • If a safe source descriptor exists, manual refresh executes it through daemon-owned local or connector wrappers.
  • Write, destructive, unknown, disabled, unconnected, or schema-drifted connector tools should not be authored as refresh sources.

Connector-backed refresh

Connector-backed refresh sources use the same connector execution service as agent-initiated connector calls. Do not call provider APIs directly from refresh logic or from skill-authored scripts.

Before creating a connector-backed refresh source:

  1. List connectors with "$OD_NODE_BIN" "$OD_BIN" tools connectors list --format compact.
  2. If the user named a connector/source and it is connected, select that connector directly instead of asking where the source is. Then select a tool whose safety is read + auto and whose catalog metadata marks it refresh-eligible.
  3. Execute once with "$OD_NODE_BIN" "$OD_BIN" tools connectors execute --connector <id> --tool <name> --input input.json to produce compact normalized preview data.
  4. Store only non-sensitive connector references, the bounded input object, output mapping, and compatibility refreshPermission in sourceJson.

On each refresh, the daemon must re-check connector status, account label, allowlist membership, input schema, and output protection. If any check fails or output protection rejects the result, refresh fails all-or-nothing and preserves the previous valid preview.

Persisted connector refresh metadata may include connectorId, toolName, non-sensitive accountLabel, bounded input, outputMapping, and compatibility refreshPermission. It must not include credentials, auth/session material, raw provider envelopes, or unbounded provider responses.

Commit behavior

Refresh is all-or-nothing:

  1. Acquire one active refresh lock per artifact.
  2. Execute each refreshable source with timeouts and current safety checks.
  3. Build candidate data.json, provenance, and preview.
  4. Validate all candidates with the same schemas used for create/update.
  5. Commit only if every refreshable source succeeds.
  6. Preserve the previous valid preview if any step fails.

Refresh IDs must be monotonic so stale runs cannot overwrite newer committed data.

Audit storage

  • Append compact records to refreshes.jsonl.
  • Successful refresh snapshots live under snapshots/<refreshId>/ and may include data.json and provenance.
  • Failed refreshes are summarized in refreshes.jsonl without leaking raw provider output or credentials.
  • On daemon startup, stale running refreshes should be marked failed or timed out while preserving the last valid preview.