Add plugin hook-info field-shape requirements 10-19..10-22

[wangyb-A]

Summary

Adds 5 plugin-suite requirements (10-19..10-23) probing the field shape of every plugin hook's info parameter across SDKs, using the union of SDK field sets as the reference schema.

Design: each handler logs one single-line JSON record per hook event — a canonical camelCase dump of that hook's own info. Unexposed fields are omitted, so a missing key = a failed assertion = an SDK parity gap. Maps → <name>Count; timestamps → ISO-8601 regex; presence-only probes via /.*/; key-absence guards via /.*/ + count: 0. Payload values (execution input/result, operation result) are not part of the asserted schemas. 10-14 on main is untouched.

ID	Hooks probed
10-19	invocation-start / invocation-end
10-20	operation-start / operation-end
10-21	attempt-start / attempt-end (retry, ordered 1→2)
10-22	operation-change (delta item + map membership)
10-23	context-typed ops (parallel): subType, isReplayingChildren

Live validation (us-west-2)

Req	Python	JS	Java
10-19	❌ no operations maps	❌ no isFirstInvocation on end info	❌ no maps / end-side start time
10-20	✅	✅	✅
10-21	✅	❌ failed-attempt-end timestamps	❌ no isReplay
10-22	✅	✅	❌ reduced change item
10-23	✅	❌ no isReplayingChildren	✅
Totals	22/23	20/23	18/21

Every red is a filed SDK gap: aws-durable-execution-sdk-python#617, aws-durable-execution-sdk-js#803, aws-durable-execution-sdk-java#604. Full 10-1..10-18 regression green everywhere.

Land this first — the companion handler PRs (python#615, js#800, java#602) reference these IDs.

[github-actions]

Claude AI review

This PR adds five additive, declarative plugin-suite requirement YAMLs (10-19–10-23) probing the field shape of cross-SDK plugin hook info parameters. No runner code changes.

I reviewed each file against the engine that evaluates it (cloudwatch.py matcher, variables.py placeholder context, history.py, validate.py) and against sibling requirements for convention parity.

No actionable findings. Verifications that passed:

• Match semantics: /…/ values map to re.search(pattern, str(actual).strip()), bare scalars to exact/numeric/bool equality, and a field must be present to match — so presence probes (/.*/), negative probes (count: 0), and value probes behave as intended. All regexes are valid Python ((?i) correctly at pattern start; ^\d{4}-, ^[1-9]\d*$, ^arn: coerce ints/bools via str()).
• Placeholders: ${INPUT_1} comes from Variables; ${ID1}/${CTX_P} are bound by the history matcher, which runs before log validation, so all are resolved when ExpectedLogs substitution runs. No unbound references.
• History/EventIds: wait (10-19) matches 10-16; retry (10-21) matches 1-11/10-13/10-15; single-step (10-20/10-22) matches 1-1; parent-only ContextStarted (10-23) matches 10-18. ExpectedResult shapes decode correctly (raw invocation result vs. serialized '"task-a"' operation result vs. [a-done, b-done] list).
• Cardinality: exact counts and min_count thresholds are consistent with the described invocation/replay flows; after anchors all match ≥1 record (no typo-guard errors); presence-only probes correctly go red when a field is absent (true parity signal, no false-pass).
• IDs/YAML: 10-19–10-23 are unique stems (no 10-2 collision); values are valid plain scalars under the repo's yamllint config.

Residual test risk (inherent, not a PR defect):

• Correctness of the assertions ultimately depends on live SDK behavior; CI only lints the YAML and cannot exercise these against a durable-execution backend, so an authoring error in a probe would surface only at live-run time. The author documents having validated all five live in us-west-2.
• 10-23's min_count: 3 presence probe and the after ordering probes lean on service-side replay/timestamp behavior; the file appropriately asserts key presence (not value) where timing is nondeterministic, and CloudWatch's epoch-ms resolution treats sub-ms events as concurrent (pre-existing engine behavior).
• 10-22's primary probe ANDs the full field set into one count: 1 assertion, so a red does not isolate which field is missing (unlike the decoupled probes in 10-19/10-21). This is a diagnostic-granularity trade-off, not a correctness issue.

Reviewed commit 93d741772685a016167e18a1b06668ea474c2fb1. Workflow run

[github-actions]

Codex AI review

High: These aggregate counts do not correlate records to either branch. Branch A's live and replay records can alone satisfy min_count: 2 when its replay value is legitimately false, allowing an incorrect value for branch B. Likewise, permitted extra reruns can satisfy min_count: 3 even when another fn-start omits the key, contradicting the “every record” requirement. Give branches stable names or bind their IDs and assert each branch separately. To verify key presence across an unbounded number of reruns, emit an explicit hasIsReplayingChildren flag and assert that no record reports false.

[github-actions]

Codex AI review

Found one high-severity false-positive in requirement 10-23. Review was static as required; runtime behavior was not exercised.

Reviewed commit cfcf58e24a6eb317fb9e3906cdfbd97fc835a667. Workflow run