[stevehu]

Migrate the native Lambda application to Jackson 3 and the shared mapper policy. CI builds and invokes the executable against a bounded loopback Runtime API fixture; this is not live AWS qualification.

CI pins policy f0d2100f972eec765b2b276e7ace38922394f0a6 and qualified core 97b2359b92ed3e1d05cac04f2da8760aa954e49d. The complete prerequisite closure is checked in at ci/jackson3-source-refs.json, initialized from successful run manifests. Missing/malformed pins fail before resolution; default CI performs no default-head or migration-branch lookup. Explicit replay overrides merge into the complete map and remain subject to core/prerequisite qualification. Core tests reuse verified evidence; other prerequisites and full consumer suites remain enabled. The source-origin audit covers NetworkNT releases and snapshots, with only the explicit digest-pinned validator release exception.

Core-pin adoption used merged light-4j #2826 and its reviewed acceptance record. Producer 40371926971, forced renewal 40371900445 and normal reuse 40373717464 passed for the exact core/policy/prerequisite tuple. No open core branch or obsolete policy pin is used.

The AWS Lambda prerequisite now pins the actual #168 merge commit dddbbc9e7f6f690f8688ceac024728b6a84f4808, verified as an ancestor of fetched AWS master. No remaining prerequisite pin or mapper policy changes in this update.

Validation: run 40435467504 passed on exact head 6e4737e40242e2f45e071dd3130cd48fbdec5c04. Downloaded reports confirm 98 tests, 4 skipped and zero failures/errors. The resolved source closure exactly matches the manifest, including actual AWS Lambda #168 merge dddbbc9e7f6f690f8688ceac024728b6a84f4808; the strict artifact audit reports no Jackson 2 runtime dependencies or source-origin failures. Native packaging checks and the executable loopback Runtime API smoke passed; the retained log confirms API Gateway binding, health response and builder error serialization. This is not live AWS qualification. The approved mapper-extraction and schema-isolation follow-ups are not included here. No release, deployment or consumer merge.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[stevehu]

Reviewed the diff at df3e5e2 plus reflect.json and native-image-linux.sh. I did not run the build or tests.

1. The native executable is built but never invoked. Jackson3NativeCompatibilityTest runs only on the JVM, and reflect.json is unchanged: it registers the AWS event types and DefaultResponse/InvocationResponse but nothing Jackson 3 specific. If that is insufficient, the image builds fine and fails at event binding on every invocation. The README discloses incomplete reflection coverage, but the repo already has test-event.json, so a smoke step running the binary against it would turn this into a test.
2. There are no checks on this PR at all (its only workflow creates sync PRs), so "CLEAN" says nothing about the build.

[stevehu]

Review of head 91c4fd7. I read the diff since my last review and ran nothing; test is green.

My earlier points look addressed (the rename to JacksonDefaults, the pinned policy and core SHAs, and the shared resolver).

One point on the workflow: policy, core, yaml-rule and http-client are pinned, but json-overlay, openapi-parser and light-rest-4j resolve to their current default-branch heads, and light-aws-lambda still uses the migrate-jackson-3 branch lookup. Once #168 merges that lookup falls through to the default branch, so after merge this repo's master CI builds against whatever those repos hold that day. An unrelated change there turns this repo red or changes what was qualified, and a run cannot be reproduced from this repo alone. Pinning those prerequisites by SHA, or documenting them as intentionally floating, would match the stated reproducibility goal.

[stevehu]

Review of head 8d6db07. I read the diff since my last review and ran nothing; test is green.

My earlier point looks addressed: ci/jackson3-source-refs.json pins the complete closure by SHA, the workflow validates the key set and core SHA, and the branch lookups are gone.

One follow-up. The manifest's light-aws-lambda pin is d68d2b3, which is a commit on the still-open #168 branch and is no longer its head (it is at 86a8fa4, because #168 then added its own manifest commit). After #168 merges, this repo's master CI keeps building the pre-merge commit, not what landed, and nothing says how to repoint the pin. A short repin step per sibling merge, and ideally a check that fails when a pinned SHA is not an ancestor of that repo's default branch once the sibling is merged, would close this.