Client-Side Resilience Pattern Audit Prompt

This prompt is for mobile and frontend engineers who need to audit a client application's resilience architecture before it reaches production or after users report data loss during connectivity failures. The job-to-be-done is a structured, evidence-based review of offline support, request queuing, optimistic updates, and error recovery UX. The ideal user has access to the client codebase, network layer configuration, state management implementation, and product requirements for offline behavior. They use this prompt to produce a prioritized audit report that identifies gaps, ranks severity, and recommends concrete fixes—not to generate code, but to guide engineering decisions.

Use this prompt when you are preparing for a launch review, responding to a production incident involving stale or lost user data, or conducting a proactive resilience assessment. It works best when you provide specific code paths, state management patterns, and UX flows rather than abstract descriptions. The prompt requires [CODEBASE_CONTEXT] such as relevant service worker logic, local storage strategies, and retry configurations; [UX_FLOWS] describing the user-facing recovery experience; and [FAILURE_SCENARIOS] you want evaluated. Do not use this prompt for server-side resilience patterns, database replication reviews, or infrastructure-level fault tolerance—those require the sibling playbooks on circuit breaker design, retry policy analysis, or multi-region resilience architecture.

This prompt is not a substitute for chaos engineering or real device testing. It produces a design-level audit that identifies architectural gaps, but it cannot observe runtime behavior, measure actual latency under degraded networks, or catch platform-specific bugs. After running the audit, you must validate findings against real device testing, network conditioning tools, and user session replay data. For regulated applications handling financial transactions or health data, always route the audit output through a senior engineer review before accepting remediation recommendations. The next step after reading this section is to gather your codebase context, UX flows, and failure scenarios, then proceed to the prompt template.

This prompt template is designed to audit a client application's resilience patterns by analyzing provided source code, configuration, and architecture notes. It systematically evaluates offline support, request queuing, optimistic updates, and error recovery UX against known resilience patterns and anti-patterns. The template uses square-bracket placeholders that you must replace with your specific inputs before execution. The output is a structured audit report that can be parsed by downstream validation tools or reviewed directly by engineering teams.

textCopy
You are a senior mobile and frontend resilience engineer auditing a client application for fault-tolerance patterns.

Analyze the provided [CODE_SNIPPETS], [CONFIGURATION_FILES], and [ARCHITECTURE_NOTES] to produce a structured resilience audit.

Focus on these four dimensions:
1. Offline Support: local storage strategy, sync protocols, conflict resolution, and stale-data handling.
2. Request Queuing: queue persistence, ordering guarantees, retry policies, and backpressure mechanisms.
3. Optimistic Updates: rollback logic, server reconciliation, conflict detection, and user notification patterns.
4. Error Recovery UX: error categorization, user-facing messaging, retry affordances, and graceful degradation paths.

For each dimension, identify:
- Implemented patterns with evidence (file paths and line references).
- Missing or incomplete patterns that introduce risk.
- Anti-patterns that could cause data loss, user confusion, or cascading failures.
- Specific recommendations ranked by severity (CRITICAL, HIGH, MEDIUM, LOW).

[CONSTRAINTS]
- Only report findings supported by the provided code and configuration evidence.
- Do not speculate about runtime behavior not visible in the provided artifacts.
- Flag any gaps where the provided artifacts are insufficient to assess a dimension.
- Prioritize findings that affect data integrity and user trust over cosmetic issues.

