Allow wpml_cf_preferences: 2 on image/gallery fields (Options Page house rule)

[parisek]

Summary

Four commits. The first widens a schema enum; the next three build and then harden a new --wpml linter check that the widening made necessary.

1. 487875e — allow wpml_cf_preferences: 2 on image/gallery (Options Page house rule)

• field-image.schema.json / field-gallery.schema.json enforced an unconditional const: 1, curated against a live install in a post_type/block location context.
• On an ACF Options Page, ACFML permanently locks a 1-flagged ("copy") field to its default-language value — there's no post duplication to copy from. tailwind-base's wordpress/gutenberg.md § Key Requirements and wordpress/wpml.md's gotcha table both document 2 for every value field on an options page, image/gallery included.
• The schema has no per-location context threaded into per-field-type validation (a nested field doesn't know its ancestor group's location), so a conditional rule isn't expressible without a large restructuring. Both refs now accept enum: [1, 2] — the same trade-off already made for field-link/field-select/field-url.
• Discovered while auditing parisek/definition-kit PR fix: unify field validation across nesting, complete per-type stubs (closes #8) #10's store-locator corpus fixture.

2. 43d40a4 — new --wpml location-value cross-check

The enum widening fixed the options-page false positive but opened a false negative in the far more common post/block context: an image/gallery field mistakenly set to 2 now validated silently, and translators lose per-language image swapping.

AcfLinter is the only place with both fields and location in view at once, so the check lives there (wpmlLocationValueFindings(), gated behind --wpml) rather than in the schema, which stays context-neutral by design.

3. 15b3ca6 — heterogeneous OR groups misclassified

classifyLocationContext() tracked only options_page vs post_type/block booleans; every other ACF param was invisible. A group located at options_page OR taxonomy collapsed to pure options-page context and demanded the options-page value from fields that also render on a term screen — contradicting the method's own documented policy of leaving genuinely dual-context groups alone.

4. 5c1a0ce — per-OR-group classification

The 15b3ca6 fix used one global flag, which could not distinguish "two AND-rules in one OR-group" from "two separate OR-groups". That silenced post_type AND page_template — one of the most common real ACF shapes — trading a false positive on a rare shape for a false negative on a common one.

Classification now runs per OR-group and unions the verdicts. All 24 params from location-rule.schema.json are assigned deliberately:

Bucket	Params
Primary post/block	post_type, block
Primary options	options_page
Post-context qualifier	page_template, post_template, post_status, post_format, post_category, post_taxonomy, post, page_type, page_parent, page, attachment
Neutral	current_user, current_user_role
Other (distinct context)	taxonomy, user_form, user_role, user, comment, widget, nav_menu, nav_menu_item

Behavioural widening worth calling out: besides fixing the AND-group regression, this also newly activates standalone qualifier groups. A group whose entire location is e.g. [[page_template == consulting.php]], with no post_type at all, previously resolved to ambiguous and was skipped; it now resolves to post-context and is checked. This is intentional — page_template can only ever apply to a post/page screen — but it is broader than "an AND-group fix" and will surface findings on files that were silently skipped before.

operator is deliberately ignored: post_type != page still means a post-type context, so the demanded value is unchanged by negation. Documented in the classifier's docblock.

Test plan

• Failing tests written first at each step and confirmed to fail for the right reason before the fix.
• composer test green — 162 tests, 607 assertions (1 pre-existing skip: SnapshotTest, requires a live WP install).
• composer phpstan green, no baseline or ignores added.
• src/templates/refs/ (source of truth) and schemas/refs/ (distribution mirror) edited identically — SchemaConsistencyTest passes.
• Real-corpus run (--wpml --strict, read-only) against eprukaz2025 unchanged before/after 5c1a0ce. Noted explicitly: that corpus is all single-context block locations, so it does not exercise this bug — the unit tests are the evidence, not the unchanged count.
• Cross-project validation: four real multi-param location shapes found across sibling projects (page_template + post_type, post_template + post_type, user_form + user_role, and a 6-group post_type/post_template mix) all classify correctly, no false positives.
• CHANGELOG.md [Unreleased] entry added.

Known gap (non-blocking)

Regression coverage is thin relative to the 24-param table: only page_template and post_status are exercised as qualifier regressions, and no other-bucket param has a dedicated "mixed with post_type stays null" test. A future refactor could silently flip one of the 9 untested qualifier assignments without any test failing. Worth a follow-up; not a merge blocker.

https://claude.ai/code/session_01J51xpeny2K3mm3LCFVGc2w