DS01 — El requisito de forma textual y la libre valoración de la prueba
Desencadenante S1
La socia única (marcador de posición E1 como empresario, organización
ORG-1) adopta una resolución de socios (GVB) — por ejemplo, la aprobación
de una compensación por gastos. Los estatutos exigen la adopción de
resoluciones en forma textual. E1 pregunta: ¿Puedo hacer eso en el
repositorio Git — y cómo debe verse una resolución que un auditor reconozca
después como "adoptada en forma textual"?
Lo que exige el § 126b BGB
§ 126b BGB (forma textual): "Si la ley no prescribe la forma escrita, sino que prevé la forma textual, la forma textual puede sustituirse por cualquier forma adecuada de transmisión electrónica, siempre que (1) la persona para la que está destinado el documento tenga acceso al documento mediante la dirección indicada por el destinatario, (2) el documento se haga accesible para otras personas y sea apto para su reproducción como texto literal en una pantalla, y (3) la persona que entrega el documento haya hecho reconocible de manera clara que el documento procede de ella, a fin de salvaguardar los intereses que representa."
Tres requisitos, tres interpretaciones de GitCover:
| § 126b BGB | Interpretación de GitCover |
|---|---|
| (1) Acceso mediante la dirección del destinatario | El repositorio tenant (Gitea) es la dirección; el destinatario (socio, GF) tiene acceso de lectura |
| (2) Accesible, reproducible como texto literal | El documento Markdown es texto literal — cat, Typora, cualquier navegador lo renderiza |
| (3) Atribución de origen ("reconocible como procedente de ella") | El documento de firma atribuye el documento de forma reconocible al firmante: nombre + rol + referencia de facsímil en un artefacto JSON anclado en SHA-256 (DS02) |
El punto (3) no exige una firma cualificada. Exige una atribución de origen reconocible: el destinatario debe poder reconocer quién entrega el documento. Exactamente ahí es donde intervienen el documento de firma (DS02) y el proceso de firma (DS03).
Libre valoración de la prueba (§ 286 ZPO)
Desde la perspectiva del derecho procesal civil, el documento en forma textual no es un acontecimiento sujeto a prueba estricta — queda sometido a la libre valoración de la prueba. El tribunal valora si los medios de prueba presentados "forman una convicción según la libre convicción". Es decir:
- No existe una forma rígida que "baste" — solo existen pruebas más o menos convincentes.
- Un procedimiento documentado sin lagunas y a prueba de auditoría (quién entregó cuándo el documento y con qué clave/qué gráfico, cómo se pudo verificar la integridad) convence más que un único "recibo de firma".
- A la inversa: una única captura de pantalla de una firma de correo convence poco; un conjunto de artefactos catalogado y basado en SHA-256, en cambio, sí.
GitCover traduce esto en una cadena favorable a la valoración de la prueba:
- Integridad: SHA-256 del documento de origen, del documento de firma, del sidecar.
- Atribución de origen: el documento de firma identifica al firmante (nombre, rol, referencia de clave/gráfico) y lo vincula mediante SHA-256 al documento de origen.
- Orden temporal: marca de tiempo uuidV7 en cada artefacto (RFC 9562).
- Catalogación: Class-Taxonomy de V7GUID en el sidecar; el auditor puede reconocer el tipo de artefacto sin conocimiento del contexto.
- Seguridad frente a auditoría: el historial de Git no es el único medio de prueba — la cadena también es verificable sin Git (con jq, sha256sum y cualquier editor).
§ 371a ZPO — el documento privado con forma electrónica
§ 371a ZPO: "Los documentos privados con forma electrónica tienen la fuerza probatoria de los documentos privados con forma escrita cuando la emitente o el emisor añade su nombre e indica la entrega de la declaración en forma electrónica, o cuando están provistos de una firma electrónica cualificada o de un sello autenticado comparable."
Tres observaciones para el enfoque de GitCover:
- Añadir el nombre + indicar la forma bastan — el documento de firma (DS02) hace exactamente eso: nombre/rol del firmante + indicación explícita de la forma ("entrega de la declaración en forma electrónica").
- QES es la alternativa de hierro — si un contrato debe tener fuerza probatoria como documento privado con QES, se acopla la cualificación FES (Parte II). La base en forma textual sigue siendo, aun así, el nivel del repositorio.
- El valor probatorio reside en la cadena — no en un rasgo individual. DS04 muestra la rutina de verificación completa.
El error más frecuente: la firma por correo electrónico
La situación práctica que GitCover quiere evitar:
unterschrieben"] B --> C["Gescannt"] C --> D["Per Mail
gesendet"] D --> E["Mail-Verzeichnis
im Postfach"] E --> F["Prüfung: Wo ist die
Original-Unterschrift?"] style F fill:#f3d9d9,stroke:#8b2635
Rupturas de la prueba: sin SHA-256, sin marca de tiempo, sin atribución de roles, sin seguridad frente a auditoría — el "original" circula entre impresora, escáner y cliente de correo. Un documento GitCover lo evita haciendo que cada etapa sea un artefacto en el repositorio.
Resumen
- El § 126b BGB exige acceso + texto literal + atribución de origen — el documento MD + el documento de firma lo cumplen de forma nativa en Git.
- Con la libre valoración de la prueba, la cadena sin lagunas (SHA-256 + tiempo + roles + catalogación) convence más que un recibo de firma externo.
- El § 371a ZPO lo confirma: añadir el nombre + indicar la forma bastan para la fuerza probatoria de los documentos privados; QES es la alternativa de hierro, no una exigencia para la forma textual.
- El siguiente artículo (DS02) define el documento de firma como esquema JSON.
Creado: 260913 | Parte I, artículo DS01 | Serie: digital-signage