Thanks for working on this. I reviewed the latest head from the API entry points down to the evaluator registry.

Runtime path checked:
OptionRule -> Condition -> ConditionEvaluators.evaluate(...) -> the new MAP_* operators in ConditionEvaluators.

The implementation is straightforward and the tests in ConfigValidatorTest cover the main user-facing cases well enough for this change: non-empty maps, single required key, multiple required keys, and composition with and(...).

I did not find a blocker in the code itself.

Merge conclusion: can merge after CI is green

1. Blocking items

• No code blocker found in the latest diff.
• The current red CI does not look caused by this PR. The failing check is connector-jdbc-e2e-ddl, and the failure is in SqlServerSchemaChangeIT (expected: 9, actual: 0 in the schema-evolution assertion path), which is outside the API validator surface changed here.

2. Suggested follow-ups

• Please rerun or resync once the unrelated CI issue is cleared.

Overall, the map-condition addition itself looks sound to me.

+1
LGTM

+1 I fixed the minor Javadoc naming inconsistency directly since it was a small cleanup, and the rest of the PR looks good to me.

Thanks for the update. I re-reviewed the latest head ae30eada271af4f6b9611488ce924f560f3f5e30 from the API entry points down to the evaluator registry again.

I noticed @davidzollo and @dybyte already rechecked the latest head. After my own rereview, I agree with that conclusion: the API-side map validators still look sound, and the follow-up Javadoc cleanup keeps the public docs aligned with the actual factory methods.

What this PR solves

• User pain: today OptionRule can validate scalars, strings, and collections, but there is no built-in way to say that a map must be non-empty or contain required keys.
• Fix approach: add MAP_NOT_EMPTY, MAP_CONTAINS_KEY, and MAP_CONTAINS_KEYS operators, expose them through Conditions, and document them in EN/ZH architecture docs.
• One-line summary: this gives plugin authors a first-class way to validate map-shaped config without custom ad hoc checks.

Simple example:

• Before this PR, a connector author who wanted to require bootstrap.servers inside a map had to write custom validation outside the shared condition system.
• After this PR, the same rule can be expressed directly as Conditions.mapContainsKey(...) and runs through the same validator pipeline as the existing numeric/string/collection checks.

Full runtime chain I checked

option validation
  -> OptionRule.builder().required(...)
  -> Condition created by Conditions.mapNotEmpty / mapContainsKey / mapContainsKeys
  -> ConfigValidator validates the configured option
  -> ConditionEvaluators.evaluate(...)
      -> dispatches to MAP_NOT_EMPTY / MAP_CONTAINS_KEY / MAP_CONTAINS_KEYS
      -> returns pass/fail for the user-facing validation error path

Findings

• The new operators are wired through the full validator chain consistently.
• The added ConfigValidatorTest cases cover empty-map, required-key, multi-key, and composed-condition scenarios.
• The EN and ZH architecture docs were updated together.
• I did not find a code blocker on the current head.

CI

I also checked the current failed Build on this head. One concrete failing job is:

• unit-test (11, ubuntu-latest): SeaTunnelClientTest.testSetJobIdDuplicate

The broader Build also includes unrelated E2E failures outside the API validation surface. I do not see evidence that those failures are caused by this map-condition change.

Merge conclusion: can merge

1. Blocking items

• No blocking code issue from my side on the latest revision.

2. Suggested follow-up

• Please rerun or resync once the unrelated CI failures are cleared so the branch has a green merge signal.

Thanks for keeping the API and documentation updates together here.