RFCs y propuestas técnicas
Una propuesta técnica (un RFC interno, un registro de decisión de arquitectura, un documento de diseño) se redacta, se discute y se acepta o se rechaza. En STXT sigue siendo un documento de texto, pero su estado, sus autores y sus relaciones con otras propuestas son datos.
Una propuesta
RFC (com.acme.rfc):
Id: RFC-013
Title: Unificación del sistema de configuración
Status: Review
Authors:
Author: Platform Team
Created: 2026-01-05
Updated: 2026-01-10
Context >>
Hoy conviven varios formatos de configuración en los servicios internos,
cada uno con sus propias reglas de validación y sus propias herramientas.
Cada equipo nuevo elige uno, y el soporte tiene que conocerlos todos.
Proposal >>
Adoptar un único formato de configuración para los servicios internos, con
una plantilla por tipo de servicio mantenida por Plataforma.
Alternatives:
Alternative: Mantener los formatos actuales
Pros >>
Sin coste inicial.
Cons >>
La fragmentación crece con cada servicio nuevo.
Alternative: Estandarizar en el formato más extendido hoy
Pros >>
Herramientas y conocimiento ya existentes en los equipos.
Cons >>
Su validación es externa.En este ejemplo tenemos:
- Cabecera:
Id,Title,Status,Authorsy las fechas. Son datos. - Cuerpo:
ContextyProposal. Son nodos block, con los nombres que la organización ya usa en sus propuestas. - Alternativas: cada una es un nodo con su título, y sus pros y contras son texto.
La plantilla
Template (@stxt.template): com.acme.rfc
Structure >>
RFC:
Id: (1)
Title: (1)
Status: (1) ENUM [Draft, Review, Accepted, Rejected, Deprecated]
Authors: (1)
Author: (+)
Created: (?) DATE
Updated: (?) DATE
Accepted date: (?) DATE
Related: (?)
Reference: (+)
Context: (1) TEXT
Proposal: (1) TEXT
Alternatives: (?)
Alternative: (*)
Pros: (?) TEXT
Cons: (?) TEXT
Decision: (?) TEXT
Consequences: (?) TEXT
Comments: (?)
Comment: (*)
Author: (1) @Author
Date: (1) DATE
Text: (1) TEXTLa plantilla exige lo mínimo de toda propuesta: identificador, título, estado,
un autor, contexto y propuesta. El resto es opcional, porque un borrador todavía no tiene
decisión ni consecuencias. El texto no se restringe: un TEXT admite cualquier contenido.
El ENUM de Status es el ciclo de vida. Una propuesta está en uno de cinco estados.
Una propuesta que no valida
# ERROR: este documento no valida
RFC (com.acme.rfc):
Id: RFC-014
Title: Migración de los servicios de facturación
# `Pendiente` no es un estado de la lista
Status: Pendiente
# Falta `Authors`
# Falta `Context`
Proposal >>
Migrar los servicios de facturación al formato único.El ciclo de vida
Semanas después, la propuesta se acepta. Este es el diff entre las dos versiones:
Title: Unificación del sistema de configuración
- Status: Review
+ Status: Accepted
Authors:
Author: Platform Team
Created: 2026-01-05
- Updated: 2026-01-10
+ Updated: 2026-01-18
+ Accepted date: 2026-01-18
...
+ Decision >>
+ Se aprueba la adopción progresiva. Plataforma publica las plantillas antes
+ del fin del trimestre.
+
+ Consequences >>
+ Los servicios nuevos usan el formato único desde su creación. Los existentes
+ migran en su siguiente versión mayor, sin fecha límite.
+
+ Comments:
+ Comment:
+ Author: Mery Adams
+ Date: 2026-01-12
+ Text >>
+ Propongo que la migración de los servicios existentes no tenga
+ fecha límite.
Cambiar de estado es cambiar una línea. Los comentarios de la revisión se guardan en el propio documento, con autor y fecha, junto a la decisión.
Relaciones entre propuestas
RFC (com.acme.rfc):
Id: RFC-020
Title: Retirada del sistema de configuración anterior
Status: Draft
Authors:
Author: Joan Costa
Related:
Reference: RFC-013
Reference: RFC-007
Context >>
Con la adopción del formato único (RFC-013), el sistema anterior queda
sin servicios nuevos y con coste de mantenimiento creciente.
Proposal >>
Retirar el sistema anterior una vez migrados los servicios que aún lo usan.RFC-013 aparece dos veces: en Related, como dato, y en Context, como texto.
Con el dato, un programa que recorra el directorio de propuestas puede responder
qué depende de qué, o qué borradores citan una propuesta rechazada.
Cómo se trabaja
- Las propuestas viven en un directorio del repositorio, una por fichero, con la plantilla en
.stxt/. stxt validate --recursive rfcs/(La línea de comandos) se ejecuta en cada cambio.- Un programa genera el índice de propuestas por estado, o avisa de las que llevan más de un mes en
Review.
Límites
La validación no comprueba relaciones entre documentos (que RFC-007 exista, o que una
propuesta aceptada no cite una rechazada). Eso lo hace el programa que recorre el directorio.
STXT tampoco sustituye a la herramienta de revisión: los comentarios del ejemplo son un registro de la discusión, sin hilos ni notificaciones.