Referencia de ingeniería del informe «Aguas Arriba»: los puntos exactos — fichero:línea sobre los commits fijados — donde el catálogo modelador-redes lee vuestro código, y las costuras (seams) que su backlog propone tocar si alguna vez se implementa. Nada de esto está ejecutado.
Advertencia de verificación: las líneas citadas fueron localizadas
sobre los clones pineados al redactar el plan de vendorización, con la regla «releer cada
línea al escribir». Este documento las reproduce de esa fuente; antes de citarlas en un
issue, contrastadlas contra el SHA — el propio catálogo obliga a ello:
scripts/vendor.sh --check falla con DERIVA si un clon no está en su
commit.
Una sola fuente de verdad y un script idempotente. Vuestro código queda en
vendor/ (ignorado por git), jamás en nuestro árbol.
12 entradas {id, repo, sha, fecha, licencia, por_defecto, proposito}.
Validación en build: ids únicos ^[a-z0-9-]+$, SHA de 40 hex, repo https,
la entrada oasis debe coincidir con el SHA auditado.
--check: rev-parse HEAD == sha; si no, DERIVA y exit 1. Nunca toca un clon existente.init + fetch --depth 1 origin <sha> + checkout FETCH_HEAD.--only id… · --all · --list.En la web y el zip, toda ruta vendor/<id>/ruta#Lx-Ly se reescribe a
github.com/<repo>/blob/<sha>/ruta#Lx-Ly (directorios →
tree/<sha>): el lector siempre aterriza en el commit fijado, nunca en
vuestro HEAD. Ningún código de terceros viaja en los zips.
Lo que la auditoría lee y lo que observó. El «seam» de Banking son 14 métodos RPC hacia el daemon.
| Sitio | Hecho observado |
|---|---|
| banking_model.js:1004, :1416 | el dinero solo sale por sendtoaddress; no hay otra vía de gasto en el módulo |
| banking_model.js (seam RPC) | timeout de 1500 ms con reintento → posible doble envío |
| banking_model.js | validación de dirección por regex ^E repetida ×12 · literal coin:"ECO" ×7 (multi-moneda exigiría parametrizar) |
| banking_model.js | processPendingClaims ≠ computeEpoch · el hash de época no se publica (verificación externa imposible) |
| POST /update | borra src/configs/*.json trackeados — actualizar pisa configuración local |
| banking_model.js:832-840 | el karma pesa en operaciones — el backlog lo saca de la política (RP-4/TK-32) |
| transfers_model.js:25, :230-231, :233-234 | categorías ECONOMIC / TIME / TRUST · importe positivo obligatorio · deadline obligatoria en createTransfer |
| parliament_model.js:17-26, :28 | constantes de gobierno (TERM_DAYS 60, umbral 25 %) y ventana electoral termWindowFor / resolveElectionImpl |
| parliament_model.js:1102, :1145-1147, :1298 | enactApprovedChanges promulga al morir el mandato · derogación sin memoria · canPropose abierto |
| parliament_model.js:373-393 | virtualAnarchyTerm: qué pasa cuando nadie gobierna |
| courts_model.js:139-155, :368, :805 | nominateJudge/voteNomination (jueces electos, modo DICTATOR presente) · el karma ordena candidaturas |
| larp_model.js:576 | transparencia del gobernante: dato existente, sin vista (RP-10/TK-36) |
Hecho sin adjetivo: sin commits desde 2022-02-05, código completo, compila
con depends/, citable. Proof-of-Cooperation con firmas CVN.
| Sitio | Qué hay |
|---|---|
| src/poc.cpp:944 | CheckProofOfCooperation — validación del bloque PoC |
| src/poc.cpp:1209 | CheckNextBlockCreator — turno del CVN creador |
| src/poc.cpp:525, :698 | CvnVerifyChainSignature · CheckAdminSignature(…, fCoinSupply) — la emisión exige firma admin |
| src/poc.cpp:882, :902, :915 | UpdateChainAdmins · SetCoinSupplyStatus · UpdateChainParameters |
| src/chainparams.cpp:89-96, :109-110 | dynParams y vChainAdmins[0] con pubkey hardcodeada (testnet :194-195, regtest :279-280; validación :351-387) — génesis nuevo = recompilar… |
| fairchains/src/fairchains-tool.cpp:253-254, :308-313, :357 | …o no: CreateGenesisBlock con vCvns/vChainAdmins desde JSON, sin recompilar |
| src/init.cpp:1118-1131 | -cvn=fasito|file — llave física o cvn.pem (usos en poc.cpp:67, :2030, :2302; firmware en vendor/fasito) |
| src/rpc/cvn.cpp:59, :113, :820, :913, :1116, :1185, :1219 | getactivecvns · getactiveadmins · addcvn · removecvn · fasito · bancvn · setchainparameters |
| src/rpc/client.cpp:100-105 | addcoinsupply — la única puerta de emisión (nota: getinfo.coinsupply, no moneysupply; no existe getmininginfo) |
| doc/on-proof-of-cooperation.md:19, :37 · doc/CVN-operators-guide.md:101, :128 | doctrina original: «Who's next», Fasito, criterios socio-políticos de alta de CVN (§4.1) y remoción (§4.5) |
Cada RPC admin queda subordinado a una regla política del modelo: ningún
acto de cadena sin ley promulgada (lawId). Es la tesis técnica central del
roadmap.
| Tarea | Costura | Regla política que la gobierna |
|---|---|---|
| TK-C01 | addcvn / removecvn / bancvn | admisión de CVN por doble voto (tribu + general); admin = ejecutivo electo |
| TK-C02 | setchainparameters ↔ UpdateChainParameters | cambiar parámetros de cadena = ley promulgada, nunca decreto |
| TK-C03 | addcoinsupply ↔ CheckAdminSignature(fCoinSupply) | emisión solo a tesoro multifirma k-de-n, dentro del presupuesto del ciclo |
| TK-C04 | génesis con fairchains-tool (JSON) | cadena nueva; no se recompila chainparams ni se toca la vuestra |
| TK-C05 | -cvn=file vs Fasito | custodia de claves con topes y cargos revocables |
| TK-C06 | guía CVN §4.1 / §4.5 | certificación y remoción de operadores con criterios escritos |
| TK-84 | CLI de admin | rechaza todo acto sin lawId — el mapa acción↔ley es ejecutable |
Lo que cualquiera puede correr sobre el catálogo para comprobar que esto es verdad y sigue siéndolo:
# los 12 clones están exactamente en su commit (nunca en vuestro HEAD) scripts/vendor.sh --check # → 12 OK, exit 0; deriva → exit 1 scripts/vendor.sh --list # tabla id · repo · sha · licencia # el manifiesto es coherente y la web no cita nada fuera de los SHA .venv/bin/modelador check grep -r "base/teoria/vendor" public/ # → vacío git ls-files | grep vendor # → vacío: nada vuestro en nuestro árbol # las marcas de opinión están erradicadas del catálogo grep -rniE "muert|cero líneas|no se vendoriza" README.md THIRD_PARTY.md llms.md # → sin resultados