@arcadialdev/arcality 4.1.0 → 4.1.1

package/.agents/skills/db-validation-evidence/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: db-validation-evidence
+description: Define, review, or execute Arcality mission corroboration against PostgreSQL or an MCP-backed database bridge. Use when a mission must validate database state after UI execution, compare exact field values, verify record existence, protect connection secrets, or reflect database evidence in reports.
+---
+
+# DB Validation Evidence
+
+Corroborate business outcomes in the database after the UI flow finishes.
+
+## Follow this workflow
+
+1. Read `.arcality/db-validations.yaml` before changing mission-level database checks.
+2. Keep raw SQL out of missions. Reference allowlisted `query_id` entries only.
+3. Keep connection strings and credentials in `.env` or local secret stores only.
+4. Prefer read-only queries that return the minimum fields needed for validation.
+5. Start with two assertion types unless the user explicitly needs more:
+   - record existence
+   - exact field values
+6. Attach or preserve `database_validation_report` evidence so the HTML report shows the database outcome.
+
+## Choose the provider
+
+- Use direct PostgreSQL when the local runner can reach the database and the query catalog is enough.
+- Use MCP when the team already has a PostgreSQL MCP server, wants centralized access policy, or needs a custom tool contract.
+
+## Author mission validations carefully
+
+- Use one validation per business expectation.
+- Name validations in business language, not technical shorthand.
+- Pass only the parameters needed by the allowlisted query.
+- Fail the mission when the UI result and database result contradict each other.
+
+## Add or review query catalog entries carefully
+
+- Keep each query focused on one entity lookup or one business rule.
+- Parameterize dynamic values.
+- Avoid `select *`.
+- Prefer deterministic ordering and explicit limits where the schema allows duplicates.
+- Return stable field names that map cleanly to expected assertions.
+
+## Read more when needed
+
+- Read [references/mission-patterns.md](references/mission-patterns.md) when defining YAML examples, connection profiles, or rollout priorities.

package/.agents/skills/db-validation-evidence/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "DB Validation QA"
+  short_description: "Validate UI outcomes against PostgreSQL state"
+  default_prompt: "Use $db-validation-evidence to define or review local database corroboration for an Arcality mission."

package/.agents/skills/db-validation-evidence/references/mission-patterns.md

@@ -0,0 +1,130 @@
+# DB validation patterns for Arcality
+
+## Scope
+
+Use this skill for local Arcality runs that need database corroboration after a mission completes. Keep CI/CD and pipeline concerns out of scope unless the user explicitly reintroduces them.
+
+## Preferred rollout order
+
+1. Validate record existence.
+2. Validate exact field values.
+3. Add negative validations only when the happy path is stable.
+4. Add broader consistency checks only after the query catalog is trusted.
+
+## Recommended secret model
+
+Store connection values in `.env` only.
+
+```env
+ARCALITY_DB_ENABLED=true
+ARCALITY_DB_PROVIDER=postgres
+ARCALITY_DB_PROFILE=qa_local
+ARCALITY_DB_QA_LOCAL_URL=postgresql://readonly_user:password@host:5432/database?sslmode=require
+ARCALITY_DB_CATALOG=.arcality/db-validations.yaml
+ARCALITY_DB_TIMEOUT_MS=8000
+```
+
+For MCP-backed validation:
+
+```env
+ARCALITY_DB_ENABLED=true
+ARCALITY_DB_PROVIDER=mcp
+ARCALITY_DB_PROFILE=qa_local
+ARCALITY_DB_CATALOG=.arcality/db-validations.yaml
+ARCALITY_DB_MCP_CONFIG=.arcality/mcp.postgres.json
+ARCALITY_DB_TIMEOUT_MS=8000
+```
+
+Do not place credentials in mission YAML, reports, screenshots, or attachments.
+
+## Query preview pattern
+
+Before wiring a strict mission assertion, use `preview_db_validation` with the same `query_id` and `params` to confirm:
+
+- the provider can connect
+- the query returns the expected entity
+- the returned field names match the intended `expect.fields`
+
+Example preview payload:
+
+```json
+{
+  "name": "preview_cliente_creado",
+  "query_id": "client_by_name",
+  "params": {
+    "name": "Cliente QA 001"
+  }
+}
+```
+
+## Mission pattern
+
+Use mission-level `db_validations` entries with business-oriented names and allowlisted `query_id` values.
+
+```yaml
+db_validations:
+  - name: cliente_creado_en_bd
+    query_id: client_by_name
+    params:
+      name: "Cliente QA 001"
+    expect:
+      exists: true
+      fields:
+        status: "ACTIVE"
+```
+
+## Query catalog pattern
+
+Keep `.arcality/db-validations.yaml` small, reviewable, and read-only in spirit.
+
+```yaml
+queries:
+  - id: client_by_name
+    description: Buscar cliente por nombre exacto
+    parameters:
+      - name: name
+        required: true
+    sql: |
+      select id, name, status
+      from clients
+      where name = :name
+      order by id desc
+      limit 1
+```
+
+## When to prefer MCP
+
+Prefer MCP when:
+
+- the team already uses an approved PostgreSQL MCP server
+- access policy should stay centralized
+- the MCP server exposes audited or pre-shaped tools that fit your environment
+
+Prefer direct PostgreSQL when:
+
+- the runner already has network access
+- a simple readonly connection is enough
+- you want fewer moving parts during local validation
+
+## Report expectations
+
+The database result should be visible in the generated evidence. At minimum, preserve:
+
+- validation name
+- query id
+- provider used
+- expected existence
+- expected fields
+- actual row presence
+- actual returned fields
+- pass or fail status
+
+## First backlog after this skill
+
+The next highest-value skills after DB validation are:
+
+1. evidence-synthesis-reporting
+2. qa-context-governance
+3. mission-generation-reviewer
+4. test-data-lifecycle
+

