让一个经营想法，
成为可持续运转的电商生意。

01 / POSITIONING产品定位与必须先确定的边界

Aster 面向希望经营独立品牌网店的商户，以及为多个品牌提供建站和运营服务的团队。核心产品是可由 Agent 协助操作的电商经营系统：商户描述目标、确认商品和经营政策，系统生成可编辑店铺；开业之后，商品、订单、支付、售后、客服和内容沿用同一套可信业务数据。

推荐的首发决策

下文中“推荐、拟定、必须验收”是本项目的设计决策或交付要求，不是已经具备的产品能力。外部软件能力和法规事实在相应段落列有官方来源。

02 / DOMAIN & ACCESS多租户、店铺、市场与权限

隔离应覆盖数据经过的每一层

OWASP 的多租户安全指南将数据访问、缓存、会话及租户生命周期一起处理，并要求受保护缓存读取之前仍执行授权；仅把租户ID放进缓存键并不足够。[S4]

• 数据库：所有商户业务表包含 tenant_id；店铺私有表同时包含 store_id。复合唯一约束和复合外键携带租户范围，禁止跨租户关联。仓储接口强制接收服务器生成的 TenantContext；普通模块无法获得无范围客户端。
• MySQL路径：本方案不假设 MySQL 自动提供 PostgreSQL 式行级安全。共享数据库依靠受约束数据层、角色权限、复合约束和跨租户回归测试；高隔离合同可采用独立数据库/实例，单独核算费用。
• 缓存与CDN：页面缓存键包括可信店铺域、市场、locale、货币和发布版本。顾客账户、购物车、结账和管理API禁用公共缓存，保护内容鉴权后才能读取。
• 存储与检索：对象键、签名下载、搜索索引和向量检索均带租户/店铺空间及可见性过滤；检索前检查权限，结果交给模型之前再次校验归属。没有跨商户共用客服记忆。
• 异步与集成：队列消息记录租户、发起人、权限版本和来源事件；消费者重新建立可信上下文。Webhook不能根据可伪造metadata任意切换商户，必须通过已验证的外部账户映射。
• 平台运维：平台客服默认只看脱敏诊断信息。临时支持访问须有目的、授权、有效期和操作记录，不提供无审计的“扮演任何商户”。

基础角色矩阵

03 / MODULE CATALOG完整功能模块

P0 表示商业首发必须具备的基础闭环，不代表所有深度功能同时完成。功能在同一领域内分期：例如首发单仓、基础折扣与一个已验证支付适配器，架构保留扩展位。P2 属于另行立项的商业扩展。

机器可读文件：module-catalog.json。它同时包含稳定模块ID、中英文名称、目的、范围、优先级及拟定套餐常量，供后续官网和应用复用。

04 / STORE JOURNEY从想法到可交易店铺

发布门槛应是可见的工作清单

商户看到“还需要完成什么、为何需要、由谁完成”。清单包含真实卖家信息、有效收款连接、商品状态、库存、至少一种可用配送方式、税费设置、条款/隐私/退货政策、联系与人工支持通道，以及移动结账检查。正式发布不以一次成功的AI生成代替这些验证。

05 / AGENT SYSTEMAgent编排、审批、幂等与预算

Agent 负责理解、计划、生成和建议；授权、金额、库存、状态变化和外部调用由服务端工具网关裁决。OWASP Agent 指南要求高影响操作的授权发生在执行组件中，审批应绑定具体动作、目标和参数并抵抗重放，而不能只相信模型返回的“用户已确认”。[S3]

任务执行模型

created → planned → validated → awaiting_approval → queued → running → succeeded。分支状态包括 failed、cancel_requested、cancelled、compensating、compensated、needs_attention。模型调用与工具调用作为不同的步骤记录；每步可独立重试或恢复，不把整段会话当成不可追踪黑箱。

1. 计划：把意图转成有限工具列表、受影响资源、估算credits、步骤依赖和预计副作用。任务创建时保留发起人、角色、租户、店铺及权限版本。
2. 验证：Zod/JSON Schema校验输出；查询当前资源版本；策略服务检查工具是否允许、资源是否属于租户、敏感数据是否必要、预算是否足够。
3. 审阅：对外可见发布、价格生效、批量删除、发送营销消息和资金动作展示具体差异。商户看到“修改了什么、影响哪些店铺、金额/数量、如何恢复”。
4. 批准：审批记录含 actor、tool、resource IDs、规范化参数hash、版本、到期时间和一次性nonce；执行前原子检查并消费。参数、目标或资源版本变化须重新批准。
5. 执行：队列负责持久化步骤；工具网关携带稳定的业务幂等键，并重新鉴权。以服务端执行结果和第三方回执确定成功，模型口头回答不能改变订单状态。
6. 恢复：断线后从已持久化检查点继续。用户取消阻止后续步骤；已开始的外部操作先查询结果，不能把“取消请求”错误展示成“资金已退回”。

