@adlc/merge-forecast

中文文档
1.12.0发布于 2026/10/10MITES Module构建来源已验证近 30 天下载 8136

Conflict forecast and dispatch schedule for parallel ticket execution (D2).

原始使用文档
文档目录8 节
  1. Usage
  2. Exit Codes
  3. Signals
  4. Width Analysis
  5. Schedule
  6. Examples
  7. Relation to Sibling Tools
  8. Core Gaps

@adlc/merge-forecast

ADLC phase: D2 — The time dial / fan-out mechanics

Conflict forecast + dispatch schedule for parallel ticket execution. Predicts merge conflicts before any agent runs, certifies the safe fan-out width, and emits a foundation-first merge schedule.

Usage

merge-forecast [options]

Options:
  --tickets <path>           Path to tickets JSON (default: .adlc/tickets.json)
  --width <N>                Desired fan-out width; gate fails (exit 2) if > firstWaveWidth
  --build-min <X>            Mean ticket build time in minutes (for backpressure width)
  --merge-min <Y>            Mean merge-rebase-regreen time in minutes
  --co-change-limit <N>      Git log depth for co-change mining (default: 500)
  --conflict-threshold <F>   Score >= this triggers SEQUENCE verdict (default: 0.5)
  --graph-coupling <path>    Path to semantic call/symbol graph coupling JSON
  --json                     Machine-readable JSON output
  --help                     Show this help

The forecast walks the tree and mines co-change from the git repository root, so it gives the same result from any subdirectory; --tickets and --graph-coupling paths resolve from the working directory. Outside a git repository the working directory is the root and co-change is skipped with a warning.

Exit Codes

CodeMeaning
0Gate passes — schedule is safe at the recommended width
1Operational error — bad tickets file, unresolvable input
2Gate fails — --width exceeds firstWaveWidth, or vetoed/high-risk pair scheduled concurrently

Signals

Each parallel-eligible ticket pair (neither is an ancestor of the other in the DAG) is scored by five signals. Combined score = max of individual signals.

ScoreSignalDescription
1.0scope-overlapHARD VETO — tickets' declared scope globs overlap. These must serialize.
0.8namespace-collisionDynamic route segments conflict ([pk] vs [voteKey] at same path depth) or migration prefix collision (drizzle/0005_* vs migrations/0005_*).
0.7graph-couplingSemantic call/symbol graph coupling (e.g. Spanner Graph, mcp__spannercg, or exported graph coupling).
0.6import-radiusFiles matching ticket A's scope import from ticket B's scope or vice versa.
0–0.5co-changeHistorical co-commit coupling: pairCount / min(fileCountA, fileCountB) × 0.5.

Pairs at or above --conflict-threshold get a SEQUENCE verdict. Below threshold: PARALLEL.

The --co-change-limit option must be an integer >= 1. When git history yields zero commits or empty co-change pairs, merge-forecast outputs a descriptive warning in warnings.

Tickets with no scope or an empty scope emit a warning (ticket "<id>" has no scope defined), and tickets whose declared scope matches zero files in the repository emit a warning (ticket "<id>" scope matches 0 files in repo). Any pair involving an unscoped or zero-match ticket is treated as SEQUENCE (score 1.0, signal unscoped) and excluded from parallel wave width calculations.

Width Analysis

  • firstWaveWidth — greedy largest independent set among wave-1 tickets (tickets where all pairs are below threshold). Answers how wide can I dispatch right now. This is the number --width is gated against.
  • scheduleWidth — the same computation applied to every wave, taking the widest. Answers how wide can this schedule ever go. For a foundation-first DAG, wave 1 holds a single ticket, so firstWaveWidth is 1 while scheduleWidth reports the fan-out behind it.
  • certifiedWidth — deprecated alias of firstWaveWidth, retained for existing consumers. It tracks wave 1, not scheduleWidth.
  • backpressureWidth — round(buildMin / mergeMin) when both flags are given. Derived from integrator-lane throughput: if builds complete faster than merges absorb them, queue depth compounds.
  • recommendedWidth — min(firstWaveWidth, backpressureWidth?, --width?).

Schedule

The schedule is derived from the ticket DAG via Kahn topological waves. All tickets in the same wave are ready to build concurrently (their dependencies completed in earlier waves). The merge order is foundation-first (ticket dependencies merge before their dependants; within a tier, first-done-first-merged).

Examples

# Basic forecast (auto-detect .adlc/tickets.json)
merge-forecast

# Gate against fan-out width
merge-forecast --width 4

# With backpressure — 20-min builds, 4-min merges
merge-forecast --width 5 --build-min 20 --merge-min 4

# JSON output for orchestrators
merge-forecast --json

# Custom tickets path + looser threshold
merge-forecast --tickets plan/tickets.json --conflict-threshold 0.7

# Deep co-change history
merge-forecast --co-change-limit 1000

Relation to Sibling Tools

  • Upstream: Tickets are produced by model-router (P2 phase). This tool validates the partition quality before agents run.
  • Downstream: rails-guard enforces the contract rails that merge-forecast identifies as conflict surfaces.
  • Complement: After completing parallel branches, merge-forecast can be re-run against the updated main to confirm rebase safety.

Core Gaps

@adlc/core provides activeTickets to filter completed tickets (drop completed tickets and strip edges pointing to them, keeping the remaining DAG valid) so backlog enumerators do not schedule finished work.

版本与发布记录

@adlc/merge-forecast 共发布 18 个版本,首次发布于 2026/06/14;过去 12 个月发布了 18 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
1.12.0latest2026/10/1027 天前
1.11.12026/09/091 个月前
1.11.02026/08/252 个月前
1.10.02026/08/112 个月前
1.9.02026/08/092 个月前
1.8.02026/08/082 个月前

关于 @adlc/merge-forecast 的常见问题

@adlc/merge-forecast 是什么?

Conflict forecast and dispatch schedule for parallel ticket execution (D2).

如何安装 @adlc/merge-forecast?

在项目目录运行 npm install @adlc/merge-forecast,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 merge-forecast,可以用 npx merge-forecast 直接运行。

@adlc/merge-forecast 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/adlc__merge-forecast 是否存在。

@adlc/merge-forecast 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@adlc/merge-forecast 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=18。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@adlc/merge-forecast 可以商用吗?

@adlc/merge-forecast 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@adlc/merge-forecast 的下载量有多少?

根据 npm 官方下载统计,@adlc/merge-forecast 在 2026/10/05 – 2026/11/03 这 30 天内被下载 8,136 次,日均约 271 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@adlc/merge-forecast 还在维护吗?

最新版本 1.12.0 发布于 2026/10/10(27 天前);至今共发布 18 个版本,其中过去 12 个月发布了 18 个;首次发布于 2026/06/14。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。