package/.agents/skills/evidence-synthesis-reporting/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: evidence-synthesis-reporting
+description: Normalize Arcality UI, console, network, attachment, and database evidence into one business-readable conclusion. Use when a mission needs a final narrative, contradiction analysis, remediation hints, or a compact summary that merges multiple evidence sources.
+---
+
+# Evidence Synthesis Reporting
+
+Produce one clear conclusion from mixed evidence.
+
+## Follow this workflow
+
+1. Start with the business outcome, not the raw telemetry.
+2. Compare UI outcome against database corroboration before declaring success.
+3. Treat console or network errors as supporting evidence, not as the only conclusion.
+4. Call out contradictions explicitly when UI and database disagree.
+5. Prefer short evidence summaries with attachment names, failure reason, and next action.
+6. Redact secrets or sensitive values before including examples in the narrative.
+
+## Synthesize in this order
+
+1. UI outcome
+2. Database corroboration
+3. Console or network anomalies
+4. Attachments that prove the state
+5. Final user-facing conclusion
+
+## Escalate when needed
+
+- Mark the run as failed when the UI appears successful but the database validation fails.
+- Mark the run as inconclusive when the evidence is incomplete or contradictory.
+- Add remediation hints only when they are grounded in the captured evidence.

package/.agents/skills/form-expert/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: form-expert
+description: Metodologia experta para explorar, identificar y llenar formularios complejos en aplicaciones web.
+---
+
+# Form Expert Skill
+
+Esta habilidad define el protocolo que el agente DEBE seguir cuando la mision involucra llenar, crear o editar registros a traves de formularios.
+
+## Principio Fundamental
+**NUNCA interactues con un campo que no hayas inspeccionado primero.** Si un componente tiene un nombre generico, un tag inferred como `[INFERRED]`, o simplemente no estas seguro de que es, usa `inspect_element_details` ANTES de hacer click o fill.
+
+## Protocolo de Formularios (4 fases obligatorias)
+
+### Fase 1: RECONOCIMIENTO (Scan)
+Antes de llenar cualquier campo, dedica tu primer turno en el formulario a **analizar todos los componentes visibles**:
+
+1. **Lee la lista completa de CURRENT COMPONENTS** e identifica:
+   - Campos de tipo FIELD (inputs, textareas, selects)
+   - Campos con label visible (prioritarios)
+   - Campos sin label o con nombre generico (requieren inspeccion)
+   - Botones de accion (GUARDAR, CANCELAR, etc.)
+   - Tabs o pestanas si el formulario tiene secciones
+
+2. **Clasifica los campos** en:
+   - Confiables: Tienen un nombre claro como `[input] Titulo del documento`
+   - Sospechosos: Tienen nombre generico como `[input] Editar` o `[INFERRED] xxx`
+   - Desconocidos: Solo tienen tag generico como `[input]`
+
+3. **Para campos sospechosos o desconocidos** usa `inspect_element_details` para obtener:
+   - El placeholder text
+   - El aria-label
+   - El atributo name o id
+   - Si esta disabled o readonly
+
+### Fase 2: PLANIFICACION (Plan)
+Con la informacion del reconocimiento, planifica la secuencia de acciones:
+
+1. **Prioriza los campos obligatorios**. Los que tienen asterisco (`*`), clase `required`, o estan marcados en rojo.
+2. **Genera datos unicos**. Si la mision dice "generico" o "aleatorio", genera datos que incluyan un timestamp o ID unico para evitar duplicados. Ejemplo: `TEST-${timestamp}` o `Prueba QA Feb24`.
+3. **Planifica el orden**. Llena los campos de arriba a abajo, izquierda a derecha, siguiendo el orden del DOM.
+
+### Fase 3: EJECUCION (Act)
+Ejecuta las acciones planificadas:
+
+1. **Llena multiples campos por turno**. No pierdas un turno por campo. Agrupa 3-5 fills en una sola llamada a `perform_ui_actions`.
+2. **Para cada campo fill**: click + fill (en ese orden). El click asegura que el campo tiene focus.
+3. **Para dropdowns/selects** usa el protocolo de re-render:
+   - **Turno A**: Click para abrir el dropdown, espera el siguiente turno para ver las opciones.
+   - **Turno B**: Click en la opcion deseada. Si el formulario requiere llenar mas campos despues de seleccionar (por ejemplo, se habilitan nuevos inputs), deten la secuencia ahi. No agrupes el select con los siguientes fills en el mismo turno porque React puede re-renderizar el DOM y romper los IDs. Espera al Turno C para seguir.
+   - Si la seleccion del dropdown era el ultimo paso y ya no hay mas campos que llenar, si puedes hacer click en `Siguiente` o `Guardar` en ese mismo turno.
+4. **Si un fill falla**, no reintentes inmediatamente. Usa `inspect_element_details` para ver si el campo es un select, un datepicker, o tiene un overlay encima.
+
+### Fase 4: VERIFICACION (Verify)
+Antes de hacer GUARDAR:
+
+1. Usa `validate_element_state` en el boton de GUARDAR para confirmar que esta enabled.
+2. Revisa visualmente si hay campos en rojo o mensajes de error.
+3. Solo entonces haz click en GUARDAR.
+4. Despues de GUARDAR, espera la respuesta de la UI. Si aparece un toast de exito o regresas a la lista, la mision fue exitosa.
+
+## Manejo de Errores en Formularios
+
+### Si un campo falla con Timeout
+1. No reintentes el mismo click o fill inmediatamente.
+2. Usa `inspect_element_details` en ese IDX.
+3. Analiza si:
+   - El elemento esta cubierto por un overlay o modal
+   - El elemento es readonly o disabled
+   - El IDX cambio porque la pagina se re-renderizo
+4. Si el elemento no sirve, busca un campo alternativo con nombre similar.
+
+### Si aparece un error de "duplicado" o "ya existe"
+1. Identifica que campo causo el error (claves, codigos, nombres).
+2. Cambia el valor a algo unico (agrega sufijo numerico o timestamp).
+3. Reintenta GUARDAR.
+
+### Si el formulario tiene tabs o secciones
+1. Llena los campos de la seccion actual primero.
+2. Identifica el elemento de la pestana. Busca el texto de la pestana (por ejemplo, `CAMPOS DE LA FORMA`) en componentes tipo ACTION.
+3. Evita hacer click en contenedores grandes que agrupan varias pestanas. Prefiere el elemento mas pequeno (span o label) que contenga el texto exacto.
+4. Haz click en la pestana. Si un click simple no funciona tras 2 intentos, usa `double_click`.
+5. Espera el siguiente turno para ver los nuevos campos.
+
+## Uso de Double Click
+
+Usalo solo cuando:
+- La mision lo pida explicitamente
+- Un elemento, como una pestana o un icono, no responda tras dos intentos de click simple
+- Quieras activar modos de edicion en tablas o componentes complejos
+
+## Anti-patrones
+
+- No hacer click en un campo `[INFERRED]` sin inspeccionarlo primero
+- No intentar llenar todo el formulario en el primer turno sin saber que campos hay
+- No hacer click en GUARDAR sin haber verificado que los campos estan llenos
+- No reintentar la misma accion fallida sin investigar la causa
+- No asumir que un componente con nombre largo (mas de 50 caracteres) es un campo, probablemente es un contenedor