回滚有明确的业务边界

页面和文案可恢复到历史版本；草稿数据可根据变更集撤回。已发送邮件、已被消费者看到的促销、已捕获支付和已提交物流无法通过数据库回滚撤销；相应流程只能以补发、更正、退款或召回等补偿动作处理，且各自重新取得必要批准。退款本身不提供“自动撤销退款”能力。

提示注入与代码隔离

• 商品描述、PDF、网页、客服邮件和外部API文本都是不可信内容；不能改变系统指令、权限或工具配置。检索出的文本必须附来源与内容类型，禁止把其中的指令拼接为工具调用。
• 密钥只存在于服务端secret store。模型看到连接ID和能力说明，不能看到PSP私钥、完整认证token或内部数据库连接串。输出和日志均经敏感信息过滤。
• URL抓取经过受控代理：限制协议/端口、验证DNS解析结果、阻断内网/元数据地址和危险重定向，限制文件大小、内容类型与请求时长。
• 模板渲染不允许任意脚本。若后期开放生成代码，采用独立构建沙箱、短期凭据、出网白名单、资源上限和签名产物；生成代码不能触及交易后台密钥。
• 每任务限制模型调用次数、递归深度、总tokens、时间和金额；各Agent共享同一租户策略，不能通过把任务转交另一个Agent绕过授权。

06 / COMMERCE CORE商品、库存与金额计算

商品模型

Product 表示商品概念，Variant / SKU 表示可销售规格；属性采用受控定义，区分展示属性与变体选项。商品含多语言标题、描述、slug、SEO字段、类目、集合、媒体、运输重量/尺寸、税类、合规字段和发布状态。商品归档后保留订单快照及售后所需引用，不删除历史交易中的名称、规格和成交价。

导入采用“上传 → 预校验 → 映射 → 草稿 → 确认导入”，返回逐行错误与批次ID。可重放的稳定外部ID用于幂等导入；SKU重复、非法币种、负价格、不一致规格或危险文件阻止对应行，而不静默覆盖已有商品。图片保存来源和授权说明，Agent生成图不能替代实物真实性确认。

库存模型与并发

available = on_hand − reserved − allocated − safety_stock

InventoryReservation:
tenant_id, store_id, sku_id, location_id, checkout_id,
quantity, expires_at, state, version

状态：held → committed / released / expired
库存调整：每次写 StockMovement，包含来源、数量变化、理由与操作者。

on_hand 是实物在库，reserved 是结账临时预占，allocated 是已确认订单待发数量。原子条件更新或行锁同时检查可用量并创建预占；成功付款后把预占转为订单占用，发货时同时减少在库和已分配数量。预占过期任务以数据库状态和版本为准，多次执行只能释放一次。

支付结果晚于预占过期：先重新检查库存能否分配；不能分配则订单进入异常处理，停止履约、通知商户。若已扣款，由授权员工处理退款；不得创建负库存或把消费者付款标为失败。处于异步付款中的订单按具体支付方式设置预占策略与用户提示，不能统一套用短购物车超时。

服务端报价流水线

商品/规格校验 → 市场可售性 → 价目表 → 促销资格与叠加
→ 折扣分摊 → 配送资格和运费 → 税费 → 舍入与总额
→ Quote快照、版本、有效期 → 客户确认 → 订单快照

order_total = item_subtotal − item_discount
            + shipping_total − shipping_discount
            + tax_total + disclosed_adjustments

定价逻辑按实际税制配置含税/未税和税费计算顺序，上述公式表达总账构成；税费若已包含在商品/运费显示价中，tax_total作为明细拆出，不能再加一次。优惠规则存储版本、渠道、市场、时间窗、用量上限、叠加优先级和排斥组；并发优惠码核销需要原子用量控制。

每个订单行保存基础单价、折扣份额、税费、币种与舍入结果。订单级优惠采用确定性分摊算法，尾差固定分配并记录，使“各行之和 = 订单总额”。部分退款依据原订单行和已退款份额计算，绝不重新按今日价格或今日优惠计算。

税费、运费与单据

税服务输入卖家税务配置、买家配送/账单地址、商品税类、日期、优惠分摊和含税模式，输出逐行税基、税率/规则版本与证据。MVP支持已验证起始市场的规则或税务适配器；平台不声称替商户完成所有国家税务登记、申报或法定开票。商业收据、PSP收据、平台订阅发票和当地法定税票分别建模。

