cc-connect-next v0.3.0

cc-connect-next v0.3.0

中文

v0.3.0 汇总五个 Beta 的反馈、更新与会话可靠性改进。相较 v0.2.1，重点是
更完整的反馈隐私保护、明确的 Stable/Beta 更新通道，以及飞书话题和卡片操作的
准确归属。候选代码与 v0.3.0-beta.5 一致。

主要变化

• 反馈入口更直接。 明确发送 /feedback <描述> 或点击反馈按钮即可提交
  已脱敏内容，不再二次确认；自动错误或能力提示在用户点击前不发送网络请求。
  错误反馈绑定原发起者，群聊共享会话、多工作区和固定工作目录都保持正确归属。
  提交结果更新原卡片，不额外发送 Issue 链接。
• 反馈隐私与服务端保护。 采用 Foundation v0.1.2，补齐引号配置、转义值、
  Cookie、URL 凭据和宿主标识脱敏，排除时间未知或来自未来的诊断上下文。
  Relay 拒绝无效 UTF-8 和认证重定向，GitHub 操作采用仓库限定的 App 身份。
• 更新通道明确可选。 stable 为默认通道；update_channel = "beta"、
  cc-connect-next update beta 或 /upgrade beta 可明确选择 Beta。
  更新展示精确版本、通道和发布说明，确认只执行已展示的同一计划；错误通道
  不能应用其他待确认计划。
• 更新恢复与提醒更可靠。 更新保留校验和、安装前后版本探针、锁、备份与
  回滚保护。Unix Beta 保留恢复备份和执行权限，Windows 增加跨进程锁及防覆盖
  备份。主动提醒只发给明确列出的管理员私聊，部分失败会重试完整收件人名单。
• Agent 可以安全反馈和重启。 本地 Agent 的 feedback preview 与
  feedback submit 使用同一脱敏和鉴权链；Agent 回合内请求重启会等待回答、
  卡片与已接收队列完成，再执行既有重启流程。
• 飞书会话和卡片归属更准确。 真实私聊话题独立保存会话上下文与回复目标；
  同一 App 的多项目卡片绑定所属项目、收件人和操作者，慢速翻页刷新也保留绑定。
• 配置和文本兼容修复。 动态 option 子键不再被误报为未知配置，非字符串
  option 值会明确报错；slash command 保持可复制，模型容量不足显示安全的重试
  或切换模型提示。

从 v0.2.1 升级

正式发布后可使用：

npm install -g cc-connect-next@latest
cc-connect-next --version

独立安装可使用 cc-connect-next update stable，聊天可使用 /upgrade stable。
省略 update_channel 仍使用 Stable；已显式配置 Beta 的用户需改为 stable，
才能持续跟随稳定通道。

• 启用飞书 thread_isolation 的真实私聊话题会使用独立 session key，此前共享
  在普通私聊会话里的上下文不会自动迁移。
• 主动更新提醒需要项目中明确列出的 admin_from 用户，以及唯一支持私聊投递的
  平台。空值或 * 无法枚举提醒收件人。
• Agent/Platform 动态 option、环境变量与 peer alias 的值需为字符串；原先被
  静默忽略的数值等非字符串值现在会被拒绝。
• 自定义反馈地址须为 HTTPS，路径精确为 /v1/feedback；仅 loopback 开发地址
  允许 HTTP。自托管 Relay 需独立更新部署，客户端升级不会自动更新服务端。
• Agent Feedback 和回合内安全重启需要对应新版 daemon API；仅更换 CLI 不会
  自动更新仍在运行的旧 daemon。原生 Windows 运行尚未验证。

English

v0.3.0 brings together five Betas of feedback, update, and session reliability
improvements. Compared with v0.2.1, it adds stronger feedback privacy, explicit
Stable/Beta channels, and precise ownership of Feishu topics and card actions.
The candidate has the same runtime code as v0.3.0-beta.5.

Highlights

• Direct chat feedback. /feedback <description> and explicit feedback
  buttons submit redacted content without a second confirmation. Automatic
  error or capability offers make no request before a user acts. Error offers
  belong to the initiating user, including shared sessions and multiple or
  fixed workspaces. Results replace the original card without an extra Issue
  link message.
• Stronger privacy and Relay protection. Foundation v0.1.2 covers quoted
  configuration, escaped values, cookies, URL credentials, and host identifiers.
  Diagnostic context with unknown or future timestamps is excluded. The Relay
  rejects invalid UTF-8 and authentication redirects and uses a repository-scoped
  GitHub App identity.
• Explicit update channels. Stable remains the default. Select Beta with
  update_channel = "beta", cc-connect-next update beta, or /upgrade beta.
  Updates show the exact version, channel, and release notes. Confirmation applies
  only the displayed plan and cannot substitute a plan from another channel.
• Safer recovery and notices. Updates retain checksums, staged/installed
  version probes, locks, backups, and rollback. Unix Beta preserves recovery
  backups and executable permissions; Windows adds cross-process locking and
  backup protection. Notices go only to explicitly listed administrators in
  private chats, retrying the full list after partial delivery failure.
• Safe Agent feedback and restart. Local-Agent feedback preview and
  feedback submit share redaction and authenticated approval. In-turn restart
  waits for the answer, cards, and accepted queue before the existing graceful
  restart lifecycle proceeds.
• Precise Feishu ownership. Real private topics keep separate session
  context and reply targets. Cards shared across projects bind their project,
  recipient, and operator, including after asynchronous navigation refreshes.
• Configuration and rendering fixes. Consumed dynamic option keys no longer
  appear unsupported, while non-string values fail explicitly. Slash commands
  stay copyable, and model-capacity failures offer safe retry/switch guidance.

Upgrade from v0.2.1

After publication:

npm install -g cc-connect-next@latest
cc-connect-next --version

Standalone installations can use cc-connect-next update stable; chat can use
/upgrade stable. Omitting update_channel still selects Stable. Users with an
explicit Beta configuration must change it to stable to follow that channel.

• Real Feishu private topics with thread_isolation use distinct session keys.
  Context previously shared with ordinary private chat is not migrated.
• Proactive notices require explicit project admin_from users and exactly one
  direct-message-capable platform. Empty or wildcard values cannot enumerate
  notice recipients.
• Dynamic Agent/Platform options, environment variables, and peer aliases must
  contain string values. Previously ignored numeric or other non-string values
  are now rejected.
• Custom feedback endpoints require HTTPS and the exact /v1/feedback path;
  HTTP is allowed only for loopback development. Self-hosted Relay operators
  must update and deploy separately; client upgrades do not deploy the server.
• Agent Feedback and safe in-turn restart require the matching daemon API.
  Replacing the CLI alone does not update an already running daemon. Native
  Windows execution remains unverified.

cc-connect-next v0.3.0-beta.5

cc-connect-next v0.3.0-beta.5

中文

v0.3.0 的第五个 Beta，修复反馈隐私、错误反馈入口和更新备份边界，并采用
Foundation v0.1.2 正式补丁版本。

主要变化

• 反馈脱敏更完整。 JSON/配置中的引号键、转义值、带前缀凭据、Cookie、URL
  用户信息和宿主标识会在内容截断与提交前脱敏，同时保留正常 URL 查询参数和片段。
• 错误反馈绑定发起用户。 群聊共享会话中的自动反馈入口只能由原发起者使用；
  多工作区和固定工作目录场景也能正常触发。时间未知或来自未来的上下文不会混入反馈。
• Relay 输入与认证保护。 拒绝无效 UTF-8，GitHub App 认证与 API 请求不跟随
  HTTP 重定向。使用自托管 Relay 的用户需更新并自行部署对应源码才能获得这些保护。
