task-l.3.1

docs/security/team-scope-limitations.md

@@ -0,0 +1,41 @@
+# Team Scope Limitations
+
+## Current Team Scope Logic
+
+Current CRM authorization resolves the most permissive ownership scope from active CRM role assignments.
+
+For `team` scope today:
+
+- quotation visibility is effectively broader than `own`, but still constrained by branch scope and product scope
+- customer visibility is approximated from branch scope plus related enquiry/quotation relationships
+- approval visibility inherits quotation visibility or current approval-actor visibility
+
+## Known Limitations
+
+There is not yet a first-class team hierarchy model in the domain.
+
+That means the system does **not** currently know:
+
+- who reports to whom
+- which sales users belong to the same explicit team
+- whether a manager should see one subset of sales users but not another inside the same branch
+
+Because of that, `team` currently behaves as an approximate operational scope rather than a strict org-chart scope.
+
+## Contact Sharing Limitation
+
+The production schema currently has no persisted contact-sharing table.
+
+Result:
+
+- contact visibility is enforced through customer ownership plus contact creator visibility
+- mock/demo shared-contact behavior from legacy demo data is not part of the production boundary yet
+
+## Future Team Hierarchy Model
+
+Recommended future direction:
+
+1. add a first-class manager/team relationship model
+2. resolve `team` scope from that relationship instead of permissive approximation
+3. add explicit contact-sharing persistence if the business still requires cross-owner contact access
+4. expand runtime security fixtures around manager-team boundaries after real hierarchy data exists