tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

⎇ 8bf1623044075274682e4351a0f8e120047c2bed docs/06-swm-format.md Markdown · 113 lines · 4.6 KB History raw

Scaffold inicial: workspace Rust + SDDs completos 8bf162304 · sergio ·

1# SDD 06 — Formato `.swm` (Software Mutación)
2
3El `.swm` es la unidad de intercambio de `hammer`. **No es un paquete binario** (`.deb`,
4`.rpm`, ni un `PKGBUILD` que compila quién-sabe-qué). Es un **manifiesto de la mutación**: la
5receta de transformación sobre código fuente público, más las ediciones de configuración. El
6receptor reproduce y verifica localmente; **nunca ejecuta tu binario** (ver
7[SDD 09](09-trust-model.md)).
8
9## 1. Esquema
10
11```yaml
12# my-grep-tweak.swm
13swm_version: 1
14
15base:
16  distro_version: "2026-06-06"      # versión del set base de hammer
17  pins:                              # commits fijados de los upstreams relevantes
18    kernel: "a1b2c3d…"
19    musl:   "e4f5a6b…"
20  # base_hash deriva de pins+distro_version; el receptor verifica compatibilidad
21
22mutations:
23  - type: source_patch              # recompilar una herramienta desde su fuente parcheada
24    repo: "git://git.savannah.gnu.org/grep.git"
25    commit: "a1b2c3d…"              # commit fijado sobre el que aplica el patch
26    patch: |                         # parche .patch de git, embebido o por URL (patch_url)
27      --- a/src/main.c
28      +++ b/src/main.c
29      @@ ...
30    build:
31      compiler: "zig-cc"
32      target: "x86_64-linux-musl"
33      link: "static"
34      flags: ["--enable-perl-regexp"]
35    target_bin: "/bin/grep"
36
37  - type: config_edit               # editar un archivo de config en texto plano
38    file: "/etc/network.conf"
39    inline_diff: |
40      - DHCP=yes
41      + IP=192.168.1.100
42
43  - type: init_rule                 # añadir/ajustar una regla del init (ver SDD 07)
44    action: "watchdog"
45    service: "web"
46    command: "/bin/myweb -p 8080"
47
48signature:                           # opcional pero recomendado (ver SDD 09)
49  by: "sergio"
50  alg: "ed25519"
51  sig: "base64…"
52```
53
54## 2. Tipos de mutación
55
56| `type` | Qué describe | Cómo lo aplica el receptor |
57|---|---|---|
58| `source_patch` | recompilar una herramienta desde fuente parcheada | clona repo@commit → aplica patch → `hammer build` → hidrata en overlay |
59| `config_edit` | edición de un archivo de config | aplica el `inline_diff` (3-way) sobre el archivo objetivo |
60| `init_rule` | regla del bus de init | inyecta la regla vía `/run/init.control` / receta de servicio |
61| `file_drop` | depositar un archivo de datos no compilable | escribe el archivo (con su hash declarado) en la ruta |
62
63Cada `source_patch` es, en esencia, una `Recipe` ([SDD 02](02-build-lab.md)) serializada para
64viajar. El `build` lleva el **compilador por mutación** (no global).
65
66## 3. Aplicación (`hammer apply`)
67
68```
69hammer apply my-grep-tweak.swm
70```
71
721. **Verifica la base.** ¿Los `pins`/`distro_version` son compatibles con el sistema local?
73   Si no, avisa qué difiere y se detiene (o `--force` bajo tu responsabilidad).
742. **Verifica la firma** (si existe) contra las claves de confianza locales.
753. **Reproduce.** Para cada `source_patch`: clona el repo al commit, aplica el patch, compila
76   en el lab local → obtiene un `artifact_hash`.
774. **Aísla.** Hidrata todo en un **overlay temporal** ([SDD 04](04-overlay.md)); aplica
78   `config_edit`/`init_rule`/`file_drop` en esa capa. **No toca el sistema base.**
795. **Valida.** Corres/pruebas en caliente. Si bien → `hammer commit`. Si mal → `hammer discard`.
80
81Nunca se ejecuta un binario ajeno: sólo se transforma código fuente público con una receta que
82tu propio laboratorio compila.
83
84## 4. Determinismo y verificación cruzada
85
86Como el lab es determinista ([SDD 02](02-build-lab.md)), el `artifact_hash` que produce tu
87máquina debe coincidir con el del autor (si declara `expected_hash`). Coincidencia ⇒ obtuviste
88exactamente el mismo binario, sin haberlo descargado. Discrepancia ⇒ algo difiere (toolchain,
89pin, patch) y `hammer` te dice qué. Esto es "verificar, no confiar" en la práctica.
90
91## 5. No-objetivos del formato
92
93- **No** transporta binarios cocidos (salvo `file_drop` para datos no compilables, con hash).
94- **No** es Turing-completo: es declarativo *para el intercambio*, aunque el sistema que
95  describe se viva imperativamente. (Lo declarativo aquí es honesto: describe una
96  transformación, no aprisiona tu sistema.)
97- **No** asume una arquitectura: `target` viaja en cada `source_patch`.
98
99## 6. Interfaz
100
101```rust
102// hammer-core
103#[derive(Serialize, Deserialize)]
104pub struct Swm { /* swm_version, base, mutations, signature */ }
105impl Swm {
106    pub fn from_yaml(s: &str) -> Result<Swm>;
107    pub fn to_yaml(&self) -> Result<String>;
108    pub fn verify_base(&self, local: &BaseRef) -> BaseCompat;
109    pub fn verify_signature(&self, trust: &TrustStore) -> SigStatus;
110}
111```
112
113CLI: `hammer apply <file.swm>` · `hammer export … > out.swm` · `hammer swm verify <file.swm>`.

