|
|
@@ -516,6 +516,71 @@ separate project (M15).
|
|
|
|
|
|
---
|
|
|
|
|
|
-**Next step:** start W1 (cert-manager + CA). If we have 2
|
|
|
-engineers, W4 UI work starts as soon as M13b W1 (Companies CRUD)
|
|
|
-is done — the cert UI is a Sources incremental.
|
|
|
+## 10. Addendum (2026-06-16) — execution ordering: M14-backend before M13
|
|
|
+
|
|
|
+**Decision (option A, confirmed by user):** M14 is split into two
|
|
|
+execution phases that decouple from M13:
|
|
|
+
|
|
|
+| Phase | Workstreams | Type | Runs when | Estimates |
|
|
|
+|---|---|---|---|---|
|
|
|
+| **M14-backend** | W1 + W2 + W3 + W5 + W6 | Backend (K8s + Go + PromQL + smoke) | **Before M13a.** Parallel with M13a. | 13-18d |
|
|
|
+| **M14-ui** | W4 | Frontend (Vite + React) | **Inside M13b W2** (Sources module), as a feature incremental | 3-5d |
|
|
|
+
|
|
|
+**Why split:** user wants all backend work finished before the
|
|
|
+frontend. 5 of 6 workstreams are backend-only; W4 is the only one
|
|
|
+that touches the UI. M14-ui becomes a feature of the Sources module
|
|
|
+in M13b, not a standalone milestone.
|
|
|
+
|
|
|
+**Updated sequencing:**
|
|
|
+
|
|
|
+```
|
|
|
+M12 W1 (K8s) ─┬─▶ M14-backend W1 (cert-manager) ─▶ M14 W2 (ingestd mTLS)
|
|
|
+ │ │
|
|
|
+ │ ├─▶ M14 W3 (gRPC mTLS)
|
|
|
+ │ │
|
|
|
+ │ └─▶ M14 W5 (rotation + alerts) ─▶ M14 W6 (smoke)
|
|
|
+ │
|
|
|
+ └─▶ M13a W1 (authd) ─▶ M13a W2-W4 (web shell + JWT gate)
|
|
|
+ │
|
|
|
+ └─▶ M13b W1 (Companies) ─▶ M13b W2 (Sources + M14-ui W4) ─▶ M13b W3 (Telegram) ─▶ M13c
|
|
|
+```
|
|
|
+
|
|
|
+**What this means for M13 plans:**
|
|
|
+
|
|
|
+- `M13b_PLAN.md` W2 (Sources CRUD) grows by ~3-5d to include the
|
|
|
+ cert lifecycle UI (M14 W4). The cert UI is a new tab in the
|
|
|
+ Source detail page.
|
|
|
+- `M13c_PLAN.md` is unchanged (no cert work needed there).
|
|
|
+- `M14 W4 exit criteria` move into `M13b_PLAN.md` W2 as a
|
|
|
+ sub-section.
|
|
|
+
|
|
|
+**What this means for M14-backend:**
|
|
|
+
|
|
|
+- W1-W3, W5, W6 ship as **M14-backend** with its own
|
|
|
+ `M14_BACKEND_VERIFICATION.md` and a SPEC.md row flip.
|
|
|
+- M14-backend is independent of M13a. Both can run in parallel
|
|
|
+ after M12 W1 lands.
|
|
|
+- M14-ui ships as part of M13b; no separate verification doc.
|
|
|
+
|
|
|
+**SPEC.md M14 row should be split** into:
|
|
|
+
|
|
|
+- `M14 (backend)` — mTLS opt-in per source + cert-manager +
|
|
|
+ rotation + alerts + runbook + smoke. Targets: enterprise
|
|
|
+ technical controls.
|
|
|
+- `M14 (ui)` — Cert lifecycle UI in Sources module. Ships as
|
|
|
+ part of M13b.
|
|
|
+
|
|
|
+**Exit criteria (whole M14, both phases):**
|
|
|
+
|
|
|
+- [ ] M14-backend: `make m14-smoke` green for 3 consecutive runs
|
|
|
+ (the existing W6 smoke, unchanged).
|
|
|
+- [ ] M14-backend: M14_VERIFICATION.md published.
|
|
|
+- [ ] M14-ui: cert UI ships inside M13b, covered by M13b smoke +
|
|
|
+ Playwright E2E (M13c).
|
|
|
+- [ ] SPEC.md rows: `M14 (backend)` and `M14 (ui)` both flipped
|
|
|
+ to ✅ shipped.
|
|
|
+- [ ] Runbook reviewed by 2 people.
|
|
|
+- [ ] No regression on M11 / M12.
|
|
|
+
|
|
|
+**Next step:** start M14-backend W1 (cert-manager + CA). M13a W1
|
|
|
+(authd) can start in parallel.
|