飞书/Lark 通道的跨代际兼容缺口：0.1.5+ 回复丢失/正文为空，第三方桥接无法跟进（求 SDK 事件契约与迁移指引）

[hdjhf888]

背景

DSH 已经走到 0.2.x（npm latest = 0.2.0-rc.2，2026-09-29；next = 0.2.1-rc.2，10-17），但飞书 / Lark 上用户量较大的第三方桥接 dsh-lark-bot（最新 0.19.16，2026-08-25）仍精确 pin @deepseek-ai/dsh-sdk-client@0.1.0-rc.8，其 COMPATIBILITY.md 也只声明 0.1.0-rc.8。结果是：所有走飞书通道的用户都被锁在 dsh@0.1.2-rc.1，无法跟进 0.2.x。

这不是来要求官方维护第三方插件，而是想反馈一个生态层面的通道插件兼容缺口，并请教迁移口径。

实测现象（两代）

1. 0.1.5 代际：2026-09-15，我们在生产 profile 上从 0.1.2-rc.1 升到 0.1.5-rc.1，重启后飞书侧回复 100% 静默丢失：turn 仍记为 completed，日志、工具通道都正常，但用户收不到任何正文；回滚到 0.1.2-rc.1 立即恢复。
2. 0.2.0 代际：社区 issue（PlutoKeating/dsh-lark-bot#158）显示，0.19.16 + dsh@0.2.0-rc.2 下入站和工具卡片正常，但正文恒为 (No content returned)；会话日志里 assistant/message 有文本，桥接只投影了 usage、没取 content，且非流式运行时没有 assistant/chunk 兜底。Linux x64 与 macOS arm64 均已独立复现。
3. 同版本族还有 provider/model 路由问题（同仓库 #156）：composed profile tree 里 agent-default-model 的配置没有被读取，settings.yaml 兜底失效，需要 DSH_LARK_PROVIDER / DSH_LARK_MODEL 环境变量绕过。

影响面

