Summary

A field-propagation primitive: lets an admin see, across every rep linked to an org AOP, which fields/mappings match the org default vs. have drifted vs. are missing entirely, and push updates to many reps at once without a blind overwrite. Design doc: apps/server/docs/design/field-propagation-primitive.md.

1. Unify the CRM-mapping write path (closes a pre-existing bug). Two paths wrote connection.metadata.fieldMappings and diverged: config-write's link-mapping action ran live CRM introspection + option reconciliation for select/list fields, but connection-write's update_crm_field_mappings never did , a simple mapping onto a select/list field written through connection-write silently skipped reconciliation. writeCrmFieldMapping() (services/integrations/crm/field-mapping-writer.ts) is now the one function both paths call; linkMapping() is a thin wrapper over it with its external contract and existing tests unchanged. Mapping validation now runs before option reconciliation commits, so a failed mapping write (e.g. op:'add' on an existing mapping) can never leave a field's options mutated.

2. Rollup read mode on list-fields. listFields() gains targetUserIds/rollup params for viewing many reps' field configs at once instead of one call per rep, via two new pure comparison functions (field-diff.ts's diffFieldAgainstOrgDefault/rollupFieldsAcrossUsers, field-mapping-diff.ts's diffMappingAgainstReference). Wired through config-read-tool.ts's list-fields action with an authorize() gate for cross-user targeting.

3. config-propagate , new MCP tool, propagate-field/propagate-mapping. Admin-only, service-layer functions kept free of any Mastra dependency (services/aop/propagate-field.ts, services/aop/propagate-mapping.ts) so a future UI can call them directly. Uniform/missing targets apply immediately; a target that genuinely diverges from the source is refused with the diff attached unless force: true, which routes it through the same runMutation/proposed-card mechanism every other config-write action already uses , an explicit per-target Slack Accept, never a blanket approval across reps.

Two real security/correctness issues found across two review passes, both fixed on this branch (not left as follow-ups):

• Cross-tenant aopId gap (self-review): an org-scope authorize() verdict alone only proves the caller administers some organization , it never sees the client-supplied aopId. Added a callerOrgId row-binding check in list-fields.ts's loadOrgContext that refuses when the AOP's actual owning org doesn't match the verdict's org.
• Cross-tenant data leak via explicit targetUserIds (caught by Greptile, verified independently before fixing): the AOP-definitions query was correctly org-scoped, but the connection and user-name queries inside loadPerUserFields were not , an admin naming a foreign-tenant userId in an explicit array got that user's real display name and a real slice of their CRM connection's mapping metadata back, via field-key overlap on shared built-in keys like status/dealValue. Fixed: every target is now validated against the caller's own orgOwnerId before any connection/name query runs; an invalid target is dropped entirely and reported via a separate invalidTargetUserIds, never blended into a "missing" rep.

Test plan

• pnpm exec tsc -p tsconfig.json --noEmit , clean
• pnpm deps:check , no dependency violations
• pnpm exec eslint on all touched source + test files , clean
• Scoped vitest across all touched/new test files , 593 passing, including:
  • field-diff.test.ts, field-mapping-diff.test.ts, field-mapping-writer.test.ts (new) , diff/rollup bucketing, reconciliation triggering rules, mapping-validation-before-reconciliation ordering
  • list-fields.test.ts , byte-for-byte single-user regression, rollup fixture, cross-tenant row-binding refusal, and the new