优化入仓码查询入口与卡片交互

docs/architecture.md

@@ -27,7 +27,8 @@ PowerShell 下把目录和 `-g '*.py'` 分开传给 `rg`。报价字典可能整
 | 知识检索 | `logistics_chat/knowledge.py`：`knowledge_list`、`search_knowledge` | [knowledge.md](knowledge.md) 与代码同步，程序不读取该文档 |
 | 运费与附加费 | `logistics_chat/pricing.py`：`RATES`、`parse_shipping_intent`、`dims_to_cm`、`pick_rate`、`calc_freight`、`freight_reply`、`calc_warehouse_card`、`detect_surcharge`、`check_island` | `logistics_chat/rates_extra.py` 为唯一扩展数据源，根目录同名文件仅兼容转发 |
 | 卡片协议 | `logistics_chat/tracking.py`：`CARD_PREFIX`、`card_to_text`；旧 `extract_tracking_no`、`build_track` 仅兼容旧导入 | `static/js/chat.js`：`fillTrackCard`、`addTrackCard`；新订单卡片由 `order_data.py` 提供，历史卡片保留兼容渲染 |
-| 订单测试表 | `logistics_chat/order_data.py`：`init_order_table`、`import_records`、`lookup_order`、`answer_query` | SQLite `order_test_data` 为可编辑快照；按订单号、入仓码、Shipment ID 精确查表。将来 MCP 在取数层替换 `lookup_order`，不让模型拼 SQL |
+| 订单测试表 | `logistics_chat/order_data.py`：`init_order_table`、`import_records`、`lookup_order`、`count_orders`、`answer_query` | SQLite `order_test_data` 为可编辑快照；按订单号、入仓码、Shipment ID 精确查表。将来 MCP 在取数层替换 `lookup_order`、`count_orders`，不让模型拼 SQL |
+| 查单交互 | `static/js/order_lookup.js`：`OrderLookup.create`；`chat.js`：`showOrderLookup`、`fillTrackCard`；`support.js`：`copyText` | 快捷入口及当前/历史卡片共用查询框；显式输入后才查单，保留聊天草稿和附件；复制共用安全回退 |
 | AI 与 SSE | `logistics_chat/chat_service.py`：`create_chat_stream`、`sse`；`ai_client.py`：`post_completion`、`compress_answer`、`gen_followups` | `routes/chat.py`：`stream_chat`；客户端 `doSend`、`renderError`、`renderFollowups` |
 | 人工会话 | `logistics_chat/human_service.py`：`human_*`（含转接、备注、撤回）；对应 `routes/human.py` | 输入状态在 `app.extensions['human_typing']`；客户 `startHumanPoll`；客服 `loadQueue`、`poll`、`sendReply`；人工申请每天 8:00–22:00 |
 | 附件 | `logistics_chat/file_service.py`：`upload_file`、`cleanup_uploads`；`routes/files.py`：`uploaded_file` | 扩展名/大小/目录由配置提供；客户端 `addMsg`，客服端 `appendMsg` |
@@ -115,6 +116,7 @@ tests/                        # 按业务模块组织的回归
 - 登录后的订单数量查询由 `parse_count_query` 识别，`count_orders` 使用与单号查询相同的 `tenant_filter` 交集规则，必须显式提供非空客户范围；SQL 直接计算订单票数和已登记入仓码的订单票数，按需过滤明确的业务状态。无额外筛选时统计授权范围全部订单，不复用上一票单号；无法识别的附加条件不静默丢弃，也不交给模型猜数。成功统计返回的内部 `_customer_data` 标记由 `chat_service` 消费并移除，使纯文本统计同样在保存/发送前绑定会话客户和范围；不增加公开 SSE 字段或管理接口。
 - 客户认证使用独立 `customer_users`、`customer_tenant_grants` 与 `customer_sessions` 表，由 `customer_service.attach_customer` 在访客恢复之后验证并设置 `g.customer`、单客户 `g.customer_tenant_id` 或多客户 `g.customer_tenant_ids`；只保存密码哈希与登录 token 哈希。默认账号首次关联当前本地订单的客户范围，之后不自动扩大，普通账号仍按明确关联过滤；`lookup_order` 的单客户参数及多客户白名单都与环境限制取交集。会话的 `customer_scope` 保存范围指纹。登录 Cookie 为 HttpOnly、SameSite=Lax，在 HTTPS 上为 Secure，绑定当前访客并在 8 小时后失效；退出、账号停用、密码或客户范围改变使旧会话失效。默认客户账号不赋予客服后台权限。
 - 匿名查单返回 SSE `login_required` 与正文，客户页提供登录按钮；`customer.js` 登录成功后仅在原会话版本未变化时继续原问题，保留期间输入的新草稿。登录过期导致界面清空时，只允许同一客户重新通过历史归属校验后恢复原会话并续查；换账号、访问范围变化、历史加载失败或切换话题均不重放旧问题。侧栏可独立登录/退出，登录状态在窗口恢复焦点时刷新。首次返回订单卡片时，会话绑定客户 ID 和客户范围；历史、人工会话及后续生成同时校验访客、客户和范围。退出立即清除当前可见订单内容和历史标题缓存，重新登录同一身份可恢复；匿名清空历史不删除被登录保护的会话。
+- 底部及欢迎卡片的查入仓码入口先确认客户登录，再打开 `OrderLookup`，不自动新建会话或发送缺少号码的问题。当前及历史订单卡片的号码也打开该查询框，保留真实的入仓码/订单号标签，支持单独复制和重新查询。提交使用既有 `/stream_chat` 并显示明确的用户问句，结果追加到当前会话；主输入框草稿及已上传附件不清空、不代发。人工接待、未加载历史或其他请求进行中时不抢占路由。切换话题/身份关闭弹窗，迟到的登录/状态/复制结果不得改动新上下文；弹窗跟随手机可视视口并将焦点还给触发按钮。
 - 节点导出：`scripts/export_order_tracking.py --database-env <显式环境文件> --orders-snapshot <私有订单快照> --output <新私有节点快照>`。仅需离线导出时安装可选 `PyMySQL`；脚本开启源库只读事务，只查询快照订单直接关联的入库完成、已冻结装柜和标准船节点，按客户与源订单 ID 同时匹配。随后运行 `scripts/import_order_test_data.py --snapshot <节点快照> --db <运行数据库> --tracking-only`；只更新已有订单的 `tracking_json`，校验源 ID，不改订单字段，默认保留已有轨迹。`--replace` 才覆盖手工轨迹。快照不随 Git 发布；将来 MCP 接入仍返回同一事实结构，无需改变卡片协议。
 - 历史卡片以 `__CARD__{json}` 保存；原 SQLite 表、字段、角色值和历史记录继续可读。历史正文和卡片使用存库时间，卡片恢复复制操作。切换话题或历史时取消旧流和待上传附件；等待建会话期间的新草稿不能被旧发送清空。历史刷新失败保留已有列表；删除或清空成功后先同步本地列表，并使先前的刷新失效，刷新失败或迟到均不恢复已删除记录。删除会话同步移除其人工会话及消息，迟到的模型写入不能生成孤立消息。
 - 人工申请使用 `conv_id`，返回 `session_id`，后续用 `sid`。状态为 `waiting/active/closed`，消息方向为 `customer/agent/system`。转接将 active 改为 waiting，列表只允许主动接入。备注保存在 `human_sessions.note`；撤回将原客服消息改为系统提示并追加带 `recalled_id` 的系统事件，轮询按原消息编号更新，重复撤回不追加事件。