[stevehu]

The source-build manifest still selects the AWS and native migration commits, so integration CI does not exercise the merged shared event mapper and schema-input isolation fixes. Pin AWS to 5913c7c25b01b6d384fd9c39014dc91d63dfc35e (networknt/light-aws-lambda#170, including #169) and native to 5ba49d703b7b2c50bb7f2a99e359e287a541b150 (networknt/light-lambda-native#190).

Only these two manifest values change. The core/policy and remaining prerequisite pins are preserved. This controls the Jackson 3 source-build workflow; it does not alter Maven dependency versions or normal local-build resolution.

Validation: both selected commits are ancestors of fetched upstream master; the workflow's manifest key/hash/core checks pass, and the diff is whitespace-clean. Full source-build CI and its strict artifact audit must pass on this PR head before merge. No local Maven suite was rerun for the manifest-only change.

Current-head CI passed at dfc6654aec2f78e547dab24fc2dd55b0c6884253: https://github.com/networknt/light-codegen/actions/runs/40515293950. Downloaded reports show 85 consumer tests, 6 skipped, zero failures/errors; generated Java and Kotlin projects compile successfully. The strict artifact audit has no failures or Jackson 2 dependencies, and all resolved source SHAs match the manifest, including both updated Lambda pins. Pre-commit also passes.

[stevehu]

Review of head dfc6654. I read the diff and checked GitHub read-only; I did not run any build. test is green and the PR is mergeable. I found no blockers.

The manifest change is two lines: light-aws-lambda moves to 5913c7c (#170, including #169) and light-lambda-native moves to 5ba49d7 (#190's merge commit). Both SHAs are the current heads of those repos' masters, and their post-merge CI runs are green. The other pins are unchanged. I downloaded the PR's source-build-reports: the strict audit has no failures and no Jackson 2 dependencies (76 artifacts checked), and source-refs.json records both Lambda pins as the new SHAs.

Two notes, neither blocking:

1. Manual repins. Each sibling merge needs a manual manifest PR, so the pins can only lag, and nothing alerts anyone when a pin is behind. That is the intended design; a scheduled check that flags a pin behind its default branch would remove the dependence on memory.
2. Ancestry not enforced. Nothing in CI checks that a pin stays on the repo's default branch, so a pin naming a commit on a deleted PR branch would build today and break later. These pins are fine; a merge-base check would catch the case.