# sandokan-watch — vigía: `--every 60 --state /var/lib/sandokan-watch.json --record --root /var/lib/tupu`.
#
# El paquete es `sandokan-seguridad-core` y el binario `sandokan-watch`.
# ⚠ Escribe en `/var/lib/tupu`, el mismo directorio que `tupu` y `matilda` (ver esa receta).
#
# Receta Cargo contra el monorepo de tawasuyu, pinneada al MISMO commit que `shuma-*` y
# `puriy-costura`: el árbol de fuentes se comparte por `<dep>-<sha>`, así que un pin distinto es otro
# vendoreo de 2,4 G. Estática musl con zig-cc — la caja la arranca el init y no puede depender de
# encontrar un cargador, que es justo lo que le falta al binario glibc de gioser.

name    = "sandokan-watch"
version = "0.1.0"
license = "MIT OR Apache-2.0"

[source]
repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
commit = "23a292863f53b355c5c02d6185904f2c33d8ab42"
# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
# RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
cargo_vendor_dir = ".hammer-cargo-vendor"

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
link     = "static"
flags    = ["-p", "sandokan-seguridad-core", "--bin", "sandokan-watch"]

# ── EL SERVICIO (SDD 30) ────────────────────────────────────────────────────────────────────────
# Fuera de `hash_inputs`: declararlo no re-hashea.
#
# ⚠ **CORRE COMO ROOT, Y NO ES UN DESCUIDO — ES UNA RESTRICCIÓN MEDIDA.** Lo natural sería una
# cuenta propia sin privilegio, como `shuma` o `gitea`. Acá no se puede, por dos hechos:
#
#   1. `matilda` lee `/var/log/caddy/requests.json`, que caddy crea **`-rw------- root root`** y
#      recrea igual en cada rotación. Un grupo con lectura se pierde en la próxima rotación.
#   2. Los tres —`tupu`, `matilda`, `sandokan-watch`— escriben en el MISMO `/var/lib/tupu`, y en
#      gioser sus 322 ficheros son `root:root`. Bajar a uno solo deja mezcla de dueños en un árbol
#      compartido, que es la trampa de siempre: escribe el primero y los otros fallan al modificar.
#
# ⇒ o los tres como root, o ninguno. La salida limpia existe y está anotada para el día que se
# quiera: que caddy escriba su log con lectura de grupo (`output file … { mode 640 }`) y que el
# árbol sea de una cuenta `tupu`. Mientras tanto, esto es lo que HACE la máquina vieja, declarado
# en vez de heredado.
[[service]]
label      = "sandokan-watch"
id         = "01M2EKDA005AND0KANWATCH001"
exec       = "/bin/busybox"
argv = ["sh", "-c", "test -d /var/lib/tupu || mkdir -p /var/lib/tupu || exit 78; test -r /var/log/auth.log || command -v journalctl >/dev/null || { echo 'sandokan-watch: no hay FUENTE DE ACCESOS en esta máquina (ni /var/log/auth.log ni journalctl). El binario arranca igual y NO GUARDA NADA: un vigía verde que no vigila. En takana hace falta darle el diario de arje o una fuente equivalente.' >&2; exit 78; }; exec /usr/bin/sandokan-watch --every 60 --state /var/lib/sandokan-watch.json --record --root /var/lib/tupu"]
envp       = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
networking = "full"
cgroup     = "arje.slice/sandokan-watch"
restart    = { initial_ms = 1000, max_ms = 30000 }

# ⚠ MEDIDO EN LA CAJA (2026-09-16): acá NO PUEDE TRABAJAR, y lo dice él mismo:
#
#     sandokan-watch · sin fuente de accesos (ni /var/log/auth.log ni journalctl): no se guarda nada
#
# En gioser lee el `auth.log` de un syslog que en takana no existe —no hay systemd ni syslog— así
# que el servicio arrancaba, quedaba «corriendo · 0 reinicios» y no guardaba una línea. Por eso la
# guarda de arriba sale 78 en vez de dejarlo verde: **un vigía que no vigila es peor que uno caído,
# porque el caído se ve**. Destrabarlo es darle el diario de arje como fuente, y eso es trabajo de
# su propio repo, no de esta receta.