06-intercambio ficha

Ver en GitHub ↗ raw ↗ zip06-intercambio.md

Reconstrucción de memoria a partir de Leval, Souchy, Casanova, Ovejero y Redalyc, sin páginas a mano: certeza A en la abolición del dinero interior y en el trueque entre colectividades, B en vales, carnet y cajas de compensación, C en los detalles de emisión y sanción, según la escala de draft.md §2. Todo es [doctrina, sin verbatim]. Confírmalo en Leval (Colectividades libertarias en España, capítulos de Aragón y Levante, y el pasaje sobre el Congreso de Caspe), en Souchy (reportajes de pueblos aragoneses) y en Casanova (El sueño igualitario, economía de las colectividades) antes de citar.

Puntos principales del tema «Intercambio sin moneda: vales, don, trueque y cajas de compensación» (reconstrucción)

# Tesis Cert.
1 Abolición del dinero dentro de la colectividad. En muchas colectividades aragonesas (y en menor medida levantinas) la moneda republicana dejó de circular entre miembros: el consumo se cubría desde el almacén comunal, sin compra ni precio interior A
2 Carnet de consumo (o de productor): cada familia inscrita retira del almacén según un cupo fijado por la asamblea (racionamiento por necesidades, no por saldo). Es contabilidad de reparto, no crédito: lo retirado se anota, no se paga A/B
3 Vales locales para lo no racionado: bonos de papel de valor local, nominativos o al portador según el pueblo, sin curso fuera de la colectividad y, en varios casos, con caducidad. Son instrumento de reparto, no moneda: no dan interés ni se acumulan B
4 El trabajo no se cambia por dinero. Aportar trabajo da derecho al consumo (salario familiar, ficha 04) sin relación aritmética entre horas y bienes; los oficios se intercambian dentro del pueblo sin precio B
5 Trueque de excedentes entre colectividades, en especie, con precio de referencia o sin él, coordinado por la federación comarcal; los excedentes no se venden entre pueblos, se compensan A
6 Cajas de compensación y almacenes comarcales: la federación (comarcal, y en Aragón el Consejo y la Federación de Colectividades tras el Congreso de Caspe, febrero de 1937) centraliza excedentes y déficits; las colectividades ricas abastecen a las pobres sin contraprestación estricta. Caspe acordó además suprimir las monedas locales y unificar el carnet de productor B
7 Con el exterior se paga en moneda: la colectividad tiene una caja común que vende excedentes a las ciudades y compra lo que no produce (maquinaria, abonos) con dinero republicano; el precio existe hacia fuera y no hacia dentro A
8 Sin acumulación: vales y carnet no permiten ahorrar ni prestar; el excedente vuelve al común, y lo no consumido en el periodo caduca o se reintegra B/C
9 La confianza sustituye a la garantía monetaria: en un pueblo donde todos se conocen, el abuso del almacén o del vale se corrige en asamblea, no con un cobro; la reputación es el respaldo del intercambio C

