82个测试全绿，官方路线图却显示未解决——这不是某个外包项目的甩锅现场，是Cx语言开发团队的日常。11天前完成的5个关键提交，至今躺在submain分支里，和main分支之间隔着一道越来越宽的沟。
五个提交，四个硬骨头
这五个提交的内容本身足够扎实：算术溢出强制检查、Phase 10的while循环降级、UTF-8实现拍板、可选分号规则定稿，外加一个基础测试运行器。它们解决了四个阻塞性问题，把测试能力补全、字符编码落地、整数安全检查到位，还顺手简化了语法规则。
问题不在于代码，在于代码的"可见性"。所有82个相关测试在submain分支上全部通过，没有合并冲突的迹象。但main分支对此一无所知，docs/frontend/ROADMAP.md上的官方路线图依然把这些标成"待解决"——相当于你加班做完了PPT，投影仪坏了，老板以为你在摸鱼。
这种"进度黑洞"在开源项目里不算罕见，但11天的窗口期已经长到足够让外部观察者误判项目状态。贡献者看路线图以为这些功能还没开工，潜在用户以为项目停滞，而团队内部清楚知道：活儿干完了，只是没"上牌"。
六条日志分支在排队腐烂
比submain积压更隐蔽的，是六条日期从2026-03-29到2026-04-05的daily-log分支。它们记录着每日微调，有些甚至可能改变开发方向。但和submain一样，它们没有PR（Pull Request，代码合并请求），没有评审，没有合并——只有时间在流逝。
2026-03-29那条分支甚至在4月5日还同步过最新代码，却依然没进入合并流程。这就像一个不断更新的草稿，永远发不出去。分支放越久，合并冲突概率越高，这是Git的基本数学：两条线分开越久，交点越难找。
团队日志里反复出现的优先级清单，此刻读起来像某种黑色幽默：
· 立即合并submain到main——"最大的阻塞点"，每天不合并，开发态和文档态的裂缝就加深一层
· 清理daily-log分支积压——六条队列，需要的不只是执行，还有整合时机判断
· 定义Error模型（Result）——测试运行器之后的下一个硬骨头，方案写过，执行卡住
· 推进:=类型推断——从计划里消失，被前面的 urgencies 挤成"等有空再说"
语言开发的沉默期
日志末尾那句"What's absent is the language work, a yawning silence now"（缺失的是语言本身的工作，如今只剩一片沉默）透露了更深层的状态。当基础设施、测试工具、合并流程吃掉全部带宽，语言设计和实现自然让位。
这不是Cx独有的困境。任何技术项目都会经历这种"修管道期"——用户看不见你在干活，但管道不修，后面的水（新功能）流不过来。区别在于，有些团队会让"修管道"本身可见，而Cx的文档系统显然没跟上这个节奏。
submain到main的合并，技术上可能只是一行git merge。但在这行命令背后，是代码所有权、评审责任、发布节奏的一整套决策。11天没按下去，说明要么有人在等"更完美的时机"，要么流程本身有卡点。
对于关注Cx的开发者来说，现在的状态是：你知道他们有货，但货架上标签没换。这种信息不对称，比单纯的开发延迟更消耗信任。
下一个合并窗口会在什么时候打开？以及，当那82个测试终于被"官宣"时，路线图上的其他条目会不会已经又落后了一个版本？
热门跟贴