Factur-X client-side feasibility spike (PDF/A-3)

[ignromanov]

Part of #8 · Layer 3 (export) · 🟡 P3 spike-gated · spike → v1.6 merchant

What

Time-boxed feasibility spike: can spec-compliant Factur-X (PDF/A-3 + embedded factur-x.xml CII + XMP RDF) be produced client-side (zero-backend), or does it force a server step?

Finding driving the spike

Client-side Factur-X is NOT feasible on mainstream JS PDF libs — pdf-lib / jsPDF / pdfmake / react-pdf lack PDF/A-3 conformance, /AF + AFRelationship, and XMP RDF injection. Three candidate paths:

• B — pdf-lib low-level object hacking (~500–800 LOC, validator compliance uncertain)
• C — pdfium WASM (full PDF/A-3, but +10–30MB bundle)
• D — minimal stateless edge step (fastest; soft zero-backend trade-off — data transits, nothing stored)

Product decision this spike informs

Is zero-backend a hard constraint or a strong default for the PDF path?

Acceptance (spike)

• each path prototyped enough to judge validator compliance + bundle/effort cost
• recommendation with go/no-go per path
• decision recorded; merchant-track Factur-X unblocked or explicitly deferred

wiki: concepts/facturx-client-side-feasibility.md, concepts/factur-x-zugferd.md