state-machine: Determination create omits required expeditedFlagged; Zod rejects every list/get response

[lkacenja]

Summary

The intake.application.submitted handler in eligibility-state-machine.yaml POSTs a Determination without setting expeditedFlagged. The resolved Determination schema marks the field as required and non-nullable, so generated Zod clients reject every list/get response with expected boolean, received undefined. Same class as #342 commit 2 ("engine didn't auto-default required-nullable fields on create") but for a required NON-nullable scalar that the engine deliberately doesn't auto-default — caller must supply it.

Related to #358 (state-machine procedure bodies are out of sync with the resolved schema), but a distinct fix surface: this one needs a one-line addition to the procedure body.

Repro

After a submitted application, fetch the Determination:

curl -s 'http://localhost:1080/eligibility/determinations?applicationId=<uuid>' | jq '.items[0]'

Response (note the missing expeditedFlagged):

{
  "applicationId": "f1e10a00-...",
  "programs": ["medicaid", "snap"],
  "status": "in_progress",
  "id": "4e467c20-...",
  "createdAt": "2026-06-17T21:24:55.642Z",
  "updatedAt": "2026-06-17T21:24:55.642Z"
}

Resolved Determination schema:

Determination:
  required:
    - applicationId
    - status
    - expeditedFlagged    # required, non-nullable boolean
  properties:
    expeditedFlagged:
      type: boolean
      description: >
        Whether the application was flagged for expedited SNAP processing
        (7 CFR § 273.2(i)). Set at submission based on the rules engine
        expedited screening call.

Generated zDetermination then parseAsync throws on every consumer fetch:

ZodError: [{
  "expected": "boolean",
  "code": "invalid_type",
  "path": ["items", 0, "expeditedFlagged"],
  "message": "Invalid input: expected boolean, received undefined"
}]

Root cause

eligibility-state-machine.yaml intake.application.submitted handler:

- call:
    POST: eligibility/determinations
    body: {applicationId: $this.subject, programs: $this.data.programs, status: in_progress}
    description: Create a Determination for the submitted application

expeditedFlagged is required by the schema (required: [applicationId, status, expeditedFlagged]) but is not in the request body. The mock-server engine's extractRequiredDefaults (fixed in #342) auto-defaults required-nullable fields but deliberately leaves required non-nullable scalars to the caller — by design, so missing values surface as real validation gaps. In this case the caller IS the bug.

Per the description text on the field — "Set at submission based on the rules engine expedited screening call" — the initial value should be false, and the rules engine flips it to true later via the flagExpeditedDetermination action (which already exists at /determinations/{determinationId}/flag-expedited).

Expected

Determination.expeditedFlagged populated on every Determination response. Initial value false; the existing expedited screening adapter promotes it to true when criteria are met.

Suggested fix

One-line addition to the create-POST body in eligibility-state-machine.yaml:

   - call:
       POST: eligibility/determinations
-      body: {applicationId: $this.subject, programs: $this.data.programs, status: in_progress}
+      body: {applicationId: $this.subject, programs: $this.data.programs, status: in_progress, expeditedFlagged: false}
       description: Create a Determination for the submitted application

Downstream symptom

In cbms-steel-thread, the same useMedicaidRteDecision hook that #358 affects also hits this — the listDeterminations SDK call rejects the response before the hook can inspect Decisions. Workaround applied: overlay action that removes expeditedFlagged from Determination.required. The workaround should be removed once this issue is resolved AND the contracts pin advances past the fix commit.

Detected in

@codeforamerica/safety-net-blueprint-contracts and -mock-server at commit 4d5d4b9aa4a13065356a89e1d167af75ccc6c31a (current main).

[lkacenja]

Adding a second instance of the same class while implementing the downstream workaround.

Second site

intake-state-machine.yaml creates the SNAP Interview obligation with this body:

- call: {POST: intake/applications/interview, body: {applicationId: $task.subjectId}}

The resolved Interview schema requires appointments (an array<uuid>):

Interview:
  required: [id, applicationId, appointments, createdAt, updatedAt]
  properties:
    appointments:
      type: array
      readOnly: true
      items: {type: string, format: uuid, x-relationship: {resource: External}}

The mock-server returns the Interview without appointments, so the generated zInterview rejects every list/get response with expected array, received undefined:

{
  "applicationId": "f1e10a00-...",
  "id": "634a4a6c-...",
  "createdAt": "2026-06-17T22:38:39.572Z",
  "updatedAt": "2026-06-17T22:38:39.572Z"
}

Suggested fix

Mirror image of the expeditedFlagged fix above — one-line addition to the create-POST body:

- - call: {POST: intake/applications/interview, body: {applicationId: $task.subjectId}}
+ - call: {POST: intake/applications/interview, body: {applicationId: $task.subjectId, appointments: []}}

Required arrays already auto-default to [] in the engine (see extractRequiredDefaults from #342 commit 2), so this might be a separate engine miss — but the procedure-side fix is the safest belt-and-suspenders.

Downstream symptom

Steel-thread Phase 5's useInterview hook hits this immediately on Leslie Trent's task. Workaround applied: overlay action that removes appointments from Interview.required until upstream lands. Comments on the workaround block reference this issue, so it disappears in one edit when the contracts pin advances.