# Why this repository pins flamenet-e2e

`.e2e-ref` is the commit of [flamenet-e2e](https://gitlab.com/paulhitt/flamenet-e2e)
whose protocol vectors the `unit-tests` job checks against. `AccountKdfTest`,
`PQVectorTest` and `PublishedVectorsTest` all read them.

**It exists because a merge in that repository could stop all work in this
one.** flamenet-relay learned this the hard way: its jobs cloned `main` at HEAD,
and the switch got thrown three times in twelve hours (flamenet-relay#56). Once
it was a deadlock with no way out from inside either repository, that repo
expected a change this one had not made, so every pipeline failed, *including
the pipeline for the branch that made it*. See `.e2e-ref.md` there for the full
account; the conclusion was that a pin makes that situation impossible rather
than survivable.

A pin alone is worse than HEAD, though. The argument for HEAD is real: a
client tested against a pinned old harness is tested against a pinned old spec,
and if the vectors move and nothing says so, this suite quietly stops checking
the protocol anybody is actually running. That is why `vectors-head` exists and
is `allow_failure: true`.

Being behind is LOUD and NON-BLOCKING. Being broken is a hard stop. A red
`vectors-head` means an update is waiting, not that anything is wrong.

## Taking an update

One MR, both parts together:

1. Put the new e2e commit in `.e2e-ref`.
2. If the vectors themselves changed, read what changed before accepting it,
   a moved vector is a protocol change, and this app is one of the two ends
   that has to agree about it.