In Allure 3, what can a rule under `resolutions` in `allurerc` match on, and what does a `resolution` of `issue` attach to a failing test?

## Where `resolutions` lives Allure 3 reads its configuration from an `allurerc` file in the working directory - `allurerc.js`, `allurerc.mjs`, `allurerc.json`, `allurerc.yaml` and several other extensions are all accepted, and `--config` overrides the search. Among its top-level keys is `resolutions`, which holds three things: - `knownIssuesPath` - where the run writes `known-issues.json` - `links` - a map of link types to a `urlTemplate` - `rules` - the list of rules themselves This whole surface is **Allure 3 only**. Allure 2 has no equivalent: no `resolutions` key, no known-issues file, and no way to attach a tracker id to a failure from the report's own configuration. ## What a rule may match on Every rule is a matcher plus a decision. Four matcher fields are available: | matcher | matches against | |---|---| | `messageRegexp` | the failing result's error message | | `testCaseId` | a list of ids; the result's case identity must be one of them | | `retryHash` | a list of hashes; the result's own retry hash must be one of them | | `environment` | a list of environment names; the result's environment must be one of them | Two rules about how they combine, and both are easy to get backwards: 1. **A rule must declare at least one matcher.** A rule with none of the four is rejected when the configuration is validated, so the mistake fails loudly rather than quietly matching everything. 2. **Declared matchers are combined with AND, not OR.** A rule carrying both `messageRegexp` and `environment` matches only a result whose message matches *and* whose environment is in the list. Matchers you leave out impose no condition at all. There is a third thing worth knowing about `messageRegexp`: it is applied as an ordinary regular expression **test** against the message, so it is a *search*, not a whole-string match. A rule written `"connection reset"` matches a message that merely contains that phrase. That is the opposite of how some other rule files in this space behave, and it is why a `resolutions` rule tends to end up too broad rather than too narrow. ## Which results are eligible Only results whose status is `failed` or `broken` are considered at all. A passing result is never handed to the rules, so a rule can never mark something green as expected, and a rule cannot be used to force a status. If the failure stops happening, its rule simply matches nothing - silently, with no message anywhere saying that a rule has gone idle. ## What `resolution: "issue"` attaches Each rule declares a `resolution`, one of the three categories `issue`, `muted` or `accepted`. The `issue` category is the one that ties the failure to a tracker item, and it comes with extra structure: - the rule must carry an `issue` object with an `id` and a `type` - the `type` must name a key in `resolutions.links` - that link entry's `urlTemplate` must contain **exactly one** `%s`, and must resolve to an absolute `http` or `https` URL once the id is substituted - each `issue.id` must be unique across the rule list All four are enforced when the configuration is validated, so a typo in `type`, a template with two placeholders or none, a relative URL, or a duplicated issue id each stop the run with a configuration error rather than producing a broken link in the report. The `%s` placeholder applies to these known-issue link templates specifically; it is not a general link-rendering mechanism, and it is not the successor to anything on the writer side. The other two categories, `muted` and `accepted`, take no `issue` object but do require a non-empty `comment` - the configuration will not accept a silent suppression. ## Priority is by category, not by file order When several rules could match one result, Allure 3 does **not** take the first one in the file. It tries the categories in a fixed order - `issue` first, then `muted`, then `accepted` - and within a category takes the first matching rule. So an `issue` rule wins over a `muted` rule that appears above it in the file. Reordering the list changes which rule wins only among rules of the same category. ## The file the run writes If `knownIssuesPath` is set - or `--known-issues` is passed on the command line, which overrides it - the run writes a `known-issues.json` file at the end. It is not an input the run reads to decide anything; it is a record of what was actually resolved as `issue` on this run, grouped under each issue id, keyed by retry hash and holding each result's name, environment, status and error. The default file name is `known-issues.json`. Treat it as a baseline you can diff between runs, which is the only mechanical way to notice that the set of failures sitting under one ticket has changed.