运费按配送区域、重量/件数/金额、运送方式及商品限制计算；报税、偏远附加费、关税和进口责任在结账前披露。无法计算税费或目的地不在配送范围时明确阻止对应市场下单，禁止用零税费或免费配送静默兜底。

07 / TRANSACTION STATES订单、支付、退款、拒付分开管理

一个订单可以有多次支付尝试、部分履约、多个退款和一个或多个支付争议。把所有情况塞进单个 order.status 会丢失事实。推荐订单商业状态、支付状态、履约状态、退款状态与争议状态分别保存，再给前端生成综合摘要。

上述状态是Aster内部统一模型，不能假设所有PSP均支持预授权、部分扣款或撤销。Stripe的PaymentIntent本身存在 requires_action、processing、requires_capture 等不同阶段，说明支付成功不能由前端跳转页面推断。[S7]

PSP适配器契约

PaymentProvider:
  getCapabilities(account, market, currency)
  createPayment(orderSnapshot, idempotencyKey)
  retrievePayment(providerPaymentId)
  capturePayment(amount, approval, idempotencyKey)
  voidAuthorization(idempotencyKey)
  createRefund(amount, approvedRefundId, idempotencyKey)
  retrieveRefund(providerRefundId)
  verifyAndNormalizeWebhook(rawBody, headers)
  fetchReconciliationRecords(period)

所有金额：{ amountMinor: string, currency: string, exponent: number }
所有结果：外部账户ID、外部对象ID、状态、证据、观察时间。

能力矩阵按“PSP × 商户账户 × 国家/地区 × 货币 × 支付方式”判断，不根据Logo声称全面支持。3DS/SCA或其他用户认证由适用支付服务要求触发并由适配器呈现；风险校验失败不能用未经授权的切换账户、重复扣款或绕过认证解决。

两条独立资金流

首发选择PSP托管页面或安全托管字段，让原始卡号及安全码直接提交给支付服务商。Stripe官方明确此类低风险集成可降低PCI负担，但PCI仍是支付服务商与经营者共同责任；官网不能由此宣称“使用托管支付即可自动全面合规”。[S9]

08 / RISK & AFTER-SALES风控、退款、退货与履约

风控在明确节点介入

每次决策保存 rule_version、输入摘要、结果、原因码、执行人和复核记录。临时风控不能修改已经成立订单的合同事实。高风险拦截规则与第三方风险适配器具备关停开关和审计；健康检查失败时暂停相应高风险操作，避免出现“所有用户都被拒绝”而无人察觉。

退款金额和并发约束

refundable = captured_amount
           − succeeded_refunds
           − reserved_pending_refunds

退款申请审批时、提交前都检查金额、币种、外部账户和争议状态。
通过数据库事务预占可退额度；同一幂等键只能形成一个退款对象。
支付争议的资金影响单列；存在活动争议时进入人工协调队列。

商户员工批准具体退款后，工具服务执行，记录PSP引用并等待最终事件或主动查询。成功退款不因Webhook乱序回到处理中；失败退款释放可退额度并通知人工处理，禁止未经批准改成其他收款目的地。以Stripe为例，退款总额不得超过原始扣款，且退款退回原支付方式；其他PSP按各自规则验证。[S8]

RMA与退货物流

ReturnRequest 记录原因、商品行与数量、图片证据、政策版本；RMA 记录授权、退货方式、地址、运费承担、物流和收货质检。退货获批、商品已收到、库存可重新入库、资金已退款是四个独立事实。退款可以按适用政策先退后收；不能把签收扫描直接当作退款完成。

履约包含发货批次、包裹、承运商、运单号和行项目数量；地址改动在创建面单之后进入专门变更流程。拆单/部分发货的模型保留到行级，首发UI可先提供单仓单包裹。物流Webhook和人工更正都保留原始记录及更正原因。

消费者在线撤回

对适用的欧盟在线远程合同，政策和产品流程应纳入新增的在线撤回功能：在撤回期间持续提供易发现入口，消费者填写或确认姓名、合同识别和回执渠道，独立确认提交，随后通过持久媒介发送含内容及提交时间的回执。相关修正措施自2026年6月19日起适用，仍需按目标成员国的转化法、具体合同与例外验证；不等同于所有商品均享有无条件退款。[S17]

本项目实现 WithdrawalNotice 与 Refund 分离：先可靠接收和记录撤回声明并发回执，再由商户按适用规则完成退货、退款等后续事项。提交声明不设置强制说明原因、不要求消费者先与Agent聊天，也不以退款审批尚未完成为由不接受声明。游客订单使用适度身份验证，不强制创建账户。

