Los repositorios y licencias de componentes para un desarrollador web autónomo necesitan una cadena de procedencia por versión. Las licencias de componentes de código en proyectos web pueden cambiar entre una dependencia, un paquete y un build. Un inventario de dependencias para un desarrollador autónomo debe enlazar origen, licencia, commit, proyecto, entrega, actualización y factura sin confundir acceso al código con titularidad.
| Elemento | Qué comprobar | Evidencia |
|---|---|---|
| Componente | Nombre, origen y versión | Lockfile o inventario |
| Licencia | Texto y procedencia | Archivo o proveedor |
| Proyecto | Repositorio y entorno | Ficha técnica |
| Build | Commit y dependencias | Artefacto |
| Entrega | Destino y aceptación | Acta o despliegue |
Separa repositorios, paquetes y artefactos
Registra URL o identificador, propietario, visibilidad, rama o versión y función. Un repositorio privado, un paquete publicado y un archivo incluido en el build son objetos distintos. Usa huellas y referencias sin copiar secretos ni código completo al expediente.
Distingue dependencia directa, transitiva, fragmento incorporado y servicio remoto. El lockfile ayuda a fijar versiones, pero puede no describir activos descargados manualmente o código generado. Añade esos elementos con su procedencia.
Conserva la licencia aplicable a cada versión
Guarda texto o referencia, proveedor, fecha y versión del componente. No supongas que una licencia actual se aplica a una descarga antigua. Si falta información, marca el componente para revisión antes de redistribuirlo.
Separa derecho de acceso, uso interno, modificación, distribución y transferencia. El medio de pago no prueba titularidad. Cuando una cuenta pertenece al cliente, documenta autorización y responsable sin trasladar credenciales.
Asocia cada componente a proyectos concretos
Relaciona dependencia, repositorio, ticket y finalidad. Si una biblioteca se usa en varios clientes, conserva la lista de builds que la incorporan. No inventes porcentajes de uso ni conviertas una instalación de prueba en entrega.
Distingue desarrollo, staging y producción. Un componente puede estar presente en el repositorio y no llegar al artefacto desplegado. Conserva la evidencia del build y la versión pública o entregada.
Versiona builds y entregas
Registra commit, herramienta, fecha, configuración relevante y huella del artefacto. Si el proceso resuelve versiones dinámicamente, conserva el lockfile o manifiesto efectivo. Una compilación correcta localmente no acredita el despliegue.
Después de entregar, verifica destino, versión y comportamiento previsto. Enlaza incidencias, rollback y nueva versión. No borres la evidencia del artefacto sustituido si es necesaria para explicar una corrección.
Concilia compras, renovaciones y proyectos
Une factura, periodo, cuenta, componente y proyectos. La Agencia Tributaria exige vinculación, registro, imputación y justificación para la deducibilidad. El inventario técnico apoya esa trazabilidad, pero no decide un reparto entre clientes o uso personal.
Si el cliente reembolsa una licencia, conserva factura recibida, contrato y factura emitida por separado. No compenses documentos dentro del inventario ni atribuyas el precio completo a un solo proyecto sin criterio acreditado.
Gestiona vulnerabilidades y sustituciones
Registra aviso, versión afectada, alcance, contención, prueba y actualización. Diferencia un identificador publicado de una afectación confirmada en el build. No atribuyas exposición sin comprobar versión y configuración.
Si sustituyes una dependencia, conserva equivalencia funcional, migración, licencia nueva y retirada de la anterior. Un nombre parecido no garantiza compatibilidad ni transferencia de datos.
Cierra con una cadena reproducible
Ejemplo hipotético: un desarrollador compra un componente, lo incluye en dos repositorios y entrega builds distintos. El expediente conecta factura, licencia, versiones, commits y destinos. Otra persona puede comprobar qué se entregó sin acceder a la clave comercial.
Revisa componentes sin procedencia, versiones flotantes, repositorios personales y cuentas que el cliente no controla. Cierra cada punto con evidencia o estado pendiente. La guía organiza trazabilidad técnica y económica; no interpreta licencias específicas ni afirma deducibilidad automática.
Control de cierre del expediente
Antes de dar la revisión por terminada, comprueba de nuevo componente, licencia, proyecto, build, entrega. Cada elemento debe apuntar a un documento, una fecha y una persona o sistema responsable. Conserva las discrepancias visibles, identifica qué dato procede del contrato y cuál de un registro posterior, y evita reemplazar un original por una tabla interna. Si una prueba no está disponible, anota el punto exacto y la acción necesaria para recuperarla.
El control está pensado para desarrollador web autónomo que integra componentes propios y de terceros en varios proyectos. Su finalidad es resolver este problema concreto: debe reconstruir procedencia, versión, licencia, build, entrega y factura sin exponer código ni claves. Otra persona debe poder reconstruir la secuencia con los mismos documentos y llegar a los mismos hechos, aunque la conclusión fiscal individual continúe pendiente. Ese criterio de reproducibilidad evita convertir una suposición cómoda en un dato cerrado.
Prueba cruzada antes de cerrar
Haz una primera lectura por orden temporal y una segunda por documento. En la lectura temporal, señala el primer acuerdo, cada cambio, la actuación realmente ejecutada y el cierre. En la documental, comprueba si contrato, factura, registro técnico y movimiento económico describen el mismo proyecto. No corrijas una diferencia copiando el dato más cómodo: conserva las versiones, fecha la discrepancia y asigna una comprobación concreta.
Prepara después una ficha mínima con el identificador del expediente, el elemento revisado, la evidencia original, la fecha del hecho, la fecha de obtención y el responsable del registro. Para este caso, la ficha debe permitir resolver debe reconstruir procedencia, versión, licencia, build, entrega y factura sin exponer código ni claves. Si intervienen varios clientes, proveedores o proyectos, usa una fila separada por relación y evita mezclar documentos solo porque comparten mes, importe o herramienta.
Realiza una muestra de extremo a extremo. Elige un caso cerrado y enlaza componente, licencia, proyecto, build, entrega con su soporte verificable. Repite la prueba con un caso abierto para identificar qué impide concluir: documento ausente, contradicción, acceso pendiente o decisión profesional necesaria. Registra el resultado como comprobado, discrepante o pendiente, junto con la siguiente acción. Así, la tabla funciona como índice de evidencias y no como sustituto de los originales.
Reconstruye una entrega desde el artefacto
Empieza por el paquete o build entregado y anota la etiqueta, el commit y el entorno en el que se verificó. Desde ese punto, recorre el lockfile y el inventario hasta cada componente relevante. Para cada dependencia, enlaza nombre, versión resuelta, origen, licencia conservada y decisión de inclusión. Si el repositorio se modificó después de la entrega, usa la referencia de aquella versión y no el estado actual de la rama.
Contrasta luego la cadena con el expediente comercial: proyecto, alcance, aceptación, factura y soporte posterior. Una dependencia puede formar parte del proceso de construcción sin entregarse como archivo separado; documenta esa diferencia. Si falta el texto de una licencia, la procedencia del paquete o el artefacto exacto, deja el hallazgo abierto y señala quién puede recuperarlo. El objetivo es reproducir qué se incorporó a esa entrega concreta, no elaborar un catálogo teórico del repositorio.
Alcance de la fuente oficial
La Agencia Tributaria explica que la deducibilidad de un gasto exige vinculación con la actividad, registro, imputación y justificación.
La fuente establece el marco general indicado. No transforma esta guía documental en una decisión fiscal individual ni resuelve excepciones, fechas, territorios, contratos o tratamientos que dependan de hechos adicionales.
Lecturas relacionadas y siguiente paso
Consulta también el contenido pilar del clúster y la guía sobre dominio y hosting de un desarrollador web. Ambos destinos son públicos y aportan contexto distinto.
Si necesitas contrastar el expediente antes de presentar, corregir o registrar información, puedes Quiero revisar mis componentes por proyecto.
Fuentes oficiales
Contenido informativo y general. La aplicación concreta depende de la actividad, el territorio, los documentos y las circunstancias de cada contribuyente.