登录
账号由管理员用 cmd/userctl -cmd create 创建（本轮不做开放注册）。
登录 token 只存在服务端内存里，服务重启后需要重新登录。
我的店铺
| 店铺号 | 归属结论 | 备注名 | 导入时间 | 最近探活 | 操作 |
|---|
还没有店铺，用下面的表单导入第一份会话 Cookie。
导入店铺会话
导入时服务端会用这份会话反问平台「这是哪家店铺」，与店铺号不一致就拒绝（HTTP 409）。
反查不出会记成 unknown（不等于不匹配）。会话加密落盘，Cookie 值从此不再以明文出现。
机会商品（点一条 → 预览 / 发布同款）
还没有拉取。
★ 机会商品列表每次请求的顺序与子集都不一样（实测同一秒两次请求，返回的 bidding_id 就不同），
所以「0-based 序号 / bidding_id」都不可靠 —— 序号在两次请求之间指向的很可能不是同一条商品。
这里把这一页的真实记录（连原始 JSON）一起取回浏览器：点「用它预览同款」后，
预览与执行都会带上那条记录本身（opportunity_json），
从而保证「预览的是哪一条，发布的就是哪一条」。本卡片只读。
属性模板（只读 → 一键填进两张表单）
还没有拉取。属性 id 与属性值 id 都是平台内部编码（关税种类 1000407=1004208、材质 160=1025）， 照着文档手敲等于发一条属性错的商品出去 —— 而平台只会回一句「普通属性中存在销售属性」。在这里点选，再点「填进两张表单」。
分流规则：普通属性（type 3/4）才进 product_attribute_list； 颜色是主销售属性（type 1 label 1，决定 SKC 数）、尺寸是次销售属性（type 1 label 0，决定 SKU 数）—— 销售属性塞进普通属性会被平台拒；type 2 是尺码表属性，值走手填数值（attribute_extra_value）。 材质类属性的手填值（如 100 = 100% 棉）填在每行第二个框里。本卡片只读。
发布预览（零写操作）
没有选中机会商品：预览时会按「机会商品」框里的序号 / bidding_id 现场拉列表（★ 列表每次都在变，建议先在上面「机会商品」卡片里点一条）。
这一步只读：拉机会商品、类目链、必填属性、类目准入、跟卖资格、必填证书，
组装出真正的发布载荷并做形状自检 —— 一个写操作都不发。同参数下返回的 sha256 应与
cmd/payloadcheck 完全一致；写操作计划只是清单，本页不执行。
写操作（默认全关）
正在读取服务端闸门状态…
闸门只由服务端启动参数决定（-allow-write / -allow-publish），
请求体里没有、也不接受任何开关；publish 还要确认词，且不可撤销。
每一次尝试（包括被拒绝的）都会追加一行到 <数据目录>/audit.jsonl（0600），
审计里记「真的发出了哪些 op」，不记 Cookie。
发布任务队列（后台跑，同店串行）
正在读取任务…
| 任务 | 阶段 | 状态 | 店铺 | 时间 | 结果 | 操作 |
|---|
为什么要有队列：一次真实发布要几十秒（建码 → 传图 → 价格预检 → 发布 → 反查），
同步跑会把浏览器吊在那里，一刷新就不知道到底跑成没有。另一半原因是
同一个店铺同一时刻只能跑一条（店铺身份完全由 SITE_ID 决定，同店并发会让两次发布互相干扰），
异店之间最多两条并行。任务里没有凭据（只记 user_id + supplier_id，执行时才取会话），
跑完还会把图片从磁盘抹掉；写操作在执行时会再查一遍服务端闸门，所以入队成功不代表一定会发出去。
取消只对「排队中」彻底生效；已经在跑的只能请求中断 —— 写操作一旦发出就不可撤销。
发布记录（只读）：我发出去的东西都在什么状态
还没有查询。
published=true 只说明平台接受了这次请求；
这里查的是「这条商品真的出现在发布记录里了吗」。填了 skc_name 时只认 skc_name 与上面的值完全相等的那一行 ——
平台在忽略参数时会返回列表第一条，拿它当结论会把后续动作打到别的商品上。本卡片只读：连「导出」也只是把行读出来交给你。查不到先别慌：记录列表有延迟，等一会儿重跑；仍然没有，就去商家后台「商品管理」按 spu 人工核对。 全店清单是按页收齐的（最多 20 页 × 200 行，按 record_id 去重），页面会明确告诉你这份清单是否完整 —— 页数用尽或有页失败时，别把它当成全店清单。
合规（只读）：还缺什么 / 池子里有什么 / 建议绑哪张 / 警告语要选什么
★ 这一整块都是只读的：扫描只调平台的查询接口， 不会绑证书、不会提交警告语、不会改动平台上的任何商品（那两步是写操作，要单独授权）。 「标记已处理」只写本机的合规状态文件，用来记住「这条我看过了」。
还没有扫描。合规扫描走官方 OpenAPI 通道（不是网页 Cookie）， 所以这个店铺得先登记过 openKeyId / secretKey —— 没登记时会明确告诉你缺凭据。
绑证书（写操作 · 服务端默认关）
绑证书走官方 OpenAPI 通道，是写操作：绑上会改平台上商品的合规状态。
服务端默认关着（启动参数 -allow-bind），关着时这里只能看「将要发出的请求」；
真绑还要请求体带 confirm="BIND"。一条 SKC 一个请求、串行 + 限速。
警告语提交（写操作；按商品级开关 warn_submit）
把 SKC 的警告语（商详页提示内容）真的写到平台上。走官方 OpenAPI 通道。
闸门是「商品档案」里的商品级开关 warn_submit：那个商品勾着就提交、
没勾就跳过（不报错、也不发请求）；另有请求体 confirm="WARNING" 防误触。
只点「预览」不写平台；点「真提交」才会写。★ 平台不校验 SKC 是否存在，对不存在的 SKC 也回
code=0，所以 code=0 只代表「平台受理」，不代表审核通过。
还没有读模板。点「读模板」拿这家店能提交的警告语类型与可选值 （只读平台，不写任何东西）——能提交的只有 EuToyWarnings / ToyWarningWord，提交时要把所有选择字段都选上。
商品档案（本地）：我发过什么 / 我打算发什么
★ 这一块是纯本地的：它记的是「我打算发什么 / 我发过什么」， 不发任何平台请求、不占发品额度、也不受写操作闸门管。 删除档案只是删本机这条记录 —— 平台上的商品不会消失，发布记录也一条不少； 反过来，你在商家后台删了商品，这里的档案也不会自己消失。
还没有读取档案。
手工建一条（同一个 spu 会并成一条）
手工建档只是「记下来」，不会把状态写成已发布 —— 只有发布链路才能写「已发布」和发布时间。
同一个 spu 再存一次是追加 SKC，不会长成两条；档案文件在数据目录 products/ 下，
每次改动前自动备份、保留最近 20 份。
商品级合规开关（8 项）：这个商品要不要做这几步
★ 开关的归属是「商品」，不是店铺 —— 同一个店铺的两个商品可以配得不一样。
「校验达标后自动撤回」默认是关的（不可逆操作），其余 7 项默认开。
这里只改本机档案，不发任何平台请求，平台上一个字都不会变。
上面「警告语提交」卡片也看这里的 warn_submit：关着的商品会被直接跳过
（不算失败、也不会发请求）—— 归属永远是商品，不是店铺、也不是服务端启动参数。
撤回替换（本地账本）：模板 / 替换商品 / 待编辑清单
★ 这一块和商品档案一样是纯本地的：不发任何平台请求、不占发品额度、也不受写操作闸门管。 撤回后证书还在审核，通过之后要用「一套固定属性模板 + 一个替换商品」把这个 SKC 重新编辑并发布 —— 平台不回答「这个 SKC 我是不是已经替换过了」「那个替换商品还有几次可用」，所以记在这里。 真正把商品重新编辑并发布的执行器还没做（它会真的改平台上的商品，需要单独点头）。 三条铁律：一个替换商品只用一次、一个撤回 SKC 只替换一次（只有「成功」才算，失败允许重试）、 用得最少的替换商品先用。
还没有读取账本。
建一个编辑属性模板（品类确认之后才参与替换）
改一条模板请用上面表里的按钮（确认 / 取消确认 / 删除）。 改名字或属性不会自动重置确认 —— 确认是人的判断；删除模板也不会连替换商品一起删， 那些商品会失去模板归属、于是不再被选中（用过的记录还在）。
入队替换商品（一个文件夹 = 一个替换商品）
多规格（一色多码）暂时只在命令行 / 接口层的 specs 里收 ——
免得把一整棵规格树塞进一个逗号输入框。
记一次替换结果（可顺带加用量 / 出清单）
顺序是先加用量、再落记录、最后出清单，每一步做过什么都会写在下面的提示里 —— 本地账写坏一半比写失败更难查。
待编辑清单（门禁已放行的 SKC）
清单只记「门禁已放行」的 SKC；真的替换完请记一条记录并勾上「出清单」 —— 这两件事分开做就会出现「替换了但没记上、下一轮又重复替换」。
发布草稿（攒一批，再一起发）
★ 这一块和「商品档案」「撤回替换」同一类：纯本地。勾一条机会商品「攒成草稿」，再慢慢补类目 / 标题 / SKC 与 SKU， 显示「就绪」后拿去发布。改草稿不发任何平台请求，所以不受写操作闸门管；真正发布仍然走下面那张写操作卡片（要闸门 + confirm）。 草稿落在服务器数据目录里，刷新或关掉浏览器都不会丢。
还没有读草稿。
攒一条（也可以把机会商品记录贴进来）
也可以在上面「机会商品」每一条点「攒成草稿」—— 那条记录会原样存进本地草稿，之后再补。
改一条草稿
★「就绪」的判据照抄 Python 版：未选类目 / 缺 product_type_id / 缺中文标题 / SKC 缺销售属性(颜色) / SKC 未上传图片 / SKU 缺供货价 / SKU 缺库存。 删草稿与清空都只动本地清单，平台上的商品一个都没动。
审核监控（本地账本 + 只读刷新）
走了「校验达标后自动撤回」这一步的商品，证书还在平台审核。这里记着它们，并显示现在审核到哪一步 —— 哪一条停了、卡在哪个必填项上。
★ 这一块是本地账本 + 只读刷新：刷新只调查询接口（不提交、不撤回、不改平台任何东西）， 所以不受写操作闸门管。已成功替换 / 已失效的 SKC 会跳过查询（不再追它替换后的审核状态）。 申诉（final-reject）要写平台，还没有做 —— 做的时候会单独设闸门并要求确认。
换电脑迁移用：导出清单把本地账本存成一个 JSON 文件，导入清单把它并进本机账本
（两种形状都收：{"rows":[…]} 与裸数组 […]）。
命令行等价物：./bin/auditcheck -export -export-out 清单.json /
./bin/auditcheck -import -import-from 清单.json。
导入只动本机账本，平台上一个字都不改。
用户管理（仅管理员）
正在读取…
| 用户名 | 角色 | 店铺数 | 建于 | 操作 |
|---|
管理员不碰平台凭据：这里只建账号与角色，Cookie 永远只由各用户自己导入到自己的店铺下。
审计（仅管理员）
| 时间 | 用户 | 阶段 | 店铺 | 结果 | 说明 |
|---|
审计只记「谁在何时对哪个店铺做了什么、结果如何」，不记 Cookie、也不记完整载荷。
全部店铺（跨用户，仅管理员）
正在读取…
| 用户 | 店铺 | 归属 | 会话 | 上次探活 | 结论 |
|---|
扫描是只读的：只调平台的登录态探活接口，不发任何写操作；结论会写回每个店铺的「上次探活」。会话过期的店铺会显示「失效（20302）」，需要用户重新导入 Cookie。