docs(forms): record Form A unique-name and locale verification

2026-10-25 13:37:01 -07:00
1 parent f41af1966e
commit 63806f106c
@@ -0,0 +1,75 @@
 # P9-03 Form A — Jotform field-key and multilingual runtime verification
 **Recorded:** 2026-10-25 · **Scope:** Form A only · **Evidence:** owner-reported Builder screenshots and manual browser checks, with form identity corroborated by the connected Jotform form metadata.  
 **Status:** partial configuration/runtime verification; **not approved for production embedding, submissions, or analytics**.
 This report adds implementation evidence to [P9-03 integration plan](phase-9-jotform-implementation-plan-2026-10-18.md) and [contract v1.2](phase-9-jotform-integration-contract-2026-10-18.md). It does not change the approved three-form architecture, close any JF/OA gate, or amend historical inventory evidence. No submitted answers or PHI were inspected.
 ## Form identity and availability
 - New blank-built form: **AIA | Website | General Enquiries**; Jotform form ID `262946078314059`.
 - Builder: `https://hipaa.jotform.com/build/262946078314059`.
 - Hosted form: `https://form.jotform.com/262946078314059`.
 - Form was **enabled temporarily for browser inspection**. This is not approval to collect public leads; its availability should be restricted/disabled outside authorized testing until notification, privacy, and acceptance gates are cleared. Do not infer current status from this dated report.
 - The legacy `250727122848156` form remains historical reference only. **Forms B and C have no approved form IDs or embed destinations yet.**
 - The four campaign landing pages remain **permanently assigned to Form B**. Any Form A compact rendition there is a temporary, non-submitting Astro review mock, not an authorized live Form A integration.
 ## Critical discovery: visible label is not the URL-prefill key
 Jotform's **Build → select field → Advanced → Field Details → Unique Name** value governs URL prepopulation. The visible question label `formContext` did **not** imply its underlying unique name was `formContext`. Initially the field retained its generated default unique name, so `?formContext=contact` failed to override the `landing` default and did not show the contact message.
 The owner set **Unique Name** explicitly to the case-sensitive value **`formContext`**. Subsequent browser inspection confirmed the contact-specific message became visible. This property must be independently inspected for every future context field; do not derive URL keys from question labels, numbers, internal HTML IDs, or semantic TypeScript names.
 | Configuration | Current Form A specification |
 |---|---|
 | Label | `formContext` (not visible to visitors) |
 | **Unique Name** | **`formContext` (case-sensitive, owner verified)** |
 | Default value | `landing` |
 | Required | No |
 | Visibility | Hidden from visitors |
 | PHI marking | Owner reports all Form A fields PHI-protected; verify any fields subsequently added before activation |
 | Approved presentation keys | `contact`, `landing` only in initial Astro placement contract |
 | Optional future conditional state | `inquiry`, existing Builder rule; not approved for an actual published placement |
 | Security significance | Presentation hint only, not authorization or trusted attribution |
 Use only controlled non-identifying literal contexts selected by Astro. Do **not** forward arbitrary page query parameters, UTM values, visitor details, clinical data, or raw referrers into Jotform. Values are client-modifiable; never authorize sensitive behavior based on them.
 ## Owner-verified browser behavior
 | Check | Result reported on 2026-10-25 |
 |---|---|
 | Hosted `?formContext=landing` | Compact fields displayed; no message text area |
 | Hosted `?formContext=contact` | Contact message **How Can We Help?** and its privacy sublabel displayed; enquiry category absent |
 | Preferred Contact Method | Phone and Email radio choices present after correcting an unintentionally enabled *Hide Field* toggle |
 | Preferred Contact Method = Email | Email Address becomes required; selecting Phone leaves Email Address optional; phone remains required |
 | Español | Spanish language added to Form A; owner reports language presentation verified |
 These are owner-reported interactive checks, **not verified accepted submissions**, delivered email tests, or comprehensive translation/accessibility certification. In particular, the complete validation-message/confirmation translations and iframe-specific locale behavior still require acceptance testing.
 The **How Can We Help?** label was shortened to that exact question, while its field sublabel now reads: “Please do not include medical details, diagnoses, insurance member identifiers, or other sensitive information.” The sublabel travels with the conditionally displayed message field. The condition is **SHOW** the message when `formContext = contact` **OR** the optional enquiry-category selection is `General Question`. Enquiry-category visibility is restricted to the unapproved `inquiry` context. Keep both independently verified during future condition edits.
 ## Honeypot, style and nonproduction notes
 - Separate field `websiteCheck` was created for a basic, hidden, optional, empty honeypot. Builder conditions visibly show **IF websiteCheck IS FILLED → DISABLE Submit**. This is not proof of server-side spam rejection, nor a replacement for vendor anti-abuse protections. Confirm the field's precise unique name, hidden status and PHI classification before live acceptance.
 - The owner installed form-specific Jotform Custom CSS and visually confirmed cream-colored inputs and AIA orange Submit button. Exact live selectors and style equivalence to Astro still need comparison; CSS cannot style a cross-origin iframe from Astro's parent document.
 - A locally generated `www/integrations/jotform/README.md` and `aia-form-a.css` were **not present on the pushed `faithful-astro-migration` branch at the time this report was authored**. Do not recreate or overwrite those Codex-owned uncommitted files through this PR. When they are committed, reconcile this verified `formContext` unique-name requirement and the actual installed CSS with that README.
 ## Future Forms B and C — explicit prefill contract required
 For any page/placement/service-context field added to Forms B or C, record and manually verify **all** of the following before authorizing live embedding:
 1. The exact Jotform form ID and Builder field label.
 2. The exact, **case-sensitive** `Advanced → Field Details → Unique Name` value (do not guess).
 3. Allowed fixed, non-identifying URL-prefill values and the value for missing/invalid context.
 4. Required/hidden/default/PHI behavior and effects of **Clear Hidden Field Values**.
 5. Show/hide/require conditions, their precedence, and no accidental hiding of required contact fields.
 6. Browser proof for each intended context and EN/ES locale, both direct hosted and iframe.
 7. Compatibility with honeypot and Submit-button behavior; no untrusted UTM/source forwarding.
 The values for B and C are **TBD**, not automatically `formContext`. The URL parameter for Form A is verified; applying that convention to another form requires its own Builder unique-name inspection.
 ## Still pending
 JF-01–JF-09 and owner-approval gates remain open until their **full scopes** are verified, including the actual notification recipients/content/attachments/reply-to, bilingual autoresponders and confirmations, third-party integrations/webhooks, security and retention settings, accepted synthetic submissions, honeypot behavior, iframe height/focus/mobile behavior, and clinical/privacy/release approval.
 **No real PHI, live production embed, production tracking, or Jotform submission is authorized by this documentation update.**