|
|
22f329cdf3
|
docs(architecture): DB 規劃淡化測試占比強調
測試是工時的自然組成，不再特別強調占比 / 與業界對照：
- 移除前言「測試占比」獨立小節，併入估算假設（中性敘述）
- §5 標題去掉「測試占比分析」，§5.3 精簡為各塊測試 hrs 明細
- 移除「約 45% vs 業界 25-35%」對照句
- 保留實用建議（要砍先砍邊界、別砍 integration 與回歸）
工時數字全未動。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-06-16 20:20:11 +08:00 |
|
|
|
46958200eb
|
docs(architecture): DB 接入規劃補 MySQL 版本估算 + 文件修訂
- 新增 §3.5 MySQL 版本估算（並列補充、不改 PG 版數字）：
MySQL 三範圍 9.2–15.7 / 18.3–31.4 / 24.6–42.5 人天，比 PG 約 +13%（中位）
delta 主來源：model array 欄位→JSON 序列化、driver/migration/testcontainers 換、
UUID + partial index 替代、交易隔離級別差異驗證；Redis delta=0
含「該不該換」中立建議（由維運能力與組織標準主導）
- 移除 130 上其他專案 DB container 的具體名稱（保留「不該共用、用獨立 DB」結論）
- 測試占比敘述改為「接 DB 的客觀測試需要」（integration/邊界/回歸），數字未動
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-06-16 20:15:01 +08:00 |
|
|
|
d41a57097f
|
docs(architecture): DB 接入工時規劃 — man-hours/man-day 估算文件
visionA backend 從 in-memory 接資料庫的規劃與工時估算（規劃，未實作）。
範圍與工時（三種）:
- 最小可行（只 model）: 7.8–13.5 人天
- 持久資料（model+device+pairing/token）: 16–27.4 人天
- 完整（+ session→Redis + 韌性）: 22–37.7 人天
關鍵結論:
- DB 由他人在 stage docker host(192.168.0.130)開好並提供連線，visionA 端不 provision
- ~80% Go 端工作（repository/migration/測試 via testcontainers）拿連線前就能開工，
等 DB 只卡最後 1.5–4 天 stage 收尾
- 測試占比 ~45%（依需求刻意拉高、業界常態 25–35%）
DB 選型: Postgres（model/device/pairing/session_token）+ Redis（userSession；
tunnel session 因 yamux Handle 不可序列化維持 in-memory）。
含 Executive Summary（主管）/ 子任務 man-hours 明細（工程師）/ man-day 表（PM）三層視角。
過程草案保留於 .autoflow/04-architecture/（個人層）。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-06-16 20:01:21 +08:00 |
|