• 更新恢复更可靠。 Unix Beta 更新保留恢复备份与可执行权限，同步安装和回滚
  的目录变更；Windows 使用跨进程独占锁，并避免覆盖已有备份。
• 依赖来源统一。 Go 模块、Relay 来源与集成锁统一固定到 Foundation v0.1.2。

安装与兼容

npm install -g cc-connect-next@beta
cc-connect-next --version

已有安装可显式执行 cc-connect-next update beta 或 /upgrade beta。
GitHub Latest 和 npm latest 继续保持 v0.2.1；省略 update_channel 仍默认 Stable。
本次发布不更改当前 daemon，也不会自动部署 Relay。Windows 变更已通过交叉编译和
测试覆盖，未完成原生 Windows 运行验证。

English

The fifth v0.3.0 Beta fixes feedback privacy, error-feedback actions, and updater
backup handling, and adopts the published Foundation v0.1.2 patch.

Highlights

• More complete feedback redaction. Quoted configuration keys, escaped
  values, prefixed credentials, cookies, URL user information, and host
  identifiers are redacted before truncation and submission. Ordinary URL
  query parameters and fragments remain intact.
• Error offers belong to the initiating user. Automatic feedback actions in
  shared group sessions reject other users and work correctly with multiple
  workspaces or a fixed working directory. Context with unknown or future
  timestamps is excluded.
• Stronger Relay input and authentication handling. Invalid UTF-8 is
  rejected, and GitHub App authentication and API requests do not follow HTTP
  redirects. Self-hosted Relay operators must update and deploy the matching
  source to receive these protections.
• Safer update recovery. Unix Beta updates retain recovery backups and
  executable permissions and sync installation/rollback directory changes.
  Windows uses an exclusive cross-process lock and avoids overwriting backups.
• One pinned dependency source. The Go module, Relay source, and integration
  lock all use Foundation v0.1.2.

Install and compatibility

npm install -g cc-connect-next@beta
cc-connect-next --version

Existing installations can explicitly run cc-connect-next update beta or
/upgrade beta. GitHub Latest and npm latest remain at v0.2.1. Omitting
update_channel still selects Stable. Publishing does not change a running
daemon or deploy a Relay. Windows changes have compilation and test coverage;
native Windows execution remains unverified.

cc-connect-next v0.3.0-beta.4

cc-connect-next v0.3.0-beta.4

中文

这是 v0.3.0 的第四个 Beta，集中收口 Stable 发布前发现的更新确认、飞书卡片路由和
动态配置校验风险。它不扩大功能范围，而是让现有 Beta 在通道、项目、操作者和配置
类型边界上更明确地失败关闭。

Beta 渠道

• 这个版本会作为 GitHub Prerelease 和 npm beta 发布，不会替换 GitHub Latest
  或 npm latest；稳定渠道继续保持 v0.2.1。

• stable 仍是默认通道。明确参与 Beta 后，可以使用
  cc-connect-next update beta、cc-connect-next check-update beta、
  /upgrade beta，或配置 update_channel = "beta" 来持续发现 Beta-to-Beta
  更新。

• 首次参与或切换到最新 Beta 可使用：

  npm install -g cc-connect-next@beta
  cc-connect-next --version

主要变化

• 更新确认绑定精确通道。 /upgrade stable confirm 和
  /upgrade beta confirm 只能应用此前审阅的同通道不可变 Plan；显式选择错误通道
  会被拒绝，待确认 Plan 会保留，用户仍可用正确通道继续确认。
• 飞书管理员私聊卡片绑定项目、收件人和操作者。 即使项目配置了群聊
  allow_chat，发给明确 admin_from 用户的更新卡片仍可正常操作；错误操作者会被
  拒绝，异步慢速翻页刷新后也不会丢失私聊收件人绑定。
• 同一飞书 App 的多项目回调不再串路由。 新卡片会携带所属项目并只交给对应
  Engine；缺少 owner 的旧卡片在多项目歧义时失败关闭。只有一个项目可接收时，
  旧卡片和基于 allow_chat 的已有配置仍保持兼容。
• 动态配置值不再被静默丢弃。 Agent/Platform 动态 option 表继续允许任意字符串
  key，但数值等非字符串值现在会明确报错，包括 Agent 环境变量和飞书 peer alias。
• 移除未支持的预发布别名歧义。 cc-connect-next update --pre 和 --beta
  会按文档明确拒绝；选择 Beta 请使用 update beta 或 --channel beta。

兼容边界

• 省略 update_channel 的现有配置继续使用 Stable；Beta 必须明确选择。错误通道、
  错误操作者和歧义 owner 都不会回退到猜测执行。
• 动态 option 中的字符串值和任意字符串 key 保持兼容；只拒绝此前会被忽略、从而
  造成配置与运行态不一致的非字符串值。
• 发布本 Beta 不会安装、覆盖或重启当前正在运行的 daemon，也不会部署 Feedback
  Relay；安装、正式配置变更和真实平台验证仍是独立操作。

English

This is the fourth v0.3.0 Beta. It closes the release-confirmation, Feishu card
routing, and dynamic-configuration risks found during the Stable readiness
review. The scope is intentionally narrow: existing Beta behavior now fails
closed at clearer channel, project, operator, and value-type boundaries.

Beta channel

• This release is a GitHub Prerelease and npm beta. It does not replace
  GitHub Latest or npm latest; the stable channel remains v0.2.1.

• stable remains the default. After opting into Beta, use
  cc-connect-next update beta, cc-connect-next check-update beta,
  /upgrade beta, or update_channel = "beta" to keep discovering
  Beta-to-Beta updates.

• Install or move to the latest Beta explicitly with:

  npm install -g cc-connect-next@beta
  cc-connect-next --version

Highlights

• Confirmations are bound to the exact release channel.
  /upgrade stable confirm and /upgrade beta confirm can apply only an
  immutable Plan reviewed for that same channel. A mismatched selector is
  rejected without consuming the pending Plan, so the correct confirmation can
  still proceed.
• Feishu administrator cards bind project, recipient, and operator. Update
  cards sent directly to an explicit admin_from user remain actionable even
  when the project has a group allow_chat list. A different operator is
  rejected, and asynchronous slow-navigation refreshes preserve the direct
  recipient binding.
• Shared-App callbacks no longer cross project boundaries. New cards carry
  their owning project and reach only that Engine. Ownerless legacy cards fail
  closed when multiple projects are ambiguous, while the uniquely eligible
  project and existing allow_chat compatibility path continue to work.
• Dynamic configuration values are no longer silently dropped. Arbitrary
  string keys remain supported in Agent and Platform option tables, but
  non-string values now fail validation, including Agent environment variables
  and Feishu peer aliases.
• Unsupported prerelease aliases fail explicitly.
  cc-connect-next update --pre and --beta are rejected as documented. Use
  update beta or --channel beta to select the Beta channel.

Compatibility boundaries

• Existing configurations that omit update_channel continue to select
  Stable; Beta remains opt-in. A wrong channel, wrong operator, or ambiguous
  owner never falls back to guessed execution.
• Dynamic option string values and arbitrary string keys remain compatible.
  Validation rejects only non-string values that were previously ignored and
  could make the effective runtime differ from the configuration.
• Publishing this Beta does not install, replace, or restart a running daemon,
  and it does not deploy the Feedback Relay. Installation, formal configuration
  changes, and real-platform validation remain separate operations.

cc-connect-next v0.3.0-beta.3

cc-connect-next v0.3.0-beta.3

中文

这是 v0.3.0 的第三个 Beta，集中完成两条产品链路：更新现在可以明确选择 Stable 或
Beta，并在整条事务中保持同一通道；聊天 Feedback 则回到一次明确触发、一次直接
提交的短流程，同时保留结构化脱敏与无 Issue 链接的结果卡片。

Beta 渠道

