task-c.1

docs/security/crm-access-enforcement-inventory.md

@@ -29,11 +29,11 @@
 ## High-Risk Findings
 
 1. Team-scope semantics are still coarse because the current model does not yet carry a first-class subordinate/team graph.
-2. Production contact sharing is not yet backed by a persisted sharing table; current enforcement covers creator/customer/admin visibility only.
+2. Contact sharing is now persisted, but team-scope still remains approximate because there is no first-class CRM team hierarchy.
 3. Enquiry services already enforce meaningful scope, but several route files still pass legacy role-shaped context instead of a dedicated security context object.
 
 ## Follow-up Focus
 
 - Normalize remaining enquiry routes onto the same security-context builder used by quotations and dashboard.
 - Add runtime seeded scenario tests once dedicated security fixtures are available.
-- Introduce a first-class team hierarchy and production contact-sharing model if the business requires them.
+- Introduce a first-class CRM team hierarchy if the business requires true team-based visibility.

docs/security/crm-authorization-boundaries.md

@@ -72,7 +72,7 @@ Contact visibility is enforced through customer visibility plus contact ownershi
 - if a user can access the parent customer, they can access its contact list within their role boundary
 - contact creators retain access to their own contacts
 - admin/organization scope retains access
-- production shared-contact persistence does not exist yet, so legacy demo sharing is not part of the live authorization boundary
+- production contact sharing is persisted through `crm_contact_shares`, so explicit share grants are part of the live authorization boundary
 
 ## Approval Boundary
 

docs/security/team-scope-limitations.md

@@ -22,14 +22,14 @@ That means the system does **not** currently know:
 
 Because of that, `team` currently behaves as an approximate operational scope rather than a strict org-chart scope.
 
-## Contact Sharing Limitation
+## Contact Sharing Status
 
-The production schema currently has no persisted contact-sharing table.
+The production schema now includes persisted contact sharing.
 
 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
+- contact visibility is enforced through customer ownership, contact creator visibility, and explicit contact-share grants
+- cross-owner contact access can now be granted and revoked without relying on demo/mock behavior
 
 ## Future Team Hierarchy Model
 
@@ -37,5 +37,5 @@ 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
+3. keep expanding security fixtures around owner/share behavior once a first-class team graph exists
 4. expand runtime security fixtures around manager-team boundaries after real hierarchy data exists