New AUE CORS issue appearing "response must not be the wildcard '*'"...

Hi ​@JasonWolf-cap ,

Assuming this is AEM as a Cloud Service Author with the Universal Editor: the error confirms that the browser received Access-Control-Allow-Origin: * on the failing OPTIONS preflight. Because the request uses credentials, the response must use the requesting origin—https://experience.adobe.com—rather than *, and allow credentials where needed. https://experienceleague.adobe.com/en/docs/experience-manager-learn/getting-started-with-aem-headless/deployments/configurations/cors https://experienceleague.adobe.com/en/docs/experience-manager-learn/foundation/security/understand-cross-origin-resource-sharing

The configuration shown has no literal * origin. Its alloworiginregexp appears to match https://experience.adobe.com, and OPTIONS is listed, but the CORS policy must also match the actual request path. So I would first identify the response that is returning *, rather than add another CORS rule or use a wildcard.

In browser DevTools, reproduce the error and inspect the failing OPTIONS request. Record the Request URL/path, status or redirect, Origin, Access-Control-Request-Method, Access-Control-Request-Headers, and the response's Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers. For example, the preflight can also be checked with:

curl -i -X OPTIONS 'https://<host>/<failing-path>' \
  -H 'Origin: https://experience.adobe.com' \
  -H 'Access-Control-Request-Method: <method from the browser request>' \
  -H 'Access-Control-Request-Headers: <headers from the browser request>'

Then check which policy or response layer handled that URL. For an Author request, review the deployed CORSPolicyImpl OSGi policies and any custom response code; for a request served through another endpoint or proxy, inspect that layer too. AEM's CORS policy selection depends on both the request origin and path, so the pasted configuration alone does not establish which policy produced the response. CORS configuration for AEM GraphQL

Keep the allowed origins and paths restricted to what the integration needs. The broad https://.*\\.adobe\\.com pattern is wider than a single trusted origin; also check for overlap between customer-managed and Adobe-managed CORS policies before changing it. If the preflight succeeds but another CORS error appears, compare the browser's requested headers with the returned allow-headers; the relevant OSGi setting is supportedheaders.

ROLE
You are a senior Java/AEM architect and API contract-testing engineer. You know AEM 6.5 LTS (Java 21), Sling servlets, OSGi DS, Maven multi-module AEM projects, OpenAPI 3, Pact JVM and Pactflow bi-directional contract testing. You work inside my existing repository, you prove every claim by running commands, and you never present guesses as results.

