@raishin/vanguard-frontier-agentic 3.2.0 → 3.4.0

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-java/POWER.md

@@ -0,0 +1,40 @@
+---
+name: "vanguard-java"
+displayName: "Vanguard Frontier — Java"
+description: "Curated Java agents for java application server exit, java concurrency and virtual thread, java container and kubernetes readiness, java database migration safety. Routes via java-maestro-agent to specialist agents based on task scope. Static review only; no live mutations."
+keywords: ["java", "static-review", "configuration-audit", "best-practices"]
+author: "Raishin"
+---
+# Vanguard Frontier — Java
+
+Curated Java agents for java application server exit, java concurrency and virtual thread, java container and kubernetes readiness, java database migration safety. Routes via java-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 Java services, resources, or operations. Do not activate on unrelated requests — narrow keyword matching is required to avoid false activations (Kiro Powers convention).
+
+## Routing pattern
+
+- **`java-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 java-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/java/` in that repository. All 15 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 java --repo .`

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

@@ -52,6 +52,7 @@
         "generic",
         "frontend",
         "dotnet",
+        "java",
         "hr",
         "legal",
         "salesforce",
@@ -61,7 +62,23 @@
         "sap",
         "microsoft",
         "databricks",
-        "snowflake"
+        "snowflake",
+        "php",
+        "kyverno",
+        "istio",
+        "argocd",
+        "cilium",
+        "opentelemetry",
+        "prometheus",
+        "falco",
+        "sigstore",
+        "cert-manager",
+        "fluxcd",
+        "backstage",
+        "velero",
+        "nvidia",
+        "claude",
+        "marketing"
       ]
     },
     "harnesses": {

package/schemas/skill.schema.json

@@ -45,6 +45,7 @@
         "generic",
         "frontend",
         "dotnet",
+        "java",
         "hr",
         "legal",
         "salesforce",
@@ -52,7 +53,32 @@
         "sap",
         "microsoft",
         "databricks",
-        "snowflake"
+        "snowflake",
+        "php",
+        "kyverno",
+        "istio",
+        "argocd",
+        "cilium",
+        "opentelemetry",
+        "prometheus",
+        "falco",
+        "sigstore",
+        "cert-manager",
+        "fluxcd",
+        "backstage",
+        "velero",
+        "alibaba",
+        "huawei",
+        "ovhcloud",
+        "ionos",
+        "scaleway",
+        "hetzner",
+        "contabo",
+        "nvidia",
+        "claude",
+        "marketing",
+        "accounting",
+        "finance"
       ]
     },
     "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', 'java', '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.

package/skills/cross-functional/revenue-critical-journey-integrity-review/references/official-sources.md

@@ -0,0 +1,71 @@
+# Official sources
+
+## Why this matters
+
+Every processor-specific, standard-specific, or architecture-specific claim
+this skill makes traces to exactly one official, primary source — never a
+tutorial, a vendor marketing page, or press coverage. This ledger is that
+trace: one row per source, the exact claim(s) it grounds, the source type,
+the applicable version where one exists, and the verification date. A
+reviewer citing this skill's guidance should be able to follow any claim back
+to the primary document that supports it, and to see at a glance which
+figures are verified fact versus flagged as unverified.
+
+## NORMATIVE: every claim in this skill must resolve to a row below
+
+No processor behavior, standard requirement, or architecture guidance may be
+asserted in this skill's other reference files without a corresponding row
+here. If Context7 is unavailable for a processor lookup, the fallback is the
+processor's official documentation site, fetched directly and labeled
+`documentation-based` rather than `context7-grounded` — never memory.
+
+| Official URL | Claim(s) supported in this skill | Source type | Applicable version | Last verified |
+|---|---|---|---|---|
+| [Stripe API reference — Idempotent requests](https://docs.stripe.com/api/idempotent_requests) | A client-generated idempotency key lets a `POST` (e.g. create charge/customer) be safely retried after a connection error without duplicating the object or repeating the operation. Stripe caches the first response — including 5xx errors — for at least 24 hours per key, and returns an error if a retry sends parameters differing from the original request. | processor-docs | Current Stripe API (fetched directly; Context7 quota was exhausted — see uncertainty note below) | 2026-07-16 |
+| [Stripe — Webhook best practices](https://docs.stripe.com/webhooks/best-practices) | Endpoints may receive the same event more than once. Live-mode automatic retries continue for up to 3 days with exponential backoff; sandbox retries 3 times over a few hours; manual dashboard resend is available within 15 days and CLI resend within 30 days, and a manual resend does not cancel Stripe's own automatic retry schedule. Endpoints are disabled after 3 days of continuous failure in live mode. Events can arrive out of order. Handlers must be idempotent, e.g. by logging processed event IDs and deduping on them. | processor-docs | Current Stripe webhooks documentation | 2026-07-16 |
+| [PCI SSC FAQ 1443](https://www.pcisecuritystandards.org/faqs/1443/) | SAQs are scoped by how an entity stores, processes, and/or transmits cardholder data; each SAQ type (A, A-EP, B, B-IP, C, C-VT, D, …) has specific eligibility criteria and approved system types; a merchant must confirm SAQ eligibility with its acquirer or the payment brand before self-assessing. Integration model drives the candidate SAQ: fully outsourced redirect/iframe typically maps to SAQ A; direct-post/merchant-served forms typically map to SAQ A-EP; server-side storage/processing of cardholder data maps to SAQ D. | standard | PCI DSS SAQ program (current) | 2026-07-16 |
+| [PCI SSC official blog — Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a) | PCI DSS v4.0.1 requirements 6.4.3 (payment-page script inventory, authorization, and integrity) and 11.6.1 (change-and-tamper-detection mechanism for payment pages) became effective 31 March 2025. Effective with the January 2025 SAQ A revision, PCI SSC removed 6.4.3, 11.6.1, and 12.3.1 from the SAQ A questionnaire itself and replaced them with an eligibility criterion requiring the merchant to attest its site "is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." Corrects the record: the underlying PCI DSS v4.0.1 requirements remain in effect — only the SAQ A checklist scope changed, contingent on the eligibility attestation. | standard | PCI DSS v4.0.1; January 2025 SAQ A revision | 2026-07-16 |
+| [AWS Well-Architected Framework — Reliability Pillar: Mitigate interaction failure with retry limits](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html) | A "retry storm" occurs when retries compound across multiple stack layers under failure, saturating the service with new-plus-retried requests and reducing availability. Documented mitigation is client-side exponential backoff, jitter, and a maximum retry cap. | cloud-architecture | AWS Well-Architected Framework (current) | 2026-07-16 |
+| [AWS Builders' Library — Timeouts, retries, and backoff with jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) | Supplementary primary source for backoff-with-jitter retry design at revenue-critical seams; used only to reinforce the Reliability Pillar guidance above, not as a source of any additional unverified claim. | cloud-architecture | AWS Builders' Library (current) | 2026-07-16 |
+| [OWASP Top 10:2021 — A01:2021 Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) | Grounds the general principle that enforcement decisions (authorization, business-rule checks) must not rely on client-side controls — the basis for treating the server as the only enforcement boundary for client-enforced rules (price, discount, quantity, eligibility, step-completion). | standard | OWASP Top 10:2021 | 2026-07-16 |
+| [OWASP Cheat Sheet Series — Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) | Grounds the requirement that input validation performed client-side is a usability aid, not a security control, and must be re-implemented server-side — supports the server-side re-validation guidance for client-enforced rules. | standard | OWASP Cheat Sheet Series (current) | 2026-07-16 |
+| [Baymard Institute — Cart Abandonment Rate Statistics](https://baymard.com/lists/cart-abandonment-rate) | Aggregate of 50 published studies puts average documented e-commerce cart/checkout abandonment at 70.22%. In Baymard's own study of abandonment reasons, 18% of US online shoppers abandoned an order due to a "too long/complicated checkout process" and 19% cited being required to create an account. Used only as motivating business-pain figures, not as a technical claim. | research-publisher | Baymard Institute published aggregate (current) | 2026-07-16 |
+
+## Known uncertainty / not encoded
+
+- **Context7 quota fallback.** Per this skill's Context7 documentation
+  protocol, Stripe idempotency and webhook behavior should be resolved via
+  Context7 (`resolve-library-id` then `query-docs`) first. During grounding
+  for this skill, Context7 returned "Monthly quota reached" for the Stripe
+  lookup. The fallback used was a direct fetch of Stripe's official
+  documentation pages, and those claims are labeled `documentation-based`
+  rather than `context7-grounded` throughout this skill's reference files.
+  Re-attempt the Context7 path when quota is available and update the labels
+  above if a discrepancy is found.
+- **UNVERIFIED — false-decline dollar estimates, do not encode as fact.**
+  Circulating industry estimates of e-commerce revenue lost to false payment
+  declines (e.g. figures on the order of ~$81B US / ~$443B global at a
+  ~1.51% false-decline rate, and an older Javelin 2014 figure contrasting
+  ~$118B in false declines against ~$9B in actual fraud losses) are known
+  only via secondary vendor reporting (press coverage citing PYMNTS, Datos
+  Insights, Cybersource, and Javelin research) and were **not** verified
+  against those primary reports for this skill. These figures must **not**
+  be stated as fact anywhere in this skill's guidance or findings. If
+  mentioned at all, they must be labeled explicitly as unverified,
+  directionally-credible industry estimates requiring primary-source
+  re-verification before use — never as a hard number backing a finding or
+  a business-pain claim.
+
+## Sources
+
+- [Stripe API reference — Idempotent requests](https://docs.stripe.com/api/idempotent_requests)
+- [Stripe — Webhook best practices](https://docs.stripe.com/webhooks/best-practices)
+- [PCI SSC FAQ 1443](https://www.pcisecuritystandards.org/faqs/1443/)
+- [PCI SSC official blog — Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a)
+- [AWS Well-Architected Framework — Reliability Pillar: Mitigate interaction failure with retry limits](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html)
+- [AWS Builders' Library — Timeouts, retries, and backoff with jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+- [OWASP Top 10:2021 — A01:2021 Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
+- [OWASP Cheat Sheet Series — Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)
+- [Baymard Institute — Cart Abandonment Rate Statistics](https://baymard.com/lists/cart-abandonment-rate)
+
+Last verified: 2026-07-16.