> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tasksmind.com/llms.txt
> Use this file to discover all available pages before exploring further.

# From Customer Report to Pull Request

> How a customer-reported bug becomes a tested, human-approved pull request.

A customer posts a problem in Slack. Instead of someone manually filing a ticket and waiting,
tasksmind investigates, drafts a fix, tests it, and hands your team a PR to approve.

## The scenario

A customer posts in the Slack channel connected to your support project. tasksmind is already
watching that channel, so nobody has to notice, triage, and file a ticket first. The report
itself starts the pipeline.

## What it looks like

**#support**

**Jordan (customer)** · 3:41 PM
hey, my export keeps failing and just says "something went wrong." anyone know what's up?

**tasksmind** <Icon icon="bot" size={14} /> · 3:41 PM
Thanks for flagging this. Looking into it now, I'll update this thread as soon as I know more.

<br />

**In your team's dev channel**

**tasksmind** <Icon icon="bot" size={14} /> · 3:42 PM
New incident from `#support`: export failure reported by a customer. Investigating, pulling
recent commits and related PRs.

**tasksmind** <Icon icon="bot" size={14} /> · 3:44 PM
Root cause: the CSV export job times out on accounts with more than \~50k rows, in
`jobs/export.ts`. Risk: **low**. Running your test suite in a sandbox before proposing a fix.

**tasksmind** <Icon icon="bot" size={14} /> · 3:46 PM
Tests passed. Opened a draft fix: **Approve** / **Request Changes** / **Stop** / **Escalate**
below.

## What's really going on

<Steps>
  <Step title="Incident created">
    A customer's message in your connected support channel creates the incident and posts an
    "investigating" update for your engineers.
  </Step>

  <Step title="Investigate">
    tasksmind reads the report and your code to pinpoint the root cause. If the report is too
    vague, it asks a clarifying question in the customer's thread rather than guessing.
  </Step>

  <Step title="Risk classification">
    Before a fix is drafted, it's scored for risk. This is a hard gate: if the risk score can't be
    recorded, the fix doesn't get generated.
  </Step>

  <Step title="Sandbox test run">
    Your test suite runs in an isolated sandbox unless a project has explicitly turned that off. A
    project can also override exactly which commands run.
  </Step>

  <Step title="Your approval">
    tasksmind opens a pull request and posts it in Slack. One of your engineers reviews it,
    approves it, and merges. tasksmind never merges on its own.
  </Step>
</Steps>

<Note>
  Approving and merging are always human actions. Fixes flagged as high-risk, or that skipped or
  failed sandbox tests, are called out clearly so they never get merged casually. See
  [the approval and safety gate](/use-cases/approval-and-safety) for details.
</Note>

<CardGroup cols={2}>
  <Card title="The approval & safety gate" icon="shield-check" href="/use-cases/approval-and-safety">
    What has to be true before a fix can merge.
  </Card>

  <Card title="Customer support, without the leak" icon="users" href="/use-cases/support-escalation">
    What the customer sees versus what your engineers see.
  </Card>
</CardGroup>