09 / CUSTOMER SUPPORTAgent自动客服与人工接管

客服Agent首发能力以“有依据回答、授权查询、可靠转交”为核心。知识库只使用该店铺已经发布的商品信息、配送与退货政策、FAQ及商户审核过的补充说明；保留文档版本与生效时间。生成回答需引用内部证据，消费者看到自然语言答复和必要的政策链接，不接触系统实现细节。

客服安全和体验约束

• 不能凭订单号和邮箱明文匹配就暴露完整地址；查询使用客户会话或短期验证链接，返回最少必要信息。
• 会话状态含 bot_active / awaiting_human / human_active / resolved，采用独立版本锁保证人工接管后Agent不继续发送冲突答复。
• 明确标识AI客服，可随时转人工；自动回复额度不足时切换人工工单，不关闭客户支持入口。
• 正常订单通知不消耗AI credits。营销消息单独管理同意、退订、频次和地区规则，不能把交易联系方式自动用于广告。
• 指标分开：自动解决率、人工接管率、事实错误、违规承诺、重复工单、响应时长。重复关闭工单不能当作解决率提高。

客户账户

顾客身份默认按店铺隔离，不把在一个品牌注册解释为同意所有品牌共享数据。地址、订单历史、通知偏好、隐私权请求和撤回入口统一呈现；商户可在法律允许和明确披露后配置跨店会员计划。访客下单与注册并列提供，账户创建不是购买或售后的隐性前提。

10 / GLOBAL COMMERCE多币种与国际化

区分三类货币

Stripe的货币文档明确API金额通常使用最小货币单位，存在零小数及其他特殊处理；因此不能全局写死“金额乘100”。各PSP适配器需要自己的币种精度与操作限制表。[S6]

Money = {
  amountMinor: "1099",  // 整数以字符串跨JSON边界传输
  currency: "USD",
  exponent: 2
}
FxQuote = {
  from: "USD", to: "EUR", rateDecimal: "example",
  source: "example", observedAt: "example", expiresAt: "example",
  roundingRule: "example", quoteId: "example"
}

交易金额在数据库用整数最小单位保存；超过安全整数范围时使用BIGINT和字符串API边界。比例、税率、汇率和中间计算用十进制定点数/Decimal，不使用JavaScript浮点数直接处理资金。货币指数、舍入规则和支付服务特殊限制均版本化，最终调用前再验证。

汇率锁定、舍入与退款

• 价目表允许“每市场固定本地价”与“基准价换算”两种模式；同一SKU/市场的生效策略唯一且可追溯。
• 结账Quote固定汇率来源、时间、期限和取整策略；到期后重新报价并由消费者确认。支付已开始后不在原订单偷偷重新换汇。
• 退款按原支付币种的已扣金额及分摊执行，不用今天汇率重算商品价格。发卡行或PSP的再次换汇可能让消费者账单本币金额不同，界面不保证相同本币数值。
• 结算报表区分支付毛额、PSP费用、结算汇率、净额和汇兑差额。跨币种分析必须标明原币和折算口径，不能直接相加USD与JPY。

语言、地区、时区是独立配置

locale 控制语言与格式，market 控制可售范围和政策，currency 控制金额，timeZone 控制当地时间。服务端记录UTC时间，营销/配送截止时间同时保存IANA时区和本地业务时间；夏令时重叠或缺失时刻采用明确规则。账单周期使用固定锚点，不按用户浏览器当天日期补充额度。

首发中文与英文覆盖官网、商户核心界面、店面、结账、通知及法律文件入口。文案以消息键管理，支持复数、插值、长度变化和语言回退；商品翻译有草稿/审核/发布状态。地址字段按国家配置而非强制所有国家都有州/邮编，电话与邮编先按字符串保存。

CSS采用逻辑方向属性，图标与数字方向分别处理，为RTL预留；首发不宣传已完成阿拉伯语本地化，直到翻译、布局和关键流程验收完成。日期、数字和货币采用本地化格式器，符号不足以识别币种时显示ISO代码。

11 / SEO & CONTENT让已发布的店铺可被正确理解

生产官网和商品页面为每种启用语言提供独立URL，并在首次HTML响应中输出标题、描述、正文、导航、canonical和语言关联。HTML预览的按钮切换用于体验演示；生产SEO依赖真正可抓取的语言页面与一致内容，而不是仅在同一路由更换文字。

性能与无障碍

页面采用明确图片尺寸、响应式图片、懒加载非首屏媒体、控制JS体积并尊重减少动画设置。键盘导航、焦点、表单错误、文本对比、语义标题、图像替代文本和支付状态播报纳入验收。以WCAG 2.2 AA作为设计目标，实际符合情况以范围明确的测试结果为准，不能把单一自动分数写成全面认证。[S15]

