test run

.github/workflows/performance-stress.yml

@@ -2,7 +2,7 @@ name: Performance Stress Test
 
 on:
   schedule:
-    - cron: '0 2 * * 1'
+    - cron: '25 2 * * 1'
   workflow_dispatch:
     inputs:
       target_url:

.github/workflows/pr-quality-gate.yml

@@ -109,6 +109,15 @@ jobs:
           sudo apt-get update
           sudo apt-get install k6
 
+      # Java is required for the Maven execution path below. Cached Maven deps
+      # are reused across all jobs that also hit the reactor.
+      - name: Set up Java ${{ env.JAVA_VERSION }}
+        uses: actions/setup-java@v4
+        with:
+          java-version: ${{ env.JAVA_VERSION }}
+          distribution: temurin
+          cache: maven
+
       # Component performance gate — validates patient lookup endpoint SLA on
       # every PR. Catches regressions at the point they are introduced.
       - name: Run patient lookup component test
@@ -117,6 +126,17 @@ jobs:
             --env API_BASE_URL=${{ env.API_BASE_URL }} \
             k6/component/patient-lookup.js
 
+      # Governance parity: invoke the same k6 script through Maven so the
+      # reactor entrypoint (`mvn test`) behaves identically to the direct k6
+      # command above. Runs alongside the direct invocation rather than
+      # replacing it, to prove the two paths produce the same result while
+      # the rest of the k6 modules are on-boarded. Once every k6 component
+      # has a Maven binding, the direct `k6 run` step will retire and CI
+      # will drive all test layers (REST Assured, Karate, Pact, k6) through
+      # a single reactor command — the operating model transformation goal.
+      - name: Run patient lookup component test via Maven
+        run: mvn test -pl k6 -Dapi.base.url=${{ env.API_BASE_URL }}
+
   k6-prescription-api:
     name: k6 — Prescription API Component
     runs-on: ubuntu-latest

README.md

@@ -45,13 +45,13 @@ flowchart TD
             direction LR
             PR1["REST Assured\nFunctional tests"]
             PR2["Karate BDD\nScenario tests"]
-            PR3["k6 Component\nOne per endpoint"]
+            PR3["k6 Component\nOne per endpoint\n60s each"]
         end
         CO["Pact Consumer\nContract generation"]
         PV["Pact Provider\nContract verification"]
         SM["Staging Smoke\nKarate @smoke\n5 min · critical paths only"]
-        K6L["k6 System Load\nFull e2e journey"]
-        K6S["k6 Stress\nScheduled — Monday 2AM"]
+        K6L["k6 System Load\nFull e2e journey\nStaging deploy"]
+        K6S["k6 Stress\nScheduled Mon 2AM\nBreak point discovery"]
     end
 
     API["🌐 JSONPlaceholder\nRepresents microservice layer"]
@@ -63,7 +63,6 @@ flowchart TD
 
     L1 --> PR1
     L2 --> PR2
-    L4 --> PR3
     PR1 --> CO
     PR2 --> CO
     PR3 --> CO
@@ -173,13 +172,18 @@ Pact inverts the testing direction. The consumer team (e.g., Cart service consum
 
 ## 6. Pipeline Integration
 
-![PR Quality Gate — 4-job dependency chain](docs/images/pipeline-visual.png)
-*PR Quality Gate: REST Assured and Karate run in parallel, 
-feeding Pact Consumer contract generation, 
-followed by Pact Provider verification. 
-Total execution: ~80 seconds on every pull request.*
+![PR Quality Gate](docs/images/pipeline-visual.png)
+*PR Quality Gate: Five parallel jobs — REST Assured, 
+Karate BDD, and three k6 component performance gates 
+run simultaneously, feeding Pact Consumer contract 
+generation, followed by Pact Provider verification. 
+Total execution: ~2m 18s on every pull request.*
 
-Two workflows, one principle: **the right tests at the right gate.**
+Three workflows, one principle: **the right tests at the right gate, at the right time.**
+
+- **PR Quality Gate** — functional, BDD, and performance component gates on every pull request
+- **Staging Smoke** — Karate @smoke + k6 system load on every staging deployment
+- **Performance Stress** — scheduled Monday 2AM UTC, on-demand for capacity planning
 
 ### `pr-quality-gate.yml` — runs on every PR to `main`
 
@@ -226,6 +230,31 @@ The goal is not to eliminate Postman from engineers' desktops. The goal is to re
 
 ---
 
+## Documentation
+
+| Document | Purpose |
+|---|---|
+| [Architecture Decision](docs/architecture-decision.md) | Why each layer — trade-offs and alternatives considered |
+| [Pipeline Design](docs/pipeline-design.md) | What runs when and why — the gate logic |
+| [Current State — Postman](docs/CURRENT_STATE_POSTMAN.md) | Enterprise-scale limitations of Postman/Newman |
+| [Test Pyramid](docs/TEST_PYRAMID.md) | Complete testing strategy including service virtualization gap |
+| [Build Story](docs/BUILD_STORY.md) | How this was built — AI-native productivity model |
+
+---
+
+## Use This Skill
+
+This repository was built using a reusable Claude Code skill. The full prompt template — including all seven prompts, verification checklist, customization guide, and talking points — is available at:
+
+👉 [SKILL.md](SKILL.md)
+
+**Adapt it for any Java microservices project** by replacing six variables:
+- PROJECT_NAME, PACKAGE_BASE, CONSUMER_NAME, PROVIDER_NAME, TARGET_API, DOMAIN
+
+The skill produces a working three-layer API testing platform with GitHub Actions pipeline in under 9 hours using Claude Code.
+
+---
+
 ## 8. Getting Started
 
 **Prerequisites:** Java 17, Maven 3.9+