ADR 0144: anything on a machine may call anything on it, superseding 0143

Everything should be able to call what runs on the same machine, another machine's
service exposed to the private network, and another machine's service exposed
publicly. Three cases; the filter had two.

The first was expressed as the machines' own addresses on the private network. A
caller on the machine carries such an address; a caller in one of its containers
carries a bridge address and matched nothing — measured, same destination and same
machine: src 10.10.0.1 against src 172.17.0.8. The second case worked by accident,
because the tunnel rewrites a caller's address to the sending machine's. Two of
three working is why it read as correct.

0143 answered the wrong question. It proposed verifying each grant from the
consumer's own network position and went to length about which position, because
whether a caller sat in a container changed the answer — and that difference was the
bug. Observing a configuration error is not its remedy. Superseded, and nothing
replaces it; whether the mesh should check a grant is still open in issue 145 and
must stand on its own.

And a module is not a container: 61 of 72 happen to use one, 11 do not, and a rule
reasoning about containers describes most of the mesh rather than the mesh.

04-ISSUES/145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md

@@ -74,15 +74,25 @@ What is not fixed is that nothing in the mesh would have told anybody.
 
 ## What was decided
 
-*2026-09-29, the same day.* The first open question below — should a grant be checked, and from where —
-is answered by [ADR 0143](../../02-DECISIONS/0143-a-consumer-verifies-the-grant-it-is-given.md): the
-consumer verifies it, from its own network position, because that is the only position that answers what
-a grant claims. A check run by the control plane or by the machine would have passed throughout this
-outage, since the rule in force admitted the machines' own addresses and it was the containers that were
-refused.
+*2026-09-29, the same day, in two steps and the first was wrong.*
 
-The remaining questions below stand, and the record answers two of them: one failure is not news, only
-consecutive ones, and a grant that cannot be checked is reported unchecked rather than assumed good.
+The first answer was [ADR 0143](../../02-DECISIONS/0143-a-consumer-verifies-the-grant-it-is-given.md):
+the consumer verifies each grant from its own network position, because whether a caller sat in a
+container changed whether it could reach the provider. **That difference was the fault**, and the record
+is superseded. A verification mechanism would have reported this sooner and would not have prevented it,
+and the part of it that was difficult — deciding which network position to check from — existed only
+while the rule was wrong.
+
+The remedy is [ADR 0144](../../02-DECISIONS/0144-anything-on-a-machine-may-call-anything-on-it.md):
+anything on a machine may call anything on it, said once rather than per service, and asked by the link
+traffic arrives on rather than the address it carries. Everything should be able to call what runs on the
+same machine, another machine's service exposed to the private network, and another machine's service
+exposed publicly. The filter had the second and third and expressed the first as a list of addresses that
+no container could match.
+
+**The question this issue is actually about is still open.** Nothing in the mesh would have said a grant
+had stopped working, and nothing does now. That is not answered by a configuration fix, and it should not
+be answered by a mechanism adopted as a remedy for one.
 
 ## Open questions