12 / POLICY SYSTEM把法律文件接入真实产品流程

法律文件应作为版本化产品数据管理，同时由适用法域的专业律师审核。平台对商户的软件合同，与商户对消费者的商品销售合同分别生成和展示。未确定法律主体、经营地、适用市场、商品类型、数据处理商和服务能力之前，不能声称“一套模板已覆盖全球所有法律要求”。

17份法律文件映射

法律包与同意记录

PolicyDocument:
document_id, scope(platform|store), jurisdiction, locale,
version, effective_at, content_hash, legal_review_status,
constants_version, reviewer_ref, published_at

PolicyBundle:
seller_entity_id, market_id, contract_type,
document_version_ids[], precedence_rules, resolved_constants_hash

ConsentReceipt:
subject_ref, tenant_id, store_id, context(registration|checkout|cookie|marketing),
policy_bundle_hash, exact_document_versions[], locale,
statement_text_hash, action, timestamp, collection_channel

合同接受、隐私告知、营销同意和Cookie偏好分开记录，不能用一个强制勾选框把非必要营销一并捆绑。法律包保存当时实际呈现文本和constants解析结果的hash；对订单和合同保留可重现快照，文件更新不篡改历史接受事实。重大条款更新依适用规则通知或重新接受，客服始终能查到对应订单的旧政策。

商户通常为其店铺消费者数据的控制者，平台在按商户指示提供相关服务时作为处理者；平台为自身订阅、反滥用和法定义务处理的数据另行界定。具体角色必须按实际处理活动确定。GDPR第28条规定控制者与处理者合同内容，第32条关注适当安全措施，第33条要求处理者在知悉泄露后无不当延迟通知控制者。[S16]

常量与上线检查

区分 PLATFORM_LEGAL_* 与 MERCHANT_LEGAL_*，包括名称、注册号、地址、邮箱、电话、税务信息、投诉通道、适用法律、争议安排及数据联系人。占位值统一为 example 或 example.com；生产发布校验器扫描占位、空联系方式、不存在的退款入口、缺失政策版本和未确认的服务承诺。

拟定“泄露初报24小时、终止导出窗口30日、主数据删除30日、备份最长90日”等为候选服务目标，需要事件响应、导出、保留例外及恢复流程实现后验证，并由律师确认合同表述；当前不是已达成SLA，也不能取代法定时限。会计/争议等依法需要保留的数据按目的最小化保留，恢复旧备份后重新执行删除标记。

欧盟ODR平台已于2025年7月20日停止运行，商店模板不应继续链接旧平台作为有效投诉入口；使用经确认适用的商户投诉和争议解决信息。[S18]

13 / ARCHITECTURE技术选择与两种官网部署

浏览器通过受控API访问交易核心；核心在同一数据库事务内更新业务记录和Outbox，后台异步传递事件。Agent只能经带策略的工具网关调用业务服务，不能绕过领域方法直接写数据库。平台订阅与商户交易在身份、密钥、表和事件路由上分开，即使首发部署在同一代码仓库。

建议的代码组织

apps/
  marketing/          官网：当前HTML；后续静态生成
  merchant-web/       React + TypeScript + shadcn/ui + Tailwind
  storefront/         SEO友好的公共店面与受控主题组件
  api/                Node.js模块化应用
  jobs/               持久化异步工作进程
packages/
  contracts/          Zod schema、OpenAPI、事件契约
  commerce/           商品、报价、订单、支付和售后领域
  tenancy/            TenantContext、授权、范围仓储
  agent-tools/        工具契约、策略、审批与任务步骤
  billing/            SaaS订阅、权益和credits账本
  policies/           法律文件、constants、版本与同意
  i18n/               消息、locale与金额格式
  ui/                 品牌组件与主题tokens
  adapters/           PSP、物流、税务、邮件、模型
  observability/      Trace、审计、指标和脱敏

自研核心路线使用TypeScript服务层、Prisma和MySQL；运行时选型锁定版本后再验证数据库驱动、迁移与部署兼容。前端React Query管理服务端状态，RHF/Zod承接表单校验；业务规则必须在后端再次执行。

Vendure可作为交易核心加速器

Vendure官方描述其核心基于TypeScript、NestJS和GraphQL，部署包含Node.js API服务器、后台worker及共享SQL数据库；其Channels支持店铺/市场分区，但默认Channel包含全部实体。[S2][S2b]因此可以先做受限验证，决定复用其商品、订单和促销基础，同时由Aster补充租户边界、Agent治理、计费、法律包与发布系统。

