Add real signer fields to templates, documents, and the client portal

[jusso-dev]

Context

ScopeStack has typed/drawn acceptance and template signer-field metadata, but it does not yet provide true document-bound signing fields in the client portal/PDF flow.

DocuSign and PandaDoc-style tools treat fields as first-class objects: signature, initials, name, date, checkbox, text, and role-specific required fields. This is the largest gap between ScopeStack and a mature e-signature workflow.

Goal

Add real signer fields that can be defined on templates/documents, assigned to a recipient role, completed in the client portal, validated before acceptance, and rendered into the final PDF/evidence record.

Scope

• Define persistent signer fields at template-version and document level.
• Support at minimum:
  • Signature
  • Initials
  • Name
  • Email
  • Date signed
  • Text input
  • Checkbox
• Assign each field to a recipient role or specific recipient.
• Mark fields as required or optional.
• Render required fields in the client portal before a recipient can accept/sign.
• Persist completed field values with signer, timestamp, IP, and user agent context.
• Include completed fields in generated PDFs and audit/completion evidence.

UX Notes

• Sender should be able to see which roles/fields are required before sending.
• Recipient should see a clear checklist of required fields.
• Missing required fields should block acceptance with inline errors.
• Avoid a full PDF coordinate editor initially if too large. A structured field block tied to template sections is acceptable for v1.

Data/Architecture Notes

Potential models:

• DocumentSignerField
  • documentId
  • recipientId nullable or recipientRole
  • fieldType
  • label
  • required
  • sectionId or sectionRef
  • order
  • optional coordinate metadata for future PDF placement
• DocumentSignerFieldValue
  • fieldId
  • recipientId
  • value
  • signedAt
  • ipAddress
  • userAgent

Acceptance Criteria

• A template can define signer fields.
• A document generated from that template carries those fields forward.
• A recipient can complete their assigned fields in the client portal.
• Required fields prevent acceptance until completed.
• Completed field values are visible in the final document/PDF evidence.
• Audit logs record field completion and final acceptance.
• Existing typed/drawn acceptance continues to work for documents without explicit fields.

Dependencies

• Recipient routing issue should inform per-recipient field availability.
• Completion certificate issue should consume completed field data.

Priority

P0. This is foundational for competing with DocuSign/PandaDoc-style signing.