mix surfex.suggest (Surfex v0.10.0)

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. A refines relation whose unit no longer sits there (moved to another section) is listed as a retire; accepting retires it beside the new one.
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.
migrated — a section's implements that mix surfex.migrate moved to claims whose relations are all validated now: accepting retires the section's.

With claim_implements: true in .surfex.exs, implements also pairs each claim (a block, test hint, row, rule or contract) with the code its verifying tests call directly, and a reached line says, per claim, which called item reaches more code and how much: name the ones that realise the claim with mix surfex.relate (spec §15.1).

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.