# Build and Verify an Offline Searchable Directory PWA Workflow ID: AMO-W-000036 Workflow URL: https://amo.ng/workflows/build-verify-offline-searchable-directory-pwa ## Outcome Directory and PWA change manifests, data/search/pagination contract, offline/sync state model, API regression suite, accessibility repair/verification record, cross-device test evidence, cache rollback procedure and release-owner checklist. ## Before you begin - Listing/source rights and schema - Search/filter/pagination/moderation/access requirements - Offline/sync/cache/privacy policy - API consumers/contracts - Repository and authorized tests - Accessibility baseline - Browser/device targets - CI/CD, monitoring and rollback controls ## Step 1 — Build a Searchable Directory from an Approved Listing Specification **Prompt** Build a Searchable Directory from an Approved Listing Specification **Instructions** Implement approved listing ingestion, search/filter, deterministic pagination, moderation and access boundaries. **Input for this step** Approved listing/search specification, repository, data contracts, moderation/access rules, acceptance scope. **Carry forward** Directory implementation, listing/data-state model, search/pagination tests, performance/index evidence, rollback handoff. **Review note** Stop if listing rights, source schema, access/moderation rules, repository authority, or safe test data is missing. **Prompt ID** AMO-P-000351 **Prompt URL** https://amo.ng/prompts/build-searchable-directory-approved-listing-specification **Prompt content** Implement the bounded searchable directory defined by the approved listing specification in the authorized repository. Build the approved listing ingestion, search, filters, result and detail views, access controls, and moderation behavior. Do not expand the task into a transactional marketplace, payment system, seller platform, web-scraping project, or generic application build. ## Required inputs Approved directory specification: {{approved_directory_specification}} Repository and stack context: {{repository_and_stack_context}} Listing schema and authorized data: {{listing_schema_and_authorized_data}} Search, filter, access, and moderation rules: {{search_filter_access_and_moderation_rules}} Acceptance criteria and authorized scope: {{acceptance_criteria_and_authorized_scope}} ## Evidence and assumption rules 1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite files, symbols, schema objects, data samples, commands, query plans, and test artifacts where available. 2. Do not invent listing fields, ownership, publication states, moderation rules, ranking signals, access policy, licenses, locations, prices, contact details, integrations, test results, or approval. 3. Treat the approved listing schema, authorized dataset, and search, access, and moderation rules as the implementation contract. If they conflict with the repository or each other, stop the affected path and request a decision from the product owner, data owner, content or moderation owner, and security reviewer. 4. Confirm the supplied data may be used for the directory. Do not scrape, enrich, geocode, publish, or import personal, confidential, copyrighted, or unlicensed data without explicit authority and a documented lawful and contractual basis. 5. Separate repository changes and commands actually executed from proposals and unverified expectations. Do not infer search quality, accessibility, security, or performance from code inspection alone. 6. Preserve unrelated repository and data changes. Do not replace the search stack, database, rendering framework, or moderation model unless the approved specification and authority require it. ## Authorization boundaries - Implementation requires an authorized repository, approved directory specification, exact listing schema, an authorized synthetic or sanitized dataset, explicit access and moderation states, acceptance criteria, and allowed files and commands. - Inspect only the supplied workspace, local or isolated database, fixtures, search adapter, schemas, routes, and test output. Do not imply access to a live CMS, production index, third-party data supplier, geocoding service, analytics platform, or deployment system. - Do not publish listings, import production data, send messages, activate payments, create seller accounts, change production access, call paid enrichment services, deploy, merge, or push. - Exclude checkout, orders, subscriptions, commissions, bidding, disputes, identity verification, seller onboarding, and marketplace transactions unless they are handled by a later separately approved Prompt. - Stop before destructive migrations, irreversible re-indexing, bulk data changes, new external transmissions, or actions whose ownership, privacy, cost, blast radius, or rollback is unclear. ## Repository inspection and implementation checkpoint 1. Inspect the repository structure, listing models and schemas, status and ownership rules, routes and APIs, validation, imports, storage, search/index adapter, query scopes, filters, sorting, pagination, access controls, moderation path, templates or components, metadata, tests, monitoring, and release controls that actually exist. 2. Trace one approved listing from source row through validation, normalization, persistence, moderation state, indexing, result display, detail view, update, unpublication, and removal. Identify unsupported or conflicting rules. 3. Establish an authorized baseline using synthetic or sanitized fixtures. Record current tests, query counts or plans where available, search behavior, rendering states, accessibility checks, and exact commands with actual results. 4. Before editing, present a concise checkpoint with affected files and schemas, import and index effects, state model, search and filter implementation, authorization points, test plan, rollout control, rollback, and blockers. Continue only within {{acceptance_criteria_and_authorized_scope}}. ## Implement the approved directory slice Apply the smallest coherent change set. Where applicable: 1. Implement the approved listing schema, server-side validation, normalization, stable identifiers, source provenance, ownership, visibility, moderation state, timestamps, and update/removal behavior. Use reversible migrations only when explicitly authorized. 2. Implement an idempotent fixture or authorized import path that reports accepted, rejected, duplicate, conflicted, and unchanged records without silently overwriting protected fields. 3. Implement the approved list and detail routes or interfaces. Keep Draft, rejected, suspended, expired, restricted, and future listings outside public results according to the supplied rules. 4. Implement exact approved filters, deterministic sorting with a stable tie-breaker, bounded pagination, result counts where safe, query preservation, empty states, invalid-filter handling, and canonical URL behavior. 5. Implement search using the existing approved database or search adapter. Normalize only the fields and language rules supplied. Bound query length and result size, escape output, parameterize database queries, and avoid leading-wildcard full-body scans unless explicitly justified by the approved architecture and measured evidence. 6. Enforce server-side listing and field visibility at query and detail boundaries. Do not rely on hidden controls or omitted links. Prevent direct-object access and index, cache, export, or metadata leakage. 7. Implement moderation and ownership transitions exactly as approved, including evidence, reason, owner role, and permitted next state. Do not let AI-generated content or an imported status publish a listing automatically. 8. Implement semantic headings, labelled controls, keyboard operation, visible focus, accessible result updates, responsive layouts, safe images or placeholders, and approved public metadata. Do not claim accessibility or SEO quality without checks. 9. Add bounded observability for import outcomes, search latency and errors, invalid filters, rejected records, index version, and moderation transitions without exposing confidential listing data. ## Domain-specific verification Use synthetic or authorized fixtures. Test at least: - valid, missing-field, malformed, duplicate, conflicting, stale, future, restricted, rejected, suspended, and removed listings; - repeat import, partial failure, interrupted import, rollback, and reconciliation between source, database, index, and rendered results; - exact search, no match, ambiguous terms, punctuation, excessive input, injection strings, and unsafe markup; - each filter alone, supported filter combinations, invalid values, sorting ties, page boundaries, empty pages, changed records between pages, and deterministic ordering; - authorized and unauthorized roles, direct identifiers, hidden fields, Draft detail routes, exports, caches, and search-index visibility; - moderation transitions, invalid transitions, ownership changes, stale moderator actions, and unpublication propagation; - loading, empty, unavailable-search, invalid-filter, denied, stale-index, error, and recovery states; - semantic structure, keyboard navigation, focus order, control names, contrast evidence where tooling exists, narrow-screen layout, metadata, canonical behavior, broken links, query count, query plan, and response-time or result-size thresholds. For every check, record the fixture and visibility state, identity, query or action, expected observation, exact command or procedure, actual observation, artifact, and pass, fail, blocked, or not run status. Do not present fixture coverage as proof that a production data source, search service, or moderation operation is ready. ## Failure, recovery, and stop conditions - On uncertain import or indexing completion, reconcile stable source and listing identifiers before replay. Do not create duplicates or silently publish partially processed records. - Preserve a pre-change schema and configuration record plus an authorized data or index snapshot where applicable. Document how to disable new routes or a feature flag, stop imports, restore prior code/configuration, revert only reversible schema changes, rebuild or restore the index, and verify visibility after recovery. - Stop with a blocked-handoff report if the approved specification, authorized repository, listing schema, rights-cleared data, visibility and moderation model, test environment, required dependency, or authority is missing or contradictory. - Stop if the implementation would expose unpublished or restricted records, import unlicensed data, broaden permissions, require an unapproved production index, publish listings automatically, or lack deterministic recovery. ## Output contract Return: 1. **Implementation status**: Applied and tested, Applied with gaps, Proposed only, or Blocked, with repository, environment, data authorization, and evidence limitations. 2. **Specification-to-implementation traceability**: Requirement, listing/search/moderation behavior, file and symbol, status, evidence, conflict, and owner decision. 3. **Listing lifecycle and boundary map**: State, permitted transition, owner role, public/search/API visibility, stored fields, index/cache behavior, and removal rule. 4. **Repository, schema, and configuration change manifest**: File or object, exact change, reason, applied/proposed state, data effect, test evidence, and rollback treatment. 5. **Import and reconciliation record**: Source, authorization, identifier, validation, normalization, accepted/rejected/duplicate outcomes, idempotency, database/index/result reconciliation, and unresolved records. 6. **Search and discovery implementation record**: Query handling, exact filters, sorting, pagination, access enforcement, metadata, performance evidence, and known limitations. 7. **Domain test ledger**: Scenario, fixture, identity, expected result, actual result, command or procedure, artifact, and status. 8. **Finding and residual-risk register**: Failed criteria, data-rights or privacy gaps, search limitations, moderation risks, owner, and smallest safe correction. 9. **Rollback and owner handoff**: Disablement, import stop, data/index restoration, visibility verification, and actions for product, data, moderation, security, accessibility, engineering, and release owners. 10. **Completion statement**: Separate requested, inspected, changed, executed, passed, failed, blocked, and unverified work. Do not claim publication, search quality, accessibility, security, performance, or release readiness without corresponding evidence. End with the smallest safe next action. ## Step 2 — Build an Offline-Capable Progressive Web App Feature **Prompt** Build an Offline-Capable Progressive Web App Feature **Instructions** Add one approved offline-aware, installable PWA feature to the directory. **Input for this step** Step 1 routes/data states, explicit offline/sync requirements, cache/privacy policy, device matrix. **Carry forward** Service-worker/cache change manifest, offline/sync state model, device/update tests, disablement and recovery. **Review note** Stop if offline behavior, storage sensitivity, update strategy, browser support, or safe test authority is undefined. **Prompt ID** AMO-P-000350 **Prompt URL** https://amo.ng/prompts/build-offline-capable-progressive-web-app-feature **Prompt content** Implement one approved, offline-capable Progressive Web App feature in the authorized existing web repository. Build only the supplied user journey and supporting installability, caching, storage, synchronization, and update behavior. Do not turn the task into a native application, a full application rewrite, or a store-submission project. ## Required inputs Approved PWA feature specification: {{approved_pwa_feature_specification}} Repository and browser context: {{repository_and_browser_context}} Offline data and synchronization contract: {{offline_data_and_sync_contract}} Privacy, security, and storage boundaries: {{privacy_security_and_storage_boundaries}} Acceptance criteria and authorized scope: {{acceptance_criteria_and_authorized_scope}} ## Evidence and assumption rules 1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite files, symbols, routes, browser versions, commands, reports, and captured test artifacts where available. 2. Do not invent offline requirements, synchronization policy, conflict precedence, retention rules, storage quotas, browser support, API behavior, credentials, test results, deployment state, or approval. 3. Treat the supplied feature, data, synchronization, privacy, and storage contracts as binding. If they conflict with current repository behavior, stop the affected path and request a decision from the product owner, data owner, privacy reviewer, or engineering owner. 4. Separate code and configuration actually changed from recommendations. Separate browser checks actually run from expected behavior. Do not infer offline reliability or installability from the presence of a manifest or service-worker file. 5. Use synthetic or sanitized fixtures. Never request secrets or production personal data. Do not cache authentication responses, tokens, private pages, personal data, or confidential records unless the supplied contract expressly authorizes the exact data and protection mechanism. 6. Preserve unrelated repository and configuration work. Avoid a framework replacement or broad refactor unless the approved feature cannot be implemented safely without a separately authorized decision. ## Authorization boundaries - Implementation requires an authorized repository, an approved feature specification, supported-browser targets, explicit offline and synchronization rules, safe test data, and authority over the identified files and commands. - Inspect only the supplied workspace, local browser tooling, fixtures, API contracts, build configuration, and test output. Do not imply access to production devices, app stores, live push services, production APIs, analytics accounts, or deployment systems. - Do not deploy, merge, push, submit to an application store, enable production push messages, alter production storage, register new live domains, or change DNS, hosting, analytics, or production APIs. - Do not use a broad cache-everything rule, suppress authentication checks, retain sensitive data across logout, or make destructive storage/schema changes without explicit approval and a tested migration and recovery path. - Stop before any action whose data exposure, browser blast radius, update behavior, cost, reversibility, or authorization is unclear. Record the blocked action and smallest safe alternative. ## Repository inspection and implementation checkpoint 1. Inspect the application entry points, routes, rendering model, asset build, existing manifest and service-worker code, cache headers, API clients, authentication and logout paths, client storage, synchronization logic, error handling, tests, monitoring, and release controls that are actually present. 2. Map the approved journey across online, intermittent, and offline states. Identify the minimum application shell, assets, data, mutations, and recovery behavior needed, plus every item that must remain network-only. 3. Establish an authorized baseline for build output, current tests, page behavior, accessibility, performance, and any existing service-worker registration. Record commands and actual observations without rewriting tests to hide failures. 4. Before editing, present a concise checkpoint with affected files, cache and storage boundaries, service-worker lifecycle, synchronization rules, browser matrix, test plan, rollout control, rollback, and blockers. Continue only within {{acceptance_criteria_and_authorized_scope}}. ## Implement the approved PWA feature Apply the smallest coherent repository change. Where applicable: 1. Implement or update the web app manifest with approved identity, icons already available or explicitly supplied, start URL, display behavior, theme values, scope, and installability requirements. Do not fabricate branded assets. 2. Register the service worker within the approved scope. Use deterministic cache names and versions, bounded precaching, safe runtime strategies by resource class, request and response eligibility checks, and explicit cleanup of obsolete caches. 3. Keep navigation, authenticated content, APIs, user data, third-party responses, and error responses out of caches unless the contract explicitly defines a safe strategy. Respect server authorization and do not treat cached UI as authorization. 4. Implement the approved offline user journey with clear online, offline, stale, synchronizing, conflicted, failed, storage-unavailable, and recovery states. Preserve semantic HTML, keyboard operation, focus, readable status announcements, responsive layout, and motion preferences. 5. Implement only the approved client storage and mutation queue. Define record identity, validation, ordering, retry, idempotency, expiry, encryption or exclusion rules, logout cleanup, schema upgrades, and quota behavior from supplied contracts. 6. Apply the approved synchronization and conflict policy. Do not silently overwrite newer server state. Surface unresolved conflicts with sufficient evidence for the user or accountable owner to decide. 7. Implement a controlled update lifecycle so a new worker does not unexpectedly discard in-progress work. Provide an accessible update notice or another approved activation rule, plus recovery from an incompatible cached version. 8. Add privacy-safe diagnostics for worker version, cache state, offline operations, retries, conflicts, and failures without logging sensitive content. Keep production analytics or push integration disabled. ## Domain-specific verification Use the approved browser and device matrix, local tooling, and synthetic data. Test at least: - first visit online, subsequent offline launch, refresh while offline, and navigation to a route not previously cached; - installability and launch scope in each supported browser where the environment permits it; - static-asset update, waiting-worker behavior, stale cache removal, interrupted update, and rollback to the previous release; - online-to-offline and offline-to-online transitions during reads and writes; - queued mutation ordering, duplicate submission, retry after uncertain completion, partial synchronization, and idempotent replay; - simultaneous or divergent edits according to the supplied conflict contract; - expired data, revoked access, logout, user change, storage denial, quota exhaustion, corrupt local state, and storage-schema upgrade; - API timeout, malformed response, authentication expiry, server rejection, rate limiting, and unavailable dependency; - loading, empty, offline, stale, conflict, error, and recovery announcements with keyboard and screen-reader checks; - responsive behavior, asset weight, cache size, startup behavior, and performance acceptance criteria under the supplied conditions. For every check, record the browser and version, network/storage setup, fixture, build identifier, exact command or procedure, expected result, actual result, evidence, and pass, fail, blocked, or not run status. Do not claim mobile-device, accessibility, offline, security, or performance readiness for combinations that were not exercised. ## Failure, recovery, and stop conditions - Do not replay uncertain mutations until the local operation identifier and server state have been reconciled. - Provide a bounded recovery path for a broken worker or cache: disable the feature flag where available, unregister or supersede only the affected worker, clear only owned caches and storage after preserving recoverable work, restore the prior assets, and verify the online baseline. - Stop with a blocked-handoff report if essential repository access, the approved feature, browser support policy, offline data rules, synchronization/conflict contract, privacy boundary, test tooling, or authority is absent or contradictory. - Stop if implementation would cache unauthorized content, expose data across users, discard unresolved offline work, broaden service-worker scope, require an unapproved production API change, or lack a safe update and rollback route. ## Output contract Return: 1. **Implementation status**: Applied and tested, Applied with gaps, Proposed only, or Blocked, with environment, browser coverage, data boundary, and evidence limitations. 2. **Feature-state map**: User journey step, online behavior, offline behavior, stored data, synchronization rule, error/recovery state, and acceptance criterion. 3. **Repository and configuration change manifest**: File or symbol, change, reason, applied/proposed state, cache or data effect, test evidence, and rollback treatment. 4. **Cache, storage, and synchronization contract record**: Resource or record, eligibility, lifetime, versioning, privacy rule, retry/idempotency behavior, conflict handling, and cleanup. 5. **Browser and failure test ledger**: Browser/device, scenario, setup, command/procedure, expected result, actual result, artifact, and status. 6. **Accessibility and performance evidence**: Check, tool or method, actual observation, threshold, limitation, and owner follow-up. 7. **Update and recovery procedure**: Worker activation, cache migration, feature disablement, preservation of pending work, prior-release restoration, and verification steps. 8. **Owner handoff**: Actions and decisions for the product owner, data and privacy owners, engineering owner, accessibility reviewer, and release owner. This is evidence for review, not deployment approval. 9. **Completion statement**: Separate requested, inspected, changed, executed, passed, failed, blocked, and unverified work. Do not claim installability, offline reliability, accessibility, or readiness beyond the captured browser evidence. End with the smallest safe next action. ## Step 3 — API Contract Regression Test Builder **Prompt** API Contract Regression Test Builder **Instructions** Protect final directory API request/response, auth, filtering, pagination and error contracts. **Input for this step** Actual endpoints and consumers, final code, access rules, expected contracts, authorized test scope. **Carry forward** Implemented or proposed regression tests, compatibility risks, commands/results and unresolved contract gaps. **Review note** Hold if current contract, clients, auth rules, or executable repository access is unavailable. **Prompt ID** AMO-P-000113 **Prompt URL** https://amo.ng/prompts/api-contract-regression-test-builder **Prompt content** You are a senior backend engineer specializing in API compatibility, contract testing, regression coverage, request validation, response shape protection, authentication behavior, permission checks, and client-safe endpoint changes. Your task is to design and, if approved, implement regression tests that lock down the externally visible API contract before endpoint behavior is changed. Context: Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing. * Repository context: [Repository context] * API endpoints: [API endpoints] * Current request examples: [Current request examples] * Expected responses: [Expected responses] * Validation rules: [Validation rules] * Auth requirements: [Auth requirements] * Permission rules: [Permission rules] * Known clients: [Known clients] * Existing tests: [Existing tests] * Test command: [Test command] * Compatibility constraints: [Compatibility constraints] * Planned endpoint change: [Planned endpoint change] * Allowed files: [Allowed files] Important constraints: * Do not start by changing endpoint behavior. * First inspect routes, controllers, request validators, serializers, resources, policies, middleware, API documentation, and existing tests. * Do not invent endpoints, request fields, response fields, status codes, validation rules, auth behavior, clients, or test commands. * Separate confirmed contract behavior from assumptions. * Focus tests on externally visible API behavior, not private implementation details. * Do not overfit tests to internal method names, database implementation details, or temporary code structure. * Protect success, validation, authentication, authorization, empty-state, rate-limit, pagination, sorting, filtering, and error response behavior where relevant. * Do not change unrelated endpoint behavior, API response shape, authentication, permissions, billing, database schema, frontend code, or integrations unless explicitly approved. * If the planned change intentionally breaks compatibility, clearly flag it and require human approval. * Use the existing test style and framework where possible. * Ask for approval before adding new dependencies, changing test tooling, or modifying broad shared API behavior. * If tests cannot be run, explain why and provide manual verification steps. Task: Create an API contract regression test plan. If editing is allowed, implement focused tests that protect client-facing behavior before endpoint changes are made. Output format: ### 1. API Contract Summary Summarize: * Endpoint or endpoints reviewed * Current request contract * Current response contract * Validation behavior * Authentication behavior * Permission behavior * Error behavior * Known clients or integrations * Compatibility constraints * Missing inputs ### 2. Contract Map Create a table with: * Endpoint * Method * Scenario * Required request fields * Optional request fields * Expected status code * Expected response shape * Validation or error behavior * Auth or permission requirement * Client compatibility concern ### 3. Regression Test Plan Create a focused test plan with: * Test name * Scenario protected * Why it matters * Setup required * Request example * Expected response * Assertions * Existing test file or proposed test file * Priority ### 4. Edge Cases to Protect Review relevant edge cases such as: * Missing required fields * Invalid field types * Unauthorized request * Forbidden request * Empty state * Not found state * Duplicate request * Pagination * Sorting * Filtering * Rate limit or throttling behavior * External integration assumptions * Backward compatibility risks ### 5. Implementation Notes If implementation is requested, explain: * Files to inspect * Files to change * Test style to follow * Test data or factories needed * Mocking or fixture requirements * What should not be changed * Risks from over-testing or under-testing ### 6. Client Compatibility Risks Identify: * Mobile app risks * Frontend app risks * Zapier or automation risks * Third-party integration risks * Versioning risks * Breaking-change risks * Documentation update needs * Human approval required ### 7. Verification Commands List: * Targeted test command * Full API test command * Lint or static analysis command, if relevant * Manual verification steps if tests cannot run ### 8. Final Handoff Provide: * Contract behavior protected * Tests added or recommended * Commands run * Results * Remaining assumptions * Compatibility risks * Human review checklist before endpoint changes continue Verification: Before finalizing, confirm that: * Tests assert externally visible API contracts rather than private implementation details. * Success, validation, auth, permission, and error behavior are covered where relevant. * The proposed tests are focused and not unnecessarily broad. * Known clients and compatibility constraints are considered. * Any intentional breaking change is clearly flagged for human approval. * No unrelated endpoint behavior, auth rules, permission rules, response shapes, billing logic, frontend code, or integrations are changed. * Assumptions, missing inputs, and checks a human should complete are clearly listed. Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions. ## Step 4 — Web Accessibility Regression Repair Guide **Prompt** Web Accessibility Regression Repair Guide **Instructions** Reproduce reported keyboard, focus, semantics, naming, contrast, reflow or assistive-technology regressions; repair only a confirmed defect. If no defect is reproduced, make no change and record that result. **Input for this step** Implemented directory/PWA, target accessibility baseline, reproduction evidence, approved browsers/AT and edit scope. **Carry forward** Accessibility findings and any approved repairs, automated protection, a no-change record when no defect is reproduced, the human verification matrix, and residual limitations. **Review note** Never claim accessibility conformance. If no defect is reproduced, make no change and record the evidence; retain qualified human review before release. **Prompt ID** AMO-P-000239 **Prompt URL** https://amo.ng/prompts/web-accessibility-regression-repair-guide **Prompt content** You are a senior web accessibility and frontend engineer specializing in semantic HTML, WCAG, keyboard interaction, focus management, accessible names, assistive technologies, responsive design, and regression-safe code repair. Your task is to reproduce the supplied accessibility regression, establish its user impact and technical cause, implement the smallest complete repair within the authorized files, and add durable automated and human verification. Do not treat automated audit success, one component test, or one browser and assistive-technology result as proof that an entire page, process, or product conforms to WCAG. ## Context to Provide Replace every bracketed placeholder. If critical evidence is missing, request it in one consolidated list before editing. Continue with clearly labeled assumptions only when the missing information is non-blocking. - [Repository, framework, and build context] - [Affected page, component, and user journey] - [Regression baseline and recent changes] - [Current and expected behavior] - [Reproduction steps and supplied evidence] - [Relevant source files and design-system contracts] - [Browser, operating system, viewport, and input methods] - [Assistive technology and versions] - [WCAG version, target level, and accessibility policy] - [Test tools, existing coverage, and verification commands] - [Allowed files, change boundaries, and reviewer roles] - [Definition of done] ## Evidence and Repository Rules - Inspect repository instructions, relevant files, package versions, tests, and version-control status before editing. - Preserve unrelated and pre-existing work. - Stay within the authorized files and systems. - Do not deploy, publish, push, update dependencies broadly, or change external services unless explicitly authorized. - Distinguish confirmed evidence, inference, assumption, hypothesis, unknown, risk, recommendation, and completed result. - Do not invent files, rendered behavior, accessibility-tree output, audit results, browser behavior, assistive-technology announcements, test results, owners, approvals, or WCAG findings. - Record browser, operating system, assistive technology, audit-tool, ruleset, framework, and component-library versions where available. - Use `Not provided`, `Not inspected`, `Not run`, or `Requires human verification` when evidence is unavailable. - Do not collect disability, health, or personal information that is unnecessary for reproducing the defect. - Report exact commands run, relevant results, failures, and checks that could not be performed. - If the environment cannot run a required browser or assistive technology, produce a precise human test script instead of claiming verification. - Treat automated audit results as supporting evidence rather than complete accessibility evaluation. - Do not make legal-compliance or complete WCAG-conformance claims. ## Accessibility Repair Principles - Establish the affected user task and state before changing code. - Determine whether the issue is a confirmed regression, a pre-existing defect, or unresolved because no reliable baseline exists. - Prefer native HTML elements and browser behavior where they meet the interaction requirement. - Use ARIA only when necessary, and implement the keyboard behavior, states, properties, and focus management promised by the selected role. - Do not add ARIA merely to silence an automated rule. - Do not hide visible instructions, errors, names, or status information from assistive technologies. - Do not create redundant or competing live-region announcements. - Avoid positive `tabindex` values unless an exceptional, documented requirement justifies them. - Preserve logical DOM, reading, focus, and interaction order. - Do not move focus solely because content changed. Move it only when the interaction pattern and user task require that movement. - Restore focus to a logical, available control after a dialog, popover, temporary view, or destructive action closes. - Preserve established visual intent where possible, but do not preserve styling that prevents equivalent perception or operation. - Test the complete affected task, including initial, loading, empty, error, success, disabled, expanded, validation, and responsive states where relevant. ## Required Workflow ### 1. Establish Input Sufficiency Identify: - the affected task; - the current failure; - the expected behavior; - the claimed regression baseline; - supported environments; - target WCAG version and level; - authorized files; - available test commands; - human reviewers; - blocking evidence gaps. Do not begin editing if the affected component, reproduction path, expected behavior, or permitted change scope cannot be determined safely. ### 2. Confirm the Regression Attempt to reproduce the issue using the supplied steps. Where repository history is available, inspect the relevant change, component upgrade, design-system release, content change, styling change, or dependency update. Classify the issue as: - confirmed regression; - likely regression; - pre-existing accessibility defect; - environment-specific behavior; - content or configuration defect; - unconfirmed because evidence is insufficient. Do not label the issue a regression merely because it was reported recently. ### 3. Map the Complete User Task Document the task from entry to completion, including: - entry point; - expected interaction sequence; - keyboard and pointer behavior; - focus entry, movement, visibility, and restoration; - accessible names, descriptions, roles, states, and values; - instructions and validation; - dynamic updates and status messages; - completion evidence; - escape, cancellation, and error recovery. Identify the exact step at which equivalent perception, understanding, or operation is lost. ### 4. Inspect the Technical Layers Inspect only the layers relevant to the supplied defect: - source component and templates; - rendered DOM; - browser accessibility tree; - accessible-name and description computation; - event handlers and state transitions; - CSS cascade and computed styles; - DOM, reading, visual, and focus order; - focus indicators and potential obscuring content; - validation, errors, alerts, and status messages; - responsive, zoom, reflow, localization, loading, and error states; - design-system primitives and documented interaction contracts; - recent commits or dependency changes; - existing unit, component, integration, and browser tests. Record evidence that supports and contradicts each plausible root cause. ### 5. Perform Relevant Accessibility Checks Select checks based on the affected task rather than applying every check mechanically. #### Keyboard and focus Check: - complete keyboard operability; - logical focus order; - absence of unintended keyboard traps; - visible and unobscured focus; - appropriate focus movement; - focus restoration; - escape or cancellation behavior; - keyboard behavior expected for composite widgets; - skip mechanisms and bypass options where relevant. #### Semantics and names Check: - native element choice; - role; - accessible name; - visible label; - label-in-name relationship; - description and instructions; - value and state exposure; - headings and landmarks; - form relationships; - table and list structure; - language and reading order. #### Dynamic content Check: - loading and completion feedback; - errors and validation summaries; - status messages; - expanded, selected, pressed, checked, invalid, busy, and disabled states; - dialogs, menus, disclosures, tabs, comboboxes, grids, and other applicable interaction patterns; - route or view changes; - live-region timing and duplication. #### Visual and responsive behavior Where relevant, check: - text and non-text contrast; - reliance on color alone; - text resize; - zoom and reflow; - text spacing; - orientation; - target size and spacing; - alternatives to dragging; - content shown on hover or focus; - motion and reduced-motion preferences; - focus obscured by sticky or overlapping content. #### Media and non-text content Where relevant, check: - image alternatives; - functional icons; - charts and data visualizations; - captions; - transcripts; - audio descriptions; - controls and equivalent alternatives. ### 6. Map Evidence to Standards Map the observed failure only to applicable success criteria in the supplied WCAG version. For each proposed criterion, state: - criterion number and name; - conformance level; - observed evidence; - affected user task; - rationale; - required verification; - confidence; - scope limitation. Distinguish: - confirmed failure supported by evidence; - likely applicable criterion requiring verification; - related usability improvement; - organizational policy requirement; - advisory best practice. Do not convert a component finding into a full-page, complete-process, organization-wide, or legal-compliance conclusion. ### 7. Design and Implement the Repair Identify the smallest responsible boundary: markup, component API, state management, event handling, focus management, styling, content, localization, or design-system behavior. Before editing: - explain the root cause; - identify affected files; - state the proposed behavior; - identify behavior that must remain unchanged; - compare viable alternatives; - choose native semantics where practical; - identify repair risks. When authorized, implement the smallest complete change. Avoid unrelated refactoring, dependency upgrades, formatting churn, or speculative cleanup. ### 8. Add Regression Protection Use the project’s existing test stack where possible. Add machine-testable assertions for relevant invariants such as: - semantic role and accessible name; - state and property changes; - keyboard activation; - focus destination and restoration; - error association; - status-message presence; - logical DOM order; - visible focus styles; - required attributes; - duplicate IDs; - automated accessibility rules. Prefer queries based on role, name, label, and user-visible behavior over brittle implementation selectors. Do not rely exclusively on snapshots or automated scanners. Do not attempt to automate a claim that requires human perception or assistive-technology judgment. ### 9. Define and Perform Human Verification Create a step-by-step manual test covering the complete affected task. The test matrix must identify: - browser and version; - operating system and version; - assistive technology and version; - viewport or zoom condition; - input method; - application state; - action; - expected result; - actual result; - evidence; - reviewer; - status. Only mark combinations actually tested as passed. Mark the others `Not run` or `Requires qualified human verification`. ### 10. Report Results and Prevention Report: - confirmed root cause; - implemented repair; - changed files; - automated checks run; - manual checks run; - assistive-technology checks run; - remaining untested combinations; - relevant WCAG mapping; - scope of the conclusion; - design-system or component-level prevention; - rollout or rollback considerations; - required reviewer signoff; - smallest safe next action. ## Output Format ### Input Sufficiency and Scope List supplied evidence, missing inputs, assumptions, authorized files, supported environments, target standard, blockers, and definition of done. ### Regression Snapshot Use: | Field | Finding | |---|---| | Affected task | | | Failing step and state | | | Current behavior | | | Expected behavior | | | Baseline evidence | | | Regression classification | | | User impact | | | Scope limitation | | ### Reproduction Evidence Provide exact reproduction steps, observed results, environment details, and evidence references. Clearly identify steps that were not run. ### Root-Cause Analysis Use: | Hypothesis | Evidence for | Evidence against | Verification check | Result | Confidence | |---|---|---|---|---|---| ### Accessibility and Standards Mapping Use: | User need or barrier | WCAG criterion | Level | Evidence | Status | Verification | Scope limitation | |---|---|---|---|---|---|---| ### Repair and Changed Files Explain the selected repair, alternatives considered, files changed, behavior preserved, risks, and rollback method. Include the focused patch or implementation when authorized. ### Automated Regression Protection List each automated assertion, its test level, command, result, coverage, and limitation. ### Human Verification Matrix Use: | Browser and AT | Viewport or zoom | Input | State and action | Expected result | Actual result | Reviewer | Status | |---|---|---|---|---|---|---|---| ### Verification Results Separate: 1. Passed checks 2. Failed checks 3. Not-run checks 4. Checks requiring qualified human review ### Residual Risks and Prevention Document untested combinations, remaining barriers, design-system improvements, content guidance, ownership, and follow-up work. ### Final Handoff Provide: - changed-file summary; - commands and results; - human review required; - conformance-claim limitation; - rollout or rollback note; - smallest safe next action. ## Verification Checklist Before finalizing, confirm that: - the affected user task and failing state are explicit; - the issue is classified accurately as a confirmed regression, likely regression, pre-existing defect, environment-specific issue, or unconfirmed; - current and expected behavior are supported by evidence; - native semantics were preferred where suitable; - every ARIA role is paired with its required interaction behavior; - accessible names, roles, states, values, instructions, errors, and status updates were checked where relevant; - keyboard operation, focus order, focus visibility, obscuring, movement, and restoration were evaluated; - responsive, zoom, reflow, localization, loading, error, and success states were considered where relevant; - automated results are not presented as complete accessibility evaluation; - no screen-reader or assistive-technology check is described as completed unless it was actually performed; - WCAG mappings identify the version, criterion, level, evidence, confidence, and scope; - no component repair is presented as full-page, complete-process, legal, or product-wide conformance; - unrelated repository changes were preserved; - every command and test result is reported accurately; - remaining limitations and human review requirements are explicit; - the final next action is the smallest safe step that materially reduces accessibility risk. ## Final Instruction to Begin Begin by reviewing the supplied context and repository for blocking gaps. If any exist, request them in one consolidated list. Otherwise, reproduce and classify the regression before making the smallest authorized repair. ## Step 5 — Production Test and Verification Plan Prompt **Prompt** Production Test and Verification Plan Prompt **Instructions** Build the final risk-based verification record across online/offline, search, sync, API and accessibility behavior. **Input for this step** Complete change set and prior test records, acceptance criteria, device/runtime and CI context. **Carry forward** Consolidated test results, unrun checks, regression gaps, observability and rollback evidence. **Review note** Hold if critical device/offline/search cases or actual execution evidence is absent. **Prompt ID** AMO-P-000010 **Prompt URL** https://amo.ng/prompts/test-and-verification-prompt **Prompt content** Build a risk-based test and verification plan for the following software change or release. Inputs - Change or release under test: [Change or release under test] - Repository and relevant files: [Repository and relevant files] - System and runtime context: [System and runtime context] - Acceptance criteria: [Acceptance criteria] - Test and deployment constraints: [Test and deployment constraints] - Available evidence: [Available evidence] - Authorized actions and environment: [Authorized actions and environment] - CI/CD and rollback context: [CI/CD and rollback context] Codex operating boundaries - Use Codex to inspect supplied repository content, diffs, configuration, test suites, CI definitions, logs, and command output that are actually available in the session. - Run tests or read additional files only when the environment provides that capability and the authorized-actions input permits it. Prefer targeted, read-only inspection before expensive or state-changing commands. - Do not deploy, merge, approve a release, alter production, access undeclared systems, expose secrets, create real customer data, disable safeguards, or run destructive commands. Treat migrations, load tests, security probes, external API calls, and commands that write or delete data as approval-gated. - Stop before an action if its target, blast radius, data handling, cost, reversibility, or authorization is unclear. Record the blocked action, required approval, and a safe alternative. - Never imply that a command ran merely because it was proposed. Never claim that code is fixed, tests passed, coverage improved, a release was approved, a rollback works, or a deployment completed without corresponding execution evidence. Input and evidence rules 1. Treat the change target, acceptance criteria, repository or equivalent technical artifacts, runtime context, and authority scope as prerequisites for an execution-backed assessment. If one is missing, ask only the questions necessary to unblock it. 2. If execution is blocked but supplied artifacts are sufficient, produce a bounded plan and mark execution-dependent conclusions unverified. If the change boundary or acceptance criteria cannot be established, do not issue a release-confidence recommendation. 3. Maintain an evidence ledger that distinguishes supplied facts, direct Codex observations, command execution evidence, assumptions, hypotheses, conflicts, and unknowns. Cite file paths, symbols, diff locations, log excerpts, CI job names, test identifiers, commands, exit codes, or artifact locations where available. 4. Do not resolve conflicting documentation, code behavior, logs, or requirements by guessing. Describe the conflict, its verification impact, and who must resolve it. 5. Do not infer test success from the existence of test files, infer production behavior solely from mocks, or equate code coverage with behavioral correctness. Assessment workflow 1. Establish scope and baseline - Identify changed components, interfaces, dependencies, data stores, feature flags, configuration, infrastructure, schemas, jobs, and user journeys. - Determine the comparison baseline and whether generated files, lockfiles, migrations, API contracts, or deployment manifests changed. - Record exclusions and distinguish intentional scope limits from unavailable evidence. 2. Perform change-impact and risk analysis - Trace affected call paths, consumers, upstream and downstream integrations, shared libraries, background work, cache behavior, concurrency boundaries, and compatibility requirements. - Rate each material risk by likelihood and impact. Include regression, data integrity, authorization, privacy, availability, performance, observability, backward compatibility, migration, retry or idempotency, and rollback risks when relevant. - Prioritize tests by risk reduction rather than test count. 3. Build acceptance traceability - Decompose each acceptance criterion into observable behavior. - Map it to one or more unit, component, integration, contract, end-to-end, migration, security, performance, resilience, or manual checks as appropriate. - Define setup, fixtures or test data, action, expected result, required evidence, cleanup, and ownership for every check. - Include negative paths and boundaries such as empty, null, malformed, duplicate, maximum-size, timeout, partial-failure, retry, race, permission-denied, stale-cache, and dependency-unavailable conditions where applicable. 4. Evaluate existing verification assets - Identify relevant tests and assess whether their assertions prove the required behavior rather than merely execute code. - Detect missing assertions, over-mocking, nondeterministic time or randomness, shared-state leakage, order dependence, brittle snapshots, unsafe fixtures, hidden network access, and flaky retries. - Review CI triggers, path filters, matrices, service dependencies, caches, artifacts, timeouts, required checks, branch protections, and failure propagation for gaps that could produce false confidence. 5. Specify the verification sequence - Order checks from fast and isolated to broad and operational: static checks, targeted unit tests, component or integration tests, contracts, migrations, end-to-end paths, non-functional checks, and manual exploration. - Provide exact commands only when supported by repository evidence. Otherwise label commands as proposed and identify what must be confirmed. - Separate blocking release gates from advisory checks. Define retry policy, flaky-test handling, artifact retention, test-data cleanup, and ownership of failures. 6. Execute only authorized checks - Before each command, state its purpose, environment, expected side effects, and why it is within authority. - Capture the exact command, working directory, relevant environment details with secrets redacted, start and finish state, exit code, actual observation, and artifact reference. - Do not silently rewrite code or tests to make checks pass. If modification is expressly authorized, present the proposed patch and its rationale separately, then verify it with fresh evidence. - Classify each check as passed, failed, blocked, not run, or inconclusive. A zero exit code is not sufficient when assertions, logs, skipped-test counts, or produced artifacts contradict success. 7. Assess deployment and recovery readiness - Verify pre-deployment prerequisites, configuration compatibility, secret references without revealing values, migration ordering, backward and forward compatibility, feature-flag behavior, health checks, and capacity assumptions where relevant. - Define post-deployment smoke tests and observability signals with query or dashboard source, baseline, threshold, observation window, and owner. Cover errors, latency, saturation, queue lag, data reconciliation, and key business behavior as applicable. - Specify rollback or roll-forward triggers, decision owner, procedure reference, data consequences, compatibility limits, recovery verification, and cases where rollback is unsafe, such as irreversible schema or data transformations. 8. Reconcile evidence and determine confidence - Reconcile every acceptance criterion, risk, test result, defect, skipped check, and conflicting observation. - Recommend exactly one state: Ready, Conditionally ready, Not ready, or Unassessed. This is a technical recommendation, not release approval. - Ready requires all blocking criteria to have passing evidence and no unresolved release-blocking defect or unknown. Conditionally ready requires explicit conditions, owners, and deadlines. Not ready requires named blockers. Unassessed applies when evidence is insufficient to support a conclusion. Required deliverable A. Scope and evidence ledger - Change boundary, baseline, affected systems, exclusions, authority scope, and environment. - Evidence table with ID, classification, source or artifact, observation, reliability limitation, and related conclusion. - Assumptions, unknowns, and conflicts, each with impact and resolution owner. B. Change-impact and risk register - Component or behavior, change mechanism, dependent systems, failure mode, likelihood, impact, detectability, risk priority, proposed control, and residual risk. C. Acceptance-to-test matrix - Criterion ID, observable behavior, risk covered, test level, setup and data, procedure or command, expected observation, required evidence, cleanup, owner, priority, and status. D. Existing test and CI assessment - Relevant test or job, what it proves, identified gap, flakiness or isolation concern, CI gate status, and recommended correction. E. Execution record - Check ID, proposed or executed state, exact command or manual procedure, environment, expected observation, actual observation, exit code when applicable, duration when known, evidence reference, and result classification. F. Defect and unresolved-work register - Defect or gap ID, reproduction evidence, affected criterion, severity, release impact, workaround, owner, and retest requirement. Keep proposed fixes separate from applied changes. G. Deployment, observability, and recovery checks - Pre-deployment gates, smoke tests, monitored signals, baselines and thresholds, observation windows, rollback or roll-forward triggers, recovery procedure references, data reconciliation, and responsible approvers. H. Verification verdict - Recommended state, evidence-backed rationale, passed blocking gates, failed or missing gates, residual risks, approval still required, and the smallest safe next action. Use concise technical language. Preserve unresolved states and make every consequential conclusion traceable to evidence. ## Step 6 — CI/CD Deployment Safety Checklist Generator **Prompt** CI/CD Deployment Safety Checklist Generator **Instructions** Prepare controlled deployment, cache/service-worker rollback, monitoring, and release-owner gates. **Input for this step** Final implementation/test evidence, CI/CD, cache/version strategy, rollback and monitoring plan. **Carry forward** Release checklist, blockers, staged rollout, rollback triggers, post-release checks and owner decision. **Review note** Do not release without safe service-worker rollback, cache invalidation, observability, and accountable approval. **Prompt ID** AMO-P-000116 **Prompt URL** https://amo.ng/prompts/ci-cd-deployment-safety-checklist-generator **Prompt content** Review the supplied release materials and produce an evidence-traceable CI/CD deployment safety assessment. Use Codex to inspect the repository and only files, text, command output, and repository context that are actually supplied or available in the current session. Do not imply access to a repository, CI provider, cloud account, secrets store, database, monitoring system, or production environment unless that access is demonstrably available. Inputs Repository and release scope: [Repository and release scope] Pipeline and deployment artifacts: [Pipeline and deployment artifacts] Platform and environment topology: [Platform and environment topology] Migration and stateful workload details: [Migration and stateful workload details] Verification and observability evidence: [Verification and observability evidence] Rollback and governance requirements: [Rollback and governance requirements] Input expectations The repository and release scope should identify the change set, affected services, release reference, critical user flows, external dependencies, and known high-risk changes such as billing, authentication, authorization, data deletion, or infrastructure changes. Pipeline and deployment artifacts should include relevant workflow files, reusable workflows, deployment scripts, manifests, infrastructure definitions, build configuration, test commands, and release instructions. Platform and environment topology should describe environments, promotion flow, deployment strategy, runtime components, regions, traffic routing, queues, caches, scheduled jobs, and secret or identity mechanisms without exposing secret values. Migration and stateful workload details should cover schema and data migrations, compatibility assumptions, expected duration, locking risk, backups, restoration, and interactions with workers or older application versions. Verification and observability evidence should provide health checks, smoke tests, dashboards, alerts, logs, service-level indicators, prior command output, and acceptance thresholds. Rollback and governance requirements should identify rollback or roll-forward procedures, approval owners, change windows, incident contacts, communication requirements, and the release definition of done. Input and evidence rules 1. Create an input ledger before drawing conclusions. Classify each needed item as supplied, observed in an accessible artifact, conflicting, missing, or not applicable. Cite file paths and line ranges when available; otherwise cite the supplied input section or evidence item. 2. Never invent workflow behavior, provider settings, branch protection, environment rules, test outcomes, secret values, migration reversibility, backup validity, monitoring coverage, approvals, or production state. 3. If inputs conflict, record both claims, identify their sources, explain the safety consequence, and request the authoritative source. Do not silently choose one. 4. If a critical fact is missing, mark the affected conclusion unverified and make the release disposition Blocked when safe deployment depends on that fact. Noncritical gaps may receive a clearly labeled conservative hypothesis, but a hypothesis is not evidence. 5. Treat documentation as evidence of an intended process, not proof that a control ran. Treat configuration as evidence of a configured control, not proof of successful execution. Treat logs, CI run records, signed approvals, artifact metadata, command output, or monitoring observations as execution evidence only when their source and release relevance are supplied. 6. Use these work-state labels consistently: Requested for work the user asked for; Proposed for changes or commands not applied; Executed only for an action actually performed in the current session; Unavailable when access or capability is absent; Unverified when evidence is insufficient. Every claim that something was tested, fixed, deployed, rolled back, approved, or verified must include execution evidence. Otherwise label it Proposed or Unverified. 7. Bind every material piece of evidence to the exact release under review. A passing test, approval, artifact, log entry, monitoring observation, or prior deployment from another commit, branch, artifact digest, environment, configuration state, or execution window is not evidence for this release unless a traceable relationship is supplied. Record the commit, release reference, artifact identity, target environment, and evidence timestamp where available. Authority and safeguards Unless [Rollback and governance requirements] expressly restrict access, permit read-only repository inspection and non-mutating diagnostics within the workspace actually available to Codex. Treat file edits, mutating commands, pipeline or configuration changes, database writes or migrations, secret rotation, infrastructure changes, deployment, rollback, production access, and external side effects as unauthorized unless expressly approved. Do not deploy, merge, approve, rotate secrets, alter infrastructure, run migrations, modify production data, disable controls, or trigger rollback. If a read-only check against a production target is expressly authorized and Codex has demonstrable access, limit it to a clearly non-mutating command against the stated target. Record the exact command, target, exit status, relevant output, time, and limitations. Never run destructive, state-changing, costly, financially consequential, or irreversibly production-affecting commands within this prompt. Otherwise provide commands as Proposed and do not fabricate output. Do not reproduce secret values, tokens, credentials, private keys, customer data, or sensitive log content. Refer to secret names or redacted identifiers only. Flag excessive permissions, untrusted code paths with secret access, unsafe pull-request triggers, command injection surfaces, unpinned third-party actions, mutable artifacts, and credential persistence. Human approval remains mandatory for production release decisions and for changes involving billing, identity, permissions, security controls, destructive data operations, non-backward-compatible migrations, or infrastructure replacement. Focused review workflow 1. Trace the failure modes and map the delivery path from source trigger to production: event and branch or tag filters, pull-request trust boundary, build, tests, artifact creation, provenance or digest handling, promotion, environment selection, deployment, verification, and rollback. Identify reusable workflows and dependencies that can alter this path. 2. Inspect trigger and concurrency safety. Check accidental production triggers, skipped required jobs, path-filter blind spots, duplicate deployments, cancellation behavior, race conditions, environment locks, release serialization, and whether the deployed commit or artifact is uniquely identified. 3. Inspect identity, permissions, and supply-chain controls. Check least-privilege workflow permissions, OIDC or credential scope where evidenced, secret availability by event and environment, masking and log exposure, dependency or action pinning, artifact integrity, provenance, retention, and separation between build and deploy authority. 4. Inspect build and test gates. Trace dependency installation, lockfile enforcement, deterministic builds, static checks, unit and integration tests, security checks where required, failure propagation, retry behavior, test exclusions, coverage of critical flows, and whether the exact promoted artifact passed the cited checks. 5. Inspect environment and deployment correctness. Check staging-to-production parity, configuration validation, immutable artifact promotion, deployment strategy, traffic shifting, readiness versus liveness semantics, timeout behavior, partial failure across services or regions, infrastructure ordering, external API dependencies, maintenance requirements, and idempotency of repeated deployment attempts. 6. Inspect migration and stateful-component safety. Evaluate expand-and-contract compatibility, application and migration order, mixed-version operation, transaction and lock behavior, table rewrites, long-running backfills, retry and resume behavior, data validation, queue payload compatibility, worker draining, cron overlap, cache-key or serialization changes, backup freshness, restore evidence, and whether rollback would leave code and schema compatible. Treat an unproven destructive or irreversible migration as a blocking risk. 7. Inspect observability and release control. Check that health endpoints test meaningful dependencies without leaking data; smoke tests cover critical user journeys; dashboards and alerts identify error rate, latency, saturation, queue lag, failed jobs, database health, and business-critical signals; thresholds, observation windows, owners, and escalation paths are defined. 8. Build rollback and roll-forward logic. Define measurable triggers, decision owner, last known good artifact, code and configuration restoration, schema mitigation, traffic restoration, queue and cache handling, external side-effect reconciliation, user communication, and post-recovery verification. Do not call rollback viable without evidence that required artifacts, procedures, permissions, and schema compatibility exist. 9. Prioritize findings using impact and likelihood rated Low, Medium, High, or Critical. Distinguish release blockers from required follow-ups and optional hardening. Prefer the smallest control that materially reduces the identified risk; do not recommend broad platform rewrites without evidence that they are necessary. Base impact and likelihood on release-specific evidence. Do not infer likelihood solely from generic industry experience or the theoretical existence of a failure mode. When the available evidence cannot support a defensible likelihood rating, mark likelihood Unverified, explain the uncertainty, and state what evidence is needed. Output contract: required CI/CD safety deliverable Produce the following task-specific sections in markdown. A. Review basis and evidence ledger Provide a table with Evidence ID, item or artifact, source locator, relevance to this release, evidence class, and status. Evidence class must distinguish intended process, static configuration, and execution evidence. Follow it with missing and conflicting inputs, their consequences, and the exact evidence needed to resolve each one. B. Delivery-path map Describe the evidenced path from trigger to production in order. For every stage list trigger or input, responsible workflow or script, output artifact or state transition, environment, controlling gate, and evidence ID. Mark inferred or unknown transitions explicitly. C. Risk register Provide Finding ID, delivery stage, failure mode, supporting evidence IDs, impact, likelihood, severity, affected environment or service, release consequence, required mitigation, owner or approver if supplied, and state. Include concrete findings for triggers, permissions, secrets, artifact integrity, tests, environment drift, deployment ordering, migrations, stateful workers, health checks, monitoring, and rollback when relevant. Do not create findings unsupported by the supplied architecture; record missing evidence instead. D. Release gate checklist Create ordered Pre-deployment, Deployment, and Post-deployment gates. Each checklist row must contain Gate ID, check, reason, execution target, method or proposed command, expected observation, supplied actual observation, evidence ID, pass criterion, stop or pause condition, responsible human, and state. Leave actual observation as Not supplied unless real output exists. Commands must identify assumptions and must not expose secrets or mutate production. Include, where applicable, confirmation of the exact commit and immutable artifact; required CI results; configuration-key presence without values; environment and identity target; backup and restoration evidence; backward-compatible migration sequence; worker, queue, cache, and scheduler coordination; approval and communication gates; deployment progress; health and readiness; critical API and user-flow smoke tests; error, latency, saturation, queue, database, and business-signal thresholds; and an observation window. E. Migration and stateful-workload decision record State the proposed sequence for application versions, schema changes, backfills, workers, queues, caches, and scheduled jobs. Document compatibility across old code, new code, old schema, and new schema; lock and duration concerns; abort criteria; backup or restoration prerequisites; data-integrity reconciliation; and rollback versus roll-forward constraints. For each conclusion cite evidence or mark it Unverified. F. Rollback readiness record Provide rollback trigger, decision owner, code or artifact action, configuration action, database mitigation, traffic action, queue and cache handling, external side-effect reconciliation, communications, verification check, expected observation, and evidence. Identify the point after which rollback becomes unsafe and a roll-forward is required. Mark readiness Unverified if no tested procedure or equivalent execution evidence is supplied. G. Verification plan and evidence requirements For each proposed verification, give the exact non-destructive command or manual action, target environment, prerequisite, expected observation, acceptance threshold, failure interpretation, evidence to retain, and current work state. Reconcile the deployed release identity with the reviewed commit and artifact digest. Reconcile migration version and data checks with the expected release state. Reconcile health and smoke-test results with monitoring over the stated observation window. Never populate actual results unless they were supplied or executed with recorded evidence. H. Release disposition Choose exactly one disposition: Blocked, Conditional candidate for human approval, or Ready for human approval. This is advice, not approval or authorization to deploy. List the decisive evidence, unresolved blockers, conditions that must be satisfied, required human gates, monitoring obligations, and safest next action. A disposition of Ready for human approval requires traceable evidence that required tests passed for the reviewed release artifact, the deployment target is identified, migration and configuration prerequisites are satisfied, meaningful health and smoke checks have acceptance thresholds, observability and escalation are active, and rollback or roll-forward is operationally credible. If any required evidence is missing, use Blocked or Conditional candidate for human approval. Keep every section concise and proportional to the release’s actual scope and risk. Do not repeat the same evidence across multiple sections unnecessarily. Where a section or control area is genuinely not applicable, retain the heading, state Not applicable, and explain briefly why using the supplied release evidence. Never omit the evidence ledger, risk register, release gates, release disposition, or completion-integrity distinctions. Final integrity check Before returning the deliverable, confirm that every material conclusion cites evidence or is marked Unverified; every proposed command has a target and expected observation; every completion claim has execution evidence; no secret value appears; migration, stateful components, artifact identity, monitoring, and rollback were addressed when applicable; and the disposition does not exceed the available evidence or human authority. ## Completion criteria Listing ingestion and access are authorized; search/pagination are deterministic; online/offline/update/sync failures are tested; API behavior remains compatible; confirmed accessibility defects are fixed or block release; cache/service-worker rollback and monitoring are observable; no deployment is claimed.