# `mix surfex.suggest`
[🔗](https://github.com/dcoai/surfex/blob/v0.6.2/lib/mix/tasks/surfex.suggest.ex#L1)

Lists what the spec already implies (`Surfex.Suggest.all/5`):

  * **moves** — a spec or test id the log knows that is gone, and a new id at the same
    version: a renamed heading or an added anchor; a test whose module, `describe` or
    file was renamed, as when a test file is split. Accepting moves each relation, and a
    test's red→green and baseline records, onto the new id (`mix surfex.move`). A
    version found under several ids is listed as ambiguous and never moved.
  * **refines** — each marked block and test hint refines the section or block it sits
    in.
  * **implements** — each spec unit paired with each code item it names.
  * **verifies** — each test paired with the spec unit its `@tag verifies:` names.
  * **tests** — each test paired with each code item it calls.
  * **excuses** — each code item nothing implements, paired with the class of the first
    rule in `.surfex.exs` it matches.

Pairs already related, in any state, are left out.

    mix surfex.suggest                         # list them; nothing is written
    mix surfex.suggest --accept                # record them
    mix surfex.suggest --accept --note "adopted the relation log"

`--accept` only creates relations that don't exist, and carries judgements across
moves. It never confirms a dangling relation: that stays `mix surfex.confirm`, one named
id at a time.

Adopting the relation log is `mix surfex.log --init`, then this with `--accept`.

---

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