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

# Effort modes

> Effort is a policy profile — breadth, reasoning passes, validation depth, parallelism, and a terminating time budget. It is never a token quota, and it never changes what is authorized.

```bash theme={null}
myrqen low
myrqen high
myrqen xhigh
myrqen ultra
myrqen auto        # resolve from the project's size, surface, and risk
```

<Warning>
  Higher effort means more depth, never fewer rules. The safety policy and the
  authorization gates are identical at every level.
</Warning>

## The profiles

Exact values from `packages/policy/src/effort.ts`:

|                               | `low`   | `high` | `xhigh` | `ultra`       |
| ----------------------------- | ------- | ------ | ------- | ------------- |
| Reasoning passes              | 1       | 2      | 3       | 4             |
| Validation passes             | 1       | 2      | 3       | 4             |
| Max parallel investigations   | 2       | 4      | 6       | 8             |
| Wall-clock budget             | 8 min   | 25 min | 50 min  | 110 min       |
| False-positive challenge pass | no      | yes    | yes     | yes           |
| Identity matrix depth         | 1       | 2      | 3       | 3             |
| Breadth                       | focused | broad  | broad   | comprehensive |

<AccordionGroup>
  <Accordion title="low — fast developer signal">
    A rapid repository map, high-signal source, configuration, secret, and dependency
    checks, a focused local runtime smoke test where one is available, validation of
    obvious high-impact candidates, and minimal exploratory branching.
  </Accordion>

  <Accordion title="high — the serious default">
    Broader route, authentication, and data-flow analysis; targeted runtime validation;
    access-control identity comparisons; deeper validation and deduplication; remediation
    context.
  </Accordion>

  <Accordion title="xhigh — pre-release depth">
    Multiple reasoning and validation passes, wider business-logic and cross-route
    analysis, more identity and state combinations, and stronger independent confirmation
    before an important hypothesis is closed.
  </Accordion>

  <Accordion title="ultra — maximum practical local depth">
    Comprehensive source and runtime surface mapping, repeated validation and
    alternative-path analysis, a broad local test matrix, an extra false-positive
    challenge pass, and detailed coverage and limitations.

    `ultra` must still terminate. The wall-clock budget is what makes that a guarantee
    rather than an intention, and progress is shown rather than silently looped.
  </Accordion>
</AccordionGroup>

## How `auto` resolves

`auto` scores the project's risk and surface, then maps the score to a profile.

Signals and their weight:

| Signal                                                           | Score                  |
| ---------------------------------------------------------------- | ---------------------- |
| Authentication implementation detected                           | +2                     |
| Role or privilege separation detected                            | +2                     |
| Payment or billing integration detected                          | +2                     |
| Database access layer detected                                   | +1                     |
| File upload or download surface detected                         | +1                     |
| Server-side outbound requests detected                           | +1                     |
| One or more external origins referenced by project configuration | +1                     |
| 60 or more routes mapped                                         | +2 (20–59 routes: +1)  |
| 900 or more source files                                         | +2 (250–899 files: +1) |

The mapping:

| Score     | Resolves to |
| --------- | ----------- |
| 9 or more | `ultra`     |
| 6 to 8    | `xhigh`     |
| 2 to 5    | `high`      |
| 0 to 1    | `low`       |

Both values are recorded — `requested: "auto"` and the resolved profile — so results stay
comparable across runs. The rationale is a list of plain sentences you can read back:

```json theme={null}
{
  "requested": "auto",
  "resolved": "xhigh",
  "rationale": [
    "auto resolved to \"xhigh\" (risk/surface score 7).",
    "Authentication implementation detected.",
    "Role or privilege separation detected.",
    "Database access layer detected.",
    "34 routes or endpoints mapped.",
    "No local runtime was reachable, so dynamic validation depth is reduced for this run."
  ]
}
```

Three conditions are appended to the rationale as honest caveats rather than being
silently absorbed:

* no local runtime was reachable, so dynamic validation depth is reduced,
* fewer than two test identities are configured, so object-ownership comparisons may be
  limited,
* isolated runtime checks are unavailable on this machine.

## What effort does not do

* It does not change what is authorized. `assertEffortDoesNotWeakenSafety` exists
  precisely so this cannot drift.
* It is not a token budget. Token usage is *reported* with provenance
  (`exact`, `estimated`, `unavailable`), never *allocated*.
* It does not make the scan omniscient. `ultra` is deeper, and the report still states
  what was not assessed.