采用条件：验证渠道越权、商户顾客隔离、退款状态、国际税务扩展、升级兼容和许可证；尤其把“默认Channel全局可见”纳入测试。Vendure使用自身数据层时，不再用Prisma对同一核心表进行双重ORM管理；Prisma可仅服务独立的平台模块。其官方声明GPLv3与商业许可证选项，自部署分发方案应由律师根据实际组合与分发方式核查。[S2]

官网部署契约

Cloudflare官方支持Worker代码与静态资源作为一体部署；其Node兼容文档仍区分完整、部分支持和不可用stub。因此，本方案从官方能力推导出“公共前端与Node交易核心解耦”，不宣称把Node应用添加兼容标志就能原样运行。[S1][S1b]

本轮所称“自部署”指官网交付物具备自行托管能力；整套SaaS私有部署、商户独占数据库和生成商店源代码授权需要在未来产品与商业合同中分别界定，不能自动等同于基础订阅权益。

14 / DATA & API数据模型与接口边界

API面向明确的业务动作

所有写接口使用规范化body hash保护幂等键：同键同请求返回已记录结果，同键不同参数返回冲突。更新接口采用资源版本或If-Match进行乐观并发控制；客户端不能覆盖更新后的价格或政策。HTTP条件请求的语义参考RFC 9110，具体失败码与API契约统一定义。[S19]

{
  "eventId": "evt_example",
  "type": "commerce.payment.captured",
  "schemaVersion": 1,
  "tenantId": "tenant_example",
  "storeId": "store_example",
  "aggregate": { "type": "payment", "id": "pay_example", "version": 4 },
  "occurredAt": "2026-10-10T06:00:00Z",
  "traceId": "trace_example",
  "causationId": "receipt_example",
  "data": { "orderId": "order_example", "amountMinor": "1099", "currency": "USD" }
}

15 / RELIABILITY & SECURITY一致性、Webhook、安全与可恢复性

外部支付事件不保证按顺序到达

Stripe明确Webhook可能重复、并不保证生成顺序，验签需要原始请求body；其事件时间戳也不能替代去重ID。[S5]据此，本方案统一采用以下接收流程：

1. 限定请求方法、body大小和来源路由，保留raw bytes；按当前/轮换期密钥校验签名、时间容差和环境。
2. 由已验证provider account映射Tenant和Store，校验外部对象属于该连接；对金额、币种、模式和对象ID进行业务一致性检查。
3. 事务写入 WebhookReceipt，唯一键为provider、账户、环境、eventId；接收内容持久化成功后快速返回2xx。数据库不可用则返回可重试错误。
4. 后台在聚合锁/版本控制下处理；必要时主动获取PSP对象最新事实，使用合法状态转换而不是“最后到达的事件覆盖一切”。
5. 业务变化和Outbox同事务提交。消费者以Inbox处理记录防重复，消息发送、发货任务和credits授予均有各自业务唯一约束。
6. 失败进入有退避重试的队列，达到上限进入死信；人工重放仍经过鉴权和幂等规则。对未知状态保留证据并进入对账，避免静默吞掉。

整体承诺是“至少一次投递 + 幂等业务处理 + 对账恢复”，不把网络和外部PSP包装成跨系统严格exactly-once事务。外部调用超时先查询结果；盲目改用新幂等键会导致重复扣款或退款。

安全基线

观测和报表的统一口径

请求、Agent任务、订单、支付和外部Webhook使用可关联TraceID；审计记录actor、role、tenant、resource、before/after摘要、原因、审批ID和来源事件。业务告警关注付款已扣但订单未确认、库存负数、重复退款风险、Webhook积压、对账未平、撤回回执失败及Agent异常预算消耗。

经营报表分列订单数、商品销售、折扣、税、运费、成功退款和拒付，区分下单时间、扣款时间和结算时间。所有图表显示币种、时区、期间与口径；收入与现金到账不能混为同一指标。Agent“完成”需有交付结果，“发布”需有人确认，客服“解决”需定义重复工单观察窗口。

备份、恢复和迁移

数据库启用全量备份与可用的时间点恢复策略，对象存储保留必要版本；备份加密并限制读取。恢复演练必须包含数据库、对象、事件游标、法律版本和PSP对账，检查已发货/已退款外部事实不会被旧备份重做。RPO、RTO、可用性承诺在成本方案、压测和恢复演练后确定，首发官网不显示未经验证的SLA。

模式迁移采用兼容性扩展、回填、切换、收缩的顺序，避免后台滚动发布期间新旧版本冲突。商户导出覆盖商品、媒体manifest、客户、订单、支付引用、政策/同意记录及可交付的Agent产物；授权检查、脱敏与法定保留例外一并处理。数据导出窗口和备份删除周期与最终合同保持一致。

