Motir

The receiving half of the wire test. MOTIR-3350 asserts the field leaves motir-core in the envelope; this asserts it arrives and reaches the gate, entering through the job endpoint with a realistic envelope rather than calling the gate directly.

Why it is its own subtask: motirAiClient.ts carries the warning that this envelope is a cross-repo contract that fails closed and silently — a typo on either side produces a validation_error, with no type error and no test. A test that starts from a hand-built context object inside motir-ai would agree with itself about the name and prove nothing. The envelope must be built from the same literal string motir-core sends.

Three cases:

• flag false → the pass files a planning bug, applies existing lessons, and writes no new tenant lesson.
• flag true → the same pass writes one.
• flag absent entirely → behaves as true. This is the version-skew case: motir-core deployed before this change sends no field, and those tenants must keep capturing.

Acceptance criteria

• Entry is the job submission path, with an envelope shaped as motir-core sends it.
• The key in the fixture is the literal wire string, written out in the test, not imported from the code under test.
• All three cases assert on the lesson store, not on a spy or a log line.
• The false case additionally asserts a planning bug was filed and an existing lesson was applied.
• A comment on the fixture names motir-core's constant, so a rename on either side has a thread to follow.

Context refs

• motir-ai src/services/lessonService.ts — captureMistake, the gated call.
• motir-ai — the job entry point and its envelope schema; existing envelope tests are the shape to copy.
• MOTIR-3350 — the producing half; same literal string.
• MOTIR-3351 — the gate under test.