[OUTPUT_SCHEMA]
{
  "audit_summary": {
    "overall_resilience_score": "string (LOW_RISK | MODERATE_RISK | HIGH_RISK | CRITICAL_RISK)",
    "dimensions_covered": ["string"],
    "dimensions_insufficient_data": ["string"],
    "critical_findings_count": "integer",
    "total_findings_count": "integer"
  },
  "findings": [
    {
      "id": "string (unique identifier)",
      "dimension": "string (OFFLINE_SUPPORT | REQUEST_QUEUING | OPTIMISTIC_UPDATES | ERROR_RECOVERY_UX)",
      "severity": "string (CRITICAL | HIGH | MEDIUM | LOW)",
      "category": "string (IMPLEMENTED_PATTERN | MISSING_PATTERN | ANTI_PATTERN | INSUFFICIENT_DATA)",
      "title": "string",
      "description": "string",
      "evidence": {
        "file_paths": ["string"],
        "line_references": ["string"],
        "configuration_keys": ["string"]
      },
      "impact": "string (description of user or data impact)",
      "recommendation": "string (actionable fix or investigation step)"
    }
  ],
  "dimension_summaries": {
    "offline_support": "string (concise assessment)",
    "request_queuing": "string (concise assessment)",
    "optimistic_updates": "string (concise assessment)",
    "error_recovery_ux": "string (concise assessment)"
  },
  "stale_data_risks": [
    {
      "scenario": "string",
      "trigger": "string",
      "user_impact": "string",
      "detection_mechanism_present": "boolean"
    }
  ],
  "conflicting_action_risks": [
    {
      "scenario": "string",
      "actions_in_conflict": ["string"],
      "resolution_strategy": "string (description or NONE_FOUND)",
      "data_loss_risk": "string (HIGH | MEDIUM | LOW)"
    }
  ]
}

[EXAMPLES]
Good finding: "Offline queue uses in-memory storage only (src/queue/requestQueue.ts:42). On app termination, queued writes are lost. No persistence to IndexedDB or AsyncStorage detected."
Bad finding: "The app probably loses data when offline." (No evidence, speculative language)

[RISK_LEVEL]
This audit informs architectural decisions and production resilience. Findings must be evidence-based. Flag any dimension where the provided artifacts are insufficient for a complete assessment.

To adapt this template, replace the square-bracket placeholders with your specific inputs. [CODE_SNIPPETS] should contain the relevant source files, focusing on networking layers, state management, persistence logic, and error handling components. [CONFIGURATION_FILES] should include retry policies, timeout settings, cache configurations, and feature flags related to offline or optimistic update behavior. [ARCHITECTURE_NOTES] can include ADRs, design docs, or inline comments explaining intentional resilience decisions. If you need to adjust the output schema, modify [OUTPUT_SCHEMA] to match your downstream parsing requirements, but preserve the evidence-tracking fields to maintain auditability. The [CONSTRAINTS] section enforces evidence-based reporting; remove or relax these only if you are using this prompt for speculative design review rather than code audit. The [RISK_LEVEL] placeholder should be updated to reflect your organization's tolerance for false positives versus missed findings.

This prompt is designed to be run against a structured input document describing a client application's resilience architecture. The ideal integration point is a CI/CD pipeline, a design review checklist tool, or an internal developer portal where engineers submit architecture descriptions for automated review before manual approval. Because the output is a structured audit with severity ratings, it can be parsed and fed into ticketing systems or dashboards.

Wrap the prompt in a function that accepts a [CLIENT_ARCHITECTURE_DESCRIPTION] string and a [PLATFORM_CONTEXT] string (e.g., iOS, Android, React Native, Flutter). Before calling the model, validate that the input contains sections on offline support, request queuing, optimistic updates, and error recovery UX. If any section is missing, return a pre-flight error asking the user to provide it rather than letting the model hallucinate a review. On the output side, parse the JSON response and validate that every finding has a non-empty severity, affected_component, finding, and remediation field. Reject and retry (once) if the schema is violated. Log all raw inputs, outputs, and parse errors for traceability.

For high-risk applications (e.g., financial transactions, health data), route findings with severity: critical to a human review queue before they are surfaced to the engineering team. Store audit results with a timestamp and architecture version so you can compare findings across iterations. Do not use this prompt as a replacement for manual QA or real-device testing; it is a design-time review tool that catches missing patterns, not runtime bugs. The next step after a clean audit is to implement the recommended patterns and verify them with automated resilience tests.