What T-Rex did

• T-Rex produced a finding-comment-proof for a posted P1 finding and attached the supporting text artifact.
• T-Rex produced a second finding-comment-proof for another posted P1 finding.
• T-Rex authored and executed a script to validate Cedar custom object docs, captured a successful exit, and noted the exact documentation and code locations involved.

_{Ran code and verified through T-Rex}

1. General comment

   Custom-object documentation claims unsupported multi-object, non-Deals routing, and bidirectional write behavior

   • Bug
     • fields-and-values.md:351-360 says customObjectConfig supports multiple synced objects, lets each route to its own AOP, and bidirectionally syncs mapped fields to Salesforce. cedar-system-knowledge.md:303-305 repeats the non-Deals routing assertion. The executed validator refuted every claim: the runtime Zod schema accepts one config object but rejects a two-object array; the custom-object query explicitly filters agentOperatingProcedures.name to AopName.Deals; and the only custom-object operation fetches records then persists them in integrationMetadata.customObjectRecords. The outbound workflow instead updates crmIntegration.dealId through updateOpportunityFields and contains no custom-object configuration, records, or fetch path.
   • Cause
     • The docs describe capabilities that are not represented by the single-object configuration schema or connected to the implemented sync and outbound write paths.
   • Fix
     • Replace the cited documentation with the implemented behavior: one optional Salesforce custom-object config per connection; it enriches Deals-AOP conversations by reading records keyed by object_name into integration metadata; it neither chooses an AOP nor writes custom-object fields back to Salesforce. If the intended product behavior is the documented one, implement an array/object-to-AOP configuration and a custom-object outbound-update driver path before documenting it.

   _{<a href="https:/}