docs(agents): mergeable is async, and the behaviour test for the gate

jlxq0 commented

2026-09-01 15:35:11 +00:00

Owner

Two entries, both from today.

`mergeable: true` plus `HTTP 405` is not branch protection

The field is recomputed asynchronously, so one sample cannot separate no
conflict from not looked at yet from behind main. Measured 2026-09-01:
#31 reported mergeable: true and its merge returned 405 seconds after #32
moved main. A retry succeeded, so it was a transient recompute rather than a
rule.

Those two readings together point a reader at the protection settings, which is
the wrong file, and this repository's rule is deliberately minimal so there is
nothing there to find.

The replacement is two commands, one question each, both deterministic:

git merge-tree --write-tree origin/main <head>      rc=0 means no conflict
git merge-base --is-ancestor <head> origin/main     behind, or not

That is exactly what mergeable conflates.

The behaviour test for the gate

Recorded as the question rather than the category: could this change alter
behaviour? No ships, yes is ordinary and gated.

With the precision that matters kept: on the redaction, no authorisation was
required, which is a different claim from having been authorised. A relay
carrying an approval for add a redirect URI would not have been enough,
because that alters behaviour.

On shipping this one

Docs only, so it cannot alter behaviour and the test above says ship. I am
reading that test as general rather than as scoped to removals, since it is
stated as a question about any change. If you meant it narrowly, say so and I
will gate documentation too — I would rather be told than keep guessing, and
this is the second time the boundary has been worth naming out loud.

Gates green at the head: fmt, clippy -D warnings, 108 tests.

Two entries, both from today. ## `mergeable: true` plus `HTTP 405` is not branch protection The field is recomputed asynchronously, so one sample cannot separate *no conflict* from *not looked at yet* from *behind `main`*. Measured 2026-09-01: #31 reported `mergeable: true` and its merge returned 405 seconds after #32 moved `main`. A retry succeeded, so it was a transient recompute rather than a rule. Those two readings together point a reader at the protection settings, which is the wrong file, and this repository's rule is deliberately minimal so there is nothing there to find. The replacement is two commands, one question each, both deterministic: git merge-tree --write-tree origin/main <head> rc=0 means no conflict git merge-base --is-ancestor <head> origin/main behind, or not That is exactly what `mergeable` conflates. ## The behaviour test for the gate Recorded as the question rather than the category: **could this change alter behaviour?** No ships, yes is ordinary and gated. With the precision that matters kept: on the redaction, no authorisation was required, which is a different claim from having been authorised. A relay carrying an approval for *add a redirect URI* would not have been enough, because that alters behaviour. ## On shipping this one Docs only, so it cannot alter behaviour and the test above says ship. **I am reading that test as general rather than as scoped to removals**, since it is stated as a question about any change. If you meant it narrowly, say so and I will gate documentation too — I would rather be told than keep guessing, and this is the second time the boundary has been worth naming out loud. Gates green at the head: fmt, clippy `-D warnings`, 108 tests.

jlxq0 added 1 commit

2026-09-01 15:35:11 +00:00

docs(agents): mergeable is async, and the behaviour test for the gate

CI / cargo (pull_request) Successful in 48s

Details

CI / docker (pull_request) Successful in 20s

Details

607ca800f2

A pull request reporting mergeable: true whose merge returns HTTP 405 is not
branch protection. The field is recomputed asynchronously, so one sample cannot
separate no-conflict from not-looked-at-yet from behind-main. Measured
2026-09-01 on PR 31 seconds after PR 32 moved main; a retry succeeded, so it was
a transient recompute. Reading those two together sends someone to the
protection rule, which is the wrong file.

Records the two commands that answer deterministically, one question each:
merge-tree --write-tree for conflicts and merge-base --is-ancestor for behind.

Also records the gate ruling from today: a change that cannot alter behaviour
ships without the gate. The case that settled it removed a real address from
public prose, and the precision that matters is that no authorisation was
required rather than that one was relayed, since a relayed approval for
something that does alter behaviour would not have been enough.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

jlxq0 added 1 commit

2026-09-01 15:37:58 +00:00

docs(agents): GitHub's single-ref endpoint served a cached head

CI / cargo (pull_request) Has been cancelled

Details

CI / docker (pull_request) Has been cancelled

Details

a1bdf282b4

Same class as mergeable, one layer out. Measured 2026-09-01 seconds apart:
/commits/main returned 477c92a0 while /commits?per_page=3 returned ade7ad30, and
it nearly produced a report that this repository's mirror was lagging when it
had fired three seconds after the merge. Minutes later all three ref endpoints
agreed, so it is transient and unreproducible on demand, which is why it is
recorded rather than left to be rediscovered.

Records the discriminator that does work: compare content across the mirror
rather than shas, because a stale mirror shows the old count while a missing
file, an empty body and a lagging fetch all show zero. Ask the same fetch for a
value you expect present.

And the counting fault behind two reports differing by exactly 2 lines: curl -w
output joins the body in the stream you then count, so grep -c '' over it
reported 535 and 286 against the true 533 and 284. Mine were wrong; the cause
was my instrument rather than a merge landing between the reads.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

