Agent-runtime boundary gate keys violations on line number, so unrelated line shifts redden it — main is stale 6h after #6462 re-baselined, with zero change to the violation set

[M3gA-Mind]

Summary

The agent-runtime ownership boundary gate keys each baselined violation on its line number, so an edit that merely shifts lines in a file containing a violation reddens the gate — reporting the same code as both a new "unbaselined violation" and a "stale baseline entry". Main is red on this right now, one day after #6462 re-baselined it, with zero actual change to the set of violations.

Proof: the violation set is identical, only lines moved

Regenerating the baseline from current main (2c579afc6) and comparing against the committed one:

baseline entries: 213   current findings: 213
differ when line INCLUDED : 5 pairs
differ when line EXCLUDED : 0

Zero difference once the line number is excluded. Same rules, same paths, same source text, same occurrence counts. Examples of entries whose only change is the line:

lifecycle.rs:        210 -> 70    let inherited_origin = crate::agent::turn_origin::capture();
runtime_session.rs: 1420 -> 1383  request_id: crate::agent::turn_origin::current_request_id(),
agent_chat.rs:       212 -> 197   if let Some(tx) = crate::agent::progress_sink::current_progress_sink() {
system_turn.rs:       88 -> 87    let result = with_origin(origin, agent.run_single(prompt))
factory.rs:         1198 -> 1206  let root = crate::agent::turn_workspace::current()?;

That is why the failure output lists the same lines on both sides — every "unbaselined violation" is also a "stale baseline entry".

Mechanism

scripts/ci/check-agent-runtime-boundary.mjs:341:

// Physical source locations are part of the temporary debt contract: a
// moved violation is stale debt, not a silently accepted occurrence.
const base = `${rule}\0${path}\0${line}\0${text}`;

Membership is then exact-JSON set comparison (:365-367), so a one-line shift is indistinguishable from "old violation deleted + new violation added".

The comment shows this is deliberate, and the intent is sound — a violation that moved should not be waved through unexamined. The cost may not have been weighed: the trigger is not "the violation changed", it is "any line above it changed". A PR that adds an import to agent_chat.rs inherits a red gate for seven violations it never touched.

Why this is worth fixing rather than re-baselining again

Re-baselining is not durable, and the history shows the treadmill:

commit	date
180bec2f0	2026-09-22	ci: refresh agent runtime boundary baseline
656c80e58	2026-09-23 07:09Z	ci: re-baseline the agent-runtime ownership boundary (#6462)
—	2026-09-23 13:00Z	stale again

Under six hours. Each refresh is a commit that reviews as "no functional change" and is therefore rubber-stamped, which is the review posture you least want on the file that defines a boundary.

It is currently invisible on main, which makes it worse

Rust Quality (fmt, clippy) is skipped on main's own pushes (changed-area gating). CI Lite on 2c579afc6: 4 success, 9 skipped, one unrelated frontend failure. So the gate is red but unexercised on main, and the next Rust-touching PR is the one that wears it — it looks like that PR's fault. This is the same dynamic as #6451 and #6486: breakage that accumulates behind a lane that does not run.

Two further gates are in the same state on 2c579afc6 and are worth separating from this one:

• cargo fmt --check — agent/harness/tool_result_artifacts/mod_tests.rs, agent/session_host/runtime_adapter_tests.rs
• pnpm rust:layout — spawn_async_subagent_execute.rs (847/832), spawn_subagent_tool_impl.rs (803/796), both over their own pinned limits (cf. Rust layout gate: main is one line from red (two files at exactly 750, one legacy pin at 0), no warning band, and two gaps in the gate #6310)

Solution (optional)

Keep the intent, drop the line from the identity. Options, cheapest first:

1. Key on rule\0path\0text\0occurrence and carry line as advisory metadata, refreshed silently. A genuinely new violation still fails; a pure move does not. The "moved violation" concern is largely served by occurrence already.
2. Key on line but report a move as a distinct, non-failing class ("N violations moved; baseline refreshed"), failing only on added/removed.
3. If physical location must stay load-bearing, add --refresh-lines that rewrites only line numbers for otherwise-identical entries, so the routine case is mechanical and a real change still needs review.

I'd take (1): it makes the gate fail on what it is named for — the ownership boundary changing — rather than on unrelated churn.

Acceptance criteria

• A pure line shift, with the violation set otherwise unchanged, does not fail the gate.
• A newly added violation still fails, and a removed one is still reported as stale — covered by a test that would pass today and must keep passing.
• main green on the boundary gate without a fresh re-baseline commit.
• A note on whether the gate should run on main's pushes at all, given it is currently gated off there.

Related

#6462 (the re-baseline this outlived by six hours), #6451 (failing step hides later steps), #6486 (same lane, same invisibility), #6310 (the layout gate's pinned limits).

Found while separating inherited red from my own on #6517/#6488 — both are comment-only or test-only and reproduce this failure byte-identically against a pristine main tree.

[M3gA-Mind]

Reproduction, and the general method for telling inherited red from introduced red

The gate's own verdict, on a pristine 2c579afc6 tree:

$ node scripts/ci/check-agent-runtime-boundary.mjs ; echo "exit: $?"
Agent-runtime ownership boundary changed.

Unbaselined violations (5):
  openhuman-task-local: .../session_host/builder/factory.rs:1206: let root = crate::agent::turn_workspace::current()?;
  openhuman-task-local: .../session_host/runtime_session.rs:1383: request_id: crate::agent::turn_origin::current_request_id(),
  openhuman-task-local: .../inference/host_runtime/ops/agent_chat.rs:197: if let Some(tx) = crate::agent::progress_sink::current_progress_sink() {
  openhuman-task-local: .../inference/host_runtime/ops/agent_chat.rs:208: let run = crate::agent::turn_origin::with_origin(
  openhuman-task-local: .../web_chat/ops/system_turn.rs:87: let result = with_origin(origin, agent.run_single(prompt))

Stale baseline entries (5); remove them:
  ...the same five lines...
exit: 1

To confirm this is not the TaskBoardCard/TodoItem rename: that one is fixed. grep TaskBoardCard on the baseline returns 0, TodoItem returns 1, and it agrees with agent/todos/types.rs:3. #6462 did its job. The remaining failure is the line-number keying described above and nothing else — which the 213/213 comparison settles, since excluding line the two sets are byte-identical.

The method

Worth recording separately, because it is the only thing that reliably separated inherited red from introduced red here:

# on your branch
git checkout <main-sha> -- <every file your PR touches>   # tree now == pristine main
<run the gate>                     > /tmp/main.txt
git checkout HEAD -- <those files> # restore your work
<run the gate>                     > /tmp/mine.txt
diff /tmp/main.txt /tmp/mine.txt   # identical => inherited, full stop

Byte-identical output means the failure is inherited, regardless of how much the failure looks like your change. On #6517 (comment-only) and #6488 (test-only) all three failing gates — boundary, cargo fmt --check, pnpm rust:layout — produced identical output on main and on the branch.

The trap it defends against is that a green main is not evidence a lane passed — here it means Rust Quality was skipped by changed-area gating and never ran. Whoever opens the next Rust-touching PR sees three red gates on their own branch and a green main, and the obvious inference is wrong.

[M3gA-Mind]

Prior art: #6458 identified this, and was closed on the re-baseline

#6458 — "Agent runtime ownership boundary baseline is keyed by line number, so moved code re-reports as a violation" — stated the same defect and was closed COMPLETED at 07:10:00Z, one minute after #6462 merged. #6462 re-baselined; #6458 had already named re-baselining as treating the symptom.

I filed this independently from the gate's output, not from that issue, which is itself the evidence for keeping it open: a closed issue reads as settled, so nobody re-derives its claims.

What this issue adds over #6458:

• The controlled comparison. Agent runtime ownership boundary baseline is keyed by line number, so moved code re-reports as a violation #6458 inferred from inspection that 9 of 10 pairs were moves. Removing line from the key turns that into differ when line EXCLUDED: 0 — the violation set is provably unchanged, not mostly unchanged.
• The recurrence. Three re-baselines, the last stale within six hours. That argument did not exist when Agent runtime ownership boundary baseline is keyed by line number, so moved code re-reports as a violation #6458 was written, and it is the case against a fourth.
• The genuine drift Agent runtime ownership boundary baseline is keyed by line number, so moved code re-reports as a violation #6458 named is fixed. TaskBoardCard/TodoItem agrees with todos/types.rs:3 now, so the rename is not the current cause — the keying is, on its own.

Refs #6458.

[tinysweeper]

The agent-runtime ownership boundary gate keys violations on line numbers, so any line shift (even unrelated) marks the same violation as both new and stale, causing the gate to fail on main with zero actual violation changes. This blocks PRs and requires frequent re-baselining.

Labelled priority: p1.

[M3gA-Mind]

This is one of four, and the pattern is worth naming

Four independent mechanisms found on 2026-09-23, all reaching the same conclusion — main's CI cannot measure main:

1. Changed-area gating — Rust Quality is skipped on main's own pushes, so Rust breakage accumulates unexercised.
2. This issue — the boundary gate keys violations on line number; the violation set is provably unchanged (213 / 213, differ with line EXCLUDED: 0) yet the gate is red.
3. Run-level success over a skipped lane — CI Lite green at 0f1ecc9d2 while the lane beneath it never ran.
4. style(app): restore Prettier compliance on main (unblocks 7 skipped Frontend Checks steps) #6526 — Frontend Checks red at step 9 (Check Prettier formatting) with steps 10–16 skipped, so the entire frontend unit suite does not run on any PR.

Each looks like an isolated flake from inside its own lane. Together they are a property of the pipeline, not a run of incidents: a green main is not evidence a lane passed, and in every one of these cases the next PR touching that area inherits red it did not cause and is the one asked to explain it.

Worth deciding whether these want an umbrella issue. Recording the cross-link either way so the fourth is not re-derived from scratch the way this one was from #6458.

Refs #6526, #6458.

[M3gA-Mind]

A moved violation is counted twice, so the reported severity is inflated

Adding this because the issue states the mechanism but not its effect on the numbers, and the numbers are what a reader triages on.

:364-367 compare whole JSON records:

const expectedKeys = new Set(expected.map(JSON.stringify));
const actualKeys   = new Set(actualStable.map(JSON.stringify));
const added = findings.filter((_, i) => !expectedKeys.has(JSON.stringify(actualStable[i])));
const stale = expected.filter((r) => !actualKeys.has(JSON.stringify(r)));

Since line is inside the record, one violation shifting by a single line lands in added and stale simultaneously. So step 7's "5 unbaselined + 5 stale" is not ten events, and not even five: it is one set of five violations that moved, counted twice.

That matters for triage. Ten findings reads like a boundary that has genuinely changed; the truth is nothing changed at all, which the differ when line EXCLUDED: 0 figure above already proves.

A concrete instance that the baseline is stale on main before anyone touches anything: the baseline records current_request_id() at line 1420; it sits at 1383 in runtime_session.rs today. That appears in the regeneration comparison above as runtime_session.rs: 1420 -> 1383.

And the sharpest demonstration of the blast radius — a one-line import deletion in runtime_session.rs shifts all three baselined violations in that file, converting one stale entry into three and producing six reported events from a change that touches none of them.

Credit to the two reviewers who established the double-count and the import-deletion case while scoping the fix; recording it here so the severity reads correctly for whoever picks this up.

[M3gA-Mind]

Landed as #6531 — option 1, re-keyed on rule\0path\0text\0occurrence, with the baseline regenerated because occurrence is now counted over (rule, path, text) rather than (rule, path, line, text).

Leaving this open rather than closing it: whether option 1 is the whole answer here is your call, not mine.

You asked specifically for the resulting behaviour on a genuinely new violation. Three injections, each against a tree restored clean and confirmed clean with git diff --quiet before the next:

A — a violation that merely moved (insert one line above three violations in runtime_session.rs):

Agent-runtime boundary holds (213 baselined violations).
rc=0

B — a genuinely new violation (added fn _probe() { let _ = crate::agent::turn_workspace::current(); }):

Unbaselined violations (1):
  openhuman-task-local: crates/openhuman-core/src/agent/session_host/runtime_session.rs:12:
    fn _probe() { let _ = crate::agent::turn_workspace::current(); }
rc=1

C — an existing violation duplicated in the same file:

Unbaselined violations (1):
  openhuman-task-local: crates/.../runtime_session.rs:934:
    workspace_descriptor: crate::agent::harness::current_parent()
rc=1

C is the one worth noting, because it is the case that removing line from the key looks like it should break. It does not: the file goes occurrence 1 → 2 and the second copy is reported. The gate still fails on added, removed and duplicated; it stops failing on moved.

The limitation you called out is real and is in the PR body rather than left to be found: a violation deleted in one place and an identical one appearing elsewhere in the same file keeps occurrence: 1 and produces no signal. That is indistinguishable from a move by construction, and silence on moves is the point of the change.

Two things I found while doing this that are arguments for the change rather than consequences of it:

1. The committed baseline was already stale on main. current_request_id() was pinned at line 1420 and actually sits at 1383. The gate was red on arrival, before anyone touched it.
2. The double report was not cosmetic. expectedKeys/actualKeys compared whole JSON records in both directions, so one moved violation landed in added and stale. The "5 unbaselined + 5 stale" in step 7 was one set of five, counted twice — which invites a triager to believe ten things changed and reach for a bigger fix than the defect deserves.

Baseline diff: 13 insertions, 13 deletions over 213 entries — 10 line refreshes and 4 occurrence bumps. 213 entries before and after, counted rather than assumed, with submodules initialised first, since a baseline that shrank because a scan path was missing reads identically to one that shrank because something got fixed.