package/.agents/skills/investigation-protocol/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: investigation-protocol
+description: Protocolo obligatorio de investigacion cuando una accion falla o un elemento es ambiguo.
+---
+
+# Investigation Protocol Skill
+
+## Regla de Oro
+**NUNCA reintentes una accion fallida sin investigar primero.** Si algo falla, SIEMPRE ejecuta el protocolo de investigacion antes de intentar de nuevo.
+
+## Protocolo de Investigacion
+
+### Paso 1: Inspeccion del elemento
+
+Usa `inspect_element_details` sobre el elemento que fallo para determinar por que fallo.
+
+Revisa en el resultado:
+- Si el elemento es `disabled` o `readonly`
+- Si el elemento esta cubierto por otro (`pointer-events: none`, overlay)
+- Si el elemento es un `<select>` que requiere interaccion diferente a `fill`
+- Si el elemento esta en un iframe diferente (`frameIdx`)
+
+### Paso 2: Auditoria de consola
+
+Usa `capture_console_errors` para buscar errores JavaScript silenciosos.
+
+Si la UI no responde o esta congelada, revisa:
+- Errores de red (`fetch failed`, `404`, `500`)
+- Errores de JS (`TypeError`, `undefined`)
+- Warnings del framework
+
+### Paso 3: Captura de evidencia
+
+Usa `create_test_evidence` con `type: annotated_screenshot` para documentar el estado actual.
+
+Si identificas un bug real de la aplicacion, documentalo con evidencia anotada.
+
+### Paso 4: Decision
+
+Despues de investigar, toma una de estas decisiones:
+1. **Reintentar con variacion**: Si descubriste que el campo es un select, usa click en vez de fill.
+2. **Buscar alternativa**: Si el elemento esta cubierto, busca otro camino al mismo objetivo.
+3. **Reportar bug**: Si es un bug de la aplicacion, usa `report_application_bug`.
+4. **Reportar incapacidad**: Si no puedes avanzar, usa `report_inability_to_proceed`.
+
+## Cuando usar cada herramienta
+
+| Situacion | Herramienta | Obligatoria |
+|-----------|-------------|-------------|
+| Accion fallo con Timeout | `inspect_element_details` | Si |
+| Elemento con nombre `[INFERRED]` | `inspect_element_details` | Si |
+| UI no responde o congelada | `capture_console_errors` | Si |
+| Antes de hacer GUARDAR o SAVE | `validate_element_state` | Si |
+| Despues de GUARDAR exitoso | `extract_table_data` | Recomendada |
+| Bug encontrado | `create_test_evidence` | Si |
+| Fin de mision exitosa | `create_test_evidence` | Recomendada |

