docs(plan): record dashboard plan approval

This commit is contained in:
2026-08-20 18:37:44 +03:30
parent 7487291df0
commit 505ae5c04f

View File

@@ -1,7 +1,7 @@
# Phase 2 Implementation Plan — Merchant Analytics Dashboard # Phase 2 Implementation Plan — Merchant Analytics Dashboard
- Status: Draft for human review - Status: Approved
- SDD phase: 2 — Plan - SDD phase: 2 — Plan approved; Phase 3 task generation authorized
- Capability: Merchant dashboard - Capability: Merchant dashboard
- Implementation authorization: Not granted - Implementation authorization: Not granted
- Task-list target after approval: `tasks/todo.md` - Task-list target after approval: `tasks/todo.md`
@@ -418,9 +418,9 @@ Every Phase 3 task must satisfy its acceptance criteria and the standing project
- The increment is an atomic Commitizen-style commit with no secrets or generated/build debris. - The increment is an atomic Commitizen-style commit with no secrets or generated/build debris.
- Human review occurs at named checkpoints and before merge/deploy. - Human review occurs at named checkpoints and before merge/deploy.
## 14. Phase 3 output after approval ## 14. Phase 3 output
After this plan is approved, create `tasks/todo.md` with one task per focused session. Each task will include: The draft Phase 3 list is recorded in `tasks/todo.md` with one task per focused session. Each task includes:
- One short outcome-focused title without combined independent concerns. - One short outcome-focused title without combined independent concerns.
- At most three testable acceptance criteria. - At most three testable acceptance criteria.
@@ -431,15 +431,18 @@ After this plan is approved, create `tasks/todo.md` with one task per focused se
No Phase 3 task may say merely “build the dashboard” or combine a foundation layer with multiple unrelated screens. No Phase 3 task may say merely “build the dashboard” or combine a foundation layer with multiple unrelated screens.
## 15. Decisions required to approve this plan ## 15. Approval record
1. Approve the overall build order and the hard rule that no implementation consumes `openapi.yaml` while its version remains `0.1.0-draft`. Approved on 2026-08-20:
2. Approve the draft API CSV defaults or send revisions: synchronous delivery; 100,000 rows; 50 MiB; 60 seconds; 3 requests/10 minutes with burst 1; UTF-8 BOM; ASCII `snake_case` headers.
3. Choose analytics/export audit retention for the hackathon. Recommendation: 30 days to match demo-auth retention unless finance/legal policy requires longer. 1. Build order and the hard rule that implementation cannot consume `openapi.yaml` while it remains `0.1.0-draft`.
4. Approve showing/exporting the existing opaque terminal reference, or require a separate display alias. 2. Synchronous CSV defaults: 100,000 rows, 50 MiB, 60 seconds, 3 requests/10 minutes with burst 1, UTF-8 BOM, and ASCII `snake_case` headers.
5. Supply the production Problem Details base URI and approve the Nginx deep-link/API proxy behavior. 3. Thirty-day analytics/export audit retention for the hackathon.
6. Approve `merchant.displayName` as the merchant name used throughout the shell and CSV preflight. 4. Display/export of the existing approved opaque terminal reference.
7. Approve the risk-spike approach for SSE, CSV delivery, and chart implementation before committing those dependencies/patterns. 5. `merchant.displayName` as the shell and CSV-preflight merchant name.
6. Early SSE, CSV-delivery, and chart risk spikes before committing their implementation patterns or dependencies.
Still external contract inputs: the production Problem Details base URI and the exact Nginx deep-link/static fallback plus `/api/v1` proxy behavior.
## 16. Official implementation references ## 16. Official implementation references