/balise-content-test

name: balise-content-test
description: Stress-tests UI content resilience across design files, screenshots, prototypes, source code, and rendered interfaces. Use when auditing, generating, repairing, or regression-testing difficult but realistic content and data cases involving length, missing values, numeric extremes, localization, RTL, Unicode, font fallback, text enlargement, variable media, narrow layouts, wrapping, truncation, disclosure, or content-driven component behavior. Preserves source artifacts and product meaning, distinguishes static evidence from runtime proof, and can produce content resilience contracts for design and engineering handoff.

Content Stress Test

Test how an interface behaves when ideal placeholder content is replaced by difficult but plausible content and data. Start from a risk, isolate important variables, observe the effect, repair only when authorized, and re-test with evidence appropriate to the artifact.

Treat content as any variable data rendered by the interface: text, names, identifiers, numbers, dates, currencies, units, status values, missing or partial values, user-generated input, localized strings, and externally supplied media.

Protect Scope and Evidence

• Treat the user’s selected files, frames, components, routes, pages, screenshots, or URLs as the working boundary.
• Inspect surrounding context when required to understand behavior, but do not edit outside the authorized scope.
• When the user asks to review, audit, explain, or diagnose, make no product or design changes.
• When testing a design artifact, preserve the source and create labeled duplicates when editing is available.
• When testing code, preserve existing architecture, component contracts, design-system conventions, localization bindings, and unrelated user changes.
• Do not modify shared components, published libraries, production systems, data, or deployments without explicit authorization.
• Use synthetic values. Never introduce real personal, confidential, medical, financial, authentication, research, or client data.
• State the evidence level for conclusions. Do not infer runtime, accessibility, localization, or user-understanding proof from a static artifact.
• Do not invent product limits, supported locales, fallback behavior, policies, or implementation guarantees.

Load the Relevant References

Read only the references needed for the request:

• Read [test-library.md](references/test-library.md) when choosing profiles, cases, data sources, or compound scenarios.
• Read [localization-unicode.md](references/localization-unicode.md) for pseudo-localization, plurals, regional formats, RTL, mixed-direction content, Unicode, or font fallback.
• Read [accessibility-runtime.md](references/accessibility-runtime.md) for the Accessible profile, browser verification, zoom, reflow, focus, keyboard, hover, touch, or accessibility claims.
• Read [remediation-patterns.md](references/remediation-patterns.md) before repairing or recommending overflow, disclosure, responsive, or component patterns.
• Read [resilience-contract.md](references/resilience-contract.md) for Deep tests, handoff, repeated component failures, or persistent reporting.

When the user requests a saved report, use [content-resilience-report-template.md](assets/content-resilience-report-template.md). Do not create a report file when a concise conversational result is sufficient.

Determine the Mode

Infer the requested mode:

• **Audit**: inspect and report risks or visible failures without changing artifacts.
• **Test**: create or run representative stress cases and diagnose the results.
• **Repair**: correct confirmed issues in the authorized artifact.
• **Test and repair**: test, diagnose, repair, and regression-test.

Default to Audit when edit intent is unclear. Testing may produce temporary local artifacts only when they are necessary, safely scoped, and within the request.

Identify the Evidence Surface

Classify what is actually available:

| Surface | Inspect | Valid conclusions | | --- | --- | --- | | Static design or screenshot | geometry, hierarchy, visible states, annotations | visible failure or design-level risk | | Editable design | components, properties, variables, Auto Layout, test copies | static behavior and intended interaction | | Source code | layout rules, formatter use, semantics, fixtures, breakpoints | implementation structure and likely behavior | | Rendered interface | actual content, viewports, zoom, focus, hover, keyboard, disclosure | observed runtime behavior in tested conditions | | Specialist evaluation | assistive technology, translation, legal or domain review | only the specialist’s verified scope |

Use the highest evidence level safely available and relevant to the request. Do not require a live application when the user only wants a design audit.

Follow the Workflow

1. Establish Context

Determine:

1. the primary user task and decision points; 2. variable content roles and their provenance; 3. known device sizes, breakpoints, locales, direction, currencies, date formats, and text-size expectations; 4. component, design-system, localization, and data conventions; 5. confirmed bounds and valid missing, loading, error, or redacted states; 6. the artifacts and tools available for verification; 7. unknowns that must remain assumptions or questions.

Inspect visible or repository evidence before asking. Ask one concise question only when the answer would materially change scope, validity, or safety.

2. Form Hypotheses

For each meaningful risk, define:

> Given [source or condition], [element] may [observable failure], affecting [task or information]. The test passes if [observable result].

Do not generate cases without a reason. A long string is a condition, not a finding.

3. Inspect the Baseline

Before introducing stress:

• read complete screens or components rather than isolated strings;
• distinguish product copy, dynamic data,