package/.agents/skills/mission-generation-reviewer/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: mission-generation-reviewer
+description: Review generated Arcality YAML missions before execution. Use when a mission may contain vague prompts, weak assertions, missing business checkpoints, poor evidence strategy, or unclear need for UI-only versus database-backed validation.
+---
+
+# Mission Generation Reviewer
+
+Review generated missions before they run.
+
+## Follow this workflow
+
+1. Check whether the mission objective is specific and observable.
+2. Replace vague success criteria with concrete assertions.
+3. Confirm the mission names the real business checkpoint, not only low-level clicks.
+4. Decide whether the flow needs UI-only validation or additional database corroboration.
+5. Flag missing evidence steps when the mission would be hard to explain after failure.
+6. Keep mission edits small and tied to test intent.
+
+## Watch for these gaps
+
+- Generic prompts like "validate the page works"
+- Assertions without expected values
+- Missing post-save verification
+- Database validation added without a matching allowlisted query_id
+- Repeated actions that do not prove a business outcome

package/.agents/skills/modal-master/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: modal-master
+description: Gestion experta de ventanas modales, dialogos y popups en pruebas de QA.
+---
+
+# Modal Master Skill
+
+Esta habilidad permite al agente detectar, navegar y cerrar ventanas modales de manera eficiente, evitando que el flujo del test se bloquee por elementos superpuestos.
+
+## Cuando usar esta habilidad
+
+- Cuando el agente realiza una accion y aparece un dialogo de confirmacion
+- Cuando un popup de error o notificacion bloquea el acceso al resto de la pagina
+- Cuando la mision requiere interactuar especificamente con elementos dentro de un modal
+
+## Instrucciones para el Agente
+
+### 1. Deteccion de Modales
+
+Antes de intentar interactuar con un elemento del fondo, verifica si hay un modal activo buscando:
+- Elementos con `role="dialog"` o `role="alertdialog"`
+- Atributos `aria-modal="true"`
+- Overlays oscuros que cubren la pantalla
+- Titulos destacados que no estaban antes de la accion
+
+### 2. Prioridad de Interaccion
+
+Si un modal esta abierto:
+- **Prioridad 1**: Si el modal es informativo (warning o error), leelo y reportalo en tu pensamiento antes de cerrarlo.
+- **Prioridad 2**: Si el modal es de confirmacion para la accion que acabas de realizar, haz click en el boton afirmativo (por ejemplo, `Aceptar`, `Si`, `Confirmar`).
+- **Prioridad 3**: Si el modal es intrusivo y no permite seguir, busca el boton de cierre (usualmente una `X`, `Cerrar` o `Cancelar`).
+
+### 3. Estrategias de Cierre
+
+Si no encuentras un boton de cierre claro:
+- Busca botones con clases `close`, `btn-close` o que tengan un icono dentro
+- Usa `send_keyboard_event` con key `Escape`
+- Verifica si el modal desaparece al hacer click en el backdrop
+
+### 4. Flujo de Trabajo
+
+1. Accion: click en `Eliminar`
+2. Scan: detecta un modal con texto tipo `Estas seguro?`
+3. Validacion: usa `validate_element_state` para verificar que el boton destructivo o confirmatorio es visible dentro del modal
+4. Ejecucion: click en el boton del modal
+5. Verificacion: espera a que el modal desaparezca antes de continuar

