# `Surfex.Item`
[🔗](https://github.com/dcoai/surfex/blob/v0.6.2/lib/surfex/item.ex#L1)

One item a scanner found in the code: the unit a spec citation resolves to, and the
source of a code record (`Surfex.Scan.code/1`).

`key/1` is the identity. It must stay stable across edits that rename nothing, or a
golden reports a deletion and an addition where a reader should see one row whose
version changed. That is why the version lives in `:hash` (a
`Surfex.SourceScan.definition_hash/1`-style content hash) and never in the key.

A scanner decides what the kinds are. Surfex never interprets `:kind` beyond grouping
and the rules a project writes in its `Surfex.Profile`.

# `t`

```elixir
@type t() :: %Surfex.Item{
  aliases: [String.t()],
  detail: String.t() | nil,
  file: String.t(),
  hash: String.t(),
  kind: atom(),
  lines: {pos_integer(), pos_integer()} | nil,
  name: String.t(),
  parent: String.t() | nil,
  shape: boolean(),
  type: String.t() | nil,
  value: String.t() | nil
}
```

# `key`

```elixir
@spec key(t()) :: String.t()
```

The citation key. A member is keyed through its parent (`parent.name`), so two structs'
`offset` fields are two keys and a bare `offset` is never silently one of them.

---

*Consult [api-reference.md](api-reference.md) for complete listing*