Add ClickToSign component for click-to-sign attestation capture

[mikewolfd]

Motivation

Forms that require legal attestation, certification, or consent (e.g., government forms, grant applications, compliance filings) need a "click to sign" capability distinct from the existing drawn-signature Signature component. Click-to-sign captures a structured attestation record (who signed, when, what they agreed to) rather than an image attachment.

The existing spec already has supporting infrastructure:

• Signature component (drawn signature, stores attachment) — Component Spec Section 6.8
• attestation.captured ledger event — Respondent Ledger Spec Section 8.2
• "signature" widgetHint for attachment fields — Core Spec Section 4.2.5.1
• Certification pattern in the comprehensive example (Toggle + ConditionalGroup + Signature)

What is missing is a first-class component that captures a structured attestation — not a drawn image, but a record of consent: who clicked, when, what statement they attested to, and whether they accepted.

Design Decision

Model click-to-sign as a group-based pattern with a new Progressive component, not a new core dataType. This keeps the data model transparent (each attestation field is a normal field usable in FEL, mapping, validation) and requires no core spec changes.

Data Model (Definition side)

A click-to-sign field is authored as a group with structured children:

{
  "key": "certification",
  "type": "group",
  "label": "Certification",
  "children": [
    { "key": "accepted", "type": "field", "dataType": "boolean" },
    { "key": "signedBy", "type": "field", "dataType": "string" },
    { "key": "signedAt", "type": "field", "dataType": "dateTime" },
    { "key": "statement", "type": "field", "dataType": "string" }
  ]
}

Data Model (Response side)

{
  "certification": {
    "accepted": true,
    "signedBy": "Jane Doe",
    "signedAt": "2026-03-31T14:30:00Z",
    "statement": "I certify that the information provided is true and correct to the best of my knowledge."
  }
}

Component (Tier 3)

A new ClickToSign Progressive component that renders this group as a single attestation UX:

{
  "component": "ClickToSign",
  "bind": "certification",
  "statement": "I certify that the information provided is true and correct.",
  "buttonLabel": "Sign & Certify",
  "showTimestamp": true,
  "showSignerName": true
}

Fallback: Stack containing a Text (statement), Toggle (accepted), and readonly TextInputs for signedBy/signedAt.

Validation

Standard bind constraints work naturally:

• required on the accepted child enforces that the attestation must be completed
• constraint on the group can enforce that $accepted = true before submission
• Shape rules can cross-reference attestation fields with other form data

Mapping

Each child field maps independently through the existing mapping DSL — no special handling needed.

Audit

The existing attestation.captured respondent ledger event type covers the audit trail. Implementations SHOULD emit this event when the sign button is clicked.

Delivery Slices

• 1. Spec: Add ClickToSign to component specification — Define the component in the built-in catalog (Section 6.x), add to the compatibility matrix, define props, rendering requirements, and fallback behavior. Add "clickToSign" as a valid widgetHint for groups.
• 2. Schema: Add ClickToSign to component.schema.json — Add the $defs/ClickToSign entry, add to the AnyComponent union, define props schema.
• 3. Schema: Add "clickToSign" widgetHint guidance to definition schema — Document that groups with the clickToSign widgetHint expect the structured children pattern.
• 4. WebComponent: Implement ClickToSign behavior and rendering — Add useClickToSign behavior hook, implement the component in the default adapter, add to component registry.
• 5. Studio: Add ClickToSign to authoring palette — Add to the AddItemPalette, implement the group+children scaffolding in studio-core helpers, add to sample data generation.

Acceptance Criteria

• ClickToSign component is defined in the component spec with clear props, rendering requirements, and fallback rules
• Component schema validates ClickToSign nodes
• WebComponent renders a click-to-sign attestation UX that captures structured data into the group's children
• Core processors that do not support ClickToSign fall back to Stack + Toggle + Text inputs
• Existing FEL, validation, mapping, and audit infrastructure works without modification
• Studio can author click-to-sign fields through the palette

Open Questions

• Should signedBy be auto-populated from a host-provided identity context, or always manually entered?
• Should the component support a requireTypedName prop that requires the respondent to type their name to confirm?
• Should there be a revocable prop controlling whether the attestation can be un-signed after signing?