@raishin/vanguard-frontier-agentic 3.2.0 → 3.3.0

package/catalog/skills.json

@@ -4294,6 +4294,33 @@
     "version": "0.1.0",
     "author": "github: Raishin"
   },
+  {
+    "id": "composer-audit-supply-chain-review",
+    "name": "Composer Audit & Supply-Chain Review",
+    "type": "skill",
+    "provider": "php",
+    "harnesses": [
+      "claude-code",
+      "cursor",
+      "codex",
+      "gemini",
+      "kiro",
+      "other"
+    ],
+    "summary": "Skill for reviewing Composer dependency supply-chain posture: composer audit advisory scanning and CI exit-code gating, config.policy advisory/abandoned settings, and composer.lock integrity and drift, so a vulnerable or abandoned Packagist dependency cannot reach production ungated.",
+    "source_type": "original",
+    "official_docs": [
+      "https://getcomposer.org/doc/03-cli.md",
+      "https://getcomposer.org/doc/06-config.md",
+      "https://getcomposer.org/doc/01-basic-usage.md",
+      "https://owasp.org/www-project-top-ten/"
+    ],
+    "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no network mutation. Never installs, updates, or requires packages. Reports composer audit posture from configuration and lockfile evidence, never fabricates advisory identifiers, and treats any credential in auth.json or configuration as a redact-and-flag finding.",
+    "last_verified": "2026-07-16",
+    "path": "skills/php/composer-audit-supply-chain-review",
+    "version": "0.1.0",
+    "author": "github: Raishin"
+  },
   {
     "id": "consolidation-intercompany-advisor",
     "name": "Consolidation & Intercompany Advisor",
@@ -13606,6 +13633,86 @@
     "version": "0.1.0",
     "author": "github: Raishin"
   },
+  {
+    "id": "php-maestro",
+    "name": "PHP Maestro",
+    "type": "skill",
+    "provider": "php",
+    "harnesses": [
+      "claude-code",
+      "cursor",
+      "codex",
+      "gemini",
+      "kiro",
+      "other"
+    ],
+    "summary": "Routing skill for the PHP board: classifies an incoming PHP task and dispatches to the narrowest specialist (application security, Composer supply-chain, runtime/EOL and OPcache/FPM, or WordPress security), caps parallel dispatch, enforces the blocking hard-gate taxonomy, and refuses live-mutation requests.",
+    "source_type": "original",
+    "official_docs": [
+      "https://www.php.net/docs.php",
+      "https://www.php.net/supported-versions.php",
+      "https://getcomposer.org/doc/03-cli.md",
+      "https://developer.wordpress.org/apis/security/"
+    ],
+    "security_notes": "Routing only; performs no review and makes no code changes. Refuses destructive/live-mutation requests and requires human confirmation. Never fabricates a routing target outside the registered PHP board, preserves specialist evidence labels, and never requests or echoes secrets or customer data.",
+    "last_verified": "2026-07-16",
+    "path": "skills/php/php-maestro",
+    "version": "0.1.0",
+    "author": "github: Raishin"
+  },
+  {
+    "id": "php-runtime-eol-opcache-fpm-review",
+    "name": "PHP Runtime EOL, OPcache & PHP-FPM Review",
+    "type": "skill",
+    "provider": "php",
+    "harnesses": [
+      "claude-code",
+      "cursor",
+      "codex",
+      "gemini",
+      "kiro",
+      "other"
+    ],
+    "summary": "Skill for reviewing PHP runtime upgrade readiness and production hardening: EOL and security-only version exposure against php.net's four-year support lifecycle, OPcache production configuration (validate_timestamps, memory sizing), and PHP-FPM pool tuning (pm, max_children, max_requests), treating an EOL runtime as a blocking finding.",
+    "source_type": "original",
+    "official_docs": [
+      "https://www.php.net/supported-versions.php",
+      "https://www.php.net/manual/en/opcache.configuration.php",
+      "https://www.php.net/manual/en/install.fpm.configuration.php"
+    ],
+    "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no configuration changes. PHP version lifecycle dates are encoded only from php.net's supported-versions page as fixed ground truth (never invented, rounded, or extrapolated); a version's current lifecycle phase is determined by comparing those published dates against the review date.",
+    "last_verified": "2026-07-16",
+    "path": "skills/php/php-runtime-eol-opcache-fpm-review",
+    "version": "0.1.0",
+    "author": "github: Raishin"
+  },
+  {
+    "id": "php-session-upload-deserialization-review",
+    "name": "PHP Session, Upload & Deserialization Security Review",
+    "type": "skill",
+    "provider": "php",
+    "harnesses": [
+      "claude-code",
+      "cursor",
+      "codex",
+      "gemini",
+      "kiro",
+      "other"
+    ],
+    "summary": "Skill for reviewing PHP application-security seams: user-reachable unserialize() object injection (allowed_classes is insufficient), session fixation/hijacking hardening (session_regenerate_id, use_strict_mode, cookie flags), and unsafe file-upload handling, each mapped to an OWASP category and the php.net-documented fix.",
+    "source_type": "original",
+    "official_docs": [
+      "https://www.php.net/manual/en/function.unserialize.php",
+      "https://www.php.net/manual/en/session.security.php",
+      "https://www.php.net/manual/en/features.file-upload.common-pitfalls.php",
+      "https://owasp.org/www-project-top-ten/"
+    ],
+    "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no network. Never runs deserialization payloads, uploads, or exploits against any live or staging system. Any credential- or PII-shaped string is a redact-and-flag finding, never echoed. Every unserialize()/session/upload claim is grounded in current php.net documentation, not memory.",
+    "last_verified": "2026-07-16",
+    "path": "skills/php/php-session-upload-deserialization-review",
+    "version": "0.1.0",
+    "author": "github: Raishin"
+  },
   {
     "id": "playwright-e2e-execution-run",
     "name": "Playwright E2E Execution Run",
@@ -14062,6 +14169,35 @@
     "version": "0.1.0",
     "author": "github: Raishin"
   },
