# Version conflict report — Orchard Gateway 4.2.0 (SAMPLE)

> SAMPLE — fictional supply-chain data. Every package, registry, version, hash, licence, advisory identifier and signature in this document is invented.

## Summary

| Package | Requested by | Range | Resolved | Outcome |
| --- | --- | --- | --- | --- |
| `example-logger` | `@orchard-example/router` | `^3.4.0` | 3.4.1 | shared |
| `example-logger` | `@orchard-example/http-core` | `^3.4.0` | 3.4.1 | shared |
| `example-logger` | `example-metrics` | `^3.4.0` | 3.4.1 | shared |
| `example-logger` | `example-cache` (peer) | `^2.9.0` | 2.9.0 | **duplicated** |

## The diamond that resolves

Three parents require `example-logger` at `^3.4.0`. All three ranges are satisfied by 3.4.1, so the resolver installs **one** copy and every parent shares it. A graph builder that emits three nodes here is wrong.

```
gateway ──┬── router     ──┐
          ├── http-core  ──┼──> example-logger 3.4.1  (one node, in-degree 3)
          └── metrics    ──┘
```

## The diamond that does not

`example-cache` declares a peer range of `^2.9.0`, which 3.4.1 does not satisfy. There is no single version that satisfies both `^3.4.0` and `^2.9.0`, so npm nests a second copy under the requiring package. That is the state `package-lock-peer-conflict.json` in the lockfiles subcategory encodes.

## What to assert

1. The resolved graph has **10** nodes, not 12 — repeat visits are the same node.
2. `example-logger` has an in-degree of **3** in the primary graph.
3. In the peer-conflict lockfile, `example-logger` appears at **two** versions and a duplicate report must say so.
4. Neither situation is an error on its own: one is normal deduplication, the other is a documented cost.