Summary

• The config agent's knowledge files did not mention the new per-connection dealWriteGuard (PR #2917) at all, and one claim became untrue: "the mapping and the push switch decide whether a field reaches the CRM" is no longer the whole story, because a matching guard now blocks the write per deal.
• cedar-system-knowledge.md: glossary row for dealWriteGuard, and the push-gates paragraph now names the guard as a third, per-deal gate, with the diagnostic ("mapped and push on, but never reached the CRM" can mean a guarded deal).
• external-writes.md: the "CRM push is automatic via the mapping" warning now points at the guard, and the connection-config list gains update_crm_settings with dealSyncFilter (which deals sync in) and dealWriteGuard (which deals are never written to): format, HubSpot-only, snapshot-based staleness, what a block does on each surface, how to set, clear (dealWriteGuard: {} + clearDealWriteGuard: true) and override a stale key cache (allowUnverifiedDealWriteGuardKeys), and to say which deals it will freeze before writing it.
• fields-and-values.md and diagnose-and-repair.md: the "field didn't update in the CRM" checks now include "does a dealWriteGuard match this deal", and say a guarded deal must not be retried.

Test plan

• pnpm --filter @zero/server exec vitest run src/mastra/skills/account-config: 13 files / 168 tests pass, including knowledge-claims-resolve.test.ts (every identifier I wrote resolves in apps/server/src) and the two splice tests.
• Generated blocks and their placeholders untouched. No resource description (routing catalog) was changed, so the routing suite was not re-run; it uses live model calls and could not have changed from body-only edits.
• Markdown only, no apps/server/src change.

Verify in prod

No runtime behaviour changes. To check the agent now knows about the guard, ask the config agent "why didn't a field reach HubSpot on a closed deal" on a connection with a guard set: the answer should mention dealWriteGuard.

Not done here (code, out of scope for this skill)

The tool descriptions the agent reads first still describe update_crm_settings as "sync toggles" only: connectionWriteTool in mastra/tools/config/connection-write-tool.ts (item 3), the tool-level description in applyConfigChangeTool.ts, and the external-writes catalog description in mastra/skills/account-config/index.ts. Adding the guard there is a separate code change and should be followed by a routing-suite run.

🤖 Generated with Claude Code

Confidence Score: 4/5

The documentation is generally safe to merge, with a non-blocking but actionable gap in how the agent can verify arbitrary per-deal guard matches.

Findings

1.  Guard Match Is Unreadable ▶

### Issue 1
apps/server/.claude/skills/cedar-configuration/diagnose-and-repair.md:114
The prescribed `get` and `read-connection-settings` reads cannot determine whether an arbitrary `dealWriteGuard` matches this deal. `get` exposes the linked deal and limited display fields such as open/closed state, while the guard evaluates arbitrary properties from a separate last-synced snapshot that nei