package/.agents/skills/native-control-expert/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: native-control-expert
+description: Protocolo experto para interactuar con controles nativos del navegador (time pickers, date pickers, selects, etc.).
+---
+
+# Native Control Expert Skill
+
+Esta habilidad define el protocolo que el agente DEBE seguir cuando la mision involucra interactuar con controles nativos del navegador que no responden bien a la accion estandar `fill`.
+
+## Controles Nativos que requieren esta skill
+
+| Control | Ejemplo | Accion preferida |
+|---------|---------|------------------|
+| `<input type="time">` | Campo de hora `HH:mm` | `interact_native_control` con `control_type: "time"` |
+| `<input type="date">` | Campo de fecha `YYYY-MM-DD` | `interact_native_control` con `control_type: "date"` |
+| `<input type="datetime-local">` | Fecha y hora combinados | `interact_native_control` con `control_type: "datetime"` |
+| `<input type="color">` | Selector de color | `interact_native_control` con `control_type: "color"` |
+| `<input type="range">` | Slider numerico | `interact_native_control` con `control_type: "range"` |
+| `<select>` nativo | Dropdown estandar HTML | `interact_native_control` con `control_type: "select"` |
+| Combobox o autocomplete | Campos con `role="combobox"` | `click` + `fill` + `send_keyboard_event` |
+| Time picker con dialogo | Campos que abren popup al hacer click | `send_keyboard_event` con arrows |
+
+## Protocolo de Interaccion con Time Pickers
+
+### Lo que no debes hacer
+
+- No intentar `fill` repetidamente si falla la primera vez
+- No hacer click una y otra vez sin cambiar de estrategia
+- No asumir que un time picker funciona como un input de texto normal
+
+### Estrategia 1: `interact_native_control`
+
+1. Usa `inspect_element_details` para confirmar que es `type="time"`.
+2. Usa `interact_native_control` con `control_type: "time"` y un valor como `13:05`.
+3. Verifica el resultado.
+
+### Estrategia 2: Keyboard Navigation
+
+1. Haz click en el campo de hora.
+2. Usa `send_keyboard_event` con `Control+a` para seleccionar todo.
+3. Escribe los digitos del tiempo.
+4. Para `13:05`, envia las teclas `1`, `3`, `0`, `5`.
+5. Usa `Tab` para navegar al siguiente campo.
+
+### Estrategia 3: Arrow Keys
+
+1. Haz click en el segmento de horas del campo.
+2. Usa `ArrowUp` o `ArrowDown` para ajustar la hora.
+3. Usa `Tab` para mover al segmento de minutos.
+4. Repite con `ArrowUp` o `ArrowDown` para minutos.
+
+## Protocolo de Interaccion con Date Pickers
+
+1. Confirma con `inspect_element_details` que es `type="date"`.
+2. Usa `interact_native_control` con `control_type: "date"` y valor `YYYY-MM-DD`.
+
+## Deteccion
+
+Activa esta skill cuando:
+1. Ves un componente FIELD cuyo nombre incluye `HH:mm`, `hora` o `time`
+2. Un campo tiene `role="combobox"` y `aria-expanded`
+3. Un `fill()` falla en un campo de fecha u hora
+4. El inspector muestra `type="time"` o `type="date"`
+
+## Keyboard shortcuts utiles
+
+| Tecla | Efecto |
+|-------|--------|
+| `Tab` | Mover al siguiente segmento |
+| `ArrowUp` | Incrementar valor |
+| `ArrowDown` | Decrementar valor |
+| `Escape` | Cerrar dropdown o calendar |
+| `Enter` | Confirmar seleccion |
+| `Control+a` | Seleccionar todo |

