# matilda — grabador: `matilda record --interval 60 --root /var/lib/tupu --access-log …`.
#
# ⚠ Lee el ACCESS LOG de caddy (`/var/log/caddy/requests.json`). En la caja nueva ese fichero
# existe sólo si el Caddyfile importa el snippet `acceso` — que sí lo hace. Si algún día deja
# de hacerlo, matilda no falla: graba vacío.
# El crate vive en `02_ruway/shuma/baremetal/matilda-app` y su paquete se llama `matilda`.
#
# 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    = "matilda"
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", "matilda", "--bin", "matilda"]

# ── 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      = "matilda"
id         = "01M2EKDA00MAT1DA0GRABA0001"
exec       = "/bin/busybox"
argv = ["sh", "-c", "test -d /var/lib/tupu || mkdir -p /var/lib/tupu || exit 78; test -r /var/log/caddy/requests.json || { echo 'matilda: no puedo leer /var/log/caddy/requests.json — sin el access log de caddy graba VACÍO y nadie lo nota' >&2; exit 78; }; exec /usr/bin/matilda record --interval 60 --root /var/lib/tupu --access-log /var/log/caddy/requests.json"]
envp       = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
networking = "full"
cgroup     = "arje.slice/matilda"
restart    = { initial_ms = 1000, max_ms = 30000 }