向代理说明依赖升级任务，同时保留应用兼容性

一份有用的依赖升级请求，要说明依赖名称、当前与目标版本、应用必须保留的行为，以及接受改动前需要什么证据。请代理同时查看依赖图与调用该包的代码。锁文件被重写，不代表 API 已兼容，也不代表应用行为正确。

GitHub 的 Dependabot 错误参考介绍了直接与间接依赖关系导致更新受阻的情况。这也是升级前先看依赖图的理由，而不是把升级只当作改版本号。下面的例子在此基础上加入一份独立的应用层契约。

画出可能变化的两层依赖

本文的应用、包名、版本、接口和发行说明均为虚构，用于演示升级任务，不代表真实软件包、安全公告或已执行的测试。

假设一个订单导出应用有一个直接格式化依赖。它记录的依赖图如下：

order-export application
  -> fictive-csv-writer 1.4.0       direct dependency
       -> fictive-quote-core 1.2.0 indirect dependency

Proposed target graph
order-export application
  -> fictive-csv-writer 2.0.0       direct dependency
       -> fictive-quote-core 2.1.0 indirect dependency

在这次练习中，它们是明确选定的版本，不是在描述某个真实包管理器的版本范围语法或锁文件格式。应用只导入直接依赖；间接依赖的变化如果影响直接依赖生成的输出，仍可能影响应用。

虚构目标版本的说明如下：

fictive-csv-writer 2.0.0
- 将 writeRows(rows, { header: true }) 替换为
  renderRows(rows, { columns: [...] })。
- 返回 { text, rowCount }，不再直接返回字符串。
- 使用 fictive-quote-core 2.1.0。
- columns 数组中各列的位置决定输出顺序。
- 任意行缺少选定列时，引发 MissingColumnError。
- 保留已定义的逗号与双引号引用规则。
- 默认记录分隔符从 CRLF 改为 LF。
- 可设置 recordSeparator: "\r\n" 来保留 CRLF 输出。

运行时支持信息：本练习未提供。

这份说明引出了三个不同问题：依赖图能否成功解析？调用方能否使用新 API？生成的文件是否仍符合下游使用方的要求？它们需要不同证据。

把调用方契约放在 API 变化旁边

原应用封装是：

import { writeRows } from "fictive-csv-writer";

export function exportOrders(rows) {
  return writeRows(rows, { header: true });
}

虚构的应用要求 EXPORT-4 为：

输入：具有 order_id 和 customer_name 字符串字段的记录。
输出：字符串，列为 order_id,customer_name，且顺序不变。
每条记录都以 CRLF 结束，表头也一样。
字段内含逗号时，整个字段用双引号包围。
字段内的一个双引号，用两个双引号表示。
空输入返回表头及其后的 CRLF。
缺少必需字段的记录，不在本次升级的输入契约范围内。

“升级这个库”这句话并没有携带这些要求。应明确提供，尤其是新版本默认行为不同时。

给定下面的虚构输入：

[
  {"order_id": "o-1", "customer_name": "Moss, Lee"},
  {"order_id": "o-2", "customer_name": "Jo \"JJ\""}
]

所需输出字符串如下，行尾使用转义形式展示：

order_id,customer_name\r\n
o-1,"Moss, Lee"\r\n
o-2,"Jo ""JJ"""\r\n

展示的每一行代表一条记录；\r\n 表示其末尾要求的两个字符。这是手工构造的预期内容，不是从软件包运行中捕获的输出。

示意性的适配代码是：

import { renderRows } from "fictive-csv-writer";

export function exportOrders(rows) {
  return renderRows(rows, {
    columns: ["order_id", "customer_name"],
    recordSeparator: "\r\n",
  }).text;
}

片段遵循虚构接口，只是待验证候选，不是安装或迁移成功的证据。真实升级中，应先读目标版本的实际文档，再选择选项名或适配返回类型。

填写影响矩阵

空输入一行有意保留为待解决。一小段迁移代码看起来正确，也可能仍有应用要求未检查。矩阵让代理知道下一步应回答哪个问题。

复制这份升级任务说明

将 order-export 应用的直接依赖 fictive-csv-writer
从 1.4.0 升到 2.0.0，同时保留下面的 EXPORT-4。
包名和所给说明均属于本次练习。

修改前：
- 查看实际清单、锁文件、当前封装和调用方。
- 确认当前与拟升级后的直接/间接依赖图。
- 阅读所给 v2 说明，指出运行时支持证据缺失。
- 搜索其它导入点或使用方；不要因为请求只展示了一个封装，
  就假设它是唯一调用方。

允许修改：
依赖清单中的 writer 条目、锁文件中相关的解析条目、
src/export-orders.js，以及聚焦于此的测试。
使用仓库已有的依赖管理器和更新流程。

保留 EXPORT-4：
返回字符串。列为 order_id,customer_name，且保持这一顺序。
每条记录后都有 CRLF，包括表头。保留逗号/引号转义规则。
空输入返回表头加 CRLF。范围内的输入包含两个必需字符串字段。

检查：
普通记录、含逗号的值、嵌入引号、空列表、返回类型、精确行尾，
以及仓库相关检查。
比较预期字节/字符，不只看文件预览是否相似。

不要升级无关包、改变公开封装签名、更换测试框架、
重新生成无关文件，或扩大输入契约。
目标版本若无法在此范围内满足 EXPORT-4，止于原因说明和替代方案，不继续实施。

返回：
升级前后依赖图；变化的调用方；迁移 diff；实际运行的命令和结果；
未运行的检查及原因；未解决的兼容性问题；以及标明精确升级改动的回退说明。

复用任务说明时，替换虚构包名、路径、要求和版本。如果真实任务涉及安全公告，应附上该公告当前的官方来源及实际受影响范围；这个例子不提供安全结论。

接受前，先确定暂停与回退条件

拟升级版本的运行时要求仍未解决、依赖管理器无解释地改了无关包，或者目标版本无法保留必需输出时，应暂停这次升级并继续调查。这些情况不自动构成修改应用契约的理由。

如果实现后的升级违反要求，改变了返回类型、分隔符、转义或空输入行为，应先修正再接受。撤销升级时，从已知的升级前版本，一起恢复这次特定的清单、锁文件、封装和测试改动。保留无关工作；遇到重叠改动，解决重叠，不要重置整个共享检出目录。改动如果已经发布，还要使用项目的发布回退流程；恢复本地文件不能撤回线上部署。

依赖解析、聚焦的兼容性检查和发布验证，应各有自己的结果。“锁文件已更新”只回答了任务的一部分。

通过 CueSpec 发送这份任务说明时，可使用确认目标会话处理路由步骤。依赖图、目标版本说明和应用契约，应留在对应编程任务中。