• 这个版本会作为 GitHub Prerelease 和 npm beta 发布，不会替换 GitHub Latest
  或 npm latest；稳定渠道继续保持 v0.2.1。

• stable 仍是默认通道。明确参与 Beta 后，可以使用
  cc-connect-next update beta、cc-connect-next check-update beta、
  /upgrade beta，或配置 update_channel = "beta" 来持续发现 Beta-to-Beta
  更新；未选择 Beta 的现有用户行为不变。

• 首次参与或切换到最新 Beta 可使用：

  npm install -g cc-connect-next@beta
  cc-connect-next --version

主要变化

• 显式 Stable/Beta 更新通道。 CLI、聊天更新计划和 daemon 提醒都使用同一个
  通道值；发现结果、Release 类型、不可变 Plan 和最终文案会明确标识 Stable 或
  Beta，不再把 prerelease 写成 stable。Beta 复用同一套 checksum、staged 与
  installed version 探针、目标锁、备份和回滚边界。
• 聊天 Feedback 一次触发直接提交。 明确执行 /feedback <描述> 或点击
  Feedback 动作后，会立即生成并提交有界、脱敏的结构化 Draft，不展示预览，也
  不要求第二次确认。Draft 只加入最近相邻、字段化、有界且脱敏的用户/Agent 诊断
  上下文，不上传任意 transcript、日志或配置。
• 自动提示仍然零网络。 回合错误和能力缺口只准备一个一次性 Feedback offer；
  用户未点击时不会访问 Relay，一次点击则提交绑定当前 session/Draft 的精确内容。
• 结果卡片保持极简。 飞书卡片提交后只显示“提交成功”或“提交失败”，不附
  Issue 链接、不另发结果消息。Agent 专用 CLI 仍保留独立的
  feedback preview / approval-token 协议。

兼容边界

• 现有配置省略 update_channel 时继续使用 Stable；Beta 必须明确选择。发布本
  Prerelease 不会改变 Stable 用户的 GitHub Latest、npm latest 或默认更新结果。
• 聊天 /feedback 是明确的外部网络动作，执行命令或点击按钮本身就是提交授权；
  自动错误/能力缺口提示本身始终不上传。
• 精确更新原反馈卡片依赖飞书 card action callback 携带原始 message_id；文字
  路径只返回提交成功或提交失败，同样不输出 Issue 链接。
• 发布 Beta 不会升级、覆盖或重启当前正在运行的 daemon，也不会部署 Relay；
  安装、正式配置变更和真实平台验证仍是独立操作。

English

This is the third v0.3.0 Beta. It completes two product paths: updates can now
select Stable or Beta explicitly and preserve that channel through the entire
transaction, while chat Feedback returns to one explicit trigger and one direct
submission without giving up structured redaction or the link-free result card.

Beta channel

• This release is a GitHub Prerelease and npm beta. It does not replace
  GitHub Latest or npm latest; the stable channel remains v0.2.1.

• stable remains the default. After opting into Beta, use
  cc-connect-next update beta, cc-connect-next check-update beta,
  /upgrade beta, or update_channel = "beta" to keep discovering
  Beta-to-Beta updates. Existing users who do not select Beta are unchanged.

• Install or move to the latest Beta explicitly with:

  npm install -g cc-connect-next@beta
  cc-connect-next --version

Highlights

• Explicit Stable/Beta update channels. The CLI, chat update Plans, and
  daemon notices share one channel value. Discovery, release type, immutable
  Plan, and terminal copy all identify Stable or Beta instead of calling a
  prerelease stable. Beta reuses the same checksum, staged/installed version
  probes, target lock, backup, and rollback boundaries.
• One-action chat Feedback. An explicit /feedback <description> command
  or Feedback card action immediately builds and submits the bounded, redacted
  structured Draft with no preview or second confirmation. The Draft adds only
  recent adjacent, typed, bounded, redacted user/Agent diagnostic context—never
  an arbitrary transcript, log, or configuration map.
• Automatic offers remain zero-network. Turn failures and capability gaps
  prepare a one-time Feedback offer without contacting Relay. One user click
  submits the exact Draft bound to that session; no click means no request.
• Minimal terminal cards stay intact. Feishu shows only 提交成功 or
  提交失败, sends no separate result message, and never exposes the Issue URL.
  The Agent-only CLI keeps its separate feedback preview and approval-token
  protocol.

Compatibility boundaries

• Omitting update_channel continues to select Stable; Beta is always an
  explicit opt-in. This prerelease does not change GitHub Latest, npm latest,
  or the default update result for Stable users.
• Chat /feedback is an explicit external network action: the command or card
  click is the submission approval. Automatic error/capability-gap offers never
  upload by themselves.
• Replacing the exact clicked Feedback card depends on the Feishu card-action
  callback carrying the original message_id. Text Feedback returns only
  success or failure and also omits the Issue URL.
• Publishing this Beta does not install, replace, or restart a running daemon,
  and it does not deploy Relay. Installation, formal configuration changes,
  and real-platform validation remain separate operations.

cc-connect-next v0.3.0-beta.2

cc-connect-next v0.3.0-beta.2

中文

这是 v0.3.0 的第二个 Beta，集中修复 Beta.1 发布后发现的两项兼容性与交互问题：
动态 Agent/Platform option 的嵌套配置不再被误报为不支持，飞书反馈按钮也会在提交
完成后直接把原卡片更新成明确的最终状态。

Beta 渠道

• 这个版本会作为 GitHub Prerelease 和 npm beta 发布，不会替换 GitHub Latest
  或 npm latest；稳定渠道继续保持 v0.2.1。

• daemon 更新提醒、cc-connect-next check-update 和内置
  cc-connect-next update 只查询 Stable，因此不会向稳定用户推送这个 Beta，也
  不会自动执行 Beta-to-Beta 更新。

• 明确参与 Beta 时使用：

  npm install -g cc-connect-next@beta
  cc-connect-next --version

主要变化

• 动态 option 配置不再误报。 Codex 的
  [projects.agent.options.env]、Feishu/Lark 的 mention_map 与 peer_bots
  等由 adapter 声明并消费的动态表，会保留完整键值且不再把嵌套叶子加入
  UnknownConfigKeys。真正未知的顶层 option 仍会报告，类型校验也保持不变。
• 反馈按钮显示明确结果。 用户点击飞书反馈确认按钮后，Relay 完成时会精确
  更新被点击的原卡片：成功只显示“提交成功”，失败、批准缺失/过期或通道停用只
  显示“提交失败”。卡片路径不再另发结果消息，也不展示 Relay 返回的 Issue
  链接；文字命令确认同样不输出 Issue 链接。

兼容边界

• 迁移器继续按目标 adapter 能力 fail closed：目标 Agent 不消费 env，或目标
  Platform 不支持 mention_map / peer_bots 时，迁移仍会明确拒绝，不能把本次
  诊断修复理解为所有动态表都可以跨 adapter 迁移。
• 精确更新原反馈卡片依赖飞书 card action callback 提供原始 message_id。普通
  文字 /feedback confirm 仍然可用，但继续走文字结果路径。
• 发布 Beta 不会升级、覆盖或重启当前正在运行的 daemon；安装、配置变更和真实
  平台验证仍需单独执行。

English

This is the second v0.3.0 Beta. It focuses on two compatibility and interaction
issues found after Beta.1: nested keys in dynamic Agent/Platform options are no
longer misreported as unsupported, and Feishu feedback actions now update the
clicked card with an explicit terminal result.

Beta channel

• This release is a GitHub Prerelease and npm beta. It does not replace
  GitHub Latest or npm latest; the stable channel remains v0.2.1.