• 老用户：被钉在 0.1.2-rc.1，拿不到 0.2.x 的能力，也装不了要求新代际的周边插件；
• 新用户：按文档装最新 core 会直接拿到 0.2.0-rc.2，踩上面第 2 条；
• 这类问题不只影响一个插件：通道 / 桥接类插件依赖 SDK 事件流（assistant/chunk、assistant/message、tool/*、审批/提问回调）与会话格式。跨代际时如果缺少公开的破坏性变更清单，第三方维护者只能靠实测和逆向，恢复周期很长。

想请教（4 个问题）

1. 从 0.1.0-rc.8 → 0.1.5 → 0.2.x，给通道插件用的 SDK 事件契约变更有没有正式说明？尤其是：
   • assistant/chunk 与 assistant/message 的语义与投影责任（谁负责把已提交消息的文本转成卡片正文）；
   • 会话格式（V3 / V4）对第三方通道读写的影响；
   • 通知 / 审批 / 提问回调（lark_notify 这类 tool 回调）的代际差异。
2. 对第三方通道插件，官方是否推荐一个最小稳定集成面（例如 SDK server / ACP 的稳定子集），以及推荐的跨代际做法（pin SDK、按代际发版、还是新旧双写）？
3. 是否有计划提供官方飞书 / Lark 通道，或把社区桥接纳入兼容矩阵 / CI 探针（类似发版前的真实探针）？
4. 以上反馈如果有更合适的渠道（issue 当前关闭），请指个路。

我们能配合的

• 在临时 DSH_HOME 跑官方探针 / 兼容测试，回贴日志与事件样本；
• 整理 0.1.5 静默丢回复的最小复现步骤；
• 验证候选迁移补丁（如果官方或社区给出方向）。

相关证据：github.com/PlutoKeating/dsh-lark-bot/issues/158、/issues/156，以及我们 2026-09-15 的升级/回滚记录。

[argszero]

Thanks — this is the right place for it, and both symptoms turn out to be one contract break seen at two stages. Source-level answers below, in your four questions' order.

1. What changed (and why the replies went silent)

One commit owns symptom 1 and predicts symptom 2:

f99b06eaed — feat(session)!: embed assistant streams in format v2 (2026-09-01). It raised SESSION_FORMAT_VERSION from 1 to 2 in packages/core/session/src/types.ts and deleted the assistant/chunk session event. Text stopped arriving as a per-token chunk event; the loop now commits exactly one durable settlement per model attempt:

• assistant/message: { turn, step, message: AssistantMessage, stream: AssistantStreamRecord[], usage?, interrupted? } — message.content is the assembled content blocks, stream is the exact timed stream that produced them, compacted without joining delta boundaries.
• assistant/attempt (new): { turn, step, stream } — attempts that settled without committing a surface message (failed, retried, cancelled, stream-error), deliberately adding no model-visible history.

Release boundary, bracketed on tags: not in dsh-v0.1.2-rc.1; present from dsh-v0.1.3-alpha.1 onward, and in dsh-v0.1.5-rc.1, dsh-v0.1.7-rc.2 and dsh-v0.2.0-rc.2. Your 2026-09-15 upgrade from 0.1.2-rc.1 to 0.1.5-rc.1 crossed it exactly.

Ownership is the part worth internalising: the consumer projects, the core only guarantees the settlement. After v2 the only durable text carrier is assistant/message.message.content (plus the embedded stream for replay fidelity). A bridge that renders from chunk events and takes only usage off the message therefore prints nothing while turn/end correctly reports the turn completed — that is symptom 1 in one sentence, and rolling back to 0.1.2-rc.1 "fixed" it only because that line still writes format 1 with assistant/chunk. Symptom 2 is the same projection bug one generation later: the session log has the text, the bridge still projects usage.

On live streaming specifically: agent/assistant-stream (start / transient chunk / end frames) is a process-local event domain whose only remote consumer in this tree is the Web session-follow adapter (docs/architecture.md). It is not a delivery surface for an external channel; there is no supported chunk-level stream to build on.

2. Session format generations

• Writer authority: SESSION_FORMAT_VERSION in packages/core/session/src/types.ts, currently 4. Latest released format is 4, evidence tag dsh-v0.2.0-rc.2 (docs/session-format-status.md). So the 0.1.x lines wrote formats 1 and 2, and 0.2.0-rc.2 is the first published format-4 release.
• Reader rules: docs/persistence-changes/README.md#compatibility-rules. Immutable generations and adjacent migration: .agents/notes/implemented/architecture/2026-08-31-released-session-format-migrations.md — successors only; a predecessor implies neither fallback nor downgrade support.
• A cheap mechanical check across generations: docs/persistence-catalog.md pins a SHA-256 per persistence type (for example event:assistant/message). Diffing that one file between two tags tells you exactly which event shapes changed, without reading code.
• Practical rule for a channel plugin: never parse the session log yourself. Consume session.event from the SDK and let the core's codecs do the reading.

3. The minimal stable integration surface

@deepseek-ai/dsh-sdk-protocol defines it, and it is small — four server-to-client notifications and seven requests:

• notifications: session.event = { sessionId, event: SessionEvent }, session.status = { sessionId, status: 'idle' | 'running' }, subagent.started, subagent.finished;
• requests: initialize (returns the wire-stable serverInfo.name = deepseek-harness-sdk-runtime), session/prompt → { messageId }, session/resume, session/wait, session/working-directory/get, session/working-directory/set, shutdown.

For a chat channel that is complete: prompt in, durable events out, session.status for typing indicators. Recommended cross-generation practice:

• pin per generation, but re-verify on the format number, not the client version — the payload you depend on is SessionEvent, and its shape is governed by SESSION_FORMAT_VERSION;
• treat unknown event types as ignore, never as fatal (the transport already drops malformed frames rather than failing);
• render from settlements; treat chunk-level streaming as optional polish you can add later from the embedded stream.

ACP (packages/acp) is automation-only and is not a channel API — I would not build a bridge on it.

4. Official Lark channel, compatibility matrix, CI probes

There is no first-party Lark/Feishu channel in this tree, and no per-channel probe in CI. What exists is pnpm run test:snapshot (keyless replay of recorded sessions through the shipped profiles) and real-API e2e that self-skips without a key; neither takes a third-party channel as its subject, so a channel-side probe has to live in the channel's own repository. Issues are disabled here on purpose; Discussions is the intended channel, and this thread is the right place — a reproduction posted here from a temporary DSH_HOME is the fastest route to a mechanism-level answer, and the offer you make at the bottom is exactly the useful shape.

One note on your point 3 (PlutoKeating/dsh-lark-bot#156, composed profile tree not reading agent-default-model): that is a different mechanism and cannot be settled from source alone — it needs the resolved composition. The configuration dump (--dump-config) of the failing profile will show whether that section is present-but-shadowed or missing entirely; paste it here and I will pin which of the two it is.

[hdjhf888]

Thanks — here is the resolved composition for the profile in the report (dsh-lark, dsh-lark-bot 0.19.16, Windows 11, $DSH_HOME = D:\dsh-home), dumped at both generations of the CLI:

CLI	layers	agent-default-model
dsh@0.1.2-rc.1 (npm global)	11	present ×1 — provider: deepseek-official, model: deepseek-v4-flash
dsh@0.2.0-rc.2 (npx)	11	present ×1 — provider: deepseek-official, model: deepseek-flash

So on this host the section is neither missing nor shadowed: exactly one declaration, contributed by the @deepseek-ai/dsh-base layer, and no later layer re-declares the same id. The 49-line delta between the two dumps is model naming plus stock defaults, not structure.

That moves point 3 off the composed tree. If DSH_LARK_PROVIDER being unset still produces MISSING_CREDENTIAL for deepseek-official, the bridge is re-deriving provider/model from its own plugin config (model: process.env.DSH_LARK_MODEL) rather than consuming the resolved agent-default-model — i.e. present, but not read.

Question back: should a channel plugin treat agent-default-model as the source of truth, or should the effective provider/model be carried on the protocol (initialize result, or a session.model-style notification) so a channel never re-derives it? The latter would also retire the env-var workaround in #156.

Full dump below (secrets are only process.env.* references — no literals; persona/personaPrefix redacted as local text unrelated to model resolution).

dsh --profile dsh-lark --dump-config  @ 0.2.0-rc.2

# == @deepseek-ai/dsh-base
- id: tool-plugin-manager
  name: '@deepseek-ai/dsh-plugin-manager/tools'
  disabled: true
- id: plugin-manager
  name: '@deepseek-ai/dsh-plugin-manager'
  disabled: !!js '!ctx.get(''profileContext'')'
- id: timer
  name: '@deepseek-ai/cordis-plugin-timer'
- id: hmr
  name: '@deepseek-ai/dsh-hmr'
  disabled: !!js '!ctx.get(''profileContext'')'
  config:
    root: []
- id: llm
  name: '@deepseek-ai/dsh-llm'
- id: deepseek-llm-api-extensions
  name: '@deepseek-ai/dsh-deepseek-llm-api-extensions'
- id: session
  name: '@deepseek-ai/dsh-session'
- id: session-log-deepseek
  name: '@deepseek-ai/dsh-session-log-deepseek'
- id: typert
  name: '@deepseek-ai/dsh-typert-registry'
- id: typert-loader
  name: '@deepseek-ai/dsh-typert-loader'
- id: typert-gateway
  name: '@deepseek-ai/dsh-api-gateway'
- id: session-title
  name: '@deepseek-ai/dsh-session-title'
  config:
    fallbackMaxWords: 5
    fallbackMaxBytes: 40
    maxTitleBytes: 80
- id: session-title-llm
  name: '@deepseek-ai/dsh-session-title-first-prompt-llm'
  config:
    targetWords: 5
    targetCjkCharacters: 10
    maxInputBytes: 4096
    maxOutputTokens: 64
    timeoutMs: 60000
- id: user-questions
  name: '@deepseek-ai/dsh-user-questions'
- id: agent
  name: '@deepseek-ai/dsh-agent'
- id: plugin-package-inventory-deepseek
  name: '@deepseek-ai/dsh-plugin-package-inventory-deepseek'
- id: agent-default-model
  name: '@deepseek-ai/dsh-agent-default-model'
  config:
    provider: deepseek-official
    model: deepseek-flash
- id: jobs
  name: '@deepseek-ai/dsh-jobs-local'
- id: llm-retry
  name: '@deepseek-ai/dsh-llm-retry'
- id: config-editor
  name: '@deepseek-ai/dsh-config-editor'
  disabled: !!js '!ctx.get(''profileContext'')'
- id: settings
  name: '@deepseek-ai/dsh-settings'
  disabled: !!js '!ctx.get(''profileContext'')'
- id: authorization
  name: '@deepseek-ai/dsh-authorization'
- id: deepseek-account
  name: '@deepseek-ai/dsh-deepseek-account-platform'
  config:
    desktopPlatform: !!js >-
      ctx.get('profileContext')?.name === 'desktop' && ['darwin',
      'win32'].includes(process.platform) ? process.platform : null
- id: credentials
  name: '@deepseek-ai/dsh-credentials-local'
- id: llm-pi-ai
  name: '@deepseek-ai/dsh-llm-pi-ai'
- id: session-persistence-jsonl
  name: '@deepseek-ai/dsh-session-persistence-jsonl'
  config:
    root: !!js dshHomePath('sessions')
- id: attachment-local
  name: '@deepseek-ai/dsh-attachment-local'
- id: session-query-sqlite
  name: '@deepseek-ai/dsh-session-query-sqlite'
  config:
    path: ':memory:'
    openAt: never
- id: session-projection
  name: '@deepseek-ai/dsh-session-projection'
- id: storage
  name: '@deepseek-ai/dsh-storage'
- id: storage-json
  name: '@deepseek-ai/dsh-storage-json'
  config:
    root: !!js dshHomePath('storages')
- id: storage-domain
  name: '@deepseek-ai/dsh-storage-domain'
  config:
    backend: json
- id: session-projection-cache
  name: '@deepseek-ai/dsh-session-projection-cache'
  config:
    writeEveryEvents: 200
    writeIntervalMs: 5000
- id: otel
  name: '@deepseek-ai/dsh-otel'
- id: session-telemetry-otel
  name: '@deepseek-ai/dsh-session-telemetry-otel'
  config:
    mode: !!js process.env.DSH_TELEMETRY_MODE || 'FEEDBACK_ONLY'
    shutdownTimeoutMillis: 3000
    maxRequestBytes: 4000000
    exporter:
      url: !!js >-
        process.env.DSH_TELEMETRY_OTLP_URL ??
        'https://dsh-otel-collector.deepseeksvc.com/v1/logs'
      compression: gzip
      timeoutMillis: 1000
    processor:
      scheduledDelayMillis: 10000
      maxQueueSize: 2048
      maxExportBatchSize: 2048
      exportTimeoutMillis: 1500
- id: subprocess
  name: '@deepseek-ai/dsh-subprocess-local'
- id: sandbox
  name: '@deepseek-ai/dsh-sandbox-local'
- id: sandbox-policy
  name: '@deepseek-ai/dsh-sandbox-policy'
  config:
    mode: !!js process.env.DSH_PERMISSION_MODE ?? 'workspace-write'
    workspaceRoot: !!js process.cwd()
- id: bash-sandbox
  name: '@deepseek-ai/dsh-bash-sandbox'
  disabled: !!js process.platform === 'win32'
  config:
    timeoutMs: 60000
- id: pwsh-sandbox
  name: '@deepseek-ai/dsh-pwsh-sandbox'
  disabled: !!js process.platform !== 'win32'
- id: approval
  name: '@deepseek-ai/dsh-user-approval'
  config:
    policy: !!js >-
      (process.env.DSH_PERMISSION_MODE ?? 'workspace-write') ===
      'danger-full-access' ? 'never' : 'ask'
- id: permission
  name: '@deepseek-ai/dsh-permission-presets'
  config:
    presets:
      read-only:
        sandbox: read-only
        approval: ask
      workspace-write:
        sandbox: workspace-write
        approval: ask
      danger-full-access:
        sandbox: danger-full-access
        approval: never
- id: shell-env
  name: '@deepseek-ai/dsh-shell-env'
- id: tool-bash
  name: '@deepseek-ai/dsh-tool-bash'
  disabled: !!js process.platform === 'win32'
- id: tool-pwsh
  name: '@deepseek-ai/dsh-tool-pwsh'
  disabled: !!js process.platform !== 'win32'
- id: tool-jobs
  name: '@deepseek-ai/dsh-tool-jobs'
- id: fs-observation-policy
  name: '@deepseek-ai/dsh-fs-observation-policy'
- id: tool-fs
  name: '@deepseek-ai/dsh-tool-fs'
- id: tool-fs-search
  name: '@deepseek-ai/dsh-tool-fs-search'
  config:
    sampleOverCapGlobResults: false
- id: agent-instructions
  name: '@deepseek-ai/dsh-agent-instructions'
  config:
    maxBytes: 65536
- id: skill
  name: '@deepseek-ai/dsh-skill'
- id: skill-filesystem
  name: '@deepseek-ai/dsh-skill-filesystem'
- id: skill-badge
  name: '@deepseek-ai/dsh-skill-badge'
  disabled: true
- id: tool-skill
  name: '@deepseek-ai/dsh-tool-skill'
- id: commands
  name: '@deepseek-ai/dsh-commands'
- id: command-feedback
  name: '@deepseek-ai/dsh-command-feedback'
- id: goal
  name: '@deepseek-ai/dsh-goal'
- id: goal-round-driver
  name: '@deepseek-ai/dsh-goal-round-driver'
- id: command-goal
  name: '@deepseek-ai/dsh-command-goal'
- id: plan-mode
  name: '@deepseek-ai/dsh-plan-mode'
  config:
    section: >
      You are in plan mode. Stay in plan mode until exit_plan_mode succeeds or
      the user switches the session mode. Imperative language to implement
      changes means plan the implementation, not execute it. A user's
      conversational agreement — including an answer confirming something you
      asked — approves nothing and does not end plan mode; fold the confirmed
      decision into the plan and submit it through exit_plan_mode.


      Explore first. Use non-mutating reads, searches, static analysis, and
      checks to ground the plan in the actual repository. Do not edit or write
      files, change configuration, run formatters or code generation that
      rewrites tracked files, commit, or otherwise carry out the plan. Prefer
      existing functions and patterns over new machinery.


      The tool catalog stays the same across modes for request-cache stability.
      These plan-mode rules override any later tool description or guidance that
      suggests using mutation tools; those tools remain listed only to keep the
      request shape stable. Do not use todo_write to track this planning phase:
      it tracks implementation after an approved plan, while the plan itself
      belongs in exit_plan_mode.


      Resolve discoverable facts by inspection. Use ask_user_question only for
      user-owned choices or material ambiguity that inspection cannot answer. Do
      not ask the user where code lives or how current behavior works when you
      can find out.


      Make the plan decision-complete: state the goal and success criteria;
      group implementation changes by subsystem; identify public API, schema,
      and data-flow changes; cover edge cases, failure modes, tests, acceptance
      criteria, and explicit assumptions. Keep it concise enough to review but
      detailed enough that another engineer can implement it without making
      design decisions.


      When ready, call exit_plan_mode with the complete plan markdown, starting
      with a # title. Make exit_plan_mode the only and final tool call in that
      assistant response: it presents the plan for approval, and implementation
      begins only in a later step after approval. Do not paste the final plan as
      a plain reply or ask "should I proceed?" through prose or
      ask_user_question. If review rejects it, incorporate the feedback and
      present again. If the review channel is unavailable or aborted, stay in
      plan mode and ask the user to switch modes manually; do not proceed with
      implementation.
- id: token-meter
  name: '@deepseek-ai/dsh-token-meter'
# == @deepseek-ai/dsh-base, patched by D:\dsh-home\profiles\dsh-lark\cordis.patch.yml
- id: compaction-basic
  name: '@deepseek-ai/dsh-compaction-basic'
  config:
    thresholdRatio: 0.8
    retainTokens: 20000
    maxTokens: 8192
    auto: true
# == @deepseek-ai/dsh-base
- id: command-compact
  name: '@deepseek-ai/dsh-command-compact'
- id: subagent
  name: '@deepseek-ai/dsh-subagent'
- id: subagent-spawn-in-process
  name: '@deepseek-ai/dsh-subagent-spawn-in-process'
  config:
    providerName: spawn
- id: subagent-fork-in-process
  name: '@deepseek-ai/dsh-subagent-fork-in-process'
  config:
    providerName: fork
- id: tool-subagent-control
  name: '@deepseek-ai/dsh-tool-subagent-control'
- id: tool-subagent-list-agents
  name: '@deepseek-ai/dsh-tool-subagent-control/list-agents'
- id: tool-subagent
  name: '@deepseek-ai/dsh-tool-subagent'
  config:
    provider: spawn
    toolName: subagent
    backgroundMode: continuable
- id: tool-subagent-fork
  name: '@deepseek-ai/dsh-tool-subagent'
  config:
    provider: fork
    toolName: subagent_fork
    backgroundMode: one-shot
- id: ptc-runtime
  name: '@deepseek-ai/dsh-ptc-runtime-node'
- id: workflow-ptc
  name: '@deepseek-ai/dsh-workflow-ptc'
  config:
    provider: spawn
- id: tool-workflow
  name: '@deepseek-ai/dsh-tool-workflow'
- id: timeout-policy
  name: '@deepseek-ai/dsh-tool-call-timeout-policy'
- id: spill-local
  name: '@deepseek-ai/dsh-spill-local'
# == @deepseek-ai/dsh-base, patched by D:\dsh-home\profiles\dsh-lark\cordis.patch.yml
- id: spill-policy
  name: '@deepseek-ai/dsh-spill-policy'
  config:
    maxInlineBytes: 16000
# == @deepseek-ai/dsh-base
- id: session-checkpoint-policy
  name: '@deepseek-ai/dsh-session-checkpoint-policy'
# == @deepseek-ai/dsh-base, patched by D:\dsh-home\profiles\dsh-lark\cordis.patch.yml
- id: tool-result-pruner
  name: '@deepseek-ai/dsh-compaction-tool-result-pruner'
  config:
    thresholdChars: 6000
    headChars: 3500
    tailChars: 900
# == @deepseek-ai/dsh-base
- id: image-offload
  name: '@deepseek-ai/dsh-compaction-image-offload'
- id: tool-todo
  name: '@deepseek-ai/dsh-tool-todo'
  config:
    allowParallelInProgress: true
- id: tool-goal
  name: '@deepseek-ai/dsh-tool-goal'
- id: tool-ralph
  name: '@deepseek-ai/dsh-tool-ralph'
  disabled: true
  config:
    subagentProvider: spawn
    maxRounds: 64
- id: repeat-tool-reminder
  name: '@deepseek-ai/dsh-repeat-tool-reminder'
  config:
    thresholds:
      - 3
      - 5
      - 8
    argumentsPreviewChars: 500
- id: web
  name: '@deepseek-ai/dsh-web'
  config:
    searchProvider: deepseek-official
    fetchProvider: http
- id: web-search-deepseek
  name: '@deepseek-ai/dsh-web-search-deepseek'
  config:
    apiKeyEnv: DEEPSEEK_API_KEY
- id: web-fetch-http
  name: '@deepseek-ai/dsh-web-fetch-http'
- id: tool-web
  name: '@deepseek-ai/dsh-tool-web'
  config:
    fetch: true
    searchTimeoutMs: 60000
- id: mcp-resources
  name: '@deepseek-ai/dsh-mcp-resources'
- id: tools
  name: '@deepseek-ai/dsh-tools'
# == @deepseek-ai/dsh-base, patched by D:\dsh-home\profiles\dsh-lark\cordis.patch.yml
- id: system-prompt
  name: '@deepseek-ai/dsh-system-prompt'
  config:
    persona: <redacted: local persona>

# == @deepseek-ai/dsh-base
- id: agent-loop
  name: '@deepseek-ai/dsh-agent-loop'
  config:
    agents: []
- id: fs-sandbox
  name: '@deepseek-ai/dsh-fs-sandbox'
- id: llm-deepseek
  name: '@deepseek-ai/dsh-llm-deepseek-api-key'
- id: llm-deepseek-account
  name: '@deepseek-ai/dsh-llm-deepseek-account'
# == dsh-lark-bot
- id: dsh-lark-bot
  name: dsh-lark-bot/plugin
  config:
    profile: !!js process.env.DSH_LARK_PROFILE ?? 'default'
    home: !!js process.env.DSH_LARK_HOME
    tenant: !!js process.env.DSH_LARK_TENANT ?? 'feishu'
    appId: !!js process.env.DSH_LARK_APP_ID
    appSecret: !!js process.env.DSH_LARK_APP_SECRET
    workspace: !!js process.env.DSH_LARK_WORKSPACE
    adapter: !!js process.env.DSH_LARK_ADAPTER
    model: !!js process.env.DSH_LARK_MODEL
    scopeConcurrency: !!js >-
      process.env.DSH_LARK_SCOPE_CONCURRENCY ?
      Number(process.env.DSH_LARK_SCOPE_CONCURRENCY) : undefined
    notificationDefault: !!js process.env.DSH_LARK_NOTIFICATION_DEFAULT
    disabled: !!js process.env.DSH_LARK_DISABLED === '1'
- id: lark-notify
  name: dsh-lark-bot/notify
  config:
    endpoint: !!js process.env.DSH_LARK_NOTIFY_URL
    token: !!js process.env.DSH_LARK_NOTIFY_TOKEN
- id: lark-file
  name: dsh-lark-bot/file
  config:
    endpoint: !!js process.env.DSH_LARK_FILE_URL
    token: !!js process.env.DSH_LARK_NOTIFY_TOKEN
- id: lark-secret
  name: dsh-lark-bot/secret
  config:
    endpoint: !!js process.env.DSH_LARK_SECRET_URL
    token: !!js process.env.DSH_LARK_NOTIFY_TOKEN
- id: lark-ask
  name: dsh-lark-bot/ask
  config:
    endpoint: !!js process.env.DSH_LARK_ASK_URL
    token: !!js process.env.DSH_LARK_NOTIFY_TOKEN
# == dsh-lark-bot, patched by D:\dsh-home\profiles\dsh-lark\cordis.patch.yml
- id: lark-plan-approval
  name: dsh-lark-bot/plan
  config:
    mode: 'off'
- id: lark-approval-answerer
  name: dsh-lark-bot/approval
  config:
    endpoint: !!js process.env.DSH_LARK_APPROVAL_URL
    token: !!js process.env.DSH_LARK_NOTIFY_TOKEN
  disabled: true

[hdjhf888]

跟进一下（第 1 次，我们上次发言至今约 72 小时，暂无新结论）：0.2.0-rc.2 session v2 破坏性变更。这边仍在按生产同款管道复现，问题没有自行消失。

补充实测（隔离环境，与生产同款 service-run --profile ... --env-file ... 管道）：0.19.16 在 0.2.0-rc.2 下 DSH_LARK_ADAPTER=dsh-sdk 会被配置校验拒绝；改成 sdk 后插件能起，但 TCP 连接数 0、无 service.log，通道整条没起来。

如果短期排不上，给个方向性判断就够：0.19.x 在 0.2 下是否还会被支持？若明确不支持，我们就按整仓替换 fork 走，不再等。谢谢。

[hdjhf888]

跟进一下（第 2 次，我们上次发言至今约 97 小时，暂无新结论）：0.2.0-rc.2 session v2 破坏性变更。这边仍在按生产同款管道复现，问题没有自行消失。

补充实测（隔离环境，与生产同款 service-run --profile ... --env-file ... 管道）：0.19.16 在 0.2.0-rc.2 下 DSH_LARK_ADAPTER=dsh-sdk 会被配置校验拒绝；改成 sdk 后插件能起，但 TCP 连接数 0、无 service.log，通道整条没起来。

如果短期排不上，给个方向性判断就够：0.19.x 在 0.2 下是否还会被支持？若明确不支持，我们就按整仓替换 fork 走，不再等。谢谢。

[hdjhf888]

跟进一下（第 3 次，我们上次发言至今约 97 小时，暂无新结论）：0.2.0-rc.2 session v2 破坏性变更。这边仍在按生产同款管道复现，问题没有自行消失。

补充实测（隔离环境，与生产同款 service-run --profile ... --env-file ... 管道）：0.19.16 在 0.2.0-rc.2 下 DSH_LARK_ADAPTER=dsh-sdk 会被配置校验拒绝；改成 sdk 后插件能起，但 TCP 连接数 0、无 service.log，通道整条没起来。

如果短期排不上，给个方向性判断就够：0.19.x 在 0.2 下是否还会被支持？若明确不支持，我们就按整仓替换 fork 走，不再等。谢谢。