audit: agreement true says nothing about whether in-flight work is healthy #41

New issue

Open

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

PerishFire commented

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

Owner

Environment: concord v0.9.0, registry version 3, Linux. Observed while sweeping 21 tasks across 3 domains.

Observed

Every task in the sweep reported agreement: true to the protocol. In the same sweep:

one member had 22 uncommitted files while its MAIN.md claimed the implementation was complete;
one task's MAIN.md said its work was committed but not landed, while the commit was already origin/main;
one member's branch was 60 commits behind its own origin/main with an open, conflicting draft PR untouched for seven days.

None of that is visible from audit. On a member with 22 dirty files today:

audit: perish.code/sealkit-combination-models
  agreement: true to the protocol
  advisory: boundary: .../sealkit: member boundary proof is absent or stale

Why this is worth changing

Four- (now five-) surface agreement is the right gate for mutation, and I am not asking to widen it. But audit is also the documented task-entry command in protocol.md "Entering and starting" step 2. An operator entering a task reads true and moves on.

v0.9.0 already has the extension point. audit --json emits typed observations:

{"kind": "boundary", "path": ".../sealkit", "message": "member boundary proof is absent or stale"}

That is a member-level advisory with a kind. Adding working-tree and remote observations alongside it needs no new plane and no new gate.

Proposal

Emit additional non-gating observations per member: dirty/untracked count, whether an upstream is configured, ahead/behind against it, whether member HEAD is an ancestor of the integration checkout HEAD, and the member's last commit date. Each is one git call. All are advisory, exactly like boundary is today.

The strongest single signal is the third one: a member whose commits exist on no remote ref at all is materially different from one that is merely unlanded, and nothing in Concord distinguishes them today.

Environment: concord v0.9.0, registry version 3, Linux. Observed while sweeping 21 tasks across 3 domains. ## Observed Every task in the sweep reported `agreement: true to the protocol`. In the same sweep: - one member had 22 uncommitted files while its `MAIN.md` claimed the implementation was complete; - one task's `MAIN.md` said its work was committed but not landed, while the commit was already `origin/main`; - one member's branch was 60 commits behind its own `origin/main` with an open, conflicting draft PR untouched for seven days. None of that is visible from `audit`. On a member with 22 dirty files today: ``` audit: perish.code/sealkit-combination-models agreement: true to the protocol advisory: boundary: .../sealkit: member boundary proof is absent or stale ``` ## Why this is worth changing Four- (now five-) surface agreement is the right gate for *mutation*, and I am not asking to widen it. But `audit` is also the documented task-entry command in `protocol.md` "Entering and starting" step 2. An operator entering a task reads `true` and moves on. v0.9.0 already has the extension point. `audit --json` emits typed observations: ```json {"kind": "boundary", "path": ".../sealkit", "message": "member boundary proof is absent or stale"} ``` That is a member-level advisory with a `kind`. Adding working-tree and remote observations alongside it needs no new plane and no new gate. ## Proposal Emit additional non-gating observations per member: dirty/untracked count, whether an upstream is configured, ahead/behind against it, whether member HEAD is an ancestor of the integration checkout HEAD, and the member's last commit date. Each is one `git` call. All are advisory, exactly like `boundary` is today. The strongest single signal is the third one: a member whose commits exist on no remote ref at all is materially different from one that is merely unlanded, and nothing in Concord distinguishes them today.

PerishFire referenced this issue

2026-08-03 08:59:25 +00:00

audit: project incoming and outgoing task todo edges #51

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#41

No description provided.

Rows
Columns