• Daemon update notices, cc-connect-next check-update, and the built-in
  cc-connect-next update query Stable releases only. Stable users are not
  prompted to install this Beta, and Beta-to-Beta updates are not automatic.

• Opt in explicitly with:

  npm install -g cc-connect-next@beta
  cc-connect-next --version

Highlights

• Dynamic option keys are no longer false positives. Adapter-declared and
  consumed tables such as Codex [projects.agent.options.env] and Feishu/Lark
  mention_map or peer_bots preserve their complete values without adding
  nested leaves to UnknownConfigKeys. Truly unknown top-level options and
  value-type validation remain intact.
• Feedback actions show an explicit result. After a user confirms a
  Feishu feedback card, Relay completion updates that exact clicked card.
  Success shows only 提交成功; failure, missing or expired approval, and a
  disabled channel show only 提交失败. The card path sends no separate result
  message and never displays the Relay's Issue URL; typed confirmation also
  omits the URL.

Compatibility boundaries

• Migration remains capability-aware and fail closed. A target Agent that does
  not consume env, or a target Platform that does not support mention_map
  or peer_bots, still rejects those values explicitly. This diagnostic fix
  does not make every dynamic table portable across adapters.
• Exact feedback-card replacement depends on the Feishu card action callback
  carrying the original message_id. Typed /feedback confirm remains
  available through the text-result path.
• Publishing this Beta does not install, replace, or restart a running daemon.
  Installation, configuration changes, and real-platform validation remain
  separate actions.

cc-connect-next v0.3.0-beta.1

cc-connect-next v0.3.0-beta.1

中文

这是 v0.3.0 的第一个 Beta，重点验证两条新的可信生命周期：用户反馈必须先展示同一
份完整脱敏 Draft 再独立批准，更新必须先展示同一份不可变 Plan 再执行；同时收口
Agent 回合内安全重启、飞书 P2P 真实话题隔离、管理员私聊更新提醒和失败卡片提示。

Beta 渠道

• 这个版本会作为 GitHub Prerelease 和 npm beta 发布，不会替换 GitHub Latest
  或 npm latest；稳定渠道继续保持 v0.2.1。

• daemon 更新提醒、cc-connect-next check-update 和
  cc-connect-next update 只查询 Stable，因此不会向现有稳定用户推送这个
  Beta，也不会自动完成 Beta-to-Beta 更新。

• 明确参与 Beta 时使用：

  npm install -g cc-connect-next@beta
  cc-connect-next --version

• GitHub Prerelease 中仍提供六个平台 archive/zip 与 checksums.txt，可手动下载
  独立二进制；内置 update 不安装 prerelease。

主要变化

• Feedback 与 Update 接入 Awesome Agent App Features v0.1.1。 聊天
  /feedback 会先展示完整结构化、已脱敏的 Draft；独立按钮或 confirm 只提交
  该 Draft。更新流程使用 Prepare → 展示精确 Plan → confirm → Apply 同一 Plan
  事务，并保留 checksum、staging、版本探针、锁、备份与回滚边界。
• Agent 拥有正式 Feedback CLI。
  cc-connect-next feedback preview --description ... 在零 Relay 网络请求下返回
  完整 Draft 和一次性 token；feedback submit --approval-token ... 必须来自
  HMAC 鉴权的活动 Agent 回合，并绑定可信 project/session/user 与精确 Draft。
  成功回执包含 status、reference_url 和 deduplicated。
• Agent 回合内重启不再杀死自己的父 daemon。 Agent 调用
  cc-connect-next daemon restart 时，会通过 mode-0600 Unix API 和回合凭证
  登记 deferred restart，等待当前回答、卡片、Agent writer 与已接收队列完成后
  进入既有 graceful restart/Ready 回执链。外部终端的 supervisor 行为保持不变。
• 飞书/Lark P2P 真实话题获得独立上下文。 启用 thread isolation 时，非空
  thread_id 成为稳定 session/workspace 身份；用于真实回复的 om_
  message ID 单独持久化，绝不会把 omt_ thread ID 当 Reply API message ID。
• 稳定版提醒只发明确管理员私聊。 最近群聊、群话题、P2P 话题和普通成员
  session 永远不是 fallback。只有唯一 direct-user 平台和明确列出的
  admin_from ID 才会收到提醒；空值、*、歧义或不支持时保持静默。每轮
  发送完整管理员名单，只有全员成功才记录完成；部分失败会在下一轮完整重试。
• 失败原因更可操作但不泄露上游原文。 Codex 模型容量不足会显示本地化的
  “稍后重试或切换模型”提示；未知错误继续使用通用安全文案，凭据、路径、内部 ID
  和未经审查的 provider 文本不会进入卡片。
• Slash command 保持逐字可复制。 普通文本与 inline code 中的
  /feedback、/new、custom command 和 Skill 命令不再被本地路径渲染器
  去掉斜杠或添加 marker；多段真实绝对路径仍按原规则渲染。
• Feedback Relay 保留旧客户端兼容。 新结构化请求进入 Foundation Relay；
  精确的旧 schema-1 请求先转换，目标仓库和 Issue 渲染继续由服务端控制。
  GitHub 操作使用仓库限定的 GitHub App installation token。

升级与兼容边界

• 已启用 Feishu thread_isolation 的 P2P 真实话题升级后会使用新的
  thread:<omt_...> session key；此前共享在普通私聊 session 的上下文不会自动
  迁移到新话题。
• 主动更新提醒需要 [[projects]] 下明确的 admin_from = "ou_..."，并且
  项目中只有一个平台实现 direct-user 消息。空值或 * 仍可用于权限语义，但
  无法枚举为固定提醒收件人。
• 自定义 feedback.endpoint 必须使用 HTTPS 且路径精确为 /v1/feedback；
  只有 localhost/loopback 开发环境允许 HTTP。
• Agent Feedback 与安全重启需要新版 daemon 的本地 API。新 CLI 面对旧 daemon
  会在变更前 fail closed，不会退化为伪造聊天消息或立即 supervisor restart。
• 发布 Beta 不会升级当前正在运行的 daemon。升级、配置变更和真实平台验证仍需
  单独执行。

反馈

Beta 期间如遇到问题，请在聊天中发送 /feedback <描述>，检查完整脱敏预览后
再确认提交；无需 GitHub 账号。

English

This is the first v0.3.0 Beta. It previews two trusted lifecycles: feedback is
rendered from one complete redacted Draft before separate approval, and updates
render one immutable Plan before applying that same Plan. It also closes the
Agent-invoked restart lifecycle, Feishu P2P topic isolation, administrator-only
update reminders, and actionable failure-card gaps.

Beta channel

• This release is a GitHub Prerelease and npm beta. It does not replace
  GitHub Latest or npm latest; the stable channel remains v0.2.1.

• Daemon update notices, cc-connect-next check-update, and
  cc-connect-next update query Stable releases only. Existing stable users
  are not prompted to install this Beta, and Beta-to-Beta updates are not
  automatic.

• Opt in explicitly with:

  npm install -g cc-connect-next@beta
  cc-connect-next --version

• The GitHub Prerelease still includes six platform archives/zips and
  checksums.txt for manual standalone installation. The built-in
  update command never installs prereleases.

Highlights

• Feedback and Update now consume Awesome Agent App Features v0.1.1.
  Chat /feedback renders the complete structured, redacted Draft first;
  a separate button or confirmation submits only that Draft. Updates use a
  Prepare → render exact Plan → confirm → Apply the same Plan transaction
  with checksum, staging, version probes, locking, backup, and rollback.
• Agents get a formal Feedback CLI.
  cc-connect-next feedback preview --description ... returns the complete
  Draft and a one-time token with zero Relay network requests.
  feedback submit --approval-token ... requires a live HMAC-authenticated
  Agent turn and binds trusted project/session/user identity to the exact
  Draft. Receipts include status, reference_url, and deduplicated.
• Agent-invoked restart no longer kills its parent daemon. Inside a turn,
  cc-connect-next daemon restart registers a deferred action through the
  mode-0600 Unix API and turn credential. The existing graceful restart/Ready
  acknowledgement runs only after the answer, card, Agent writer, and accepted
  queue finish. External-terminal supervisor behavior is unchanged.
• Real Feishu/Lark P2P topics receive independent context. With thread
  isolation enabled, a non-empty thread_id becomes the stable session and
  workspace identity. The concrete om_ message ID required for replies is
  persisted separately; an omt_ thread ID is never sent as a Reply API
  message ID.
• Stable-release reminders go only to explicit administrator DMs. Recent
  groups, topics, P2P topics, and ordinary member sessions are never fallback
  targets. Delivery requires one unambiguous direct-user platform and explicit
  admin_from IDs; empty, wildcard, ambiguous, or unsupported targets stay
  silent. Every incomplete pass retries the full administrator list and marks
  the project/version complete only after one all-success pass.
• Failures become actionable without exposing provider text. Codex model
  capacity errors show localized retry-or-switch guidance. Unknown errors keep
  the generic safe copy; credentials, paths, internal IDs, and unreviewed
  provider text never enter the card.
• Slash commands stay byte-for-byte copyable. /feedback, /new,
  runtime custom commands, and Skill commands in prose or inline code are no
  longer rewritten as local paths. Unambiguous multi-segment absolute paths
  keep the existing rendering behavior.
• The Feedback Relay remains compatible with installed clients. New
  structured submissions enter the Foundation Relay; exact legacy schema-1
  requests are translated first. Repository selection and Issue rendering
  remain server-owned, and GitHub writes use a repository-scoped GitHub App
  installation token.

Upgrade and compatibility boundaries

• Existing P2P Feishu topics with thread_isolation enabled start using
  thread:<omt_...> session keys. Context previously shared in the ordinary
  private-chat session is not migrated into the new topic session.
• Proactive update notices require explicit admin_from = "ou_..." entries
  under [[projects]] and exactly one direct-user-capable platform. Empty or
  wildcard values remain valid permission policies but cannot enumerate fixed
  reminder recipients.
• A custom feedback.endpoint must use HTTPS and the exact
  /v1/feedback path. HTTP is accepted only for localhost/loopback
  development.
• Agent Feedback and safe restart require the new daemon local API. A new CLI
  talking to an old daemon fails closed before mutation; it never falls back
  to a fake chat message or immediate supervisor restart.
• Publishing the Beta does not upgrade a running daemon. Installation,
  configuration changes, and real-platform validation remain separate actions.

Feedback

During the Beta, send /feedback <description> in chat, review the complete
redacted preview, and then confirm it. No GitHub account is required.

cc-connect-next v0.2.1

cc-connect-next v0.2.1

中文

这个稳定版让 cc-connect-next 的能力与配置真正可以被 Agent 自己理解：运行中
的 Agent 能查询与当前版本、项目和会话一致的能力清单，配置说明也由可执行契约
统一生成。飞书话题隔离同时细化为三种明确模式，Bridge 投递、会话切换、Claude
Code 长连接和 Codex App 会话标题等路径也完成收口。

变化

• Agent 可以查询当前运行态到底能做什么。 新的只读 Agent Capability
  Manifest 统一描述配置、Agent-facing CLI 工具、内置和自定义聊天命令、Skills，
  以及当前 Agent、会话和平台的可选能力。每一项都包含参数、调用权限、只读属性、
  写入或外部副作用、退化行为、可用状态与原因。Agent 可通过
  cc-connect-next capabilities --search "关键词" 查询与当前版本和项目匹配的
  结果；Management API、Web 命令面板和 Agent brief 使用同一事实源。
• 配置目录升级为可执行契约。 所有公开 TOML、环境变量和持久启动参数都声明
  精确位置、类型、必填或条件关系、省略默认值、推荐预设、枚举或数值边界、单位、
  生效方式、敏感性和可解析示例。cc-connect-next config capabilities 支持自然
  语言搜索、精确 key、Agent/平台过滤以及 Markdown/JSON 输出；中英文参考文档和
  Web 设置常量由同一契约生成。动态 Agent/平台配置现在会在构造适配器之前验证，
  不再静默忽略明显的类型或必填错误。
• 飞书/Lark 话题隔离变成三个明确范围。 thread_isolation = "off" 保留
  旧的用户/频道会话；"topics_only" 只隔离飞书事件中真实存在 thread_id
  的话题，普通群消息仍留在群主会话；"topic_per_message" 保留此前每条顶层
  群消息都建立话题的行为。新 Starter 和推荐飞书配置写入 "topics_only"。
  即使 reply_to_trigger = false，真实话题的回复也不会泄漏回群主会话。
• Bridge 重复消息与持久定时投递更安全。 非空 msg_id 现在按 adapter、
  project 和 session 做短窗口幂等，连接替换后重复帧也会在进入 Engine/FIFO 前
  丢弃。Cron/Timer 在创建、更新、启用和手动触发前验证目标是否支持持久主动投递；
  依赖浏览器在线连接的 Web/Bridge session 会明确拒绝，而不是先显示 triggered
  再在连接消失后丢失消息。
• 飞书身份发现失败时安全拒绝。 mention-gated 的飞书/Lark WebSocket 项目若
  启动时无法解析机器人 open_id，会进入可观测的降级状态并拒绝无法可靠过滤的
  群消息；后台恢复成功后自动解除。Webhook、私聊和显式 group_reply_all 行为
  保持不变。
• 会话连续性得到修复。 Claude Code 不再传入会让当前 CLI 每轮退出的
  --replay-user-messages，原生 /compact 等命令可以继续进入存活会话。显式
  /switch、Management API 或 Bridge 选择旧会话后，第一条消息不会再被
  reset_on_idle_mins 立即旋转到新会话。
• 回复底部现在包含本轮真实耗时。 开启 reply_footer 时，普通消息、rich
  card 和原生流式卡片会显示模型、推理强度与处理时间；排队等待和仅用于展示的
  卡片停留时间不会被算入本轮处理耗时。
• Codex App 新会话拥有可读标题。 app-server 在 fresh thread 创建后、首轮
  开始前，用真实用户请求生成安全的简短标题，并支持可配置来源前缀。显式 /name
  会同步到兼容的在线 Codex 会话；可选 session_title_model 使用隔离的本地临时
  Codex 进程，失败时安全回退，不影响用户回合。
• 移除没有消费者的 session context/usage telemetry。 Codex 不再在每轮后
  扫描 rollout 文件，也不再在 app-server 会话启动时额外请求 session 级 rate
  limit。Manifest 会如实说明 session context usage 不可读；Agent 级 /usage
  配额查询保持不变。面向 Go 嵌入方的 ContextUsageReporter 和 ContextUsage
  类型随这条无消费者链路一并删除。
• 特权命令的权限契约一致。 /timer addexec 的延迟 shell 注册现在和
  /cron addexec、/commands addexec 一样要求 admin_from；Manifest 会同时
  显示权限与副作用，避免 Agent 把可发现误解为可直接执行。

默认值与升级须知

• 现有 TOML 无需迁移。省略飞书 thread_isolation 仍等价于 "off"；旧
  false 映射 "off"，旧 true 映射 "topic_per_message"。希望只隔离真实
  话题时请显式使用 "topics_only"。
• fresh Starter 现在显式写入 Codex mode = "yolo"，会跳过审批并取消 sandbox
  限制；推荐飞书配置仍包含 group_reply_all = true。把机器人加入共享群前，请按
  需要改回 mode = "default"，并设置 allow_from / allow_chat，或关闭
  group_reply_all。手写旧配置省略 mode 时仍使用兼容 fallback。
• reply_footer 的内置默认值现在是 true；若不希望现有会话出现模型、推理强度
  和耗时状态行，请在全局 [display] 或项目级 [projects.display] 显式设置
  reply_footer = false。
• 直接嵌入 Go 包且实现或引用 ContextUsageReporter / ContextUsage 的下游代码
  需要删除对应编译期依赖。普通 CLI、daemon、配置和 /usage 用户不受影响。
• 持久 Cron/Timer 如果目标是连接期 Web/Bridge session，升级后会在写入时明确
  拒绝；请改用能够重建主动投递上下文的平台目标。

升级

cc-connect-next update
# 或
npm install -g cc-connect-next

English

This stable release makes cc-connect-next self-describing to the Agent that is
actually running: capabilities are queryable for the current version, project,
and session, while configuration documentation is generated from an executable
contract. Feishu topic isolation now has three explicit scopes, and Bridge
delivery, session switching, Claude Code continuity, and Codex App titles are
more predictable.

Changes

• Agents can query what the current runtime can actually do. The new
  read-only Agent Capability Manifest unifies configuration, Agent-facing CLI
  tools, built-in and custom chat commands, Skills, and optional capabilities
  of the active Agent, session, and platform. Every entry includes parameters,
  caller permission, read-only status, write or external side effects,
  fallback behavior, availability, and its reason. Agents can search the
  version- and project-matched result with
  cc-connect-next capabilities --search "keywords"; the Management API, Web
  command palette, and Agent brief consume the same source of truth.
• The configuration catalog is now an executable contract. Every public
  TOML option, environment override, and persistent startup flag declares its
  exact location, type, requirement or condition, omitted default, recommended
  presets, enum or numeric bounds, units, apply mode, sensitivity, and a
  parseable example. cc-connect-next config capabilities supports natural
  language search, exact keys, Agent/platform filters, and Markdown or JSON;
  bilingual references and Web settings constants are generated from that same
  contract. Dynamic Agent/platform options are validated before adapter
  construction instead of silently accepting obvious type or requirement
  errors.
• Feishu/Lark topic isolation has three explicit scopes.
  thread_isolation = "off" keeps the legacy user/channel session;
  "topics_only" isolates only real topics whose events contain a thread_id
  while ordinary group messages stay in the main chat; and
  "topic_per_message" preserves the previous behavior that promotes every
  top-level group message into its own topic. New Starter and recommended
  Feishu profiles write "topics_only". Real-topic replies remain in their
  topic even when reply_to_trigger = false.
• Bridge duplicates and persistent scheduled delivery fail safely. A
  non-empty msg_id is now a short-window idempotency key scoped by adapter,
  project, and session, including across adapter connection replacement. Cron
  and Timer validate durable delivery before create, update, enable, or manual
  trigger; browser-connection-scoped Web/Bridge sessions are rejected clearly
  instead of appearing triggered and losing delivery after disconnect.
• Feishu identity discovery fails closed for mention-gated groups. If a
  Feishu/Lark WebSocket project cannot resolve the bot open_id at startup, it
  enters an observable degraded state and rejects group traffic it cannot
  filter reliably. A background supervisor restores normal handling after
  recovery. Webhooks, private chats, and explicit group_reply_all behavior
  are unchanged.
• Session continuity is fixed. Claude Code no longer receives
  --replay-user-messages, which made current CLI processes exit after each
  turn and prevented native commands such as /compact from reaching the live
  session. After explicit selection through /switch, the Management API, or
  Bridge, the first message in an old conversation is no longer immediately
  rotated by reset_on_idle_mins.
• The reply footer includes real turn duration. When reply_footer is
  enabled, plain replies, rich cards, and native streaming cards show model,
  reasoning effort, and processing time. Queue wait and presentation-only card
  dwell are excluded from the turn duration.
• Fresh Codex App sessions receive readable titles. The app-server derives
  a safe concise title from the real user request after fresh thread creation
  and before the first turn, with a configurable source prefix. Explicit
  /name changes sync to compatible live Codex sessions. Optional
  session_title_model generation runs in an isolated local ephemeral Codex
  process and falls back without affecting the user turn.
• Unused session context/usage telemetry is removed. Codex no longer scans
  rollout files after every turn or performs an extra session-level rate-limit
  request during app-server startup. The Manifest truthfully marks session
  context usage unreadable; Agent-level /usage quota reporting is unchanged.
  The exported Go ContextUsageReporter interface and ContextUsage type were
  removed with this consumer-free path.
• Privileged command registration has one permission contract. Delayed
  shell registration through /timer addexec now requires admin_from, just
  like /cron addexec and /commands addexec. The Manifest exposes both the
  permission and the side effect, so discoverability is not mistaken for
  authorization.

Defaults and upgrade notes

• Existing TOML does not require migration. Omitting Feishu
  thread_isolation still means "off"; legacy false maps to "off", and
  legacy true maps to "topic_per_message". Use "topics_only" explicitly
  when only real topics should be isolated.
• Fresh Starter configs now write Codex mode = "yolo", which bypasses
  approvals and sandbox restrictions; the recommended Feishu profile still
  includes group_reply_all = true. Before adding the bot to a shared group,
  consider restoring mode = "default", setting allow_from / allow_chat,
  or disabling group_reply_all. Hand-written legacy configs that omit mode
  retain the compatibility fallback.
• The built-in reply_footer default is now true. Set
  reply_footer = false under global [display] or per-project
  [projects.display] to keep the model, effort, and elapsed-time line hidden.
• Downstream Go embedders that referenced or implemented
  ContextUsageReporter / ContextUsage must remove that compile-time
  dependency. Ordinary CLI, daemon, configuration, and /usage users are not
  affected.
• Persisted Cron/Timer jobs targeting connection-scoped Web/Bridge sessions are
  now rejected at write time. Choose a platform target that can reconstruct
  proactive delivery context.

Upgrade

cc-connect-next update
# or
npm install -g cc-connect-next

cc-connect-next v0.2.0

cc-connect-next v0.2.0

中文

这个稳定版重点收紧 Codex app-server 的父子代理隔离，并把迁移、更新、会话
恢复和定时任务等关键路径收敛到更可靠的实现；同时加入单条消息回答档位、
/new 同条首问和官方 lark-cli companion。Go 1.25.13、Go/Web 安全依赖与
全量 lint 基线也完成升级，为后续 tag 构建建立可重复通过的发布门禁。

变化

• Codex 原生子代理不再污染父回合。 app-server 现在按归属隔离子代理的
  thread、turn、item、error、token usage、审批和用户问答事件，避免子任务
  输出混入父回复或提前结束父回合。来自其他回合的交互请求会在有限时间内
  拒绝；若写入阻塞，连接会中止，不再卡住整个聊天读取循环。
• 可显式设置 Codex 上下文窗口。 新增一等配置项
  model_context_window，exec 与 app-server 后端都会使用该值。它是可选项；
  不配置时保持 Codex 自身默认行为。
• 会话恢复与公共运行时更稳。 活跃 provider 和最后用户活动时间会完整
  持久化；多个 agent 共用 provider 状态和附件暂存实现；Cron 与 Timer 共用
  一条 shell 执行链路，并正确支持 timeout = 0；回合处理器完成拆分但保留
  原有对外契约。
• 真实端到端路径完成收口。 Web 管理台默认只显示并发送到自己的 Web
  会话，外部平台会话必须显式选择；--config <路径> doctor 不再误启动
  daemon；Bridge 的 ready 状态会跟随 adapter 连接生命周期；排队和 steer
  消息会刷新最后用户活动时间；doctor 会检查配置实际使用的 data_dir。
• 每条消息可以单独选择回答档位。 Codex 项目可配置 fast 与 quality
  profile，并通过 /fast <任务>、/quality <任务> 或保守的中文前缀只影响
  当前一条消息；下一条普通消息自动恢复项目默认。忙时 profile 消息进入独立
  FIFO turn，不会错误复用无法携带档位参数的 turn/steer。
• 新会话可以同条发送首问。 /new <问题> 会创建全新会话并立即处理
  <问题>，不再需要先 /new 再补发一次；无参数 /new 仍创建空白会话，
  显式命名继续使用 /name。
• 同一飞书机器人可直接用于官方 lark-cli。 feishu setup、迁移完成流程
  和独立的 cc-connect-next lark-cli setup 可以创建或复用隔离 profile，设为
  默认 profile 与默认 bot 身份，同时保留旧 profile 和用户 OAuth。App Secret
  只通过 stdin 交给 lark-cli；dry-run 不写入，也不会启动第二条事件连接。
• 更新可以直接用自然语言完成。 新版本提醒在支持的平台提供【立即更新】
  按钮，也可回复“更新”“升级到最新版”或 update。同一条消息只保留一个
  主操作，管理员与禁用命令门禁仍然生效，/upgrade 继续可用。
• 不需要测试应用的一键生产迁移。 当官方 CC Connect 与 cc-connect-next
  使用相同平台凭据时，启动会拒绝危险并行；migrate --switch 要求外部终端
  且没有已安装的 Next 服务，随后停止并禁用官方、最终同步并启动 Next。成功后
  必须等本地 API 与所有配置平台真实 Ready，CLI 才私聊唯一或显式飞书/Lark
  操作者；歧义和发送失败不会误发群聊或回滚迁移。激活失败时，只有 Next 已解除
  注册、socket 不再应答且配置锁释放，才恢复官方服务；Windows 计划任务查询失败
  也会安全拒绝。daemon status 会分别显示 Service 与 Runtime/Platforms。
• 迁移、平台和上游兼容性修复。 本版补齐迁移预检与竞态保护，支持将
  官方 beta.4、beta.5 和稳定版 v1.5.0 作为精确迁移来源；同时修复 Markdown
  长消息切分、QQ Bot 命令按钮、Claude Code/pi/Antigravity 等 agent 行为，
  并完成官方 v1.4.1 到 v1.5.0 的逐提交审计。
• 安全与质量门禁更新。 构建基线升级为 Go 1.25.13，并升级
  golang.org/x/crypto、x/net、slack-go 等安全相关依赖；Slack 文件事件
  与上传同步适配当前 SDK。Vite、PostCSS、React Router 及传递依赖完成修补。
  pnpm 的 esbuild 安装白名单改为有效 workspace 配置；生产依赖 audit 为零，
  完整 audit 无 high/critical，golangci-lint 全量检查为零且没有关闭任何
  linter。

升级

cc-connect-next update
# 或
npm install -g cc-connect-next

升级须知：无需迁移现有配置。model_context_window 与 answer profiles 都是
可选项；官方 lark-cli companion 也只在交互确认或显式 flag 下写入，不会执行
用户 OAuth。若同一平台凭据仍被官方 CC Connect 占用，请先使用迁移切换流程
或停止其中一个 daemon。

English

This stable release tightens parent/subagent isolation in the Codex app-server
and makes migration, updates, session recovery, and scheduled work more
reliable. It also adds one-shot answer profiles, first-prompt /new, and the
official lark-cli companion. The release baseline moves to Go 1.25.13 with
upgraded Go/Web security dependencies and a clean full-lint gate.

Changes

• Native Codex subagents no longer contaminate the parent turn. The
  app-server now isolates subagent thread, turn, item, error, token-usage,
  approval, and user-input traffic by ownership, preventing child output from
  leaking into or prematurely completing the parent reply. Interactive
  requests owned by another turn are rejected within a bounded write; a
  blocked write aborts the transport instead of wedging the chat read loop.
• The Codex context window is configurable. model_context_window is a
  first-class option used by both exec and app-server backends. It is optional;
  omitting it preserves Codex's own default behavior.
• Session recovery and shared runtime paths are safer. Active-provider and
  last-user-activity state now persist completely; agents share provider-state
  and attachment-staging implementations; Cron and Timer use one shell runner
  with correct timeout = 0 behavior; turn processing is separated without
  changing the public engine contract.
• Real end-to-end paths are internally consistent. The Web dashboard now
  displays and sends through its own Web session unless another session is
  explicitly selected; --config <path> doctor cannot start the daemon;
  Bridge readiness follows adapter connections; queued and steered messages
  refresh user activity; and doctor checks the configured data_dir.
• Each message can select its own answer profile. Codex projects can define
  fast and quality profiles and apply them with /fast <task>,
  /quality <task>, or conservative Chinese prefixes. The following ordinary
  message automatically restores project defaults; profiled busy messages use
  their own FIFO turn instead of a turn/steer call that cannot carry profile
  settings.
• A new session can receive its first prompt immediately. /new <prompt>
  creates a fresh session and handles <prompt> in the same message. Plain
  /new still creates an empty session, and /name remains the explicit naming
  command.
• The same Feishu bot can back the official lark-cli. feishu setup, the
  completed migration flow, and cc-connect-next lark-cli setup can create or
  reuse an isolated profile, make it the default profile and default bot
  identity, and preserve old profiles plus user OAuth. The App Secret reaches
  lark-cli through stdin; dry-runs do not write, and no second event connection
  is started.
• Updates work in natural language. Release notices offer an [Update now]
  button where supported, and replies such as “update” or “upgrade to the
  latest version” enter the same flow. Each message keeps one primary action,
  admin and disabled-command gates still apply, and /upgrade remains
  available.
• One-command production migration needs no test app. Startup refuses an
  unsafe overlap when official CC Connect and cc-connect-next share platform
  credentials. migrate --switch requires an external terminal and no installed
  Next service, then stops/disables official, final-syncs, starts Next, and waits
  for the local API plus every configured platform to report Ready. The CLI then
  privately notifies one unique or explicit Feishu/Lark operator; ambiguity and
  send failure never fall back to a group or roll back successful migration.
  Failed activation restores official only after Next is proven unregistered and
  stopped; Windows Task Scheduler query failures now fail closed. daemon status
  separates Service from Runtime/Platforms.
• Migration, platform, and upstream compatibility fixes. This release
  strengthens migration preflight and race handling, accepts official beta.4,
  beta.5, and stable v1.5.0 as exact migration provenance, and fixes Markdown
  long-message splitting, QQ Bot command buttons, and Claude
  Code/pi/Antigravity behavior, backed by a commit-by-commit audit from
  official v1.4.1 through v1.5.0.
• Updated security and quality gates. The build baseline is Go 1.25.13,
  with patched golang.org/x/crypto, x/net, slack-go, and related modules;
  Slack file events and uploads now follow the current SDK contracts. Vite,
  PostCSS, React Router, and transitive packages are upgraded. pnpm's esbuild
  allowlist is valid workspace YAML; the production audit is clean, the full
  audit has no high or critical findings, and the complete golangci-lint run
  is clean without disabling any linter.

Upgrade

cc-connect-next update
# or
npm install -g cc-connect-next

Upgrade notes: no existing configuration migration is required.
model_context_window and answer profiles are optional. The official lark-cli
companion writes only after interactive confirmation or an explicit flag and
does not perform user OAuth. If official CC Connect still owns the same platform
credentials, use the migration switch flow or stop one daemon first.

cc-connect-next v0.1.5

cc-connect-next v0.1.5

中文

这个稳定版带来一条完整的反馈通路：使用中遇到任何问题，都可以在聊天里一键
反馈给项目作者——无需 GitHub 账号。同时修复了 Codex app-server 后端丢弃
cmd 额外参数的问题（issue #37），service_tier 成为一等配置项，rich
卡片支持简洁的模型信息 footer。

变化

• 应用内反馈通道。 回合失败后会出现一张询问卡：梳理好的问题 +
  「要反馈给作者吗？」+【反馈给作者】【忽略】按钮。点一下即匿名提交为
  GitHub issue（经作者侧中继，无需 GitHub 账号），最近错误与配置上下文
  自动附上，凭据/ID/路径自动脱敏。也可随时手动发送
  /feedback <描述>。重复问题自动合并为已有 issue 的 +1 评论。
  绝不会在未经你同意的情况下上报任何内容；[feedback] enabled = false
  可整体关闭。
• Agent 知道真实的配置面。 每个会话首条消息注入一段能力简报，列出当
  前 agent 全部可配置项。问 Agent"怎么配 X"时，它基于真实键集回答；不
  存在的能力会如实告知并指引反馈，不再编造配置键。
• Codex cmd 额外参数在 app-server 后端生效（issue #37）。 自定义二
  进制路径与 -c 覆盖现在两个后端行为一致；结构化选项在键冲突时优先。
• service_tier 一等配置项。 service_tier = "fast" 直接写在
  [projects.agent.options]，无需再经 cmd 注入；reasoning_effort
  新增支持 "max"，不支持的取值会告警而非静默忽略。
• rich 卡片支持回复 footer。 reply_footer = true 时完成卡片底部显
  示一行 模型 · effort（默认关闭，隐私优先契约不变）。footer 内容整体
  瘦身为仅模型与推理强度；show_context_indicator 与
  show_workdir_indicator 废弃为无操作。
• 配置错误不再静默。 顶层配置里本版本不认识的键会在启动后主动提示，
  并可一键反馈给作者。

升级

cc-connect-next update
# 或
npm install -g cc-connect-next

升级须知：反馈通道默认开启（提交永远需要你逐次同意）；若此前开启了
reply_footer，footer 内容将从多行元数据变为一行 模型 · effort。

English

This stable release ships a complete feedback loop: any problem you hit can
be reported to the project author straight from chat — no GitHub account
needed. It also fixes the Codex app-server backend dropping cmd extra
args (issue #37), promotes service_tier to a first-class option, and adds
a compact model footer to rich cards.

Changes

• In-app feedback channel. After a failed turn a question card appears:
  the summarized problem plus "Report to the author?" with
  [Report to author] / [Ignore] buttons. One tap files an anonymous GitHub
  issue through an author-operated relay (no GitHub account required), with
  the recent error and config context attached and credentials/ids/paths
  redacted automatically. /feedback <description> works anywhere, any
  time. Duplicate reports thread onto the existing issue as "+1" comments.
  Nothing is ever submitted without your explicit consent;
  [feedback] enabled = false turns the channel off entirely.
• The agent knows the real configuration surface. Each session's first
  message carries a capability brief listing every configurable option for
  the active agent, so asking "how do I configure X" gets answers from the
  real option set — capabilities that do not exist are stated plainly with
  a pointer to feedback, instead of invented keys.
• Codex cmd extra args reach the app-server backend (issue #37).
  Custom binaries and -c overrides now behave identically on both
  backends; structured options win on duplicate keys.
• First-class service_tier. Set service_tier = "fast" directly in
  [projects.agent.options] — no more smuggling it through cmd.
  reasoning_effort additionally accepts "max", and unsupported values
  warn instead of being silently ignored.
• Rich cards can render the reply footer. With reply_footer = true, a
  finished card carries a dim model · effort line (default off; the
  privacy-first contract is unchanged). The footer itself slims down to
  model and effort only; show_context_indicator and
  show_workdir_indicator become documented no-ops.
• Config mistakes are no longer silent. Top-level keys this build does
  not recognize are announced after startup and can be reported to the
  author with one tap.

Upgrade

cc-connect-next update
# or
npm install -g cc-connect-next

Upgrade notes: the feedback channel is enabled by default (submission
always requires your per-case consent); if you had reply_footer on, the
footer changes from multi-line metadata to a single model · effort line.

cc-connect-next v0.1.4

cc-connect-next v0.1.4

中文

这是修复默认配置链路的稳定补丁版。v0.1.3 已把忙时消息策略默认改为
steer，但直接安装生成的配置仍使用不具备原生 steer 能力的 Agent/后端，
导致默认策略在首次安装后只能回退到排队。v0.1.4 让策略默认与后端默认真正
对齐。

变化

• 直接安装默认即可使用 native steer。 首次运行生成的配置现在显式写入
  [queue] busy_message_mode = "steer"，默认 Agent 改为 Codex，并使用
  backend = "app_server" + app_server_url = "stdio" 启动本地 Codex
  app-server。替换配置中的 REPLACE 占位值后，无需再补隐藏配置即可使用
  turn/steer。
• 已有最简 Codex 配置自动修复。 对 Codex 而言，省略 backend 现在等同于
  app_server，省略 app_server_url 现在等同于 stdio。因此升级后，不需要
  重写配置也能获得与新安装相同的 steer 能力。
• 显式 exec 仍受支持。 已明确配置 backend = "exec" 的用户保持每回合
  codex exec --json 子进程行为；该后端不能向进行中的回合追加输入，忙时
  消息会安全回退到 FIFO 队列。若你依赖旧行为，请显式保留此配置。
• doctor 可直接看出能力。 cc-connect-next doctor 现在会报告当前后端是否
  支持 native steer；配置选择了 steer、但后端不支持时会给出明确警告和修复
  方向。
• 文档与安装说明对齐。 README、配置示例、双语使用文档、npm README 和
  飞书卡片契约均已改为描述真实默认值及 exec 兼容退出路径。

升级

稳定版用户可以直接更新或重新安装：

cc-connect-next update
# 或
npm install -g cc-connect-next

升级前若 Codex 配置没有写 backend，升级后它会从逐回合 exec 切换为本地
app-server/stdio。需要保留旧路径时，显式设置：

[projects.agent.options]
backend = "exec"

English

This stable patch fixes the default configuration chain. v0.1.3 made steer
the default busy-message policy, but a direct install still generated an
agent/backend combination without native steering, so the policy could only
fall back to the queue. v0.1.4 aligns the backend defaults with the policy.

Changes

• Direct installs get native steering by default. The generated config now
  explicitly writes [queue] busy_message_mode = "steer", selects Codex, and
  launches a local Codex app-server with backend = "app_server" plus
  app_server_url = "stdio". After replacing the REPLACE placeholders,
  turn/steer works without additional hidden configuration.
• Existing minimal Codex configs are fixed too. For Codex, an omitted
  backend now resolves to app_server, and an omitted app_server_url
  resolves to stdio. Upgrading therefore gives existing minimal configs the
  same steer-capable path without rewriting the config file.
• Explicit exec remains supported. Users who set backend = "exec" keep
  the per-turn codex exec --json subprocess behavior. That backend cannot
  append input to an in-flight turn, so busy messages safely fall back to FIFO.
  Keep this setting explicitly if you depend on the legacy path.
• Doctor exposes the capability. cc-connect-next doctor now reports
  whether the configured backend supports native steering and gives a clear
  warning plus remediation when steer is selected without that capability.
• Installation and configuration docs match reality. The READMEs, config
  example, bilingual usage docs, npm README, and Feishu card contract now
  describe the actual defaults and the explicit exec compatibility opt-out.

Upgrade

Stable users can update or reinstall directly:

cc-connect-next update
# or
npm install -g cc-connect-next

If an existing Codex config omits backend, upgrading changes it from the
per-turn exec path to local app-server/stdio. To retain the old path, set:

[projects.agent.options]
backend = "exec"