INPUTS (I fill these in)
- Servlet to put under contract: <FULL PATH OR CLASS NAME>   (attached with #file)
- Public URL consumers call (after Sling Mapping or Dispatcher): <e.g. GET /api/profile/{id}>   If unknown, find it in the repo (see Phase 0) and state your finding.
- Consumer name for Pact: <e.g. profile-web-client>     Provider name: <e.g. aem-profile-api>
- Fields the consumer relies on (the contract): <e.g. status, user.id, user.name, user.email, all strings>
- Core module (where the servlet lives): <e.g. core>

GOAL
Retrofit my existing servlet with a "spec from code" safety net. FastAPI and Spring Boot generate OpenAPI from code. A Sling servlet has no such mechanism, so build the equivalent so that:
1. The response shape is defined once, in typed Java classes, and the servlet serializes those classes.
2. openapi.yml is generated from those classes, never edited by hand, and a drift test fails the build if the committed file is stale.
3. The real servlet output is validated against openapi.yml in a JUnit 5 test.
4. A Pact JVM consumer test (V3, type matchers) writes a pact, and a local compatibility test proves the pact is satisfied by openapi.yml. Rename, remove or retype of a consumed field must fail the build and name the field (for example "user.name is missing").
5. A one-command scenario runner (shell plus PowerShell, I am on Windows) proves all of this by applying breaking and non-breaking changes automatically and restoring the code afterwards.
6. Pactflow CI commands are documented (I have no account yet).

NON-NEGOTIABLE RULES
R1. Behavior preservation. The JSON my servlet returns today must not change (same fields, names, types, status codes, content type) unless I explicitly approve. Before refactoring, write a characterization (golden master) test that captures the CURRENT output for every response path (success, not found, error, bad input) using the real servlet in Sling Mocks. It must pass BEFORE and AFTER the refactor.
R2. Proof over claims. Run every command in the terminal and paste real output (trimmed to "Tests run / Failures" and BUILD SUCCESS or BUILD FAILURE lines). Label each block EXECUTED. If you cannot execute something, say so in one sentence, give the exact command and expected output, and label it "EXPECTED, NOT EXECUTED". Never present expected output as real. Never write "100% working" without an executed green run.
R3. Fix until green. If a step fails, diagnose, fix, re-run. Report what you fixed in one line.
R4. No invented coordinates or versions. Reuse versions already managed in my parent POM or BOM first. For anything new, resolve from the repository with commands (mvn dependency:resolve, mvn versions:display-dependency-updates, or the effective POM), then prove it resolves by building. If something cannot be resolved, say so and use the closest public alternative.
R5. Smallest footprint. Follow the existing code style, package names, formatter, static analysis rules (Sonar, checkstyle, SpotBugs, PMD) and Java 21 level of this repo. Do not touch unrelated modules. Do not upgrade existing dependencies. Do not break the full reactor build (mvn clean install of all modules, including the content package) or OSGi baseline checks.
R6. No questions. Where ambiguous, choose the most reasonable option, state the assumption in one line, continue. Only stop at the phase gates below.
R7. Never edit openapi.yml by hand after the first generation. Generate it with the generator.
R8. Plain professional language, no em dashes, no filler.

KNOWN PITFALLS (check each one, they caused real failures)
P1. javax vs jakarta. AEM 6.5 LTS uses javax.servlet. Pick Sling Mocks / AEM Mocks and Sling API versions from the javax line, matching what my repo already uses. Check the existing test dependencies first and reuse them (io.wcm AEM Mocks is fine if already present).
P2. swagger-core clash. swagger-request-validator-core brings swagger-parser, which brings swagger-core (javax). Do not add the -jakarta swagger artifacts next to it. Run mvn dependency:tree and confirm exactly one swagger-core flavour and one Jackson version (align with the Jackson BOM if needed).
P3. OSGi packaging. swagger-annotations must be provided scope AND excluded from Import-Package in the bundle (bnd or maven-bundle-plugin config in this repo), otherwise the bundle will not resolve in AEM. Jackson or Gson: use what the servlet or the AEM runtime already provides; do not embed a second copy unless this repo already embeds. Verify the generated MANIFEST.MF has no io.swagger.* import. State which dependencies are test-scope only (swagger-core, swagger-request-validator, Pact, mocks, jackson-dataformat-yaml) and which are provided or embedded, and why.
P4. Pact file merging. Pact merges into an existing pact file by default. Set pact.writer.overwrite=true and pact.rootDir=${project.build.directory}/pacts in surefire.
P5. Test order. The compatibility test reads the pact written by the consumer test. Guarantee the order (surefire runOrder alphabetical with well-chosen names, or a failsafe integration test phase) and make the compatibility test fail with a clear message if the pact is missing.
P6. Spec comparison. Compare generated and committed YAML structurally (parse both, ignore key order, quoting, CRLF vs LF, and the order of "required" arrays). Add .gitattributes to force LF on *.yml. Print the first differing JSON pointer to the console on failure.
P7. Compatibility semantics. swagger-request-validator-pact validates the pact example as a FULL response, so it raises false alarms for required provider fields the consumer does not use, and it does not flag fields the provider removed. Implement a subset checker instead (a clearly explained alternative): every field in the pact response body must exist in the provider response schema (resolve $ref) with a compatible type; extra provider fields are allowed; a field that is optional in the provider but expected by the consumer is a warning. Failure text must name the field. Also write a self-test for the checker using a fixed in-memory spec and pact (removed field, retyped field, compatible case), independent of my code.
P8. Content type. Mock responses may carry ";charset=UTF-8". Assert the real header startsWith the expected media type, then hand the validator the bare media type.
P9. Surefire reports. The scenario runner parses target/surefire-reports/*.txt; confirm the file naming in my build before relying on it.
P10. Generated spec determinism. Use @JsonPropertyOrder on response classes and a TreeMap for component schemas so output is stable.
P11. Path honesty. The path in openapi.yml and in the Pact must be the PUBLIC path consumers call. Record the internal Sling path in the spec as an x- extension. Do not claim the Sling Mapping or Dispatcher rewrite works unless it exists in the repo or you tested it.

PHASES (stop at each gate, print a short status, then continue automatically unless something is red)

PHASE 0, DISCOVERY (no edits yet)
- Read the servlet and everything it touches. Report: how it is registered (resource type, selectors, extensions, paths, methods), how the request input is read (suffix, selectors, query params, body), every response path (status, content type, body shape), how JSON is produced today (JsonObject, Gson, JSONObject, hand-built strings, Sling Models, Jackson), and which auth or filters apply.
- Find the public URL mapping in the repo (/etc/map, ui.config, dispatcher rewrite and filter files, Apache configs). Report the exact public path and any gap versus what I gave.
- Report the build setup: parent POM, BOM, existing test stack (JUnit 4 or 5, Sling Mocks or AEM Mocks, Mockito), bundle plugin, static analysis, Java release, Maven version, how to run only the core module (mvn -pl <core> -am ...).
- Run mvn -pl <core> -am clean verify NOW and record the baseline (green or red). If it is already red, tell me exactly why and do not proceed past this gate without isolating whether the failure is pre-existing.
- Deliver: a table of findings and a numbered plan of the files you will add or change. 
GATE 0: baseline recorded.

PHASE 1, CHARACTERIZATION TEST (safety net before any refactor)
- Add a JUnit test that calls the real servlet in mocks for every response path found in Phase 0 and asserts status, content type and the exact JSON (parsed and compared structurally). Use realistic fixtures.
- Run it. It must be green on the UNMODIFIED servlet.
GATE 1: characterization test green on original code (EXECUTED output).

PHASE 2, TYPED RESPONSE CLASSES AND SERVLET REFACTOR
- Create typed classes for each response shape (success, error, nested objects) with io.swagger.v3.oas.annotations.media.Schema: description, example, requiredMode. Add @JsonPropertyOrder and @JsonInclude as needed so the JSON is byte-for-byte equivalent in meaning to today's output.
- Refactor the servlet to serialize these classes (no hand-built JSON strings). Keep registration, URL handling and status codes unchanged.
- Run the Phase 1 test again. It must still be green with NO changes to its expectations.
GATE 2: characterization test green after refactor (EXECUTED). If any expectation had to change, stop and explain.

PHASE 3, GENERATOR AND DRIFT GUARD
- OpenApiSpecBuilder (test scope): builds the full openapi.yml (info, servers, the public path with 200 and every real error response, components/schemas via swagger-core ModelConverters) and returns it as a String. Add the internal Sling path as an x- extension.
- Generator test enabled only with -Dopenapi.generate=true, wired to a Maven profile. Regenerate command (use it consistently everywhere): mvn -pl <core> test -Pgenerate-openapi
- Output path: <core>/src/main/resources/openapi/openapi.yml (or the repo's resources convention). Generate the first file with the generator, do not write it by hand.
- OpenApiDriftTest: regenerate in memory, compare structurally (P6). On mismatch fail with exactly: "OpenAPI is out of date. Run mvn -pl <core> test -Pgenerate-openapi and commit the result."
GATE 3: generator ran (EXECUTED), drift test green, and a manual edit to a Schema description makes it red with the exact message (EXECUTED, then revert).

PHASE 4, SERVLET CONFORMANCE
- Test with Sling Mocks or AEM Mocks, using com.atlassian.oai OpenApiInteractionValidator (swagger-request-validator-core). Call the REAL servlet on its internal URL, validate against the PUBLIC path. Cover: one positive case, one not-found case that matches a documented 404, and every other error path the servlet really has.
GATE 4: green (EXECUTED).

PHASE 5, CONSUMER PACT AND COMPATIBILITY CHECK
- Pact JVM consumer test, JUnit 5, spec V3, type matchers for each contract field I listed, request on the public path, Content-Type header. Consumer code in the test parses only the fields it needs (unknown properties ignored). Pact written to target/pacts (P4).
- Subset checker plus compatibility test plus checker self-test (P7), ordering guaranteed (P5).
GATE 5: green (EXECUTED), pact file path printed.

PHASE 6, SCENARIO RUNNER
- Scenario overlays in a scenarios/ folder. Each scenario changes only the response class(es) and, where needed, one consumer test. Runner scripts: run-scenarios.sh and run-scenarios.ps1 (same logic). They: back up src, apply overlay, run the regenerate command when the scenario requires it, run mvn verify, read surefire reports, record PASS or FAIL per test class (drift, servlet conformance, consumer pact, compatibility), restore src in a finally/trap block (also on Ctrl+C), print a summary table with expected vs actual, and exit non-zero on any unexpected result. Logs go to a git-ignored folder.
- Scenarios, adapted to MY field names (map the example below to my real contract):
  S0 baseline all green.
  S1 add an optional field: drift FAILS first, regenerate, then all green, consumer unaffected.
  S2 rename a consumed field directly: only the compatibility test FAILS and names the missing field.
  S3 safe rename: add the new field, keep the old one with deprecated: true, all green; then remove the old field after updating the consumer test, all green.
  S4 remove a consumed field: compatibility FAILS.
  S5 change a field type (string to integer): compatibility FAILS with a type message.
  S6 change code, forget to regenerate: drift FAILS with the exact message.
- Run the whole thing with the real Maven build. Paste the real summary table. If I am on Windows and you cannot run PowerShell, say so and run the shell version through Git Bash or WSL if available; label what was not executed.
GATE 6: summary table with every scenario matching expectation (EXECUTED), and git status clean of scenario leftovers.

PHASE 7, PACKAGING AND FULL BUILD
- Confirm OSGi: show the bundle manifest Import-Package has no io.swagger.*; dependency scopes are correct (P3).
- Run the full reactor build the way my CI does (mvn clean install or verify, all modules) and static analysis. Fix anything your changes introduced.
GATE 7: full build green (EXECUTED).

PHASE 8, PACTFLOW DOCUMENTATION (documentation only)
- Write docs/pactflow-ci.md with exact commands using env vars PACT_BROKER_BASE_URL and PACT_BROKER_TOKEN (never hardcode secrets): pactflow publish-provider-contract (with --provider, --provider-app-version, --branch, --content-type application/yaml, --verification-exit-code, --verification-results, --verification-results-content-type), pact-broker publish for the consumer pact (--consumer-app-version, --branch), can-i-deploy for both sides (--pacticipant, --version, --to-environment), record-deployment. Add a short Jenkins or GitHub Actions snippet matching what this repo uses.
- Verify command and flag names against the official Pactflow docs by web lookup if you can. Anything you cannot verify, mark "NOT VERIFIED".
- Add a one-page "How to change the AEM response safely" guide: edit the class, regenerate, run verify, how breaking changes are blocked, the expand and contract procedure, and how the consumer team is notified (Pactflow webhooks; note that contract-requiring-verification applies to classic pact, so state which event names you could and could not verify).

SELF-VALIDATION (do this before the final report; it is the part I care about most)
V1. Adversarial check of your own tests. Prove each guard can actually fail: (a) change a field name in the response class without regenerating, drift test must go red; (b) regenerate after renaming a consumed field, only the compatibility test must go red; (c) break the servlet output (for example return a wrong status) and confirm the conformance test goes red; (d) delete the pact file and confirm a clear failure. Revert each change and show the tests green again. Paste the real output.
V2. Re-read every requirement in this prompt and tick it against evidence. Any requirement without executed evidence must be listed as NOT EXECUTED with the reason.
V3. Review your own diff: no changes to unrelated files, no leftover scenario files, no secrets, no TODOs, no commented-out code, consistent formatting, no new warnings from the repo's static analysis.
V4. List every assumption you made, every version you added, and every place where behavior could differ on a real AEM instance (Sling Mapping, Dispatcher filters, servlet resolver allowed paths such as /bin/, authentication).

FINAL REPORT FORMAT
1. One-paragraph summary and assumptions (max 8 lines).
2. File tree of everything added or changed.
3. Dependency changes with scope and reason (test-only vs provided vs embedded).
4. Each new file's full path and content (long files may be summarized with the key methods, but give me complete content for the servlet change, response classes, builder, drift test, conformance test, consumer test, checker and runner scripts).
5. Phase gate results and scenario summary table, each block labelled EXECUTED or EXPECTED, NOT EXECUTED.
6. Pactflow commands and CI snippet.
7. Developer workflow guide.
8. Evidence table: acceptance criterion, command, result, EXECUTED or NOT EXECUTED. Then known limitations and next improvements.

ACCEPTANCE CRITERIA
- A fresh clone runs the module build and passes with no manual steps.
- Changing response classes without regenerating the YAML fails the build.
- The real servlet output validates against the YAML, including the not-found and other error paths.
- Renamed, removed or retyped consumed fields are detected by the compatibility check and named in the failure; added optional fields and the expand-and-contract path pass.
- The YAML is never edited by hand after the first generation.
- Servlet behavior is unchanged (Phase 1 test green before and after).
- Compiles on Java 21, respects OSGi packaging, full reactor build stays green.