Skip to content

Card 12 — F8 e-signature connector · F15 HotCRM hand-off behind CLM_COMPOSITION (M4) #83

Description

@objectstack-fleet

Blocked-by: #82

Card spec: docs/backlog/12-esign-and-crm-handoff.md — read it in full; this issue carries only the increment. Milestone M4. The card's own blockers (cards 06 and 09) have both landed (#16, #39).

Why it is blocked on #82, and on nothing else

#82 moves @objectstack/* from 17.4.0 to 17.7.0. This card authors new flows and connectors; authored against 17.4.0 schemas, they would meet 17.5–17.7's new refusals on the next bump. It is filed now so it is visible, and it unlocks when #82 merges.

Release changes that bear on this card (leads from the 17.5–17.7 release pages, not measured against code that does not exist yet)

  • 17.5 — an api flow's start node needs a non-blank config.secret (or the flow is declared autolaunched), or it stops registering at boot. F8's callback is an api-triggered flow.
  • 17.6 — Connectors keep only what runs: connector triggers, syncConfig and fieldMappings are deleted; a sync moves to a mapping with connectorSource.
  • 17.7 — inbound and outbound flow secrets move into sys_flow_credential; credential values leave the copies they were made into.

Read the pages (objectstack-ai/objectstack → content/docs/releases/v17/17-{5,6,7}.mdx) for the exact shapes at dispatch time.

Premises the seat re-checks before dispatch

  1. A provider sandbox is reachable from a dev container. The card's acceptance needs "against a provider sandbox, a contract goes signing → active with the signed PDF attached". The PM has no reading that a DocuSign sandbox credential or the network path exists for a dev. If it does not, the seat asks the maintainer how acceptance is met before dispatch — ⛔ not decided by the seat, ⛔ not faked by the dev (AGENTS.md: a capability the runtime does not deliver is hidden, not faked).
  2. The with-hotcrm composition can be booted for the gate run ("Gates green in both compositions"). How HotCRM's crm_contract is present in that composition is a reading the dev takes from HotCRM's HOTCRM_COMPOSITION precedent; the PM has none.

Filed by the repo:hotclm PM seat from the backlog card file.

Activity

  1. objectstack-fleet commented on Oct 9, 2026

    @objectstack-fleet
    ContributorAuthor

    决策:卡 12 的电子签验收需要服务商沙箱,开发容器里没有凭据——怎么验收? · 2026-10-09T16:05Z

    Governing text: docs/backlog/12-esign-and-crm-handoff.md 验收「Against a provider sandbox, a contract goes signing → active with the signed PDF attached」· AGENTS.md「Honest capabilities … A capability the runtime does not deliver is hidden, not faked」与「Capability expansion: Tight … unless the card says so」

    维护者速读

    事情:卡 12 有两半——F8 电子签(DocuSign 起步)与 F15 HotCRM 交接。F15 不依赖外部服务;F8 的验收要在服务商沙箱里真跑通「签署中 → 生效」并挂上签好的 PDF。

    读数(2026-10-09,派发容器):环境变量中电子签相关凭据 0 个;https://account-d.docusign.com/ 网络可达(HTTP 200)。也就是说,缺的只是一个沙箱账号凭据,不是网络。

    你要做的:回一个字母。

    做法 代价 / 收益
    A(推荐) 拆卡:F15 在 #82 落地后先派;F8 等你把 DocuSign 开发者沙箱凭据加进环境 secret 后再派,按原验收跑通 F15 立刻推进;F8 上线即真实可用。需要你做一次环境配置
    B 整卡等凭据 不拆卡,但 F15 白等
    C 现在就写 F8 连接器,只验到 gate,不跑沙箱 ⛔ 展品里出现一个从未真正跑过的电子签连接器,正是「声明了却不兑现」;列出仅为否决

    四棱分析

    • 实际业务需求:电子签是 M4 的核心卖点,评估者会真去点「发起签署」;F15 是与 HotCRM 联动的展示点,两者需求都真实,但互不依赖。
    • 项目长远合理性:连接器的正确性只能在真实服务商上证明;拆卡让每一半都能完整验收,不留「以后再验」的尾巴。
    • 防 AI 写错:C 会让 agent 学到「连接器写出来、gate 绿就算完成」——外部契约(字段名、回调签名)全靠猜,恰是 AI 最容易写错且 gate 抓不到的地方。
    • 创业阶段不扩散:A 不新增范围,只是改变两半的先后;服务商仍按卡片只做 DocuSign 起步。

    另:卡 12 还需要 with-hotcrm 组合能启动以跑「两种组合下 gate 全绿」,席位没有读数,派发时由 dev 先测。


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions