连接器上线预检
上线前验证 TLS、签名、路径、权限、版本、会话、发送、历史与人工接管。
近 29 天对话复盘后,ReplyTower 最清楚的产品信号不是“再加功能”。是把连接器、附件、知识库、反馈与性能的真实状态直接交给客户。
生产读取严格只读。没有上传探测、部署、配置改动或客户原文复制。
当前最大机会是把系统真相做成产品能力。
6,952 个生产对话中,79.7% 是平台合成 canary。它们用于健康监测,不能拿来计算用户需求或问题频率。
历史会话中的“已关闭”保留为归档字段。当前执行状态采用更严格口径:只有真实浏览器、生产或端到端回执,才能从 △ 升为 ○。代码与测试只证明已经实现。
同一对话可进入多个主题。下列数字是使用相关词汇的唯一用户数,用于发现旅程,不用于直接证明产品故障。
ReplyTower 生产后端并不是 2MB。精确症状更像 Xboard 面板 PHP 默认值进入了插件的最小值计算,但这个推断尚未获得面板生产读取授权。
保留的生产窗口与日志中没有发现明确的 2MB 投诉或上传相关 413;日志保留从 7 月 11 日到 22 日后分层开始,不能排除更早记录。102 位用户成功发送 178 个附件,最大规范化对象 0.484MB。
PHP 官方文档列出的 `upload_max_filesize` 默认值正是 2M。插件又会选择 PHP、面板 Nginx、ReplyTower 中的最小值,所以它是第一检查点,不是已确认根因。
这不是 VPNCheap 客户端路线图。这里只把首位客户的使用证据映射回 ReplyTower 自己应承担的产品能力。
状态按 19 个唯一反馈指纹分组且只计一次。组件可以协作,但每个客户可见结果始终只有一个最终验收负责人。
五组相加恰好是 ReplyTower 唯一总数:○1 / △14 / ☐4 / X0。VPNCheap 客户端改进另见独立简报。
以下是产品方案价值评分。客户伤害优先级另在 19 条指纹注册表中只计一次,避免一个共享方案重复放大需求。
上线前验证 TLS、签名、路径、权限、版本、会话、发送、历史与人工接管。
让 Ticket 与 Widget 一样携带安全图片元数据、检索、视觉理解和历史回显。
统一所有入口的有效上限、流式拒绝、配置事实源、Telegram 失败与安全边界。
持久化评分、负面原因、接管、恢复和解决结果,让 0.71% 捕获率变成可行动信号。
已部署优化必须用 Portal 路由和浏览器 p50/p95 证明,不再用“感觉更快”结案。
把工具、保留、订阅授权、知识完整性与公告新鲜度变成幂等验收。
先识别投诉旅程,再读出插件、PHP、面板 Nginx 与后端每一层;最小字节值决定展示与拒绝。
第一阶段不是大规模开发。先把 14 个 △ 变成可执行的真实验收卡,把 4 个 ☐ 写成有负责人与停止条件的产品结果。
| CEO 指标 | 当前 | 90 天目标 | 为什么重要 |
|---|---|---|---|
| 真实验收债务 | △ 14 | 计划内至少 80% 转为 ○ | 防止“代码合并”等同“客户问题解决” |
| 结构化反馈捕获 | 0.71% | 所有显式负面信号有记录 | 当前样本严重偏差,无法可靠比较版本 |
| Ticket 附件能力 | 937 个 Ticket 对话中 0 个附件 | 发布版本端到端回执 | Widget 成功不等于支持工单可用 |
| 约束不一致 | 代码 10m,生产 12m,入口语义不一 | 一份配置事实源,所有入口一致 | 最小闸门与拒绝原因必须可解释 |
| Portal 性能 | 优化已部署,p50/p95 未量化 | 基线与 SLO 均有浏览器回执 | “已优化”必须转化成客户可见结果 |
| 负责人完整率 | 计划已映射,GitHub 执行卡待建 | 100% | 一个客户结果只允许一个最终验收负责人 |
批准 ReplyTower 的真相能力建设。
没有浏览器、生产或付款回执,不再把“已实现”汇报成“已解决”。
先读 PHP、Nginx、插件与后端;同时修复已实测的配置漂移和入口不一致。
连接器预检、Ticket 附件、结构化反馈先于新 Portal 功能。
ReplyTower 对 Ticket、Portal 与后端能力闭环负责;xboard-replytower 对嵌入式 Widget 结果负责;托管层只对所运营的最早失败层负责。