Winston Builds

Evolution Log

记录改变判断的变化，不记录流水账。

这里不是 release notes。只保留那些会改变“为什么 Winston Builds 现在是这样”的节点：重要 Build、产品与设计决策、架构变化，以及经过真实验证后被推翻或修正的判断。

BUILDVALIDATELEARNCORRECT
202615 个关键节点
Architecture Decision

三个 Product 完成「正经上线」冲刺：three.js 异步化、AI 挂起兜底与交互语义补齐

评审团（A 产品 / B 交互 / C 工程）收敛后落地：Factory Twin 的 3D 模拟器拆为异步 chunk（three.js 不再阻塞 Product 页首载）、客户端 AI 请求补超时兜底（弱网挂起走确定性回退）、agent-team 首屏补主动作、AI 浮层可关闭、移动端 3D 手势与 aria 语义修复；新增 Product 详情页浏览器验收门禁 test:products-browser。

WHY
三个 Product 的交互主路径已经可用，但作为可对外上线的作品仍有可观测缺口：favicon 404、非首屏 3D 资源阻塞首载、弱网下 AI 请求无超时可无限挂起、移动端 3D 画布锁死页面滚动、动作后果留在视口外。
RESULT
test:products-browser 全绿（4 页 × 桌面/移动、三条主路径交互、内链健康、无运行时错误）；three.js 移出首屏 chunk；懒加载后的 twin 完整交互链（注入 → 选方案 → 批准 → 订单工作区）经真浏览器回归。决策与未做清单见 docs/PRODUCT_LAUNCH_SPRINT_REVIEW_2026-10-22.md。
LEARNED
Next 16 会把非 localhost Host 的 dev 资源当跨域封锁，导致全站静默不水合而静态文本测试照绿——交互验收必须断言真实点击生效。上线标准不是更多功能，而是把「挂起、遮挡、锁滚、断链」这类可观测的洞逐个关掉。
查看 Product →决策记录 ↗
Product Decision

Portfolio 从 Supply Chain-only 扩展为 Industrial AI Systems

保留 Supply Chain / Manufacturing 作为当前最强证据主干，同时引入 industry baseline、AI augmentation / AI-native、工业系统术语和 Decision Rights 作为新的 portfolio framing。

WHY
现有 Build 功能与真实工业问题已经较接近，但自定义命名、供应链单一坐标和通用 Human Approval 让招聘者与行业读者需要自行翻译；同时无法准确容纳 PLM / CPQ / Engineering front-end 等新的真实工业问题。
RESULT
PRODUCT_DIRECTION、INFORMATION_ARCHITECTURE、PAGE_CONTRACTS 与 BUILD_OVERVIEW_MAP 已更新；Supply Chain × AI Map 降为 operations lens，后续重构将先修改内容模型和行业语义，再决定页面视觉改动。
LEARNED
作品集的价值不只来自功能覆盖。先说明行业已经解决了什么，再说明剩余 gap、AI delta 与责任边界，才能证明真正的工业理解和系统判断。
Product Direction ↗Information Architecture ↗
Product Decision

Exception Command Center 演进为 Supply Chain Control Tower

把单一 Supplier Delay 闭环提升到 shared network state、双重 Root Event、Impact Provenance、P1–P4 Priority 和跨域 Recovery Scenario，同时保留原 14 个异常恢复 fixture 作为回归层。

WHY
单异常闭环已经证明局部恢复逻辑；下一步需要验证的是多个扰动同时发生时，系统能否解释影响传播、决定先处理什么，并避免把局部风险静默转移到其他节点。
RESULT
新增 11 节点供应链网络、Supplier Delay + Machine Breakdown guided flow、3 个 What-if Recovery、Human Gate 和 8 个 Control Tower fixture；没有引入新数据库、Event Bus 或 Agent Framework。
LEARNED
Control Tower 的价值来自共享状态、可验证传播和决策边界，不来自地图或更多 KPI；已有 Engine 应作为能力被组合和回归，而不是复制重写。
查看 Product →PR #45 ↗
Major Build

