# CRM recovery findings, revision 4

Status: bounded recovery completed, full 32-criterion goal remains PARTIAL. No production bridge change was deployed in this revision. The current accepted count remains 8/32.

## What was established

- Native CRM access works. The existing same-tenant browser session returned HTTP 200 for the observed native edit route and opened diagnostic card 1916. The public AuthToken key was rejected when supplied as native Bearer credentials, while the existing native session worked. The sole cause of the earlier 401 is not independently established. No token was printed, saved or installed in production. [Sanitized native proof](r4-native-route-readback.json), [earlier native write/control receipt](crm-native-url-readback.json), [earlier public source49 write/read controls](url-encoding-correction-v5.json).
- The earlier claim that date fields 5/40/41 and boolean 47 contained actual stored 1970/false defaults was incorrect. Raw v2 detail values are null. Native date values are empty strings and boolean 47 is null. The separate formatted custom-fields response renders those nulls as 1970-01-01 and false. No cleanup write is justified by that formatting artifact. [Raw versus formatted comparison](r4-native-storage-comparison.json).
- Diagnostic 1914 remains explicitly synthetic, linked to QA partner 3703. Its source49 retains the normal URL. The prior whole-form save created extra null rows. The remaining 23 unused empty-versus-null differences are a parent-selected fixture preference, separate from the source URL business requirement and historical lead recovery. No second whole-form save, delete or recreation occurred.
- One standard JSON Unicode escape probe changed only diagnostic memo46, keeping required name/category unchanged. The wire used `\u0026`, decoded to the exact logical `&`, and the v2 PUT returned 200. Both raw detail and formatted readers still returned literal `&`. Source49 and every other custom/top-level field were unchanged. [Probe](r4-json-hex-amp-probe.json).
- The vendor's released Contact Form 7 plugin supports the AuthToken JSON route `POST /api/v2/cf7/send/module/{module_id}` and metadata `GET /api/v2/cf7/fields/module/{module_id}`. Current tenant metadata exposes source49 with its existing slug. The valid types are module, modulepartner and partner. There is no documented existing-object selector or narrow native service-token lifecycle. [Official released source](https://plugins.svn.wordpress.org/qlickcrm-integration-for-contact-form-7/tags/1.0.0/QLICKCRMFunctions.php), [documentation investigation](vendor_raw_storage_recovery.md).
- One create-path diagnostic exercised that supported route. HTTP 200/data ok created exactly one matching request, 1916, with no partner or website submission. Raw v2 storage, formatted response, native edit response and the opened card all contain literal `&` instead of the supplied normal `&`. It therefore does not provide the needed raw writer. [Exact probe](r4-cf7-writer-probe.json), [opened card proof](r4-native-route-readback.json).
- The supported `modulepartner/1` variant was then tested once with a fresh controlled QA address. HTTP 200/data ok created one labelled request 1917 and QA partner 3705, correctly linked, newsletter false. Raw-detail and formatted response again contain literal `&`. This resolves the independent review's additional candidate without altering an existing customer/partner. [Variant probe](r4-cf7-modulepartner-probe.json), [opened variant card](r4-modulepartner-opened-card.json).

These are API-observed persistence and opened-card results. No database-level CRM storage inspection was performed. The required specified reader/card behavior fails regardless of that internal distinction.

## Consequential method correction

The earlier existing-card-only test method was parent-selected, rather than a restriction in Matt's business requirements. The supported CF7 routes create requests, matching the actual production path. Root tested one isolated labelled unlinked diagnostic and one isolated labelled controlled-QA partner variant, each with an attempt lock and exact-name reconciliation. No guessed update flag, existing customer/partner change, deleted data or extra credentials were involved. Both routes failed the same raw-storage requirement, so production was not switched to either.

## Remaining boundaries

1. **Provider capability:** The tested public object writer and official CF7 module/modulepartner routes do not preserve the exact URL string in the specified API readers/card. Native editing has preserved it on 1914, but a supported repeatable authentication lifecycle and narrow production writer have not been established. This is an observed limitation of the tested routes, not proof that every possible vendor route is impossible. A sanitized reproduction and an UNSENT vendor question are prepared. [Minimal reproduction](r4-vendor-reproduction.md), [UNSENT support draft](r4-vendor-support-draft-unsent.md).
2. **Pending human action:** The existing CAPTCHA/binding-acceptance request is still unanswered. It has not been asked again. Prepared form tab 12 is retained, unsubmitted, for that action. The actual staff mailbox request is owned by the parent and is also pending. No SMTP transport or other inbox was used as a substitute.
3. **Full acceptance:** Real protected website source/placement, partner, notification, duplicate, newsletter and chat cases remain unproved. No new combined criterion is promoted. Existing UI, negative and regression components remain valid on their current scopes.

## Changed state and recovery

Created diagnostic request 1916 through the official CF7 module route, partner null, and 1917 through modulepartner, linked to newly created QA partner 3705. All labels/descriptions clearly identify synthetic diagnostics. Updated only synthetic memo46 on 1914 for the Unicode probe. There were no native write calls, no existing customer/partner changes, no customer/lead messages, no explicit mail-send calls, no production code/provider changes, and no security changes. Vendor internal notification delivery for these API diagnostics was not checked and is not claimed absent.

Full outbound/readback snapshots and the one-attempt locks remain privately under `/Users/agency/.local/share/analit-recovery/unified-20260930/url-encoding-v5/`, mode 0600. Synthetic records were retained, rather than deleted. The production bridge remains SHA `6596cab128f6a55dced39ab27b919222f207d09ca5d431bc8029e0d71faba7c9`. The earlier website CSS deployment and verified recovery fixture remain unchanged.