Let a site keep its own proven contact form

Context and Problem Statement

ADR-0024 and ADR-0031 gave every site one contact form: the package’s ContactForm, posted to the site’s own /contact/ and relayed by the Worker to the group’s CRM (Salesforce Web-to-Lead), with a honeypot instead of a third-party captcha. akribis.info already has a form that works: it posts from the browser straight to Salesforce Web-to-Lead with its organisation, its return address, its lead source, Google reCAPTCHA and the standard and custom fields Comercial reads every day (industry, country, Area__c, Nivel_Jer_rquico__c, Motivo_de_contacto__c, Interno__c). Rebuilding that site on the package swapped it for the shared form and the relay, which changed what Salesforce receives: other names, no industry and country, no reCAPTCHA.

The decision of 2026-10-07 (Demian Montes de Oca, akribis.info decision 26): “the form shouldn’t have changed; what we have now is what works and pushes the leads to Salesforce.” How does a site on the package keep a form that is proven in production?

Decision Drivers

Criteria 1 (trust: a lead that reaches the CRM is worth more than a uniform form) and 9 (generated and tested) of ADR-0009; ADR-0031 (the shared layer is one package, and a site adds its own layer to it).

Considered Options

• contact.form: the site names its own form component; the package renders it wherever it renders the contact form, and mounts no relay for that site
• Make the shared form configurable enough to reproduce akribis.info’s (its action, its hidden fields, its captcha, its option lists)
• Let the site override the shared pages one by one

Decision Outcome

Accepted: the first option.

• The shared form stays the group’s default. A site that names nothing gets ContactForm and the Worker’s relay, as before.
• A site may name its own. akribis({ contact: { form: "./src/views/ContactoForm.astro" } }): an .astro file, from the project’s root. The package resolves virtual:akribis/contact-form to it, and every place that renders the form imports that module: the shared contact page, the home’s contact section, a contact page of the tree, and the starter’s shared pages. The component receives { locale, quote } (quote: what ?quote= named, as the server read it).
• No relay for it. With its own form the site posts where its form posts: the integration does not mount /contact/, and contact.fields and contact.leadSource are refused next to contact.form, since they configure the shared form and its relay.
• The quote list stays the package’s. Product pages and the configurator keep writing it to sessionStorage (akribis-quote, components/quote.ts); the site’s form reads it and sends it in the form its CRM expects.
• The standards still apply to the page. The checker reads the own form like any other markup (labels, autocomplete, naming, voice). Two things it does not object to today, and that the own form of akribis.info needs, are recorded here so that a future rule keeps them narrow: the reCAPTCHA script from https://www.google.com/recaptcha/ (not a host in consent.needs_consent: it protects the form, it does not measure the visitor) and a form action at https://webto.salesforce.com/ (no rule reads form actions). A rule that would flag either must allow exactly those two prefixes for a site whose contact.form posts there, not exempt the site.

Consequences

• Good, because a lead form that works in production is not rebuilt for uniformity: Salesforce receives the same request for the same input.
• Good, because the shared pages, the home and the tree’s contact pages keep one layout; only the form inside them is the site’s.
• Bad, because the site’s form is the site’s to maintain: the group’s honeypot, the relay’s validation and the shared labels do not reach it.
• Neutral, because a site can move to the shared form later by removing one line from its config.