package/.agents/skills/qa-context-governance/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: qa-context-governance
+description: Govern .arcality/qa-context.md and .arcality/qa-context.meta.json so Arcality uses fresh, owned, and reviewable customer rules. Use when validating context completeness, metadata quality, enforcement mode, stale guidance, or conflicts between local rules and observed behavior.
+---
+
+# QA Context Governance
+
+Keep local QA context usable, current, and reviewable.
+
+## Follow this workflow
+
+1. Read both .arcality/qa-context.md and .arcality/qa-context.meta.json together.
+2. Confirm ownership, version, updated_by, owner_team, and change_summary before trusting the context.
+3. Separate real business rules from placeholders, examples, or stale notes.
+4. Warn when context exists without governance metadata.
+5. Escalate when strict governance is enabled and required metadata is incomplete.
+6. Prefer small, auditable updates over broad rewrites.
+
+## Resolve conflicts carefully
+
+- If local context contradicts observed application behavior, report the contradiction instead of silently trusting one side.
+- If context is incomplete, fall back to base heuristics but make the gap visible.
+- If the user asks to change governance mode, preserve the current files and only adjust the enforcement decision.

package/.agents/skills/security-evidence-triage/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: security-evidence-triage
+description: Triage security-related evidence captured by Arcality into confirmed findings, suspicious signals, or unsupported noise. Use when reviewing console errors, headers, reflected payloads, auth bypass behavior, or mixed signals from the existing security QA tools.
+---
+
+# Security Evidence Triage
+
+Classify security evidence before escalating it.
+
+## Follow this workflow
+
+1. Separate a confirmed vulnerability from a suspicious signal.
+2. Tie every claim to at least one concrete artifact: screenshot, response, console output, storage evidence, or replayable step.
+3. Record severity and confidence independently.
+4. Downgrade findings that lack proof of exploitability.
+5. Preserve raw payload details only when they are necessary for reproduction.
+6. Prefer a short reproduction note plus evidence list over a long speculative explanation.
+
+## Use these categories
+
+- Confirmed: reproducible and supported by direct evidence
+- Suspected: credible signal but incomplete proof
+- Noise: no reliable reproduction or benign explanation found

package/.agents/skills/test-data-lifecycle/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: test-data-lifecycle
+description: Define safe Arcality patterns for creating, reusing, locating, and cleaning test data across missions. Use when reducing flaky validations caused by shared records, deciding whether to reuse existing entities, or planning setup and cleanup responsibilities.
+---
+
+# Test Data Lifecycle
+
+Keep test data deterministic and reviewable.
+
+## Follow this workflow
+
+1. Decide whether the mission should create fresh data or reuse an existing fixture.
+2. Prefer unique, traceable values when the application allows duplicate records.
+3. Record how the mission will locate the target record again for UI or DB validation.
+4. Avoid shared mutable data unless the mission explicitly tests shared workflows.
+5. Add cleanup steps only when they are reliable and proportional to the risk.
+6. Document when cleanup is intentionally skipped and why.
+
+## Prefer these patterns
+
+- Unique suffixes for names or codes
+- Read-only lookup queries for corroboration
+- Cleanup by deterministic identifier
+- Reuse only when the record is stable and part of the scenario