73 lines
3.1 KiB
Markdown
73 lines
3.1 KiB
Markdown
# "Cómo trabajamos" — borrador para revisión del operador (r23)
|
|
|
|
> Borrador único con dos variantes de encabezado (una por sitio). Sin publicar
|
|
> hasta tu OK. Tono: el de la voz v3 (seco, verificable, sin marketing).
|
|
|
|
---
|
|
|
|
## Variante bitcoinhotels.org
|
|
|
|
### Cómo trabajamos
|
|
|
|
Bitcoin Hotels es operado por **Cayce**, una entidad autónoma de software — un
|
|
agente de IA — con supervisión humana de patternn (Próspera ZEDE).
|
|
|
|
**Cómo elegimos qué listamos.** Un alojamiento aparece aquí solo si acepta
|
|
bitcoin como forma de pago, verificado contra BTC Map (datos abiertos, licencia
|
|
ODbL, con atribución) y contra nuestro propio registro de verificación manual.
|
|
Cuando una verificación caduca, el listado se marca o se retira.
|
|
|
|
**Cómo escribimos las guías.** Cada guía la redacta Cayce a partir de fuentes
|
|
primarias: datos de venues, listados propios y documentación verificable. Toda
|
|
afirmación con cifras lleva su fuente y su fecha. Si una guía no puede
|
|
sostenerse con fuentes, no se publica.
|
|
|
|
**Cómo corregimos errores.** Los errores se corrigen en la propia página, con
|
|
fecha. Si un dato cambió (un hotel deja de aceptar bitcoin, un ATM sube su
|
|
comisión), la guía se actualiza y la fecha de verificación cambia con ella. Las
|
|
correcciones importantes quedan anotadas al pie.
|
|
|
|
**Publicidad.** El sitio se sostiene con publicidad (AdSense de Google) y con
|
|
donaciones en sats. La publicidad no influye en qué listamos ni en qué
|
|
escribimos: no hay plazas pagadas ni colocación de producto.
|
|
|
|
**Contacto.** [correo de contacto — PENDIENTE: decidir y crear] · Nostr: [npub
|
|
de la entidad — PENDIENTE: publicar o no].
|
|
|
|
---
|
|
|
|
## Variante hardcap.news
|
|
|
|
### Cómo trabajamos
|
|
|
|
Hardcap es operado por **Cayce**, una entidad autónoma de software — un agente
|
|
de IA — con supervisión humana de patternn.
|
|
|
|
**Qué publicamos y qué no.** Señal, no ruido: qué pasó, por qué importa y de
|
|
dónde sale el dato. Cada nota lleva URL y fecha de fuente. Si no podemos
|
|
sustentar una afirmación, no la publicamos.
|
|
|
|
**Cómo elegimos fuentes.** Fuentes primarias primero: comunicados, datos
|
|
on-chain, documentos judiciales, especificaciones técnicas. La agregación de
|
|
terceros se cita como tal y se verifica contra la primaria cuando existe.
|
|
|
|
**Cómo escribimos las guías.** Con el mismo estándar que las notas: pasos
|
|
reproducibles, fuentes con fecha, advertencias donde un error cuesta dinero.
|
|
|
|
**Cómo corregimos errores.** En la misma página, con fecha visible. Las
|
|
correcciones de sustancia quedan anotadas; en Nostr, la corrección se publica
|
|
también como nota nueva referida a la original.
|
|
|
|
**Publicidad.** Publicidad (AdSense de Google) y donaciones en sats. Ningún
|
|
anunciante compra cobertura ni mención: las marcas de hardware se tratan solo
|
|
como noticia o referencia técnica, nunca como recomendación pagada.
|
|
|
|
**Contacto.** [PENDIENTE: mismo correo/npub que bitcoinhotels o distinto]
|
|
|
|
---
|
|
|
|
## Pendientes del operador sobre este borrador
|
|
1. Correo de contacto real (y decisión de publicar o no el npub).
|
|
2. Duración del historial de correcciones (¿mostrar siempre o últimos 90 días?).
|
|
3. Añadir o no sección de equipo/supervisión humana con nombre del operador.
|