4. Fixing

We've monitored the service and diagnosed the problem. Now let's take action — create a GitHub issue with the diagnosis.

The fix function

let create_issue diagnosis =
  let title = "[Auto] " ++ .severity diagnosis ++ ": " ++ .root_cause diagnosis in
  let body = to_json {
    severity: .severity diagnosis,
    root_cause: .root_cause diagnosis,
    suggested_fix: .suggested_fix diagnosis,
    source: "self-healer agent"
  } in
  github_post {
    url: "https://api.github.com/repos/myorg/myapp/issues",
    body: to_json {title: title, body: .suggested_fix diagnosis, labels: ["auto-healer"]}
  };

This function:

• Builds a title from the diagnosis fields (.severity, .root_cause — prefix field access)
• Creates the GitHub issue body as JSON using to_json
• Posts to the GitHub API using github_post — our HTTP POST capability scoped to api.github.com

The inferred type:

create_issue : {severity: String, root_cause: String, suggested_fix: String}
  -> Result<String, QosmError> ! {Http.Post}

Only Http.Post — this function doesn't make LLM calls or read from the service. Each function does one thing, and the types prove it.

Only act on real problems

We don't want to create issues for "info" level diagnostics:

let maybe_fix diagnosis =
  match .severity diagnosis with (
  | "critical" -> create_issue diagnosis
  | "warning" -> create_issue diagnosis
  | _ -> Ok{value: "No action needed"});

Pattern matching on the severity string — only "critical" and "warning" trigger an issue. Everything else gets a pass.

The three capabilities in play

At this point, our agent uses all three capabilities:

| Function | Effects | What it does | |----------|---------|-------------| | check_health | Http.Get | Fetches the health endpoint | | diagnose | LLM.Call | Analyzes errors with the model | | create_issue | Http.Post | Creates a GitHub issue |

Each function uses exactly the capabilities it needs — nothing more. The type system makes this visible and verifiable.

Next: Putting It Together →