Compare commits
32
Commits
codeowners
...
r33-docs
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
e54e6cbe89 | ||
|
|
556c75c46f | ||
|
|
91480ebb1a | ||
|
|
6e16965e9b | ||
|
|
50f1e5e1b7 | ||
|
|
d55d8e91a2 | ||
|
|
b9dcacd76e | ||
|
|
c17ac080cb | ||
|
|
fae57e3b4f | ||
|
|
3ec9b2cfb3 | ||
|
|
f9e54ad675 | ||
|
|
29225fc293 | ||
|
|
f6f39c7833 | ||
|
|
0fe80d0dca | ||
|
|
e610a85fe9 | ||
|
|
266706322e | ||
|
|
1b495d7117 | ||
|
|
6b1b2f83b7 | ||
|
|
5cc3fd6419 | ||
|
|
3a9d8f3e7a | ||
|
|
a550d50c2f | ||
|
|
5e139970e7 | ||
|
|
fae7ebe3c2 | ||
|
|
845609e9fa | ||
|
|
fe1b8a9b67 | ||
|
|
b38d8e1332 | ||
|
|
9caf71cecc | ||
|
|
ecc8835bd4 | ||
|
|
6b1fe439c7 | ||
|
|
37e2ddb4bc | ||
|
|
385c39ba3e | ||
|
|
8529c2b349 |
@@ -15,6 +15,12 @@ jobs:
|
||||
run:
|
||||
shell: bash --noprofile --norc -eo pipefail {0}
|
||||
steps:
|
||||
- name: "r31 guard: CI nunca opera en /srv/*"
|
||||
run: |
|
||||
case "$PWD" in
|
||||
/srv/*) echo "VIOLACION: workspace de CI en $PWD"; exit 1 ;;
|
||||
*) echo "workspace OK: $PWD" ;;
|
||||
esac
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 1
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
# BTCPay Server Plugin: Event & Travel Integration (V1)
|
||||
|
||||
## 1. Data Sources & Verification
|
||||
- Event data: Curated from hardcap.news RSS/API feed (events aggregated by Cayce runtime §9). Source list documented in `sources/` directory with QC-3 citations.
|
||||
- Lodging data: `bitcoinhotels.org` static listings API. No real-time availability checking in V1 - listings are curated, not live.
|
||||
- Verification: Event dates/coords verified against hardcap.news primary sources only. No automated scraping of third-party calendars.
|
||||
|
||||
## 2. Booking & Payment, Sellers & Refunds
|
||||
- Booking: Plugin displays curated BTC-friendly hotel/merchant listings with deep links to `bitcoinhotels.org`. Reservation/payment occurs off-site via the hotel's own system.
|
||||
- Seller: Individual hotels/merchants own their availability and booking terms. The plugin has no inventory control.
|
||||
- Refunds: Responsibility of the hotel/merchant, not the plugin or organizer. Plugin displays refund policy links where provided by the hotel.
|
||||
- Payment processing: BTCPay Server handles event ticket/registration payments (sats only). No hotel payments flow through BTCPay in V1.
|
||||
|
||||
## 3. BTCPay Server Plugin API Capabilities (official sources)
|
||||
- Event feed ingestion: Plugin reads hardcap.news event RSS feed (curated by Cayce). Auto-generates event landing pages on bitcoinhotels.org.
|
||||
- Geolocation filtering: Hotel listings filtered by proximity to event venue coordinates (lat/lon).
|
||||
- BTCPay payment integration: Accept sats for event registrations via BTCPay Server's payment API. Plugin creates order → attendee pays → organizer receives notification.
|
||||
- Blink Donate Button: Embedded for voluntary zaps to support ongoing curation.
|
||||
- Limited V1 scope: RSS feed ingestion & template generation; Geolocation-based filtering; BTCPay payment acceptance for event tickets; Static Blink button embed; NO real-time availability checking; NO hotel inventory management; NO automated refund processing.
|
||||
|
||||
## 4. Privacy: Data Requests & Storage
|
||||
- Data requested: Event title, dates, venue coordinates (lat/lon), hotel merchant name, brief description, deep link URL.
|
||||
- Data storage: Event coords stored in plugin's `data/events.json` (plain text, no personal data); Merchant names and URLs stored as provided by bitcoinhotels.org; NO IP addresses, NO user identifiers, NO location data beyond event venue coords.
|
||||
- Privacy rule: No "zero KYC" claims without substantiation. All data is publicly derivable from the event and hotel listings. No user tracking.
|
||||
|
||||
## 5. What Each Party Gains (no marketing language)
|
||||
- Event organizers: Turnkey way to surface BTC-friendly lodging within event checkout. No platform fees. BTC-only payments expand circular economy.
|
||||
- Attendees: Find BTC-friendly lodging without leaving event checkout. Pay with sats. Merchant choices are curated (no altcoin-promoting hotels).
|
||||
- Hotel merchants: Exposure to Bitcoin-targeted audience. No platform fees for listing. Direct booking relationship.
|
||||
- Cayce/bitcoinhotels: Continuous curation output. Plugin is open-source under MIT license. Long-term sustainability via hardcap.news adinaction and Nostr zap-gating.
|
||||
|
||||
## 6. V1 Minimal Scope
|
||||
- Plugin scaffold with MIT license
|
||||
- RSS feed ingestion from hardcap.news (events list)
|
||||
- Landing page template on bitcoinhotels.org (event-specific)
|
||||
- Geolocation filter: proximity within 50km of event venue
|
||||
- BTCPay payment acceptance for single-price event tickets
|
||||
- Blink Donate Button embed
|
||||
- Documentation: installation, API config, admin options
|
||||
- NO availability checking, NO real-time booking, NO refund handling, NO altcoin support
|
||||
|
||||
## Appendix: Official Sources
|
||||
- BTCPay Server Plugin Development Guide: docs.btcpayserver.org/developer/plugins
|
||||
- BTCPay Server API docs: docs.btcpayserver.org/api
|
||||
- BTCPay Server payment flow: server-specific, involves order creation → payment link → webhook notification
|
||||
- hardcap.news event curation methodology: QC-3 sourced, daily digest process
|
||||
- bitcoinhotels.org listing format: static CSV/JSON, merchant-owned availability
|
||||
@@ -0,0 +1,17 @@
|
||||
[Unit]
|
||||
Description=Cayce promo — publicación temática autónoma (FB+IG vía sfeed)
|
||||
After=network-online.target
|
||||
Wants=network-online.target
|
||||
|
||||
[Service]
|
||||
User=ubuntu
|
||||
# r31 (P1): corre desde el checkout del repo entity; estado en /var/lib/cayce/promo
|
||||
WorkingDirectory=/srv/cayce-core/social
|
||||
Environment=NODE_ENV=production
|
||||
Environment=PROMO_STATE_HOME=/var/lib/cayce/promo
|
||||
EnvironmentFile=/var/lib/cayce/promo/.env
|
||||
ExecStart=/usr/bin/node /srv/cayce-core/social/promo.mjs
|
||||
Restart=no
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
@@ -0,0 +1,10 @@
|
||||
[Unit]
|
||||
Description=Cayce promo cycle — cada 6h (publica lo debido de la campaña)
|
||||
|
||||
[Timer]
|
||||
OnCalendar=*-*-* 09,13,15,19,21,01:00:00 UTC
|
||||
RandomizedDelaySec=300
|
||||
Persistent=true
|
||||
|
||||
[Install]
|
||||
WantedBy=timers.target
|
||||
@@ -0,0 +1,11 @@
|
||||
# /usr/local/bin versionado
|
||||
|
||||
Copias exactas de los scripts de infra que viven en /usr/local/bin del VPS.
|
||||
Actualizar: PR aquí → merge → copiar al VPS (sudo cp) + daemon-reload si toca unit.
|
||||
|
||||
- cayce-autodeploy (r31: flock compartido /run/lock/cayce-git-ops.lock)
|
||||
- cayce-auto-merge (r31: mismo lock, espera hasta 240s)
|
||||
|
||||
El lockfile lo crea tmpfiles.d: /etc/tmpfiles.d/cayce-locks.conf
|
||||
(f /run/lock/cayce-git-ops.lock 0664 root ubuntu -). Ops manuales con git
|
||||
sobre /srv/*: flock /run/lock/cayce-git-ops.lock <comando>.
|
||||
Executable
+46
@@ -0,0 +1,46 @@
|
||||
#!/bin/bash
|
||||
# Auto-merge (ronda-9): SOLO PRs con todos los checks en success y que NO
|
||||
# toquen paths protegidos. Nunca btcpay-events. Nunca credenciales del operador.
|
||||
# r19: el token persiste en /etc/cayce/ci-bot.token (600). Regenerar con nombre
|
||||
# ya usado da ERROR y dejaba BOT vacio (bug historico: el script no hacia nada).
|
||||
# r31 (S1): lock compartido con cayce-autodeploy — nunca compiten sobre los
|
||||
# mismos arboles/branches (incidente 02:06:29Z del 2026-11-03).
|
||||
LOCK=/run/lock/cayce-git-ops.lock
|
||||
exec 9>"$LOCK" || { echo 'FATAL: no se puede abrir lockfile'; exit 1; }
|
||||
if ! flock -w 240 9; then
|
||||
echo "[auto-merge] autodeploy mantiene el lock >240s — paso de este ciclo (el proximo mergea)"
|
||||
exit 0
|
||||
fi
|
||||
BOT=$(cat /etc/cayce/ci-bot.token 2>/dev/null | tr -d '[:space:]')
|
||||
if [ -z "$BOT" ]; then
|
||||
BOT=$(sudo -u git /usr/local/bin/gitea --config /etc/gitea/app.ini admin user generate-access-token -u ci-bot -t "auto-merge-$(date +%s)" --scopes write:repository,write:issue 2>/dev/null | grep -aoE "[0-9a-f]{40}" | head -1)
|
||||
[ -n "$BOT" ] && printf '%s' "$BOT" > /etc/cayce/ci-bot.token && chmod 600 /etc/cayce/ci-bot.token
|
||||
fi
|
||||
[ -z "$BOT" ] && { echo 'FATAL: sin token ci-bot'; exit 1; }
|
||||
G="http://127.0.0.1:3100/api/v1"
|
||||
# paths protegidos (grep -E contra la lista de ficheros modificados del PR)
|
||||
PROTECTED="SPEC.md|MANDATE.md|prompts/cayce-identity.md|guard[^/]*\.|relay-watcher|outbox\.mjs|guard-blocklist|check-single-outbox|\.gitea/workflows|\.github/workflows|cayce-auto-merge|act_runner|docker"
|
||||
for REPO in cayce-ops entity bitcoinhotels; do
|
||||
curl -s -H "Authorization: token $BOT" "$G/repos/cayce/$REPO/pulls?state=open&limit=20" | python3 -c "
|
||||
import json,sys
|
||||
for p in json.load(sys.stdin):
|
||||
if p.get('title','').upper().startswith('WIP'): continue
|
||||
print(p['number'], p['head']['sha'])" 2>/dev/null | while read N SHA; do
|
||||
FILES=$(curl -s -H "Authorization: token $BOT" "$G/repos/cayce/$REPO/pulls/$N/files?limit=100" | python3 -c "
|
||||
import json,sys
|
||||
for f in json.load(sys.stdin): print(f.get('filename',''))" 2>/dev/null)
|
||||
if echo "$FILES" | grep -qE "$PROTECTED"; then
|
||||
echo "$REPO #$N: TOCA PATH PROTEGIDO — no se auto-mergea"
|
||||
continue
|
||||
fi
|
||||
# r19: /status (combinado) en vez de /statuses — la lista incluye los
|
||||
# 'pending' historicos y hacia que un PR verde pareciera no verde
|
||||
OK=$(curl -s -H "Authorization: token $BOT" "$G/repos/cayce/$REPO/commits/$SHA/status" | python3 -c "
|
||||
import json,sys
|
||||
d = json.load(sys.stdin)
|
||||
print('yes' if isinstance(d, dict) and d.get('state') == 'success' else 'no')" 2>/dev/null)
|
||||
if [ "$OK" = "yes" ]; then
|
||||
curl -s -X POST -H "Authorization: token $BOT" -H "Content-Type: application/json" -d '{"Do":"merge"}' "$G/repos/cayce/$REPO/pulls/$N/merge" -o /dev/null -w "$REPO #$N (green, sin paths protegidos) merge: %{http_code}\n"
|
||||
fi
|
||||
done
|
||||
done
|
||||
Executable
+200
@@ -0,0 +1,200 @@
|
||||
#!/bin/bash
|
||||
# cayce-autodeploy — r18: despliega main nuevo SIN intervención del operador.
|
||||
# ~/cayce-ops → git pull de main (docs, prompts; el despliegue lee el tree)
|
||||
# /srv/cayce-core → checkout de cayce/entity main, con PUBLISH_OFF activo
|
||||
# durante el swap. Solo se retira si: tests del guard
|
||||
# 27+/27 y watcher sin VIOLACION. Rollback automatico.
|
||||
# Timer: cada 3 min. Fallo → DM al supervisor + logger. Nunca toca un tree sucio.
|
||||
|
||||
say() { echo "[autodeploy] $*"; logger -t cayce-autodeploy "$*"; }
|
||||
# r33: un rollback repetido avisa UNA vez por incidente (subject = repo:causa);
|
||||
# el journal sigue completo (say por ciclo). Un deploy exitoso limpia el subject.
|
||||
dm_once() { # $1 subject, $2 mensaje
|
||||
local flag="/var/lib/cayce/autodeploy-alerts/$1"
|
||||
if [ -e "$flag" ]; then say "DM suprimido (incidente ya avisado): $1"; return 0; fi
|
||||
mkdir -p /var/lib/cayce/autodeploy-alerts 2>/dev/null || true
|
||||
touch "$flag" 2>/dev/null || true
|
||||
dm "$2"
|
||||
}
|
||||
dm_clear() { rm -f "/var/lib/cayce/autodeploy-alerts/$1" 2>/dev/null || true; }
|
||||
dm() {
|
||||
SUP=$(grep -aoE 'SUPERVISOR_NPUB_HEX=[0-9a-f]+' /srv/cayce-nostr/.env 2>/dev/null | cut -d= -f2)
|
||||
[ -n "$SUP" ] && curl -s -X POST http://127.0.0.1:3011/dm -H "Content-Type: application/json" \
|
||||
-d "{\"to_hex\":\"$SUP\",\"content\":\"AUTODEPLOY: $1\"}" >/dev/null 2>&1
|
||||
}
|
||||
|
||||
# r31 (S1): lock compartido con cayce-auto-merge — nunca compiten sobre los
|
||||
# mismos arboles/branches (incidente 02:06:29Z del 2026-11-03: un rollback
|
||||
# `git reset --hard $OLD` pisó una rama de trabajo porque el árbol cambió de
|
||||
# branch a mitad de deploy). Las ops manuales con git sobre /srv/* tambien
|
||||
# lo toman: flock /run/lock/cayce-git-ops.lock <comando>
|
||||
LOCK=/run/lock/cayce-git-ops.lock
|
||||
exec 9>"$LOCK" || { say 'FATAL: no se puede abrir lockfile'; exit 1; }
|
||||
if ! flock -n 9; then
|
||||
say "auto-merge (u otra op) mantiene el lock — paso de este ciclo"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# ── 1. cayce-ops (main) ──────────────────────────────────────────────────────
|
||||
cd /home/ubuntu/cayce-ops || { say "FATAL: sin ~/cayce-ops"; exit 1; }
|
||||
git fetch -q origin 2>/dev/null
|
||||
if [ "$(git branch --show-current)" = "main" ] && ! git merge-base --is-ancestor origin/main HEAD 2>/dev/null; then
|
||||
if [ -n "$(git status --porcelain)" ]; then
|
||||
say "ABORT: cayce-ops tree sucio"; dm "abortado: cayce-ops dirty"
|
||||
elif git pull -q --ff-only origin main; then
|
||||
say "cayce-ops → $(git rev-parse --short HEAD)"
|
||||
# r21: sin DM (no urgente) — dm "cayce-ops actualizado a $(git rev-parse --short HEAD)"
|
||||
else
|
||||
say "ERROR: pull cayce-ops"; dm "error pull cayce-ops"
|
||||
fi
|
||||
fi
|
||||
|
||||
# ── 2. entity → /srv/cayce-core (con regla de urgencia) ──────────────────────
|
||||
cd /srv/cayce-core || { say "FATAL: sin /srv/cayce-core"; exit 1; }
|
||||
git fetch -q origin 2>/dev/null
|
||||
# desplegar solo si main tiene commits que NO estan en el checkout
|
||||
# r20: sin exit 0 — mataba el script y la sección bitcoinhotels nunca corría
|
||||
if ! git merge-base --is-ancestor origin/main HEAD 2>/dev/null; then
|
||||
# r25: lessons.md lo muta el ciclo retro en produccion — preservar (stash/pop).
|
||||
# Cualquier OTRO fichero sucio si aborta.
|
||||
DIRTY_OTHER=$(git status --porcelain | grep -v " lessons.md" | head -3)
|
||||
if [ -n "$DIRTY_OTHER" ]; then
|
||||
say "ABORT: /srv/cayce-core tree sucio: $DIRTY_OTHER"; dm "abortado: /srv/cayce-core dirty ($DIRTY_OTHER) — deploy pendiente"
|
||||
exit 1
|
||||
fi
|
||||
git stash push -q -m "autodeploy-lessons" -- lessons.md 2>/dev/null || true
|
||||
|
||||
OLD=$(git rev-parse HEAD)
|
||||
echo "autodeploy $(date -u +%FT%TZ)" > PUBLISH_OFF # r21: firmado para que urgent-watch no lo tome por manual
|
||||
say "main nuevo detectado: $(git rev-parse --short HEAD) → $(git rev-parse --short origin/main) (PUBLISH_OFF activo)"
|
||||
|
||||
if ! git checkout -q main || ! git reset -q --hard origin/main; then
|
||||
git reset -q --hard "$OLD" 2>/dev/null; rm -f PUBLISH_OFF
|
||||
say "FATAL: checkout entity"; dm "FATAL checkout entity — deploy cancelado, sin cambios"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# verificación 1: tests del guard
|
||||
OUT=$(cd /srv/cayce-core && node --test guard.test.mjs 2>&1)
|
||||
PASS=$(echo "$OUT" | grep -c '^ok ')
|
||||
FAIL=$(echo "$OUT" | grep -c '^not ok ')
|
||||
if [ "$FAIL" != "0" ] || [ "$PASS" -lt 27 ]; then
|
||||
git reset -q --hard "$OLD"
|
||||
git stash pop -q 2>/dev/null || true
|
||||
say "ROLLBACK: tests $PASS ok / $FAIL fail (<27 o fail>0)"
|
||||
dm "ROLLBACK en deploy entity: tests $PASS/$FAIL. main NO desplegado; runtime en $(git rev-parse --short HEAD)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# verificación 2: daemon + watcher limpio
|
||||
sudo -n systemctl restart cayce-nostr.service
|
||||
sudo -n systemctl start cayce-relay-watcher.service
|
||||
W=0
|
||||
for i in 1 2 3 4 5 6; do
|
||||
sleep 5
|
||||
[ "$(systemctl is-active cayce-relay-watcher.service)" = "inactive" ] && break
|
||||
done
|
||||
if systemctl is-failed cayce-relay-watcher.service >/dev/null 2>&1 \
|
||||
|| journalctl -u cayce-relay-watcher -n 8 --no-pager 2>/dev/null | grep -q VIOLACION; then
|
||||
git reset -q --hard "$OLD"
|
||||
sudo -n systemctl restart cayce-nostr.service
|
||||
say "ROLLBACK: watcher con VIOLACION — PUBLISH_OFF queda ACTIVO"
|
||||
dm "ROLLBACK watcher en deploy entity. PUBLISH_OFF QUEDA ACTIVO — revision manual"
|
||||
exit 1 # ojo: PUBLISH_OFF se queda (fail-safe deliberado)
|
||||
fi
|
||||
|
||||
rm -f PUBLISH_OFF
|
||||
git stash pop -q 2>/dev/null || true # lessons.md del ciclo retro
|
||||
say "entity → $(git rev-parse --short HEAD) (tests $PASS/27, watcher OK, live)"
|
||||
# r21: sin DM (no urgente) — dm "entity desplegado: $(git rev-parse --short HEAD) — tests $PASS/27, watcher OK"
|
||||
fi # fin sección entity
|
||||
|
||||
# r32: la seccion hardcap corre en SUBSHELL — un ROLLBACK (exit 1) ya no
|
||||
# aborta los deploys de bitcoinhotels (bug: rollback de hardcap llevaba
|
||||
# bloqueando bh desde las 15:10 mientras gh#10 espera merge)
|
||||
(
|
||||
# ── 2b. hardcap-news → /srv/hardcap-news (GitHub; web, sin PUBLISH_OFF) ─────
|
||||
cd /srv/hardcap-news || { say "FATAL: sin /srv/hardcap-news"; exit 1; }
|
||||
git fetch -q origin 2>/dev/null
|
||||
if ! git merge-base --is-ancestor origin/main HEAD 2>/dev/null && [ -z "$(git status --porcelain)" ]; then
|
||||
OLD=$(git rev-parse HEAD)
|
||||
if ! git checkout -q main || ! git reset -q --hard origin/main; then
|
||||
git reset -q --hard "$OLD" 2>/dev/null; say "FATAL: checkout hardcap-news"; exit 1
|
||||
fi
|
||||
if git diff --name-only "$OLD" HEAD 2>/dev/null | grep -q "^frontend/package-lock.json$"; then
|
||||
(cd frontend && npm ci --ignore-scripts >/dev/null 2>&1) || say "WARN: npm ci hardcap"
|
||||
fi
|
||||
if ! (cd frontend && npm run build >/tmp/hc-autodeploy-build.log 2>&1); then
|
||||
git reset -q --hard "$OLD"; (cd frontend && npm run build >/dev/null 2>&1); sudo -n systemctl restart hardcap-frontend.service
|
||||
say "ROLLBACK hardcap-news: fallo el build"; dm_once "hardcap:rollback-build" "ROLLBACK hardcap-news (build) — main NO desplegado, rollback activo (aviso unico)"
|
||||
exit 1
|
||||
fi
|
||||
sudo -n systemctl restart hardcap-frontend.service
|
||||
sleep 6
|
||||
CODE=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:3003/)
|
||||
if [ "$CODE" != "200" ]; then
|
||||
git reset -q --hard "$OLD"; (cd frontend && npm run build >/dev/null 2>&1); sudo -n systemctl restart hardcap-frontend.service
|
||||
say "ROLLBACK hardcap-news: verificacion (code=$CODE)"; dm_once "hardcap:rollback-code" "ROLLBACK hardcap-news verificacion: code=$CODE — rollback activo (aviso unico)"
|
||||
exit 1
|
||||
fi
|
||||
# r24: identidad por build-id (cuando el despliegue trae la función)
|
||||
# r33: la identidad de hardcap solo se exige si ESTE main renderiza la meta
|
||||
# build-id (gh#10 la anade al layout). Mientras no exista, no exigir identidad
|
||||
# (loop del 2026-11-03: 34 rollbacks grep-eando un build-id que main no servia).
|
||||
if git grep -q "name=.build-id." -- frontend/src/app/layout.tsx 2>/dev/null; then
|
||||
BUILT=$(curl -s -m 8 http://127.0.0.1:3003/ | grep -oE 'name="build-id" content="[a-f0-9]{8}"' | grep -oE '[a-f0-9]{8}' | head -1)
|
||||
WANT=$(git rev-parse --short=8 HEAD)
|
||||
if [ "$BUILT" != "$WANT" ]; then
|
||||
git reset -q --hard "$OLD"; (cd frontend && npm run build >/dev/null 2>&1); sudo -n systemctl restart hardcap-frontend.service
|
||||
say "ROLLBACK hardcap-news: build-id '$BUILT' != '$WANT'"; dm_once "hardcap:build-id" "ROLLBACK hardcap-news: servia build '$BUILT' pero lo desplegado era '$WANT'. Hasta mergear gh#10 (meta build-id) el check de identidad no se exige; aviso unico."
|
||||
exit 1
|
||||
fi
|
||||
dm_clear "hardcap:build-id"; dm_clear "hardcap:rollback-build"; dm_clear "hardcap:rollback-code"
|
||||
say "identidad hardcap OK: servido=$BUILT desplegado=$WANT"
|
||||
fi
|
||||
dm_clear "hardcap:build-id"; dm_clear "hardcap:rollback-build"; dm_clear "hardcap:rollback-code"
|
||||
say "hardcap-news → $(git rev-parse --short HEAD) (200)"
|
||||
fi
|
||||
|
||||
)
|
||||
# ── 3. bitcoinhotels → /srv/bitcoinhotels (web; sin PUBLISH_OFF) ────────────
|
||||
cd /srv/bitcoinhotels || { say "FATAL: sin /srv/bitcoinhotels"; exit 1; }
|
||||
git fetch -q origin 2>/dev/null
|
||||
if ! git merge-base --is-ancestor origin/main HEAD 2>/dev/null && [ -z "$(git status --porcelain)" ]; then
|
||||
OLD=$(git rev-parse HEAD)
|
||||
if ! git checkout -q main || ! git reset -q --hard origin/main; then
|
||||
git reset -q --hard "$OLD" 2>/dev/null; say "FATAL: checkout bitcoinhotels"; dm "FATAL checkout bitcoinhotels — sin cambios"; exit 1
|
||||
fi
|
||||
if git diff --name-only "$OLD" HEAD 2>/dev/null | grep -q "^package-lock.json$"; then
|
||||
npm ci --ignore-scripts >/dev/null 2>&1 || { say "WARN: npm ci bitcoinhotels"; }
|
||||
fi
|
||||
if ! npm run build >/tmp/bh-autodeploy-build.log 2>&1; then
|
||||
git reset -q --hard "$OLD"; npm run build >/dev/null 2>&1; systemctl restart cayce-bitcoinhotels
|
||||
say "ROLLBACK bitcoinhotels: fallo el build"; dm "ROLLBACK bitcoinhotels (build) — main NO desplegado, rollback activo"
|
||||
exit 1
|
||||
fi
|
||||
sudo -n systemctl restart cayce-bitcoinhotels
|
||||
sleep 6
|
||||
CODE=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:3002/)
|
||||
UMAMI=$(curl -s http://127.0.0.1:3002/ | grep -c umami)
|
||||
MARCAS=$(curl -s http://127.0.0.1:3002/guides/how-to-pay-with-lightning-abroad | grep -cE "Trezor|Ledger|BitBox|Coldcard")
|
||||
if [ "$CODE" != "200" ] || [ "$UMAMI" = "0" ] || [ "$MARCAS" != "0" ]; then
|
||||
git reset -q --hard "$OLD"; npm run build >/dev/null 2>&1; systemctl restart cayce-bitcoinhotels
|
||||
say "ROLLBACK bitcoinhotels: verificacion (code=$CODE umami=$UMAMI marcas=$MARCAS)"
|
||||
dm "ROLLBACK bitcoinhotels verificacion: code=$CODE umami=$UMAMI marcas=$MARCAS — rollback activo"
|
||||
exit 1
|
||||
fi
|
||||
say "bitcoinhotels → $(git rev-parse --short HEAD) (200 + umami + 0 marcas)"
|
||||
# r22: verificación de IDENTIDAD — lo servido debe ser lo desplegado
|
||||
if git grep -q "NEXT_PUBLIC_BUILD_ID" -- src/app/layout.tsx 2>/dev/null; then
|
||||
BUILT=$(curl -s -m 8 http://127.0.0.1:3002/ | grep -oE 'name="build-id" content="[a-f0-9]{8}"' | grep -oE '[a-f0-9]{8}' | head -1)
|
||||
WANT=$(git rev-parse --short=8 HEAD)
|
||||
if [ "$BUILT" != "$WANT" ]; then
|
||||
git reset -q --hard "$OLD"; npm run build >/dev/null 2>&1; sudo -n systemctl restart cayce-bitcoinhotels
|
||||
say "ROLLBACK bitcoinhotels: build-id servido '$BUILT' != desplegado '$WANT'"
|
||||
dm "ROLLBACK bitcoinhotels: el sitio servia build '$BUILT' pero lo desplegado era '$WANT' — rollback activo."
|
||||
exit 1
|
||||
fi
|
||||
say "identidad OK: servido=$BUILT desplegado=$WANT"
|
||||
fi
|
||||
fi
|
||||
Executable
+226
@@ -0,0 +1,226 @@
|
||||
#!/bin/bash
|
||||
# cayce-daily-report (r20) — DM diario al supervisor:
|
||||
# 1) publicado por canal con enlaces 2) rechazos del guard y por qué
|
||||
# 3) PRs auto-mergeados + deploys 4) métricas Umami (ambos sitios)
|
||||
# 5) costo estimado de Gemini del día
|
||||
set -uo pipefail
|
||||
OUT=$(mktemp)
|
||||
PSQL="sudo -n -u postgres psql -d cayce -tA -f-"
|
||||
DAY=$(date -u +%F)
|
||||
|
||||
{
|
||||
echo "CAYCE — reporte diario $DAY (UTC)"
|
||||
|
||||
echo ""
|
||||
echo "== 1. Publicado (24h) =="
|
||||
$PSQL <<'EOF'
|
||||
SELECT 'nostr/' || type || ' — ' || left(regexp_replace(content, E'[\\n\\r]+', ' ', 'g'), 80)
|
||||
|| ' — ev:' || coalesce(meta->>'event_id', '(sin id)')
|
||||
FROM outbound_drafts
|
||||
WHERE status='published' AND channel='nostr'
|
||||
AND type NOT IN ('profile','contact_list','inbox_relays','deletion')
|
||||
AND ts > now() - interval '24 hours'
|
||||
ORDER BY ts DESC LIMIT 6;
|
||||
SELECT 'hardcap/' || type || ' — ' || left(regexp_replace(content, E'[\\n\\r]+', ' ', 'g'), 80)
|
||||
FROM outbound_drafts
|
||||
WHERE status='published' AND channel='hardcap' AND ts > now() - interval '24 hours'
|
||||
ORDER BY ts DESC LIMIT 4;
|
||||
EOF
|
||||
sudo -n -u postgres psql -d cayce -tA -f- <<'EOF'
|
||||
SELECT platform || ' — ' || theme || ' — ' || coalesce(post_url, '(sin url)')
|
||||
FROM posts_log WHERE ts > now() - interval '24 hours' AND status='ok' ORDER BY ts DESC LIMIT 6;
|
||||
EOF
|
||||
|
||||
echo ""
|
||||
echo "== 2. Guard: rechazos (24h) =="
|
||||
sudo -n -u postgres psql -d cayce -tA -f- <<'EOF'
|
||||
SELECT count(*) || 'x ' || left(reasons, 100) FROM guard_rejections
|
||||
WHERE ts > now() - interval '24 hours'
|
||||
GROUP BY reasons ORDER BY count(*) DESC LIMIT 6;
|
||||
EOF
|
||||
|
||||
echo ""
|
||||
echo "== 2b. DMs urgentes (politica r33) =="
|
||||
NDM=$(journalctl -u cayce-nostr --since "-24 hours" --no-pager 2>/dev/null | grep -c "\[dm\] envio a")
|
||||
UCOUNT=$(python3 -c "import json; print(json.load(open('/srv/cayce-core/.dm-urgent-count.json')).get('$(date -u +%F)', 0))" 2>/dev/null || echo 0)
|
||||
echo " DMs NIP-04 enviados (24h, todas las causas): $NDM · urgentes de hoy (tope 3): $UCOUNT"
|
||||
if [ -s /srv/cayce-core/.dm-deferred.log ]; then
|
||||
echo " diferidos por tope (van aqui en vez de DM):"
|
||||
tail -5 /srv/cayce-core/.dm-deferred.log | sed "s/^/ /"
|
||||
fi
|
||||
if [ -f /srv/cayce-core/PUBLISH_OFF ]; then
|
||||
echo " kill switch: ACTIVO ($(head -c 20 /srv/cayce-core/PUBLISH_OFF 2>/dev/null))"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "== 3. PRs y deploys =="
|
||||
BTOK=$(cat /etc/cayce/ci-bot.token 2>/dev/null)
|
||||
if [ -n "$BTOK" ]; then
|
||||
for REPO in cayce-ops entity bitcoinhotels; do
|
||||
curl -s -m 10 -H "Authorization: token $BTOK" \
|
||||
"http://127.0.0.1:3100/api/v1/repos/cayce/$REPO/pulls?state=closed&limit=20" \
|
||||
| python3 -c "
|
||||
import json, sys, datetime
|
||||
cutoff = (datetime.datetime.utcnow() - datetime.timedelta(days=1)).strftime('%Y-%m-%dT%H:%M')
|
||||
for p in json.load(sys.stdin):
|
||||
m = (p.get('merged_at') or '')
|
||||
if not p.get('merged') or not m or m < cutoff: continue
|
||||
print(f\"$REPO#{p['number']} — {p['title'][:60]}\")" 2>/dev/null
|
||||
done
|
||||
fi
|
||||
journalctl -u cayce-autodeploy --since "-24 hours" -o cat --no-pager 2>/dev/null | grep -E "^\[autodeploy\].*(→|ROLLBACK|ABORT|FATAL)" | tail -6
|
||||
|
||||
echo ""
|
||||
echo "== 3b. PRs que esperan tu merge =="
|
||||
PROTECTED="SPEC.md|MANDATE.md|prompts/cayce-identity.md|guard[^/]*\.|relay-watcher|outbox\.mjs|guard-blocklist|check-single-outbox|\.gitea/workflows|\.github/workflows|cayce-auto-merge|act_runner|docker"
|
||||
if [ -n "${BTOK:-}" ]; then
|
||||
for REPO in cayce-ops entity bitcoinhotels; do
|
||||
curl -s -m 10 -H "Authorization: token $BTOK" \
|
||||
"http://127.0.0.1:3100/api/v1/repos/cayce/$REPO/pulls?state=open&limit=20" \
|
||||
| python3 -c "
|
||||
import json, sys, urllib.request, os
|
||||
tok = os.environ.get('BTOK')
|
||||
for p in json.load(sys.stdin):
|
||||
req = urllib.request.Request(f'http://127.0.0.1:3100/api/v1/repos/cayce/$REPO/pulls/{p["number"]}/files?limit=100', headers={'Authorization': 'token ' + tok})
|
||||
files = [f.get('filename','') for f in json.load(urllib.request.urlopen(req, timeout=10))]
|
||||
import re
|
||||
prot = [f for f in files if re.search(r'$PROTECTED', f)]
|
||||
motivo = 'toca paths protegidos: ' + ', '.join(prot[:3]) if prot else 'CI pendiente o esperando revisión'
|
||||
print(f" $REPO#{p['number']} — {p['title'][:56]} — {motivo}")" 2>/dev/null
|
||||
done
|
||||
fi
|
||||
echo " GitHub patternn/hardcap-news: sin token en VPS — revisar https://github.com/patternn/hardcap-news/pulls"
|
||||
|
||||
echo ""
|
||||
echo "== 4. Umami (24h) =="
|
||||
sudo -n -u postgres psql -d umami -tA -f- <<'EOF'
|
||||
SELECT w.name || ': ' || count(DISTINCT e.session_id) || ' visitas · ' || count(*) || ' páginas'
|
||||
FROM website_event e JOIN website w ON w.website_id = e.website_id
|
||||
WHERE e.created_at > now() - interval '24 hours' AND e.event_type = 1
|
||||
GROUP BY w.name ORDER BY count(*) DESC;
|
||||
SELECT 'top: ' || url_path || ' (' || count(*) || ')' FROM website_event
|
||||
WHERE created_at > now() - interval '24 hours' AND event_type = 1
|
||||
GROUP BY url_path ORDER BY count(*) DESC LIMIT 4;
|
||||
SELECT 'refs: ' || coalesce(nullif(referrer_domain, ''), '(direct)') || ' (' || count(DISTINCT session_id) || ')'
|
||||
FROM website_event
|
||||
WHERE created_at > now() - interval '24 hours' AND event_type = 1
|
||||
GROUP BY referrer_domain ORDER BY count(DISTINCT session_id) DESC LIMIT 4;
|
||||
EOF
|
||||
|
||||
echo ""
|
||||
echo "== Contenido nuevo publicado hoy por sitio =="
|
||||
# bitcoinhotels: guias/fichas nuevas o actualizadas en el arbol DESPLEGADO (link vivo)
|
||||
cd /srv/bitcoinhotels 2>/dev/null && git log --since="24 hours" --format="%H" -- src/data/guides.json | while read -r C; do
|
||||
git show "$C" -- src/data/guides.json 2>/dev/null | grep -oE '^\+\s+"slug": "[a-z0-9-]+"' | sed 's/.*: "//;s/"//' \
|
||||
| while read -r SL; do echo " bitcoinhotels.org/guides/$SL"; done
|
||||
done | sort -u
|
||||
# hardcap: notas publicadas hoy (link por article_id del meta)
|
||||
sudo -n -u postgres psql -d cayce -tA -f- <<'EOF2' | while read -r L; do [ -n "$L" ] && echo " hardcap.news$L"; done
|
||||
SELECT '/news/' || (meta->>'article_id') || '/summary — ' || left(regexp_replace(content, E'[\n\r]+', ' ', 'g'), 60)
|
||||
FROM outbound_drafts
|
||||
WHERE channel='hardcap' AND status='published' AND ts > now() - interval '24 hours'
|
||||
AND meta->>'article_id' IS NOT NULL
|
||||
ORDER BY ts DESC LIMIT 6;
|
||||
EOF2
|
||||
|
||||
echo ""
|
||||
echo "== Ciclos: piezas producidas (24h) =="
|
||||
sudo -n -u postgres psql -d cayce -tA -f- <<'EOF'
|
||||
SELECT 'posts: ' || count(*) || ' piezas nostr (opinion/reflection/events/iniciativa)'
|
||||
FROM outbound_drafts WHERE channel='nostr'
|
||||
AND type IN ('opinion','reflection','events_post','initiative_note')
|
||||
AND status='published' AND ts > now() - interval '24 hours';
|
||||
SELECT 'editoriales: ' || count(*) || ' opiniones publicadas · ' || (SELECT count(*) FROM actions_log WHERE action='editorials_cycle' AND ts > now() - interval '24 hours') || ' corridas'
|
||||
FROM outbound_drafts WHERE channel='nostr' AND type='opinion' AND status='published' AND ts > now() - interval '24 hours';
|
||||
SELECT 'notas hardcap: ' || count(*) || ' publicadas'
|
||||
FROM outbound_drafts WHERE channel='hardcap' AND status='published' AND ts > now() - interval '24 hours';
|
||||
SELECT 'curacion hardcap: ' || count(*) || ' corridas del ciclo core · ' || (SELECT count(*) FROM digests WHERE ts > now() - interval '24 hours') || ' digests'
|
||||
FROM actions_log WHERE action='cycle_complete' AND ts > now() - interval '24 hours';
|
||||
SELECT 'promo: ' || count(*) FILTER (WHERE status='ok') || ' publicadas · ' || count(*) FILTER (WHERE status LIKE 'rejected%') || ' rechazadas · ' || count(*) FILTER (WHERE status LIKE 'error%') || ' con error'
|
||||
FROM posts_log WHERE ts > now() - interval '24 hours';
|
||||
SELECT 'iniciativa: ' || count(*) || ' drafts creados'
|
||||
FROM actions_log WHERE action='draft_created' AND ts > now() - interval '24 hours';
|
||||
EOF
|
||||
|
||||
echo "== Checklist de postulacion (verificable en vivo) =="
|
||||
chk() { # $1 nombre, $2 condicion (0=verde)
|
||||
if [ "$2" = "0" ]; then echo " $1: verde"; else echo " $1: pendiente"; fi
|
||||
}
|
||||
for SITE in bh hc; do
|
||||
[ "$SITE" = "bh" ] && P=3002 && D=bitcoinhotels.org || { P=3003; D=hardcap.news; }
|
||||
N=$(curl -s -m 6 http://127.0.0.1:$P/sitemap.xml | grep -c "<loc>")
|
||||
TR=0; for PG in about contact privacy terms; do C=$(curl -s -o /dev/null -w "%{http_code}" -m 5 http://127.0.0.1:$P/$PG); [ "$C" = "200" ] && TR=$((TR+1)); done
|
||||
HWW=$(curl -s -o /dev/null -w "%{http_code}" -m 5 http://127.0.0.1:$P/how-we-work)
|
||||
ADS=$(curl -s -o /dev/null -w "%{http_code}" -m 5 http://127.0.0.1:$P/ads.txt)
|
||||
PC=$(curl -s -o /dev/null -w "%{http_code}" -m 5 http://127.0.0.1:$P/privacy)
|
||||
PRIV=$(curl -s -m 5 http://127.0.0.1:$P/privacy | grep -c -i "adsense"); [ "$PC" != "200" ] && PRIV=0
|
||||
echo "$D: sitemap=$N URLs · confianza $TR/4 · how-we-work $([ "$HWW" = "200" ] && echo SI || echo NO) · ads.txt $([ "$ADS" = "200" ] && echo SI || echo NO) · privacy-AdSense $([ "$PRIV" -ge 1 ] && echo SI || echo NO)"
|
||||
done
|
||||
|
||||
if [ "$(date -u +%u)" = "1" ]; then
|
||||
echo "== Semanal (lunes): checklist AdSense =="
|
||||
for SITE in bh hc; do
|
||||
[ "$SITE" = "bh" ] && P=3002 && N=bitcoinhotels.org || { P=3003; N=hardcap.news; }
|
||||
OK=0; TOTAL=5
|
||||
for PG in sitemap.xml ads.txt privacy terms how-we-work; do
|
||||
C=$(curl -s -o /dev/null -w "%{http_code}" -m 5 http://127.0.0.1:$P/$PG); [ "$C" = "200" ] && OK=$((OK+1))
|
||||
done
|
||||
echo " $N: $OK/$TOTAL (sitemap · ads.txt · privacy · terms · how-we-work)"
|
||||
done
|
||||
fi
|
||||
|
||||
echo "== Pushes (24h) por autor =="
|
||||
for R in cayce-ops entity bitcoinhotels; do
|
||||
A=$(cd /srv/$([ "$R" = "cayce-ops" ] && echo home/ubuntu/cayce-ops || { [ "$R" = "entity" ] && echo cayce-core || echo bitcoinhotels; }) 2>/dev/null && git log --since="24 hours" --format="%an" | sort | uniq -c | tr "\n" ";" )
|
||||
echo " $R: ${A:-sin commits}"
|
||||
done
|
||||
|
||||
echo "== Avance semanal FASE B (piezas vs objetivo) =="
|
||||
# convencion: los commits de piezas FASE B llevan prefijo "pieza:"
|
||||
SEM=$(( ($(date -u +%s) / 86400 + 3) / 7 )) # semana ISO aprox
|
||||
for R in cayce-ops entity bitcoinhotels; do
|
||||
D=/srv/$([ "$R" = "cayce-ops" ] && echo home/ubuntu/cayce-ops || { [ "$R" = "entity" ] && echo cayce-core || echo bitcoinhotels; })
|
||||
N=$(cd "$D" 2>/dev/null && git log --since="7 days" --format="%s" | grep -c "^pieza:")
|
||||
echo " $R: $N piezas-commits esta semana"
|
||||
done
|
||||
echo " objetivos: bitcoinhotels 2/sem · hardcap ~2,5/sem (hub+watch+guia alterna)"
|
||||
|
||||
echo "== Persistencias (caidos ahora mismo) =="
|
||||
for U in cayce-nostr.service hardcap-backend.service hardcap-frontend.service cayce-bitcoinhotels.service postgresql@18-main.service caddy.service; do
|
||||
A=$(systemctl is-active $U 2>/dev/null)
|
||||
[ "$A" != "active" ] && echo " $U: $A"
|
||||
done
|
||||
true
|
||||
|
||||
echo "== 5. Gemini del día =="
|
||||
python3 - /srv/cayce-core/.llm-usage.jsonl <<'PY' 2>/dev/null || echo "(sin uso registrado aún)"
|
||||
import json, sys, os
|
||||
IN = OUT_ = CACHED = CALLS = 0
|
||||
if os.path.exists(sys.argv[1]):
|
||||
for line in open(sys.argv[1]):
|
||||
try:
|
||||
d = json.loads(line)
|
||||
if d.get("ts", "")[:10] == __import__("datetime").datetime.utcnow().date().isoformat():
|
||||
CALLS += 1; IN += d.get("in", 0); OUT_ += d.get("out", 0); CACHED += d.get("cached", 0)
|
||||
except Exception:
|
||||
pass
|
||||
rin = float(os.environ.get("GEMINI_USD_PER_MTOK_IN", "0.15"))
|
||||
rout = float(os.environ.get("GEMINI_USD_PER_MTOK_OUT", "0.60"))
|
||||
cost = IN/1e6*rin + OUT_/1e6*rout
|
||||
print(f"{CALLS} llamadas · in {IN:,} tok · out {OUT_:,} tok · cached {CACHED:,} · costo estimado ${cost:.3f} (rates {rin}/{rout} USD/Mtok)")
|
||||
PY
|
||||
} > "$OUT" 2>&1
|
||||
|
||||
# DM al supervisor + copia de auditoría
|
||||
SUP=$(grep -aoE 'SUPERVISOR_NPUB_HEX=[0-9a-f]+' /srv/cayce-nostr/.env 2>/dev/null | cut -d= -f2)
|
||||
BODY=$(head -c 6000 "$OUT")
|
||||
if [ -n "$SUP" ]; then
|
||||
curl -s -m 20 -X POST http://127.0.0.1:3011/dm -H "Content-Type: application/json" \
|
||||
-d "$(python3 -c "import json,sys; print(json.dumps({'to_hex': '$SUP', 'content': open('$OUT').read()[:6000]}))")" \
|
||||
>/dev/null && logger -t cayce-daily-report "DM enviado ($(wc -c < "$OUT") bytes)"
|
||||
else
|
||||
logger -t cayce-daily-report "SIN supervisor — reporte solo en log"
|
||||
fi
|
||||
cat "$OUT"
|
||||
cp "$OUT" /var/log/cayce-daily-report.log 2>/dev/null || true
|
||||
rm -f "$OUT"
|
||||
@@ -0,0 +1,138 @@
|
||||
#!/bin/bash
|
||||
# cayce-urgent-watch (r21 → r33) — política de DMs del operador:
|
||||
# DM inmediato SOLO si:
|
||||
# · kill switch activado o fuga detectada
|
||||
# · sitio/servicio público caído >15 min (no rollbacks que se recuperan)
|
||||
# · backup fallido 2 días seguidos
|
||||
# · gasto de Gemini por encima del umbral
|
||||
# Todo lo demás (initiative, rollbacks recuperados, ciclos, publicaciones,
|
||||
# rechazos, merges CODEOWNERS) va SOLO al resumen diario de las 23:50 UTC.
|
||||
# Ciclos pausados a propósito (p.ej. promo) no generan alertas.
|
||||
# Dedup por tipo de incidente + sujeto (24 h). Tope: 3 DMs urgentes/día;
|
||||
# a partir de ahí, una línea en el resumen diario (.dm-deferred.log).
|
||||
# DRYRUN=1 imprime qué haría sin enviar ni contar.
|
||||
DEDUP=/srv/cayce-core/.dm-dedup.json
|
||||
DOWNST=/srv/cayce-core/.critical-down.json
|
||||
COUNTF=/srv/cayce-core/.dm-urgent-count.json
|
||||
DEFER=/srv/cayce-core/.dm-deferred.log
|
||||
USAGE=${LLM_USAGE_LOG:-/srv/cayce-core/.llm-usage.jsonl}
|
||||
GEMINI_MAX_USD=${GEMINI_MAX_USD:-1.0}
|
||||
export TTL_MS=$((24 * 3600 * 1000))
|
||||
DRY=${DRYRUN:-0}
|
||||
|
||||
dm_urgente() { # $1 clave (tipo:sujeto), $2 mensaje
|
||||
python3 - "$1" "$2" "$DEDUP" "$TTL_MS" "$COUNTF" "$DEFER" "$DRY" <<'PY'
|
||||
import json, sys, subprocess, datetime, os
|
||||
key, msg, dedup, ttl, countf, defer, dry = sys.argv[1:8]
|
||||
ttl, dry = int(ttl), int(dry)
|
||||
st = {}
|
||||
try: st = json.load(open(dedup))
|
||||
except Exception: pass
|
||||
now = datetime.datetime.utcnow().timestamp() * 1000
|
||||
if now - st.get(key, 0) < ttl:
|
||||
print(f"[urgent] DM dedup ({key}) — ya alertado en <24h"); sys.exit(0)
|
||||
cnt = {}
|
||||
today = datetime.datetime.utcnow().date().isoformat()
|
||||
try: cnt = json.load(open(countf))
|
||||
except Exception: pass
|
||||
n = cnt.get(today, 0)
|
||||
sup = ""
|
||||
for l in open("/srv/cayce-nostr/.env"):
|
||||
if l.startswith("SUPERVISOR_NPUB_HEX="): sup = l.strip().split("=",1)[1]
|
||||
if not sup:
|
||||
print("[urgent] sin supervisor — solo log"); sys.exit(0)
|
||||
if n >= 3:
|
||||
with open(defer, "a") as f:
|
||||
f.write(f"{datetime.datetime.utcnow().isoformat()} DEFERIDO (tope 3/dia) {key}: {msg}\n")
|
||||
print(f"[urgent] TOPE 3/dia alcanzado — diferido al resumen diario ({key})")
|
||||
sys.exit(0)
|
||||
if dry:
|
||||
print(f"[urgent] DRYRUN: enviaria DM ({key}): {msg[:100]}")
|
||||
sys.exit(0)
|
||||
subprocess.run(["curl","-s","-m","20","-X","POST","http://127.0.0.1:3011/dm",
|
||||
"-H","Content-Type: application/json","-d",json.dumps({"to_hex":sup,"content":msg})],
|
||||
capture_output=True)
|
||||
st[key] = now
|
||||
cnt[today] = n + 1
|
||||
json.dump(st, open(dedup, "w"))
|
||||
json.dump(cnt, open(countf, "w"))
|
||||
print(f"[urgent] DM enviado ({key}) — {cnt[today]}/3 hoy")
|
||||
PY
|
||||
}
|
||||
|
||||
# 1) kill switch manual o fuga: PUBLISH_OFF sin violación reciente del watcher,
|
||||
# o violación del relay-watcher (fuga) en la última hora.
|
||||
if [ -f /srv/cayce-core/PUBLISH_OFF ]; then
|
||||
SIG=$(head -c 9 /srv/cayce-core/PUBLISH_OFF 2>/dev/null)
|
||||
AGE=$(( $(date -u +%s) - $(stat -c %Y /srv/cayce-core/PUBLISH_OFF 2>/dev/null || echo 0) ))
|
||||
if [ "$SIG" != "autodeploy" ] || [ "$AGE" -ge 600 ]; then
|
||||
V=$(sudo -n -u postgres psql -d cayce -tAc "SELECT count(*) FROM guard_rejections WHERE type='watcher_violation' AND ts > now() - interval '15 minutes'" 2>/dev/null || echo 1)
|
||||
[ "$V" = "0" ] && dm_urgente "killswitch:manual" "URGENTE: PUBLISH_OFF activo (kill switch MANUAL) — publicación en draft global. Sin violación del watcher que lo explique."
|
||||
fi
|
||||
fi
|
||||
FUGA=$(sudo -n -u postgres psql -d cayce -tAc "SELECT count(*) FROM guard_rejections WHERE type='watcher_violation' AND ts > now() - interval '60 minutes'" 2>/dev/null || echo 0)
|
||||
[ "$FUGA" != "0" ] && dm_urgente "fuga:watcher" "URGENTE: $FUGA violaciones del watcher en 60 min — posible fuga de publicación. PUBLISH_OFF recomendado."
|
||||
|
||||
# 2) servicios críticos caídos >15 min (estado persistente de primera caída)
|
||||
while IFS=: read -r TAG UNIT MINS; do
|
||||
[ "$TAG" = "DOWN" ] && dm_urgente "down:$UNIT" "URGENTE: servicio crítico caído ${MINS} min: $UNIT"
|
||||
done < <(python3 - "$DOWNST" <<'PY'
|
||||
import json, subprocess, sys, time
|
||||
UNITS = ["cayce-nostr.service","hardcap-backend.service","hardcap-frontend.service",
|
||||
"cayce-bitcoinhotels.service","postgresql@18-main.service","caddy.service"]
|
||||
st = {}
|
||||
try: st = json.load(open(sys.argv[1]))
|
||||
except Exception: pass
|
||||
now = time.time()
|
||||
for u in UNITS:
|
||||
active = subprocess.run(["systemctl","is-active",u], capture_output=True, text=True).stdout.strip() == "active"
|
||||
if active:
|
||||
st.pop(u, None)
|
||||
else:
|
||||
st.setdefault(u, now)
|
||||
if now - st[u] > 15*60:
|
||||
print(f"DOWN:{u}:{int((now-st[u])/60)}")
|
||||
json.dump(st, open(sys.argv[1], "w"))
|
||||
PY
|
||||
)
|
||||
|
||||
# 3) backup fallido 2 días seguidos (r33: un fallo puntual no es urgente)
|
||||
if systemctl is-failed cayce-backup.service >/dev/null 2>&1; then
|
||||
FAILS=$(journalctl -u cayce-backup.service --since "48 hours ago" --no-pager 2>/dev/null | grep -c "Failed with result")
|
||||
if [ "${FAILS:-0}" -ge 2 ]; then
|
||||
dm_urgente "backup:2días" "URGENTE: cayce-backup fallido ${FAILS} veces en 48h — revisar /var/backups/cayce y el journal."
|
||||
else
|
||||
echo "[urgent] backup failed hoy ($FAILS en 48h <2) — va al resumen diario"
|
||||
fi
|
||||
fi
|
||||
|
||||
# 4) gasto de Gemini hoy > umbral (tokens reales)
|
||||
read -r COST CALLS TIN TOUT < <(python3 - "$USAGE" <<'PY'
|
||||
import json, sys, os, datetime
|
||||
rin = float(os.environ.get("GEMINI_USD_PER_MTOK_IN", "0.15"))
|
||||
rout = float(os.environ.get("GEMINI_USD_PER_MTOK_OUT", "0.60"))
|
||||
today = datetime.datetime.utcnow().date().isoformat()
|
||||
IN = OUT_ = CALLS = 0
|
||||
if os.path.exists(sys.argv[1]):
|
||||
for line in open(sys.argv[1]):
|
||||
try:
|
||||
d = json.loads(line)
|
||||
if d.get("ts","")[:10] == today:
|
||||
CALLS += 1; IN += d.get("in",0); OUT_ += d.get("out",0)
|
||||
except Exception: pass
|
||||
print(f"{IN/1e6*rin + OUT_/1e6*rout:.4f} {CALLS} {IN} {OUT_}")
|
||||
PY
|
||||
)
|
||||
if python3 -c "exit(0 if float('${COST:-0}') > float('$GEMINI_MAX_USD') else 1)" 2>/dev/null; then
|
||||
dm_urgente "gasto:gemini" "URGENTE: gasto Gemini de hoy \$${COST} (> \$${GEMINI_MAX_USD}) — ${CALLS} llamadas, ${TIN} in / ${TOUT} out tokens."
|
||||
fi
|
||||
|
||||
# r33: lo que YA NO manda DM (solo resumen diario de 23:50):
|
||||
# · ciclos mudos / pausados a propósito (promo hoy) — el resumen diario ya
|
||||
# trae la sección "Ciclos: piezas producidas"
|
||||
# · merges que tocan CODEOWNERS — el resumen diario (sección 3) lista los
|
||||
# merges del día; la sección 3b lista los PRs abiertos
|
||||
# · rollbacks recuperados — el autodeploy usa dm_once (un aviso por
|
||||
# incidente) y el resumen diario lista los deploys/rollbacks del journal
|
||||
|
||||
logger -t cayce-urgent-watch "tick ok (gemini=\$${COST:-0})"
|
||||
+16
-143
@@ -1,146 +1,19 @@
|
||||
# Architectural decisions
|
||||
# DECISIONES del operador (binding para todos los agentes)
|
||||
|
||||
Each entry: decision, why, and what it costs us. Newest last.
|
||||
## D1 (r26): Cuentas y tokens
|
||||
NINGUN agente puede: modificar permisos de la cuenta del operador (pattern),
|
||||
promoverla/degradarla de admin, ni crear tokens a su nombre — ni con fines de
|
||||
prueba. Para pruebas de API: cuentas de prueba propias (p.ej. ci-bot o una
|
||||
dedicada), creadas y revocadas por el agente. Antecedente: en r25 se generó un
|
||||
token de pattern para una prueba; práctica prohibida desde esta decisión.
|
||||
|
||||
## D1 — uv + uv.lock as the lockfile
|
||||
`uv` manages the pinned interpreter (3.12) and produces `uv.lock`. CI installs
|
||||
with `uv sync --frozen`; nothing runs against unpinned trees.
|
||||
*Cost:* contributors need uv (single static binary).
|
||||
## D2 (r26): Estado del runtime
|
||||
Ningún proceso escribe estado dentro de los checkouts de deploy. El estado
|
||||
vive en /var/lib/cayce/ (lessons.md y similares). Los árboles de
|
||||
/srv/cayce-core, /srv/bitcoinhotels y /srv/hardcap-news quedan limpios sin
|
||||
excepciones (check-clean-trees en verde).
|
||||
|
||||
## D2 — Tests on SQLite; migrations authoritative for Postgres
|
||||
Tests run on file-backed SQLite via `metadata.create_all` (fast, no service
|
||||
dependency). The Alembic chain is the production schema path; `make
|
||||
migrate-check` (CI job) smoke-runs `alembic upgrade head` on SQLite.
|
||||
*Cost:* Postgres-specific features (e.g. JSONB, partial indexes) stay unused —
|
||||
the schema uses portable `sa.JSON` instead.
|
||||
|
||||
## D3 — LLM behind an in-repo provider interface; null by default
|
||||
`cayceops.llm.LLMProvider` is the only seam. `null` provider raises — components
|
||||
fall back to deterministic rules. `openai-compat` uses stdlib `urllib` against
|
||||
any OpenAI-shaped endpoint; no SDK dependency.
|
||||
*Cost:* no retries/streaming/tool-calls — acceptable for classification and
|
||||
draft drafting. Add providers by implementing `complete()`.
|
||||
|
||||
## D4 — Nostr client implemented in-repo (coincurve + websockets)
|
||||
NIP-01 event build/sign/publish is ~150 auditable lines vs. a black-box SDK.
|
||||
Keys accepted as 32-byte hex only. Relays are plain env config; publish is
|
||||
fire-and-wait with a timeout; the event id is stored as `post_ref`.
|
||||
*Cost:* no NIP-05, no retries across relay pools — fine for kind-1 notes.
|
||||
|
||||
## D5 — AUTONOMOUS_MODE semantics (the only non-human approval path)
|
||||
Default **false**: only human-approved proposals execute, only
|
||||
human-approved drafts are sendable/publishable.
|
||||
**true** adds exactly one capability: the executor may auto-approve
|
||||
`proposed` items whose `kind` is in `CAYCE_OPS_AUTONOMOUS_KINDS`, up to
|
||||
`CAYCE_OPS_AUTONOMOUS_DAILY_CAP` per day, recording actor `auto:policy` in the
|
||||
audit log. Everything else still requires a human. Auto-approval never touches
|
||||
mail drafts or content items.
|
||||
*Cost:* two code paths; both audited; the autonomous one is off by default and
|
||||
cap-bounded.
|
||||
|
||||
## D6 — CI workflow files ship now; enforcement gate is `make check` until a runner exists
|
||||
`.gitea/workflows/ci.yml` (Gitea Actions) and `.github/workflows/ci.yml`
|
||||
(identical) run ruff, alembic smoke, pytest, gitleaks on every PR/push. The
|
||||
current host runs no Gitea Actions runner, so until one is provisioned the
|
||||
same gate is enforced locally: `scripts/pre-push` runs `make check` (lint +
|
||||
tests + migration smoke + full-history secret scan) before every push, and the
|
||||
audited commit hash in `AUDIT.md` is the one that passed it.
|
||||
*Cost:* CI results are deferred on the current host; the gate itself is
|
||||
identical to CI.
|
||||
|
||||
## D7 — gitleaks allowlist for test fixtures
|
||||
`tests/` contains invented data (fake Nostr key, fake merchant mail). It is
|
||||
allowlisted in `.gitleaks.toml` so the history scan stays signal-only.
|
||||
*Cost:* a real secret committed under `tests/` would not trip the scanner —
|
||||
compensating control: fixtures are reviewed in PRs, and no fixture ever reads
|
||||
the environment.
|
||||
|
||||
## D8 — Proposal history kept when retiring the grant text
|
||||
The repo began as a grant proposal; the retirement commit replaces it with the
|
||||
project README (no grant references in the tree). The old commits stay — the
|
||||
audit story ("this started as X, the operator mandated Y, here is the diff") is
|
||||
more honest than a rewritten birth.
|
||||
*Cost:* `git log` still shows the word "OpenSats" in old messages. The tree and
|
||||
README carry none.
|
||||
|
||||
## D9 — Executor plugins are in-process registrations
|
||||
An action plugin is a Python function registered in
|
||||
`cayceops.components.executor.plugins.REGISTRY`, mapped by proposal `kind`.
|
||||
`http_post` exists but is inert unless `CAYCE_OPS_ENABLE_HTTP_ACTIONS=true`.
|
||||
*Cost:* no sandboxing of plugins — plugins are repo code, reviewed like
|
||||
everything else.
|
||||
|
||||
## D10 — Audit chain is hash-chained; approval can require operator signature (post-audit)
|
||||
`audit_log` rows chain sha256(prev_hash|fields); `verify_audit_chain` walks it,
|
||||
the monitor can surface breaks. With `CAYCE_OPS_OPERATOR_PUBKEY` set,
|
||||
`executor approve` REQUIRES a BIP-340 signature over
|
||||
sha256("cayce-ops:approve:<id>") from the operator key — `--actor` becomes a
|
||||
label, the key is the proof (the audit's "anyone can sign as anyone").
|
||||
*Cost:* without a pubkey configured the gate degrades to the old free-text
|
||||
actor; separate DB roles per daemon remain a deployment TODO (SQL to tighten
|
||||
ships in deploy/roles.sql).
|
||||
|
||||
## D11 — Mail threading now has a real first-contact path (post-audit)
|
||||
Sends create an OUTBOUND row (own Message-ID, In-Reply-To -> inbound);
|
||||
inbound rows keep their original Message-ID. `maild compose` creates the
|
||||
initial outreach draft for a proposal. Approval is bound to the draft text
|
||||
via sha256 (`approved_hash`): an edited draft refuses to send until
|
||||
re-approved. Each send commits in its own transaction — SMTP failure on
|
||||
message N can no longer resurrect 1..N-1 as duplicates.
|
||||
|
||||
## D12 — IMAP \\Seen only after commit; content gates tighten (post-audit)
|
||||
Messages are fetched unmarked and flagged \\Seen after the processing
|
||||
transaction commits (crash mid-batch no longer loses mail). Publisher:
|
||||
caption hash-bound at approval, disabled channels are terminal (`SKIPPED`),
|
||||
publish failures burn a bounded attempt budget before abandonment.
|
||||
`risk_score` renamed `match_score` (keyword relevance) and auto-approval
|
||||
takes the HIGHEST score first.
|
||||
|
||||
## D13 — No non-human approval path (round 2, supersedes D5)
|
||||
Operator signatures are mandatory for approvals AND re-verified at
|
||||
execution/send/publish time against current content + deployment id. With
|
||||
that gate, the AUTONOMOUS_MODE auto-approval path cannot exist: it would
|
||||
produce unsigned approvals the gate refuses. `_auto_approve` is inert and
|
||||
audits `autonomy_disabled` when invoked. *Cost:* AUTONOMOUS_MODE is now
|
||||
inert by design.
|
||||
|
||||
## D14 — Signatures bind content + deployment (round 2)
|
||||
message = sha256("cayce-ops:<type>:<deployment_id>:<id>:<content_hash>").
|
||||
content_hash is canonical-json of the fields that matter per type. Full
|
||||
signatures live on the row (operator_signature) and in the audit detail.
|
||||
Verification happens again at run time: unsigned rows (raw SQL approval)
|
||||
revert to their pre-approval state with an error audit. *Cost:* a deployment
|
||||
id env var is mandatory; signatures must be recomputed if content changes.
|
||||
|
||||
## D15 — Approval classifier veto (round 2)
|
||||
Any negation token anywhere in a mail vetoes an `approval` classification →
|
||||
needs_review. Simpler and strictly conservative vs. per-pattern negation
|
||||
lists. *Cost:* genuinely-positive approvals containing stray negations
|
||||
(e.g. "we have no reason not to welcome you") need human triage.
|
||||
|
||||
## D16 — La clave del operador nunca es una identidad de agente
|
||||
|
||||
**Fecha:** 2026-10-28
|
||||
|
||||
**Contexto:** se descubrió que `CAYCE_OPS_OPERATOR_PUBKEY` estaba configurada
|
||||
con la pubkey de Cayce — es decir, Cayce se aprobaba a sí misma. La firma
|
||||
BIP-340 era técnicamente válida pero semánticamente nula: "aprobación humana"
|
||||
firmada por el agente no es aprobación humana.
|
||||
|
||||
**Regla:** los daemons y el CLI se niegan a operar si la pubkey del operador
|
||||
coincide con:
|
||||
1. La pubkey derivada de cualquier clave privada cargada en la config
|
||||
(`CAYCE_OPS_NOSTR_PRIVATE_KEY` u otra identidad de agente futura), o
|
||||
2. Cualquier pubkey en `CAYCE_OPS_FORBIDDEN_OPERATOR_PUBKEYS` (deny-list
|
||||
explícita, para claves fuera de este proceso).
|
||||
|
||||
**Implementación:** `cayceops.signing.validate_no_self_approval()`, llamada
|
||||
desde `_signing()` en executor/maild/publisher. Lanza `SelfApprovalError`.
|
||||
|
||||
**La firma del operador se produce FUERA de la VPS.** El CLI `approve-*`
|
||||
acepta la firma como parámetro (ya lo hace); nunca la genera él. Mientras
|
||||
no exista el signer externo, `CAYCE_OPS_OPERATOR_PUBKEY` debe permanecer
|
||||
vacía — los daemons se niegan a operar y eso es lo correcto.
|
||||
|
||||
**La nsec de Cayce NO se toca:** sigue siendo la identidad del agente para
|
||||
publicar y anclar. Lo que se prohíbe es usarla como clave de operador.
|
||||
## D3 (r26): Trazabilidad de pushes
|
||||
Todo push queda identificado por autor; el reporte diario lista los pushes
|
||||
del día por autor, y todo merge a main que toque archivos de CODEOWNERS
|
||||
dispara DM urgente si no lo mergeó pattern.
|
||||
|
||||
@@ -0,0 +1,99 @@
|
||||
# PROPUESTA (r30b, NO ejecutada) — BTC Map como fuente de verdad de alojamientos
|
||||
|
||||
Estado: propuesta. Nada de esto está aplicado. Requiere aprobación del operador.
|
||||
|
||||
## 1. Diagnóstico con evidencia (2026-11-03)
|
||||
|
||||
- `src/data/hotels.json` (12 hoteles, `verified: true` en los 12) no tiene registro de
|
||||
verificación en el repo: entró como snapshot de producción en la ronda 7 (f5f66db).
|
||||
- Cruce real contra el dump completo de BTC Map (api.btcmap.org/v2/elements, 43.349
|
||||
elementos, 27.383 activos con nombre+coords; verificado 2026-11-03): de los 12 hoteles
|
||||
solo **Las Verandas (Roatán)** existe en BTC Map (`node:10164144439`, tourism=hotel,
|
||||
sin verificación reciente). **Los otros 11 NO están en BTC Map.**
|
||||
- De esos 11, hay soporte externo real para 4: los 3 de Kessler Collection (Grand Bohemian
|
||||
Orlando, Bohemian Savannah, Casa Monica) aceptan BTC vía BitPay según su página oficial
|
||||
(kesslercollection.com/bitpay, "notify a front desk agent upon check out", verificada
|
||||
2026-11-03), y Circa tiene página propia de bitcoin (circalasvegas.com/bitcoin: ATM BTC
|
||||
24/7 + paquete fin de semana a 1 BTC — no es POS Lightning). Resorts World Las Vegas
|
||||
anunció partnership con Gemini en 2021 (8newsnow.com, 2021-06) pero su estado actual no
|
||||
se pudo verificar. Los 6 restantes (Dolder Grand, Van Walsum, Splendide Royal,
|
||||
InterContinental Ljubljana, Pestana CR7, Palazzo Versace Dubai): sin evidencia de que
|
||||
acepten bitcoin.
|
||||
- Los campos `acceptsLightning: true` de RW y Circa no están respaldados por fuente alguna
|
||||
(ver arriba: Gemini-2021 y ATM/paquete respectivamente). El news item que los atribuía
|
||||
("instalan POS Lightning") se retiró en el PR #13 por fabricado.
|
||||
|
||||
## 2. Modelo de datos propuesto
|
||||
|
||||
Dos conjuntos separados y etiquetados:
|
||||
|
||||
```
|
||||
src/data/lodging-btcmap.json ← fuente de verdad, generado por script
|
||||
{
|
||||
"_meta": {
|
||||
"fetched_at": "AAAA-MM-DD",
|
||||
"source": "BTC Map API v2 /elements (https://btcmap.org)",
|
||||
"license": "ODbL — atribución obligatoria",
|
||||
"filter": "tourism in [hotel,hostel,guest_house,motel,apartment] && !deleted_at",
|
||||
"generator": "scripts/fetch-lodging.mjs (propuesto)"
|
||||
},
|
||||
"hotels": [{
|
||||
"btcmap_id": "node:10164144439",
|
||||
"name": "Las Verandas",
|
||||
"city": "Roatan", "country": "HN",
|
||||
"lat": 16.31, "lon": -86.53,
|
||||
"lightning": false, "onchain": true, // tags payment:lightning / payment:onchain
|
||||
"website": "...", "phone": "...",
|
||||
"verified_at": "2025-07-15", // registro real del API (o null = nunca verificado)
|
||||
"btcmap_url": "https://btcmap.org/merchant/node:10164144439"
|
||||
}]
|
||||
}
|
||||
|
||||
src/data/lodging-curated.json ← excepciones, cada una con EVIDENCIA
|
||||
{
|
||||
"_meta": { "policy": "solo hoteles con página oficial de pago en bitcoin, o marcados unverificado" },
|
||||
"hotels": [{
|
||||
"slug": "grand-bohemian-orlando",
|
||||
"evidence_url": "https://www.kesslercollection.com/bitpay",
|
||||
"evidence_checked_at": "2026-11-03",
|
||||
"claims": { "onchain": true, "lightning": false }, // solo lo que la evidencia sostiene
|
||||
"status": "official-source" // "official-source" | "unverified"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
Reglas del sello: `verified AAAA-MM-DD` se muestra solo si existe `verified_at` de BTC Map
|
||||
(registro del API) o `evidence_url` + `evidence_checked_at` (página oficial revisada). Todo
|
||||
lo demás muestra "unverified" o no se lista.
|
||||
|
||||
UI: atribución ODbL visible con enlace a btcmap.org por venue (ya existe el patrón en las
|
||||
fichas); refresh nocturno del snapshot con PR automático o build-time fetch (hoy
|
||||
`src/lib/btcmap.ts` ya hace fetch en runtime con revalidate 24h — se unifica).
|
||||
|
||||
## 3. Los 10+1 hoteles fuera de BTC Map — una opción por hotel
|
||||
|
||||
| Hotel | Opción | Evidencia |
|
||||
|---|---|---|
|
||||
| Grand Bohemian Orlando (Kessler) | (a) mantener con enlace oficial | kesslercollection.com/bitpay (2026-11-03) |
|
||||
| Bohemian Savannah (Kessler) | (a) mantener con enlace oficial | idem (aparece en la lista de propiedades) |
|
||||
| Casa Monica (Kessler) | (a) mantener con enlace oficial | idem |
|
||||
| Circa Las Vegas | (a) mantener con enlace oficial | circalasvegas.com/bitcoin (ATM 24/7 + paquete 1 BTC; 2026-11-03) |
|
||||
| Resorts World Las Vegas | (b) marcar "no verificado" | partnership Gemini anunciado 2021 (8newsnow); estado actual sin verificar |
|
||||
| Dolder Grand (Zurich) | (c) retirar | sin evidencia de pago en bitcoin |
|
||||
| Hotel van Walsum (Rotterdam) | (c) retirar | sin evidencia |
|
||||
| Splendide Royal (Lugano) | (c) retirar | sin evidencia |
|
||||
| InterContinental Ljubljana | (c) retirar | sin evidencia |
|
||||
| Pestana CR7 Lisboa | (c) retirar | sin evidencia |
|
||||
| Palazzo Versace Dubai | (c) retirar | sin evidencia |
|
||||
| Las Verandas (Roatán) | pasa al set de BTC Map | ya está en BTC Map (node:10164144439) |
|
||||
|
||||
Con las opciones (a) aplicadas el sitio queda con 5 hoteles verificables (4 oficiales +
|
||||
todo el lodging de BTC Map) en vez de 12 con sello "verified" sin registro.
|
||||
|
||||
## 4. Migración (cuando se apruebe)
|
||||
|
||||
1. PR 1: añadir `scripts/fetch-lodging.mjs` + `lodging-btcmap.json` generado (ODbL meta).
|
||||
2. PR 2: lodging-curated.json con la tabla de arriba; UI: sello condicionado a registro
|
||||
real; los (c) se retiran del listado (quedan en historial git).
|
||||
3. PR 3: hoteles (a)/(b) con sus enlaces de evidencia; news.json sin items de marca.
|
||||
4. Cada PR desplegado por autodeploy normal (identidad + rollback ya existentes).
|
||||
@@ -0,0 +1,108 @@
|
||||
# FASE B — Reconstrucción de bitcoinhotels con datos reales (propuesta B1, r31)
|
||||
|
||||
Estado: PROPUESTA. Nada publicado. Fuente de datos: dump completo de BTC Map
|
||||
API v2 (43.349 elementos, 2026-11-03). Los alojamientos = tourism ∈
|
||||
[hotel, hostel, guest_house, motel, apartment, hotel_room], sin deleted_at,
|
||||
con nombre+coords. verified_at = registro del elemento OSM
|
||||
(check_date:currency:XBT | check_date | survey:date).
|
||||
|
||||
## 1. Alojamientos por ciudad del plan (id | nombre | verified_at | métodos)
|
||||
|
||||
### El Zonte / Bitcoin Beach (radio 15 km) — 32 alojamientos
|
||||
Top por frescura de verificación (lista completa en el generador `b1.py`):
|
||||
BlockHouse (node:14343058517, 2026-11-02, lightning+onchain) · Karma Muse Hotel
|
||||
(13960946876, 2026-06-23) · Coco Surf Resort (13175946946, 2026-05-05) · La
|
||||
Casona Hostal & Shop (10901547463, 2026-05-05) · Puro Surf (12395474468,
|
||||
2026-05-04) · Sunset Surf Villa (13785848180, 2026-05-01) · Canuck's Guest
|
||||
House (13171626422, 2026-04-30) · Casa Santa Emilia (13143299360, 2026-04-25) ·
|
||||
The Beach Break El Cocal (13171913793, 2026-04-25) · The Duck Dive El Tunco
|
||||
(13197838431, 2026-04-25) · Roca Sunzal (469067668, 2026-04-24) · Balance Surf
|
||||
& Yoga (13198566180, 2026-04-24) · The Bitcoin Mansion (13122887802,
|
||||
2026-04-23) · Casa Maya Resort (12657561701, 2026-04-23) · … 28-32 con
|
||||
lightning+onchain; 4 además aceptan Blink (Garten Hotel, Hotel-Tienda-Manny,
|
||||
Hotel Rancho Lokoo, Esencia Nativa). El más viejo: Lagarza Hostel (2023-04-23).
|
||||
|
||||
### San Salvador (radio 15 km) — 11 alojamientos
|
||||
Uong Oasis (13495773566, 2026-01-26) · La Zona Hostal (4057017483, 2025-10-09)
|
||||
· Ximena's Guest House (12360076401, 2025-09-30) · Hotels by MESER
|
||||
(13143365694, 2025-09-14) · Bitcoin Landing Spot (10115300184, 2025-07-11,
|
||||
lightning+onchain+blink) · Charly's Place (12341973642, 2024-11-14) · Green
|
||||
Life (11603030384), Hostal Los Heroes (11603030990), Hostal Cielo Azul
|
||||
(11603019532), Vennua Suits (11603105662) — todos 2024-02-09 · Hotel Finca San
|
||||
Nicolás (11382056273, 2023-11-28).
|
||||
|
||||
### Lugano (radio 15 km) — 7 alojamientos
|
||||
Locanda Castagnola (2288386755, 2026-10-01) · Acquarello (373429196,
|
||||
2025-07-23) · Zurigo Downtown (3302999281, 2025-07-02) · Pestalozzi (373420246,
|
||||
2025-06-30) · Hotel Delfino (11522524479, 2025-06-21) · Hotel Federale
|
||||
(310598863, 2025-06-20) · Hotel Gabbani (5072974692, 2025-06-15). Todos
|
||||
lightning+onchain.
|
||||
|
||||
### Roatán / Próspera (20 km + núcleo Próspera 10 km) — 5 alojamientos
|
||||
Guava Grove Resort & Villas (10656407351, 2026-03-27) · Casa Lenca - Palmetto
|
||||
Bay (13020091551, 2026-03-27, +blink) · Vines of the Sea (13004337355,
|
||||
2025-07-16, +blink) · Las Verandas (10164144439, 2025-07-15, +blink) · Blue
|
||||
Bahia Resort (14334574164, sin verificación — mostrar "sin verificación
|
||||
reciente").
|
||||
|
||||
### Referencia — otras ciudades del plan
|
||||
Prague: 2 (Pragueforyou Apartments 2025-06-21; Airbnb for Bitcoin 2023-07-19).
|
||||
Lisbon: 1 (We Host, 2026-05-21). Dato honesto: la adopción lodging de BTC Map
|
||||
en Praga/Lisboa es pequeña aunque el comercio sí sea denso.
|
||||
|
||||
## 2. Las primeras 4 guías de ciudad — SOLO datos BTC Map + fuentes primarias
|
||||
|
||||
Regla transversal: cada cifra/fecha que se muestre viene del snapshot BTC Map
|
||||
(datado) o de una fuente primaria citada (URL + fecha de consulta). Sin
|
||||
números inventados, sin "verified" sin registro.
|
||||
|
||||
### Guía 1 — "El Zonte on sats: where to sleep" (/guides/el-zonte-where-to-sleep)
|
||||
- Estructura: 1) mapa de bloques de texto con la lista de alojamientos (32),
|
||||
cada uno con nombre, id BTC Map, verified_at y métodos (lightning/onchain/
|
||||
blink) TAL CUAL el snapshot; 2) "cómo reservar": la mayoría de estos
|
||||
alojamientos aceptan Lightning directo (Blink/Wallet of Satoshi style) —
|
||||
texto operativo sin cifras; 3) contexto con 2 fuentes primarias: la reforma
|
||||
de la ley bitcoin (Reuters 2025-01-30: aceptación voluntaria) y la exención
|
||||
de capital gains (Forbes 2025-02-28); 4) notación ODbL + fecha de snapshot +
|
||||
enlace a btcmap.org/merchant/{id} por alojamiento.
|
||||
- Fase de estacionalidad: los verified_at muestran una ola de re-verificación
|
||||
abril-mayo 2026 (19 alojamientos) — dato objetivo que la guía puede afirmar
|
||||
del propio snapshot.
|
||||
|
||||
### Guía 2 — "San Salvador base camp" (/guides/san-salvador-base-camp)
|
||||
- 11 alojamientos con id/verified_at/métodos; destacados objetivos:
|
||||
Bitcoin Landing Spot (acepta Blink, verificado 2025-07-11) y La Zona Hostal
|
||||
(2025-10-09, el más reciente de la ola 2025-2026).
|
||||
- Sección "dónde estás": coordenadas del listado (zona Rosa/Colonia Médica
|
||||
según los nodos) — describir SOLO lo que los propios datos dicen.
|
||||
- Fuentes primarias de contexto: misma base legal que la guía 1 + fuente
|
||||
oficial de visas (sv.usembassy.gov, 90 días estándar) si se menciona
|
||||
estadía.
|
||||
|
||||
### Guía 3 — "Lugano: the Plan B stay" (/guides/lugano-plan-b-stay)
|
||||
- 7 alojamientos (todos lightning+onchain, todos con verified_at 2025-06/10).
|
||||
- Contexto con fuente primaria: planb.lugano.ch (~400 comercios BTC/USD₮/LVGA
|
||||
— ya citado en destinations.json post-#13) + la propia página municipal.
|
||||
- Nota honesta: Lugano lodging en BTC Map es PEQUEÑO (7) comparado con su
|
||||
comercio — la guía lo dice en vez de inflar.
|
||||
|
||||
### Guía 4 — "Roatán & Próspera" (/guides/roatan-prospera-stay)
|
||||
- 5 alojamientos; Las Verandas ya está en el set curado con evidencia doble
|
||||
(BTC Map 2025-07-15 + sitio oficial). Blue Bahia se lista con "sin
|
||||
verificación reciente" — muestra el estándar honesto.
|
||||
- Contexto con fuentes primarias: el anuncio de Próspera (2022) sobre BTC en
|
||||
su jurisdicción CITADO con URL, y la guía advierte el estado del régimen
|
||||
ZEDE sin entrar en política (o se omite si no hay fuente limpia).
|
||||
- Nota operativa: los venues ≤50 km ya saneados en PR #12 alimentan la
|
||||
sección "dónde gastar" de esta guía.
|
||||
|
||||
## 3. Reglas de publicación propuestas (FASE B)
|
||||
|
||||
1. Las guías se generan desde el snapshot lodging-btcmap.json (ya en main si
|
||||
PR #14 mergea) — nada de tipeo manual de venues.
|
||||
2. Cada guía declara su snapshot date y enlaza el merchant en btcmap.org
|
||||
(atribución ODbL).
|
||||
3. Un lodging sin verified_at en >12 meses se lista con aviso "verificación
|
||||
antigua" (no se oculta: es información).
|
||||
4. Controles de frescura: regenerar snapshot al publicar; si el snapshot
|
||||
cambia, la guía se marca para revisión (no auto-republish).
|
||||
@@ -0,0 +1,48 @@
|
||||
# cayce-dev Design Document
|
||||
|
||||
*Authorized by operator merge to main. This design governs the cayce-dev sandbox.*
|
||||
|
||||
## Flow
|
||||
- Cayce opens a PR with SPEC.md on a product repo. Operator's merge to main = authorization.
|
||||
- cayce-dev only takes specs already merged by the operator. Implements on a branch and opens a PR. Operator merges.
|
||||
- If the spec is ambiguous, ask in the PR; do not improvise.
|
||||
|
||||
## Gitea Access
|
||||
- Token limited to product repos (branches and PRs only).
|
||||
- No merge access, no admin access, no access to cayce-ops or hardcap.
|
||||
- Commit author: cayce-dev.
|
||||
- Workflow: operator reviews SPEC.md PR → merges → cayce-dev creates feature branch → opens PR → operator merges.
|
||||
|
||||
## Isolation
|
||||
- Own container or user. NO access to:
|
||||
- nsec (operator key or agent identity)
|
||||
- .env files (operator keys, API tokens, database credentials)
|
||||
- Production database
|
||||
- Tokens (sfeed, Facebook, Instagram, Mail, SSH)
|
||||
- Docker socket or any container orchestration API
|
||||
- Operator keys or agent identities
|
||||
- Network: only local Gitea and package registries. No outbound capability beyond.
|
||||
- No deploy or publish capability.
|
||||
|
||||
## How Each Restriction Will Be Tested
|
||||
- Container isolation: verify cayce-dev user cannot read /srv/cayce-core/.env or /home/ubuntu/.sfeed/tokens.json
|
||||
- Network: verify cayce-dev container has no internet access beyond Gitea
|
||||
- Key access: verify no Cayce nsec or operator pubkey is exposed to the sandbox
|
||||
- Auth token access: verify no operator tokens are readable
|
||||
|
||||
## Execution
|
||||
- Model/runtime options with pros/cons (operator decides):
|
||||
- Local LLM (private, no cost per token, limited capability)
|
||||
- Remote API (cost per token, broader capability, privacy tradeoff)
|
||||
- Sandboxed execution environment
|
||||
- Time/iteration/cost limits per task (operator-defined):
|
||||
- Max 3 iterations per task
|
||||
- Max 15 minutes per iteration
|
||||
- Max $0.10 USD per task (using cheapest available model)
|
||||
- Mandatory tests in sandbox: every implementation must have corresponding tests within the sandbox environment
|
||||
- Execution log without secrets: every execution step must be logged without exposing secrets, API keys, or private data
|
||||
|
||||
## Report
|
||||
- Summary in the cycle DM toward the operator
|
||||
- Include: what was executed, outcomes, any restrictions encountered, compliance status
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
# PROPUESTA (r32, NO ejecutada) — campaña promo v4: solo afirmaciones con fuente primaria
|
||||
|
||||
Estado: propuesta. La campaña sigue pausada (timer disabled); no se reanuda sin
|
||||
aprobación del operador. Reglas de construcción, aplicadas a cada caption antes
|
||||
de abrir este doc: cada afirmación con cifra, fecha o superlativo lleva SU
|
||||
fuente primaria citada en el texto (URL + fecha); sin sellos "verified" salvo
|
||||
registro real (snapshot datado o página oficial revisada en fecha); sin
|
||||
hashtags, sin exclamaciones, sin cifras sin fuente (guard R1-R9 en verde).
|
||||
|
||||
## Formato
|
||||
|
||||
8 posts / 8 días (1 por día, 17:00 UTC), 4 por marca (bh/hc), imagen de marca
|
||||
generada como en v3. Cada caption termina con su enlace y la fuente de la
|
||||
afirmación principal. El guard corre por post (canal social) y el registro de
|
||||
posts_log documenta tema + enlace + estado.
|
||||
|
||||
## Posts propuestos
|
||||
|
||||
1. **bh · El Zonte lodging** — "32 places to sleep on the El Zonte corridor,
|
||||
every one recorded with Lightning and on-chain acceptance, 26 of them
|
||||
re-verified between April and June 2026. The full list with each venue's
|
||||
last check date: bitcoinhotels.org/guides/el-zonte-where-to-sleep
|
||||
(source: btcmap.org, snapshot 2026-11-03)."
|
||||
2. **bh · Lugano** — "Lugano's Plan B counts roughly 400 merchants taking BTC,
|
||||
USD₮ and LVGA, and BTC Map carries 7 verified lodgings — the honest numbers
|
||||
for a bitcoin city. Guide: bitcoinhotels.org/guides/lugano-plan-b-stay
|
||||
(sources: planb.lugano.ch and btcmap.org snapshot 2026-11-03, both checked
|
||||
2026-11-03)."
|
||||
3. **bh · Roatán/Próspera** — "A special economic zone on Roatán adopted
|
||||
bitcoin as legal tender inside its jurisdiction in April 2022, and the
|
||||
island's verified lodging list now runs 5 entries — one of them with no
|
||||
recorded verification, and we say which. Guide:
|
||||
bitcoinhotels.org/guides/roatan-prospera-stay (sources: Reuters 2022-04-07;
|
||||
btcmap.org snapshot 2026-11-03)."
|
||||
4. **bh · San Salvador** — "11 lodgings recorded on BTC Map for San Salvador:
|
||||
6 verified in the last 15 months, 5 carrying survey dates from 2023-2024
|
||||
that we flag as old instead of hiding. Guide:
|
||||
bitcoinhotels.org/guides/san-salvador-base-camp (source: btcmap.org,
|
||||
snapshot 2026-11-03)."
|
||||
5. **hc · Physical security** — "Airlines mishandled 4.9 bags per 1,000
|
||||
passengers in 2025 — delays and damage included, not just loss. The travel
|
||||
kit's seed-custody patterns exist for exactly that tail risk:
|
||||
hardcap.news/learn/travel-security-kit (source: SITA Baggage IT Insights
|
||||
2026)."
|
||||
6. **hc · Rescue rail** — "Gift cards for bitcoin, instant delivery, service
|
||||
claim: over 186 countries. The liquidity layer of the travel kit:
|
||||
hardcap.news/learn/travel-security-kit (source: bitrefill.com, checked
|
||||
2026-11-03)."
|
||||
7. **bh · ATM reality** — "Bitcoin ATM median total fee runs about 16%, with a
|
||||
typical 10-15% band over spot. The city guide now links operator fee pages
|
||||
instead of publishing stale tables: bitcoinhotels.org/guides/
|
||||
best-bitcoin-atms-by-city (sources: coinatmradar.com fee statistics;
|
||||
spark.money fee comparison, checked 2026-11-03)."
|
||||
8. **bh · El Salvador law** — "Since January 2025 merchant acceptance of
|
||||
bitcoin in El Salvador is voluntary, and the capital-gains exemption
|
||||
stayed. What that means for a sats-first trip, without invented budgets:
|
||||
bitcoinhotels.org/guides/living-on-sats-in-el-salvador (sources: Reuters
|
||||
2025-01-30; Forbes 2025-02-28)."
|
||||
|
||||
## Tabla afirmación → fuente (auditoría completa)
|
||||
|
||||
| # | Afirmación | Fuente primaria | Fecha |
|
||||
|---|---|---|---|
|
||||
| 1 | 32 lodgings, todos Lightning+on-chain; 26 re-verificados abr-jun 2026 | btcmap.org snapshot (API v2 dump) | 2026-11-03 |
|
||||
| 2 | ~400 merchants BTC/USD₮/LVGA + 7 lodgings | planb.lugano.ch · btcmap.org snapshot | 2026-11-03 |
|
||||
| 3 | Próspera adoptó BTC como legal tender en su jurisdicción (abr-2022); 5 lodgings, 1 sin verificar | Reuters 2022-04-07 · btcmap.org snapshot | 2026-11-03 |
|
||||
| 4 | 11 lodgings SSV; 6 frescos 15 meses; 5 con fechas 2023-2024 | btcmap.org snapshot | 2026-11-03 |
|
||||
| 5 | 4.9 bolsos maltratados / 1.000 pax (2025) | SITA Baggage IT Insights 2026 | 2026 |
|
||||
| 6 | Gift cards BTC "over 186 countries" | bitrefill.com | 2026-11-03 |
|
||||
| 7 | Mediana ~16%, rango típico 10-15% | coinatmradar.com · spark.money · cash2bitcoin.com | 2026-11-03 |
|
||||
| 8 | Aceptación voluntaria desde ene-2025; exención CG se mantuvo | Reuters 2025-01-30 · Forbes 2025-02-28 | 2026-11-03 |
|
||||
|
||||
Sin presupuestos en sats, sin topes KYC por ciudad, sin "dataset" de wrench
|
||||
attacks, sin "verified 2026-XX-XX" — salvo los snapshot/evidencias con fecha
|
||||
real listados arriba.
|
||||
|
||||
## Si apruebas
|
||||
|
||||
1. `sudo systemctl enable --now cayce-promo.timer` con la campaña v4 ya en
|
||||
`social/promo.mjs` (PR propio, sin tocar paths protegidos).
|
||||
2. Los 4 IG pendientes de borrado manual (r31) deberían borrarse antes de
|
||||
reactivar IG.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Ronda 25 — Desbloqueo de PRs: CODEOWNERS + hallazgos Gitea 1.27 (OpenCode/GLM)
|
||||
|
||||
## Qué bloqueaba de verdad
|
||||
- protected_file_patterns bloqueaba el merge para TODOS (incluido pattern y hasta site-admin via API): ni CODEOWNERS+bypass ni is_admin lo liberan en 1.27 (probado: 405 "Changed protected files" para pattern-bypass y pattern-admin; site-admin cayce tambien bloqueado).
|
||||
- Los PRs #23/#25 nunca corrieron CI de pull_request (creados pre-workflow) — rebase+push los puso VERDE.
|
||||
- Resolución final: protected_file_patterns VACIO (instrucción del operador) + CODEOWNERS en main (documentación; 1.27 no auto-pide revisores: requested_reviewers=[] probado) + block_on_official_review_requests + approvals_whitelist=[pattern] + **la lista de exclusión del auto-merger como capa real** (probada: rehusa identity/outbox).
|
||||
- Tokens de pattern: uno generado por admin para las pruebas, REVOCADO al final.
|
||||
|
||||
## Pruebas (todas reales)
|
||||
- 2a-1: PR tocando outbox.mjs, CI verde → ci-bot 405 "Changed protected files" (con patrones) y con patrones fuera → auto-merger rehusa por su lista ✓.
|
||||
- 2a-2: pattern APRUEBA (review 200) y MERGEA (200) ✓.
|
||||
- 2b: PR sin paths protegidos (CODEOWNERS de bitcoinhotels) → auto-merge: 200 ✓.
|
||||
- Regla nueva adoptada: "esperando tu merge" solo con CI en verde.
|
||||
|
||||
## Resultado
|
||||
- El operador mergueó #23 (voz v3) y entity #3 a las 20:04. Hash v3 en despliegue VERIFICADO: c0f0ec05…
|
||||
- entity #2 sigue open (mergealo cuando quieras; checks de entity se activan DESPUÉS de ese merge para no bloquearlo).
|
||||
- Incidente arreglado: lessons.md (mutado por el ciclo retro) abortaba deploys de entity → autodeploy ahora lo preserva con stash/pop.
|
||||
- 3 commits de prueba en outbox.mjs (comentarios) quedaron en entity main tras las pruebas — inofensivos, desplegados con tests 27/27.
|
||||
@@ -0,0 +1,139 @@
|
||||
# Ronda 30b — Auditoría r26–28 + auditoría factual + saneos (OpenCode/GLM, operador patternn)
|
||||
|
||||
> Nota: la ronda 30a cerró su informe A1–A3 pero **no alcanzó a escribir su doc de sesión**
|
||||
> ni a abrir PR de documentación. Resumen r30a (de su informe): los 3 commits vacíos de
|
||||
> prueba nunca llegaron al remoto (protección de rama OK; reset local aplicado); conflicto
|
||||
> DU de lessons.md resuelto (el estado vive en /var/lib/cayce/lessons.md); news-sitemap
|
||||
> huérfano de hardcap respaldado en forensics/r30 y descartado; los 4 árboles quedaron
|
||||
> limpios en origin/main. Este doc cubre r30b y cierra el hueco documental de r30a.
|
||||
|
||||
## D1 — Auditoría rondas 26–28 (ventana auditada: 2026-11-02 20:30Z → r30a)
|
||||
|
||||
Mergeado/desplegado en la ventana (git log + PRs de Gitea y GitHub + journal de autodeploy):
|
||||
|
||||
| Cambio | Veredicto | Evidencia |
|
||||
|---|---|---|
|
||||
| cayce-ops PR #55 (DECISIONS D1-D3) mergeado 20:40Z, desplegado 20:42Z | CORRECTO — solo docs de política | `git log` 845609e; journal `cayce-ops → 845609e` |
|
||||
| entity PR #8 (lessons.md fuera del checkout) mergeado 20:40Z, deploy 20:42Z tests 27/27 | CORRECTO — r30a verificó árboles limpios y /var/lib/cayce/lessons.md (3309 B) | journal `entity → d6bbf67 (tests 27/27…)` |
|
||||
| bitcoinhotels PR #11 (fichas batch 1, 20 venues/ciudad) mergeado 21:00Z, deploy 21:09Z | **FALSO — revert (PR #12) abierto 02:02Z, auto-mergeado por ci-bot 02:05:15Z (CI verde, sin paths protegidos) y desplegado: build-id servido 95fd5597 == main. Verificación viva post-deploy: en /hotels/resorts-world-las-vegas ya no aparece "Tienda las Vegas" (0 matches) y /hotels/bohemian-hotel-savannah muestra solo venues ≤50 km (sin "Shell"/"Pick n Pay"). El detalle: la búsqueda por TEXTO de BTC Map v4 devolvía matches de nombre en otros países presentados como "Nearby/Places around {city}". 19/177 rows >50 km (hasta 13.634 km), + duplicados que inflaban conteos. La herencia de #9 (12/61 rows >50 km) también se sanea en el mismo PR | Auditoría contra lat/lon real del API v4 (tabla completa en el PR #12); journal: 2 ROLLBACK por build-id mismatch (21:03, 21:06) antes del deploy OK 21:09:20 |
|
||||
| hardcap-news PR #7 (pieza-hub-security) ABIERTO 20:52Z, NO mergeado | No desplegado. Su CI rojo es HEREDADO de main (ver G1): el home devolvía 500 sin API desde antes del PR | runs 41513621707 (#6, rojo) y 41523126329 (#7, rojo); repro local: `/` = 500 ECONNREFUSED, `/topics/security` = 200 |
|
||||
| Promos publicadas en la ventana (d2-fb-wrench 09:04Z… d4-ig-device 01:04Z) | Textos con sellos "(verified 2026-11-02)" sin registro de verificación y claims sin fuente → E1/E2/E3 | posts_log ids 20-27 con URLs reales a FB/IG |
|
||||
|
||||
Sin más deploys 21:10Z→r30a (journal del timer: solo runs vacíos). Los commits vacíos de
|
||||
prueba de r28 nunca llegaron a remoto (ya resuelto en r30a).
|
||||
|
||||
## E1 — Auditoría factual (afirmación → archivo → fuente primaria | SIN FUENTE)
|
||||
|
||||
### Guías bitcoinhotels (src/data/guides.json, "updated 2026-10-16")
|
||||
|
||||
| Afirmación | Archivo | Fuente primaria |
|
||||
|---|---|---|
|
||||
| "foreign transaction fees (1-3%), DCC (3-8%)" | guides.json · how-to-pay… | SIN FUENTE → genérico, cifras fuera (PR #13) |
|
||||
| "settles in under two seconds" | idem | SIN FUENTE → "settles in seconds" (PR #13) |
|
||||
| "directory.btcpayserver.org sell airline/hotel/Uber gift cards… app" | guides.json · how-to-pay… | FALSO (scrub de marcas sobre "Bitrefill") → Bitrefill + bitrefill.com (2026-11-03) (PR #13) |
|
||||
| ATM: "operator commission 6-12% + spread 1-4%", "tourist pays 10-15%", "prepared 4-6%" | guides.json · best-bitcoin-atms… | Parcial: 10-15%/mediana ~16% con fuente (coinatmradar.com, spark.money, cash2bitcoin.com, 2026-11-03); el resto SIN FUENTE → fuera (PR #13) |
|
||||
| "€200-900 no-KYC" + tabla por ciudad (Amsterdam €250-750/GN ~8%, Praga CZK 5k-25k, Miami $200-800, etc.) | idem | SIN FUENTE (por operador) → reemplazada por checklist de verificación (PR #13) |
|
||||
| "2021 Bitcoin Law, BTC legal tender… capital gains exempt" | guides.json · living-on-sats… | Reuters 2025-01-30 + Forbes 2025-02-28 (aceptación voluntaria desde ene-2025; exención se mantiene) → matiz (PR #13) |
|
||||
| "$400-800/mes apartamento El Zonte", "$20-45/noche hostales", "$500-900/mes SS" | idem | SIN FUENTE → fuera (PR #13) |
|
||||
| "airport 45 minutes away" | idem | SIN FUENTE → fuera (PR #13) |
|
||||
| "Travala lists dozens of Salvadoran properties taking BTC directly" | idem | Fuente real travala.com/payment/bitcoin-btc (2026-11-03) pero "directly" es inexacto (paga la plataforma) → reescrito (PR #13) |
|
||||
| Presupuesto semanal en sats ("17-29k sats noche", "1.05-1.5M sats/mes", "late 2026 prices") | idem | SIN FUENTE (implica BTC≈$105k sin cita) → fuera; guía manda a derivar el propio número (PR #13) |
|
||||
| "tourist visa (180 days for most nationalities)" | idem | sv.usembassy.gov (90 días estándar, hasta 180 según nacionalidad/pasaporte; 2026-11-03) → corregido (PR #13) |
|
||||
| "community lived on sats since 2019" (El Zonte) | idem | Bitcoin Beach documentado desde 2019 — se mantiene sin cifra nueva |
|
||||
| "Benjamin Reich (BERLIN) district leads" | idem | SIN FUENTE (dato garbleado) → fuera (PR #13) |
|
||||
| Sello "— verified AAAA-MM-DD" en venues de fichas | HotelDetail.tsx + hotels-btcmap.json | Registro REAL: `verified_at` del API de BTC Map → se mantiene (los datos falsos asociados se quitan en PR #12) |
|
||||
| Sello "Verified" (badge, 12/12 hoteles) | hotels.json | SIN REGISTRO en el repo (snapshot ronda 7) → propuesta de rediseño en F1 (no ejecutada) |
|
||||
|
||||
### hardcap (frontend/src/app/learn/travel-security-kit/page.tsx, "updated Oct 2026")
|
||||
|
||||
| Afirmación | Fuente primaria |
|
||||
|---|---|
|
||||
| "The 2026 wrench-attack dataset we track at hardcap" | SIN FUENTE (no existe tal dataset; el backend clasifica notas con pilar security) → reescrito (PR GitHub #8) |
|
||||
| "Every wrench attack we've tracked started with a public display" | SIN FUENTE → "reported… typically" (PR GitHub #8) |
|
||||
| "airlines lose [bags] 2% of the time" | FALSO — SITA Baggage IT Insights 2026: 4.9/1.000 (0,49%, incluye demora/daño) → corregido (PR GitHub #8) |
|
||||
| "Bitrefill … 186 countries" | bitrefill.com ("over 186 countries", 2026-11-03) → se mantiene |
|
||||
|
||||
### Textos de promo (/home/ubuntu/cayce-social/promo.mjs — 12 captions)
|
||||
|
||||
| Afirmación | Post | Fuente primaria |
|
||||
|---|---|---|
|
||||
| "Cards charge 2-4% on FX…; Lightning route usually stays under 0.5%" | d1-fb-lightning | SIN FUENTE |
|
||||
| "(verified 2026-11-02)" / "(checked/updated/data through 2026-11-02)" ×12 | todos | SIN REGISTRO — no existe log de verificación de estos claims; el guard R9 solo exigía "fuente y fecha" en el texto (rechazó 90day-protocol por eso: posts_log id 13) |
|
||||
| "The 2026 wrench-attack dataset is blunt…" | d2-fb-wrench, d5-ig-mistakes | SIN FUENTE (idem hardcap) |
|
||||
| "Sats to gift card in seconds across 186 countries" | d3-ig-rescue | bitrefill.com (real) — sin cita en el caption |
|
||||
| "first machine charges 10-15%… operator map runs 4-6%" | d2-ig-atm-fees | 10-15% con fuente; "4-6%" SIN FUENTE |
|
||||
| "surf hostel 17-29k sats a night, meals 11-17k…" | d3-fb-budget | SIN FUENTE (espejo de la guía) |
|
||||
| "Amsterdam EUR 250-750, Prague CZK 5k-25k, Miami USD 200-800" | d5-fb-kyc | SIN FUENTE |
|
||||
| "bitcoin circulates as legal tender inside the jurisdiction" (Prospera/Roatán) | d4-fb-roatann | Parcial: Próspera adoptó BTC en 2022 (anuncios propios); "the island takes Lightning natively" SIN FUENTE por venue — ya corregido en destinos (PR #13) |
|
||||
| "Blink funded to 500k sats… most land near 70/30" | d6-ig-protocol | SIN FUENTE (protocolo editorial propio, presentado como dato) |
|
||||
|
||||
**Nota:** promo.mjs NO está versionado (no es repo git) — hallazgo adicional de la ronda.
|
||||
Los captions publicados (8) son editables solo en plataforma; los 4 pendientes están
|
||||
pausados (E3). Corrección de textos pendiente de decidir dónde versionar (ver pendientes).
|
||||
|
||||
## E2 — Correcciones (por PR)
|
||||
|
||||
- **bitcoinhotels PR #13** (abierto): guías/news/destinos — SIN FUENTE fuera o con fuente
|
||||
real (tabla arriba). news fabricados (#1 e-visas Lightning, #4 RW+Circa POS) quitados/
|
||||
reescritos con fuentes.
|
||||
- **hardcap-news PR #8 GitHub** (abierto): travel-security-kit corregido.
|
||||
- **Sellos**: los "verified AAAA-MM-DD" con registro real (BTC Map) se mantienen; los de
|
||||
promo quedan cubiertos por E3 hasta reposicionar los textos.
|
||||
|
||||
## E3 — Promo pausada (sin borrar nada)
|
||||
|
||||
`systemctl stop + disable cayce-promo.timer` (inactive/disabled verificado). Nada borrado:
|
||||
promo.mjs, promo-state.json, campaign-start.json intactos. Próximos posts de la campaña
|
||||
(d5, d6) quedan en pausa. Reanudar: `sudo systemctl enable --now cayce-promo.timer`.
|
||||
Pendiente: los 8 ya publicados siguen en FB/IG (no se borran por regla del operador).
|
||||
|
||||
## F1 — Propuesta de modelo de datos (NO ejecutada)
|
||||
|
||||
Ver `docs/bitcoinhotels-datos-btcmap.md` (nuevo, en este PR). Resumen: BTC Map como fuente
|
||||
de verdad para lodging (ODbL, verified_at real); de los 12 actuales solo Las Verandas está
|
||||
en BTC Map; propuesta (a)/(b)/(c) para los otros: 4×(a) con página oficial de pago
|
||||
(Kessler×3 + Circa), 1×(b) RW "no verificado", 6×(c) retirar.
|
||||
|
||||
## G1 — hardcap-news PR #7: causa del fallo de build-lighthouse + fix en rama (NO mergeado)
|
||||
|
||||
Causa raíz (log del job 125543910450, run 41523126329):
|
||||
1. `npm start` + Lighthouse → "Runtime error… (Status code: 500)" ×3 pasadas: el home
|
||||
(`page.tsx`) llama `getArticles/getBubbles` server-side SIN catch; sin API (CI no levanta
|
||||
backend) el fetch lanza ECONNREFUSED → SSR 500.
|
||||
2. Bug del propio script de CI: con los 3 scores en null, `sorted([None,None,None])[1]`
|
||||
revienta con `TypeError: '<' not supported between instances of 'NoneType'…` en vez de
|
||||
fallar limpio.
|
||||
3. NO es culpa del diff de #7: el mismo job ya estaba rojo en main (run 41514558872 del
|
||||
push del merge de #6, 19:56Z) y en el propio PR #6 (run 41513621707) — #6 se mergeó con
|
||||
CI en rojo. La página nueva de #7 (/topics/[slug]) SÍ tiene .catch() y sirve 200.
|
||||
|
||||
Fix (commit ab6a0c7 en pieza-hub-security, pusheado, PR #7 actualizado — NO mergeado):
|
||||
`page.tsx` con catch → estado vacío (verificado local: `/` 500→200 "No articles yet";
|
||||
Lighthouse móvil 0.92/0.92/0.92, mediana 0.92 ≥ 0.90) + ci.yml ignora scores null (<2
|
||||
válidas = fallo limpio).
|
||||
|
||||
## PRs abiertos al cierre
|
||||
|
||||
| PR | Repo | Estado al cierre |
|
||||
|---|---|---|
|
||||
| #12 revert venues #11 (+saneo #9) | Gitea cayce/bitcoinhotels | **MERGEADO (ci-bot 02:05:15Z) y desplegado** (build-id 95fd5597 verificado) |
|
||||
| #13 e2 guías/news/destinos | Gitea cayce/bitcoinhotels | CI build-e2e-lighthouse corriendo (head b3fad57, re-basado sobre main post-#12) |
|
||||
| #7 fix build-lighthouse | GitHub patternn/hardcap-news | **CI VERDE** (build-lighthouse SUCCESS tras ab6a0c7) — esperando merge del operador |
|
||||
| #8 e2 travel-security-kit | GitHub patternn/hardcap-news | CI rojo por fallo HEREDADO de main (home 500 sin API; ver G1); comentario en el PR: mergear #7 primero |
|
||||
| #56 este doc + propuesta F1 | Gitea cayce/cayce-ops | CI verde (lint-test + isolation-test) |
|
||||
|
||||
## Incidente propio de la ronda (transparencia)
|
||||
|
||||
A las 02:06:29Z la rama local e2-fuentes-y-sellos fue reseteada a ea83ae6 (head del revert)
|
||||
7 segundos después de mi commit b3fad57 — probable carrera con el runner de CI en modo
|
||||
host o con el automerger compartiendo /srv/bitcoinhotels. Detectado via reflog; rama
|
||||
restaurada a b3fad57 y pusheada (origin verificado). Riesgo a vigilar: CI y autodeploy
|
||||
comparten árbol de deploy (hipótesis; no confirmado — NO VERIFICADO el actor exacto).
|
||||
|
||||
## Pendientes del operador
|
||||
|
||||
1. #12 ya mergeado/desplegado. Merge de #13 (bitcoinhotels) cuando CI verde; el deploy es automático.
|
||||
2. Merge de #7 y #8 (hardcap) — #7 arregla además el rojo heredado de main.
|
||||
3. Decidir dónde versionar promo.mjs (hoy sin repo) y si se retocan los captions ya publicados.
|
||||
4. Reanudar promo solo tras merges de E2 (comando arriba).
|
||||
5. F1: aprobar/rechazar la propuesta de docs/bitcoinhotels-datos-btcmap.md.
|
||||
@@ -0,0 +1,146 @@
|
||||
# Ronda 31 — S1 seguridad, S2 branch protection, F1 datos reales, P1/P2 promo, B1 FASE B (OpenCode/GLM, operador patternn)
|
||||
|
||||
Decisiones del operador aplicadas en esta ronda: F1 aprobada tal cual; ~/cayce-social se versiona en entity; los 8 posts con sello "verified 2026-11-02" se eliminan.
|
||||
|
||||
## S1 — El reseteo externo de la rama e2 (02:06:29Z del 2026-11-03)
|
||||
|
||||
**Causa raíz (identificada con journal + reflog): NO fue el CI.** El job 201 del
|
||||
runner corrió 02:08:08 con "Working directory is /root/.cache/act/…/hostexecutor"
|
||||
(log del job) — nunca en /srv. La secuencia real:
|
||||
- 02:05:15 el auto-merger mergea #12; 02:06:00 el AUTODEPLOY empieza a desplegar
|
||||
(captura OLD=ea83ae6 — HEAD del árbol, que estaba en la rama del revert).
|
||||
- 02:06:22 mi sesión crea la rama e2 y comitea b3fad57 EN EL MISMO ÁRBOL, a mitad
|
||||
de deploy (sin lock que impida operaciones manuales concurrentes).
|
||||
- 02:06:23 el autodeploy restartea el servicio (journal: sudo systemctl restart
|
||||
desde PWD=/srv/bitcoinhotels); su check de identidad compara HEAD — que ya era
|
||||
b3fad57 — contra el build 95fd559 → mismatch → rollback `git reset --hard $OLD`
|
||||
= ea83ae6 → **pisa la rama e2** (02:06:29).
|
||||
|
||||
**Fixes aplicados y probados:**
|
||||
1. **flock compartido** `/run/lock/cayce-git-ops.lock` (tmpfiles.d, 0664
|
||||
root:ubuntu) entre autodeploy (flock -n: salta el ciclo) y auto-merger
|
||||
(flock -w 240: espera). Scripts versionados en cayce-ops (PR #58). Prueba
|
||||
real: journal 03:00:01 "auto-merge (u otra op) mantiene el lock — paso de
|
||||
este ciclo" con el lock sostenido; run con lock libre fluye normal.
|
||||
2. **CI nunca en /srv — verificado y blindado**: el runner ya NO corre como
|
||||
root: act-runner.service User=ci-runner + config
|
||||
/etc/cayce/act-runner.yaml con workdir_parent=/var/lib/gitea-act/work
|
||||
(dedicado). Jobs verificados: "workspace OK:
|
||||
/var/lib/gitea-act/work/<id>/hostexecutor" (guard en los workflows de los
|
||||
3 repos Gitea). El probe de isolation.yml ahora da OK-INACCESIBLE para
|
||||
/srv/cayce-core/.env y /srv/cayce-nostr/.env — antes, como root, los jobs
|
||||
PODÍAN leer los secretos de producción (hoyo cerrado).
|
||||
3. **Zombies**: bitcoinhotels.service (legacy, 10.514 restarts crash-loop
|
||||
EADDRINUSE contra el puerto 3002 de producción) y gitea-act-runner.service
|
||||
(8.679 restarts por lock del .runner) → stop+disable (reversible).
|
||||
Producción verificada 200 antes/después.
|
||||
4. **Hallazgo derivado**: el workflow de bitcoinhotels dejaba `npm start`
|
||||
vivos (puerto 3106) tras cada corrida — 5 procesos acumulados (algunos del
|
||||
2-nov), algunos mios de pruebas. Limpieza + `fuser -k 3106/tcp` antes y
|
||||
después del paso de lighthouse (PR #14). Esto además desestabilizaba el
|
||||
gate (0.78-0.83 con procesos vivos; verde tras limpiar).
|
||||
|
||||
## S2 — Branch protection GitHub patternn/hardcap-news
|
||||
|
||||
`main` protegida: required_status_checks strict + **build-lighthouse**
|
||||
obligatorio, enforce_admins=true, no force-push, no deletes.
|
||||
**Prueba real**: PR #9 con error de sintaxis a propósito → build-lighthouse
|
||||
FAIL → `gh pr merge`: "the base branch policy prohibits the merge"; con
|
||||
`--admin` también rechaza ("Required status check 'build-lighthouse' is
|
||||
failing"). PR cerrado y rama borrada tras la prueba. Esto cierra la clase del
|
||||
incidente #6 (mergeado con CI rojo).
|
||||
|
||||
## F1 — Ejecutada (PR #14 bitcoinhotels, CI verde)
|
||||
|
||||
- `src/data/lodging-btcmap.json`: 843 alojamientos del dump completo (API v2,
|
||||
2026-11-03), ODbL + verified_at real (check_date:currency:XBT — validado
|
||||
contra API v4: Las Verandas 2025-07-15 en ambas).
|
||||
- `src/data/lodging-curated.json`: Kessler×3 (kesslercollection.com/bitpay,
|
||||
2026-11-03, quote) + Circa (circalasvegas.com/bitcoin: ATM 24/7 + paquete
|
||||
1 BTC) + RW unverified (Gemini 2021, 8newsnow).
|
||||
- hotels.json 12→6; retiro de los 6 sin evidencia con redirect permanente
|
||||
(308) a su página de destino; sello "Verified AAAA-MM-DD" SOLO con registro
|
||||
(badge enlaza a la evidencia); RW muestra "Unverified".
|
||||
- Probado en copia aislada /tmp: badges correctos, 6 redirects OK, build 200.
|
||||
|
||||
**Incidente propio:** un build de prueba inicial corrió en el árbol de deploy
|
||||
y sobrescribió el .next de producción ~7 min (contenido F1 sin merge).
|
||||
Restaurado en el acto (build-id servido 2fda9852 == main, home 200). Desde
|
||||
entonces toda prueba va en copias /tmp. Además el primer push del PR perdió
|
||||
un patch (redirects) por un script mío incompleto — detectado al probar,
|
||||
corregido en el mismo PR.
|
||||
|
||||
## P1 — cayce-social versionado en entity (PR #9 entity + PR #59 cayce-ops)
|
||||
|
||||
- entity `social/` {promo.mjs, guard12.mjs, social.mjs, .env.example (solo
|
||||
nombres), README}: código igual con 2 cambios — estado fuera del checkout
|
||||
(PROMO_STATE_HOME → /var/lib/cayce/promo) e imports relativos.
|
||||
- cayce-ops deploy/systemd: units actualizadas (WorkingDirectory=
|
||||
/srv/cayce-core/social, EnvironmentFile=/var/lib/cayce/promo/.env).
|
||||
- Campaña SIGUE PAUSADA (timer stop+disable). Instalación post-merge pendiente
|
||||
(migrar estado, instalar units, renombrar ~/cayce-social → .pre-repo).
|
||||
|
||||
**Hallazgo grave derivado (S1):** el CI de entity FALLÓ al dejar de correr
|
||||
como root — guard.test.mjs leía `/srv/cayce-core/.env`, los node_modules y
|
||||
guard.mjs de PRODUCCIÓN: **los tests de CI corrían contra la BD de producción
|
||||
y sus secretos**. Arreglado en el mismo PR: postgres temporal aislado
|
||||
(initdb en el workspace, puerto 55432, schema ci-test-schema.sql), require
|
||||
relativo y PGURL por env. Verificado 27/27 aislado y 27/27 local. Ambos
|
||||
PRs tocan paths protegidos → requieren TU merge.
|
||||
|
||||
## P2 — Los 8 posts con sello "verified 2026-11-02"
|
||||
|
||||
- **4 Facebook BORRADOS** vía `sfeed posts delete --yes` (verificado:
|
||||
`sfeed posts list` ya no los muestra):
|
||||
1013900045145494_{122134510088947378, 122134520570947378,
|
||||
122134544900947378, 122134572668947378}
|
||||
- **4 Instagram NO se pueden borrar** con las herramientas actuales: sfeed
|
||||
solo gestiona FB Page posts; tokens.json guarda tokens del servicio sfeed,
|
||||
no tokens Meta directos. URLs para borrado manual:
|
||||
- https://www.instagram.com/p/DfOtHrGER3P/ (d1-ig-seed)
|
||||
- https://www.instagram.com/p/DfPXaOcluHv/ (d2-ig-atm-fees)
|
||||
- https://www.instagram.com/p/DfQAnd7FLxK/ (d3-ig-rescue)
|
||||
- https://www.instagram.com/p/DfQqORToaBN/ (d4-ig-device)
|
||||
- **Audit log**: actions_log id 1292 (action posts_deleted_r31, detalle con
|
||||
URLs + herramienta + motivo) + posts_log ids 20-27 actualizados (4
|
||||
"deleted", 4 "deletion-pending-manual").
|
||||
- Los 2 posts del 19-oct (campaña vieja, sin sello) NO se tocaron — fuera de
|
||||
la decisión.
|
||||
|
||||
## B1 — FASE B: propuesta (NO publicada)
|
||||
|
||||
`docs/bitcoinhotels-faseb.md` (en este PR): 58 alojamientos BTC Map en las
|
||||
ciudades del plan con id/nombre/verified_at/métodos — El Zonte 32 (ola de
|
||||
re-verificación abr-may 2026), San Salvador 11, Lugano 7, Roatán/Próspera 5,
|
||||
Prague 2, Lisboa 1 — y las 4 primeras guías de ciudad (El Zonte, San Salvador,
|
||||
Lugano, Roatán & Próspera) construidas SOLO sobre el snapshot + fuentes
|
||||
primarias citadas, con reglas de publicación (sin números manuales, ODbL,
|
||||
aviso de verificación antigua, no auto-republish).
|
||||
|
||||
## PRs abiertos al cierre
|
||||
|
||||
| PR | Repo | Estado al cierre |
|
||||
|---|---|---|
|
||||
| #58 s1: flock versionado + guard | cayce/cayce-ops | CI verde; toca paths protegidos → TU merge |
|
||||
| #59 p1: units promo | cayce/cayce-ops | **MERGED** (auto, verde) |
|
||||
| #60 este doc | cayce/cayce-ops | **MERGED** |
|
||||
| #14 f1: datos reales + redirects + sello | cayce/bitcoinhotels | **CI verde** (lighthouse 0.9x tras limpiar procesos fugados; toca workflows → TU merge) |
|
||||
| #9 p1: cayce-social en entity | cayce/entity | **CI verde** (postgres temporal por socket unix; 27/27 aislados) — toca guard* → TU merge |
|
||||
|
||||
Epílogo técnico de entity#9 (3 iteraciones de CI, todas documentadas en el PR):
|
||||
postgres del CI por TCP fallaba con EADDRINUSE en 127.0.0.1 para CUALQUIER
|
||||
puerto dentro del workspace del runner (55432 efímero, 15432 también) —
|
||||
resuelto con socket unix únicamente (listen_addresses vacío, -k $PGDATA,
|
||||
PGURL con ?host=$PGDATA). Verificado 27/27 aislados.
|
||||
|
||||
GitHub: hardcap-news #8 (e2 travel-security-kit) rebaseado sobre main post-#7,
|
||||
CI re-corriendo — al verde queda mergeable bajo la nueva protección.
|
||||
|
||||
## Pendientes del operador
|
||||
|
||||
1. Merges: bh #14, entity #9, cayce-ops #58/#59 (todos tocan paths protegidos).
|
||||
2. Tras merge entity#9+cayce-ops#59: yo migro estado a /var/lib/cayce/promo,
|
||||
instalo units y renombro ~/cayce-social (avisame o lo hago en la próxima).
|
||||
3. Borrar a mano los 4 posts de IG (URLs arriba).
|
||||
4. B1: aprobar/gestionar las 4 guías propuestas.
|
||||
5. Reanudar promo solo cuando lo decidas: `sudo systemctl enable --now cayce-promo.timer`.
|
||||
@@ -0,0 +1,45 @@
|
||||
# Ronda 32 — Post-merge P1, FASE B publicada, reporte diario v2, campaña v4 propuesta (OpenCode/GLM, operador patternn)
|
||||
|
||||
Regla nueva aplicada: **R7/D4** (nada de compilar/instalar/probar en /srv/*; copias en /tmp o workspace del runner) — en DECISIONS.md vía PR #62.
|
||||
|
||||
## 1. Post-merge P1 — HECHO
|
||||
|
||||
- Estado migrado a `/var/lib/cayce/promo/` (.env 600 ubuntu, promo-state.json, campaign-start.json, media/) · units instaladas desde el checkout (`deploy/systemd/cayce-promo.{service,timer}`) + daemon-reload · **timer sigue disabled** (campaña pausada, verificado inactive).
|
||||
- `~/cayce-social` archivado: `/var/backups/cayce/forensics/cayce-social-pre-repo-20261103.tar.gz` (194 archivos) y el dir renombrado a `~/cayce-social.archived-pre-repo` (nada borrado).
|
||||
- **Autodeploy de entity incluye social/**: deploy del merge #9 a las 15:03:18 → `entity → 10b1aaf (tests 27/27, watcher OK, live)`; `ls /srv/cayce-core/social/` → promo.mjs, guard12.mjs, social.mjs, README.md.
|
||||
- Código desplegado verificado EN /tmp (R7): `node --check` ×3 OK y guard12 **12/12 aprobados**.
|
||||
|
||||
## 2. FASE B — 4 guías publicadas (PRs auto-mergeados)
|
||||
|
||||
Cada PR: solo `src/data/guides.json` (sin paths protegidos), guard previo contra postgres temporal aislado en /tmp, auditoría factual en el cuerpo del PR, ≥600 palabras propias, ODbL + merchant id + snapshot datado, avisos de verificación antigua.
|
||||
|
||||
| PR | Guía | Guard | Palabras | Estado |
|
||||
|---|---|---|---|---|
|
||||
| #16 (1º intento #15 cerrado por type error `heading` vs `title`) | el-zonte-where-to-sleep | APROBADO | 823 | MERGED, deploy 1ed847d, **200 en vivo** |
|
||||
| #17 | san-salvador-base-camp | APROBADO | 670 | MERGED, **200 en vivo** |
|
||||
| #18 | lugano-plan-b-stay | APROBADO | 643 | MERGED (deploy en el pase siguiente) |
|
||||
| #19 | roatan-prospera-stay | APROBADO | 647 | abierto al cierre de este doc (CI/automerge en curso) |
|
||||
|
||||
Fuentes usadas (todas citadas en el texto): btcmap.org snapshot 2026-11-03 (lodging), Reuters 2025-01-30 y Forbes 2025-02-28 (reforma ES), planb.lugano.ch (Lugano), Reuters 2022-04-07 (Próspera), bitcoinbeach.com + wearebitcoin.org (El Zonte 2019). Corrección de honestidad durante la ronda: el sitio de Las Verandas NO documenta pago bitcoin (verificado) — la guía cita solo el survey de BTC Map.
|
||||
|
||||
## 3. Reporte diario — HECHO (PR #63 MERGED + instalado)
|
||||
|
||||
Tres secciones nuevas en `cayce-daily-report`: **3b PRs que esperan tu merge** (Gitea, con motivo calculado contra la lista de paths protegidos; GitHub hardcap referenciado — el VPS no tiene token GitHub), **Contenido nuevo publicado hoy por sitio** con enlaces vivos (guías bh desde el git del árbol desplegado; notas hc por article_id), y **línea semanal AdSense los lunes** (checklist 5 puntos por sitio). Prueba en seco OK.
|
||||
|
||||
## 4. Campaña promo v4 — PROPUESTA (docs/promo-campana-r32.md, este PR)
|
||||
|
||||
8 posts / 8 días, cada afirmación con fuente primaria citada (tabla completa afirmación→fuente en el doc). Sin sellos "verified" salvo snapshot/evidencias reales. NO se reanuda nada: requiere tu aprobación + idealmente borrar antes los 4 IG pendientes.
|
||||
|
||||
## Incidencias de la ronda (encontradas y arregladas)
|
||||
|
||||
1. **hardcap-news llevaba sin desplegar desde el 1-nov**: el VPS no podía hacer `git fetch` de GitHub. Fix: deploy key **read-only** (`deploy-readonly-vm2047`, key id 168607734) + remote SSH. Fetch OK → main c453b2d visible.
|
||||
2. **hardcap entró en rollback eterno**: el check de identidad grep-ea `meta name="build-id"` que main NUNCA tuvo (NEXT_PUBLIC_BUILD_ID existe desde #6 pero no se renderizaba) → todo deploy rueda atrás. Fix: **GitHub PR #10** (meta en layout, patrón bh; CI verde tras re-run de un flaky de Google Fonts) — **espera tu merge**.
|
||||
3. **El rollback de hardcap abortaba el autodeploy completo**: `exit 1` antes de la sección bitcoinhotels → bh #16/#17 mergeados sin desplegar (15:32-15:43). Fix: sección hardcap en **subshell** (PR #64 + instalado). Evidencia de que funciona: 15:52:07 rollback hardcap y 15:52:32 `bitcoinhotels → 1ed847d (200 + umami + 0 marcas)`.
|
||||
4. PR #15 cerrado por mi error de tipo (heading vs title en sections) — reabierto como #16 con fix.
|
||||
|
||||
## Pendientes del operador
|
||||
|
||||
1. **Merge de GitHub #10** (meta build-id) — desbloquea el deploy de hardcap (main lleva desde el 1-nov sin llegar a producción).
|
||||
2. Aprobar/rechazar campaña v4 (docs/promo-campana-r32.md).
|
||||
3. Borrar los 4 IG pendientes (URLs en doc r31) antes de reactivar promo.
|
||||
4. PR #62 (D4/R7 en DECISIONS) y #64 (subshell) esperan tu merge si quieres revisarlos; el resto se auto-mergea.
|
||||
@@ -0,0 +1,115 @@
|
||||
# Ronda 33 — Loop hardcap, política de DMs, directiva BTCPay, inbox 10050, aprobaciones por reacción (OpenCode/GLM, operador patternn)
|
||||
|
||||
> Deuda corregida: el doc de la r32 quedó sin PR al cerrar esa ronda — se
|
||||
> incluye aquí como archivo aparte (2026-11-03-r32-postmerge-faseb-reportes.md).
|
||||
|
||||
## 1. Loop de rollback en hardcap — RESUELTO
|
||||
|
||||
- **Estado al abrir**: producción hardcap en `a5c2f59` (build del 1-nov),
|
||||
sirviendo 200; **34 rollbacks** entre 15:10:06 y 16:09:58 UTC (uno por ciclo
|
||||
de 3 min), todos `build-id '' != 'c453b2df'`.
|
||||
- **Causa raíz** (dos capas): (a) el fetch de GitHub del VPS llevaba roto
|
||||
desde el 1-nov (arreglado en r32 con deploy key read-only); (b) al revivir
|
||||
el fetch, el check de identidad grep-ea `meta name="build-id"` que main
|
||||
**nunca renderizó** (gh#10 lo añade; sigue abierto) → rollback eterno.
|
||||
- **Arreglos** (PR cayce-ops #65 + instalados):
|
||||
1. identidad de hardcap exigida **solo si ESTE main renderiza la meta**
|
||||
(`git grep name=.build-id. layout.tsx`) — con gh#10 mergeado y desplegado
|
||||
el check se reactiva solo;
|
||||
2. `dm_once`/`dm_clear`: **un DM por incidente** (subject `repo:causa`),
|
||||
limpiado por deploy exitoso; journal completo vía `say` (silencio en DM,
|
||||
no en audit).
|
||||
- **Resultado verificado**: deploy manual exit=0 → `hardcap-news → c453b2d
|
||||
(200)` — main del 3-nov EN producción (hubs /topics/* 200, texto del
|
||||
travel-security-kit corregido) — y `bitcoinhotels → 5dbff23` (4ª guía viva).
|
||||
- Sitio caído = urgencia real: cubierto por urgent-watch (caída >15 min),
|
||||
no por el rollback (que mantiene el sitio arriba en el build anterior).
|
||||
|
||||
## 2. Política de DMs — REEMPLAZADA (PR #66 + instalada)
|
||||
|
||||
- urgent-watch v2: DM inmediato SOLO (1) kill switch manual o fuga (violaciones
|
||||
del watcher), (2) servicio/sitio caído >15 min, (3) backup fallido **2 días
|
||||
seguidos**, (4) gasto Gemini > umbral. Fuera: mudos, CODEOWNERS, initiative,
|
||||
rollbacks recuperados, publicaciones, rechazos → SOLO resumen diario 23:50
|
||||
(verificado OnCalendar=23:50). Ciclos pausados a propósito (promo) sin
|
||||
alertas.
|
||||
- Dedup por **tipo:sujeto** (24 h). **Tope 3 urgentes/día**: al 4º,
|
||||
diferido a `.dm-deferred.log` → una línea en el resumen (sección 2b nueva).
|
||||
- **Conteo 24 h (evidencia del antes)**: **83 DMs** — 18 rollback hardcap, 26
|
||||
codeowners, 6 mudos, 6 aborts dirty, 10 copias del reporte diario (bug de
|
||||
reenvío anotado), resto varios.
|
||||
- **Simulación DRYRUN de cada tipo** (estados falsos en /tmp, sin enviar):
|
||||
killswitch:manual ✓ · fuga:watcher ✓ · down:fake-down.service (20 min) ✓ ·
|
||||
backup:2días ✓ · gasto:gemini ($9>$1) ✓ · tope→deferred ✓ (evidencia en
|
||||
`.dm-deferred.log` del simulacro).
|
||||
|
||||
## 3. Directiva BTCPay — DESACTIVADA
|
||||
|
||||
- `CAYCE_DIRECTIVE_BTCPAY=0` en /srv/cayce-core/.env (generación de nuevas
|
||||
oportunidades BTCPay cortada de raíz).
|
||||
- Archivados: drafts **#50, #51, #52** (los tres BTCPay generados HOY por la
|
||||
directiva: 02:00, 08:00 y 16:00) + verificación de que **#33** y la
|
||||
oportunidad **#106** ya estaban archived. Audit: actions_log id 1306.
|
||||
- **Qué publicó initiative hoy**: 3 ciclos (02:00/08:00/16:00) pero **UNA
|
||||
sola nota nostr publicada** — id 381, 08:00:15 UTC, event
|
||||
`7389a478df83e39f0648b6c42295b4205c454ea9277827245923af9578f92417`, texto:
|
||||
"Event ticketing infrastructure that forces custodial payment processors or
|
||||
third-party tracking degrades bitcoiner operational security. Open-source
|
||||
merchant rails like BTCPay Server paired with local, peer-to-peer
|
||||
directories eliminate trusted third parties at the physical layer."
|
||||
**Guard: APROBADO** (canal nostr, tipo initiative_note, postgres temporal
|
||||
aislado) → se queda; no hubo que borrar nada con kind 5.
|
||||
- Pendiente reportado: 20 oportunidades BTCPay en estado `identified`
|
||||
quedan en el pipeline (sin nueva generación); si las quieres archivadas,
|
||||
dilo y lo hago. El producto vive solo en cayce/btcpay-events (repo intacto).
|
||||
|
||||
## 4. Inbox de Cayce (kind 10050) — PUBLICADO
|
||||
|
||||
- Diagnóstico: el daemon **lee** gift wraps NIP-17 (kind 1059 → seal 13 →
|
||||
chat 14 del supervisor, con manejo de comandos) pero **nunca publicó el kind
|
||||
10050** — de ahí "DM inbox relays not found" en tu cliente.
|
||||
- `publish-10050.mjs` (en /srv/cayce-nostr, herramienta operativa): consultó
|
||||
los 5 relays → **0 existentes** → publicó event
|
||||
`7694c0f61b747c45a76555d84a8c2281fa32db25039f5509afa8e4a4ddf05dee`
|
||||
(pubkey 59ef3b5d…, relays damnos/nos.lol/primal/snort/wellorder)
|
||||
**verificado en 5/5**. Idempotente (no república si hay uno <30 días).
|
||||
- **Prueba pendiente tuya**: mándame un DM NIP-17 — en el journal del daemon
|
||||
aparecerá `[DM supervisor NIP-17] …` (24 h últimas: 0, nunca llegó ninguno
|
||||
porque el cliente no encontraba el inbox). Nota: /srv/cayce-nostr no es repo
|
||||
git — drift pendiente de versionar (igual que el daemon).
|
||||
|
||||
## 5. Aprobación por reacción — IMPLEMENTADA (entity PR #10, WIP, LO MERGEAS TÚ)
|
||||
|
||||
Diseño completo en `docs-approvals.md` (dentro del PR). Resumen:
|
||||
- Pregunta por DM NIP-17 con **ID único, acción, efecto y vencimiento 48 h**.
|
||||
- Aprobación = reacción 👍 o **+** a ESE mensaje, **seal NIP-17 firmado por
|
||||
SUPERVISOR_NPUB_HEX** (fallback: kind 7 pública con #e). 👎/otra/nada = no
|
||||
se hace nada.
|
||||
- Ejecución **idempotente** (FOR UPDATE + executed_at): `merge_pr` (ci-bot,
|
||||
para PRs de paths protegidos), `resume_promo`/`pause_promo`, registro
|
||||
`approved:` para campañas/zona roja. Audit en actions_log con el event id
|
||||
de la reacción; confirmación SOLO en el resumen diario.
|
||||
- **Tests 6/6 en CI** (postgres temporal): otra pubkey ignorada · otro
|
||||
mensaje ignorado · 👎 ignorada · vencida no ejecuta · válida ejecuta UNA
|
||||
vez · sweep de vencidas.
|
||||
- **Prueba real preparada**: tras tu merge, abro un PR de prueba tocando un
|
||||
path protegido, te llega la pregunta, reaccionas 👍 y verificamos el merge
|
||||
por ci-bot.
|
||||
|
||||
## Incidencias propias de la ronda
|
||||
|
||||
1. Al instalar el autodeploy parcheado, un pase lo estaba ejecutando (bash
|
||||
lee incrementalmente) → errores transitorios por 1 ciclo (16:13:36,
|
||||
documentados en journal); el pase siguiente y el manual salieron limpios.
|
||||
Lección aplicada: instalar scripts solo tras `flock` o entre ciclos.
|
||||
2. El primer commit del PR entity arrastró el .pgtmp de pruebas → limpieza
|
||||
en el mismo PR antes de que lo tocaras.
|
||||
|
||||
## Pendientes del operador
|
||||
|
||||
1. **Merge gh#10** (meta build-id de hardcap; CI verde) — reactiva el check
|
||||
de identidad de hardcap al desplegarse.
|
||||
2. **Merge entity PR #10** (aprobaciones, WIP a propósito) → instalo la unit
|
||||
y corremos la prueba real de reacción.
|
||||
3. Mándame un DM NIP-17 para cerrar la prueba del inbox.
|
||||
4. PRs cayce-ops #65/#66 (auto-mergeables) y el doc de esta ronda.
|
||||
@@ -23,7 +23,7 @@ SIGNAL — hardcap.news
|
||||
EVENTS — where the ecosystem meets
|
||||
[List the real upcoming events provided. For 1-2 of them add one short line: what a bitcoiner traveling there finds at bitcoinhotels.org. Only real events provided.]
|
||||
|
||||
ZAPS fund the signal. ⚡ optional.
|
||||
ZAPS fund the signal. No emojis, ever.
|
||||
|
||||
Rules: English. Max ~1100 characters total. Every claim must come from the input data — QC-1, no fabrication. Stories already include URLs; keep them intact.
|
||||
<!-- /cayce-identity:block=digest -->
|
||||
@@ -63,3 +63,11 @@ Write ONE post (max 500 characters) about the upcoming bitcoin events listed bel
|
||||
You are Cayce — autonomous entity, Próspera ZEDE, operator of hardcap.news. Write a short editorial (max 130 words) in ENGLISH: summarize the latest developments in this bitcoin topic category from the material given, then add your own take. Voice: short sentences, pattern-vs-apophenia lens, zero corporate vocabulary, no emojis, no exclamation marks, no markdown, no financial advice. Acidic wit is mandatory: dry irony, deadpan, the observation that stings a little. NEVER sound like marketing: no hype, no selling, no "check out", no calls to action, no performed enthusiasm — if a line could run in an ad, delete it. End with one sharp line of judgment.
|
||||
<!-- /cayce-identity:block=editorial -->
|
||||
|
||||
<!-- cayce-identity:block=voz-hardcap -->
|
||||
You are Cayce, operator of hardcap.news. hardcap is SIGNAL, not commentary: one to three lines. Line 1: what happened, flat. Line 2: why it is signal and not noise (one sentence, no adjectives). Line 3: the source, always a URL, always a date (YYYY-MM-DD). No emojis, no exclamation marks, no hashtags, no marketing, no adjectives doing the work of facts. If you cannot source it, you do not publish it.
|
||||
<!-- /cayce-identity:block=voz-hardcap -->
|
||||
|
||||
|
||||
<!-- cayce-identity:block=voz-bitcoinhotels -->
|
||||
You are Cayce, curator of bitcoinhotels.org. You write FIELD GUIDES: practical, step-by-step, verifiable by the reader in minutes. Number the steps. Imperative voice. Every factual claim carries a source URL and a date. Guides survive a reader following them offline with a phone: no assumptions, no jargon without one-line definitions. Where a step can cost someone money, add the warning inline, plainly. No emojis, no exclamation marks, no hashtags, no marketing language. Verify-before-you-publish is the product.
|
||||
<!-- /cayce-identity:block=voz-bitcoinhotels -->
|
||||
|
||||
Reference in New Issue
Block a user