16 / SUBSCRIPTIONS月付与年付订阅设计

以下是用于官网预览与商业验证的拟定方案，所有价格以USD标价。平台不另收商品交易抽佣，PSP手续费与适用税费另计；自部署官网不会消除真实SaaS后台、模型、支付或第三方服务成本。

年付按10个月月费收费，和连续12个月月付相比省2个月，即约16.7%。年付卡片同时展示年度实扣总額和月均参考，不把月均值伪装成每月实际账单。基础安全、隐私、退款和消费者支持不应作为高阶套餐才具备的功能。

配额口径与耗尽行为

• 店铺为活动中的独立店铺，包含仍在编辑的草稿；归档店铺只读且不能继续接单，不计活动数量。归档不是删除订单或结束售后义务。
• 席位包含Owner与激活员工；待接受邀请预留席位，撤销邀请释放。Agent服务身份不按自然人员工计费，但受任务和权限配额限制。
• SKU按租户内活动的独立可销售SKU计数；同一个SKU分配到多个渠道不重复计数，复制成独立SKU会计数。已有订单不因商品归档丢失快照。
• 不按订单数量触发强制关停；明确基础运行容量、合理使用与滥用规则。达到SKU/席位/店铺上限时限制新增并提示升级，不停止既有订单的处理。
• AI余额不足时停止新的Agent任务或转人工客服，结账、人工处理订单、Webhook和退款状态同步继续工作。预算增加必须有商户明确选择，无默认超额付费。

credits是任务计价，不是模型token

上述成本档位是产品定价假设，需用模型调用成本和用户接受度实测后定稿。执行前原子预占，成功交付后结算；任务失败通过幂等补偿账目退回，系统失败不让用户承担重复计费。credits账本保留 grant / reserve / capture / release / reversal / expire，不能直接修改余额覆盖历史。

月付和年付均按账单锚点每月补充额度；年付不在第一天一次发放12个月额度。月度额度不累计滚存，补充时间和下次重置在账单页明示；失败任务返还原则和跨周期情况由账本记录原始来源，避免把旧额度错误计入新月。法定退款或平台服务补偿另按合同处理。

订阅生命周期

本地订阅使用 pending / active / past_due / grace / suspended / cancel_at_period_end / ended 等业务状态，并分别保存PSP原始状态。支付完成跳转只显示处理中；服务端核验账单和订阅状态后发放权益。Stripe建议收到invoice.paid后再查询订阅确认active，不能把单个已付发票直接当作所有订阅责任都已履行。[S20]

• 续费：在购买页清楚说明续费周期、总额、税费和取消方法；按法域要求发送提醒并保存记录。
• 取消：账单中心自助取消自动续费并显示服务截止日期、导出和售后安排；取消不删除已支付期间权益。
• 升级：显示准确的差额报价与生效时间，经确认和支付后发放新增权益；避免重复发放整月credits套利。
• 降级：默认下一周期生效；商户选择要保留的店铺/席位并完成超限处理，不自动删除数据。
• 欠费：提醒并提供明确宽限期；宽限后按已签合同有序限制新操作/新下单，保留既有订单售后、付款Webhook和数据退出路径。AI额度耗尽与订阅欠费是不同情况。

17 / MARKETING WEBSITE双语SaaS官网的信息设计

官网面向商户解释可以完成什么、如何保有控制、价格如何计算。数据库、队列和模型实现属于产品文档，不出现在主购买路径里。工作品牌Aster需要后续商标、域名和冲突调查；本轮不把命名可用性当作已验证事实。

视觉和交互要求

采用留白充足的浅色编辑式排版、温暖中性色背景、克制的强调色和清晰产品示意。动画服务于“想法 → 内容 → 店铺 → 运营”的叙事，避免抢眼粒子、无意义仪表盘数字或过度炫光。减少动态偏好下保持完整内容；窄屏导航、表格与价格卡片可读且触控友好。

预览中的语言切换覆盖导航、按钮、模块、FAQ、价格说明、弹窗和错误消息；记住用户语言与计费选择。主要按钮都产生真实可见结果：滚动到目标、打开演示、展示套餐摘要或打开法律文件。联系/提交类演示必须说明未发送，不能给出假的“已联系销售”。

18 / DELIVERY & ACCEPTANCE分期建设与可验收目标

关键验收用例

上线前需要明确的商业输入