Ficha de confirmación del mapeo (fuente: draftv0.md)

  • Mapeado: tesis 1 → hallazgo 5, fila 7 de la confrontación, hallazgo E, CL-6 y TK-E'01 (precio cero, market_model.js:182, shops_model.js:414-415, verificados); tesis 2 y 3 → TK-D'03 (pregunta por el carnet y los vales) y TK-E'02 (vales = transfers TIME, transfers_model.js:25); tesis 4 → TK-E'03 (bolsa de trabajo sin salary, jobs_model.js:192); tesis 5 → CL-6 (kind: "barter"); tesis 6 → TK-F'02 y el default de TK-D'03 (saldo TRUST liquidado por la federación); tesis 7 → nada explícito, pero CL-5 (tesoro de tribu) es la caja común que compra fuera.
  • Acierto no explicitado 1 (el precio es un número, no un cobro): ninguna compra de Oasis liquida en cadena. decrementStock publica un marketPurchase sin pago (L634), buyProduct un shopPurchase igual de vacío (L614), y en la tienda el estado PAID lo declara el vendedor por su palabra (L26, L731-L734); en los cinco módulos no aparece sendtoaddress, ecoin ni wallet. Draftv0 trata el > 0 como una prohibición económica; es solo una validación de formulario. Quitarla (TK-E'01) no rompe ninguna liquidación porque no hay ninguna. La tesis 9 (confianza en vez de cobro) describe exactamente cómo funciona ya el código.
  • Acierto no explicitado 2 (el trueque ya tiene nombre): Market conoce un item_type: "exchange" que filtra por FOR SALE (L391-L392) y que el formulario ofrece como opción «Exchange» (market_view.js:384), pero createItem le exige precio positivo (L182) y updateItemById también (L252). El trueque existe como etiqueta y está prohibido como número. CL-6 proponía inventar kind: "barter"; basta con liberar el tipo que ya hay.
  • Acierto no explicitado 3 (el banco de tiempo está escrito en Jobs, no en Transfers): createJob guarda salary como 0.000000 cuando no se da (L200-L201), la actualización solo rechaza salarios negativos (L334), y el tipo exchange lleva hoursOffered, hoursRequested y exchangeSkill (L228-L230; «Skill wanted in exchange», jobs_view.js:383). Es la tesis 4 (oficios intercambiados sin precio) tal cual. §2.6 solo dice que «dos son asalariadas» y TK-E'03 propone un tipo collective nuevo sin apoyarse en el que existe.
  • Acierto no explicitado 4 (la RBU ya paga en vales): cada asignación de época se registra como transfer del PUB al miembro, con concept: "UBI …", estado UNCLAIMED, deadline de gracia y tags: ["UBI", …] (L974-L986), y transfers_model.js la reconoce por la etiqueta (L75-L79). El común ya emite vales nominativos con caducidad: TK-E'02 no parte de cero, parte de ahí.
  • Acierto no explicitado 5 (el vale caduca y no se acumula): createTransfer exige deadline futura (L233-L234) y deriveStatus pasa a DISCARDED lo vencido (L182-L183). Es la tesis 8 en aritmética. Conviene decirlo en «Lo que no se toca».
  • Hueco 1 (grave, tesis 6): TK-D'03 y TK-F'02 dan por hecho un «saldo TRUST». En transfers_model.js no hay ningún balance, ledger ni suma por par (verificado con grep: cero apariciones); TRUST es solo una etiqueta normalizada (L26-L29) sin lógica propia. Peor: isValidId solo acepta feeds @…ed25519 como destinatario (L12, aplicado en L228), y una tribu es un mensaje %…. Una tribu no puede recibir ni emitir una transferencia. La caja de compensación no cabe en Transfers sin CL-5 (tesoro con identidad propia) y sin un agregado nuevo.
  • Hueco 2 (tesis 2): el carnet de consumo es un cupo por hogar retirado del almacén, no un crédito. TK-E'02 lo mete en transfers TIME (un vale bilateral) y no depende de CL-9 (household). La costura correcta es la tienda de tribu: pedido shop-purchase privado entre comprador y vendedor (L636-L651), estados del pedido (L26-L28) y RECEIVED que solo firma el comprador (L731-L732). Falta una tarea.
  • Hueco 3 (tesis 3): el vale de Oasis es nominativo y bilateral: from es siempre el autor (L243), lo confirma solo el destinatario (L339) y se cierra con dos firmas (L177-L181). No hay endoso: un vale no puede pasar a un tercero. TK-D'03 no pregunta si los vales históricos circulaban o eran nominativos; la respuesta decide si el modelo necesita endoso o no.
  • Hueco 4 (tesis 7): ningún parche dice que el precio se conserva hacia fuera. CL-6 «admite» precio cero; no dice que dentro de la tribu sea el default ni que el Market con precio siga siendo el canal con el exterior y la caja común (CL-5) quien compra. Sin esa frase, el criterio 7 parece pedir abolir el precio en toda la red.
  • Contradicción a corregir: la fila 7 afirma que «solo transfers TIME y couchsurfing admiten lo no monetario» y el hallazgo 5 que «el don y el trueque no son representables». Ambas son falsas en parte: housing admite precio 0 también en rent y sale, porque nonNeg devuelve 0 para todo lo no positivo (L25-L28) y buildContent lo aplica (L317); jobs admite salary 0 en cualquier tipo; y el trueque es representable como exchange con precio nominal. §2.6 («solo couchsurfing fuerza precio cero») es exacto; la fila 7 generaliza mal. Se corrige con nota fechada, no reescribiendo.
  • Sin hueco: tesis 9, cubierta de hecho por transferOpinion (L411-L425) y por marketOpinion, que solo puede emitir quien compró (L542); no necesita parche, solo que CL-4 saque esas opiniones del karma de la renta, cosa que ya hace.

Veredicto: el intercambio sin moneda está mapeado en su prohibición (precio cero, CL-6, TK-E'01) y en su carril de escape (TIME), no en su mecánica: el carnet de consumo no tiene costura, la caja de compensación no cabe en Transfers (sin saldo, sin tribu como destinatario), y las tres grietas que el código ya trae (Jobs con salario 0 y tipo exchange, Market con exchange etiquetado, compras que no cobran) no estaban en el draft.

Correcciones aplicadas (2026-09-09)

  • draftv0.md hallazgo 5: matizado que el trueque existe como etiqueta exchange con precio forzoso y que jobs (salario 0) y housing (precio 0) son apoyos adicionales del criterio 7 (contradicción).
  • draftv0.md fila 7: añadidos jobs con salary 0 y tipo exchange (jobs_model.js:200-201, :228-230), housing con precio 0 (housing_model.js:25-28) y el item_type: "exchange" de Market con precio forzoso (market_model.js:391-392, :182); el veredicto pasa de «un carril de escape» a «carriles de escape» (contradicción).
  • draftv0.md hallazgo E: nota fechada con las grietas no citadas (Jobs, Housing, exchange de Market) y con el hecho de que ninguna compra liquida en cadena (market_model.js:634, shops_model.js:614, :26, :734): el precio es un número declarado, no un cobro (aciertos 1, 2 y 3).
  • draftv0.md CL-6: barter reutiliza item_type: "exchange" (market_model.js:391-392); los vales son nominativos, con doble confirmación y caducidad (deriveStatus, transfers_model.js:175-185), como ya hace la RBU (banking_model.js:974-986); la caja de compensación exige un agregado nuevo y el tesoro CL-5 como identidad porque transfers no tiene saldo ni acepta tribus (transfers_model.js:12); el precio se conserva hacia fuera (huecos 1 y 4, aciertos 2 y 4). Costuras ampliadas.
  • draftv0.md TK-D'03: añadidas las preguntas cupo o saldo, caducidad y endoso, quién emite, compensación bilateral o multilateral (Caspe, febrero 1937) y pago exterior en moneda (huecos 2, 3 y 4); default: vales nominativos con deadline emitidos por la comisión de abastos (cargo CL-2), carnet = cupo por household en la tienda de tribu (TK-E'04), saldo TRUST por par de tribus con CL-5, Market con precio hacia fuera; nueva alternativa: vales al portador endosables; desbloquea TK-E'02 y TK-E'04.
  • draftv0.md TK-E'01: barter = tipo exchange liberado del > 0; el cambio es solo de validación porque marketPurchase/shopPurchase no pagan; costuras market_model.js:252, :391-392, :634, shops_model.js:614 (acierto 1 y 2).
  • draftv0.md TK-E'02: vales nominativos emitidos por la comisión de abastos, cierre por confirmación del receptor, caducidad por deadline, sin endoso; el carnet de consumo sale de aquí y pasa a TK-E'04; depende también de G'03; costuras transfers_model.js:175-185, :243, :339 (hueco 3, acierto 5).
  • draftv0.md TK-E'03: parte del tipo exchange (hoursOffered, hoursRequested, exchangeSkill) y de que salary 0 ya es legal; costuras jobs_model.js:200-201, :228-230, :334 (acierto 3).
  • draftv0.md TK-E'04 (nueva, prioridad media, tras TK-E'03): carnet de consumo sobre la tienda de tribu: pedido shop-purchase sin precio que descuenta un cupo por household, RECEIVED firmado por el consumidor y PAID suprimido; depende de D'03, B'02 y E'01; costuras shops_model.js:26-28, :592-616, :636-651, :731-734 (hueco 2).
  • draftv0.md TK-F'02: requiere un agregado de saldo por par de tribus (inexistente) y que el tesoro CL-5 sea emisor y destinatario porque isValidId solo acepta feeds; costuras transfers_model.js:12, :26-29, :175-185 (hueco 1).
  • draftv0.md resumen de prioridades: TK-E'04 añadida a la fila Media.
  • 00-indice.md: fila «Intercambio sin moneda» enlazada a esta ficha, con hallazgo principal y tareas tocadas.