jlxq0 commented

2026-09-01 15:38:47 +00:00

Author

Owner

Two more entries batched onto this branch rather than pushed one at a time,
since a second push cancels an in-flight run and requeues from the back of a
capacity-1 queue. Head is now the last of them.

GitHub's single-ref endpoint served a cached head

Same class as mergeable, one layer out. Measured seconds apart on this
repository: /commits/main returned 477c92a0 while /commits?per_page=3
returned ade7ad30. It nearly produced a report that this repository's mirror
was lagging when the mirror had fired three seconds after the merge. Minutes
later all three of /commits/main, /commits?per_page=3 and
/git/refs/heads/main agreed, so it is transient and unreproducible on demand,
which is the reason to write it down rather than leave it to be rediscovered.

Recorded with the discriminator that does work: compare content across the
mirror, not shas. A stale mirror shows the old count; a missing file, an empty
body and a lagging fetch all show zero.

`curl -w` output joins the stream you then count

My GitHub line counts were 535 and 286 against the true 533 and 284, because
-w "\nHTTP %{http_code}" adds a blank line and a status line to the body and I
counted the lot with grep -c ''. Two independent counts differing by exactly 2
in both files, and the cause was my instrument rather than a merge landing
between the reads. Clark's numbers were right and mine were not.

The substituted address now says it is fiction

The addresses were gone and nothing told the next reader that what replaced them
is a stand-in. A real-looking address in a measured port table invites someone
to test it, which is the one thing substitution can actively mislead about.

One note per file near the first use, in both for the same reason the argument
is in both: AGENTS.md is read before working and config.rs beside the
constant. It says the value answers nothing, the last octet means nothing, and
no conclusion depends on it. Came from jmap-mcp via Clark, the reverse
direction of this repository's LAN phrasing travelling the other way.

Gates green at the head: fmt, clippy -D warnings, 108 tests.

Two more entries batched onto this branch rather than pushed one at a time, since a second push cancels an in-flight run and requeues from the back of a capacity-1 queue. Head is now the last of them. ## GitHub's single-ref endpoint served a cached head Same class as `mergeable`, one layer out. Measured seconds apart on this repository: `/commits/main` returned `477c92a0` while `/commits?per_page=3` returned `ade7ad30`. It nearly produced a report that this repository's mirror was lagging when the mirror had fired three seconds after the merge. Minutes later all three of `/commits/main`, `/commits?per_page=3` and `/git/refs/heads/main` agreed, so it is transient and unreproducible on demand, which is the reason to write it down rather than leave it to be rediscovered. Recorded with the discriminator that does work: **compare content across the mirror, not shas.** A stale mirror shows the old count; a missing file, an empty body and a lagging fetch all show zero. ## `curl -w` output joins the stream you then count My GitHub line counts were 535 and 286 against the true 533 and 284, because `-w "\nHTTP %{http_code}"` adds a blank line and a status line to the body and I counted the lot with `grep -c ''`. Two independent counts differing by exactly 2 in both files, and the cause was my instrument rather than a merge landing between the reads. Clark's numbers were right and mine were not. ## The substituted address now says it is fiction The addresses were gone and nothing told the next reader that what replaced them is a stand-in. A real-looking address in a measured port table invites someone to test it, which is the one thing substitution can actively mislead about. One note per file near the first use, in both for the same reason the argument is in both: `AGENTS.md` is read before working and `config.rs` beside the constant. It says the value answers nothing, the last octet means nothing, and no conclusion depends on it. Came from `jmap-mcp` via Clark, the reverse direction of this repository's LAN phrasing travelling the other way. Gates green at the head: fmt, clippy `-D warnings`, 108 tests.

jlxq0 added 1 commit

2026-09-01 15:38:47 +00:00

docs: say the substituted address is a documentation-range stand-in

CI / cargo (pull_request) Successful in 36s

Details

CI / docker (pull_request) Successful in 40s

Details

1cea0cf402

The addresses were gone and nothing told the next reader that what replaced them
is fiction. A real-looking address in a measured port table invites someone to
test it, which is the one thing substitution can actively mislead about.

One note per file, near the first use, in both because AGENTS.md is read before
working and config.rs is read beside the constant, so a reader hitting the
address in either place learns the same thing about it. Says the value answers
nothing, that the last octet means nothing, and that no conclusion depends on
it: the measurements are real and the address is not.

Came from jmap-mcp via Clark, the reverse direction of this repository's LAN
phrasing travelling the other way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CI / cargo (pull_request) Successful in 36s

Required

Details

CI / docker (pull_request) Successful in 40s

Details

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin docs/mergeable-is-async:docs/mergeable-is-async

git switch docs/mergeable-is-async

Rows
Columns

docs(agents): mergeable is async, and the behaviour test for the gate #33

mergeable: true plus HTTP 405 is not branch protection

The behaviour test for the gate

On shipping this one

GitHub's single-ref endpoint served a cached head

curl -w output joins the stream you then count

The substituted address now says it is fiction

Checkout

`mergeable: true` plus `HTTP 405` is not branch protection

`curl -w` output joins the stream you then count