+  {
+    "id": "revenue-critical-journey-integrity-review",
+    "name": "Revenue-Critical Journey Integrity Review",
+    "type": "skill",
+    "provider": "generic",
+    "harnesses": [
+      "claude-code",
+      "cursor",
+      "codex",
+      "gemini",
+      "kiro",
+      "other"
+    ],
+    "summary": "Skill for reviewing the cross-tier seams of revenue-critical journeys (checkout, payment, account creation, login): idempotency of money-moving and account-creating requests, server-side re-validation of client-enforced rules, webhook duplicate/out-of-order handling, retry-storm safeguards, and advisory PCI DSS SAQ-scope judgment for the integration model in use.",
+    "source_type": "original",
+    "official_docs": [
+      "https://docs.stripe.com/api/idempotent_requests",
+      "https://docs.stripe.com/webhooks/best-practices",
+      "https://www.pcisecuritystandards.org/faqs/1443/",
+      "https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a",
+      "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html",
+      "https://baymard.com/lists/cart-abandonment-rate"
+    ],
+    "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no network egress to any payment system. Never requests, transmits, stores, or reproduces cardholder data (PAN/CVV), API keys, session tokens, or webhook signing secrets — any such string is a redact-and-flag finding, never echoed. PCI DSS SAQ-scope output is an advisory scoping opinion to inform a Qualified Security Assessor or the merchant's own validation, never a compliance attestation or assessment of record. Never executes payment flows or replays webhooks against live, sandbox, or staging systems.",
+    "last_verified": "2026-07-16",
+    "path": "skills/cross-functional/revenue-critical-journey-integrity-review",
+    "version": "0.1.0",
+    "author": "github: Raishin"
+  },
   {
     "id": "revenue-recognition-advisor",
     "name": "Revenue Recognition Advisor",
@@ -17996,6 +18132,33 @@
     "version": "0.1.0",
     "author": "github: Raishin"
   },
