¿Sabes qué versión de una biblioteca quedó en la web que entregaste? Empieza por la entrega y relaciónala con el código, las dependencias y sus condiciones de uso. En los repositorios y licencias de componentes de un desarrollador web autónomo, la rama actual puede ser distinta de la versión que recibió el cliente.
Guarda una referencia de la entrega y la procedencia de los componentes que incorpora. Tener acceso al código o haber pagado una descarga no demuestra por sí solo que puedas redistribuirla de cualquier forma.
Identifica el código y el paquete que realmente entregas
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.
| 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 |
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.
Relaciona la versión de código con la entrega
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.
Consultar con Alexis cómo relacionar las compras de código con tus proyectos.
Concilia compras, renovaciones y proyectos
Une factura, periodo, cuenta, componente y proyectos. La AEAT exige vinculación con la actividad, registro, imputación correcta y justificación para considerar deducible un gasto. 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.
Un componente usado en dos webs
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.
Revisa desde la web entregada hacia sus componentes
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. Así puedes comprobar qué se incorporó a la entrega sin confundirlo con todo lo que contiene hoy el repositorio.
Si la dependencia cambió después de publicar
Compara el aviso con la versión que utilizaste. Las licencias de componentes de código en proyectos web deben revisarse sobre el recurso concreto, no sobre una página comercial que puede describir otro producto o una edición posterior. Conserva la referencia de las condiciones y plantea la duda al proveedor cuando no puedas determinar su alcance.
Si se trata de una actualización técnica, comprueba qué webs incorporan la versión afectada. Un inventario de dependencias para un desarrollador autónomo permite localizar los proyectos que necesitan revisión. No atribuyas una vulnerabilidad a un cliente solo por compartir el nombre de la biblioteca: confirma versión, uso y configuración pertinente.
Antes de sustituir el componente, conserva el estado entregado y prueba el cambio en el entorno adecuado. Registra la nueva dependencia, sus condiciones y el resultado real. Una compilación terminada no acredita que el formulario, la compra u otra función de la web siga funcionando como se esperaba.
Al cerrar el cambio, enlaza versión anterior, motivo, pruebas y entrega nueva. Si el cliente conserva un paquete anterior, identifica cuál tiene. Mantén las claves comerciales y los accesos en su ubicación segura, separados del inventario que se comparte para el proyecto.
La guía fiscal del autónomo aporta el marco de los gastos. Para cada compra técnica conserva además qué componente obtuviste y en qué entrega se utilizó.
Si necesitas ordenar compras y renovaciones de componentes, revisa con Alexis los gastos de componentes de tus proyectos web. Prepara facturas, condiciones de compra y proyectos en los que los usas.
