[{"data":1,"prerenderedAt":935},["ShallowReactive",2],{"manifesto-es":3},{"id":4,"title":5,"attribution":6,"body":7,"definition":925,"description":926,"extension":927,"eyebrow":928,"meta":929,"navigation":930,"path":931,"seo":932,"stem":933,"__hash__":934},"docs\u002Fes\u002Findex.md","Context Architecture","Introduje el término Context Architecture en octubre de 2025, mientras reestructuraba el monorepo de Skyward para la legibilidad de personas y agentes de IA. Publicado por primera vez en junio de 2026.",{"type":8,"value":9,"toc":890},"minimark",[10,15,19,32,40,43,47,50,53,59,62,97,100,104,119,124,127,155,169,175,181,185,188,218,221,225,228,231,235,238,243,246,250,253,321,325,330,350,353,356,362,367,376,380,385,393,404,408,414,418,423,426,434,438,444,448,453,480,495,499,505,509,514,517,530,534,540,544,549,552,565,569,575,579,584,587,592,596,602,606,611,614,619,623,629,633,636,739,743,749,758,764,768,771,777,783,793,797,800,817,834,838,842,845,849,852,856,859,863,866,870,873,877,880,884],[11,12,14],"h2",{"id":13},"la-regla","La regla",[16,17,18],"p",{},"Context Architecture no inventa piezas nuevas. Toma lo que ya funciona en el ecosistema y lo\norganiza bajo una sola regla. Esa regla es la columna vertebral, y todo lo demás deriva de ahí.",[20,21,22,25],"rule",{},[16,23,24],{},"Toda afirmación que un repositorio hace sobre sí mismo debe estar ligada a un mecanismo que\nfalla cuando esa afirmación deja de ser verdad.",[26,27,29],"template",{"v-slot:slogan":28},"",[16,30,31],{},"Si un dato de contexto puede pudrirse en silencio, no es arquitectura: es documentación.",[16,33,34,35,39],{},"La regla es un test que puedes correr sobre cualquier repo, línea por línea. Para cada cosa que el\nrepositorio afirma sobre sí mismo (dónde está la fuente de verdad, qué patrón es el correcto, qué no\nse toca), ¿hay un compilador, un linter, un test o un paso de review que se rompe si esa afirmación\nse vuelve falsa? Si no lo hay, es texto, y el texto se pudre. Una afirmación de contexto sin\nmecanismo que la respalde ",[36,37,38],"em",{},"es"," la violación.",[16,41,42],{},"La contribución no son las piezas. Es la regla que las selecciona y las sostiene, y la consecuencia\nde esa regla: el contexto deja de ser una promesa que alguien mantiene a mano y pasa a ser una\npropiedad verificable y autosostenida del sistema.",[11,44,46],{"id":45},"el-problema","El problema",[16,48,49],{},"Durante mucho tiempo, una buena arquitectura se medía por una sola cosa: qué tan rápido un ingeniero\nnuevo entendía el codebase. Screaming Architecture le puso nombre al ideal. La estructura de un\nproyecto debería gritar qué hace, no qué framework lo construyó.",[16,51,52],{},"Ese ideal sigue intacto. El que cambió es el lector. Hoy buena parte del código que se envía a\nproducción lo leen, navegan y modifican agentes de IA. Por eso la arquitectura parte de un supuesto\nde diseño explícito:",[54,55,56],"blockquote",{},[16,57,58],{},"Asume un lector que no retiene nada entre sesiones y conoce únicamente lo que el repositorio hace\nexplícito. Los agentes de IA satisfacen este supuesto de forma exacta; un contribuyente humano\nnuevo lo aproxima.",[16,60,61],{},"De ese supuesto se siguen cinco modos de falla. Cada uno es un defecto de diseño del repositorio, no\nun límite del modelo, y por eso ninguno se corrige con un modelo mejor ni con mejores prompts:",[63,64,65,73,79,85,91],"ol",{},[66,67,68,72],"li",{},[69,70,71],"strong",{},"Reimplementación."," El lector reconstruye lo que ya existe, porque la fuente de verdad no\nestaba localizable.",[66,74,75,78],{},[69,76,77],{},"Estructura inventada."," Impone su propia organización, porque ninguna estaba impuesta.",[66,80,81,84],{},[69,82,83],{},"Obediencia a documentación falsa."," Cita archivos borrados o contradice el código actual, con\nplena confianza.",[66,86,87,90],{},[69,88,89],{},"Propagación de patrón deprecado."," Copia el patrón más visible aunque esté obsoleto.",[66,92,93,96],{},[69,94,95],{},"Resolución aleatoria de ambigüedad."," Con dos convenciones coexistiendo, usa la del archivo que\nleyó primero.",[16,98,99],{},"La arquitectura existe para que estas cinco fallas no tengan dónde ocurrir.",[11,101,103],{"id":102},"cómo-funciona","Cómo funciona",[16,105,106,107,110,111,114,115,118],{},"La arquitectura satisface la regla con dos movimientos y una frontera: el contexto se ",[69,108,109],{},"escribe","\n(los cuatro pilares) y vive con el código que describe (principio 02); se ",[69,112,113],{},"verifica"," (el mecanismo,\ncuya primera instancia es codificar las convenciones en lint y tipos, principio 05); y, en su forma\nmadura, se ",[69,116,117],{},"alimenta"," (el metabolismo).",[120,121,123],"h3",{"id":122},"los-cuatro-pilares","Los cuatro pilares",[16,125,126],{},"Por sí solos los pilares son buena documentación, y la documentación se pudre. Son solo la mitad del\ntrabajo. Dos de ellos hacen legible la forma del propio código (estructura y capacidades, que el\nlector infiere del árbol); dos declaran lo que el código no puede decir de sí mismo (contexto\nembebido e intención escrita).",[16,128,129,132,133,137,138,137,141,144,145,137,148,137,151,154],{},[69,130,131],{},"Pilar 1. La estructura grita la intención."," El nivel superior se organiza por dominio, no por\ntecnología: ",[134,135,136],"code",{},"billing\u002F",", ",[134,139,140],{},"onboarding\u002F",[134,142,143],{},"payments\u002F",", no ",[134,146,147],{},"controllers\u002F",[134,149,150],{},"services\u002F",[134,152,153],{},"utils\u002F",". Las\ncarpetas técnicas están bien un nivel más abajo, dentro del dominio al que sirven; lo que el\nframework no debe ser es el eje sobre el que se organiza el repositorio. Un lector ubica un cambio\nantes de leer una línea de código.",[16,156,157,160,161,164,165,168],{},[69,158,159],{},"Pilar 2. Contexto embebido."," Un ",[134,162,163],{},"AGENTS.md"," o ",[134,166,167],{},"CLAUDE.md"," en cada frontera significativa, con\nsolo lo que no se aprende leyendo el código: fuentes de verdad, invariantes, deuda técnica asumida y el\nporqué que deja una spec al volverse mecanismo (pilar 3). Como está pegado al código, envejece con él y lo\nencuentra el mismo agente que está a punto de editarlo. No vive en una wiki que se desactualiza en\notra parte.",[16,170,171,174],{},[69,172,173],{},"Pilar 3. La intención se vuelve mecanismo."," La spec precede al código: define el qué, no el cómo, con criterios\nde aceptación contra los que el agente se autoevalúa. Pero la spec es andamiaje de diseño, no un\nartefacto durable; una vez que su intención vive en tests, tipos y lint, cumplió su tarea y se\nelimina. Cuando la intención solo vive en la cabeza de quien estuvo en la reunión, el agente no\ntiene contra qué alinearse.",[16,176,177,180],{},[69,178,179],{},"Pilar 4. Las capacidades son descubribles."," Herramientas, skills y comandos en rutas\npredecibles, nombrados por lo que hacen. Una capacidad que existe pero no se encuentra, para un\nagente no existe: garantiza que se reimplemente o se omita. Las capacidades se invocan cuando hacen\nfalta, no siempre, porque el contexto es finito: si le das todo a un agente siempre, no le das nada.\nCuál cargar en cada momento es trabajo de context engineering, en runtime; el trabajo de este pilar\nes de diseño, hacerlas encontrables en primer lugar y ligar eso a un mecanismo (abajo).",[120,182,184],{"id":183},"el-mecanismo","El mecanismo",[16,186,187],{},"Esta es la otra mitad, y la línea entre Context Architecture y \"buenas prácticas de documentación\".\nCada afirmación de los pilares se liga a un mecanismo que la hace fallar cuando deja de ser verdad.\nCuatro capas, cada una atrapando un tipo de deriva:",[189,190,191,197,203,212],"ul",{},[66,192,193,196],{},[69,194,195],{},"El compilador"," vigila lo que puede: reintroducir un alias de import prohibido rompe el\ntypecheck.",[66,198,199,202],{},[69,200,201],{},"El linter"," vigila la estructura: un archivo en la carpeta equivocada es un error inmediato, con\nun mensaje que cita la regla, no un comentario en el review.",[66,204,205,208,209,211],{},[69,206,207],{},"Los tests"," vigilan que la documentación no mienta: si un ",[134,210,163],{}," cita un archivo borrado,\nla suite se pone roja. La misma capa vigila la descubribilidad: un índice de capacidades generado\ndesde las rutas convencionales (no mantenido a mano) no puede omitir una capacidad real, y una\nentrada obsoleta pone la suite en rojo.",[66,213,214,217],{},[69,215,216],{},"El review"," (humano o IA) vigila la verdad semántica, con una instrucción que en cada cambio\npregunta si deja alguna doc mintiendo y exige actualizarla en el mismo PR.",[16,219,220],{},"Con el mecanismo, el contexto deja de ser una promesa y pasa a ser una propiedad del sistema. Es\ntambién lo que deja a los cinco modos de falla sin lugar donde ocurrir: la estructura inventada la\natrapa el linter, la documentación falsa los tests, los patrones obsoletos y la ambigüedad las\nconvenciones codificadas, y la reimplementación las capacidades descubribles y su índice.",[120,222,224],{"id":223},"el-metabolismo","El metabolismo",[16,226,227],{},"El nivel maduro, el que separa una Context Architecture real de una bien intencionada: el contexto\nno solo se valida, se alimenta. Una arquitectura que se valida no puede pudrirse en silencio. Una\nque se alimenta incorpora conocimiento nuevo en el momento en que se crea. Cuando un PR introduce\nuna fuente de verdad o una invariante, el loop de review pide documentarla ahí mismo. El contexto\ncrece con el sistema, no por detrás de él.",[229,230],"diagram-metabolism",{},[120,232,234],{"id":233},"el-porqué-el-atributo-de-calidad","El porqué: el atributo de calidad",[16,236,237],{},"Todo esto sirve a un solo atributo de calidad, y nombrarlo es lo que vuelve la arquitectura una\narquitectura y no un conjunto de buenas ideas:",[54,239,240],{},[16,241,242],{},"El tiempo hasta el primer cambio correcto de un lector sin contexto previo.",[16,244,245],{},"Históricamente ese lector era un ingeniero nuevo. Ahora también es un agente, y es el lector más\nexigente que hay, porque no tapa la ambigüedad con intuición. Optimizar para él es el norte que\njustifica integrar las piezas. No es elegancia, es servir a un lector concreto.",[11,247,249],{"id":248},"los-principios","Los principios",[16,251,252],{},"Cada principio sigue la misma anatomía: un nombre, un enunciado de una línea, el razonamiento, la\npráctica que lo implementa y un ejemplo. La regularidad es parte del argumento. Esto es una\nmetodología, no una colección de opiniones. Cada principio es una derivación de la regla, y cada uno\nvive en un pilar o en un nivel superior:",[254,255,256,269],"table",{},[257,258,259],"thead",{},[260,261,262,266],"tr",{},[263,264,265],"th",{},"Principio",[263,267,268],{},"Dónde vive",[270,271,272,281,289,297,305,313],"tbody",{},[260,273,274,278],{},[275,276,277],"td",{},"01 · 04 · 07",[275,279,280],{},"Pilar 1: La estructura grita la intención",[260,282,283,286],{},[275,284,285],{},"02",[275,287,288],{},"Pilar 2: Contexto embebido",[260,290,291,294],{},[275,292,293],{},"03",[275,295,296],{},"Pilar 3: La intención se vuelve mecanismo",[260,298,299,302],{},[275,300,301],{},"06",[275,303,304],{},"Pilar 4: Las capacidades son descubribles",[260,306,307,310],{},[275,308,309],{},"05",[275,311,312],{},"El mecanismo (su primera instancia)",[260,314,315,318],{},[275,316,317],{},"08",[275,319,320],{},"El atributo de calidad (el porqué)",[120,322,324],{"id":323},"_01-la-estructura-grita-la-intención","01 La estructura grita la intención",[54,326,327],{},[16,328,329],{},"Un lector, persona o agente, debe poder inferir qué hace el sistema solo a partir del árbol de\narchivos, nunca del framework que se usó.",[16,331,332,333,335,336,338,339,137,342,345,346,349],{},"Un directorio llamado ",[134,334,136],{}," dice más que uno llamado ",[134,337,147],{},". El primero nombra una\nresponsabilidad del dominio. El segundo nombra un mecanismo técnico que podría pertenecer a\ncualquier sistema. Cuando el nivel superior de un repo grita ",[134,340,341],{},"payments",[134,343,344],{},"onboarding",",\n",[134,347,348],{},"notifications",", tanto una persona como un agente ubican un cambio antes de leer una línea de\ncódigo.",[16,351,352],{},"Los árboles con forma de framework hacen lo contrario. Optimizan para la conveniencia del framework,\nno para la comprensión del lector, y obligan a cada recién llegado a reconstruir el dominio desde\nevidencia dispersa.",[354,355],"diagram-tree",{},[16,357,358,361],{},[69,359,360],{},"Práctica."," Organiza el nivel superior por capacidad de dominio, no por capa técnica. Deja que el\nframework viva un nivel más abajo, dentro de la capacidad a la que sirve.",[16,363,364],{},[69,365,366],{},"Ejemplo.",[368,369,374],"pre",{"className":370,"code":372,"language":373,"meta":28},[371],"language-text","src\u002F\n  billing\u002F          # el dominio en el nivel superior\n    controllers\u002F    # el framework vive un nivel más abajo,\n    services\u002F       # dentro del dominio al que sirve\n    models\u002F\n  onboarding\u002F\n  payments\u002F\n# no: un nivel superior de controllers\u002F services\u002F models\u002F utils\u002F\n","text",[134,375,372],{"__ignoreMap":28},[120,377,379],{"id":378},"_02-el-contexto-vive-con-el-código","02 El contexto vive con el código",[54,381,382],{},[16,383,384],{},"El contexto embebido pertenece a cada frontera significativa, colocado junto a lo que describe, no\nexiliado a una wiki que se desactualiza.",[16,386,387,388,164,390,392],{},"La documentación que vive en otra parte se desactualiza en otra parte. El arreglo es la proximidad:\nun ",[134,389,163],{},[134,391,167],{}," en cada frontera, que dice qué hace esta parte, qué no debe hacer y\ncómo trabajar dentro de ella. Como está pegado al código, se revisa en el mismo pull request,\nenvejece al mismo ritmo que el código y lo encuentra el mismo agente que está a punto de editarlo.",[16,394,395,397,398,400,401,403],{},[69,396,360],{}," Pon un ",[134,399,163],{},"\u002F",[134,402,167],{}," en la raíz y en cada directorio que tenga una\nresponsabilidad distinta. Mantén cada uno corto y específico a su alcance.",[16,405,406],{},[69,407,366],{},[368,409,412],{"className":410,"code":411,"language":373,"meta":28},[371],"billing\u002F\n  AGENTS.md       # invariantes, trampas, propiedad de billing\n  invoices\u002F\n  refunds\u002F\n",[134,413,411],{"__ignoreMap":28},[120,415,417],{"id":416},"_03-la-intención-se-vuelve-mecanismo","03 La intención se vuelve mecanismo",[54,419,420],{},[16,421,422],{},"La intención se escribe como spec antes de que exista el código, y luego se vuelve mecanismo: el\ncódigo y los chequeos que la hacen valer. La spec es andamiaje, no un artefacto permanente.",[16,424,425],{},"Una spec es la fuente de verdad en tiempo de diseño: le da al código contra qué contrastarse, y al\nagente algo a lo que alinearse. Pero una vez que el código existe, una spec en prosa que solo lo\ndescribe es una segunda fuente que puede divergir, y según la regla, una afirmación sin un mecanismo\ndetrás es solo documentación. Así que la spec se vuelve mecanismo: sus criterios de aceptación se vuelven\ntests, sus contratos se vuelven tipos y schemas, sus convenciones se vuelven lint. Su intención\nverificable queda forzada por algo que falla cuando el código diverge. Lo que queda es el porqué, lo\nque el código no puede contener, y eso se mueve al contexto embebido (principio 02). Entonces la\nspec se elimina, para que no pueda pudrirse. Solo sigue viva si es generativa: alimentando un loop\niterativo que sigue produciendo código y validación, atada a un mecanismo como la regeneración o los\ncontract tests.",[16,427,428,430,431,433],{},[69,429,360],{}," Escribe una spec antes de cualquier trabajo no trivial. A medida que el código\naterriza, vuélvela mecanismo: convierte los criterios de aceptación en tests, los contratos en tipos, las\nconvenciones en lint; mueve el porqué que sobrevive al ",[134,432,163],{}," más cercano; luego borra la spec.\nMantén una en el repo solo si es generativa (codegen, configuración declarativa, un loop\nspec-driven).",[16,435,436],{},[69,437,366],{},[368,439,442],{"className":440,"code":441,"language":373,"meta":28},[371],"# tiempo de diseño\nspecs\u002Fcheckout-flow.md        # se escribe primero, se borra al volverse mecanismo\n# después de volverse mecanismo\ntests\u002Fcheckout-flow.test.ts   # criterios de aceptación, ahora ejecutables\ntypes\u002Fcheckout.ts             # contratos, ahora forzados\nbilling\u002FAGENTS.md             # el porqué que sobrevive a la spec\n",[134,443,441],{"__ignoreMap":28},[120,445,447],{"id":446},"_04-las-fronteras-son-explícitas-y-nombradas","04 Las fronteras son explícitas y nombradas",[54,449,450],{},[16,451,452],{},"Cada módulo, paquete y línea de propiedad se nombra para que su responsabilidad sea inferible. Los\nnombres ambiguos son deuda arquitectónica.",[16,454,455,456,137,458,461,462,465,466,137,469,137,472,475,476,479],{},"Una frontera que no se nombra no se hace cumplir. ",[134,457,153],{},[134,459,460],{},"common\u002F"," y ",[134,463,464],{},"helpers\u002F"," son donde la\nresponsabilidad va a morir: acumulan código no relacionado porque nada en el nombre lo resiste. Una\nfrontera nombrada (",[134,467,468],{},"pricing",[134,470,471],{},"auth",[134,473,474],{},"ingestion",") comunica una responsabilidad y presiona para\nmantener fuera lo que no corresponde. Usadas con criterio no están prohibidas: un helper chico, sin\ndependencias y sin hogar de dominio (un formateador de fechas, un tipo Result) vive legítimamente en\nun ",[134,477,478],{},"shared\u002F",". La deuda es usar el nombre para esquivar la decisión de dónde va algo, hasta que la\ncarpeta se vuelve un cajón de sastre que crece sin límite.",[16,481,482,484,485,488,489,400,491,494],{},[69,483,360],{}," Nombra cada paquete y módulo por la responsabilidad que tiene. Cuando no puedas\nnombrar una frontera con precisión, es señal de que la frontera está mal, no excusa para llamarla\n",[134,486,487],{},"shared",". Reserva ",[134,490,487],{},[134,492,493],{},"utils"," para lo genuinamente genérico, y mantenlo chico.",[16,496,497],{},[69,498,366],{},[368,500,503],{"className":501,"code":502,"language":373,"meta":28},[371],"packages\u002F\n  pricing-engine\u002F\n  auth-session\u002F\n  event-ingestion\u002F\n# no: packages\u002Fcore\u002F  packages\u002Flib\u002F\n",[134,504,502],{"__ignoreMap":28},[120,506,508],{"id":507},"_05-las-convenciones-se-codifican-no-son-implícitas","05 Las convenciones se codifican, no son implícitas",[54,510,511],{},[16,512,513],{},"Una convención que vive solo en la cabeza de las personas es invisible para un agente. Codifícala\nen el linting y los tipos para que el toolchain pueda chequearla.",[16,515,516],{},"Las personas en un equipo transmiten las convenciones por ósmosis: code review, pairing, algún\nsuspiro de vez en cuando. El agente no recibe nada de eso. Una convención que no puede leer es una\nconvención que va a romper. La salida es sacar las convenciones de la cultura y meterlas en el\ntoolchain: reglas de lint, restricciones de tipos y checks de CI que enuncian la regla y la hacen\ncumplir en el mismo lugar. Este principio es la primera instancia del mecanismo: es lo que cada otro\npilar invoca cuando necesita que sus afirmaciones se sostengan.",[16,518,519,521,522,525,526,529],{},[69,520,360],{}," Por cada «siempre lo hacemos así», pregúntate si un linter o el sistema de tipos puede\nexpresarlo. Si puede, codifícalo. El propio toolchain de este sitio usa ",[134,523,524],{},"oxlint"," con el plugin\n",[134,527,528],{},"oxlint-tailwindcss"," para lintear sus convenciones de CSS de forma que se chequeen\nautomáticamente.",[16,531,532],{},[69,533,366],{},[368,535,538],{"className":536,"code":537,"language":373,"meta":28},[371],".oxlintrc.json    # la convención, escrita y aplicada\n",[134,539,537],{"__ignoreMap":28},[120,541,543],{"id":542},"_06-las-capacidades-son-descubribles","06 Las capacidades son descubribles",[54,545,546],{},[16,547,548],{},"Las herramientas, skills y comandos se documentan donde un agente los va a buscar, no donde una\npersona los archivó por casualidad.",[16,550,551],{},"Una capacidad que existe pero no se puede encontrar es, para un agente, una capacidad que no existe.\nArchivar un script útil en una carpeta personal, o un comando de deploy en un README olvidado,\ngarantiza que se reimplemente o se omita. Ser descubrible significa poner las capacidades en la ruta\npredecible y nombrarlas por lo que hacen.",[16,553,554,556,557,560,561,564],{},[69,555,360],{}," Expón las capacidades del proyecto (scripts, generadores, skills de agente) en\nubicaciones convencionales y nombradas. Prefiere los scripts de ",[134,558,559],{},"package.json",", un directorio\n",[134,562,563],{},"skills\u002F"," o comandos documentados antes que el boca a boca.",[16,566,567],{},[69,568,366],{},[368,570,573],{"className":571,"code":572,"language":373,"meta":28},[371],"scripts\u002F\n  deploy.sh\n  seed-db.sh\npackage.json      # los \"scripts\" que un agente lee primero\n",[134,574,572],{"__ignoreMap":28},[120,576,578],{"id":577},"_07-el-repo-es-legible-en-todo-nivel-de-zoom","07 El repo es legible en todo nivel de zoom",[54,580,581],{},[16,582,583],{},"Del árbol de archivos al cuerpo de la función, cada nivel de zoom comunica propósito. La\nlegibilidad es fractal.",[16,585,586],{},"La legibilidad no es solo una propiedad del nivel superior. Un árbol claro con funciones opacas\nadentro es legible en un zoom e ilegible en otro. La misma disciplina que nombra directorios debería\nnombrar funciones, tipos y variables, para que la comprensión se degrade con gracia a medida que el\nlector baja, sin caer por un acantilado en la frontera del archivo.",[16,588,589,591],{},[69,590,360],{}," Aplica la misma claridad de nombres y estructura en cada escala. El lector debería\npoder dejar de hacer zoom en cualquier nivel y aun así saber dónde está.",[16,593,594],{},[69,595,366],{},[368,597,600],{"className":598,"code":599,"language":373,"meta":28},[371],"billing\u002Frefunds\u002Fissue-refund.ts\n  → issueRefund(order, reason)   # propósito legible en la hoja\n",[134,601,599],{"__ignoreMap":28},[120,603,605],{"id":604},"_08-optimiza-para-el-recién-llegado-y-ahora-el-recién-llegado-es-un-agente","08 Optimiza para el recién llegado, y ahora el recién llegado es un agente",[54,607,608],{},[16,609,610],{},"La prueba más clara de una arquitectura es qué tan rápido un desconocido se vuelve productivo. Ese\ndesconocido es cada vez más una máquina.",[16,612,613],{},"Todos los principios anteriores se reducen a una prueba: ¿qué tan rápido puede alguien que nunca vio\neste codebase hacer trabajo correcto en él? Durante años ese alguien era una contratación nueva.\nAhora también es un agente invocado en frío, sin memoria de la sesión de ayer. Una arquitectura que\nsirve al recién llegado en frío sirve a todos, y el agente es el recién llegado más exigente que\nhay, porque no va a tapar tu ambigüedad con intuición.",[16,615,616,618],{},[69,617,360],{}," Haz del tiempo hasta el primer cambio correcto tu única métrica, y optimiza sin tregua\npara ella.",[16,620,621],{},[69,622,366],{},[368,624,627],{"className":625,"code":626,"language":373,"meta":28},[371],"README.md         # grita la intención\nAGENTS.md         # las reglas de la casa\nspecs\u002F            # qué construir, antes de construirlo\n",[134,628,626],{"__ignoreMap":28},[11,630,632],{"id":631},"las-prácticas","Las prácticas",[16,634,635],{},"Cada principio mapea a un artefacto concreto que puedes agregar a un repo hoy.",[254,637,638,647],{},[257,639,640],{},[260,641,642,644],{},[263,643,265],{},[263,645,646],{},"Artefacto",[270,648,649,657,670,678,691,701,714,722],{},[260,650,651,654],{},[275,652,653],{},"La estructura grita la intención",[275,655,656],{},"Directorios de primer nivel por dominio",[260,658,659,662],{},[275,660,661],{},"El contexto vive con el código",[275,663,664,666,667,669],{},[134,665,163],{}," \u002F ",[134,668,167],{}," por frontera",[260,671,672,675],{},[275,673,674],{},"La intención se vuelve mecanismo",[275,676,677],{},"Se convierte en tests, tipos, lint",[260,679,680,683],{},[275,681,682],{},"Las fronteras son explícitas y nombradas",[275,684,685,686,400,688],{},"Paquetes nombrados; sin ",[134,687,493],{},[134,689,690],{},"common",[260,692,693,696],{},[275,694,695],{},"Las convenciones se codifican",[275,697,698,700],{},[134,699,524],{},", restricciones de tipos, checks de CI",[260,702,703,706],{},[275,704,705],{},"Las capacidades son descubribles",[275,707,708,137,711,713],{},[134,709,710],{},"scripts\u002F",[134,712,563],{},", comandos documentados",[260,715,716,719],{},[275,717,718],{},"Legible en todo nivel de zoom",[275,720,721],{},"Disciplina de nombres del árbol a la función",[260,723,724,727],{},[275,725,726],{},"Optimiza para el recién llegado",[275,728,729,732,733,732,735,738],{},[134,730,731],{},"README"," + ",[134,734,163],{},[134,736,737],{},"specs\u002F"," en la raíz",[11,740,742],{"id":741},"el-linaje","El linaje",[16,744,745,748],{},[69,746,747],{},"Ancestro."," Screaming Architecture (Robert C. Martin, 2011). Context Architecture la hereda y la\nextiende a la era de los agentes: la estructura ya no solo debe gritarle a un humano, sino a un\nlector sin memoria.",[16,750,751,754,755],{},[69,752,753],{},"Mecanismos que adopta."," Spec-driven development (la intención escrita antes que el código) y TDD.\nTDD es el ancestro espiritual de la regla: verifica que el código hace lo que dice. Context\nArchitecture generaliza esa idea del comportamiento a todo el contexto: ",[69,756,757],{},"los tests verifican que el\ncódigo hace lo que dice; Context Architecture verifica que el repositorio dice la verdad sobre sí\nmismo.",[16,759,760,763],{},[69,761,762],{},"Vecinos en otras capas, distintos pero a los que habilita."," Context engineering (runtime: qué\nentra a la ventana de contexto del modelo en cada momento) y harness engineering (operación: el\nentorno donde corre el agente). Context Architecture no los absorbe. Se sienta debajo, en tiempo de\ndiseño, y les baja el trabajo. Una mejor Context Architecture significa menos que comprimir en\nruntime y menos guardrails correctivos en el harness.",[11,765,767],{"id":766},"límites-y-costo","Límites y costo",[16,769,770],{},"No es bala de plata, y decirlo es parte de la solidez.",[16,772,773,776],{},[69,774,775],{},"Aplica en:"," refactors a escala, migraciones mecánicas, features con spec clara, generación de\ntests, contribuciones donde el contexto ya existe.",[16,778,779,782],{},[69,780,781],{},"No aplica en:"," problemas mal definidos, decisiones de producto, debugging sin contexto, el primer\nprototipo de algo que aún no se entiende. El límite que lo resume: el agente no reemplaza el\ncriterio, lo amplifica donde el criterio ya está claro.",[784,785,787],"callout",{"color":786},"neutral",[16,788,789,792],{},[69,790,791],{},"El costo."," Trabajo de estructuración por adelantado, capas de verificación que son\ncódigo y hay que mantener, y un impuesto de disciplina en cada PR. Es una inversión que rinde en\nproporción a cuánto trabajo de agentes o de varias personas absorbe el repositorio. En un proyecto\ndesechable, el peaje supera al retorno.",[11,794,796],{"id":795},"casos-de-estudio","Casos de estudio",[16,798,799],{},"Evidencia, con sobriedad.",[16,801,802,803,806,807,810,811,732,813,816],{},"En ",[69,804,805],{},"Skyward"," apliqué Context Architecture sobre el monorepo de la empresa; es donde más a fondo lo\nprobé. Una vez reestructurado para la legibilidad, sobre ese mismo codebase agentes de IA migraron el\ntoolchain de Biome + ",[134,808,809],{},"tsc"," a ",[134,812,524],{},[134,814,815],{},"tsgo",", llevaron el sitio público de React Router a Nuxt y\nconstruyeron features grandes a partir de specs. Cada uno de los cambios que normalmente\nse ramifican por todo el codebase, acá salió bien, porque el codebase estaba hecho para entenderse:\ncon las convenciones codificadas y los checks en su lugar, un agente sabe de inmediato cuando algo\ndeja de funcionar.",[16,818,819,821,822,824,825,833],{},[69,820,528],{}," es un plugin nativo de ",[134,823,524],{}," que construí: el principio 05 hecho código.\nUna convención de Tailwind que normalmente vive solo en la cabeza de la gente se vuelve reglas de\nlint que el toolchain chequea. Lo usamos en todo el monorepo de Skyward, y su CTO lo\n",[826,827,832],"a",{"href":828,"rel":829,"target":831},"https:\u002F\u002Fx.com\u002Ffforres\u002Fstatus\u002F2044481779306823819",[830],"nofollow","_blank","respaldó públicamente",". Lo que aporta Context\nArchitecture viene antes: escribir la convención como reglas chequeables, en vez de dejarla\nimplícita, es la razón de que un plugin así pueda existir.",[11,835,837],{"id":836},"preguntas-frecuentes","Preguntas frecuentes",[120,839,841],{"id":840},"qué-es-context-architecture","¿Qué es Context Architecture?",[16,843,844],{},"Context Architecture es una arquitectura de software para la era de los agentes de IA: la práctica de\nestructurar un codebase para que su intención y comportamiento sean igual de legibles para personas y\nagentes de IA. Trata el repositorio (su árbol de archivos, fronteras, convenciones y contexto\nembebido) como un artefacto diseñado.",[120,846,848],{"id":847},"quién-creó-context-architecture","¿Quién creó Context Architecture?",[16,850,851],{},"Sergio Azócar introdujo el término en octubre de 2025, mientras reestructuraba el monorepo de Skyward para la\nlegibilidad de personas y agentes de IA.",[120,853,855],{"id":854},"en-qué-se-diferencia-de-context-engineering","¿En qué se diferencia de context engineering?",[16,857,858],{},"Context engineering es un asunto de runtime: qué información entra a la ventana de contexto del\nmodelo en cada momento. Context Architecture es un asunto de diseño: cómo está estructurado el\ncodebase mismo. Uno diseña el contenido de la ventana; el otro diseña aquello que la ventana mira.",[120,860,862],{"id":861},"en-qué-se-diferencia-de-harness-engineering","¿En qué se diferencia de harness engineering?",[16,864,865],{},"Harness engineering diseña el entorno donde opera el agente: el bucle de ejecución, las herramientas\ny los guardrails. Context Architecture diseña el codebase sobre el que el agente opera. Una mejor\nContext Architecture le baja el trabajo al harness.",[120,867,869],{"id":868},"esto-no-es-solo-buena-documentación","¿Esto no es solo buena documentación?",[16,871,872],{},"No. La documentación es no verificada y se pudre en silencio. Context Architecture liga toda\nafirmación de contexto a un mecanismo que falla cuando la afirmación deja de ser verdad. El contexto\ncon enforcement difiere de la documentación en categoría, no en grado.",[120,874,876],{"id":875},"es-de-verdad-una-arquitectura","¿Es de verdad una arquitectura?",[16,878,879],{},"Sí. Toma decisiones estructurales caras de revertir (dónde vive el contexto, cómo se nombran las\nfronteras, qué se codifica), optimiza un atributo de calidad concreto (la legibilidad para personas\ny agentes) y es verificable con fitness functions. Eso es operar al nivel arquitectónico.",[120,881,883],{"id":882},"necesito-herramientas-especiales-para-aplicarlo","¿Necesito herramientas especiales para aplicarlo?",[16,885,886,887,889],{},"No. Context Architecture es una disciplina de estructura, no un producto. ",[134,888,163],{},", specs,\nfronteras nombradas y convenciones codificadas son prácticas que aplicas con las herramientas que ya\nusas.",{"title":28,"searchDepth":891,"depth":891,"links":892},2,[893,894,895,902,912,913,914,915,916],{"id":13,"depth":891,"text":14},{"id":45,"depth":891,"text":46},{"id":102,"depth":891,"text":103,"children":896},[897,899,900,901],{"id":122,"depth":898,"text":123},3,{"id":183,"depth":898,"text":184},{"id":223,"depth":898,"text":224},{"id":233,"depth":898,"text":234},{"id":248,"depth":891,"text":249,"children":903},[904,905,906,907,908,909,910,911],{"id":323,"depth":898,"text":324},{"id":378,"depth":898,"text":379},{"id":416,"depth":898,"text":417},{"id":446,"depth":898,"text":447},{"id":507,"depth":898,"text":508},{"id":542,"depth":898,"text":543},{"id":577,"depth":898,"text":578},{"id":604,"depth":898,"text":605},{"id":631,"depth":891,"text":632},{"id":741,"depth":891,"text":742},{"id":766,"depth":891,"text":767},{"id":795,"depth":891,"text":796},{"id":836,"depth":891,"text":837,"children":917},[918,919,920,921,922,923,924],{"id":840,"depth":898,"text":841},{"id":847,"depth":898,"text":848},{"id":854,"depth":898,"text":855},{"id":861,"depth":898,"text":862},{"id":868,"depth":898,"text":869},{"id":875,"depth":898,"text":876},{"id":882,"depth":898,"text":883},"Context Architecture es una arquitectura de software para la era de los agentes de IA: la práctica de estructurar un codebase para que su intención y comportamiento sean igual de legibles para personas y agentes de IA. Trata el repositorio mismo (su árbol de archivos, fronteras, convenciones y contexto embebido) como un artefacto diseñado, no como un accidente de su crecimiento.","Context Architecture es una arquitectura de software para la era de los agentes de IA: la práctica de estructurar un codebase para que su intención y comportamiento sean igual de legibles para personas y agentes de IA. Una especificación de Sergio Azócar.","md","Una especificación",{},true,"\u002Fes",{"title":5,"description":926},"es\u002Findex","BJybl5wH-nmYHUKALzaCd1dCQxKYIOxohyjpSRkixPs",1781789100456]