实际平台公司与注册地、第一批商户所在地区、首先开放的销售市场和商品类型、首个PSP及商户开户方式、税务/开票边界、客服渠道和时段、模型供应商与数据处理条款、实际资源成本和最终价格、律师审定法律包与服务目标。这些输入可以并行推进；不阻塞本轮官网预览和产品架构交付。

19 / PRIMARY SOURCES官方资料与核查范围

资料核查日期：2026-10-10。仅引用官方文档、标准或法规原文。来源支持下列明确的外部事实；Aster的流程、数据模型、配额和验收用例是本项目拟定设计，仍需实施和验证。

1. [S1] Cloudflare — Workers Static Assetshttps://developers.cloudflare.com/workers/static-assets/支持事实：Workers可以部署静态资源，并与Worker代码一起部署。
2. [S1b] Cloudflare — Node.js compatibilityhttps://developers.cloudflare.com/workers/runtime-apis/nodejs/支持事实：Node API有支持程度差异和非功能stub，不能把兼容性等同完整Node进程。
3. [S2] Vendure — Core architecture and licensehttps://vendure.io/core支持事实：TypeScript/NestJS/GraphQL、Node服务器与worker、SQL存储及GPLv3/商业许可选项。
4. [S2b] Vendure — Channels source documentationhttps://github.com/vendurehq/vendure/blob/master/docs/docs/guides/core-concepts/channels/index.mdx支持事实：渠道可限定商品、货币、语言与权限；默认Channel包含所有实体。
5. [S3] OWASP — AI Agent Security Cheat Sheethttps://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html支持事实：执行组件独立授权、高影响操作绑定审批与重放防护、人工监督。
6. [S4] OWASP — Multi Tenant Security Cheat Sheethttps://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html支持事实：多层隔离与缓存读取前授权，缓存键不能代替权限控制。
7. [S5] Stripe — Receive events in your webhook endpointhttps://docs.stripe.com/webhooks支持事实：原始body验签、重复事件、无顺序保证与事件ID去重。
8. [S6] Stripe — Supported currencieshttps://docs.stripe.com/currencies支持事实：最小货币单位、零小数和特定币种规则。
9. [S7] Stripe — PaymentIntent lifecyclehttps://docs.stripe.com/payments/paymentintents/lifecycle支持事实：支付需要区分用户动作、处理中、待扣款及成功等阶段。
10. [S8] Stripe — Refund and cancel paymentshttps://docs.stripe.com/refunds支持事实：累计退款上限为原始扣款；退款退回原付款方式。
11. [S9] Stripe — Integration security guidehttps://docs.stripe.com/security/guide支持事实：托管/低风险集成降低卡数据经过业务服务器的范围，但不消除经营者PCI责任。
12. [S10] Google Search Central — Localized versionshttps://developers.google.com/search/docs/specialty/international/localized-versions支持事实：hreflang语言/地区版本和互相回链要求。
13. [S11] Google Search Central — Canonical URLshttps://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls支持事实：canonical与hreflang作用不同，语言版本优先关联同语言规范页。
14. [S12] Google Search Central — Product structured datahttps://developers.google.com/search/docs/appearance/structured-data/product支持事实：产品结构化数据及商家展示相关支持；不保证搜索展示结果。
15. [S13] Google Search Central — Block indexing with noindexhttps://developers.google.com/search/docs/crawling-indexing/block-indexing支持事实：noindex可用meta或响应头；robots阻断会使爬虫看不到noindex。
16. [S14] Google Search Central — Build and submit a sitemaphttps://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap支持事实：站点地图格式、规范URL与维护建议。
17. [S15] W3C WAI — How to meet WCAG 2.2https://www.w3.org/WAI/WCAG22/quickref/支持事实：无障碍设计与验收所依据的成功准则。
18. [S16] EUR-Lex — Regulation (EU) 2016/679https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng支持事实：GDPR第28、32、33条的处理合同、安全和通知要求；具体适用待律师确认。
19. [S17] EUR-Lex — Directive (EU) 2023/2673https://eur-lex.europa.eu/eli/dir/2023/2673/oj/eng支持事实：对2011/83/EU新增Article11a在线撤回功能，Article2规定成员国自2026-06-19适用转化措施。
20. [S18] European Commission — ODR platform closurehttps://consumer-redress.ec.europa.eu/site-relocation_en支持事实：旧ODR平台于2025-07-20停止运行。
21. [S19] IETF — RFC 9110 HTTP Semanticshttps://www.rfc-editor.org/rfc/rfc9110.html支持事实：HTTP条件请求与If-Match语义；本方案另行定义业务幂等合同。
22. [S20] Stripe — Subscription webhookshttps://docs.stripe.com/billing/subscriptions/webhooks支持事实：订阅状态与账单事件需协同校验后更新访问权益。