# Colectivizaciones libertarias · Auditoría de OASIS 1.0.7 contra los ocho criterios colectivistas **Revisión 0 — 2026-09-09.** La semilla (`draft.md`) fijó el corpus, los ocho criterios y las premisas técnicas. Este documento audita el código real y propone once parches CL-1…CL-11 y un backlog por carriles. --- ## 0. Qué cambia respecto de la semilla | # | Hallazgo | Consecuencia | | :-- | :-- | :-- | | 1 | **La asamblea existe en el código y no manda.** Toda tribu nace con un parlamento propio en `ANARCHY`, sin líder, con quórum del 25 %. Pero ese parlamento no gobierna nada de la tribu: ni sus campos, ni sus miembros, ni su dinero (no tiene). | El criterio 1 no se diseña: se **conecta**. Ver §3.B. | | 2 | **La tribu es propiedad de su fundador.** Solo el autor invita en modo estricto, no puede irse, y si se le fuerza a irse la tribu muere con él. | Lo contrario del criterio 2. La colectividad digital hoy es una monarquía con cifrado. Ver §3.A. | | 3 | **La instalación industrial es una cooperativa de aportantes, no un medio de producción común.** Trabajo, material y ECOin entran en la misma bolsa de puntos y el reparto es estrictamente proporcional, sin suelo ni necesidad. Lo firma una sola persona. | Los criterios 3 y 4 fallan en el único módulo que podía cumplirlos. Ver §3.C. | | 4 | **La única renta con suelo es la RBU, y está ponderada por karma.** El peso va de 0,2 a 6: hasta treinta veces más para el notorio que para el silencioso. Sin hogar ni dependientes. | El salario familiar no existe; existe una renta por mérito. Ver §3.D. | | 5 | **El precio cero está prohibido** en Market y Shops; el don y el trueque no son representables **(el trueque solo como etiqueta `item_type: "exchange"` con precio forzoso, `market_model.js:391-392`, `:182`)**. | El criterio 7 no tiene dónde apoyarse salvo en `Transfers` (vales de tiempo), **`jobs` con `salary` 0 (`jobs_model.js:200-201`) y `housing` con precio 0 (`housing_model.js:25-28`)** (nota 2026-09-09 en §3.E). Ver §3.E. | | 6 | **La semilla anterior de este modelo daba por hechos tres supuestos falsos** (smart contracts en Faircoin, nodo central en SSB, Faircoin vivo). | Corregidos en `draft.md` §3. Nada de este documento depende de ellos. | **Metodología.** Todo lo que aquí se afirma sobre Oasis está verificado contra el código fuente, no contra su documentación. Árbol auditado: `vendor/oasis` (ignorado por git; clónalo con `git clone --depth 1 https://github.com/epsylon/oasis.git`). Commit auditado: **`9a657b776fcafc7c24bf3ad61825316385ecf513`, "Oasis release 1.0.7", 2026-09-08**. Cada afirmación lleva `fichero:línea`; cuando cito la web y no el disco, lo digo; la doctrina colectivista va marcada **[doctrina, sin verbatim]** hasta que el carril D' la verifique en las fuentes. --- ## 1. Estado del arte verificado ### 1.1 OASIS 1.0.7 - Paquete `@krakenslab/oasis` v1.0.7, AGPL-3.0, Node.js + HTML sin JavaScript en el navegador, sobre SSB. 70 ficheros en [src/models/](vendor/oasis/src/models/) (32.849 líneas). - Los módulos que importan a una colectividad son los que la auditoría trevijanista dejó «en una línea»: [tribes_model.js](vendor/oasis/src/models/tribes_model.js) (939 líneas), [industry_model.js](vendor/oasis/src/models/industry_model.js) (991), la parte de reparto de [banking_model.js](vendor/oasis/src/models/banking_model.js) (1.479), el parlamento de tribu de [parliament_model.js](vendor/oasis/src/models/parliament_model.js) (1.615), [votes_model.js](vendor/oasis/src/models/votes_model.js) (390), [polls_model.js](vendor/oasis/src/models/polls_model.js) (440), [market_model.js](vendor/oasis/src/models/market_model.js) (641), [transfers_model.js](vendor/oasis/src/models/transfers_model.js) (428), [jobs_model.js](vendor/oasis/src/models/jobs_model.js) (558), [housing_model.js](vendor/oasis/src/models/housing_model.js) (551), [school_model.js](vendor/oasis/src/models/school_model.js) (1.404) e [inhabitants_model.js](vendor/oasis/src/models/inhabitants_model.js) (505). - **Vocabulario.** En 33.000 líneas de modelos y 60 vistas no aparece ni una vez *assembly*, *council*, *delegate*, *recall*, *commons*, *cooperative* ni *mutual aid*. *Federation* significa «conectarse a un PUB». La única aparición de «collective» está en un mensaje automático de [backend.js#L6214](vendor/oasis/src/backend/backend.js#L6214): la instalación «ha sido disuelta por voto colectivo». En cambio *salary* aparece en doce sitios (§2.6). El código habla el idioma del mercado con un acento cooperativo. ### 1.2 La capa económica - `faircoin/faircoin`: último push 2022-02-05 (verificado vía API de GitHub el 2026-09-09); dominios de FairCoop y Bank of the Commons caídos. Bitcoin 0.12 con Proof-of-Cooperation, **sin contratos**. No es un sustrato vivo. - Lo vivo es **ECOin** a través del módulo `Banking`, que habla con la cadena por RPC (`sendtoaddress`, [banking_model.js#L1004](vendor/oasis/src/models/banking_model.js#L1004)) desde la cartera del PUB. La oferta monetaria la lee de fuera; Oasis no emite. - Consecuencia: todo reparto colectivista se implementa en Oasis (reglas de `Banking`, `Industry`, `Transfers`), no en la cadena. ### 1.3 El corpus colectivista (recordatorio operativo) Los ocho criterios de `draft.md` §2, **[doctrina, sin verbatim]**: 1. **Asamblea soberana**: toda decisión nace de la asamblea de miembros; las comisiones ejecutan. 2. **Cargos rotatorios y revocables**, sin poder propio. 3. **Propiedad colectiva** de los medios de producción. 4. **Distribución según necesidades** (salario familiar), no según rendimiento. 5. **Derechos sociales garantizados**: educación, sanidad, jubilación, jornada. 6. **Federación de abajo arriba** con delegados mandatados. 7. **Intercambio sin moneda o con vales**; compensación entre colectividades. 8. **Voluntariedad** de entrada y salida. Con estos ocho criterios se puede auditar cualquier institución. Los aplico al código en la §3. --- ## 2. Anatomía de los módulos que importan aquí ### 2.1 Tribes — [tribes_model.js](vendor/oasis/src/models/tribes_model.js) · 939 líneas **La tribu nace como propiedad de una persona.** `createTribe` inicializa `members: [userId]` e `invites: []` ([L337-L338](vendor/oasis/src/models/tribes_model.js#L337-L338)) y fija `author: userId` ([L345](vendor/oasis/src/models/tribes_model.js#L345)); `parentTribeId` ([L341](vendor/oasis/src/models/tribes_model.js#L341)) permite anidar tribus en jerarquía padre-hijo. **La jerarquía es descendente**: la subtribu la crea el padre (en modo estricto solo su autor, [backend.js#L7799-L7801](vendor/oasis/src/backend/backend.js#L7799-L7801)), hereda su privacidad ([L490](vendor/oasis/src/models/tribes_model.js#L490), [backend.js#L7806-L7807](vendor/oasis/src/backend/backend.js#L7806-L7807)) y no puede cambiarla ni cambiar de padre ([backend.js#L7819-L7822](vendor/oasis/src/backend/backend.js#L7819-L7822)), muere en cascada si el padre recibe `tombstone` ([L218-L225](vendor/oasis/src/models/tribes_model.js#L218-L225)) y **no tiene parlamento**: el backend rechaza candidaturas, votos y reglas de toda tribu con padre («Sub-tribes have no governance», [backend.js#L8305](vendor/oasis/src/backend/backend.js#L8305), [L8323](vendor/oasis/src/backend/backend.js#L8323), [L8339](vendor/oasis/src/backend/backend.js#L8339), [L8353](vendor/oasis/src/backend/backend.js#L8353), [L8364](vendor/oasis/src/backend/backend.js#L8364)). Los campos estructurales (`title`, `description`, `inviteMode`, `status`, `parentTribeId`…) están enumerados en `STRUCTURAL_FIELDS` ([L11](vendor/oasis/src/models/tribes_model.js#L11)). **Quién manda: el autor.** No hay rol de administrador ni de asamblea: hay una comparación `tribe.author !== userId`. En modo estricto solo el autor genera invitaciones ([L554-L556](vendor/oasis/src/models/tribes_model.js#L554-L556), repetido en [L612-L617](vendor/oasis/src/models/tribes_model.js#L612-L617)); en modo abierto, cualquier miembro. **El autor no puede abandonar su tribu** ([L721](vendor/oasis/src/models/tribes_model.js#L721)) y, si se le fuerza y no queda nadie, la tribu recibe un `tombstone` ([L726-L729](vendor/oasis/src/models/tribes_model.js#L726-L729)): la comunidad muere con su fundador. No existe sucesión. **La pertenencia es una clave.** `updateTribeMembers` ([L533-L541](vendor/oasis/src/models/tribes_model.js#L533-L541)) recalcula altas y bajas y **rota la clave de cifrado** en cada expulsión. Es un buen mecanismo de privacidad y un mal mecanismo político: quien controla la lista controla quién puede leer. **No hay patrimonio.** Cero apariciones de `treasury`, `wallet`, `balance` o `ecoin` en todo el fichero. La tribu tiene miembros, claves e invitaciones; no tiene nada que repartir. ### 2.2 Industry — [industry_model.js](vendor/oasis/src/models/industry_model.js) · 991 líneas Tres niveles: **instalación** (medio de producción) → **plano** (`blueprint`) → **lote** (`build`). Políticas de admisión `open | vote | invite` ([L16](vendor/oasis/src/models/industry_model.js#L16)). **El `steward` es el autor del mensaje raíz** ([L164](vendor/oasis/src/models/industry_model.js#L164)), miembro inamovible ([L187](vendor/oasis/src/models/industry_model.js#L187), [L205](vendor/oasis/src/models/industry_model.js#L205)), el único que edita la instalación ([L457](vendor/oasis/src/models/industry_model.js#L457)), no puede irse ([L510](vendor/oasis/src/models/industry_model.js#L510)), es el único que da por terminado o fallido un lote ([L808-L809](vendor/oasis/src/models/industry_model.js#L808-L809)) y **el único que reparte** ([L980](vendor/oasis/src/models/industry_model.js#L980)). La propiedad del medio de producción se deriva de la autoría de un mensaje. **Lo que sí es colectivo.** Admisión y disolución se deciden por voto con quórum y mayoría ([L211-L223](vendor/oasis/src/models/industry_model.js#L211-L223)); una instalación con miembros no puede borrarse, «debe disolverse por voto» ([L484-L485](vendor/oasis/src/models/industry_model.js#L484-L485)). `passesThreshold` ([L98-L101](vendor/oasis/src/models/industry_model.js#L98-L101)) exige el máximo entre quórum y mayoría; `clampMajority` acota la mayoría a **[0,5, 1]** ([L23-L27](vendor/oasis/src/models/industry_model.js#L23-L27)): nunca menos de la mitad. Con un solo miembro todo se aprueba solo ([L121](vendor/oasis/src/models/industry_model.js#L121)). Materias votables: `admit, dissolve, pause, bpUpdate, bpDelete, buildUpdate, buildDelete` ([L532](vendor/oasis/src/models/industry_model.js#L532)). Ni el steward ni el reparto están en la lista. **Cómo se reparte: a cada cual según su aportación.** `computeShares` ([L306-L321](vendor/oasis/src/models/industry_model.js#L306-L321)) convierte trabajo (`hours × laborRate`), material (`value`) y ECOin (`eco`) en **la misma bolsa de puntos**; la participación es `puntos / total`. `laborRate`, la tasa que convierte horas en puntos, la fija el steward al crear la instalación ([L438](vendor/oasis/src/models/industry_model.js#L438)) y solo él la cambia ([L457](vendor/oasis/src/models/industry_model.js#L457)): **la relación entre trabajo y capital es una decisión unipersonal del propietario.** `computeDistributionPlan` ([L960-L970](vendor/oasis/src/models/industry_model.js#L960-L970)) reparte `pot × share` a cada uno, sin suelo, sin tope y sin parte reservada al común; la «tesorería» del lote es solo la suma de aportes ECO ([L378](vendor/oasis/src/models/industry_model.js#L378)). El resultado se publica como `industryAllocation` ([L986](vendor/oasis/src/models/industry_model.js#L986)). El único gesto anticapitalista del fichero es el `license: "copyleft"` por defecto de los planos ([L439](vendor/oasis/src/models/industry_model.js#L439)). ### 2.3 Banking: la renta básica — [banking_model.js](vendor/oasis/src/models/banking_model.js) · 1.479 líneas **Reglas por defecto** ([L14-L21](vendor/oasis/src/models/banking_model.js#L14-L21)): épocas mensuales, `alpha 0.2`, reserva mínima 500, tope 2.000 por época, tope 50 por persona y época, **suelo 1**, pesos entre 0,2 y 6, 30 días de gracia. **El fondo** ([L913-L917](vendor/oasis/src/models/banking_model.js#L913-L917)): el 20 % del saldo del PUB, nunca por debajo de la reserva ni por encima del tope de época. El común es la cartera del operador del PUB. **El reparto** (`computeEpoch`, [L920-L947](vendor/oasis/src/models/banking_model.js#L920-L947)): el peso de cada persona es `1 + karma/100`, acotado a [0,2, 6] ([L932](vendor/oasis/src/models/banking_model.js#L932)); la cantidad bruta es `max(suelo, min(pool × w / W, tope))` ([L941](vendor/oasis/src/models/banking_model.js#L941)); el impuesto de carbono y archivo se descuenta **solo del excedente sobre el suelo** ([L942-L947](vendor/oasis/src/models/banking_model.js#L942-L947)). La interfaz lo declara doctrina: «the base UBI value is set as an immovable minimum» ([banking_views.js#L246](vendor/oasis/src/views/banking_views.js#L246), [L486](vendor/oasis/src/views/banking_views.js#L486)). La misma fórmula de peso se repite en la estimación ([L1300](vendor/oasis/src/models/banking_model.js#L1300)) y en el pago real ([L1413-L1416](vendor/oasis/src/models/banking_model.js#L1413-L1416)), aunque en el pago real el denominador no es la suma de pesos `W` sino el número de elegibles con peso 1 cada uno ([L1414](vendor/oasis/src/models/banking_model.js#L1414)): el karma pondera solo al reclamante y la cantidad pagada no coincide con la asignación calculada. La asignación de cada época nace `UNCLAIMED` con 30 días de plazo ([L982](vendor/oasis/src/models/banking_model.js#L982)) y pasa a `EXPIRED` a los doce meses si nadie la reclama ([L1331-L1341](vendor/oasis/src/models/banking_model.js#L1331-L1341)): la renta hay que pedirla. El impuesto de archivo grava los días de antigüedad del feed ([L32](vendor/oasis/src/models/banking_model.js#L32), [L38](vendor/oasis/src/models/banking_model.js#L38), [L759-L768](vendor/oasis/src/models/banking_model.js#L759-L768)): cuanto más viejo el miembro, más paga sobre su excedente. *(Nota 2026-09-09: en el pago real el numerador es el peso del reclamante, pero el denominador suma 1 por cada dirección elegible ([L1414](vendor/oasis/src/models/banking_model.js#L1414)), no el peso de cada uno como en L932; el importe enviado por `sendtoaddress` ([L1416](vendor/oasis/src/models/banking_model.js#L1416)) no coincide con el asignado en L941. TK-B'06 lo unifica.)* Cada época se sella con un hash ([L960-L962](vendor/oasis/src/models/banking_model.js#L960-L962)). **El karma** es un escalar único: actividad menos gramos de carbono ([L840](vendor/oasis/src/models/banking_model.js#L840)), publicado en el log ([L501-L506](vendor/oasis/src/models/banking_model.js#L501-L506)); impuestos en [L30-L36](vendor/oasis/src/models/banking_model.js#L30-L36). Es una **renta por notoriedad con suelo**, no una renta por necesidad. No hay hogar, no hay dependientes, no hay edad. ### 2.4 El parlamento de tribu y `canPropose` — [parliament_model.js](vendor/oasis/src/models/parliament_model.js) · 1.615 líneas **Toda tribu nace en anarquía.** `tribePublishInitialTerm` ([L1354-L1374](vendor/oasis/src/models/parliament_model.js#L1354-L1374)) publica un mandato con `method: 'ANARCHY'` y `leaderId: null` ([L1363-L1364](vendor/oasis/src/models/parliament_model.js#L1363-L1364)). El quórum de la tribu es `max(2, ceil(miembros × 0,25))` ([L1376-L1384](vendor/oasis/src/models/parliament_model.js#L1376-L1384)); si nadie lo alcanza, `chosen = null` ([L1402-L1403](vendor/oasis/src/models/parliament_model.js#L1402-L1403)) y el mandato vuelve a `ANARCHY` ([L1409-L1410](vendor/oasis/src/models/parliament_model.js#L1409-L1410)). `ANARCHY` es un método de voto pero **no es elegible** como candidatura ([L22-L23](vendor/oasis/src/models/parliament_model.js#L22-L23)): solo se llega a ella por ausencia. **Quién propone.** `canPropose` ([L1298-L1311](vendor/oasis/src/models/parliament_model.js#L1298-L1311)): bajo `ANARCHY`, todos; con gobierno de persona, solo ella; con gobierno de tribu, **todos los miembros de la tribu**. Es lo más parecido a una asamblea que hay en el código, y solo se activa cuando no hay gobierno o cuando gobierna una facción. Un gobierno de tribu es una colectividad gobernando toda la red: cualquier tribu raíz puede presentarse en bloque al parlamento general ([backend.js#L8300-L8316](vendor/oasis/src/backend/backend.js#L8300-L8316); `resolveTarget` acepta tribus, [L216-L226](vendor/oasis/src/models/parliament_model.js#L216-L226); `winnerTribeId`, [L1206](vendor/oasis/src/models/parliament_model.js#L1206)), y al subir su `ANARCHY` se convierte en `DEMOCRACY` ([backend.js#L8314](vendor/oasis/src/backend/backend.js#L8314)). Es lo contrario de una federación de delegados (CL-8). **Umbrales generales** ([L240-L242](vendor/oasis/src/models/parliament_model.js#L240-L242)): 80 % / 20 % / mitad más uno; quórum general `max(2, 25 % del censo)` ([L257-L259](vendor/oasis/src/models/parliament_model.js#L257-L259)). La prohibición de autovoto solo aplica a personas ([L756](vendor/oasis/src/models/parliament_model.js#L756)): una tribu puede votarse a sí misma en bloque. **Lo decisivo:** el parlamento de tribu es un órgano sin competencias. No toca `STRUCTURAL_FIELDS`, no expulsa, no elige steward, no reparte. Vota leyes que son texto. Tampoco revoca: el único mecanismo llamado revocación en el fichero, `parliamentRevocation` con `REVOCATION_DAYS = 15` ([L19](vendor/oasis/src/models/parliament_model.js#L19); `createRevocation`, [L638-L649](vendor/oasis/src/models/parliament_model.js#L638-L649)), revoca **leyes** del parlamento general, nunca personas, y no tiene tipo de tribu ([L14](vendor/oasis/src/models/parliament_model.js#L14)). Un líder de tribu solo cae al expirar los 60 días de `TERM_DAYS` ([L17](vendor/oasis/src/models/parliament_model.js#L17), `isExpiredTerm` [L68-L72](vendor/oasis/src/models/parliament_model.js#L68-L72), `tribeEnsureTerm` [L1433-L1437](vendor/oasis/src/models/parliament_model.js#L1433-L1437)) y puede reelegirse sin límite: la única traba es una candidatura por candidato y ciclo ([L1449-L1452](vendor/oasis/src/models/parliament_model.js#L1449-L1452)). El código rota por calendario y no revoca por voluntad (ficha 02, hueco 1). ### 2.5 Votes, Polls y Opinions - [votes_model.js](vendor/oasis/src/models/votes_model.js): plazo mínimo de 7 días ([L10](vendor/oasis/src/models/votes_model.js#L10)); opciones por defecto `YES, NO, ABSTENTION, CONFUSED, FOLLOW_MAJORITY, NOT_INTERESTED` ([L173](vendor/oasis/src/models/votes_model.js#L173)). **`FOLLOW_MAJORITY` es la única delegación de todo el sistema**, y es una delegación al agregado anónimo, no a una persona revocable. Sin quórum: la votación se cierra por fecha y muestra el recuento. - [polls_model.js](vendor/oasis/src/models/polls_model.js): consultas cifrables por tribu ([L45-L60](vendor/oasis/src/models/polls_model.js#L45-L60)), un voto por autor sobreescribible ([L84-L86](vendor/oasis/src/models/polls_model.js#L84-L86)), caducidad ([L143](vendor/oasis/src/models/polls_model.js#L143)). Sin duración mínima, quórum ni umbral. - [opinions_model.js](vendor/oasis/src/models/opinions_model.js): una reacción tipificada por persona y objeto, irrevocable ([L59](vendor/oasis/src/models/opinions_model.js#L59), [L67](vendor/oasis/src/models/opinions_model.js#L67)). Alimenta el karma y, por tanto, la renta. ### 2.6 Mercado, trabajo y vivienda - [market_model.js](vendor/oasis/src/models/market_model.js): `if (p <= 0) throw new Error("Invalid price")` ([L182](vendor/oasis/src/models/market_model.js#L182)); stock también positivo ([L185](vendor/oasis/src/models/market_model.js#L185)). **No se puede publicar un bien gratuito ni un don.** Lo mismo en [shops_model.js#L414-L415](vendor/oasis/src/models/shops_model.js#L414-L415). - [transfers_model.js](vendor/oasis/src/models/transfers_model.js): categorías `ECONOMIC, TIME, TRUST` ([L25](vendor/oasis/src/models/transfers_model.js#L25)); importe positivo obligatorio ([L230-L231](vendor/oasis/src/models/transfers_model.js#L230-L231)). `TIME` es el único carril no monetario: vales de tiempo, crédito mutuo. - [jobs_model.js](vendor/oasis/src/models/jobs_model.js): tres relaciones de producción, `freelancer | employee | exchange` ([L192](vendor/oasis/src/models/jobs_model.js#L192)); dos son asalariadas y `salary` se propaga a vistas, búsquedas y estadísticas de la red. Pero el salario puede ser 0: se guarda como `0.000000` cuando no es número ([L201](vendor/oasis/src/models/jobs_model.js#L201)) y la edición solo rechaza negativos ([L334](vendor/oasis/src/models/jobs_model.js#L334)); un puesto sin salario ya es representable, al contrario que un bien sin precio en Market. `job_time` `partial | complete` ([L203-L204](vendor/oasis/src/models/jobs_model.js#L203-L204)) y `hoursOffered`/`hoursRequested` ([L228-L229](vendor/oasis/src/models/jobs_model.js#L228-L229)) describen la jornada sin acotarla. - [housing_model.js](vendor/oasis/src/models/housing_model.js): `sale | rent | couchsurfing` sobre `apartment | house | room | land | other` ([L9-L10](vendor/oasis/src/models/housing_model.js#L9-L10)); solo `couchsurfing` fuerza precio cero ([L317](vendor/oasis/src/models/housing_model.js#L317)). **La tierra es una mercancía** con tres regímenes y ninguno por necesidad. Nota 2026-09-09 (ficha 03): la tribu no puede ser titular de un anuncio; solo el autor lo edita ([L374](vendor/oasis/src/models/housing_model.js#L374)) y fija el precio ([L388](vendor/oasis/src/models/housing_model.js#L388)). Sin tarea propia hasta CL-5 (`tribeAsset`) y TK-G'07. ### 2.7 School e Inhabitants - [school_model.js](vendor/oasis/src/models/school_model.js): un curso sin precio se guarda como `0.000000` ([L320](vendor/oasis/src/models/school_model.js#L320)) y solo se protege si el precio es positivo o la visibilidad es `INVITE` ([L392-L393](vendor/oasis/src/models/school_model.js#L392-L393)): **la educación gratuita es el caso por defecto**. El certificado solo lo emite el autor del curso ([L1222](vendor/oasis/src/models/school_model.js#L1222)). Pero «gratuito» significa aquí «sin cobrar al alumno», no «pagado por el común»: la matrícula de pago es una transferencia `ECONOMIC` del alumno al autor ([L613-L616](vendor/oasis/src/models/school_model.js#L613-L616)) y nadie mantiene al maestro del curso gratuito. Y los exámenes solo existen en cursos de pago o por invitación ([L745](vendor/oasis/src/models/school_model.js#L745)): el curso gratuito certifica lecciones completadas ([L1242-L1243](vendor/oasis/src/models/school_model.js#L1242-L1243)), no pruebas. - [inhabitants_model.js](vendor/oasis/src/models/inhabitants_model.js): el censo es el conjunto de autores que han publicado algo ([L86-L88](vendor/oasis/src/models/inhabitants_model.js#L86-L88)). **Un feed, una persona.** No hay hogar, familia ni dependientes en ningún modelo. ### 2.8 Lo demás, en una línea `Courts` (juicio cifrado, jueces electos, ya auditado en otro nodo), `L.A.R.P.` (turno por casas), `Projects` (financiación con objetivo), `Tasks` (autoasignación), `Events` y `Calendars` (precio 0 posible), `Multiverse` (puentes a Mastodon y Telegram), `AI 42`. --- ## 3. Confrontación: los ocho criterios contra el código | # | Criterio colectivista | Estado en Oasis 1.0.7 | Veredicto | | :-- | :-- | :-- | :-- | | 1 | Asamblea soberana | Existe un parlamento de tribu que nace en `ANARCHY` con quórum del 25 % (`parliament_model.js:1354-1384`), pero no gobierna la tribu: campos, miembros y reparto están fuera de su alcance. `Polls` sin quórum ni umbral | ⚠️ **Parcial**: la asamblea existe y no manda | | 2 | Cargos rotatorios y revocables | El autor de la tribu y el steward de la instalación son vitalicios e irrevocables (`tribes_model.js:721`, `industry_model.js:510`); no hay ningún cargo electo salvo el gobierno de tribu | ❌ **Falla en la raíz** | | 3 | Propiedad colectiva | `Industry` exige voto para admitir y disolver, pero el medio de producción pertenece al autor del mensaje raíz (`industry_model.js:164`) y solo él reparte (`:980`). La tribu no tiene patrimonio | ❌ **Falla**: cooperativa de aportantes con propietario | | 4 | Distribución según necesidades | Industria: pro rata a puntos de trabajo *y capital* (`industry_model.js:306-321`, `:960-970`). RBU: suelo 1 y peso por karma de 0,2 a 6 (`banking_model.js:932`, `:941`). Sin hogar ni dependientes | ❌ **Reproduce el mérito**; el suelo es el único gesto de necesidad | | 5 | Derechos sociales | Educación gratuita por defecto (`school_model.js:320`); RBU con suelo inmovible; nada sobre enfermedad, jubilación ni edad; la jornada es un campo descriptivo de `Jobs` (`jobs_model.js:203-204`, `:228-229`), no un límite | ⚠️ **Parcial** | | 6 | Federación de abajo arriba | `parentTribeId` (`tribes_model.js:341`) es jerarquía padre-hijo de privacidad, descendente: la subtribu la crea el padre y **no tiene parlamento** (`backend.js:7799-7801`, `:8305`); no hay delegados, mandatos ni tesoro federado. «Federación» = conectarse a un PUB (`onboarding_model.js:5`, `:85-93`) | ❌ **Ausente**, con la pirámide invertida | | 7 | Intercambio sin moneda | Precio > 0 obligatorio en Market y Shops; `transfers` `TIME` y `couchsurfing` admiten lo no monetario; **también `jobs` con `salary` 0 y tipo `exchange` con horas y `exchangeSkill` (`jobs_model.js:200-201`, `:228-230`, `:334`) y `housing` con precio 0 en `rent` y `sale` (`nonNeg`, `housing_model.js:25-28`, `:317`); Market tiene un `item_type: "exchange"` obligado a precio positivo (`market_model.js:391-392`, `:182`)** (nota 2026-09-09, ficha 06) | ❌ **Falla**, con carriles de escape (`TIME`, `exchange` de Jobs, precio 0 en Housing) | | 8 | Voluntariedad | Entrada por invitación o abierta, salida libre para los miembros; **el fundador no puede irse** (`tribes_model.js:721`) y el steward tampoco (`industry_model.js:510`). Censo por actividad, sin coerción | ⚠️ **Parcial**: libre para todos menos para quien fundó | **Recuento.** 0 cumplen, 3 parciales, 5 fallan. Y sin embargo el sistema tiene, sin proponérselo, la pieza que más cuesta construir: una asamblea que existe por defecto. Los hallazgos que siguen ordenan el diagnóstico. ### A. La tribu es propiedad de su fundador `tribes_model.js` no tiene ninguna noción de asamblea, junta ni administrador: tiene un `author`. Ese autor genera invitaciones en modo estricto (L554-L556), no puede irse (L721) y su marcha forzada disuelve la comunidad (L726-L729). La rotación de claves al expulsar (L533-L541) convierte la lista de miembros en un dispositivo de lectura: quien la controla, controla quién puede ver. Es una monarquía con cifrado de extremo a extremo. Lo que una colectividad necesita es exactamente lo inverso: que la lista de miembros, los campos estructurales y las expulsiones sean actos de la asamblea. ### B. La asamblea existe y no manda Cada tribu nace con un `tribeParliamentTerm` en `ANARCHY`, sin líder (L1363-L1364), con quórum del 25 % (L1384) y con retorno automático a la anarquía si nadie lo alcanza (L1402-L1410). Bajo `ANARCHY` todos proponen (L1298-L1311). Eso **es** una asamblea permanente: cualquiera propone, nadie preside, la mayoría decide. Pero sus decisiones son texto en el log. No hay una sola función en `tribes_model.js`, `industry_model.js` ni `banking_model.js` que lea un resultado del parlamento de tribu. La asamblea tiene voz y no tiene manos. El parche no es inventarla: es darle competencias (CL-1, CL-5, CL-7). Y hay un segundo riesgo: el parlamento de tribu admite candidaturas con cualquier método de `METHODS` ([L1443-L1445](vendor/oasis/src/models/parliament_model.js#L1443-L1445)), así que una asamblea puede votarse un dictador de tribu. En la doctrina colectivista la asamblea elige comisiones, no gobiernos: CL-1 cierra esa puerta. ### C. Cooperativa de aportantes: trabajo y capital en la misma bolsa `computeShares` (L306-L321) es la fórmula de una sociedad de capital: una hora vale `laborRate` puntos, un euro de material vale un punto, un ECOin vale un punto, y quien más puntos tiene más se lleva (L960-L970). El `laborRate` lo fija el propietario (L438, L457). En una colectividad el reparto no sale de la aportación sino de la necesidad, y lo decide la asamblea (crit. 1 y 4). La estructura de votación de `Industry` (L98-L101, L211-L223) es reutilizable; lo que sobra es el steward vitalicio (L164-L205, L510, L980) y lo que falta es una `disposition` de necesidades (CL-2, CL-3). Tres costuras más (ficha 03, 2026-09-09): el aporte `material` se capitaliza como participación (`industry_model.js:824-831`, «Material contributions require a value above zero»), de modo que quien entra con una herramienta cobra por ella en cada lote; el valor del producto (`outputValue`) lo declara el steward al repartir (`:961`, `:986`) y nadie lo vota; y `updateFacility` propaga cualquier campo del `patch`, `license` y `laborRate` incluidos (`:457`, `:463`), sin voto. CL-2 y TK-G'07 los cierran. Hay un segundo cargo que esta auditoría no había nombrado: el `proposer` del lote ([L341](vendor/oasis/src/models/industry_model.js#L341)). El lote se aprueba por voto de los miembros ([L352-L353](vendor/oasis/src/models/industry_model.js#L352-L353)), pero quien lo propone se nombra a sí mismo responsable: solo él o el steward lo hacen avanzar ([L809](vendor/oasis/src/models/industry_model.js#L809)) o lo editan ([L869](vendor/oasis/src/models/industry_model.js#L869)); es el delegado de grupo de trabajo, sin elección ni revocación. Y el steward conserva un poder propio que ningún voto toca: declara solo el `outputValue` que forma el bote (`pot = treasury + outputValue`, [L961](vendor/oasis/src/models/industry_model.js#L961), [L985](vendor/oasis/src/models/industry_model.js#L985)); CL-3 lo incorpora al plan votable (ficha 02, huecos 4 y 5). ### D. Renta por mérito, no por necesidad La RBU es el único mecanismo con suelo y con techo (L941), y por eso es la mejor base para un salario familiar. Pero el peso `1 + karma/100` (L932) multiplica por hasta treinta la diferencia entre el más notorio y el más silencioso, y el karma premia publicar vídeos y comentar (§2.3). Un anciano que no publica cobra el suelo. Un hogar de cinco cobra lo mismo que uno de uno, porque el hogar no existe (L86-L88 de `inhabitants_model.js`). El parche es doble: coeficiente de necesidad en lugar de karma (CL-4) y unidad familiar declarada (CL-9). Hay un tercer defecto, anterior a la fórmula: el censo de la RBU no es la tribu ni el hogar, sino el conjunto de feeds con dirección ECOin válida ([L924](vendor/oasis/src/models/banking_model.js#L924)); la asignación nace `UNCLAIMED` y caduca a los 30 días si nadie la reclama ([L20](vendor/oasis/src/models/banking_model.js#L20), [L982](vendor/oasis/src/models/banking_model.js#L982)): quien no pide, no cobra. En la industria pasa lo mismo por otra vía: solo entra en el plan quien tiene importe positivo ([L966-L968](vendor/oasis/src/models/industry_model.js#L966-L968)) y sin puntos no hay reparto ([L984](vendor/oasis/src/models/industry_model.js#L984)). El salario familiar se cobraba sin haber trabajado y sin pedirlo: CL-3 y TK-B'06 cierran ambas puertas. ### E. El precio cero está prohibido `market_model.js:182` y `shops_model.js:415` rechazan cualquier precio no positivo. El don, el trueque y el reparto sin contrapartida no tienen representación en los módulos de intercambio. Existen dos grietas: `transfers` con categoría `TIME` (L25) y `couchsurfing` (L317). El criterio 7 se construye ensanchando esas grietas (CL-6), no inventando un módulo. **Nota (2026-09-09, ficha 06): las grietas son más de dos.** `jobs` admite `salary` 0 en cualquier tipo (`jobs_model.js:200-201`, `:334`) y su tipo `exchange` lleva `hoursOffered`, `hoursRequested` y `exchangeSkill` (`:228-230`): es un banco de tiempo ya escrito. `housing` admite precio 0 también en `rent` y `sale` (`nonNeg`, `housing_model.js:25-28`, `:317`). Market tiene un `item_type: "exchange"` (`market_model.js:391-392`) obligado a precio positivo (`:182`, `:252`): el trueque existe como etiqueta y está prohibido como número. Y ninguna compra liquida en cadena: `marketPurchase` y `shopPurchase` son mensajes sin pago (`market_model.js:634`, `shops_model.js:614`) y `PAID` lo declara el vendedor (`shops_model.js:26`, `:734`); en los cinco módulos no aparece `sendtoaddress`, `ecoin` ni `wallet`. El precio es un número declarado, no un cobro: quitar el `> 0` no rompe ninguna liquidación. Lo que ya está escrito para nosotros: el vale caduca (`deadline` obligatoria, `transfers_model.js:233-234`; `DISCARDED` al vencer, `:182-183`) y la RBU ya se paga como `transfer` etiquetado `UBI` (`banking_model.js:974-986`). ### F. No hay hogar: un feed, una persona El censo es la lista de autores con mensajes (L86-L88). Toda la aritmética de reparto (`Banking`, `Industry`) opera sobre feeds. El salario familiar histórico se calculaba por hogar, con escala por edad y dependientes. Sin una unidad familiar declarada y validada por la asamblea, el criterio 4 no puede ni formularse (CL-9). Y el censo, además de individual, es por actividad: la lista de habitantes oculta por defecto a quien lleva seis meses sin publicar (`bucket: 'red'`, [L65-L72](vendor/oasis/src/models/inhabitants_model.js#L65-L72); filtro en [L120](vendor/oasis/src/models/inhabitants_model.js#L120)). El anciano silencioso no solo cobra el suelo: deja de verse. El `household` de CL-9 no puede depender de la actividad de sus miembros. ### G. La anarquía como estado normal (donde el código ya es colectivista) `ANARCHY` no es elegible (L22-L23) y solo se alcanza por ausencia de quórum. Para un modelo estatal eso es un fallo; para una colectividad es la descripción exacta de su régimen: sin gobierno permanente, con asamblea abierta a todos y decisiones por mayoría. Este nodo **no toca** `ANARCHY` por defecto ni `canPropose` universal bajo `ANARCHY`. Es la única parte del código que ya estaba escrita para nosotros. --- ## 4. Especificación CL-OASIS: la bifurcación colectivista | # | Cambio | Punto de intervención | Criterio que repara | | :-- | :-- | :-- | :-- | | **CL-1** | **Gobierno de la tribu por su asamblea.** Edición de `STRUCTURAL_FIELDS`, invitaciones y expulsiones pasan de `tribe.author` a una `tribeParliamentRule` aprobada con el quórum del parlamento de tribu. **La asamblea no puede abdicar**: el parlamento de tribu solo admite `ANARCHY` (se eliminan las candidaturas a líder de tribu, `tribePublishCandidature`); las comisiones son cargos de CL-2, nunca gobierno | `tribes_model.js:11`, `:554-556`, `:612-617`, `:533-541` ← `parliament_model.js:1376-1384`, `:1443-1445` | 1, 2 | | **CL-2** | **Steward electo, rotatorio y revocable.** `steward` deja de ser `rootNode.author`; se elige por `passesThreshold` entre los miembros, con mandato de N lotes (default: N = 3 o un ciclo de 60 d, lo que venza antes; TK-D'09) y revocación por voto (`subject: "steward"`) **en cualquier momento y sin causa tasada**. **El índice sigue al steward electo, no al autor raíz**: los filtros `tn.author !== steward`, `n.author !== steward` y `x.author === steward` (`:167`, `:240`, `:379`) y las transiciones `stewardOnly` (`:357-361`) leen el cargo vigente. **Sin retribución especial**: el steward cobra por `computeShares` como cualquier miembro (`:306-321`, se conserva). El `outputValue` que hoy declara solo él (`:961`, `:985`) forma parte del plan votable de CL-3 | `industry_model.js:164`, `:167`, `:187`, `:205`, `:240`, `:357-361`, `:379`, `:510`, `:532`, `:961`, `:980`, `:985` | 2, 3 | | **CL-3** | **Reparto por necesidades, decidido por la asamblea.** `disposition: "needs"` en `computeDistributionPlan`: cada miembro declara su unidad de necesidad (CL-9), la asamblea de la instalación la valida por voto, y el reparto es proporcional a necesidades con suelo; el excedente va al tesoro de la tribu (CL-5). **La base del reparto `needs` es el censo de hogares de los miembros, no las aportaciones**: hoy solo entra en el plan quien tiene importe positivo (`industry_model.js:966-968`), no hay reparto sin puntos (`:984`) y solo cuentan aportaciones de miembros (`:372`); con `needs` un miembro sin puntos cobra su necesidad. El registro de horas (`:827`, `:85`) se conserva como cuenta de «cada uno según sus facultades», desligado del cobro. **El plan de reparto es una materia votable** (`subject: "distribute"` en `SUBJECTS`): nadie reparte sin acuerdo de la asamblea, ni siquiera el steward electo | `industry_model.js:960-970`, `:966-968`, `:984`, `:372`, `:306-321`, `:827`, `:532`, `:980` | 4, 3, 1 | | **CL-4** | **Coeficiente de necesidad en la RBU.** Sustituir `1 + karma/100` por `coef(hogar)` = 1 + 0,5 por dependiente, con edad; el karma sale de la fórmula. Suelo y techo se conservan **pero escalan con el hogar**: `floor_user × miembros` y `cap_user_epoch × coef(hogar)`; un techo por feed (`:19`) anularía el coeficiente en cuanto el fondo fuese holgado (`:941`). El denominador se unifica: en el pago real (`:1414`) los demás cuentan con peso 1, no con el suyo, y el importe pagado no coincide con el asignado (`:941`). La escala llega como `rules` de `computeEpoch` (`:920`, `:925`, `:928`), votada por la asamblea (CL-5), no como `DEFAULT_RULES` del operador (`:14-21`) | `banking_model.js:19`, `:920`, `:932`, `:941`, `:1300`, `:1413-1414` | 4 | | **CL-5** | **Tesoro de tribu.** Cartera colectiva multisig k-de-n cuyos firmantes nombra la asamblea; las épocas de reparto las ejecuta la asamblea de la tribu, no el operador del PUB. **Patrimonio** (ficha 03, 2026-09-09): nuevo tipo `tribeAsset` para instalaciones, planos y tierras (`housing` `land`) cuyo titular es la tribu y no un feed; el aporte `material` entra en el inventario colectivo sin generar participación ni renta y se devuelve al salir (default de TK-D'09); `sale` o `rent` de un `tribeAsset` solo por voto de la asamblea | `banking_model.js:913-917`, `:1004`, `:1413-1416`; `tribes_model.js` (nuevos tipos `tribeTreasury`, `tribeAsset`); `industry_model.js:824-831`; `housing_model.js:10`, `:374` | 1, 3 | | **CL-6** | **Precio cero, don y trueque.** Admitir `price = 0` y `kind: "gift" \| "barter"` en Market y Shops; **`barter` reutiliza el `item_type: "exchange"` que ya existe (`market_model.js:391-392`) y que hoy está obligado a precio positivo (`:182`, `:252`)**; vales = `transfers` `TIME` **nominativos, con doble confirmación y caducidad (`deriveStatus`, `transfers_model.js:175-185`), como ya hace la RBU con sus `transfer` etiquetados `UBI` (`banking_model.js:974-986`)**; caja de compensación entre tribus como `transfers` `TRUST` con saldo **(agregado nuevo por par de tribus: el fichero no tiene ningún saldo, `TRUST` es solo una etiqueta (`:26-29`) y `isValidId` solo acepta feeds como destinatario (`:12`), así que emite y recibe el tesoro de tribu de CL-5)**. **El precio se conserva hacia fuera: dentro de la tribu el don y el cupo son el default; Market con precio y tesoro de tribu para lo que la colectividad no produce** | `market_model.js:182`, `:252`, `:391-392`, `shops_model.js:415`, `transfers_model.js:12`, `:25`, `:26-29`, `:175-185`, `:230-231`; `banking_model.js:974-986` | 7 | | **CL-7** | **Quórum, umbral y duración mínima en las consultas de tribu.** `polls` y `votes` con `tribeId` heredan el quórum de `tribeElectionQuorum`; resultado vinculante publicado como `tribeParliamentRule` | `polls_model.js:84-86`, `votes_model.js:10`, `:173` ← `parliament_model.js:1376-1384` | 1 | | **CL-8** | **Federación con delegados mandatados.** `parentTribeId` deja de ser solo herencia de privacidad: la tribu hija elige un `delegate` con mandato firmado y revocable; la tribu madre solo decide con el voto de los delegados. **Cuatro condiciones que el código hoy niega**: (a) la subtribu tiene parlamento propio (se elimina «Sub-tribes have no governance»); (b) `parentTribeId` es un acto de la asamblea de la hija (adhesión y salida por voto), no del padre al crearla; (c) sin cascada de `tombstone` ni herencia forzosa de privacidad; (d) ninguna tribu puede presentarse en bloque al parlamento general: la federación se compone de delegados, nunca de una tribu vencedora (`FOLLOW_MAJORITY` tampoco es un mandato: delega en un agregado anónimo). Los acuerdos de la madre entran en vigor tras ratificación por las asambleas de las hijas | `tribes_model.js:341`, `:218-225`, `:490`; `parliament_model.js:1354-1374` (mandato de delegado), `:1206`, `:1303-1309`, `:1484-1492`; `backend.js:7799-7801`, `:7808`, `:8305`, `:8300-8316`; `votes_model.js:173` | 6, 8 | | **CL-9** | **Unidad familiar.** Tipo `household` sobre feeds individuales: miembros, edades y dependientes, validado por la asamblea de la tribu; base de CL-3 y CL-4 | `inhabitants_model.js:86-88` (censo) | 4 | | **CL-10** | **Derechos sociales.** Cursos con precio 0 por defecto se conservan (`school_model.js:320`); nuevo concepto en `Banking`: `epoch` de enfermedad y jubilación por edad declarada en `household`, pagado del tesoro de tribu (CL-5). Cada época especial es una variante de `rules` de `computeEpoch` (`banking_model.js:920`) con elegibles filtrados por `household` (edad, enfermedad validada por la asamblea) en vez de por dirección ECOin (`:924`), **exenta del impuesto de archivo** (`:38`, `:759-768`: grava los días de antigüedad del feed, es decir, a los más viejos) y **sin caducidad** de la asignación no reclamada (`:982`, `:1331-1341`). Con CL-4 la renta del jubilado, del enfermo y del maestro es la misma renta que la de cualquier miembro: no hay pensión ni nómina, hay salario familiar que no depende del trabajo. La jornada y las edades de trabajo son reglas de `Industry` y `Jobs` (TK-S'02); el maestro y el médico son puestos colectivos con salario familiar (TK-S'03) | `school_model.js:320`, `:392-393`, `:613-616`, `:745`; `banking_model.js:920-947`, `:924`, `:38`, `:759-768`, `:982`, `:1331-1341`; `industry_model.js:824-827`; `jobs_model.js:201`, `:203-204` | 5 | | **CL-11** | **Voluntariedad y salida.** El fundador puede irse con sucesión decidida por la asamblea (`opts.force` deja de ser necesario); el steward puede irse tras elección de sucesor; la disolución solo por voto. Los «individualistas» son feeds fuera de la tribu, sin penalización en la RBU. **Lo que se sucede no es una autoridad** (CL-1 la disuelve) **sino la custodia de claves**: `ensureTribeKeyDistribution` solo corre para el autor (`tribes_model.js:764-769`), `rotateTribeKey` (`:753`) se dispara desde sus escrituras y el validador del log privilegia al autor raíz (`:39-40`, `:158-166`, `:175`); el sucesor es un custodio electo por un ciclo y revocable (TK-G'07), nunca un nuevo fundador | `tribes_model.js:721`, `:726-729`, `:753`, `:764-769`, `:39-40`, `:158-166`, `:175`; `industry_model.js:510` | 8, 2 | **Lo que no se toca, y por qué.** `ANARCHY` como estado por defecto y `canPropose` universal bajo `ANARCHY` (`parliament_model.js:1298-1311`): es la asamblea permanente. El quórum de tribu `max(2, 25 %)` (`:1376-1384`): un suelo razonable hasta que el carril D' diga otra cosa. El `copyleft` por defecto de la instalación (`industry_model.js:439`) y de los planos (`:638`, `:670`); nota 2026-09-09 (ficha 03): el default se conserva, pero la licencia es cadena libre sin enumeración y el steward puede cambiarla sin voto (`:463`), de ahí TK-G'07. El cifrado de tribu y la rotación de claves como mecanismo (no como poder). El censo por actividad. El suelo inmovible de la RBU (`banking_model.js:941`). El registro de horas de trabajo por lote (`industry_model.js:827`, `:85`) y el `laborHours` de los planos (`:288`): es la cuenta de «cada uno según sus facultades», que CL-3 desliga del cobro pero no borra. Que `computeEpoch` reciba las reglas como parámetro (`banking_model.js:920`): la escala votada por la asamblea entra por ahí. Son buena economía moral escrita en aritmética. --- ## 5. Backlog v0 Leyenda: T = tamaño (S/M/L) · P = prioridad (C crítica, H alta, M media). Cada tarea D' tiene **camino por defecto**: si no se investiga, el carril siguiente usa el default; si se investiga y la respuesta difiere, la tarea dice qué cambia aguas abajo. ### Carril D' · Investigación en fuentes | ID | Buscar | Dónde | Default | Alternativas | Desbloquea | | :-- | :-- | :-- | :-- | :-- | :-- | | TK-D'01 | **Quién forma la asamblea y con qué quórum**: ¿todos los miembros?, ¿cabezas de familia?, ¿mayoría de presentes o de censo?; **convocatoria y periodicidad** (¿ordinaria fija?, ¿quién convoca la extraordinaria?); **voto a mano alzada o secreto**; ¿puede la asamblea delegar en un líder o un consejo? | Leval, Souchy; Casanova (Aragón); Simoni (Cretas) | Asamblea = todos los miembros de la tribu; quórum = 25 % del censo (el de Oasis) y mayoría simple de votantes. Asamblea ordinaria = ciclo de 60 d del `tribeParliamentTerm`; extraordinaria convocada por el 10 % de los miembros. Voto público (firmado, visible dentro de la tribu). **La asamblea no puede abdicar**: no elige líder (ver CL-1) | quórum del 50 %; voto por hogar (CL-9) en vez de por persona; voto secreto cifrado; consejo delegado revocable | CL-1, CL-7, TK-G'01, TK-G'06 *Verificado 2026-09-09 en [draftv1](draftv1.md): el default cambia.* | | TK-D'02 | **Fórmula del salario familiar**: por miembro, por edad, por dependientes; ¿escala fija o decidida por asamblea?; **¿cobran íntegro quienes no trabajan** (enfermos, ancianos, viudas, familias de milicianos en el frente)?; **¿parte fija por cabeza más parte por dependiente, o escala decreciente** por miembro adicional?; **¿en dinero, en vales o en carnet de consumo**, y con qué bienes libres fuera del salario?; **¿techo por hogar o por persona?** | Ovejero; Redalyc; Leval (casos de Aragón y Levante); Souchy (familias de combatientes) | coef = 1 + 0,5 por dependiente; menores y mayores de 65 cuentan como dependientes; la escala la fija la asamblea de la tribu. **La necesidad no depende de la aportación**: el hogar cobra aunque ningún miembro haya aportado puntos ni publicado nada en la época. Techo de época = `cap_user_epoch × coef(hogar)`, suelo = `floor_user × miembros`. Pago en ECOin al hogar; los vales (TK-E'02) son alternativa, no default | escala lineal por miembro; coef por edad en tramos; techo por persona; salario en vales `TIME` con bienes de primera necesidad a precio 0 | CL-3, CL-4, CL-9, TK-B'01, TK-B'03, TK-B'06 *Verificado 2026-09-09 en [draftv1](draftv1.md): el default cambia.* | | TK-D'03 | **Vales y cajas de compensación**: qué circulaba dentro (carnet de consumo, vales locales) y entre colectividades (compensación comarcal); **¿el carnet de consumo era cupo por familia (racionamiento) o saldo?**; **¿los vales caducaban y circulaban de mano en mano (endoso) o eran nominativos?**; **¿quién los emitía: la comisión de abastos o la asamblea?**; **¿la compensación comarcal era bilateral entre pueblos o multilateral por la federación (Congreso de Caspe, febrero 1937)?**; **¿con el exterior se pagaba en moneda republicana desde una caja común?** | Leval, Souchy; Gómez (economía confederal); Casanova (Congreso de Caspe) | Vales = `transfers` `TIME` dentro de la tribu, **nominativos, con caducidad (`deadline`) y emitidos por la comisión de abastos (cargo CL-2), sin endoso**; carnet de consumo = **cupo por `household` (CL-9) retirado del almacén de tribu (TK-E'04), no saldo**; compensación entre tribus = saldo `TRUST` **agregado por par de tribus y** liquidado por la federación **(hoy `transfers` no tiene saldo ni admite una tribu como destinatario, `transfers_model.js:12`; requiere CL-5)**; **con el exterior, Market con precio y tesoro de tribu** | moneda local ECOin por tribu; vales al portador endosables; sin compensación | CL-6, TK-E'01, TK-E'02, TK-E'04, TK-F'02 *Verificado 2026-09-09 en [draftv1](draftv1.md): el default cambia.* | | TK-D'04 | **Delegados comarcales**: mandato imperativo, duración, revocación, ¿voto por colectividad o ponderado por población?; **¿ratifican las asambleas los acuerdos del pleno o son ejecutivos?**; **adhesión y salida** de la federación (¿por acuerdo de asamblea?, ¿coexistencia con colectividades no federadas?); **distinguir** el Consejo de Aragón (órgano regional con partidos, octubre 1936 a agosto 1937) de la Federación Regional de Colectividades de Aragón (congreso de Caspe, febrero 1937): ¿cuál de los dos es el nivel regional del modelo? | Casanova (Consejo de Aragón y Federación Regional de Colectividades); Vela; Leval (Aragón, Levante) | Un delegado por tribu hija, mandato firmado por su asamblea, revocable en cualquier momento, voto por colectividad. Los acuerdos federales no vinculan hasta ratificación por las asambleas de las hijas; adhesión y salida = voto de la tribu hija; la federación no interviene en la administración interna; el nivel regional del modelo es la federación de colectividades, no un consejo de gobierno | voto ponderado por miembros; delegado rotatorio por sorteo; acuerdos federales ejecutivos con revocación a posteriori | CL-8, TK-F'01, TK-F'04, TK-F'05 *Verificado 2026-09-09 en [draftv1](draftv1.md): el default cambia.* | | TK-D'05 | **Individualistas**: condiciones de permanencia fuera de la colectividad, acceso a servicios, entrada posterior | Casanova; Redalyc (voluntariedad y coerción) | Los feeds fuera de la tribu conservan RBU y servicios de red; pueden pedir admisión por voto | exclusión de servicios de tribu; admisión automática | CL-11, TK-G'04 | | TK-D'06 | **Decreto de Colectivizaciones (24-10-1936) frente a la práctica aragonesa**: qué fijaba el decreto (consejos de empresa, control obrero) y qué hacían las colectividades agrarias | Decreto (BOGC); Vela; Casanova | Este nodo modela la práctica agraria (asamblea + comisión), no el decreto industrial catalán | modelar el consejo de empresa del decreto como variante | CL-1, CL-2 | | TK-D'07 | **Derechos sociales**: edades de trabajo, jornada, enfermedad y jubilación; ¿quién los pagaba?; **¿quién certificaba la enfermedad** (médico de la colectividad, asamblea)?; ¿maestros y médicos eran **miembros con salario familiar** o contratados de fuera?; **¿obligación de trabajar para los aptos** y qué pasaba con quien no lo hacía?; ¿servicios comarcales (hospital, escuela) financiados por la federación? | Redalyc; Ovejero; Leval (Levante: sanidad federada) | Jubilación y enfermedad pagadas del tesoro de tribu como época especial; edad declarada en `household`; enfermedad declarada por el miembro y validada por la asamblea, como el hogar (TK-B'02); maestro y médico = miembros con `job_type: "collective"` y salario familiar (TK-S'03); sin obligación de trabajar codificada: el suelo nunca se condiciona, la asamblea solo puede condicionar el excedente; servicios comarcales fuera de v0 (TK-F'03 si el carril F' lo pide) | pagadas de la RBU general; sin edad; certificación médica por cargo electo (CL-2); trabajo obligatorio con pérdida del excedente | CL-10, TK-B'05, TK-S'01, TK-S'02, TK-S'03 | | TK-D'08 | **Unidad familiar**: cómo se definía el hogar a efectos de reparto | Leval; Ovejero | `household` declarado por un miembro y validado por la asamblea; una persona pertenece a un solo hogar | hogar = feed (sin cambio); hogar autodeclarado sin validación | CL-9, TK-B'02 | | TK-D'09 | **Qué se colectivizó y en qué condiciones**: tierras comunales, incautadas, aportadas; ¿daba el aporte algún derecho (renta, voto, ración)?; ¿se devolvía lo aportado al salir, con o sin mejoras?; ¿vendía o alquilaba la colectividad tierras y talleres?; ¿quién fijaba el valor de la cosecha?; ¿se asignaba la vivienda en asamblea? | Casanova (Aragón); Decreto (24-10-1936); Leval (Aragón, Levante); Redalyc | El aporte no da participación ni renta; lo aportado se devuelve al salir sin mejoras; los medios de la tribu no se venden ni alquilan salvo voto; el valor del producto lo aprueba la asamblea con el plan de reparto, no el steward | aporte con participación temporal; sin devolución; venta por voto cualificado; vivienda fuera del modelo | CL-2, CL-3, CL-5, TK-G'07, TK-B'03 | | TK-D'09 | **Cargos de la colectividad**: composición de la comisión administrativa y de los consejos de empresa del decreto (¿cuántos miembros?, ¿qué funciones?); duración y renovación (¿anual?, ¿por mitades?), ¿límite de reelección?; revocación (¿por mayoría simple?, ¿en cualquier asamblea?); ¿cobraban los cargos algo distinto del salario familiar?, ¿había liberados?; ¿un cargo por persona?; ¿elegían los grupos de trabajo a su delegado? | Leval (comisiones y contabilidad); Souchy; Casanova; Ovejero; Decreto (consejos de empresa) | Steward y custodio de claves electos por un ciclo de 60 d (`TERM_DAYS`) o N = 3 lotes, lo que venza antes; reelección libre; revocación por `passesThreshold` en cualquier momento y sin causa tasada; sin retribución especial (el steward cobra por `computeShares` como cualquier miembro); un cargo por persona; delegado de lote = `proposer` confirmado por el voto del lote | mandato de dos años renovado por mitades (decreto); límite de dos mandatos seguidos; delegado de grupo electo aparte del proposer | CL-2, CL-11, TK-G'03, TK-G'07 | ### OP-01 · Autogobierno de la colectividad La asamblea de tribu recibe competencias sobre lo que hoy decide el fundador: campos, miembros, expulsiones, consultas vinculantes y cargos revocables. Carril G'. | ID | Tarea | Depende | Seam | T | P | | :-- | :-- | :-- | :-- | :-- | :-- | | TK-G'01 | CL-1: `tribeParliamentRule` gobierna `STRUCTURAL_FIELDS`, invitaciones y expulsiones; `tribe.author` deja de ser autoridad | D'01 | `tribes_model.js:11`, `:554-556`, `:612-617`, `:533-541` | L | **C** | | TK-G'02 | CL-7: quórum y umbral en `polls`/`votes` con `tribeId`; resultado publicado como regla | D'01 | `polls_model.js:84-86`, `votes_model.js:10`, `:173` | M | H | | TK-G'03 | CL-2: steward electo por `passesThreshold`, mandato de N lotes (default N = 3 o un ciclo de 60 d), `subject: "steward"` revocable en cualquier momento; el índice sigue al steward electo, no al autor raíz | D'06, D'09 | `industry_model.js:164`, `:167`, `:240`, `:357-361`, `:379`, `:532`, `:510`, `:980` | L | H | | TK-G'04 | CL-11: sucesión del fundador por asamblea; salida libre del steward tras elección | D'05 | `tribes_model.js:721`, `:726-729`; `industry_model.js:510` | M | H | | TK-G'05 | Publicidad: la deliberación de la asamblea (propuestas y votos) visible a todos los miembros; el cifrado de tribu sigue protegiendo hacia fuera | D'01 | `polls_model.js:45-60` | S | M | | TK-G'06 | Convocatoria y periodicidad: asamblea ordinaria = ciclo de 60 d del `tribeParliamentTerm`; `assemblyCall` extraordinaria por el 10 % de los miembros abre una ventana de propuestas; solo `ANARCHY` como método de tribu | D'01 | `parliament_model.js:1354-1374`, `:1443-1445` | M | H | | TK-G'07 | Patrimonio de la instalación: `license` y `laborRate` pasan a materia votable (`subject: "facility"` en `SUBJECTS`); `outputValue` se aprueba con el plan de reparto (CL-3); el aporte `material` deja de generar puntos en `computeShares` y entra en el inventario del `tribeAsset` (CL-5) | D'09, G'03 | `industry_model.js:439`, `:463`, `:532`, `:306-321`, `:824-831`, `:961`, `:986` | M | H | | TK-G'07 | Custodio de claves como cargo: `tribeKeeper` electo por la asamblea por un ciclo de 60 d y revocable; `ensureTribeKeyDistribution`, `rotateTribeKey` y el privilegio de `isRootAuthor` en el índice pasan del autor raíz al custodio vigente; ejecuta los acuerdos de CL-1 sin decidirlos | D'09, G'01 | `tribes_model.js:39-40`, `:158-166`, `:175`, `:753`, `:764-769` | L | H | ### OP-02 · Reparto por necesidades Salario familiar sobre la RBU y sobre la industria; unidad familiar; tesoro de tribu. Carril B'. | ID | Tarea | Depende | Seam | T | P | | :-- | :-- | :-- | :-- | :-- | :-- | | TK-B'01 | CL-4: `coef(hogar)` sustituye a `1 + karma/100` en los tres cálculos | D'02, B'02 | `banking_model.js:932`, `:1300`, `:1413` | M | **C** | | TK-B'02 | CL-9: tipo `household` (miembros, edades, dependientes) validado por la asamblea | D'08 | `inhabitants_model.js:86-88` | M | **C** | | TK-B'03 | CL-3: `disposition: "needs"` en `computeDistributionPlan`, excedente al tesoro; `subject: "distribute"` votable | D'02, B'02, G'03, D'01 | `industry_model.js:960-970`, `:306-321`, `:532`, `:980` | M | H | | TK-B'04 | CL-5: `tribeTreasury` multisig k-de-n; épocas ejecutadas por la asamblea, no por `isPubNode` | D'01 | `banking_model.js:913-917`, `:1004`, `:1413-1416` | L | H | | TK-B'05 | CL-10: épocas de enfermedad y jubilación pagadas del tesoro de tribu; elegibles por `household` en vez de por dirección ECOin, exentas de `archTax`, sin caducidad de la asignación no reclamada | D'07, B'02, B'04 | `banking_model.js:920-947`, `:924`, `:38`, `:759-768`, `:982`, `:1331-1341` | M | M | | TK-B'06 | Cobro sin reclamación ni aportación: la RBU se asigna por `household` (CL-9) y no por dirección ECOin; la asignación no caduca a los 30 d (`graceDays`) para hogares validados; suelo y techo escalan con el hogar; el pago usa el mismo denominador que el plan | D'02, D'08, B'02 | `banking_model.js:19-20`, `:924`, `:982`, `:1414` | M | H | ### OP-03 · Intercambio sin precio Don, trueque y vales dentro de la colectividad. Carril E'. | ID | Tarea | Depende | Seam | T | P | | :-- | :-- | :-- | :-- | :-- | :-- | | TK-E'01 | CL-6: `price = 0` y `kind: gift \| barter` en Market y Shops; `barter` = `item_type: "exchange"` liberado del `> 0`; el cambio es solo de validación porque `marketPurchase` y `shopPurchase` no pagan nada | D'03 | `market_model.js:182`, `:252`, `:391-392`, `:634`; `shops_model.js:415`, `:614` | S | H | | TK-E'02 | CL-6: vales de tiempo = `transfers` `TIME` nominativos: emisor = comisión de abastos (cargo CL-2), cierre por confirmación del receptor (`deriveStatus`), caducidad por `deadline`; sin endoso a terceros (el vale se consume, no circula); el carnet de consumo sale de aquí y pasa a TK-E'04 | D'03, G'03 | `transfers_model.js:25`, `:175-185`, `:230-231`, `:243`, `:339` | M | M | | TK-E'03 | Bolsa de trabajo por asamblea: `jobs` con `job_type: "collective"` sin `salary`, asignado por voto; parte del tipo `exchange` (`hoursOffered`, `hoursRequested`, `exchangeSkill`) y de que `salary` 0 ya es legal en cualquier tipo | D'02 | `jobs_model.js:192`, `:200-201`, `:228-230`, `:334` | M | M | | TK-E'04 | Carnet de consumo: el almacén de la colectividad es una `shop` de la tribu; el pedido `shop-purchase` sin precio descuenta un cupo por `household` fijado por la asamblea; `RECEIVED` lo firma el consumidor y `PAID` desaparece (hoy `PAID` lo declara el vendedor y la compra no paga nada) | D'03, B'02, E'01 | `shops_model.js:26-28`, `:592-616`, `:636-651`, `:731-734` | M | M | ### OP-04 · Federación Colectividad → comarcal → regional con delegados mandatados y compensación entre colectividades. Carril F'. | ID | Tarea | Depende | Seam | T | P | | :-- | :-- | :-- | :-- | :-- | :-- | | TK-F'01 | CL-8: `delegate` con mandato firmado y revocable; la tribu madre decide solo con voto de delegados | D'04, G'01 | `tribes_model.js:341`; `parliament_model.js:1354-1374` | L | H | | TK-F'02 | Caja de compensación: saldos `TRUST` entre tribus liquidados por la federación; requiere (a) un agregado de saldo por par de tribus, que `transfers` no tiene (`TRUST` es solo una etiqueta), y (b) que el tesoro de tribu (CL-5) sea emisor y destinatario, porque `isValidId` solo acepta feeds | D'03, B'04 | `transfers_model.js:12`, `:25`, `:26-29`, `:175-185` | M | M | | TK-F'03 | Tesoro federado: `tribeTreasury` de la tribu madre alimentado por cuotas votadas por las hijas | B'04, F'01 | nuevo | L | M | | TK-F'04 | CL-8: adhesión y salida federal por asamblea: `parentTribeId` lo fija la tribu hija por voto (no el padre al crearla); la subtribu recupera parlamento propio; sin cascada de `tombstone`; visibilidad propia | D'04, G'01 | `backend.js:7799-7801`, `:7808`, `:7820`, `:8305`; `tribes_model.js:218-225`, `:490` | M | H | | TK-F'05 | CL-8: ratificación: los acuerdos de la tribu madre se publican a las hijas y entran en vigor tras el voto de N asambleas; ninguna tribu puede presentarse en bloque al parlamento general | F'01, G'02 | `parliament_model.js:1484-1492`, `:1206`, `:1303-1309`; `backend.js:8300-8316`, `:8354` | M | M | ### OP-05 · Derechos sociales | ID | Tarea | Depende | Seam | T | P | | :-- | :-- | :-- | :-- | :-- | :-- | | TK-S'01 | Documentar que la educación gratuita es el caso por defecto y que el certificado lo emite solo el autor: ¿certifica la asamblea? Precisar que «gratis» en Oasis significa «maestro sin cobrar» (la matrícula de pago es una transferencia `ECONOMIC` del alumno al autor, `:613-616`; la de precio 0 no genera nada), no «pagado por el común»; y que los exámenes solo existen en cursos de pago o por invitación (`:745`): el curso gratuito certifica lecciones completadas, no pruebas (`:1242-1243`) | D'07, S'03 | `school_model.js:320`, `:613-616`, `:745`, `:1222`, `:1242-1243` | S | M | | TK-S'02 | Jornada y edades de trabajo como reglas de `Industry` y `Jobs`: horas máximas por lote, miembro y semana en la contribución de trabajo (hoy solo exige `hours > 0`, `:827`; el `laborHours` del plano es una estimación de coste, `:632`, no un límite); edad mínima y máxima leídas de `household`; `job_time` y `hoursOffered`/`hoursRequested` de `Jobs` describen la jornada pero no la acotan | D'07, B'02 | `industry_model.js:824-827`, `:632`, `:306-321`; `jobs_model.js:203-204`, `:228-229` | M | M | | TK-S'03 | Maestro y médico como puestos colectivos: `jobs` con `job_type: "collective"` y `salary` 0 (ya admisible: `:201`, `:334`), asignados por voto de la asamblea; cobran el salario familiar (CL-4), no por acto ni por alumno; la sanidad no tiene módulo y se modela como puesto, no como mercado | D'07, E'03, B'01 | `jobs_model.js:201`, `:334`; `school_model.js:613-616` | M | M | ### OP-06 · Voluntariedad y censo | ID | Tarea | Depende | Seam | T | P | | :-- | :-- | :-- | :-- | :-- | :-- | | TK-V'01 | Individualistas: feeds fuera de la tribu conservan RBU y servicios de red | D'05 | `banking_model.js:920-947` | S | H | | TK-V'02 | Disolución de la tribu solo por voto (nunca por marcha del fundador) | G'04 | `tribes_model.js:726-729` | S | H | ### Resumen de prioridades v0 | Prioridad | Tareas | | :-- | :-- | | **Crítica** | TK-G'01, TK-B'01, TK-B'02 | | **Alta** | TK-G'02, TK-G'03, TK-G'04, TK-G'06, TK-G'07, TK-G'07, TK-B'03, TK-B'04, TK-B'06, TK-E'01, TK-F'01, TK-F'04, TK-V'01, TK-V'02 | | **Media** | TK-G'05, TK-B'05, TK-E'02, TK-E'03, TK-E'04, TK-F'02, TK-F'03, TK-F'05, TK-S'01, TK-S'02, TK-S'03 | Mapa de carriles: **D' → G' → B' → E' → F'**; OP-05 y OP-06 corren en paralelo sobre B' y G'. El carril de cadena (Faircoin3 o ECOin) no se abre en este nodo: todo el reparto vive en Oasis. --- ## 6. Fuentes **Código auditado (disco):** `vendor/oasis` @ `9a657b776fcafc7c24bf3ad61825316385ecf513` (release 1.0.7, 2026-09-08). Clonado con `git clone --depth 1 https://github.com/epsylon/oasis.git`. **Red:** `faircoin/faircoin` (último push 2022-02-05, API de GitHub, 2026-09-09). **Doctrina:** `draft.md` §1 (Souchy 1937, Leval 1972, Casanova 1988, Ovejero 2015, Vela 2013, Redalyc 2016). Sin páginas: todo lo doctrinal es **[doctrina, sin verbatim]** hasta que el carril D' lo verifique. **Grado de certeza.** Cuatro niveles: *verificado en código con fichero y línea* (todo §2 y §3) · *fuente primaria del proyecto, no verificada de forma independiente* (README de Oasis) · *inferido de la actividad del repositorio* (estado de Faircoin) · *paráfrasis marcada, no cita* (criterios 1-8).