Skip to content

Run the Case (Block 3e)

The plan is checked but has never met a real claim. This block deploys it and finds out what it actually does. Several deploy cycles are the normal shape of this block. The discipline is that each cycle ends with a named defect and a fix, not with "tried again."

The prompt

Prompt — block 3e · Run it
# Run Maestro Case and test it: the clean claim, then the four possible routes involving human review

Case Plan is checked, but not tested yet on real claims. Compile, Pack, Publish and Deploy with the **`uipath-solution`** skill. Run it to find out what the plan actually does. It is normal for it to take several deploy cycles, each one should end with a named defect and fix.

Aim each run with the case's own `scenario` / `discrepancy` inputs (and `profileId` to repeat a claimant) — they flow to the generator (`contracts/provided-processes.md`, *Retrieve Property Claim*); a scenario alone does not guarantee a route — pin a `discrepancy` with it, preferably an unambiguous breach (`cookbook.md`).

Complete the Action Center tasks from the command line (`uip tasks complete`) — the Coded Action App has no screens yet, only the empty-page registration the case binds. A route that misbehaves now is a case defect; the point is to find case-plan issues before the app is live. Read the record while a gate task is still open, before you complete it: the reviewer sees what is on it then, and a write that lands only after the gate is hidden once the task is done.


**Done when:**
- a claim with nothing wrong with it goes in and a settled claim comes out, with no human touching it and no task ever raised. That is the run that proves the whole case (happy path), the Action Center task never appears. Read the Data Fabric record and the case instance's timeline instead.
- four human routes proven: proceed and refuse at the first gate, approve and deny at the second. 

Five runs prove the block; a broken version costs more, so start one claim on each new version before the batch. The Data Fabric record populated by the end of this block: the next block builds the Action App's screens against these payloads.

Steps:

  • Compile the case plan to BPMN (uip maestro case pack)
  • Wire the RPA / Agent / connector task inputs and outputs
  • Recompile and validate
  • Solution pack, publish, deploy for the first time
  • Run the auto-settle claim (happy path, no human)
  • Run the four human routes (proceed/refuse at the first gate, approve/deny at the second)
  • Verify and fix all five routes; check the data landed on the claim record
  • Upload the solution to Studio Web
  • Update PROGRESS.md

What the agent will review

  • The clean claim is the acceptance run. A claim with nothing wrong traverses the whole lifecycle unattended. No task ever appears. Read the Data Fabric record and the case instance's trace instead: the checks, the findings and the letter should all be there. A flagged clean claim means the Agents are wrong, not the case.
  • Four human routes, answered from the command line. The app has no screens yet and doesn't need them. A route that misbehaves now is a case defect, and finding it before the screens exist is the objective.
  • Read the record while a gate is open. Completing the task lets the next write fill the columns, which hides a missing write before the gate. Read what the reviewer would see, then answer.
  • One claim first on every new version. A broken version costs a whole batch; one claim through Analysis tells you in minutes.
  • One identity. A single claim number spans the case, the three documents, the letters and the record's key.
  • Letters are logged, never sent. No mail leaves the exercise: the notification process records every letter (claim, stage, recipient, subject, body) in a tenant-level entity. The reviewer's screen will later show the thread from it, and Verify will read decisions from it.

Proof

A clean claim goes in; a settled claim comes out, no human touching it and no task ever raised. Then all four human routes pass, each proven from the CLI and each landing its data on the record.