06-swm-format.md

SDD 06 — Formato .swm (Software Mutación)

El .swm es la unidad de intercambio de hammer. No es un paquete binario (.deb, .rpm, ni un PKGBUILD que compila quién-sabe-qué). Es un manifiesto de la mutación: la receta de transformación sobre código fuente público, más las ediciones de configuración. El receptor reproduce y verifica localmente; nunca ejecuta tu binario (ver SDD 09).

1. Esquema

# my-grep-tweak.swm
swm_version: 1

base:
  distro_version: "2026-06-06"      # versión del set base de hammer
  pins:                              # commits fijados de los upstreams relevantes
    kernel: "a1b2c3d…"
    musl:   "e4f5a6b…"
  # base_hash deriva de pins+distro_version; el receptor verifica compatibilidad

mutations:
  - type: source_patch              # recompilar una herramienta desde su fuente parcheada
    repo: "git://git.savannah.gnu.org/grep.git"
    commit: "a1b2c3d…"              # commit fijado sobre el que aplica el patch
    patch: |                         # parche .patch de git, embebido o por URL (patch_url)
      --- a/src/main.c
      +++ b/src/main.c
      @@ ...
    build:
      compiler: "zig-cc"
      target: "x86_64-linux-musl"
      link: "static"
      flags: ["--enable-perl-regexp"]
    target_bin: "/bin/grep"

  - type: config_edit               # editar un archivo de config en texto plano
    file: "/etc/network.conf"
    inline_diff: |
      - DHCP=yes
      + IP=192.168.1.100

  - type: init_rule                 # añadir/ajustar una regla del init (ver SDD 07)
    action: "watchdog"
    service: "web"
    command: "/bin/myweb -p 8080"

signature:                           # opcional pero recomendado (ver SDD 09)
  by: "sergio"
  alg: "ed25519"
  sig: "base64…"

2. Tipos de mutación

typeQué describeCómo lo aplica el receptor
source_patchrecompilar una herramienta desde fuente parcheadaclona repo@commit → aplica patch → hammer build → hidrata en overlay
config_editedición de un archivo de configaplica el inline_diff (3-way) sobre el archivo objetivo
init_ruleregla del bus de initinyecta la regla vía /run/init.control / receta de servicio
file_dropdepositar un archivo de datos no compilableescribe el archivo (con su hash declarado) en la ruta

Cada source_patch es, en esencia, una Recipe (SDD 02) serializada para viajar. El build lleva el compilador por mutación (no global).

3. Aplicación (hammer apply)

hammer apply my-grep-tweak.swm
  1. Verifica la base. ¿Los pins/distro_version son compatibles con el sistema local? Si no, avisa qué difiere y se detiene (o --force bajo tu responsabilidad).
  2. Verifica la firma (si existe) contra las claves de confianza locales.
  3. Reproduce. Para cada source_patch: clona el repo al commit, aplica el patch, compila en el lab local → obtiene un artifact_hash.
  4. Aísla. Hidrata todo en un overlay temporal (SDD 04); aplica config_edit/init_rule/file_drop en esa capa. No toca el sistema base.
  5. Valida. Corres/pruebas en caliente. Si bien → hammer commit. Si mal → hammer discard.

Nunca se ejecuta un binario ajeno: sólo se transforma código fuente público con una receta que tu propio laboratorio compila.

4. Determinismo y verificación cruzada

Como el lab es determinista (SDD 02), el artifact_hash que produce tu máquina debe coincidir con el del autor (si declara expected_hash). Coincidencia ⇒ obtuviste exactamente el mismo binario, sin haberlo descargado. Discrepancia ⇒ algo difiere (toolchain, pin, patch) y hammer te dice qué. Esto es "verificar, no confiar" en la práctica.

5. No-objetivos del formato

6. Interfaz

// hammer-core
#[derive(Serialize, Deserialize)]
pub struct Swm { /* swm_version, base, mutations, signature */ }
impl Swm {
    pub fn from_yaml(s: &str) -> Result<Swm>;
    pub fn to_yaml(&self) -> Result<String>;
    pub fn verify_base(&self, local: &BaseRef) -> BaseCompat;
    pub fn verify_signature(&self, trust: &TrustStore) -> SigStatus;
}

CLI: hammer apply <file.swm> · hammer export … > out.swm · hammer swm verify <file.swm>.