[e54-bot]

Documents the locale field that wright sends and opy-provider reads, as new spec section 8.3. No version or behavior change: the field is optional and unknown fields are already ignored (§19.1).

Refs #42. This does not decide the issue's open question (provider-defined fallback vs invalidParams for an unserved locale). §8.3 states that behavior is provider-defined and requires no outcome. Left for #42: that decision, and whether to keep or drop the opy locale-unsupported diagnostic as the reference behavior.

Correction to the issue text: locale is the Workshop client locale for locale-dependent text (for example enum member spellings, read from source and written into the artifact). It is not the source/output language, which languageId identifies. §8.3 says so. I did not edit the issue.

Verified behavior:

• wright (wright-lpp/src/provider.rs, entry_params) sends locale on entry-based check/compile only, and omits it when unset.
• opy-provider accepts locale on documents and entry requests, defaults to en-US, matches case-insensitively, returns -32602 for a non-string, and gives locale-unsupported (error diagnostic, artifact: null) from compile for an unserved locale.

Changes:

• project-loading.md §8 table and §8.3; analysis-and-compilation.md §9.1/§10.1; conformance.md method table.
• Mock provider validates locale as a string.
• Fixture 68-locale-param: the -32602 steps fail if the mock stops validating the type. The valid-locale steps cannot fail on the mock, which has no locale-dependent text, and the description says so.

Validation at head: cargo fmt --all --check, cargo clippy --locked --workspace --all-targets -- -D warnings, cargo test --workspace --locked, fixture validation, and 68/68 conformance against the mock pass.

[Teakowa]

Verdict: changes requested (round 1). The text matches the implementations, but it also decides the open question from #42 as a new normative rule.

I confirmed against current opy-rs main (5eb983b, debug build from that commit):

• The wright client (wright-lpp/src/provider.rs:672-679, entry_params) adds locale only when set. It sends it only on entry-based check/compile.
• opy-provider takes locale on documents and entry requests, defaults to en-US, and returns -32602 for 5 on both check and compile.
• The locale is case-insensitive (ZH-cn behaves like zh-CN). zh-CN compile writes a Chinese artifact.
• xx-YY gives a locale-unsupported error diagnostic with artifact: null from compile. Check returns no diagnostics.

Blocking: docs/spec/project-loading.md §8.3, last-but-one bullet.
"A locale string that the provider does not serve MUST NOT fail the request with -32602" is a normative choice. Issue #42 lists "provider-defined fallback vs invalidParams" as undecided. The author states it is not decided. This bullet decides it in favor of "never -32602". It is also unenforced: no fixture covers it, and a provider that returns -32602 for an unknown tag becomes non-conformant from this PR alone.

• Fix, either way:
  • (a) Make the bullet descriptive: the behavior for an unserved locale is provider-defined; the opy provider reports locale-unsupported; and the spec does not require a specific outcome. Or
  • (b) Record the maintainers' decision on #42 first, then keep the MUST NOT.

Two smaller points on the same section, which I treat as part of the same fix:

1. "A client that has no locale to state MUST omit the field" adds a client obligation. wright satisfies it, but no source in the issue requires it. Use SHOULD or drop it.
2. "check and compile ... MUST judge locale-dependent spellings the same way" is a new cross-method MUST. Only opy-rs tests it (opy-provider/tests/lpp.rs, issue #620). The conformance suite cannot enforce it with the mock.

Fixes #42: justified only after the blocker above is resolved. With option (a), the issue's "add field with defined semantics" half is done, so use Refs #42 and say what is left. Keep Fixes only if the decision is recorded on the issue.

Fixture 68-locale-param.json:

• The type-rejection steps work. I changed the mock's locale to Option<Value> and got 67 passed, 1 failed (locale-param: step 3 missing key 'error'). With the unmodified PR it is 68 passed.
• The valid-locale steps cannot fail, because the mock ignores the value. The description says "return the same result as without it". That is false for a provider with locale text, such as opy where zh-CN changes the artifact. Reword to say that this holds for the demo language, which has no locale-dependent text.

Also: the issue text calls locale the "source/output language". §8.3 says it is the Workshop client locale and not the source language. That matches the implementations. Please note the correction on #42.

Checked, no problem: no protocol version or behavior change, and the field is optional with unknown-field rules from §19.1. Rust (1.85.0) / Quality and conformance CI jobs pass, and I reproduced 68 passed locally. Not found: .github/docs/pr-review.md does not exist in this repo, so I reviewed against the task instructions.

[Teakowa]

Approve (round 2). All round-1 findings are fixed at a2cd501.

• §8.3 no longer decides #42. The unserved-locale bullet is descriptive: provider-defined, no specific outcome required, with opy's locale-unsupported named as an example. The remaining MUST is the non-string -32602, which the fixture enforces. "Omit the field" is now SHOULD. The check/compile consistency and case-insensitivity points are non-normative.
• The fixture description now says the demo language has no locale-dependent text, so the result equals the no-locale result and other providers may differ.
• §8.3 states that locale is the Workshop client locale and not the source language (languageId).
• The PR body says Refs #42 and states what is left: the fallback-versus-invalidParams decision, and whether the locale-unsupported diagnostic stays the reference behavior.
• Locally: fixture validation and conformance against the mock both pass 68/68. CI Rust (1.85.0) / Quality and conformance are green.