sundynix/sundynix-agentix
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
390 Commits 5 Branches 0 Tags
main
Commit Graph

6 Commits

Author SHA1 Message Date
Blizzard bd829cfecb feat(invite): 租户成员二维码邀请（可复用团队码，扫码关注即入组） 
owner/admin 在桌面端生成一张微信带参二维码发给团队，成员用微信扫码关注
即自动加入租户，并收到「✅ 已加入团队【X】」被动回复。与登录二维码同一微信机制，
scene 加 inv_ 前缀分流；扫码入组走被动回复，不需要 access_token、不碰 IP 白名单。

- store: TenantInvite(可复用码=有效期+人数上限+可撤销三道闸)；RedeemInvite 幂等入组、
  同一人重复扫不重复消耗名额、复活已移除者；带单测钉死过期/撤销/满员/幂等。
- handler: 建码/列表/撤销端点(RequireTenantRole admin)；WxMPEvent inv_ 分支。
- 顺手修潜在生产 bug：微信用户此前都建成空邮箱，User.Email 整列唯一索引下第二个微信
  用户就撞唯一约束建号失败(登录"全通"只因当前仅一个微信用户)。改为按 openid 合成占位
  邮箱 wx-<openid>@wx.local，绕开冲突且不动索引。邀请功能会批量建微信用户，非修不可。
- desktop: 顶栏「邀请成员」入口(租户 admin/owner 可见) + 二维码弹窗(生成/大图展示/撤销)。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-21 11:47:21 +08:00
Blizzard 80d4aaf4ba feat(billing): 订阅制后端 —— 手动购买 + 周期发放积分 + 到期失效 
规格（按需求）：用户扫码买一个订阅周期，有效期内每 N 天发一次积分，到期即失效，
不自动续费。N 与每次发放额度都在套餐里配，后台可改。

为什么不做自动续费：微信 Native 扫码支付没有代扣能力，真自动续费要走「委托代扣」
——另一套产品与资质。与其假装有，不如把"到期即失效"这个语义做扎实。

两个决定，都写进了代码注释：
- **发放语义是累加而非重置**。每次刷新写一条 grant 分录、余额累加。重置型
  （月度配额清零）会让「余额 = SUM(ledger)」这条对账不变量变复杂，且有误清
  用户自费积分的风险。
- **订阅开通放在 store.MarkOrderPaid 内**，而不是各调用方。回调与掉单补偿两条
  路都经过它，放这一处才没人能漏掉；按 orderID 幂等，重复调用无害。

复用而非另造：订阅单与积分包单走同一条支付链路（下单/回调/查单/掉单补偿），
只是 kind=sub 且 credits_micro=0——积分不在付款时给，由订阅按周期发。

定时器每 10 分钟扫一轮，语义与幂等都在 store.TickSubscription 里，与手动触发
共用，不会两处漂移。停机期间欠下的发放会一次性补齐。

8 组测试。其中一条当场抓到真 bug：开通时原本无条件发一笔，同一订单重复开通
（回调重推/查单赛跑）会因序号自增绕过幂等索引，白送积分。改为开通也走与定时器
同一套排期判断——排期天然幂等。教训：幂等键要锚在业务时间轴上，不能靠自增序号。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 16:11:34 +08:00
Blizzard e4ec74893f feat(admin): 任务观测支持下钻 —— 轨迹/输出/评测/DSL 
全平台任务页此前只能看列表，点进去什么都没有。现在点一行开抽屉，四个页签：
执行轨迹、最终输出、评测明细、提交时的 DSL。不含审批操作——审批是客户端
用户的行为（桌面端 ApprovalBar），管理端只做观测。

不复用用户面的 /tasks/:id/replay：Task/Eval 都在租户插件作用域内，用请求 ctx
查别的租户的任务不会报错，而是静默返回空输出/空轨迹，UI 上表现为"这任务没
产出"，比报错难查得多。新增 admin 端点走 WithoutTenant。

数据取自 sundynix_task 收尾落库的 output/trace 列，不依赖 Redis 流（10min TTL）。
所以这是复盘视图，运行中的任务轨迹为空——UI 里明确写出来，免得被当成轨迹丢了。

修的两处与测试环境失真有关（写测试时暴露的）：
  - 测试库没配 NamingStrategy，与 OpenPostgres 不一致：多数模型有显式
    TableName() 碰巧对得上，但 Task 这类没有的会退化成 "tasks"，导致写裸
    SQL 的查询在测试里查无此表。现已对齐 sundynix_ 前缀 + 单数表名。
  - graph 的 ::text 换成标准 cast(... as text)：前者是 Postgres 专有，
    换掉后这条查询才能被内存库覆盖。