+  {
+    "id": "wordpress-rest-block-security-review",
+    "name": "WordPress REST & Block Security Review",
+    "type": "skill",
+    "provider": "php",
+    "harnesses": [
+      "claude-code",
+      "cursor",
+      "codex",
+      "gemini",
+      "kiro",
+      "other"
+    ],
+    "summary": "Skill for reviewing WordPress plugin and theme security: REST register_rest_route permission_callback enforcement (required since WordPress 5.5) and nonce/capability checks, dynamic-block render_callback output escaping, and the validate-on-input, escape-on-output discipline behind the plugin-dominated WordPress CVE surface.",
+    "source_type": "original",
+    "official_docs": [
+      "https://developer.wordpress.org/apis/security/",
+      "https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/",
+      "https://developer.wordpress.org/block-editor/getting-started/fundamentals/static-dynamic-rendering/",
+      "https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/"
+    ],
+    "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no live WordPress access. Flags missing permission_callback, unescaped output, and missing nonce/capability checks from source only; treats any credential- or PII-shaped string as a redact-and-flag finding; grounds REST and block-editor API claims in current developer.wordpress.org documentation.",
+    "last_verified": "2026-07-16",
+    "path": "skills/php/wordpress-rest-block-security-review",
+    "version": "0.1.0",
+    "author": "github: Raishin"
+  },
   {
     "id": "working-capital-advisor",
     "name": "Finance Working Capital Advisor",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@raishin/vanguard-frontier-agentic",
-  "version": "3.2.0",
+  "version": "3.3.0",
   "description": "Cloud and zero-trust agentic workflow marketplace for skills, agents, rules, MCP references, and compliance-aware architecture.",
   "license": "Apache-2.0",
   "repository": {

package/plugins/vanguard-frontier-agentic/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vanguard-frontier-agentic",
-  "version": "3.2.0",
+  "version": "3.3.0",
   "description": "Curated marketplace for cloud and zero-trust AI workflows. 331 agents, 286 skills, and rules across AWS, Azure, OCI, GCP, Alibaba Cloud, Huawei Cloud, Kubernetes, and Terraform.",
   "author": {
     "name": "Raishin",

package/powers/README.md

@@ -1,6 +1,6 @@
 # `powers/` — Kiro Powers
 
-This directory holds **40 Kiro Powers** for `vanguard-frontier-agentic`, one
+This directory holds **41 Kiro Powers** for `vanguard-frontier-agentic`, one
 per cloud/platform/IaC provider. Each Power is a directory containing a
 `POWER.md` file with strict-5 frontmatter and steering content.
 
@@ -41,6 +41,7 @@ powers/
 ├── vanguard-oci/POWER.md
 ├── vanguard-opentelemetry/POWER.md
 ├── vanguard-ovhcloud/POWER.md
+├── vanguard-php/POWER.md
 ├── vanguard-prometheus/POWER.md
 ├── vanguard-salesforce/POWER.md
 ├── vanguard-sap/POWER.md
@@ -84,7 +85,7 @@ cd vanguard-frontier-agentic
 ## How to update
 
 ```bash
-# Regenerate the 40 Powers from catalog/agents.json + per-provider config:
+# Regenerate the 41 Powers from catalog/agents.json + per-provider config:
 npm run kiro-powers:write
 
 # Then verify everything is in sync:

package/powers/vanguard-generic/POWER.md

@@ -32,7 +32,7 @@ Live-guard agents enforce approval, target confirmation, evidence capture, and r
 
 ## Where the agents live
 
-Agent specs and adapters are part of the [Vanguard Frontier Agentic](https://github.com/Raishin/vanguard-frontier-agentic) marketplace. For this provider, see `agents/generic/` in that repository. 9 of 10 agents in this provider ship a Kiro adapter; the rest provide steering context only.
+Agent specs and adapters are part of the [Vanguard Frontier Agentic](https://github.com/Raishin/vanguard-frontier-agentic) marketplace. For this provider, see `agents/generic/` in that repository. 10 of 11 agents in this provider ship a Kiro adapter; the rest provide steering context only.
 
 ## Companion install paths
 

package/powers/vanguard-php/POWER.md

@@ -0,0 +1,40 @@
+---
+name: "vanguard-php"
+displayName: "Vanguard Frontier — Php"
+description: "Curated Php agents for composer supply chain, php application security, php runtime upgrade readiness, wordpress security. Routes via php-maestro-agent to specialist agents based on task scope. Static review only; no live mutations."
+keywords: ["php", "static-review", "configuration-audit", "best-practices"]
+author: "Raishin"
+---
+# Vanguard Frontier — Php
+
+Curated Php agents for composer supply chain, php application security, php runtime upgrade readiness, wordpress security. Routes via php-maestro-agent to specialist agents based on task scope. Static review only; no live mutations.
+
+## When to engage this Power
+
+Activate when the task references Php services, resources, or operations. Do not activate on unrelated requests — narrow keyword matching is required to avoid false activations (Kiro Powers convention).
+
+## Routing pattern
+
+- **`php-maestro-agent`** — classifies and routes the task to the right specialist
+
+Use the maestro as the entry point: classify the task, then dispatch to one specialist or a parallel team of specialists. Never have the maestro itself execute a live mutation.
+
+## Live-guard agents (gate_mode only)
+
+- *(none — this provider has no live-mutation guards in the catalog)*
+
+Live-guard agents enforce approval, target confirmation, evidence capture, and rollback plans before executing a mutation. They are never auto-dispatched — the maestro must place them in `live-guard-gate` or `runtime-evidence-gate` mode.
+
+## Invariants
+
+- Route all tasks through php-maestro-agent for proper classification and dispatch.
+- Static review only -- agents analyze configuration and provide findings without mutating live systems.
+
+## Where the agents live
+
+Agent specs and adapters are part of the [Vanguard Frontier Agentic](https://github.com/Raishin/vanguard-frontier-agentic) marketplace. For this provider, see `agents/php/` in that repository. All 5 agents in this provider ship a Kiro adapter (`harnesses/kiro-ide.agent.md`, `kiro-cli.agent.json`).
+
+## Companion install paths
+
+- **Claude Code:** `/plugin marketplace add Raishin/vanguard-frontier-agentic` then `/plugin install vanguard-frontier-agentic@vanguard-frontier-agentic`
+- **Codex / Copilot / Cursor / Gemini CLI / Kiro (file export):** `npx vfa-export-agents --platform <harness> --provider php --repo .`

package/schemas/agent.schema.json

@@ -61,7 +61,8 @@
         "sap",
         "microsoft",
         "databricks",
-        "snowflake"
+        "snowflake",
+        "php"
       ]
     },
     "harnesses": {

package/schemas/skill.schema.json

@@ -52,7 +52,8 @@
         "sap",
         "microsoft",
         "databricks",
-        "snowflake"
+        "snowflake",
+        "php"
       ]
     },
     "harnesses": {

package/scripts/generate-docs-data.mjs

@@ -56,7 +56,7 @@ const taxonomy = [
   { category: 'Infrastructure as Code', providers: ['terraform'] },
   { category: 'AI & Compute', providers: ['nvidia'] },
   { category: 'Frontend & Web', providers: ['frontend'] },
-  { category: 'Developer Platforms', providers: ['backstage', 'dotnet', 'generic', 'multi-cloud'] },
+  { category: 'Developer Platforms', providers: ['backstage', 'dotnet', 'php', 'generic', 'multi-cloud'] },
   { category: 'ERP & Finance', providers: ['netsuite', 'accounting', 'finance', 'sap'] },
   { category: 'Business Functions', providers: ['salesforce', 'legal', 'hr', 'marketing'] },
   { category: 'Microsoft 365 & Dynamics 365', providers: ['microsoft'] },

package/skills/cross-functional/revenue-critical-journey-integrity-review/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: revenue-critical-journey-integrity-review
+description: Use this skill to review the cross-tier seams of revenue-critical journeys — checkout, payment submission, account creation, and login — for idempotency of money-moving and account-creating requests, server-side re-validation of client-enforced rules, webhook duplicate/out-of-order handling, retry-storm safeguards, and PCI DSS SAQ-scope judgment. Use when a request crosses client-to-server, system-to-processor, or webhook-back-into-system and a failure at that seam would double-charge, double-fulfill, bypass a required step, drop revenue, or misjudge PCI scope. Static review only; it does not execute payment flows and its PCI SAQ output is an advisory scoping opinion, never a compliance attestation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-16"
+  category: resilience
+  lifecycle: experimental
+---
+
+# Revenue-Critical Journey Integrity Review
+
+## Purpose
+
+Review the seams of revenue-critical journeys — the points where a request crosses from client to server, from your system to a payment processor, or from a webhook back into your system — so a journey that looks correct in any one tier does not break where the tiers meet. The dominant seam failures are non-idempotent money-moving requests, client-enforced rules the server never re-validates, webhook consumers that assume exactly-once/in-order delivery, unbounded retries that become retry storms, and PCI DSS SAQ-scope misjudgment.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review whether a checkout, payment, subscription, coupon, or account-creation request is safe to retry (idempotency at money-moving seams),
+- confirm the server re-validates rules the client enforces (price, discount, quantity, eligibility, step-completion),
+- review a webhook consumer for duplicate-delivery and out-of-order handling,
+- review retry/backoff/circuit-breaker safety at a revenue-critical seam across web, mobile, or backend consumers,
+- get an advisory PCI DSS SAQ-scope opinion for the payment integration model actually in the code.
+
+## When not to use
+
+Do not use this skill for:
+
+- tier-internal review that an owning specialist owns — DOM XSS/CSP and client injection (use the frontend security review), backend authorization-model design, mobile-platform specifics, or infrastructure hardening. This skill reviews the seam, not the interior; hand tier-internal findings to the owning agent.
+- issuing a PCI compliance attestation, signing an SAQ, or acting as an assessment of record. SAQ-scope output here is advisory only.
+- any live exercise of a payment system — executing flows, replaying webhooks, or sending requests to live/sandbox/staging processors. This skill is static review only.
+
+## Preconditions
+
+- The money-moving and account-creating request paths in scope, across whichever tiers exist.
+- The webhook consumer code and the event types it acts on.
+- The retry configuration (max attempts, backoff, jitter, timeout, circuit breaker) for the seams in scope.
+- The payment integration model (redirect, iframe/hosted fields, direct post/custom form) if a SAQ-scope opinion is requested.
+- The processor/SDK and version in scope, so idempotency and webhook guidance matches the real API surface.
+
+## Lean operating rules
+
+- Confirm retry/replay reachability before flagging an idempotency gap; a genuinely non-retryable internal call is not a finding.
+- Treat the server as the only enforcement boundary; a client-only check is UX, not enforcement.
+- Require webhook consumers to be both idempotent (dedupe by event id or business key) and order-tolerant.
+- Require bounded, backoff-with-jitter retries with a timeout at every revenue seam; add a circuit breaker or dead-letter path for backend/queue consumers.
+- Give a PCI SAQ-scope opinion only against the integration model present in the code, name the candidate SAQ, and label it advisory.
+- Never request, echo, store, or reproduce cardholder data, API keys, session tokens, or webhook signing secrets; redact-and-flag any that appear.
+- Label every claim `repo evidence`, `context7-grounded`, `documentation-based`, or `inference`.
+
+## Context7 documentation protocol
+
+Processor idempotency semantics, webhook retry windows, event ordering, and signature verification are version-sensitive. The bundled [official sources](references/official-sources.md) are the versioned ground truth for this skill: every processor-specific claim must trace to them and is labeled `documentation-based`, and the ledger records the version and last-verified date so a claim can be re-checked. This static-review skill's own tool grant is read-only (`Read Grep Glob`); when the invoking harness additionally provides Context7 or official-documentation tools, use them to confirm the current behavior against the bundled snapshot (`resolve-library-id` then `query-docs`, labeled `context7-grounded`) and to cover a processor the bundle does not. For a processor with no bundled or fetched coverage, say so and treat the claim as `inference` — never rely on memorized API details.
+
+## Workflow
+
+Follow the step-by-step review and output contract in [workflow and output](references/workflow-and-output.md). At a high level: (1) map the seams in scope; (2) for each money-moving/account-creating request, check idempotency against reachable retry/replay; (3) check server re-validation of every client-enforced rule; (4) check webhook consumers for idempotency + order-tolerance; (5) check retry safety; (6) if requested, form the advisory SAQ-scope opinion; (7) emit findings with evidence tiers and tier-internal handoffs.
+
+## Decision gates
+
+- Block only on a seam failure with a demonstrated reachable retry/replay/bypass path.
+- Every processor-specific claim is Context7-grounded or documentation-based, never memory.
+- Every SAQ-scope statement is advisory and tied to the integration model in the code.
+- Every tier-internal finding is handed off, not adjudicated.
+
+## Evidence classification
+
+Label each finding `repo evidence` (seen in the code), `context7-grounded` (current provider docs via Context7), `documentation-based` (official docs), or `inference`. Documentation never proves a specific deployment's live behavior — say so.
+
+## Security and privacy constraints
+
+Static review only. Never transmit, request, store, or reproduce cardholder data (PAN/CVV), API keys, session tokens, or webhook signing secrets; treat any such string as a redact-and-flag finding. Never execute payment flows or contact any live/sandbox/staging payment system. PCI SAQ-scope output is an advisory opinion, never an attestation.
+
+## Escalation conditions
+
+Escalate to incident response on any evidence of a live failure (duplicate charges in logs, replayed webhooks, retry amplification). Escalate SAQ-scope opinions to the merchant's compliance owner or a QSA as advisory input.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output](references/workflow-and-output.md) — the end-to-end review steps and the finding/output contract.
+- [Idempotency and safe retries](references/idempotency-and-safe-retries.md) — idempotency keys at money-moving seams and bounded backoff-with-jitter retry design.
+- [Webhook delivery: dedup and ordering](references/webhook-delivery-dedup-ordering.md) — duplicate-delivery and out-of-order handling for webhook consumers.
+- [Server-side re-validation and the client trust boundary](references/server-side-revalidation-trust-boundary.md) — why the server is the only enforcement boundary and what to re-check.
+- [PCI DSS SAQ scope boundaries](references/pci-saq-scope-boundaries.md) — SAQ A vs A-EP vs D by integration model and the 6.4.3/11.6.1 payment-page expectations.
+- [Official sources](references/official-sources.md) — the primary-source ledger for every claim in this skill.
+
+## Response minimum
+
+Return, at minimum:
+
+- the seam(s) in scope and, per finding, the failure class and evidence tier;
+- the cross-tier failure narrative (how a retry, replay, or bypass reaches a wrong outcome);
+- concrete remediation and an exact verification step;
+- the advisory SAQ-scope opinion when requested, labeled advisory;
+- tier-internal handoffs and any incident-response escalation.
+
+## Anti-goals
+
+- Do not expand into tier-internal review; own the seam, hand off the interior.
+- Do not present a SAQ-scope opinion as a compliance determination.
+- Do not exercise any live payment system or reproduce any secret or PAN.
+- Do not assert processor behavior from memory.

package/skills/cross-functional/revenue-critical-journey-integrity-review/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "revenue-critical-journey-integrity-review",
+  "name": "Revenue-Critical Journey Integrity Review",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Skill for reviewing the cross-tier seams of revenue-critical journeys (checkout, payment, account creation, login): idempotency of money-moving and account-creating requests, server-side re-validation of client-enforced rules, webhook duplicate/out-of-order handling, retry-storm safeguards, and advisory PCI DSS SAQ-scope judgment for the integration model in use.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.stripe.com/api/idempotent_requests",
+    "https://docs.stripe.com/webhooks/best-practices",
+    "https://www.pcisecuritystandards.org/faqs/1443/",
+    "https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a",
+    "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html",
+    "https://baymard.com/lists/cart-abandonment-rate"
+  ],
+  "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no network egress to any payment system. Never requests, transmits, stores, or reproduces cardholder data (PAN/CVV), API keys, session tokens, or webhook signing secrets — any such string is a redact-and-flag finding, never echoed. PCI DSS SAQ-scope output is an advisory scoping opinion to inform a Qualified Security Assessor or the merchant's own validation, never a compliance attestation or assessment of record. Never executes payment flows or replays webhooks against live, sandbox, or staging systems.",
+  "last_verified": "2026-07-16",
+  "path": "skills/cross-functional/revenue-critical-journey-integrity-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cross-functional/revenue-critical-journey-integrity-review/references/idempotency-and-safe-retries.md

@@ -0,0 +1,155 @@
+# Idempotency and safe retries
+
+## Why this matters
+
+Every money-moving or account-creating request that can be retried — by a client
+double-submit, a gateway timeout-then-retry, or a user hitting back/refresh — is a
+duplicate-charge or duplicate-account risk unless the seam is explicitly made safe
+to repeat. This is a seam failure, not a tier-internal bug: the client, server,
+and processor can each look correct in isolation while the combination
+double-charges a customer. Idempotency keys close the money-moving side;
+bounded backoff-with-jitter retries close the availability side by preventing a
+single downstream blip from becoming a self-inflicted retry storm.
+
+## Where an idempotency mechanism is required
+
+An idempotency mechanism is required at any request that both (a) moves money
+or creates a billable resource (create charge, create payment intent, create
+subscription, apply a coupon), and (b) is reachable by at least one
+retry/replay path: client double-submit (double click, back-button resubmit),
+gateway or SDK-level automatic retry on connection error/timeout, or a user
+manually resubmitting after an ambiguous response.
+
+A genuinely non-retryable internal call (no client retry, no gateway retry
+configured, no user-facing resubmit path) is not a finding — confirm
+reachability before flagging, per the skill's lean operating rules.
+
+## NORMATIVE: what Stripe requires and provides
+
+Per Stripe's API reference on idempotent requests (`documentation-based`;
+Context7 was attempted first and returned a monthly-quota error, so this was
+grounded via direct WebFetch of the official page):
+
+- A client generates and attaches an idempotency key to a `POST` request (e.g.
+  create charge, create customer). This lets the request be retried safely
+  after a connection error without performing the operation twice.
+- Stripe caches the first response for that key — including a 5xx error
+  response — for **at least 24 hours**.
+- A replay with the same key returns the cached first result rather than
+  re-executing the operation.
+- If a retry sends the same key with **different parameters** than the
+  original request, Stripe returns an error rather than silently applying the
+  new parameters. The key scopes to the exact original request, not just the
+  endpoint.
+
+These are processor-documented behaviors, not general recommendations — do not
+generalize them to a processor without checking that processor's own docs.
+
+## RECOMMENDATION: how to implement idempotency at your own seams
+
+For a seam the merchant's own server owns (e.g. an internal "create order" call
+in front of the processor call), the same pattern applies as a design
+recommendation, not a processor mandate:
+
+- **Client-generated key** — a UUID generated once per logical operation
+  attempt, not per HTTP retry, sent in a header or body field.
+- **Server-side unique constraint** — the server stores the key in a table
+  with a unique constraint (e.g. a unique index on `idempotency_key`)
+  alongside the operation's result. The insert-or-conflict on that constraint
+  is the correctness mechanism, not an application-level `SELECT`-then-`INSERT`
+  check, which races under concurrent retries.
+- **Return the cached first result on replay** — on a unique-constraint
+  conflict, look up the stored result for that key and return it unchanged,
+  rather than re-running the operation.
+- **Scope keys to exact request parameters**, mirroring Stripe's behavior:
+  reject (or explicitly document accepting) a replay whose parameters differ
+  from the original.
+
+## Reviewer evidence criteria
+
+For each money-moving or account-creating request in scope, check for:
+
+- A client-generated idempotency key attached to the request (header or body
+  field), generated once per user-intent attempt, not regenerated on every
+  retry.
+- A server-side store (table/cache) keyed on that value with a **unique
+  constraint**, not merely an in-memory or best-effort check.
+- Confirmation that a replay with the same key returns the original stored
+  result rather than re-invoking the money-moving/account-creating operation.
+- Confirmation that a replay with the same key but different parameters is
+  rejected or explicitly handled, not silently accepted.
+- For calls that pass through to Stripe (or another processor) directly,
+  confirmation the processor's own idempotency-key parameter is used on the
+  outbound call, in addition to (not instead of) any client-facing key.
+
+Absence of all of the above at a seam where retry/replay is reachable is a
+blocking finding per the skill's decision gates.
+
+## Retry design: bounded backoff, jitter, and the retry-storm failure
+
+Retry-storm mitigation is not a processor-documented requirement — no
+NORMATIVE claim applies here. It is a reliability-engineering recommendation
+grounded in AWS's Well-Architected Reliability Pillar guidance
+(`documentation-based`).
+
+## RECOMMENDATION: bounded, backoff-with-jitter retries
+
+Per AWS's Well-Architected Reliability Pillar guidance on limiting retries, a
+**retry storm** occurs when retries compound across multiple layers of a stack
+under failure — each layer retrying independently — so the failing service
+receives new requests plus every layer's retries simultaneously, saturating it
+and reducing availability further rather than recovering it. The documented
+mitigation is client-side exponential backoff, jitter, and a maximum retry cap.
+A second AWS primary source, the Builders' Library article "Timeouts, retries,
+and backoff with jitter," covers the same pattern in more implementation depth
+and may be cited alongside it.
+
+For every retry path at a revenue-critical seam (web client, mobile client, or
+backend/queue consumer), check for:
+
+- **Maximum attempt cap** — retries stop after a fixed, small number of
+  attempts rather than continuing indefinitely.
+- **Exponential backoff** — each successive retry waits longer than the last
+  (e.g. doubling), rather than retrying at a fixed interval.
+- **Jitter** — the wait interval is randomized within a range rather than
+  deterministic, so many clients failing at once do not retry in lockstep and
+  re-collide on the recovering service.
+- **Request timeout** — each attempt has an explicit timeout rather than
+  waiting indefinitely for a hung connection, so a stuck attempt does not
+  block the retry budget.
+- **Circuit breaker or dead-letter path for backend/queue consumers** — once
+  failures exceed a threshold, the consumer stops retrying and either trips a
+  circuit (short-circuits further calls for a cooldown period) or routes the
+  message to a dead-letter queue, instead of retrying forever against a
+  downstream that is already down.
+- **No cross-tier amplification** — if a mobile client retries and the API
+  gateway it calls also retries independently, confirm the combination is
+  still bounded; check the effective worst-case request multiplier across all
+  layers, not one layer's configuration in isolation.
+
+Unbounded retries, retries with no backoff, or fixed-interval retries with no
+jitter at a revenue-critical seam are retry-storm-risk findings, citable
+against the AWS Well-Architected reference.
+
+## Applicable versions
+
+- Stripe idempotent-request behavior described here reflects the current
+  Stripe API reference page as of this review; idempotency-key retention
+  windows and behavior are processor-specific and must be re-verified against
+  the exact processor/SDK version in scope, per the skill's Context7
+  documentation protocol.
+- The AWS Well-Architected Reliability Pillar guidance is framework-level
+  (not tied to a specific AWS service version) and applies to any retry
+  design, not only AWS-hosted systems.
+- Documentation describes intended behavior only; whether a specific
+  deployment actually implements a unique constraint, a bounded backoff
+  policy, or a circuit breaker is an `inference` from code review, never
+  proven by the existence of these docs.
+
+## Sources
+
+- [Stripe API reference — Idempotent requests](https://docs.stripe.com/api/idempotent_requests) — supports the client-generated-key mechanism, the 24-hour-minimum cache of the first response (including 5xx), and the error-on-differing-parameters behavior.
+- [AWS Well-Architected Reliability Pillar — Limit retries](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html) — supports the retry-storm definition and the exponential-backoff/jitter/max-retry-cap mitigation.
+- [AWS Builders' Library — Timeouts, retries, and backoff with jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) — supplementary primary source on backoff-with-jitter implementation.
+
+Last verified: 2026-07-16.