member preflight: reachability conflates "not landed yet" with "landed then drifted" #42

New issue

Open

opened 2026-08-02 07:03:23 +00:00 by PerishFire · 0 comments

PerishFire commented

2026-08-02 07:03:23 +00:00

Owner

Environment: concord v0.9.0.

Observed

Fault kinds do exist in v0.9.0 — preflight --json returns {"kind": "dirty", ...}, and boundary and reachability appear the same way. That part is fine.

The problem is inside one kind. reachability is emitted for both of these:

a member whose work is simply not landed yet — the normal state of every in-flight task;
a member that was landed but whose HEAD no longer reaches the integration checkout — a real problem.

Sweeping 7 members with in-flight work, all 7 produced reachability faults plus found N fault(s) and 1 unproved member(s). Six were entirely normal. One was not: its commits existed on no remote ref at all. The output was identical.

Why it matters

preflight reads as the natural "is this member OK?" command, and its name does not say "landed-removal gate only". Used for inspection it is close to pure noise, which trains an operator to ignore it — including on the member that deserved attention.

Proposal

Split the predicate that already exists internally. The check knows whether it failed because the member HEAD is not an ancestor of the integration checkout HEAD versus because a previously landed member has diverged. Emit those as distinct kinds — for example unlanded and drifted — and leave the gate behaviour unchanged.

Alternatively, keep preflight as a pure gate and expose a separate read-only member status. Either resolves it; the first is cheaper.

Environment: concord v0.9.0. ## Observed Fault kinds do exist in v0.9.0 — `preflight --json` returns `{"kind": "dirty", ...}`, and `boundary` and `reachability` appear the same way. That part is fine. The problem is inside one kind. `reachability` is emitted for both of these: 1. a member whose work is simply not landed yet — the normal state of every in-flight task; 2. a member that was landed but whose HEAD no longer reaches the integration checkout — a real problem. Sweeping 7 members with in-flight work, all 7 produced `reachability` faults plus `found N fault(s) and 1 unproved member(s)`. Six were entirely normal. One was not: its commits existed on no remote ref at all. The output was identical. ## Why it matters `preflight` reads as the natural "is this member OK?" command, and its name does not say "landed-removal gate only". Used for inspection it is close to pure noise, which trains an operator to ignore it — including on the member that deserved attention. ## Proposal Split the predicate that already exists internally. The check knows whether it failed because the member HEAD is not an ancestor of the integration checkout HEAD versus because a previously landed member has diverged. Emit those as distinct kinds — for example `unlanded` and `drifted` — and leave the gate behaviour unchanged. Alternatively, keep `preflight` as a pure gate and expose a separate read-only `member status`. Either resolves it; the first is cheaper.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

PerishFire/concord#42

No description provided.

Rows
Columns