数字孪生从 3D 展示升级为状态驱动 Product

建立 Factory Digital Twin Command Center，把 5 条产线、20 个工位、异常传播、What-if 恢复、AI 解释和人工授权连接到同一 Twin State。

WHY
单纯用 3D 模型复刻工厂只能证明视觉实现；真正需要验证的是空间对象、业务状态、仿真、约束和恢复决策能否共享一套可重复模型。
RESULT
Three.js 只负责空间视图，TypeScript Twin Engine 负责设备状态、WIP、KPI、传播和 Hard Constraint；3 类异常与 9 个 fixture 提供可重复证据。
LEARNED
Digital Twin 的成熟度不取决于模型面数。先把状态模型、异常因果、What-if 与责任边界做正确，再决定是否需要更高保真资产。
查看 Product →PR #44 ↗
Product Decision

页面目标从实现细节中独立出来

新增 Page Contracts，为核心页面定义稳定的 visitor outcome，而不是冻结当前布局。

WHY
连续 UI 调整已经证明：如果只有实现规范，没有页面级目标，局部优化很容易破坏第一次访问者真正需要完成的任务。
RESULT
首页、Build、Product、Capabilities 与 About 都有了明确的页面职责、首屏任务、主操作和不可破坏条件。
LEARNED
布局可以持续变化，但页面存在的理由必须稳定；Source of Truth 应保存目的，而不是把当前 UI 固化成永久规则。
Page Contracts ↗
Design Decision

Exception Command Center 改成 Visual-first

把 prose-heavy 产品说明压缩成 Input → AI → CODE → HUMAN、影响传播、方案比较和 Human Decision 等视觉流程。

WHY
真实浏览器检查发现，系统逻辑虽然完整，但关键判断被大量说明文字淹没，第一次访问者的阅读成本过高。
RESULT
详细 rationale 移入渐进披露，核心责任边界、KPI、恢复方案和授权结果留在主阅读路径。
LEARNED
完整信息不等于一次展示全部信息；Evidence 应该 progressive disclosure，主路径只保留理解当前决策所需的内容。
查看 Product →PR #40 ↗
Learning / Correction

Product 从 Happy Path 扩展到 Failure Handling

Exception Command Center 增加 6 个业务场景和 8 个失败场景，并补上强制 Human Escalation。

WHY
单一成功路径只能证明 Demo 能跑，不能证明系统知道什么时候不该相信 AI、什么时候没有可行方案、什么时候必须升级给人。
RESULT
AI master data 校验、fallback、缺失数据、约束违规、无可行恢复方案等失败边界都变成可重复验证的 fixtures。
LEARNED
成熟度来自边界验证而不是功能数量；Negative path 和 escalation evidence 是 Mature Product 的核心证据。
查看 Product →PR #38 ↗
Major Build

建立第一个跨模块 Supply Chain Exception Product

Supplier event → Inventory impact → Order / Scheduling impact → Recovery Plans → Human approval 被整合成一条完整工作流。

WHY
单独的 Idea Builds 可以证明局部能力，但还需要一个 Product 来证明业务逻辑、AI 边界和已有模块能否形成完整系统。
RESULT
复用现有 Inventory 与 Scheduling 模型；AI 只做结构化事件提取，核心计算保持 deterministic，最终恢复授权由人负责。
LEARNED
Product 不应该通过复制已有逻辑变大；成熟系统更重要的是把已有能力组合成清晰、可验证的责任边界。
查看 Product →PR #37 ↗
Learning / Correction

真实浏览器验收推翻“必须塞进一屏”

Build Detail 的 CTA 一度只有约 9px，辅助文字出现 8–11px；随后建立最低可读性约束并放松固定高度。

WHY
为了追求单屏体验，页面把内容压得过小；结构更紧凑了，但实际阅读反而更差。
RESULT
按钮、正文和辅助标签建立可读性底线；“下一步”状态改成明确文字提示，避免双高亮歧义。
LEARNED
Single viewport 是手段，不是目标。只要可读性被牺牲，就应该允许页面自然增长，而不是继续压缩。
PR #35 ↗
Design Decision