新增 5 组测试，其中一组专门先证明"租户过滤在测试环境里确实开着"——否则
"跨租户能读到"的断言可能只是因为插件没装，属于假过。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 14:07:02 +08:00
Blizzard 84463394d4 fix(admin): 审计筛选下沉 SQL + 工具数不再写死 + 模型删除加确认 
清单里那批小毛病，逐条复核后修（「审计详情列缺失」那条已不成立，早补上了）。

1. 审计筛选只在当前页生效 —— 影响最大的一条。分页是服务端的，筛选却在
   前端对已取回的 50 条做，于是搜一个用户 ID 显示"无结果"时，后面几页
   可能还有几百条。审计的用途就是查证，"搜不到"会被读成"没发生过"。
   改为 action/path/q 三个条件全部落到 SQL，前端只管发条件（防抖 300ms）。

2. 服务状态页把 mcp-go/mcp-py 的工具数写死成 23/4 —— 增删工具后一直骗人，
   且服务离线时照样显示，看不出工具其实一个都没注册上。改取实际上报值。

3. 模型删除一点即删，无任何确认。补二次确认，并对"正在使用中"的模型
   单独说明后果（删掉会立刻打断线上对话/向量能力）。

审计筛选补了 4 组回归测试，两条是踩出来的坑：
  - q 的 OR 组必须带括号：gorm 以 AND 拼接各 Where，裸 OR 会让 action
    条件被绕过（测试里用"同 IP 不同方法"两行钉死这个语义）；
  - LIKE 必须显式写 ESCAPE '\'：Postgres 默认拿反斜杠当转义符，SQLite
    不写就没有转义符——原来的写法在单测里静默失效，搜 "100%" 命中 0 条。
    顺带把 ILIKE 换成 LOWER()+LIKE，这段才能被内存库覆盖。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 13:51:59 +08:00
Blizzard 5e5f6e9610 feat(billing): 人工退款入口 —— paid 单冲销积分+置 refunded(幂等) 
PAYMENT_DESIGN §5 承诺却只留了 OrderRefunded 常量、无入口。补齐全链路:

- store.RefundOrder:订单 CAS(paid→refunded) 为主闸(重复退 changed=false 幂等),
  同事务记 adjust 负分录(ref=订单号)+ 回退物化余额。照抄 MarkOrderPaid 双闸范式;
  新增 idx_ledger_refund_ref 部分唯一索引(kind='adjust' AND ref<>'')做账本级兜底,
  与 grant 索引对称、不与 admin 手工校正(ref 空)冲突。
- 积分若已消费,回退后余额可为负(人工退款预期,账本仍自洽,后续消费被硬拦截)。
- handler AdminRefundOrder + POST /admin/orders/:id/refund(admin 组已挂 Audit 留痕);
  真渠道钱款原路退回需 admin 另在商户后台操作,本地仅冲销积分与订单态(不接自动退款 API)。
- admin 订单流加「退款」按钮(仅 paid 单可见,二次确认+填原因)。
- 测试:RefundOrder 冲销+幂等、只退 paid 两个不变量测试(sqlite 真 DB,余额=账本之和)。
  gateway build/vet/test 全绿,admin tsc 干净。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-18 13:35:31 +08:00
Blizzard bff6e5c7fd test(gateway): 补上「钱路径」与租户隔离的回归测试 —— P0 最高优先级缺口 
完成度审计(见记忆 completion-audit)最尖的一条:涉及钱的路径此前 0 测试,
支付一上线 bug=真实错账;租户数据层隔离也只测了角色门禁没测数据层真隔离。
把本会话 live 手验过的断言固化成回归测试。

测试基建:纯 Go sqlite(glebarez,无 CGO)内存库,迁同款模型+建部分唯一索引+
挂租户作用域回调,复用生产 store 方法测真逻辑。CI ubuntu 无 Postgres 也能跑
(此前 store 测试全是纯逻辑,DB 事务逻辑从没进过关卡)。

钱路径不变量(6):
- GrantCredits 记分录+增余额,余额恒等于 SUM(ledger)
- 兑换码核销一次性(CAS)+原子入账,重复核销余额纹丝不动
- 账本(kind,ref)部分唯一索引:重复 grant 被兜底拦下、usage 不受约束
- MarkOrderPaid CAS 幂等:重复回调 changed=false 不重复入账
- SaveUsageEvent task_id 幂等:同任务重投不重复扣费
- ReconcileOrders 抓出 order_without_ledger(钱到了积分没给)

租户隔离(3):创建自动填 tenant_id、查询按 ctx 租户过滤、跨租户改/删命不中、
WithoutTenant 系统视角全可见。

go build/vet + 全 gateway 测试全绿;sqlite 仅测试引用,不进生产二进制。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-18 11:39:36 +08:00