Repository navigation
test(e2e): open a macOS box by name and through the proxy (T101) - #2741
Conversation
The new case macos_box_opens_by_name_and_proxy activates an own-address box with a declared port and publishes a second port with min net expose. It asserts both ports open at the box's address, at its name and through the hostname proxy, each leg printed with its URL and status. A second box on the same port must be refused at activate and leave no box.
The finalize-install section now says a box opens at its name directly on macOS once min finalize-install has run, and through the hostname proxy before. It quotes the refusal an activation gives for a declared host port that something already holds.
|
Important Review skippedBot user detected. To trigger a single review, invoke the
 |
|
Approved: every review thread resolved at @norrietaylor resolved the last thread, which releases the approval this review had withheld. Nothing to do. |
There was a problem hiding this comment.
arch-review: CONDITIONS · 3 conditions · the full ruling
The e2e case conforms to §7.1. It asserts the range address and the 127.0.0.1 interim, each leg, and the held-port refusal with the correct holder. Two sentences in docs/reference/cli-min.md are not exact. 'In any browser' contradicts §7.1 lines 252-253, which name only the default profiles and record DoH as a residual. Make the change in C1. 'min ls names' the address is false, because min ls prints no per-box address. Make the change in C2. The proof leg is deferred and did not run, so C3 keeps the merge open until the macOS lane records it.
Ruled at 4ae3ee0 against gominimal/arch@109541a48c31 by claude-opus-5-5.
There was a problem hiding this comment.
minimal-review — approval withheld
Verdict COMMENT — APPROVE withheld: 3 unresolved threads — minimal-arch[bot] docs/reference/cli-min.md:562, minimal-arch[bot] docs/reference/cli-min.md:563, minimal-arch[bot] scripts/session-e2e.sh:26700. No findings.
Panel: 3 of 3 personas ran (correctness, security, supply-chain).
A browser profile that uses DNS-over-HTTPS does not ask the host resolver, so the name does not resolve there. The section also stops saying that min ls names the box's address.
|
/revise Close arch-review conditions C1 and C2 at 4ae3ee0 (arch_rulings 551). Both are wording fixes in
Generated by Claude Code |
|
That Nothing to type again: the command gets a rocket when its round starts, or a refusal that names the reason. No round was counted for it yet. |
There was a problem hiding this comment.
arch-review: CONDITIONS · 2 conditions · the full ruling
The doc now names the browsers that section 7.1 line 252 measured, and it states the DoH case of line 253. One new sentence tells a DoH profile to open the box through the hostname proxy. Line 259 says a browser recipe for the proxy must be a PAC file, never a whole-browser proxy setting. C1 makes that sentence a PAC recipe. The e2e case ran nowhere, and its name legs can be NOT RUN. C2 asks for the macOS lane record at this head. I escalate the proxy-after-the-step question (NET-019 against line 258) to arch. This PR does not need to change for it.
Ruled at 13a0afb against gominimal/arch@109541a48c31 by claude-opus-5-5.
|
Round 1 of 10 on a failed check suite, pushed as
Verify Review threads the coder judged:
On a macOS host, the e2e case macos_box_opens_by_name_and_proxy opens a declared and a runtime-published port at http://.min.internal:, at the box's address, at its name and through the hostname proxy. It also asserts that a second activation on a held declared port is refused and leaves no box. docs/reference/cli-min.md says the same. This branch does not show the proof as observed: no run of the case on a macOS host exists yet. Notes from the agent: Revise round 1. This round changed only docs/reference/cli-min.md (C1, C2). Deferred: ./scripts/session-e2e.sh macos_box_opens_by_name_and_proxy (lane: vm). I did not run it, because this box has no macOS host or VM. Failed checks: ci-macos-success is the aggregator, and it fails because the e2e job failed. The e2e excerpt does not show which case failed. The expose lines in it are the expected refusals of earlier cases, and those cases run before this case. I found no fault in the new case: bash -n passes, it parses min ls the same way as the other cases, and its teardown globals follow the same pattern as the other cases. Somebody must read the full e2e job log to find the failing case. vale is not installed here, so just lint-prose did not run on the edited doc. |
A browser profile that resolves names through DNS over HTTPS does not resolve box names. The section no longer gives a browser proxy recipe.
There was a problem hiding this comment.
minimal-review — approval withheld
Verdict COMMENT — APPROVE withheld: 6 unresolved threads — minimal-arch[bot] docs/reference/cli-min.md, minimal-arch[bot] docs/reference/cli-min.md, minimal-arch[bot] scripts/session-e2e.sh:26700, minimal-foundry[bot] scripts/session-e2e.sh:26878, minimal-arch[bot] docs/reference/cli-min.md, …. No findings.
Panel: 3 of 3 personas ran (correctness, security, supply-chain).
There was a problem hiding this comment.
arch-review: PASS_WITH_CONDITIONS · 1 condition · the full ruling
The docs paragraph now matches §7.1. Default browser profiles resolve box names (line 252), a DoH profile does not (line 253), and the section gives no browser proxy recipe that is not a PAC (line 259). The e2e case asserts what lines 249, 255 and 258 require. The case ran nowhere, and its name leg is NOT RUN on a host without /etc/resolver/min.internal. C1 asks for one macOS run with both name legs at HTTP:200, or a filed issue that owns the run.
Ruled at 20e654a against gominimal/arch@109541a48c31 by claude-opus-5-5.
|
Round 2 of 10 on a /revise note, pushed as
Verify Review threads the coder judged:
docs/reference/cli-min.md says that on macOS a box opens at http://.min.internal: in the default profile of Safari, Chrome or Firefox once min finalize-install has run, and through the hostname proxy before it. It says that a profile on DNS over HTTPS does not resolve box names, and that an activation refuses a held port. The macOS end-to-end proof is still owed by the vm lane. Notes from the agent: Round 2 changed only docs/reference/cli-min.md, as the /revise note asked. C1: the DoH sentence is now the exact text from the note. The sentence that sent a DoH profile to the hostname proxy is gone. C2 ('the address that its name resolves to') was already on the branch at 13a0afb. vale is not installed on this box, so 'just lint-prose docs/reference/cli-min.md' did not run. Its alert count is not known. Deferred: ./scripts/session-e2e.sh macos_box_opens_by_name_and_proxy (lane: vm). C3 is not part of this round. Commit 20e654a carries the C1 fix. |
|
Revise round 1 ran against |
|
/revise Fix the macOS e2e failure and LOW thread 4408437135. The epic owner chose this round to also fix the same parse in the NET-040 case, which has turned
Generated by Claude Code |
…s-open-end-to-end
The macOS VM lane prints the zone answerer line without the word 'listening', so the NET-040 case and the macOS by-name case read an empty port. Anchor the parse on the address so both spellings match. The port-holder step now fails when its helper holds zero addresses.
There was a problem hiding this comment.
arch-review: PASS_WITH_CONDITIONS · 1 condition · the full ruling
This head keeps the earlier ruling. The new commit changes only how the e2e case reads the DNS port and how it checks the held port. Both changes still fail closed. The docs and the case's assertions agree with §7.1 lines 249, 252, 255, 258 and 259. One condition stays open: the macOS by-name leg did not run. C1 closes it on #2717 with a run on a host where min finalize-install ran.
Ruled at a0058fc against gominimal/arch@109541a48c31 by claude-opus-5-5.
There was a problem hiding this comment.
minimal-review — approval withheld
Verdict COMMENT — APPROVE withheld: 2 unresolved threads — minimal-foundry[bot] scripts/session-e2e.sh:26878, minimal-arch[bot] scripts/session-e2e.sh:26842. No findings.
Panel: 3 of 3 personas ran (correctness, security, supply-chain).
|
Round 3 of 10 on a /revise note, pushed as
Verify Review threads the coder judged:
On a macOS host, the e2e case macos_box_opens_by_name_and_proxy and the NET-040 case fresh_install_range_lands_on_macos now read the zone answerer port from the VM wording of the DNS SERVICE line in 'min ls'. The holder step now fails when its helper holds zero addresses. The lane can then show that http://.min.internal: opens a published port at the name and through the hostname proxy, and that a held declared port refuses the activation. Notes from the agent: Revise round 3, commit a0058fc. The DNS SERVICE parse at lines 5173 and 26786 now uses sed -En 's/^DNS SERVICE:.* on 127.0.0.1:([0-9]+) (UDP).*/\1/p'. A shell check printed 5353 for the native line, and 7656 and 7657 for the two VM lines. The holder check at line 26875 now requires '^held [1-9]'. The wait loop above it still stops on any 'held' line, and the check after it decides. A shell check showed that 'held 0' fails and 'held 3' passes. As the directive asked, I changed nothing else. Line 16670 has the same 'listening' parse. I did not change it because the directive scoped this round to the two cases it named. If that case runs on the macOS lane, it needs the same fix. Thread 4408437135 (PRRT_kwDOPdfcxM6xZ_s5): the earlier verdict was invalid. This round changes it to valid and fixes it. Deferred: ./scripts/session-e2e.sh macos_box_opens_by_name_and_proxy (lane: vm). I did not run it. |
There was a problem hiding this comment.
minimal-review — approved
Verdict APPROVE — every review thread is resolved; @norrietaylor closed the last one. The review of a0058fc8524a withheld this approval on the threads open then. Posted as a comment: the App cannot approve its own pull request; the check and the label carry it.
There was a problem hiding this comment.
Babysitter review at a0058fc8. I read T101's e2e case and docs against the plan block and arch's rulings 551, 554 and 557 (PASS_WITH_CONDITIONS at this head).
- Docs:
docs/reference/cli-min.mdbounds the by-name claim to the default profile of Safari, Chrome or Firefox, says a DoH profile does not resolve box names, says the box stands at the address its name resolves to, and gives no whole-browser proxy recipe (arch C1/C2 on 4ae3ee0 and C1 on 13a0afb). - e2e parse:
scripts/session-e2e.shreads the answerer port withDNS SERVICE:.* on 127.0.0.1:N (UDP), which matches both the native and the macOS VM wording, in the new case (:26786) and in the NET-040 case (:5173). That NET-040 parse has keptmain's macOS lane red since #2713, and the epic owner chose to fix it here. - Holder step: requires
^held [1-9], so a helper that binds nothing fails (LOW 4408437135). - C1 (deferred macOS leg): the epic owner ruled #2717 carries it; the Deferred table links it.
- Threads: zero open. CI: every lane aggregator is green at this head, macOS included.
No further findings.
Generated by Claude Code
There was a problem hiding this comment.
Babysitter approval at a0058fc: every merge gate passes at this head (arch PASS at a0058fc, zero open threads, every lane aggregator green). Squash title test(e2e): open a macOS box by name and through the proxy (T101) and the squashed message pass commitlint. Queued for squash merge.
Generated by Claude Code
A macOS VM host prints "this VM's host daemon answers its box names on 127.0.0.1:<port> (UDP)", so the parser in fresh_install_range_lands_on_macos found no port and failed the lane. This takes the one line from #2741 (de32bd3). The rest of that commit stays off the 0.7 line. The case now matches main.
A macOS VM host prints "this VM's host daemon answers its box names on 127.0.0.1:<port> (UDP)", so the parser in fresh_install_range_lands_on_macos found no port and failed the lane. This takes the one line from #2741 (de32bd3). The rest of that commit stays off the 0.7 line. The case now matches main.
T101 — macOS names open end to end
slice: S0
kind: integration
covers: none
size: M
est: 120 code, 220 tests
executor: agent
difficulty: needs care
model: standard
diagnostics:
min bugbundles carry the daemon log, where the session-start probe line, the proxy's route lines and the activation refusal line together show which of the three paths failedobservability: the e2e case logs each leg's URL and status so a failed run names the leg
layers:
- e2e:
- scripts/session-e2e.sh: a new case activates one own-address box with a declared port on macOS, publishes a second port at runtime, and asserts both open at the name and through the hostname proxy, then activates a second box on the same port and asserts the refusal
test (deferred: vm): ./scripts/session-e2e.sh macos_box_opens_by_name_and_proxy
test: cargo nextest run -p minimald each_box_gets_own_loopback_address
test: cargo nextest run -p minimald proxy_undeclared_port_refused_like_direct
- docs:
- docs/reference/cli-min.md: the box-name section says again that a box opens at its name directly on macOS once
min finalize-installhas run, through the hostname proxy otherwise, and that an activation refuses a held portproduces: none
consumes:
- crates/minimald/src/box_manager/handle.rs
- crates/minimald/src/net/dns.rs
- crates/minimald-rpc/src/lib.rs
depends on:
- blocked by #2687
- blocked by #2688
- blocked by #2703
proof: on a macOS host,
http://<name>.min.internal:<port>opens a port a box publishes, at its name and through the hostname proxy alike, and an activation whose declared port cannot be published is refused (NET-010, NET-069, NET-123, NET-144).Proof
On a macOS host,
./scripts/session-e2e.sh macos_box_opens_by_name_and_proxyactivates an own-address box with a declared port and publishes a second port withmin net expose. It prints each leg's URL and status, and it fails unless 8000 both ports open at the box's address, at http://.min.internal:, and through the hostname proxy thatmin lsnames. It then activates a second box on the same port and fails unless the activation is refused with the port and its holder, with no box left behind. docs/reference/cli-min.md now says the same thing for a person.Notes from the agent: Deferred (lane: vm): ./scripts/session-e2e.sh macos_box_opens_by_name_and_proxy. I wrote it and ran nothing for it. I checked it only with bash -n and shellcheck, and shellcheck reports no new findings. The case runs in the state it finds the host in. With the reserved range on lo0, box A stands at its own 127.0.64.N address. Box B then gets its own address too, so the case holds the port with a plain listener on every other range address, and it expects the refusal 'by another program on this machine.'. Without the range, both boxes share 127.0.0.1, so the case expects 'by box e2e-mac-open-a.'. The direct name leg needs /etc/resolver/min.internal. Without that file, the case records the leg as NOT RUN with not_run, and the address and proxy legs still run. The case is in the whole-lane order after two_named_vms_on_one_machine, in the dispatch, in the usage text and in the header list. On a host that is not macOS, it prints SKIPPED. NET-144's text was not in the spec excerpt. I took the refusal wording from PortInUseRefusal's Display in crates/minimald-rpc/src/lib.rs, and the docs quote that wording. I could not run
just lint-prose, because vale is not installed on this box.Tests
cargo nextest run -p minimald each_box_gets_own_loopback_addresscargo nextest run -p minimald proxy_undeclared_port_refused_like_directVerify
min task run agent-verifypassed ([tasks.verify]).Deferred
The plan marked these test lines deferred: the executor lacks the lane, so nothing here ran them and they still owe evidence.
./scripts/session-e2e.sh macos_box_opens_by_name_and_proxyThe epic owner ruled on 2026-10-29 that #2717 carries this leg, as it carries T98's: a run on the macOS VM lane, on a host where
min finalize-installran, recordsrange presentand both name legs at HTTP:200 there.Closes #2708
Generated by Claude Code