Guided Story + AI System Proof 成为共享模式

把试点中的 state-driven tabs 提升为站点级模式，并将业务故事与 AI 系统证明拆成两个层次。

WHY
不同 Build 需要自己的业务因果顺序，但招聘者也需要一致地看懂 AI 在哪里、CODE 做什么、人保留什么权力。
RESULT
共享 BuildStoryTabs 与 AI System Proof 被逐步推广到现有 Build，而不是强行使用一套固定四 Tab 模板。
LEARNED
可复用的是交互与证明结构，不是业务流程本身；共享模式应该约束理解方式，而不是抹平 domain 差异。
PR #25 ↗PR #30 ↗
Product Decision

Builds 首页从卡片库存变成能力地图

/builds 先展示 Supply Chain × AI Competence 的整体分布，再进入完整 Gallery。

WHY
Build 数量增长后，直接展示大量卡片只能告诉访问者“很多”，却不能快速解释这些实验覆盖供应链哪些阶段和 AI 角色。
RESULT
访问者先看到 portfolio 的形状、覆盖与 AI participation，再按需进入单个 Build。
LEARNED
集合页首先应该解释结构，而不是展示库存；Technology 更适合作为维度和 metadata，而不是内容组织主轴。
查看 Builds →PR #32 ↗
Architecture Decision

开发流程改成 CI 验证、任务完成后统一部署

停止 feature branch 的自动 Vercel Preview 风暴，把 GitHub CI 作为开发中的默认质量门槛。

WHY
频繁小改动不断触发 Preview，消耗有限部署额度，也让“代码检查”和“最终交付验证”混在一起。
RESULT
非 main Git build 被跳过；相关改动先在 branch 累积并通过 CI，任务形成完整批次后才进入一次正式部署。
LEARNED
验证强度应该跟变化规模匹配；部署是 delivery step，不应该成为每次编辑的副作用。
PR #21 ↗
Major Build

Supply Chain Agent Team 成为第一个正式 Product

多角色 Agent 分析、有限协商、Action Catalog、deterministic guardrails 与 Human Review 被组合成完整案例。

WHY
需要验证的不是“多个 Agent 能聊天”，而是多个 AI 角色在有限上下文、成本和错误边界下能否形成受控协作。
RESULT
Agent 可以讨论和提出动作，但 KPI、硬约束、可执行动作以及高影响决策仍由确定性代码和人控制。
LEARNED
Agent autonomy 必须被任务边界、轮数、并发、Action Catalog 和人工升级机制约束；Agent 不天然拥有执行权。
查看 Product →PR #10 ↗
Product Decision

网站从文章式 Portfolio 转向 Demo-first Proof of Work

确立 SEE → TRY → OBSERVE → UNDERSTAND → VERIFY，并把“Experience first. Evidence behind.”写进页面架构。

WHY
原有页面更像博客或案例文章，访问者需要先读大量解释才能发现真正可运行的系统和判断证据。
RESULT
Build Gallery、stage-first detail、distinct Product archetype 和 progressive disclosure 成为新的站点结构。
LEARNED
对技术 Portfolio 来说，解释不能先于证据；应该先让访问者看到系统行为，再允许继续深入架构、限制与实现。
PR #4 ↗
Architecture Decision

建立可跨项目复用的 UI Capability Library

新增 @winston-builds/ui 与 /design-system，把通用体验框架和解释型可视化从具体 Build 中抽离。

WHY
Build 数量和仓库会持续增长，如果每个项目都重新实现相同的体验模式，视觉一致性和验证成本都会迅速恶化。
RESULT
共享 tokens、Experience primitives、BoundaryFlow 和 visualization patterns 可以版本化复用，同时 backend、AI runtime 和 domain algorithms 仍留在应用内。
LEARNED
应复用稳定的 capability pattern，而不是抽象整个应用；共享组件不应该接管业务路由、状态或 domain authority。
UI 模块库 →PR #3 ↗