{
  "what": "The texts of the Urazuke method by stable identifier, in the languages its prose is published in. It exists because the gate catalogue tells a consumer not to print its texts and to take them from its own catalogue instead, and until this resource there was no catalogue to take them from: the instruction was right and impossible to obey, so every tool ended up writing its own translations of the titles of the method. Nothing here is translated by this file. Every string is EXTRACTED from the prose of the method, which already carries the translations; if a text is not in the prose, publication is refused instead of inventing it. Read the opaque id from the gate catalogue and look it up here under the language you are rendering for. And about the content hash, said plainly: a content hash is self-consistent, so whoever can edit a file can recompute it. It detects truncation, a bad merge and hand editing, which is exactly what its own note promises; it does not protect against an adversary who controls the host that served the file. The anchors that do not live on that host are the version ledger of each resource, which lives in the method repository and records the pair (version -> hash) append-only, and the transport security of the connection. There is no cryptographic signature: that is a written decision with its cost on the table, not an oversight.",
  "labels_version": "2026.10.1",
  "content_hash": {
    "algo": "sha256",
    "encoding": "hex_lower",
    "canonical_form": "json_sorted_keys_codepoint_no_whitespace_utf8",
    "covers": [
      "labels_version",
      "counts",
      "keyed_by",
      "scope",
      "languages",
      "labels",
      "what"
    ],
    "excludes": [
      "git_commit",
      "git_commit_note",
      "generated_at",
      "source",
      "license",
      "content_hash"
    ],
    "value": "0f3c78defe6fb19192098acd1f707814851bd832465c6901ef2a0e336835e66b",
    "note": "Recompute it over the canonicalised payload and compare. If you only read it, a frozen copy edited by hand or truncated by a merge is undetectable."
  },
  "git_commit": "82cbfeb",
  "git_commit_note": "Informative. It is the sha of the change BEFORE the one that contains this file, because it is computed before saving: it is not the identity of what is published and no comparison looks at it.",
  "generated_at": "2026-10-28T10:50:30.451Z",
  "source": "https://github.com/pkuschnirof/urazuke",
  "license": "CC BY-SA 4.0",
  "counts": {
    "languages": 8,
    "ids_per_language": 78,
    "steps": 24,
    "stations": 8,
    "rules": 46,
    "strings": 624
  },
  "keyed_by": "labels.<language>.<kind>.<id>, where <language> is one of the entries of `languages.published`, <kind> is one of steps, stations or rules, and <id> is the opaque identifier the gate catalogue declares for that node. The ids are the key, not the order: they are append-only and never renamed.",
  "scope": {
    "included": [
      {
        "kind": "steps",
        "what": "The title of each of the steps of the ladder.",
        "source": "The heading of the step card in the main document of each language."
      },
      {
        "kind": "stations",
        "what": "The title of each of the normalisation stations.",
        "source": "The heading of each station in the evolutionary-corrective path of each language."
      },
      {
        "kind": "rules",
        "what": "The statement of each rule of Annex H.",
        "source": "The row of each rule in Annex H of each language, read with the same extractor that resolves the English statement published in the gate catalogue."
      }
    ],
    "excluded": [
      {
        "kind": "the evaluator vocabulary",
        "why": "The description of what an evaluator checks is written at the data layer, in English, and is not part of the translated corpus (D-051). There is no prose source for it in the other languages, so publishing it translated would mean writing new text here, and a catalogue of texts is exactly where inventing one is easiest to do and hardest to see.",
        "measured": "Twelve evaluator names, each with one English description and no other language."
      },
      {
        "kind": "the verification questions of a step",
        "why": "The questions the data declares for a step and the ones the prose of its contract lists are not the same list, so matching them by position would mislabel them. Translating them here instead of extracting them would make this file a second copy of the method, which is the thing it exists to prevent.",
        "measured": "Counted over the twenty-four steps of the Spanish prose on 2026-10-28: zero of twenty-four carry the same number of items in the data and in the contract, and the prose is the longer one in every single step."
      }
    ]
  },
  "languages": {
    "published": [
      "es",
      "en",
      "pt",
      "fr",
      "de",
      "it",
      "ja",
      "zh"
    ],
    "note": "The languages this file publishes are the languages the PROSE of the method is published in, declared once in the gate catalogue and derived here instead of listed again. The reading interface of the method is published in more languages than its prose, and that difference is a known open item of the method, not a defect of this file: a language whose prose does not exist has no text to extract, and inventing it is what this file refuses to do. Ask for a language that is not published here and there is nothing to fall back to; render in one that is."
  },
  "labels": {
    "es": {
      "steps": {
        "u00-elegibilidad": "¿Este proyecto se puede encarar así? (la elegibilidad)",
        "u01-contrato-de-convivencia": "El contrato de convivencia (las reglas antes del código)",
        "u02-definicion-y-lectura": "La definición del proyecto y la lectura obligatoria",
        "u03-dimensionar": "Dimensionar antes de diseñar la arquitectura",
        "u04-esqueleto": "El esqueleto con sus compuertas",
        "u05-pendientes": "El plan son los pendientes",
        "u06-decisiones": "Las decisiones se escriben junto al código",
        "u07-medir": "Medir antes de construir, con un instrumento que también se verifica",
        "u08-tests-en-rojo": "Tests como candados, probados en rojo",
        "u09-calidad-de-codigo": "Calidad del código verificada por máquina, con compuerta",
        "u10-casos-de-prueba-manual": "Los casos de prueba manual se escriben junto con la funcionalidad, y los ejecutan personas",
        "u11-simetria-y-antipatrones": "Simetría entre productor y consumidor, y el registro de anti-patrones",
        "u12-verificacion-honesta": "Verificación honesta y reporte proporcional",
        "u13-auditoria": "La auditoría periódica como insumo del plan",
        "u14-fail-closed": "Fail-closed, candados y cero daño silencioso",
        "u15-ci-entornos-secretos-deploy": "Integración continua, entornos, secretos y despliegue como parte del producto",
        "u16-observabilidad-y-trazabilidad": "Observabilidad y trazabilidad totales, con nivel configurable",
        "u17-persistencia": "Optimización de la capa de persistencia, medida antes y después",
        "u18-vulnerabilidades": "Escaneo y solución de vulnerabilidades, en la cadena y con calendario",
        "u19-rendimiento-y-punto-de-ruptura": "Pruebas de rendimiento en volumen y punto de ruptura",
        "u20-documentacion-viva": "Documentación viva y manuales que una persona puede seguir sin IA",
        "u21-monitoreo-de-recursos": "Monitoreo de recursos, funciones y consultas fuera de rango, con reporte cíclico",
        "u22-monitoreo-de-errores": "Monitoreo de errores y reporte cíclico: ningún error sin pendiente",
        "u23-agente-residente-y-retrospectiva": "El agente adentro del sistema, y la retrospectiva con número"
      },
      "stations": {
        "n0-elegibilidad-legado": "Elegibilidad de un sistema existente: los prerrequisitos que un modelo puede verificar",
        "n1-contrato-legado": "El contrato de convivencia para un legado",
        "n2-lectura-del-sistema": "La lectura del sistema: el mapa recuperado y las discrepancias",
        "n3-auditoria-inventario": "La auditoría como inventario de la deuda",
        "n4-cinturon-de-seguridad": "El cinturón de seguridad",
        "n5-candados-y-mapa": "Candados y mapa productor-consumidor desde el código",
        "n6-dimensionar-real": "Dimensionar con números reales",
        "n7-backlog-de-normalizacion": "El backlog de normalización, emparejado con el pedido del cliente"
      },
      "rules": {
        "CQ-01": "Hay un solo formateador, corre sin intervención y no admite discusión.",
        "CQ-02": "Hay un solo linter por repositorio y sus reglas son las mismas para todo el mundo; se apaga una regla con motivo escrito, nunca en un archivo suelto.",
        "CQ-03": "Ningún archivo supera el límite declarado (arranca en 300 líneas) y ninguna función el suyo (arranca en 40).",
        "CQ-04": "Ninguna función supera el límite de caminos declarado.",
        "CQ-05": "No entra duplicación nueva: el bloque copiado se extrae o se justifica.",
        "CQ-06": "No hay código muerto: funciones, variables, importaciones, ramas y dependencias sin uso.",
        "CQ-07": "Si el lenguaje permite tipos, el proyecto los usa en serio; el tipo \"cualquiera\" es una excepción declarada, no un hábito.",
        "CQ-08": "La cobertura no baja: el número de hoy es el piso de mañana.",
        "CQ-09": "Con usuarios reales, el puntaje de mutación se mide por bloque y cada mutante que sobrevive en código nuevo abre un pendiente.",
        "CQ-10": "Toda dependencia está declarada, se usa y no trae un árbol de terceros desproporcionado a lo que aporta.",
        "CQ-11": "No hay credenciales, claves ni cadenas de conexión en el repositorio, ni en el historial nuevo.",
        "CQ-12": "La interfaz no decide: ninguna pantalla ni componente contiene reglas de negocio (qué se puede, cuánto sale, qué estado sigue). Vive en el dominio y la vista lo consulta.",
        "CQ-13": "Cada llamada al servidor pasa por un cliente único y tipado; ninguna pantalla arma su propia petición a mano.",
        "CQ-14": "Hay un solo lugar donde vive el estado compartido; la duplicación de estado entre pantallas es un fallo, no un atajo.",
        "CQ-15": "Todo texto visible sale de un catálogo de traducciones; ninguna cadena de usuario queda escrita dentro del componente.",
        "CQ-16": "Todo elemento interactivo lleva identificador estable y rol, para que la prueba automática lo encuentre por nombre y no por posición.",
        "CQ-17": "Todos los colores, espaciados y tipografías salen de tokens; ningún valor mágico suelto en la hoja de estilos.",
        "CQ-18": "La accesibilidad básica se verifica sola: contraste, etiquetas en los campos, foco visible, navegación por teclado en los flujos principales, imágenes con texto alternativo.",
        "UX-01": "Cada grupo del menú se nombra con un trabajo del usuario (en su vocabulario, con el glosario del proyecto), nunca con un módulo técnico ni con una entidad de datos.",
        "UX-02": "Cada funcionalidad tiene exactamente una casa canónica. Si sirve a dos grupos, se elige una casa y desde la otra se enlaza; no se duplica la entrada.",
        "UX-03": "No hay huérfanas: toda funcionalidad declarada es alcanzable desde la pantalla de entrada en no más de tres pasos.",
        "UX-04": "El tamaño de un grupo es razonable: menos de tres funcionalidades indica un grupo que no era grupo; más de siete indica un cajón.",
        "UX-05": "Todo grupo tiene una pantalla de entrada que dice qué se hace ahí y cuál es la acción principal. No hay grupos que se abren directo en una tabla vacía.",
        "UX-06": "Los flujos que la persona hace seguido viven juntos: si \"cargar un pago\" y \"ver la cuenta del cliente\" se usan en la misma sesión, comparten grupo.",
        "UX-07": "La prueba del primer clic: el dueño, frente a una tarea concreta (\"¿dónde cobrás un pago?\"), nombra un lugar. Si nombra dos, hay duplicación; si no nombra ninguno, hay huérfana. Se corre al cierre de cada bloque.",
        "UX-08": "Toda funcionalidad declara en la matriz qué perfiles la tienen. Una funcionalidad sin perfil no existe: o se le asigna perfil o se borra.",
        "UX-09": "Todo perfil declarado tiene al menos una funcionalidad y un punto de entrada propio. Un perfil vacío es un perfil que nadie usó al diseñar.",
        "UX-10": "La navegación se genera desde la matriz. Un menú escrito a mano es un fallo, no un atajo.",
        "UX-11": "Ocultar no es proteger: toda ruta verifica el permiso del lado del servidor además de esconder la entrada. Escribir la dirección a mano no alcanza para entrar.",
        "UX-12": "Ni de menos ni de más: por cada perfil, el conjunto de funcionalidades alcanzables es exactamente el de su fila en la matriz.",
        "UX-13": "La negativa se explica: si una persona entra a una funcionalidad que no le corresponde, ve un mensaje que dice por qué y a quién pedirle acceso. Nunca una pantalla en blanco, nunca un botón gris sin razón.",
        "UX-14": "El mismo botón significa lo mismo para todos: si dos perfiles comparten etiqueta, comparten efecto. Si el efecto cambia según el perfil, la etiqueta cambia o la funcionalidad se separa en dos.",
        "UX-15": "Los datos también se filtran por perfil: quien ve la lista ve las filas que le corresponden, no la lista completa con las filas escondidas en el navegador.",
        "UX-16": "La matriz y el manual de usuario se actualizan en el mismo pendiente que la funcionalidad. Una funcionalidad nueva sin fila en la matriz no se cierra.",
        "UX-17": "Toda lista tiene cuatro estados resueltos: con datos, vacía, cargando y con error. La vacía distingue \"todavía no hay\" de \"tu búsqueda no encontró\".",
        "UX-18": "Mientras algo demora, se ve que está trabajando y se puede cancelar si es largo. Un botón que no responde nada es la queja número uno.",
        "UX-19": "El error dice qué pasó, qué se puede hacer y no borra lo cargado. Ni un código técnico solo, ni un \"ocurrió un error\".",
        "UX-20": "Una pantalla tiene una acción principal evidente; el resto son secundarias y se ven como tales.",
        "UX-21": "Toda acción destructiva pide confirmación nombrando el objeto afectado, y cuando se puede se deshace en lugar de confirmar.",
        "UX-22": "Un formulario que falla conserva lo cargado y marca el campo con problema, en el lugar del campo.",
        "UX-23": "Ninguna acción deja la pantalla sin salida: después de guardar, borrar o cancelar, la persona sabe dónde quedó y cómo seguir.",
        "UX-24": "La interfaz habla el idioma del glosario del proyecto: el mismo objeto se llama igual en la pantalla, en el manual y en el correo. Un sinónimo es un defecto.",
        "UX-25": "Todo se puede hacer sin mouse y con lector de pantalla en los flujos principales; el foco se ve siempre y no queda atrapado.",
        "UX-26": "Los estados no se comunican solo por color; toda imagen informativa tiene texto alternativo; los textos se leen a tamaño normal sin zoom.",
        "UX-27": "Cada pendiente que toca una pantalla entrega la captura real del entorno de prueba, y el dueño la mira antes de cerrar. La captura no es opcional ni es un maqueta.",
        "UX-28": "Cuando el agente necesita una decisión del dueño, la pregunta llega con sus cuatro partes y en este orden: los datos que la hacen necesaria, enumerados; un párrafo de no más de cinco líneas que los enlace y deje ver el interrogante; la pregunta con sus respuestas posibles enumeradas; y la recomendación del agente. Y a la profundidad técnica que el proyecto declaró. Una pregunta suelta le deja al dueño el trabajo de reconstruir por qué se la hacen."
      }
    },
    "en": {
      "steps": {
        "u00-elegibilidad": "Can this project be run this way? (eligibility)",
        "u01-contrato-de-convivencia": "The working agreement (the rules before the code)",
        "u02-definicion-y-lectura": "The project definition and the mandatory reading",
        "u03-dimensionar": "Size before designing the architecture",
        "u04-esqueleto": "The skeleton with its gates",
        "u05-pendientes": "The plan is the pending items",
        "u06-decisiones": "Decisions are written next to the code",
        "u07-medir": "Measure before building, with an instrument that is itself verified",
        "u08-tests-en-rojo": "Tests as locks, proved red",
        "u09-calidad-de-codigo": "Code quality verified by machine, with a gate",
        "u10-casos-de-prueba-manual": "Manual test cases are written together with the functionality, and people execute them",
        "u11-simetria-y-antipatrones": "Producer/consumer symmetry, and the anti-pattern register",
        "u12-verificacion-honesta": "Honest verification and proportional reporting",
        "u13-auditoria": "The periodic audit as input to the plan",
        "u14-fail-closed": "Fail-closed, locks and zero silent harm",
        "u15-ci-entornos-secretos-deploy": "Continuous integration, environments, secrets and deployment as part of the product",
        "u16-observabilidad-y-trazabilidad": "Total observability and traceability, with a configurable level",
        "u17-persistencia": "Optimization of the persistence layer, measured before and after",
        "u18-vulnerabilidades": "Scanning and fixing vulnerabilities, in the chain and on a schedule",
        "u19-rendimiento-y-punto-de-ruptura": "Performance tests at volume and the breaking point",
        "u20-documentacion-viva": "Living documentation and manuals a person can follow without AI",
        "u21-monitoreo-de-recursos": "Monitoring of resources, functions and queries out of range, with a cyclic report",
        "u22-monitoreo-de-errores": "Error monitoring and cyclic report: no error without a pending item",
        "u23-agente-residente-y-retrospectiva": "The agent inside the system, and the retrospective with numbers"
      },
      "stations": {
        "n0-elegibilidad-legado": "Eligibility of an existing system: the prerequisites a model can verify",
        "n1-contrato-legado": "The working agreement for a legacy system",
        "n2-lectura-del-sistema": "Reading the system: the recovered map and the discrepancies",
        "n3-auditoria-inventario": "The audit as an inventory of the debt",
        "n4-cinturon-de-seguridad": "The safety belt",
        "n5-candados-y-mapa": "Locks and producer/consumer map from the code",
        "n6-dimensionar-real": "Sizing with real numbers",
        "n7-backlog-de-normalizacion": "The normalization backlog, paired with the client's request"
      },
      "rules": {
        "CQ-01": "There is a single formatter, it runs without intervention and it admits no discussion.",
        "CQ-02": "There is a single linter per repository and its rules are the same for everybody; a rule is switched off with a written reason, never in a loose file.",
        "CQ-03": "No file exceeds the declared limit (starts at 300 lines) and no function exceeds its own (starts at 40).",
        "CQ-04": "No function exceeds the declared path limit.",
        "CQ-05": "No new duplication enters: the copied block is extracted or justified.",
        "CQ-06": "There is no dead code: unused functions, variables, imports, branches and dependencies.",
        "CQ-07": "If the language allows types, the project uses them seriously; the \"any\" type is a declared exception, not a habit.",
        "CQ-08": "Coverage does not go down: today's number is tomorrow's floor.",
        "CQ-09": "With real users, the mutation score is measured per block and every mutant that survives in new code opens a pending item.",
        "CQ-10": "Every dependency is declared, is used and does not bring a third-party tree out of proportion to what it contributes.",
        "CQ-11": "There are no credentials, keys or connection strings in the repository, nor in the new history.",
        "CQ-12": "The interface does not decide: no screen or component contains business rules (what is allowed, how much it costs, which state follows). It lives in the domain and the view queries it.",
        "CQ-13": "Every server call goes through a single typed client; no screen builds its own request by hand.",
        "CQ-14": "There is a single place where shared state lives; duplicating state between screens is a failure, not a shortcut.",
        "CQ-15": "Every visible text comes out of a translation catalogue; no user string stays written inside the component.",
        "CQ-16": "Every interactive element carries a stable identifier and a role, so that the automated test finds it by name and not by position.",
        "CQ-17": "All colours, spacings and typefaces come out of tokens; no loose magic value in the stylesheet.",
        "CQ-18": "Basic accessibility is verified on its own: contrast, labels on fields, visible focus, keyboard navigation in the main flows, images with alternative text.",
        "UX-01": "Every menu group is named with a user job (in their vocabulary, with the project glossary), never with a technical module nor with a data entity.",
        "UX-02": "Every functionality has exactly one canonical home. If it serves two groups, one home is chosen and the other links to it; the entry is not duplicated.",
        "UX-03": "There are no orphans: every declared functionality is reachable from the entry screen in no more than three steps.",
        "UX-04": "The size of a group is reasonable: fewer than three functionalities indicates a group that was not a group; more than seven indicates a drawer.",
        "UX-05": "Every group has an entry screen that says what is done there and which is the main action. No group opens straight into an empty table.",
        "UX-06": "The flows the person does often live together: if \"record a payment\" and \"see the customer's account\" are used in the same session, they share a group.",
        "UX-07": "The first-click test: the owner, facing a concrete task (\"where do you charge a payment?\"), names one place. If they name two, there is duplication; if they name none, there is an orphan. It runs at the close of every block.",
        "UX-08": "Every functionality declares in the matrix which profiles have it. A functionality without a profile does not exist: either it is given a profile or it is deleted.",
        "UX-09": "Every declared profile has at least one functionality and its own entry point. An empty profile is a profile nobody used while designing.",
        "UX-10": "Navigation is generated from the matrix. A hand-written menu is a failure, not a shortcut.",
        "UX-11": "Hiding is not protecting: every route verifies the permission on the server side in addition to hiding the entry. Typing the address by hand is not enough to get in.",
        "UX-12": "Neither less nor more: for each profile, the set of reachable functionalities is exactly the one in its row of the matrix.",
        "UX-13": "The refusal is explained: if a person enters a functionality that is not theirs, they see a message that says why and who to ask for access. Never a blank screen, never a grey button without a reason.",
        "UX-14": "The same button means the same for everybody: if two profiles share a label, they share an effect. If the effect changes per profile, the label changes or the functionality is split in two.",
        "UX-15": "Data is also filtered by profile: whoever sees the list sees the rows that correspond to them, not the whole list with the rows hidden in the browser.",
        "UX-16": "The matrix and the user manual are updated in the same pending item as the functionality. A new functionality without a row in the matrix does not close.",
        "UX-17": "Every list has four resolved states: with data, empty, loading and with error. The empty one distinguishes \"there is nothing yet\" from \"your search found nothing\".",
        "UX-18": "While something takes time, it is visible that it is working and it can be cancelled if it is long. A button that answers nothing is complaint number one.",
        "UX-19": "The error says what happened, what can be done and does not erase what was entered. Neither a technical code alone, nor an \"an error occurred\".",
        "UX-20": "A screen has one evident main action; the rest are secondary and look like it.",
        "UX-21": "Every destructive action asks for confirmation naming the affected object, and when it can be done it is undone instead of confirmed.",
        "UX-22": "A form that fails keeps what was entered and marks the field with the problem, in the place of the field.",
        "UX-23": "No action leaves the screen without an exit: after saving, deleting or cancelling, the person knows where they are and how to continue.",
        "UX-24": "The interface speaks the language of the project glossary: the same object is called the same on the screen, in the manual and in the email. A synonym is a defect.",
        "UX-25": "Everything can be done without a mouse and with a screen reader in the main flows; the focus is always visible and it does not get trapped.",
        "UX-26": "States are not communicated by colour alone; every informative image has alternative text; texts are read at normal size without zoom.",
        "UX-27": "Every pending item that touches a screen delivers the real screenshot of the test environment, and the owner looks at it before closing. The screenshot is not optional and it is not a mock-up.",
        "UX-28": "When the agent needs a decision from the owner, the question arrives with its four parts and in this order: the data that makes it necessary, listed; one paragraph of no more than five lines that links that data and lets the question be seen; the question with its possible answers numbered; and the agent recommendation. And at the technical depth the project declared. A loose question leaves the owner the work of reconstructing why they are being asked."
      }
    },
    "pt": {
      "steps": {
        "u00-elegibilidad": "Este projeto pode ser encarado assim? (a elegibilidade)",
        "u01-contrato-de-convivencia": "O contrato de convivência (as regras antes do código)",
        "u02-definicion-y-lectura": "A definição do projeto e a leitura obrigatória",
        "u03-dimensionar": "Dimensionar antes de desenhar a arquitetura",
        "u04-esqueleto": "O esqueleto com suas comportas",
        "u05-pendientes": "O plano são as pendências",
        "u06-decisiones": "As decisões se escrevem junto ao código",
        "u07-medir": "Medir antes de construir, com um instrumento que também se verifica",
        "u08-tests-en-rojo": "Testes como cadeados, provados em vermelho",
        "u09-calidad-de-codigo": "Qualidade do código verificada por máquina, com comporta",
        "u10-casos-de-prueba-manual": "Os casos de teste manual se escrevem junto com a funcionalidade, e quem os executa são pessoas",
        "u11-simetria-y-antipatrones": "Simetria entre produtor e consumidor, e o registro de antipadrões",
        "u12-verificacion-honesta": "Verificação honesta e relatório proporcional",
        "u13-auditoria": "A auditoria periódica como insumo do plano",
        "u14-fail-closed": "Fail-closed, cadeados e zero dano silencioso",
        "u15-ci-entornos-secretos-deploy": "Integração contínua, ambientes, segredos e implantação como parte do produto",
        "u16-observabilidad-y-trazabilidad": "Observabilidade e rastreabilidade totais, com nível configurável",
        "u17-persistencia": "Otimização da camada de persistência, medida antes e depois",
        "u18-vulnerabilidades": "Varredura e solução de vulnerabilidades, na cadeia e com calendário",
        "u19-rendimiento-y-punto-de-ruptura": "Testes de desempenho em volume e ponto de ruptura",
        "u20-documentacion-viva": "Documentação viva e manuais que uma pessoa pode seguir sem IA",
        "u21-monitoreo-de-recursos": "Monitoramento de recursos, funções e consultas fora de faixa, com relatório cíclico",
        "u22-monitoreo-de-errores": "Monitoramento de erros e relatório cíclico: nenhum erro sem pendência",
        "u23-agente-residente-y-retrospectiva": "O agente dentro do sistema, e a retrospectiva com número"
      },
      "stations": {
        "n0-elegibilidad-legado": "Elegibilidade de um sistema existente: os pré-requisitos que um modelo pode verificar",
        "n1-contrato-legado": "O contrato de convivência para um legado",
        "n2-lectura-del-sistema": "A leitura do sistema: o mapa recuperado e as discrepâncias",
        "n3-auditoria-inventario": "A auditoria como inventário da dívida",
        "n4-cinturon-de-seguridad": "O cinto de segurança",
        "n5-candados-y-mapa": "Cadeados e mapa produtor-consumidor a partir do código",
        "n6-dimensionar-real": "Dimensionar com números reais",
        "n7-backlog-de-normalizacion": "O backlog de normalização, emparelhado com o pedido do cliente"
      },
      "rules": {
        "CQ-01": "Há um único formatador, corre sem intervenção e não admite discussão.",
        "CQ-02": "Há um único linter por repositório e suas regras são as mesmas para todos; uma regra se apaga com motivo escrito, nunca em um arquivo solto.",
        "CQ-03": "Nenhum arquivo supera o limite declarado (arranca em 300 linhas) e nenhuma função supera o seu (arranca em 40).",
        "CQ-04": "Nenhuma função supera o limite declarado de caminhos.",
        "CQ-05": "Não entra duplicação nova: o bloco copiado se extrai ou se justifica.",
        "CQ-06": "Não há código morto: funções, variáveis, importações, ramos e dependências sem uso.",
        "CQ-07": "Se a linguagem permite tipos, o projeto os usa a sério; o tipo \"any\" é exceção declarada, não habito.",
        "CQ-08": "A cobertura não baixa: o número de hoje é o piso de amanhã.",
        "CQ-09": "Com usuários reais, o escore de mutação se mede por bloco e todo mutante que sobrevive em código novo abre um pendente.",
        "CQ-10": "Toda dependência está declarada, se usa e não traz uma árvore de terceiros desproporcionada ao que aporta.",
        "CQ-11": "Não há credenciais, chaves nem cadeias de conexão no repositório, nem no histórico novo.",
        "CQ-12": "A interface não decide: nenhuma tela nem componente contém regras de negocio (o que se permite, quanto custa, que estado segue). Vive no domínio e a vista consulta.",
        "CQ-13": "Toda chamada ao servidor passa por um único cliente tipado; nenhuma tela monta a sua requisição a mão.",
        "CQ-14": "Há um único lugar onde vive o estado compartido; duplicar estado entre telas é um fracasso, não um atalho.",
        "CQ-15": "Todo texto visível sai de um catálogo de traduções; nenhuma cadeia de usuário fica escrita dentro do componente.",
        "CQ-16": "Todo elemento interativo leva identificador estável e papel, para que o teste automático o encontre pelo nome e não pela posição.",
        "CQ-17": "Todas as cores, espaçamentos e tipografias saem de tokens; nenhum valor solto na folha de estilos.",
        "CQ-18": "A acessibilidade básica se verifica sozinha: contraste, rótulos nos campos, foco visível, navegação por teclado nos fluxos principais, imagens com texto alternativo.",
        "UX-01": "Todo grupo do menu se nomeia com um trabalho do usuário (no vocabulário dele, com o glossário do projeto), nunca com um módulo técnico nem com uma entidade de dados.",
        "UX-02": "Toda funcionalidade tem exatamente uma casa canônica. Se serve dois grupos, se escolhe uma casa e o outro aponta para ela; não se duplica a entrada.",
        "UX-03": "Não há órfãs: toda funcionalidade declarada é alcançável desde a tela de entrada em no máximo três passos.",
        "UX-04": "O tamanho de um grupo é razoável: menos de três funcionalidades indica um grupo que não era grupo; mais de sete indica uma gaveta.",
        "UX-05": "Todo grupo tem uma tela de entrada que diz o que se faz ali e qual é a ação principal. Nenhum grupo abre direto em uma tabela vazia.",
        "UX-06": "Os fluxos que a pessoa faz seguido vivem juntos: se \"registrar um pagamento\" e \"ver a conta do cliente\" se usam na mesma sessão, compartilham grupo.",
        "UX-07": "O teste do primeiro clique: o dono, diante de uma tarefa concreta (\"onde se cobra um pagamento?\"), nomeia um lugar. Se nomeia dois, há duplicação; se não nomeia nenhum, há órfã. Corre no fechamento de cada bloco.",
        "UX-08": "Toda funcionalidade declara na matriz que perfis a tem. Uma funcionalidade sem perfil não existe: ou se lhe dá um perfil ou se apaga.",
        "UX-09": "Todo perfil declarado tem ao menos uma funcionalidade e um ponto de entrada próprio. Um perfil vazio é um perfil que ninguém usou ao desenhar.",
        "UX-10": "A navegação se gera desde a matriz. Um menu escrito a mão é um fracasso, não um atalho.",
        "UX-11": "Esconder não é proteger: toda rota verifica a permissão do lado do servidor além de esconder a entrada. Digitar o endereço a mão não basta para entrar.",
        "UX-12": "Nem menos nem mais: para cada perfil, o conjunto de funcionalidades alcançáveis é exatamente o da sua linha da matriz.",
        "UX-13": "A negativa se explica: se uma pessoa entra em uma funcionalidade que não é sua, vê uma mensagem que diz por que e a quem pedir acesso. Nunca uma tela em branco, nunca um botão cinza sem motivo.",
        "UX-14": "O mesmo botão significa o mesmo para todos: se dois perfis compartilham rótulo, compartilham efeito. Se o efeito muda por perfil, muda o rótulo ou a funcionalidade se divide em duas.",
        "UX-15": "Os dados também se filtram por perfil: quem vê a lista vê as linhas que lhe correspondem, não a lista inteira com as linhas escondidas no navegador.",
        "UX-16": "A matriz e o manual do usuário se atualizam no mesmo pendente que a funcionalidade. Uma funcionalidade nova sem linha na matriz não fecha.",
        "UX-17": "Toda lista tem os quatro estados resolvidos: com dados, vazia, carregando e com erro. A vazia distingue \"ainda não há nada\" de \"sua busca não achou nada\".",
        "UX-18": "Enquanto algo demora, se vê que está trabalhando e se pode cancelar se for longo. Um botão que não responde nada é a reclamação número um.",
        "UX-19": "O erro diz o que passou, o que se pode fazer e não apaga o que foi digitado. Nem um código técnico sozinho, nem um \"ocorreu um erro\".",
        "UX-20": "Uma tela tem uma ação principal evidente; o resto é secundário e se parece com isso.",
        "UX-21": "Toda ação destrutiva pede confirmação nomeando o objeto afetado, e quando se pode se desfaz em vez de confirmar.",
        "UX-22": "Um formulário que falha conserva o que foi digitado e marca o campo com o problema, no lugar do campo.",
        "UX-23": "Nenhuma ação deixa a tela sem saída: depois de salvar, apagar ou cancelar, a pessoa sabe onde está e como seguir.",
        "UX-24": "A interface fala o idioma do glossário do projeto: o mesmo objeto se chama igual na tela, no manual e no e-mail. Um sinônimo é um defeito.",
        "UX-25": "Tudo se pode fazer sem mouse e com leitor de tela nos fluxos principais; o foco está sempre visível e não se prende.",
        "UX-26": "Os estados não se comunicam só por cor; toda imagem informativa tem texto alternativo; os textos se leem em tamanho normal sem zoom.",
        "UX-27": "Todo pendente que toca uma tela entrega a captura real do ambiente de teste, e o dono a olha antes de fechar. A captura não é opcional e não é um mockup.",
        "UX-28": "Quando o agente precisa de uma decisão do dono, a pergunta chega com as suas quatro partes e nesta ordem: os dados que a tornam necessária, enumerados; um parágrafo de no máximo cinco linhas que os ligue e deixe ver a dúvida; a pergunta com as suas respostas possíveis enumeradas; e a recomendação do agente. E na profundidade técnica que o projeto declarou. Uma pergunta solta deixa para o dono o trabalho de reconstruir por que lhe perguntam."
      }
    },
    "fr": {
      "steps": {
        "u00-elegibilidad": "Ce projet peut-il être abordé ainsi ? (l'éligibilité)",
        "u01-contrato-de-convivencia": "Le contrat de collaboration (les règles avant le code)",
        "u02-definicion-y-lectura": "La définition du projet et la lecture obligatoire",
        "u03-dimensionar": "Dimensionner avant de concevoir l'architecture",
        "u04-esqueleto": "Le squelette avec ses portes",
        "u05-pendientes": "Le plan, ce sont les éléments en attente",
        "u06-decisiones": "Les décisions s'écrivent à côté du code",
        "u07-medir": "Mesurer avant de construire, avec un instrument lui-même vérifié",
        "u08-tests-en-rojo": "Les tests comme verrous, prouvés en rouge",
        "u09-calidad-de-codigo": "Qualité du code vérifiée par machine, avec une porte",
        "u10-casos-de-prueba-manual": "Les cas de test manuel s'écrivent avec la fonctionnalité, et ce sont des personnes qui les exécutent",
        "u11-simetria-y-antipatrones": "Symétrie entre producteur et consommateur, et le registre des anti-patrons",
        "u12-verificacion-honesta": "Vérification honnête et rapport proportionné",
        "u13-auditoria": "L'audit périodique comme intrant du plan",
        "u14-fail-closed": "Fail-closed, verrous et zéro dommage silencieux",
        "u15-ci-entornos-secretos-deploy": "Intégration continue, environnements, secrets et déploiement comme partie du produit",
        "u16-observabilidad-y-trazabilidad": "Observabilité et traçabilité totales, avec un niveau configurable",
        "u17-persistencia": "Optimisation de la couche de persistance, mesurée avant et après",
        "u18-vulnerabilidades": "Scan et résolution des vulnérabilités, dans la chaîne et avec un calendrier",
        "u19-rendimiento-y-punto-de-ruptura": "Tests de performance en volume et point de rupture",
        "u20-documentacion-viva": "Documentation vivante et manuels qu'une personne peut suivre sans IA",
        "u21-monitoreo-de-recursos": "Supervision des ressources, des fonctions et des requêtes hors plage, avec rapport cyclique",
        "u22-monitoreo-de-errores": "Supervision des erreurs et rapport cyclique : aucune erreur sans élément en attente",
        "u23-agente-residente-y-retrospectiva": "L'agent dans le système, et la rétrospective chiffrée"
      },
      "stations": {
        "n0-elegibilidad-legado": "Éligibilité d'un système existant : les prérequis qu'un modèle peut vérifier",
        "n1-contrato-legado": "Le contrat de collaboration pour un legacy",
        "n2-lectura-del-sistema": "La lecture du système : la carte récupérée et les divergences",
        "n3-auditoria-inventario": "L'audit comme inventaire de la dette",
        "n4-cinturon-de-seguridad": "La ceinture de sécurité",
        "n5-candados-y-mapa": "Verrous et carte producteur-consommateur depuis le code",
        "n6-dimensionar-real": "Dimensionner avec de vrais chiffres",
        "n7-backlog-de-normalizacion": "La file de normalisation, appariée à la demande du client"
      },
      "rules": {
        "CQ-01": "Il y a un seul formateur, il tourne sans intervention et il n'admet pas de discussion.",
        "CQ-02": "Il y a un seul linter par dépôt et ses règles sont les mêmes pour tous ; une règle s'éteint avec un motif écrit, jamais dans un fichier isolé.",
        "CQ-03": "Aucun fichier ne dépasse la limite déclarée (commence à 300 lignes) et aucune fonction ne dépasse la sienne (commence à 40).",
        "CQ-04": "Aucune fonction ne dépasse la limite déclarée de chemins.",
        "CQ-05": "Aucune duplication nouvelle n'entre : le bloc copié est extrait ou justifie.",
        "CQ-06": "Il n'y a pas de code mort : fonctions, variables, imports, branches et dépendances inutilisées.",
        "CQ-07": "Si le langage permet les types, le projet les utilise sérieusement ; le type \"any\" est une exception déclarée, pas une habitude.",
        "CQ-08": "La couverture ne baisse pas : le chiffre d'aujourd'hui est le plancher de demain.",
        "CQ-09": "Avec de vrais utilisateurs, le score de mutation se mesure par bloc et tout mutant qui survit dans du code nouveau ouvre un élément en attente.",
        "CQ-10": "Toute dépendance est déclarée, est utilisée et n'apporte pas un arbre tiers disproportionne à ce qu'elle apporte.",
        "CQ-11": "Il n'y a pas d'identifiants, de clés ni de chaînes de connexion dans le dépôt, ni dans l'historique nouveau.",
        "CQ-12": "L'interface ne décide pas : aucun écran ni composant ne contient de règle métier (ce qui est permis, combien cela coûte, quel état suit). Elle vit dans le domaine et la vue l'interroge.",
        "CQ-13": "Tout appel au serveur passe par un seul client type ; aucun écran ne construit sa requête à la main.",
        "CQ-14": "Il y a un seul endroit où vit l'état partagé ; dupliquer l'état entre écrans est un échec, pas un raccourci.",
        "CQ-15": "Tout texte visible sort d'un catalogue de traductions ; aucune chaîne utilisateur ne reste écrite dans le composant.",
        "CQ-16": "Tout élément interactif porte un identifiant stable et un rôle, pour que le test automatique le trouve par son nom et non par sa position.",
        "CQ-17": "Toutes les couleurs, espacements et typographies sortent de tokens ; aucune valeur en dur dans la feuille de styles.",
        "CQ-18": "L'accessibilité de base se vérifie toute seule : contraste, etiquettes sur les champs, focus visible, navigation au clavier dans les flux principaux, images avec texte alternatif.",
        "UX-01": "Chaque groupe du menu se nomme par un travail de l'utilisateur (dans son vocabulaire, avec le glossaire du projet), jamais par un module technique ni par une entité de données.",
        "UX-02": "Chaque fonctionnalité a exactement une maison canonique. Si elle sert deux groupes, on choisit une maison et l'autre pointe vers elle ; l'entrée n'est pas dupliquée.",
        "UX-03": "Il n'y a pas d'orphelines : chaque fonctionnalité déclarée est accessible depuis l'écran d'entrée en trois étapes au plus.",
        "UX-04": "La taille d'un groupe est raisonnable : moins de trois fonctionnalités indique un groupe qui n'en était pas un ; plus de sept indique un tiroir.",
        "UX-05": "Chaque groupe a un écran d'entrée qui dit ce qu'on y fait et quelle est l'action principale. Aucun groupe n'ouvre directement sur un tableau vide.",
        "UX-06": "Les flux que la personne fait souvent vivent ensemble : si \"enregistrer un paiement\" et \"voir le compte du client\" s'utilisent dans la même session, ils partagent un groupe.",
        "UX-07": "Le test du premier clic : le propriétaire, devant une tâche concrète (\"où encaisse-t-on un paiement ?\"), nomme un endroit. S'il en nomme deux, il y a duplication ; s'il n'en nomme aucun, il y a orpheline. Il tourne à la fermeture de chaque bloc.",
        "UX-08": "Chaque fonctionnalité déclare dans la matrice quels profils l'ont. Une fonctionnalité sans profil n'existe pas : ou on lui donne un profil, ou on la supprime.",
        "UX-09": "Chaque profil déclare a au moins une fonctionnalité et son propre point d'entrée. Un profil vide est un profil que personne n'a utilisé en concevant.",
        "UX-10": "La navigation est générée à partir de la matrice. Un menu écrit à la main est un échec, pas un raccourci.",
        "UX-11": "Cacher n'est pas protéger : chaque route vérifie la permission côté serveur en plus de cacher l'entrée. Taper l'adresse à la main ne suffit pas pour entrer.",
        "UX-12": "Ni moins ni plus : pour chaque profil, l'ensemble des fonctionnalités accessibles est exactement celui de sa ligne de la matrice.",
        "UX-13": "Le refus s'explique : si une personne entre dans une fonctionnalité qui n'est pas la sienne, elle voit un message qui dit pourquoi et à qui demander l'accès. Jamais un écran vide, jamais un bouton gris sans motif.",
        "UX-14": "Le même bouton veut dire la même chose pour tous : si deux profils partagent un libellé, ils partagent l'effet. Si l'effet change par profil, le libellé change ou la fonctionnalité se coupe en deux.",
        "UX-15": "Les données se filtrent aussi par profil : qui voit la liste voit les lignes qui lui correspondent, pas la liste entière avec les lignes cachées dans le navigateur.",
        "UX-16": "La matrice et le manuel utilisateur se mettent à jour dans le même élément en attente que la fonctionnalité. Une fonctionnalité nouvelle sans ligne dans la matrice ne ferme pas.",
        "UX-17": "Chaque liste a les quatre états résolus : avec données, vide, en chargement et en erreur. La vide distingue \"il n'y a encore rien\" de \"votre recherche n'a rien trouve\".",
        "UX-18": "Pendant qu'une chose prend du temps, on voit qu'elle travaille et on peut annuler si c'est long. Un bouton qui ne repond rien est la plainte numéro un.",
        "UX-19": "L'erreur dit ce qui s'est passé, ce qu'on peut faire et n'efface pas ce qui a été saisi. Ni un code technique seul, ni un \"une erreur est survenue\".",
        "UX-20": "Un écran a une action principale évidente ; le reste est secondaire et y ressemble.",
        "UX-21": "Chaque action destructive demande confirmation en nommant l'objet concerne, et quand c'est possible on défait au lieu de confirmer.",
        "UX-22": "Un formulaire qui échoue conserve ce qui a été saisi et marque le champ avec le problème, à l'endroit du champ.",
        "UX-23": "Aucune action ne laisse l'écran sans sortie : après avoir enregistré, supprime ou annule, la personne sait où elle est et comment continuer.",
        "UX-24": "L'interface parle la langue du glossaire du projet : le même objet s'appelle pareil à l'écran, dans le manuel et dans l'e-mail. Un synonyme est un défaut.",
        "UX-25": "Tout se fait sans souris et avec un lecteur d'écran dans les flux principaux ; le focus est toujours visible et ne se coince pas.",
        "UX-26": "Les états ne se communiquent pas seulement par la couleur ; chaque image informative a un texte alternatif ; les textes se lisent en taille normale sans zoom.",
        "UX-27": "Chaque élément en attente qui touche un écran livre la capture réelle de l'environnement de test, et le propriétaire la regarde avant de fermer. La capture n'est pas optionnelle et ce n'est pas une maquette.",
        "UX-28": "Quand l'agent a besoin d'une décision du propriétaire, la question arrive avec ses quatre parties et dans cet ordre : les données qui la rendent nécessaire, énumérées ; un paragraphe de cinq lignes au plus qui les relie et laisse voir la question ; la question avec ses réponses possibles numérotées ; et la recommandation de l'agent. Et à la profondeur technique que le projet a déclarée. Une question en vrac laisse au propriétaire le travail de reconstruire pourquoi on la lui pose."
      }
    },
    "de": {
      "steps": {
        "u00-elegibilidad": "Lässt sich dieses Projekt so angehen? (die Eignung)",
        "u01-contrato-de-convivencia": "Die Arbeitsvereinbarung (die Regeln vor dem Code)",
        "u02-definicion-y-lectura": "Die Projektdefinition und die Pflichtlektüre",
        "u03-dimensionar": "Dimensionieren, bevor die Architektur entworfen wird",
        "u04-esqueleto": "Das Skelett mit seinen Toren",
        "u05-pendientes": "Der Plan sind die offenen Posten",
        "u06-decisiones": "Entscheidungen werden neben dem Code festgehalten",
        "u07-medir": "Messen vor dem Bauen, mit einem Instrument, das ebenfalls geprüft wird",
        "u08-tests-en-rojo": "Tests als Sperren, rot bewiesen",
        "u09-calidad-de-codigo": "Maschinell verifizierte Code-Qualität, mit Tor",
        "u10-casos-de-prueba-manual": "Die manuellen Testfälle werden zusammen mit der Funktionalität geschrieben, und Menschen führen sie aus",
        "u11-simetria-y-antipatrones": "Symmetrie zwischen Produzent und Konsument, und das Register der Anti-Muster",
        "u12-verificacion-honesta": "Ehrliche Verifikation und verhältnismäßiger Bericht",
        "u13-auditoria": "Das periodische Audit als Input für den Plan",
        "u14-fail-closed": "Fail-closed, Sperren und null stiller Schaden",
        "u15-ci-entornos-secretos-deploy": "Continuous Integration, Umgebungen, Geheimnisse und Deployment als Teil des Produkts",
        "u16-observabilidad-y-trazabilidad": "Vollständige Beobachtbarkeit und Nachverfolgbarkeit, mit konfigurierbarem Level",
        "u17-persistencia": "Optimierung der Persistenzschicht, vorher und nachher gemessen",
        "u18-vulnerabilidades": "Scannen und Beheben von Schwachstellen, in der Kette und mit Zeitplan",
        "u19-rendimiento-y-punto-de-ruptura": "Lasttests im Volumen und Bruchpunkt",
        "u20-documentacion-viva": "Lebendige Dokumentation und Handbücher, denen eine Person ohne KI folgen kann",
        "u21-monitoreo-de-recursos": "Monitoring von Ressourcen, Funktionen und Abfragen außerhalb des Bereichs, mit zyklischem Bericht",
        "u22-monitoreo-de-errores": "Fehler-Monitoring und zyklischer Bericht: kein Fehler ohne offenen Posten",
        "u23-agente-residente-y-retrospectiva": "Der Agent im System, und die Retrospektive mit Zahlen"
      },
      "stations": {
        "n0-elegibilidad-legado": "Eignung eines bestehenden Systems: die Voraussetzungen, die ein Modell verifizieren kann",
        "n1-contrato-legado": "Die Arbeitsvereinbarung für ein Altsystem",
        "n2-lectura-del-sistema": "Das Lesen des Systems: die wiedergewonnene Karte und die Diskrepanzen",
        "n3-auditoria-inventario": "Das Audit als Inventar der Schuld",
        "n4-cinturon-de-seguridad": "Der Sicherheitsgurt",
        "n5-candados-y-mapa": "Sperren und Produzenten-Konsumenten-Karte aus dem Code",
        "n6-dimensionar-real": "Dimensionieren mit echten Zahlen",
        "n7-backlog-de-normalizacion": "Das Normalisierungs-Backlog, gepaart mit der Anfrage des Kunden"
      },
      "rules": {
        "CQ-01": "Es gibt einen einzigen Formatierer, er läuft ohne Eingriff und lässt keine Diskussion zu.",
        "CQ-02": "Es gibt einen einzigen Linter pro Repository und seine Regeln sind für alle dieselben; eine Regel wird mit schriftlicher Begründung abgeschaltet, niemals in einer verstreuten Datei.",
        "CQ-03": "Keine Datei überschreitet die erklärte Grenze (Start bei 300 Zeilen) und keine Funktion die ihre (Start bei 40).",
        "CQ-04": "Keine Funktion überschreitet die erklärte Grenze der Pfade.",
        "CQ-05": "Keine neue Duplizierung kommt hinein: der kopierte Block wird extrahiert oder begründet.",
        "CQ-06": "Es gibt keinen toten Code: Funktionen, Variablen, Importe, Zweige und ungenutzte Abhängigkeiten.",
        "CQ-07": "Erlaubt die Sprache Typen, nutzt das Projekt sie ernsthaft; der Typ „irgendein\" ist eine erklärte Ausnahme, keine Gewohnheit.",
        "CQ-08": "Die Abdeckung sinkt nicht: die Zahl von heute ist der Boden von morgen.",
        "CQ-09": "Mit echten Nutzern wird der Mutationswert pro Block gemessen, und jeder überlebende Mutant in neuem Code öffnet einen offenen Punkt.",
        "CQ-10": "Jede Abhängigkeit ist deklariert, wird genutzt und bringt keinen Fremdbaum mit, der unverhältnismäßig zu ihrem Beitrag ist.",
        "CQ-11": "Es gibt keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Repository, auch nicht in der neuen Historie.",
        "CQ-12": "Die Oberfläche entscheidet nicht: keine Bildschirmseite und keine Komponente enthält Geschäftsregeln (was erlaubt ist, wie viel es kostet, welcher Zustand folgt). Sie leben in der Domäne und die Ansicht fragt sie ab.",
        "CQ-13": "Jeder Aufruf an den Server geht über einen einzigen typisierten Client; keine Bildschirmseite baut ihre Anfrage von Hand.",
        "CQ-14": "Es gibt einen einzigen Ort für den geteilten Zustand; die Verdopplung von Zustand zwischen Bildschirmseiten ist ein Fehler, keine Abkürzung.",
        "CQ-15": "Jeder sichtbare Text kommt aus einem Übersetzungskatalog; keine Nutzerzeichenkette steht im Bauteil geschrieben.",
        "CQ-16": "Jedes interaktive Element trägt eine stabile Kennung und eine Rolle, damit der automatische Test es über den Namen findet und nicht über die Position.",
        "CQ-17": "Alle Farben, Abstände und Schriften kommen aus Tokens; kein magischer Wert steht frei im Stylesheet.",
        "CQ-18": "Die grundlegende Barrierefreiheit wird selbst geprüft: Kontrast, Feldbeschriftungen, sichtbarer Fokus, Tastaturnavigation in den Hauptabläufen, Bilder mit Alternativtext.",
        "UX-01": "Jede Menügruppe wird mit einer Arbeit des Nutzers benannt (in seinem Wortschatz, mit dem Glossar des Projekts), niemals mit einem technischen Modul oder einer Datenentität.",
        "UX-02": "Jede Funktionalität hat genau ein kanonisches Zuhause. Dient sie zwei Gruppen, wird ein Zuhause gewählt und aus der anderen verlinkt; der Eintrag wird nicht dupliziert.",
        "UX-03": "Es gibt keine Waisen: jede erklärte Funktionalität ist vom Einstiegsbildschirm aus in nicht mehr als drei Schritten erreichbar.",
        "UX-04": "Die Größe einer Gruppe ist vernünftig: weniger als drei Funktionalitäten zeigt eine Gruppe, die keine war; mehr als sieben zeigt eine Schublade.",
        "UX-05": "Jede Gruppe hat einen Einstiegsbildschirm, der sagt, was dort getan wird, und was die Hauptaktion ist. Es gibt keine Gruppen, die direkt in eine leere Tabelle öffnen.",
        "UX-06": "Abläufe, die die Person häufig macht, leben zusammen: wenn „eine Zahlung erfassen\" und „das Konto des Kunden sehen\" in derselben Sitzung genutzt werden, teilen sie die Gruppe.",
        "UX-07": "Der Test des ersten Klicks: der Eigentümer nennt vor einer konkreten Aufgabe („wo kassierst du eine Zahlung?\") einen Ort. Nennt er zwei, gibt es Duplizierung; nennt er keinen, gibt es eine Waise. Er läuft beim Abschluss jedes Blocks.",
        "UX-08": "Jede Funktionalität erklärt in der Matrix, welche Profile sie haben. Eine Funktionalität ohne Profil existiert nicht: entweder wird ihr ein Profil zugewiesen oder sie wird gelöscht.",
        "UX-09": "Jedes erklärte Profil hat mindestens eine Funktionalität und einen eigenen Einstiegspunkt. Ein leeres Profil ist ein Profil, das beim Entwerfen niemand genutzt hat.",
        "UX-10": "Die Navigation wird aus der Matrix erzeugt. Ein von Hand geschriebenes Menü ist ein Fehler, keine Abkürzung.",
        "UX-11": "Verbergen ist nicht Schützen: jede Route prüft die Berechtigung auf der Serverseite, zusätzlich zum Verbergen des Eintrags. Die Adresse von Hand zu schreiben reicht nicht, um hineinzukommen.",
        "UX-12": "Weder weniger noch mehr: pro Profil ist die Menge der erreichbaren Funktionalitäten genau die seiner Zeile in der Matrix.",
        "UX-13": "Die Ablehnung wird erklärt: tritt eine Person in eine Funktionalität ein, die ihr nicht zusteht, sieht sie eine Meldung, die sagt, warum, und an wen sie sich für den Zugang wenden soll. Niemals ein leerer Bildschirm, niemals eine graue Schaltfläche ohne Grund.",
        "UX-14": "Dieselbe Schaltfläche bedeutet für alle dasselbe: teilen zwei Profile die Beschriftung, teilen sie die Wirkung. Ändert sich die Wirkung je nach Profil, ändert sich die Beschriftung oder die Funktionalität wird in zwei geteilt.",
        "UX-15": "Auch die Daten werden pro Profil gefiltert: wer die Liste sieht, sieht die Zeilen, die ihm zustehen, nicht die vollständige Liste mit den im Browser versteckten Zeilen.",
        "UX-16": "Die Matrix und das Benutzerhandbuch werden im selben offenen Punkt wie die Funktionalität aktualisiert. Eine neue Funktionalität ohne Zeile in der Matrix wird nicht geschlossen.",
        "UX-17": "Jede Liste hat vier gelöste Zustände: mit Daten, leer, ladend und mit Fehler. Die leere unterscheidet „es gibt noch nichts\" von „deine Suche hat nichts gefunden\".",
        "UX-18": "Während etwas dauert, sieht man, dass es arbeitet, und man kann abbrechen, wenn es lange dauert. Eine Schaltfläche, die nichts antwortet, ist die Beschwerde Nummer eins.",
        "UX-19": "Der Fehler sagt, was passiert ist, was man tun kann, und löscht nicht das Eingetragene. Weder ein technischer Code allein noch ein „es ist ein Fehler aufgetreten\".",
        "UX-20": "Eine Bildschirmseite hat eine offensichtliche Hauptaktion; der Rest ist sekundär und sieht so aus.",
        "UX-21": "Jede destruktive Aktion verlangt eine Bestätigung, die das betroffene Objekt nennt, und wo es möglich ist, wird sie rückgängig gemacht statt bestätigt.",
        "UX-22": "Ein fehlschlagendes Formular behält das Eingetragene und markiert das problematische Feld an der Stelle des Feldes.",
        "UX-23": "Keine Aktion lässt die Bildschirmseite ohne Ausweg: nach dem Speichern, Löschen oder Abbrechen weiß die Person, wo sie geblieben ist und wie es weitergeht.",
        "UX-24": "Die Oberfläche spricht die Sprache des Glossars des Projekts: dasselbe Objekt heißt gleich auf der Bildschirmseite, im Handbuch und in der E-Mail. Ein Synonym ist ein Defekt.",
        "UX-25": "Alles ist ohne Maus und mit Screenreader in den Hauptabläufen machbar; der Fokus ist immer sichtbar und bleibt nicht gefangen.",
        "UX-26": "Zustände werden nicht nur durch Farbe mitgeteilt; jedes informative Bild hat Alternativtext; die Texte sind bei normaler Größe ohne Zoom lesbar.",
        "UX-27": "Jeder offene Punkt, der eine Bildschirmseite berührt, liefert den echten Screenshot der Testumgebung, und der Eigentümer sieht ihn an, bevor geschlossen wird. Der Screenshot ist weder optional noch ein Mockup.",
        "UX-28": "Wenn der Agent eine Entscheidung des Eigentümers braucht, kommt die Frage mit ihren vier Teilen und in dieser Reihenfolge: die Daten, die sie nötig machen, aufgelistet; ein Absatz von höchstens fünf Zeilen, der sie verbindet und die Frage sichtbar macht; die Frage mit ihren möglichen Antworten durchnummeriert; und die Empfehlung des Agenten. Und in der technischen Tiefe, die das Projekt erklärt hat. Eine lose Frage überlässt dem Eigentümer die Arbeit, zu rekonstruieren, warum sie ihm gestellt wird."
      }
    },
    "it": {
      "steps": {
        "u00-elegibilidad": "Questo progetto si può affrontare così? (l'idoneità)",
        "u01-contrato-de-convivencia": "Il patto di convivenza (le regole prima del codice)",
        "u02-definicion-y-lectura": "La definizione del progetto e la lettura obbligatoria",
        "u03-dimensionar": "Dimensionare prima di progettare l'architettura",
        "u04-esqueleto": "Lo scheletro con i suoi cancelli",
        "u05-pendientes": "Il piano sono le voci in sospeso",
        "u06-decisiones": "Le decisioni si scrivono accanto al codice",
        "u07-medir": "Misurare prima di costruire, con uno strumento che a sua volta si verifica",
        "u08-tests-en-rojo": "I test come lucchetti, provati in rosso",
        "u09-calidad-de-codigo": "Qualità del codice verificata dalla macchina, con cancello",
        "u10-casos-de-prueba-manual": "I casi di prova manuale si scrivono insieme alla funzionalità, e li eseguono le persone",
        "u11-simetria-y-antipatrones": "Simmetria tra produttore e consumatore, e il registro degli anti-pattern",
        "u12-verificacion-honesta": "Verifica onesta e rapporto proporzionato",
        "u13-auditoria": "L'audit periodico come input del piano",
        "u14-fail-closed": "Fail-closed, lucchetti e zero danno silenzioso",
        "u15-ci-entornos-secretos-deploy": "Integrazione continua, ambienti, segreti e deployment come parte del prodotto",
        "u16-observabilidad-y-trazabilidad": "Osservabilità e tracciabilità totali, con livello configurabile",
        "u17-persistencia": "Ottimizzazione dello strato di persistenza, misurata prima e dopo",
        "u18-vulnerabilidades": "Scansione e soluzione delle vulnerabilità, nella catena e con un calendario",
        "u19-rendimiento-y-punto-de-ruptura": "Prove di rendimento in volume e punto di rottura",
        "u20-documentacion-viva": "Documentazione viva e manuali che una persona può seguire senza IA",
        "u21-monitoreo-de-recursos": "Monitoraggio di risorse, funzioni e query fuori range, con rapporto ciclico",
        "u22-monitoreo-de-errores": "Monitoraggio degli errori e rapporto ciclico: nessun errore senza voce in sospeso",
        "u23-agente-residente-y-retrospectiva": "L'agente dentro il sistema, e la retrospettiva con i numeri"
      },
      "stations": {
        "n0-elegibilidad-legado": "Idoneità di un sistema esistente: i prerequisiti che un modello può verificare",
        "n1-contrato-legado": "Il patto di convivenza per un legacy",
        "n2-lectura-del-sistema": "La lettura del sistema: la mappa recuperata e le discrepanze",
        "n3-auditoria-inventario": "L'audit come inventario del debito",
        "n4-cinturon-de-seguridad": "La cintura di sicurezza",
        "n5-candados-y-mapa": "Lucchetti e mappa produttore-consumatore dal codice",
        "n6-dimensionar-real": "Dimensionare con numeri reali",
        "n7-backlog-de-normalizacion": "Il backlog di normalizzazione, abbinato alla richiesta del cliente"
      },
      "rules": {
        "CQ-01": "C'è un solo formattatore, corre senza intervento e non ammette discussione.",
        "CQ-02": "C'è un solo linter per repository e le sue regole sono le stesse per tutti; una regola si spegne con motivo scritto, mai in un file sparso.",
        "CQ-03": "Nessun file supera il limite dichiarato (parte da 300 righe) e nessuna funzione il suo (parte da 40).",
        "CQ-04": "Nessuna funzione supera il limite di percorsi dichiarato.",
        "CQ-05": "Non entra duplicazione nuova: il blocco copiato si estrae o si giustifica.",
        "CQ-06": "Non c'è codice morto: funzioni, variabili, importazioni, rami e dipendenze senza uso.",
        "CQ-07": "Se il linguaggio permette i tipi, il progetto li usa sul serio; il tipo \"qualunque\" è un'eccezione dichiarata, non un'abitudine.",
        "CQ-08": "La copertura non scende: il numero di oggi è il pavimento di domani.",
        "CQ-09": "Con utenti reali, il punteggio di mutazione si misura per blocco e ogni mutante che sopravvive in codice nuovo apre una pendenza.",
        "CQ-10": "Ogni dipendenza è dichiarata, si usa e non porta un albero di terzi sproporzionato a ciò che apporta.",
        "CQ-11": "Non ci sono credenziali, chiavi né stringhe di connessione nel repository, nemmeno nella storia nuova.",
        "CQ-12": "L'interfaccia non decide: nessuna schermata né componente contiene regole di business (cosa si può, quanto costa, quale stato segue). Vivono nel dominio e la vista le interroga.",
        "CQ-13": "Ogni chiamata al server passa da un client unico e tipizzato; nessuna schermata costruisce la propria richiesta a mano.",
        "CQ-14": "C'è un solo posto dove vive lo stato condiviso; la duplicazione di stato fra schermate è un guasto, non una scorciatoia.",
        "CQ-15": "Ogni testo visibile esce da un catalogo di traduzioni; nessuna stringa utente resta scritta dentro il componente.",
        "CQ-16": "Ogni elemento interattivo porta identificatore stabile e ruolo, perché la prova automatica lo trovi per nome e non per posizione.",
        "CQ-17": "Tutti i colori, le spaziature e i caratteri escono da token; nessun valore magico sparso nel foglio di stile.",
        "CQ-18": "L'accessibilità di base si verifica da sola: contrasto, etichette nei campi, fuoco visibile, navigazione da tastiera nei flussi principali, immagini con testo alternativo.",
        "UX-01": "Ogni gruppo del menu si nomina con un lavoro dell'utente (nel suo vocabolario, con il glossario del progetto), mai con un modulo tecnico né con un'entità di dati.",
        "UX-02": "Ogni funzionalità ha esattamente una casa canonica. Se serve a due gruppi, si sceglie una casa e dall'altra si collega; la voce non si duplica.",
        "UX-03": "Non ci sono orfane: ogni funzionalità dichiarata è raggiungibile dalla schermata d'ingresso in non più di tre passi.",
        "UX-04": "La dimensione di un gruppo è ragionevole: meno di tre funzionalità indica un gruppo che non era un gruppo; più di sette indica un cassetto.",
        "UX-05": "Ogni gruppo ha una schermata d'ingresso che dice cosa si fa lì e qual è l'azione principale. Non ci sono gruppi che si aprono direttamente su una tabella vuota.",
        "UX-06": "I flussi che la persona fa spesso vivono insieme: se \"caricare un pagamento\" e \"vedere il conto del cliente\" si usano nella stessa sessione, condividono il gruppo.",
        "UX-07": "La prova del primo clic: il proprietario, davanti a un'attività concreta (\"dove incassi un pagamento?\"), nomina un posto. Se ne nomina due, c'è duplicazione; se non ne nomina nessuno, c'è un'orfana. Si corre alla chiusura di ogni blocco.",
        "UX-08": "Ogni funzionalità dichiara nella matrice quali profili la hanno. Una funzionalità senza profilo non esiste: o le si assegna un profilo o si cancella.",
        "UX-09": "Ogni profilo dichiarato ha almeno una funzionalità e un punto d'ingresso proprio. Un profilo vuoto è un profilo che nessuno ha usato progettando.",
        "UX-10": "La navigazione si genera dalla matrice. Un menu scritto a mano è un guasto, non una scorciatoia.",
        "UX-11": "Nascondere non è proteggere: ogni rotta verifica il permesso lato server oltre a nascondere la voce. Scrivere l'indirizzo a mano non basta per entrare.",
        "UX-12": "Né meno né più: per ogni profilo, l'insieme delle funzionalità raggiungibili è esattamente quello della sua riga nella matrice.",
        "UX-13": "Il rifiuto si spiega: se una persona entra in una funzionalità che non le spetta, vede un messaggio che dice perché e a chi chiedere l'accesso. Mai una schermata bianca, mai un pulsante grigio senza ragione.",
        "UX-14": "Lo stesso pulsante significa la stessa cosa per tutti: se due profili condividono l'etichetta, condividono l'effetto. Se l'effetto cambia secondo il profilo, l'etichetta cambia o la funzionalità si separa in due.",
        "UX-15": "Anche i dati si filtrano per profilo: chi vede l'elenco vede le righe che gli spettano, non l'elenco completo con le righe nascoste nel browser.",
        "UX-16": "La matrice e il manuale utente si aggiornano nella stessa pendenza della funzionalità. Una funzionalità nuova senza riga nella matrice non si chiude.",
        "UX-17": "Ogni elenco ha quattro stati risolti: con dati, vuoto, in caricamento e con errore. Il vuoto distingue \"non c'è ancora\" da \"la tua ricerca non ha trovato\".",
        "UX-18": "Mentre qualcosa tarda, si vede che sta lavorando e si può annullare se è lungo. Un pulsante che non risponde niente è la lamentela numero uno.",
        "UX-19": "L'errore dice cosa è successo, cosa si può fare e non cancella quello che è stato caricato. Né un codice tecnico da solo, né un \"si è verificato un errore\".",
        "UX-20": "Una schermata ha un'azione principale evidente; le altre sono secondarie e si vedono come tali.",
        "UX-21": "Ogni azione distruttiva chiede conferma nominando l'oggetto colpito, e quando si può si annulla invece di confermare.",
        "UX-22": "Un modulo che fallisce conserva quello che è stato caricato e segna il campo con problema, nel posto del campo.",
        "UX-23": "Nessuna azione lascia la schermata senza uscita: dopo aver salvato, cancellato o annullato, la persona sa dove è rimasta e come proseguire.",
        "UX-24": "L'interfaccia parla la lingua del glossario del progetto: lo stesso oggetto si chiama uguale nella schermata, nel manuale e nell'email. Un sinonimo è un difetto.",
        "UX-25": "Tutto si può fare senza mouse e con lettore di schermo nei flussi principali; il fuoco si vede sempre e non resta intrappolato.",
        "UX-26": "Gli stati non si comunicano solo con il colore; ogni immagine informativa ha testo alternativo; i testi si leggono a dimensione normale senza zoom.",
        "UX-27": "Ogni pendenza che tocca una schermata consegna la cattura reale dell'ambiente di prova, e il proprietario la guarda prima di chiudere. La cattura non è opzionale né è una bozza.",
        "UX-28": "Quando l'agente ha bisogno di una decisione del proprietario, la domanda arriva con le sue quattro parti e in questo ordine: i dati che la rendono necessaria, elencati; un paragrafo di non più di cinque righe che li colleghi e lasci vedere l'interrogativo; la domanda con le sue possibili risposte numerate; e la raccomandazione dell'agente. E alla profondità tecnica che il progetto ha dichiarato. Una domanda sciolta lascia al proprietario il lavoro di ricostruire perché gliela fanno."
      }
    },
    "ja": {
      "steps": {
        "u00-elegibilidad": "このプロジェクトはこの方法で取り組めるか？（適格性）",
        "u01-contrato-de-convivencia": "共働の約束（コードの前のルール）",
        "u02-definicion-y-lectura": "プロジェクトの定義と必読",
        "u03-dimensionar": "アーキテクチャを設計する前にサイジングする",
        "u04-esqueleto": "ゲート付きの骨組み",
        "u05-pendientes": "計画とは保留項目のこと",
        "u06-decisiones": "決定はコードの隣に書く",
        "u07-medir": "構築の前に計測する、自身も検証される計器で",
        "u08-tests-en-rojo": "錠としてのテスト、赤で証明",
        "u09-calidad-de-codigo": "機械で検証されるコードの品質、ゲート付きで",
        "u10-casos-de-prueba-manual": "手動テストケースは機能とともに書かれ、それを実行するのは人である",
        "u11-simetria-y-antipatrones": "生産者と消費者の対称性、そしてアンチパターンの記録",
        "u12-verificacion-honesta": "誠実な検証と釣り合った報告",
        "u13-auditoria": "計画への入力としての定期監査",
        "u14-fail-closed": "フェイルクローズド、錠、静かな損害ゼロ",
        "u15-ci-entornos-secretos-deploy": "プロダクトの一部としての継続的インテグレーション、環境、秘密、デプロイ",
        "u16-observabilidad-y-trazabilidad": "設定可能なレベルを持つ、完全な可観測性とトレーサビリティ",
        "u17-persistencia": "永続化層の最適化、前と後を計測して",
        "u18-vulnerabilidades": "脆弱性の走査と解決、連鎖の中で、そして暦とともに",
        "u19-rendimiento-y-punto-de-ruptura": "量に対する性能テストと破断点",
        "u20-documentacion-viva": "生きた文書と、人がAIなしで追えるマニュアル",
        "u21-monitoreo-de-recursos": "資源、関数、クエリの範囲外の監視、周期報告とともに",
        "u22-monitoreo-de-errores": "エラーの監視と周期報告：保留項目のないエラーは一つもない",
        "u23-agente-residente-y-retrospectiva": "システムの中のエージェント、そして数字による振り返り"
      },
      "stations": {
        "n0-elegibilidad-legado": "既存システムの適格性：モデルが検証できる前提条件",
        "n1-contrato-legado": "レガシーのための共働の約束",
        "n2-lectura-del-sistema": "システムの読み取り：復元された地図と食い違い",
        "n3-auditoria-inventario": "負債の棚卸しとしての監査",
        "n4-cinturon-de-seguridad": "安全ベルト",
        "n5-candados-y-mapa": "コードからの錠と生産者・消費者の地図",
        "n6-dimensionar-real": "実数でサイジングする",
        "n7-backlog-de-normalizacion": "顧客の依頼と対にした正常化のバックログ"
      },
      "rules": {
        "CQ-01": "フォーマッタは一つしかなく、介入なしに走り、議論を許さない。",
        "CQ-02": "リポジトリごとにリンタは一つしかなく、その規則は全員にとって同じである。規則は書かれた理由とともに切るのであり、野放しのファイルの中で切るのではない。",
        "CQ-03": "宣言された上限を超えるファイルはなく（三百行から始まる）、自分の上限を超える関数もない（四十行から始まる）。",
        "CQ-04": "宣言された経路の上限を超える関数はない。",
        "CQ-05": "新しい重複は入らない。コピーされたブロックは抽出されるか、正当化される。",
        "CQ-06": "デッドコードはない。使われていない関数、変数、インポート、分岐、依存関係である。",
        "CQ-07": "言語が型を許すなら、プロジェクトは型を本気で使う。「どれでも」の型は宣言された例外であり、習慣ではない。",
        "CQ-08": "カバレッジは下がらない。今日の数値が明日の床である。",
        "CQ-09": "実際のユーザーがいるところでは、ミューテーションのスコアをブロックごとに測り、新しいコードの中で生き残ったミューテートはそれぞれペンディングを開く。",
        "CQ-10": "すべての依存関係は宣言され、使われ、そしてそれが提供するものに対して不釣り合いな第三者ツリーを持ち込まない。",
        "CQ-11": "認証情報、鍵、接続文字列がリポジトリに、また新しい履歴にもない。",
        "CQ-12": "インターフェースは決定しない。どの画面もコンポーネントも業務規則（何ができるか、いくらになるか、どの状態が続くか）を含まない。ドメインに住み、ビューがそれを問い合わせる。",
        "CQ-13": "サーバへの呼び出しはすべて単一の型付きクライアントを通る。画面が自分で手作業のリクエストを組むことはない。",
        "CQ-14": "共有状態が住む場所は一つだけである。画面間の状態の重複は近道ではなく故障である。",
        "CQ-15": "見えるテキストはすべて翻訳カタログから出る。ユーザー向けの文字列がコンポーネントの中に書かれたままになることはない。",
        "CQ-16": "すべてのインタラクティブな要素は安定した識別子とロールを持ち、自動テストが位置ではなく名前でそれを見つけられるようにする。",
        "CQ-17": "色、間隔、タイポグラフィはすべてトークンから出る。スタイルシートに野放しのマジック値はない。",
        "CQ-18": "基本的なアクセシビリティは自動で検証される。コントラスト、欄のラベル、可視のフォーカス、主要なフローでのキーボードナビゲーション、代替テキストを持つ画像である。",
        "UX-01": "メニューの各グループはユーザーの仕事で名付けられる（その人の語彙で、プロジェクトの用語集を用いて）。技術的なモジュールでもデータのエンティティでも決してない。",
        "UX-02": "各機能はちょうど一つの正規の家を持つ。二つのグループに役立つなら、一つの家を選び、もう一方からはリンクする。入口は複製しない。",
        "UX-03": "孤児はない。宣言されたすべての機能は入口画面から三ステップ以内で到達可能である。",
        "UX-04": "グループのサイズは妥当である。三つ未満の機能はグループでなかったものを示し、七つを超えるものは引き出しを示す。",
        "UX-05": "すべてのグループは、そこで何をするのか、主な操作は何かを言う入口画面を持つ。空の表で直接開くグループはない。",
        "UX-06": "人が頻繁に行うフローは一緒に住む。「支払を登録する」と「顧客の口座を見る」が同じセッションで使われるなら、同じグループを共有する。",
        "UX-07": "最初のクリックのテスト：所有者は具体的な作業（「支払はどこで請求しますか」）の前に一つの場所を名指す。二つを名指すなら重複があり、一つも名指さないなら孤児がある。各ブロックの閉鎖時に走らせる。",
        "UX-08": "すべての機能はマトリクスの中で、どのプロファイルがそれを持つかを宣言する。プロファイルのない機能は存在しない。プロファイルを割り当てるか、削除するかである。",
        "UX-09": "宣言されたすべてのプロファイルは少なくとも一つの機能と独自の入口点を持つ。空のプロファイルは、設計時に誰も使わなかったプロファイルである。",
        "UX-10": "ナビゲーションはマトリクスから生成される。手書きのメニューは近道ではなく故障である。",
        "UX-11": "隠すことは保護することではない。すべてのルートは入口を隠すことに加えてサーバ側で権限を検証する。アドレスを手で書いても入るには足りない。",
        "UX-12": "少なすぎても多すぎてもならない。プロファイルごとに、到達可能な機能の集合はマトリクスのその行の集合とちょうど同じである。",
        "UX-13": "拒否は説明される。人が自分に属さない機能に入ったとき、なぜか、誰にアクセスを求めるべきかと言うメッセージを見る。空白の画面でも、理由のない灰色のボタンでも決してない。",
        "UX-14": "同じボタンは全員にとって同じことを意味する。二つのプロファイルがラベルを共有するなら、効果も共有する。効果がプロファイルによって変わるなら、ラベルが変わるか、機能が二つに分かれる。",
        "UX-15": "データもプロファイルでフィルタされる。一覧を見る人は自分に対応する行を見るのであり、完全な一覧から行をブラウザで隠したものを見るのではない。",
        "UX-16": "マトリクスとユーザーマニュアルは機能と同じペンディングで更新される。マトリクスに行のない新しい機能は閉じられない。",
        "UX-17": "すべての一覧は四つの解決された状態を持つ。データあり、空、読み込み中、エラーである。空は「まだ何もない」と「あなたの検索が見つけなかった」を区別する。",
        "UX-18": "何かが遅れている間は、動いていることが見え、長ければキャンセルできる。何も応答しないボタンが第一の苦情である。",
        "UX-19": "エラーは何が起きたか、何ができるかを言い、入力済みのものを消さない。技術的なコードだけでも、「エラーが発生しました」でもない。",
        "UX-20": "画面には明らかな主操作が一つあり、残りは副次的であり、そう見える。",
        "UX-21": "すべての破壊的な操作は影響を受ける対象を名指して確認を求め、できるときは確認する代わりに取り消す。",
        "UX-22": "失敗したフォームは入力済みのものを保ち、問題のある欄をその欄の場所で示す。",
        "UX-23": "どの操作も画面を出口のないままにしない。保存、削除、キャンセルの後、その人はどこにいるのか、どう続けるのかを知る。",
        "UX-24": "インターフェースはプロジェクトの用語集の言語を話す。同じ対象は画面でも、マニュアルでも、メールでも同じように呼ばれる。同義語は欠陥である。",
        "UX-25": "主要なフローでは、マウスなしで、スクリーンリーダーで、すべてを行える。フォーカスは常に見え、閉じ込められない。",
        "UX-26": "状態は色だけで伝わらない。情報を持つ画像はすべて代替テキストを持ち、テキストはズームなしで通常のサイズで読める。",
        "UX-27": "画面に触れる各ペンディングはテスト環境の実際のスクリーンショットを提出し、所有者は閉じる前にそれを見る。スクリーンショットは任意でもなく、モックアップでもない。",
        "UX-28": "エージェントが所有者の決定を必要とするとき、問いは四つの部分を伴い、この順で届く。それを必要にしているデータを列挙して。それらをつないで問いが見えるようにする五行以内の段落。取りうる答えに番号を振った問いそのもの。そしてエージェントの推奨。そしてプロジェクトが宣言した技術的な深さで。裸の問いは、なぜそれを尋ねられているのかを再構成する仕事を所有者に残す。"
      }
    },
    "zh": {
      "steps": {
        "u00-elegibilidad": "这个项目能这样做吗？（适格性）",
        "u01-contrato-de-convivencia": "协作契约（代码之前的规则）",
        "u02-definicion-y-lectura": "项目定义与必读",
        "u03-dimensionar": "在设计架构之前先做容量估算",
        "u04-esqueleto": "带闸门的骨架",
        "u05-pendientes": "计划就是待办项",
        "u06-decisiones": "决策写在代码旁边",
        "u07-medir": "构建之前先测量，用一把自己也要被验证的量具",
        "u08-tests-en-rojo": "作为锁的测试，先证红",
        "u09-calidad-de-codigo": "由机器验证的代码质量，带闸门",
        "u10-casos-de-prueba-manual": "人工测试用例和功能一起写，并且由人来执行",
        "u11-simetria-y-antipatrones": "生产者与消费者之间的对称性，以及反模式记录",
        "u12-verificacion-honesta": "诚实的验证与相称的报告",
        "u13-auditoria": "作为计划输入的定期审计",
        "u14-fail-closed": "失败即关闭、锁与零静默损害",
        "u15-ci-entornos-secretos-deploy": "持续集成、环境、密钥与作为产品一部分的部署",
        "u16-observabilidad-y-trazabilidad": "完整的可观测性与可追溯性，级别可配置",
        "u17-persistencia": "持久化层的优化，前后都要测量",
        "u18-vulnerabilidades": "漏洞的扫描与解决，放进链条并带日程",
        "u19-rendimiento-y-punto-de-ruptura": "量级下的性能测试与断裂点",
        "u20-documentacion-viva": "活的文档与一个人无需 AI 即可遵循的手册",
        "u21-monitoreo-de-recursos": "对资源、函数和超出范围查询的监控，带周期报告",
        "u22-monitoreo-de-errores": "错误监控与周期报告：没有任何错误没有待办项",
        "u23-agente-residente-y-retrospectiva": "系统里的代理，以及带数字的复盘"
      },
      "stations": {
        "n0-elegibilidad-legado": "既有系统的适格性：一个模型能够验证的那些前提条件",
        "n1-contrato-legado": "遗留系统的协作契约",
        "n2-lectura-del-sistema": "阅读系统：恢复出来的地图和那些不一致",
        "n3-auditoria-inventario": "作为债务清单的审计",
        "n4-cinturon-de-seguridad": "安全带",
        "n5-candados-y-mapa": "从代码里找出锁和生产者-消费者地图",
        "n6-dimensionar-real": "用真实数字做容量估算",
        "n7-backlog-de-normalizacion": "和客户请求配对的规范化待办队列"
      },
      "rules": {
        "CQ-01": "只有一个格式化器，无人干预地运行，并且不容争辩。",
        "CQ-02": "每个仓库只有一个 linter，它的规则对所有人相同；关掉一条规则要写出理由，绝不在某个孤立的文件里关。",
        "CQ-03": "任何文件不超过声明的上限（起点为 300 行），任何函数不超过自己的上限（起点为 40 行）。",
        "CQ-04": "任何函数不超过声明的路径上限。",
        "CQ-05": "不引入新的重复：被复制的块要么被抽取出去，要么被说明理由。",
        "CQ-06": "没有死代码：未使用的函数、变量、导入、分支和依赖。",
        "CQ-07": "如果语言允许类型，项目就认真使用类型；“任意”类型是一条声明出来的例外，不是习惯。",
        "CQ-08": "覆盖率不下降：今天的数字就是明天的底线。",
        "CQ-09": "在有真实用户时，变异得分按块测量，每个在新代码里存活下来的变异体开一个待办项。",
        "CQ-10": "每个依赖都已声明、被使用，并且没有带来与它贡献不相称的第三方依赖树。",
        "CQ-11": "仓库里没有凭据、密钥或连接串，新增的历史里也没有。",
        "CQ-12": "界面不做决定：任何页面或组件都不包含业务规则（什么可以做、收多少钱、接下来是什么状态）。它们住在领域里，由视图去查询。",
        "CQ-13": "每一次对服务端的调用都经过一个唯一的、带类型的客户端；没有任何页面自己手工拼请求。",
        "CQ-14": "共享状态只有一处存放地；页面之间复制状态是故障，不是捷径。",
        "CQ-15": "所有可见文本都来自翻译目录；没有任何用户可见字符串被写在组件内部。",
        "CQ-16": "每个可交互元素都带稳定标识符和角色，好让自动测试按名字而不是按位置找到它。",
        "CQ-17": "所有颜色、间距和字体都来自设计令牌；样式表里没有任何孤立的魔法值。",
        "CQ-18": "基本无障碍自行验证：对比度、字段标签、可见焦点、主要流程中的键盘导航、带替代文本的图片。",
        "UX-01": "菜单的每个分组都用一个用户的工作来命名（用他的词汇，用项目的术语表），绝不用技术模块或数据实体命名。",
        "UX-02": "每个功能恰好有一个归口。如果它服务两个分组，就选一个归口，从另一个链接过去；入口不复制。",
        "UX-03": "没有孤儿：每个声明的功能都能从入口页面在三步之内到达。",
        "UX-04": "分组的大小是合理的：少于三个功能说明它本来不是分组；多于七个说明它是个抽屉。",
        "UX-05": "每个分组都有一个入口页面，说明在这里做什么、主操作是什么。没有哪个分组一打开就是一张空表。",
        "UX-06": "人经常做、连在一起做的流程住在一起：如果“录入一笔付款”和“查看该客户的账户”在同一次会话里被使用，它们共用一个分组。",
        "UX-07": "首次点击测试：所有者面对一个具体任务（“你在哪里收一笔付款？”），说出一个地方。如果说得出两个，就有重复；如果一个都说不出，就有孤儿。每个块关闭时运行。",
        "UX-08": "每个功能都在矩阵里声明哪些角色拥有它。没有角色的功能不存在：要么给它分配角色，要么删掉。",
        "UX-09": "每个声明的角色至少有一个功能和自己的入口点。空角色是设计时没人用过的角色。",
        "UX-10": "导航由矩阵生成。手写的菜单是故障，不是捷径。",
        "UX-11": "隐藏不等于保护：每条路由除了藏起入口，还要在服务端校验权限。手写地址不足以进入。",
        "UX-12": "不多不少：对每个角色来说，可到达的功能集合恰好等于它在矩阵里那一行。",
        "UX-13": "拒绝要说清：如果一个人进入不属于他的功能，他看到一个消息，说明为什么、该向谁申请权限。绝不是空白页面，绝不是没有理由的灰按钮。",
        "UX-14": "同一个按钮对所有人意味着同一件事：如果两个角色共用标签，就共用效果。如果效果随角色而变，标签就变，或者功能拆成两个。",
        "UX-15": "数据也按角色过滤：看到列表的人看到属于他的那些行，而不是在浏览器里把行藏起来的完整列表。",
        "UX-16": "矩阵和用户手册在与功能同一个待办项里更新。没有矩阵行的新功能不关闭。",
        "UX-17": "每张列表都有四个已处理的状态：有数据、空、加载中、出错。空状态区分“还没有”和“你的搜索没有找到”。",
        "UX-18": "当某事耗时，要看得见它在工作，如果很长还可以取消。一个毫无反应的按钮是第一号抱怨。",
        "UX-19": "错误说明发生了什么、可以做什么，并且不抹掉已录入的内容。既不是只有一个技术代码，也不是一句“发生了错误”。",
        "UX-20": "一个页面有一个明显的主操作；其余是次要的，并且看起来就是次要的。",
        "UX-21": "每个破坏性操作都要在命名受影响对象的前提下请求确认；能撤销时，就撤销而不是确认。",
        "UX-22": "失败的表单保留已录入的内容，并在字段所在的位置标出有问题的字段。",
        "UX-23": "没有任何操作把页面留在死路上：保存、删除或取消之后，人知道自己停在哪里、怎么继续。",
        "UX-24": "界面说项目术语表的语言：同一个对象在页面里、手册里和邮件里叫同一个名字。一个同义词就是一个缺陷。",
        "UX-25": "主要流程里的一切都能不用鼠标、用屏幕阅读器完成；焦点永远可见，也不会被困住。",
        "UX-26": "状态不只靠颜色传达；每一张有信息量的图片都有替代文本；文本在正常字号下无需缩放即可阅读。",
        "UX-27": "每个触及页面的待办项都交付来自测试环境的真实截图，所有者在关闭之前看它。截图不是可选项，也不是一张效果图。",
        "UX-28": "当代理需要所有者做决定时，问题带着它的四个部分、按这个顺序到来：让它成为必要的数据，列举出来；不超过五行的一段话，把这些数据连起来并让问题显现；问题本身，可能的答案逐一编号；以及代理的推荐。并且用项目声明的技术深度来说。一个光秃秃的问题，把\"为什么要问我\"的重建工作留给了所有者。"
      }
    }
  }
}
