偶尔深入：改价、账单修正，以及「作废并重建」对财务到底意味着什么。
2026-04-14
日常里两件事——提高行价、修正账单地址——总变成绕路方案；我们围绕「先预览再提交」搭了一条主路径。
商家反复提到同一种场景：订单「差不多对了」、财务要干净留痕，而后台原生的编辑流并不是把「售后向上改价」或「账单地址纠偏」当作一等任务来设计的。 Reprice Order Price Editor 希望团队留在同一套嵌入流程里：找到订单、改行与地址、读 diff、在需要作废并重建等路径上确认风险，再提交。目标不是「多几个按钮」，而是减少手工重建与同步时的意外。 我们描述 Shopify 本身时保持克制：平台仍是 Shopify；我们只是在结账后补齐一类明确的工作。
2026-04-15
一批内部契约被标为稳定：订单列表、预览、提交、运行历史、引导、设置、账单与合规钩子。
在 2026-04-07，我们将 docs/MODULE-CONTRACTS.md 中大量模块契约与已在跑的代码对齐：例如订单列表、预览与行项目路由、提交信封、异步任务轮询、改价运行历史与详情、引导就绪、结构化 shopRepriceSettings v2、Shopify 计费目录 v1，以及 GDPR 相关流程（如 redaction、保留）。 这不是营销话术，而是把这些界面从「随时会变」收束为 UI、路由与模型之间的 API 契约。对商家而言，Activity 里更少含糊状态，设置变更时提交行为也更可预期。
2026-04-16
每条提交路径都围绕在 Shopify 看到最终意图之前，先把增量展示清楚。
订单纠偏是高风险操作；总额错了会牵连退款、税务与客服工单。因此主路径被设计成 编辑 → 预览 → 提交：运营应在同一处看到行、总额与地址的增量，再执行不可逆步骤。 当存在软风险（如作废并重建或受账单地址驱动的路径）时，界面有意放慢节奏；我们宁愿少一秒「手速」，也不愿花一小时撤销静默错误。
2026-04-17
Activity 把提交与 trace ID、结果和错误串起来，方便支持或财务回答「#… 订单怎么了？」。
orderRepriceRun 等记录（在 Activity 中呈现）携带与后端日志一致的标识与状态。线上出问题最快的路径是：复制 trace ID、开支持工单并附上脱敏截图。 我们这样设计，是因为「失败了」本身不可操作——可关联才可处理。
2026-04-18
作废命名、向上改价方式与就绪检查，是为了同一按钮在不同店铺里语义一致。
引导会检查命名配置、向上改价策略，以及是否有安全的示例订单可练手。设置按店持久化为结构化配置，而不是「上周二 localStorage 里剩什么算什么」。 区别在于：商家策略才是真相来源；浏览器只该保存列宽等偏好，不能冒充策略。
2026-04-19
Shopify Partner 需要稳定的 HTTPS 隐私与文档 URL；嵌入应用与公开营销域不是同一类表面。
嵌入后台是会话绑定的；隐私、FAQ、更新日志、教程等公开页需要任何人无需店铺登录即可打开。用独立 Vercel 站点承载，可避免 Partner 必填项（隐私 URL、开发者网站、FAQ 等）与 Gadget 开发同步、构建根目录互相拉扯。 若你是商家：Admin 内体验不变；从应用商店查找我们时，外链会更清晰。
2026-04-20
内部云测与清单让「在我笔记本上能跑」不足以成为对外的生产叙事。
本仓包含围绕云测与发版纪律的自动化与 Playbook（如 cloud-gate、PRE-LAUNCH-CHECKLIST、内部 cloudTestRun 模型）。商户很少直接看到它们，但它们影响「我们多久会把你搞挂」的频率。 当我们在 MODULE-CONTRACTS.md 称某路径稳定，指的是契约级约束，而非感觉；这与先预览再提交的哲学一致：证据优于乐观。
2026-04-21
把运费与购物车级折扣放在行编辑旁，减少运营在本应用与零散后台界面之间来回跳。
改价叙事里行项目最抢眼，但很多工单最后仍落在「运费不对」或「整单折扣不对」。这些字段放在合计区是有原因的：它们直接改变客户与财务看到的数字。 在 Shopify 允许原地编辑的订单上，嵌入编辑器把它们当作一等输入——店铺币种固定金额或相对当前行项目小计的百分比——同时对需要作废并生成替代订单的路径保持坦诚。预览有意放慢节奏：若下调折扣或某些优惠组合无法作为「快速编辑」表达，差异会在提交前说明。 Activity 本就承载支持关联一次运行所需的上下文；把运费与折扣结果纳入同一证据链，能让运营与财务继续用同一套留痕回答问题。