taks-d.2.1

docs/implementation/technical-debt.md

@@ -242,3 +242,58 @@ Future:
 - decide when direct signed URLs are acceptable versus mandatory server streaming
 - add response caching strategy for large artifact downloads
 - evaluate optional download-audit sampling if volume grows
+
+## After Task J.0
+
+### Missing lifecycle timestamps for KPI precision
+
+Task J.0 freezes KPI rules around `pipelineStage`, but the schema still lacks explicit lifecycle timestamps for stage conversion and closure events.
+
+Future:
+
+- add `convertedToOpportunityAt` for precise lead-to-opportunity timing
+- add `closedWonAt` for won-date reporting
+- add `closedLostAt` for lost-date reporting
+- backfill reporting logic to prefer explicit lifecycle timestamps over inference when available
+
+### Lost reason analytics
+
+Closed-lost semantics are frozen, but there is still no structured `lostReason` field for dashboard grouping and sales analysis.
+
+Future:
+
+- add `lostReason` to the CRM enquiry lifecycle model
+- define a controlled vocabulary or master-option category for loss analysis
+- expose lost-reason reporting only after the field is reliably captured
+
+### Default customer party role behavior
+
+Customer party definitions are frozen, but there is still no `defaultPartyRole` behavior to help normalize customer selection and reduce operator ambiguity.
+
+Future:
+
+- decide whether customers should carry a suggested default project-party role
+- add `defaultPartyRole` only if it improves data-entry quality without creating hidden automation
+- keep dashboard logic independent from this field until the model is formally introduced
+
+## After Task D.2.1
+
+### Unified project-party reporting projection
+
+Revenue attribution is now frozen, but the schema still stores enquiry and quotation parties in separate tables rather than a dedicated reporting projection.
+
+Future:
+
+- add a unified reporting view or materialized projection if dashboard/report queries become heavy
+- keep quotation-party precedence and enquiry fallback centralized in one service until that projection exists
+- avoid duplicating attribution logic in dashboard-specific code
+
+### Historical party snapshot fidelity
+
+Current revenue attribution uses live project-party relationships with quotation-first fallback behavior, but it does not yet provide effective-dated historical party snapshots for reporting.
+
+Future:
+
+- decide whether approved quotation snapshots or another immutable reporting snapshot should become the historical source of truth
+- define how reporting should behave if project parties change after quotation approval or after a won/lost outcome
+- add backfill or reconciliation tooling if historical party drift becomes a business issue