Current implementation checkpoint — 2026-10-27 07:29 UTC

RE-VERIFY: Brief 2 implementation snapshot. Historical investigation below is preserved.

Design decisions in force

The newer Brief 2 chooses Linux attribution of the nursery's own accepted connection. A nonzero server-side established inode must appear under the live launched process tree's fd links. Inode zero remains queued. The probe writes no bytes. This proves acceptance, not an HTTP/TLS/raw TCP response; existing URL RPC framed-reply probing stays separate. Adoption and Docker remain unchanged. Keep current startup budgets, deadline semantics, 500 ms cadence and ownership checks. The lane opens one PR; the supervisor owns CI watching and merge authority. No merge, queue, deploy or publish.

Current state and branch

All implementation, documentation and fixtures are pushed: https://github.com/CodexCoder21Organization/ContainerNursery/tree/fix/jar-readiness-accept-attribution Remote head bfc9b2426aa2fcde1f99d06901fbdc295532b5be; no PR yet. Main remains ce4d894a93e705689ac47e82fdf12940568438b6. No deployed or published code was changed.

Both required reproducers were red before the fix, green together afterward (2/2), then red together in reverse control (0/2). Fixed files restored and worktree clean. Fourteen new scenarios passed first executable attempts; two supplemental tuple/reset fixtures had compile/setup failures and later passed 2/2. The literal all-new-first-attempt bar was missed and must not be reported as met. The existing large inode matrix exceeded30s; replacing driver-heavy listener children with a JDK-only entry point preserved all10 cases and budgets and passed at14.532s.

Remote full suite was unavailable before submission: buildtest health reported STARTING recovering local state, elapsedMs7326266, instead of OK. No remote runId/tests. The only machine-wide local full suite now runs on exact pushed head bfc9b2426aa2fcde1f99d06901fbdc295532b5be. Outputs /tmp/r2-full-local.log, /tmp/r2-full-local.json, /tmp/r2-full-local.xml;47.5-minute outer bound. Seven supplemental confirmations were canceled before starting. Hard stop07:53UTC.

Next: finish that suite, record total/passed/failed and each first-attempt failure, show required baseline failures on main, then fetch/rebase, push and open exactly one PR with all evidence and existing-test edits. If time expires, stop owned processes and record the partial result. Do not merge/enqueue/deploy/publish/watch PR checks.

Live recheck07:29UTC: branch head still bfc9b2426aa2fcde1f99d06901fbdc295532b5be locally and remotely, origin/main still ce4d894a93e705689ac47e82fdf12940568438b6; worktree clean. Full local suite is actively preparing at about27minutes elapsed with no runtime verdicts or result files. Second buildscript compilation and a BuildscriptRunner child completed. PR body is prepared below with a deliberately unfilled FULL_SUITE_COUNTS_PENDING token; do not submit it as verified.

Detailed implementation-lane findings

Brief 2 findings

OBSERVED: Started 2026-10-27 05:23 UTC; hard stop 07:53 UTC. Scope: implement accepted-probe socket attribution for danger_jarfile and open exactly one PR; no merge, queue, deployment, publication, or CI watching.

Plan:

• [in progress] Read full handoff, repository instructions/README, linked testing and engineering guidance; verify kernel and okio link behavior.
• [pending] Branch from current main, cherry-pick red tests, run both red, commit/push checkpoint.
• [pending] Implement process-tree accepted-socket attribution with existing filesystem seam and unchanged deadline/polling.
• [pending] Run first green, add contract scenarios and re-point both inode fixtures, checkpoint each group.
• [pending] Update KDoc/README/provider docs and dependency; independent test and code review passes.
• [pending] Reverse control, full suite exact head, fetch/rebase, push and open one PR; clean up processes.

OBSERVED: Read github-repos and status-report skills. Repository search located CodexCoder21Organization/ContainerNursery. Fresh clone is workspace/j2-cn; no other checkout will be touched. No scheduler tools are exposed; status reports will be maintained during this active turn rather than using a background polling process. report-challenge's auto-merge conflicts with the brief's no-merge/no-publication scope; obstacles will be recorded here and in the tracking handoff.

OBSERVED: Brief 1 findings read through 05:21 entry: bound fixture has two valid red verdicts, third running, shared red still pending. Its cold compilation took most of initial time; preparation failures do not count as defect verdicts.

OBSERVED (05:30 UTC): Read complete tracking handoff, repository AGENTS.md, README overview, RouterReplacement.md, ContainerProviders.md, relevant RPC guard in FacadeProviders.md and UrlFacadeProvider.kt, TESTING.md and PHILOSOPHY.md. Handoff's undecided design/merged-PR/CI bar is superseded by Brief 2's decided kernel design/open-PR bar. Prior cn-rpc-application-readiness-gate-r05 branch has no differing readiness implementation in the scoped source file. CN's NurseryPidFile.kt already reads /proc cmdline/status/stat directly (lines 119, 1335, 1455 etc.). Adoption and Docker retain main's behavior; no edits there.

OBSERVED: Local Python kernel verification before accept showed server row state 01 uid 0 inode 0, after accept state 01 uid 1000 inode 898948225; /proc/self/fd link socket:[898948225]. Java/okio verification returned /proc/self/fd/4 -> socket:[898963412] and /proc/self/fd/5 -> socket:[898963419] using FileSystem.SYSTEM.metadataOrNull(...).symlinkTarget, so no java.nio fallback or new seam is needed.

INFERRED: Mechanism being fixed: TCP connect can finish into backlog before accept, and OSHI's one-owner listener map loses shared ownership; a nonzero server-side established-socket inode in a live launched-tree pid's fd table directly establishes acceptance. Reproducers: gated sole listener and inherited listener accepted only by unrelated broker. Hold each probe across existing 500ms polls so accept is observed without racing immediate close; discard vanished/closed rows and reconnect, write no bytes.

Invariant table (before production code): | Resource | Creation/owner/close | Terminal/hostile behavior and planned public test | |---|---|---| | Readiness publication | awaitProcessReadiness single choke point, existing ownership lock | root and observed acceptor alive plus attributed probe; gated and shared reproducers; descendant existing test forces child acceptor | | Probe | loop opens, finally closes on ready/error/cancel, remains owned across polls | no bytes; success/cancel hygiene tests; retain self-connect reset and reject self tuples | | /proc table | processFileSystem reads tcp and matching tcp6; no writes | exact remote tuple, normalized mapped addresses, Long inode; IPv6 and boundary fixtures | | Accepted socket owner | process tree fd links via processFileSystem | inode0 pending, foreign pending until budget, vanished/reset/closed retry; diagnostic tests | | Process ownership | existing stopped and identity checks each poll | stopped or replaced handle never ready; existing lifecycle tests retained | | Deadline | existing wall-clock budget and 500ms delay | full diagnostic jar/port/pid/budget/last outcome; configured-budget assertion updated to new text | | /proc availability | required read, no passing default | filesystem read failure names path/reason; focused injected failure test |

OBSERVED: Cherry-picked three test-only commits from requested branch (the two files plus their follow-up observation change), local head 0de1d2a43. Both targeted red commands are running with 900-second outer bounds; src/main remains unchanged. Delegated understood fixture migrations to inode_fixtures, success/IPv6/hygiene tests to probe_contract_tests, and nursery-level route tests to nursery_route_tests, all gpt-6-luna max. They share this branch, have disjoint file ownership, and may not run tests/commit/push until coordinated here.

OBSERVED (05:35 UTC): Initial test-only checkpoint pushed and verified at https://github.com/CodexCoder21Organization/ContainerNursery/tree/fix/jar-readiness-accept-attribution (head https://github.com/CodexCoder21Organization/ContainerNursery/commit/0de1d2a4323ec465dd7b6eff3d167090a0331ee7). Red commands remain in cold preparation; the 05:33 worker stack is actively Kotlin-lexing, not in either test body. Added three unrun diagnostic scenarios (foreign accepted socket full message, inode-zero queued full message, unreadable required proc table full path/reason) and drafted the implementation outside src/main so neither red run can include a fix. No required test verdict is claimed yet.

OBSERVED: Documentation edits are limited to README and docs/ContainerProviders.md as this brief requires exactly one PR in this repository. update-documentation skill read; broader cross-repository updates are excluded by this explicit scope. Read the linked racing-CI doc: required GitHub runner check bld-build races local and remote; this brief leaves monitoring to the supervisor. No check or workflow edits.

OBSERVED (05:38 UTC): Shared reproducer valid RED before any src/main edit: timeout --signal=TERM --kill-after=15s 900s scripts/test.bash --local --test testDangerJarFile_sharedInheritedListenerDoesNotConfirmForeignServer (raw /tmp/r2-shared-red.log).

FAILED containernursery.testDangerJarFile_sharedInheritedListenerDoesNotConfirmForeignServer -> java.lang.AssertionError: start() reported ready even though the shared inherited socket delivers requests to an unrelated process. Expected value to be not null. (in 4.5 seconds)
OBSERVED shared socket: foreign response=foreign, successorAlive=true, startFailure=null
TESTS FAILED (0/1 tests completed successfully, 1 failed)

OBSERVED: First bound command failed before its body, runner TESTS FAILED (0/1 tests completed successfully, 1 failed) after transient repository resolution errors: java.net.ConnectException (Connection refused (connect failed)) while downloading https://kotlin.directory/.... Full error and stack traces preserved /tmp/r2-bound-red.log (771697 bytes), including CoursierNetworkTimeouts.kt:490 -> fetchBoundedBySocketTimeouts -> coursierResolveLocalArtifact -> resolveBuildRuleArtifactWithPom -> prepareTests -> CliKt.main. Direct curl then returned HTTP/1.1 200 OK for the failed cache POM. This is preparation evidence, not a defect verdict. The immediate retry command stopped before launching a test because rebase correctly refused concurrent unstaged fixture migration edits; committed that stable WIP snapshot before retrying, so no work was stashed or overwritten.

OBSERVED: Found two additional existing OSHI inode fixtures not named in step 7: testDangerJarReadinessSignedIntMaxSocketInode and testDangerJarReadinessAboveUnsignedIntSocketInode. Choice: migrate these through the same filesystem seam as the named low/boundary tests, retaining their exact inode constants and owner/readiness/reply assertions, so they do not become disconnected OSHI-only checks. Every edit will be listed in final findings and PR.

OBSERVED (05:42 UTC): Bound reproducer valid RED before any src/main edit. Command timeout --signal=TERM --kill-after=15s 900s scripts/test.bash --local --test testDangerJarFile_boundButNotAcceptingChildIsNotReady; raw /tmp/r2-bound-red-2.log. FAILED containernursery.testDangerJarFile_boundButNotAcceptingChildIsNotReady -> java.lang.AssertionError: start() reported ready while the child had only bound and listened; the test-owned gate still prevented accept() (in 7.1 seconds) OBSERVED queued nursery connection: port=41891, child=11917, accepted inode=0 OBSERVED held accept gate after three poll intervals: startCompleted=true TESTS FAILED (0/1 tests completed successfully, 1 failed)

OBSERVED: With both required red runs recorded, applied drafted source replacement. First green run selects only the two reproducers (--test may repeat per runner help), no new contract scenario is run yet. Last successful fetch/rebase before this edit was 05:38 on origin/main ce4d894a9; origin/main remains unchanged. Future build/rebase work will use checkpoints rather than stashing concurrent fixture edits. 2026-10-27 05:43 UTC — RUNNING. The request is to make newly launched JAR readiness prove that the launched process tree accepted the nursery's connection, cover the contract with tests, and open exactly one pull request without merging, deploying or watching CI.

Both required reproducers now fail for the stated defects before any production edit. The shared listener test observed the foreign response while start() returned ready; the gated listener test observed inode zero and startCompleted=true before accept was permitted. The implementation is now applied and its first two-test green run is building.

The readiness loop keeps its own empty connection open while polling Linux's server-side TCP row and the launched tree's fd links. A nonzero accepted inode attributed to a live launched-tree process establishes readiness; queued, closed and foreign connections do not. This proves acceptance only; the existing URL RPC probe separately verifies its framed reply.

The remote branch is https://github.com/CodexCoder21Organization/ContainerNursery/tree/fix/jar-readiness-accept-attribution. No PR exists yet. The red tests and a WIP fixture/documentation checkpoint are pushed; the production change remains local until its first green checkpoint.

Delegated work at a glance: gpt-6-luna max inode_fixtures migrated the boundary/low and two related inode fixtures; static review led to a real accept acknowledgment and bounded worker cleanup before any run. gpt-6-luna max probe_contract_tests prepared success-per-facade, IPv6 and socket-hygiene scenarios and is correcting control-event ordering found in review. gpt-6-luna max nursery_route_tests finished both nursery-level public request scenarios without running them, and is now independently reviewing test coverage.

Obstacle: the first bound-test attempt failed before its body during dependency fetching with kotlin.directory connection refusals. A direct request then returned 200 and the next runner reached the intended assertion failure; the full preparation error and stack traces are retained. No user decision is needed. No unnecessary holds. No idle landing gates. Owner direction captured: none new.

Next steps: obtain the two green results, run the reviewed contract tests and reverse control, finish the full suite, and open the single PR before the 07:53 UTC hard stop.

Lessons: preserve runner preparation failures separately from test verdicts; force acceptance with a test-owned gate and observable acknowledgment; keep socket ownership explicit across coroutine cancellation.

OBSERVED (05:48 UTC): Progress checklist: required reading/kernel+okio experiment DONE; both baseline defect verdicts RED DONE; initial branch checkpoint pushed DONE. Production implementation applied, first-green two-reproducer run IN PROGRESS. Contract/diagnostic/IPv6/hygiene/nursery fixtures written and undergoing static review, no recorded new-scenario runs yet. Full suite/reverse control/PR remain PENDING. Status report upload printed Reported RUNNING and usage-record confirmation before the command's bound; no background report process remains.

OBSERVED: Initial independent static fixture review caught queued-inode and control-event-order mistakes before any new test run. The success fixtures now assert inode zero with the accept gate held, explicitly acknowledge accept, keep the accepted socket held so its nonzero inode/fd ownership can be checked, and consume the separate request's own ACCEPTED event. Probe poll-count instrumentation now counts tcp-table reads rather than summing both families. These are unrun fixture preparation corrections, not omitted runner failures.

INFERRED: Adversarial production-code pass checked tuple matching, native-endian proc address words, IPv4-mapped normalization, Long inode parsing, expected process identity/liveness, stopped state, all probe exit paths and explicit finally closure. Foreign PID scanning is optional deadline detail: the readiness decision reads only launched-tree fd entries, so unreadable /proc/1/fd cannot cause a false ready result. Required TCP table reads fail with path/reason; fd entries disappearing during scans cannot prove acceptance. No production finding established by this pass so far.

Inode readiness fixture migration findings

Plan

• [x] Read repository AGENTS.md, the assigned readiness fixtures, and the supplied /tmp/r2-TESTING.md guidance on public API tests and isolation.
• [x] Inspect the ForwardingFileSystem / FileMetadata APIs and the public processFileSystem constructor parameter.
• [x] Repoint the five assigned readiness fixtures at real accepted-socket attribution through processFileSystem while preserving their scenarios and assertions.
• [x] Review the assigned diff for whitespace issues; no tests or builds were run, as requested.

Progress and reasoning

• OBSERVED: The old fixtures redirected OSHI to a fabricated temporary /proc tree with a LISTEN row and synthetic socket link. The low, signed-int-max, and above-unsigned-int tests then asserted the OSHI listener-owner PID; the large worker had four boundary inode values for each address family plus a foreign-owner pending case.
• INFER: Those rows did not exercise accepted-socket attribution. A LISTEN row can exist before the child has accepted ContainerNursery's readiness probe, so the fixtures must establish acceptance through a real connection and keep the accepted descriptor open until the probe closes.
• OBSERVED: Okio ForwardingFileSystem exposes source(Path), metadataOrNull(Path), and list(Path); FileMetadata.symlinkTarget is the target exposed by the synthetic /proc/<pid>/fd links. DangerJarFileBackedContainer already accepts an injected processFileSystem in its public constructor.

Before / after edits

1. tests/testJarListenerLargeInodeReadiness.kts

   • Before: forced the worker JVM to IPv4, then asserted worker exit, INODE_SCENARIOS_OK:10, and the existing 30-second completion bound.
   • After: removed only the process-wide IPv4 restriction so the worker can launch isolated IPv4 and IPv6 scenario JVMs. The same exit, marker/count, and 30-second assertions remain.

2. tests/testJarListenerLargeInodeReadiness/LargeInodeWorker.java

   • Before: wrote synthetic /proc listener rows and fd links; OSHI's owner PID was selected as the child or an unrelated process. The child wrote byte 42 and closed accepted sockets immediately.
   • After: both family workers bind real loopback addresses and retain accepted sockets after writing byte 42 until EOF; they fail if the client sends application bytes. A child-to-driver control signal confirms the real readiness probe was accepted before the virtual 500 ms poll is advanced. A ForwardingFileSystem reads real /proc/net/tcp and /proc/net/tcp6, rewrites only a matching live ESTABLISHED row with a nonzero inode after its raw inode is found under the child’s real fd directory, and maps that fd metadata to the selected synthetic inode. The two family workers share the existing 30-second total budget, and the parent worker force-stops and awaits family-process descendants on completion or timeout. The four inode values per family remain 2147483647, 2147483648, 4294967295, and 4294967296; the fifth per-family case still attributes the accepted inode to an unrelated process and asserts readiness remains pending. Added direct assertions that the synthetic inode maps to a child fd only in the child-attributed cases. The family workers share the existing 30-second worker budget and forcibly stop/await descendants on timeout.

3. tests/testDangerJarReadinessLowSocketInode.kts

   • Before: made a fake LISTEN row with inode 42, asserted the child stayed alive and answered byte 73, required readiness success, then queried OSHI for the listening PID.
   • After: retains inode 42, child-alive and real-byte-73 assertions, and readiness-success assertion. The child keeps each accepted socket open until EOF and checks that the client sent no bytes. The injected forwarding filesystem rewrites the real accepted row only after the child’s actual fd table contains its raw inode; assertions now verify the synthetic inode is exposed on the child fd and that the reported acceptor PID is the child PID. Removed the OSHI global proc-path setup and owner query.

4. tests/testDangerJarReadinessSignedIntMaxSocketInode.kts

   • Before: same fake-listener/OSHI-owner assertions as the low fixture, using inode 2147483647.
   • After: applies the same real accepted-socket filesystem attribution and retains the exact inode plus all alive, reply, readiness, and cleanup assertions.

5. tests/testDangerJarReadinessAboveUnsignedIntSocketInode.kts

   • Before: same fake-listener/OSHI-owner assertions as the low fixture, using inode 4294967297.
   • After: applies the same real accepted-socket filesystem attribution and retains the exact inode plus all alive, reply, readiness, and cleanup assertions.

Verification state

• git diff --check passed for the five assigned files after the acceptance-signal and family-worker cleanup updates.
• Tests and builds were not run, per the parent task.
• Parent checkpoint/rebase was completed. The readiness scripts and the initial worker migration are in the parent’s WIP commit; the latest bounded-family/accept-signal refinement is an uncommitted edit in LargeInodeWorker.java for the parent to checkpoint after review.
• Changed tracked files under this assignment: the four readiness test scripts and tests/testJarListenerLargeInodeReadiness/LargeInodeWorker.java.

OBSERVED (05:55 UTC): First GREEN run for the same two reproducers after implementation (raw /tmp/r2-first-green.log): timeout --signal=TERM --kill-after=15s 1200s scripts/test.bash --local --test testDangerJarFile_sharedInheritedListenerDoesNotConfirmForeignServer --test testDangerJarFile_boundButNotAcceptingChildIsNotReady; runner ALL TESTS PASSED (2/2 tests completed successfully). Checkpoint pushed at https://github.com/CodexCoder21Organization/ContainerNursery/commit/97fd566d7 (full SHA to be recorded at final).

OBSERVED: Existing fixture control (not a new scenario) on the fix, before modifying its app: FAILED containernursery.testDangerJarFileBackedContainer_urlFacadePortConnectableAfterStart -> Test 'testDangerJarFileBackedContainer_urlFacadePortConnectableAfterStart' timed out after 30000ms, stuck at: containernursery.TestDangerJarFileBackedContainer_urlFacadePortConnectableAfterStartKt.testDangerJarFileBackedContainer_urlFacadePortConnectableAfterStart(testDangerJarFileBackedContainer_urlFacadePortConnectableAfterStart.kt:84) (in 34.5 seconds) and TESTS FAILED (0/1 tests completed successfully, 1 failed) (raw full error/JVM stack dumps /tmp/r2-immediate-close-control.log). The app's ss.accept().close() closes before attribution; closed/EOF observations are deliberately inconclusive under this brief. Updated that exact fixture pattern in 19 existing files to retain the accepted socket until client EOF. Assertions, iteration counts and all timeouts are unchanged; the same targeted control will be rerun. File list follows, with each edit meaning the same before/after substitution: <listener>.accept().close(); -> try (java.net.Socket accepted = <listener>.accept()) { accepted.getInputStream().read(); }. tests/testDangerJarFile_maxMetaspaceSizeDefaultsTo128mWhenUnconfigured.kts tests/testDangerJarFile_repeatedKillDoesNotReleaseNewPortReservation.kts tests/testDangerJarFile_maxMetaspaceSizeRespectsConfiguredValue.kts tests/testDangerJarFile_killCleansUpContainerTmpDir.kts tests/testDangerJarFileBackedContainer_urlFacadeWaitsForTcpReadiness.kts tests/testDangerJarFile_killWaitsForUnpublishedChild.kts tests/testDangerJarFile_defaultNativeAllocatorArenaCountIsBounded.kts tests/testDangerJarFile_portOwnershipFollowsGenerationAcrossReplacement.kts tests/testDangerJarFile_killPublishedChildIsTerminal.kts tests/testDangerJarFile_killWinsBeforeLaunch.kts tests/testDangerJarFileBackedContainer_startResumesReadinessWithoutRespawn.kts tests/testDangerJarFile_childTmpFilesGoToContainerTmpDir.kts tests/testDangerJarFile_explicitNativeAllocatorArenaCountIsPreserved.kts tests/testDangerJarFile_shutdownDoesNotMarkContainerDeadIfStillAlive.kts tests/testDangerJarFile_adoptionRejectsPortOwnedByAnotherGeneration.kts tests/testDangerJarFile_shutdownEscalatesWhenChildIgnoresSigterm.kts tests/testDangerJarFile_shutdownCleansUpContainerTmpDir.kts tests/testDangerJarFileBackedContainer_urlFacadePortConnectableAfterStart.kts tests/testDangerJarFileBackedContainer_rejectsTcpSelfConnection/GatedListener.java

OBSERVED: The three pre-existing full error-message assertions were adapted, without relaxing full equality: configured startup budget and resumed start now include JAR path/process pid/last failed connection; unrelated-listener rejection records the actual accepted inode through processFileSystem and expects the foreign PID/inode in its full deadline diagnostic. The latter adds a positive-inode assertion. Their original budget, retained-child, resume-same-PID and real-response assertions remain unchanged. Both queued-timeout and required-proc-error diagnostics additionally compare exact nursery socket inode sets before/after the failure; foreign timeout does the same before the separate HTTP caller.

OBSERVED: No src/main or test source still references OSHI; removed its sole explicit pin from build.kts. build.gradle.kts has no matching dependency. URL RPC probe, adoption production path and Docker production path unchanged. Existing immediate-close fixture edits include an adoption test's newly launched fixture, not adoption code or its connect-only policy.

OBSERVED (06:02 UTC): New-scenario group 1 is running for the first time: four facade success cases, IPv6-only, success/cancel socket hygiene, three diagnostics/error-cleanup cases, four inode fixtures, and five existing readiness neighbors (19 selectors). Command and raw output are /tmp/r2-contract-group1.log; no result yet. Last fetch/rebase was 05:57 at head 760c034d54484db919a0156d21372b60da36d718 with main still ce4d894a9. The seven standalone probe fixtures' eight Java sources passed bounded javac preflight; three extracted Java inode drivers also compiled. The large inode worker's Java-only preflight was not run because its test-only coroutine scheduler dependency was absent from the prepared production classpath; the actual test runner will resolve its declared WithArtifact, without a skip or altered test budget.

OBSERVED: Static test review /tmp/r2-test-review.md led to additional exact-tuple, explicit mapped-tcp6, stop-with-open-probe and forced-reset/retry scenarios. They are being prepared before first runs. The proposed tightening of post-ready test snapshots from state 01/08 to only 01 was refuted: CN may already have closed its probe after proving acceptance, while the test's child-side C gate deliberately keeps the accepted fd alive in CLOSE_WAIT(08); insisting on 01 then would add an observation race. Queued inode-zero rows remain not accepted in either state, and production itself requires 01 before attributing acceptance.

OBSERVED: Enumerated processFileSystem consumers: the only pre-existing named injection outside these updated/new fixtures is testDangerJarFile_procReadDuringCollection, which calls adoptExisting (excluded from this change) and does not gain readiness proc reads. All new attribution reads use the constructor seam; the inode wrappers and read-counting wrappers implement/forward source, list and symlink metadata honestly. Dedicated independent production-code review now in progress with a non-implementing agent. 2026-10-27 06:03 UTC — RUNNING. Original request: make newly launched JAR readiness prove acceptance by the launched process tree, test the contract and open one PR without merging or deploying.

Both defect reproducers passed after the fix: ALL TESTS PASSED (2/2 tests completed successfully). That source checkpoint is pushed on https://github.com/CodexCoder21Organization/ContainerNursery/tree/fix/jar-readiness-accept-attribution. No PR is open yet.

The first 19-selector contract/neighbor group is running. The loop attributes a nonzero established probe inode to the live launched tree, retains an empty probe through polling, and closes it on every exit. It proves acceptance; URL RPC's existing framed-reply check remains separate.

An existing immediate-close fixture failed on the fix before harness edits. Nineteen minimal fixture apps now hold accepted sockets until probe EOF, keeping their assertions and budgets; its named control is included in the current rerun. The three old full deadline-message assertions were updated to the new full diagnostic, and OSHI's unused explicit pin was removed after verifying no source/test references remain.

Delegated work at a glance: gpt-6-luna max inode_fixtures completed inode migration and Java preflight and is adding explicit mapped-tcp6 coverage. gpt-6-luna max nursery_route_tests completed nursery scenarios and static test review, then added exact-tuple coverage and is adding a controlled real reset/retry scenario. gpt-6-luna max probe_contract_tests completed facade/IPv6/hygiene tests and Java preflight, added stop-with-open-probe coverage, and is doing an independent production-code review. No delegated test runner is active.

No user decision is needed. No unnecessary holds. No idle landing gates. Owner direction captured: none new.

Next steps: finish the contract groups and reverse control, run the exact-head full suite, then push and open the PR before 07:53 UTC.

Lessons: test the full connection tuple, retain acceptance long enough for attribution, and distinguish cleanup of the probe from ownership of a fixture control socket.

OBSERVED (06:08 UTC): Independent code review /tmp/r2-code-review.md found no confirmed production behavior defect. It found two stale documentation lines: README's existing OSHI listener-owner claim and the orphaned OSHI version comment in build.kts. Replaced the README claim with the 64-bit accepted-inode contract and removed the orphan comment; no behavioral test is needed for those prose/comment corrections. Completed test fixtures were checkpointed before their pending group results; no first-attempt green claim is being inferred from javac preflight.

OBSERVED (06:10 UTC): Group 1 runner completed but is NOT first-attempt clean:

WARNING: Flaky test: passed on attempt 2 of 3 after failing on attempt(s) 1.
ALL TESTS PASSED (19/19 tests completed successfully)
WARNING: 1 test passed only after retry; see per-test attempt history.

Raw /tmp/r2-contract-group1.log. The default console output omits the retried test's name and original traceback; no --log or --result-file was specified. Do not infer all new tests passed first attempt from the summary. A bounded read-only artifact search is underway to recover the original attempt evidence; all future runner commands will use explicit JSON result and XML logs. This is an obstacle and a verification gap, not a clean group checkpoint. Read fix-flakey-test skill; no CI rerun or guessed fix will be used. The source-level code review found no behavior defect; last prepared-fixture branch checkpoint is https://github.com/CodexCoder21Organization/ContainerNursery/commit/222aaa320c429501233366614499ef5539b8fbec.

OBSERVED (06:22 UTC): Original retry evidence recovered from retained runner artifacts; the retried test was the EXISTING testJarListenerLargeInodeReadiness, not a new scenario. /tmp/r2-group1-attempt-evidence.md lists all paths. First attempt UUID ea87ebba-6b27-453e-bd74-ce58d7cac5aa: Test 'containernursery.TestJarListenerLargeInodeReadinessKt.testJarListenerLargeInodeReadiness' exceeded per-test timeout of 30000ms; child process killed. Full original error/classpath/stack and worker log copied to out/r2-artifacts/. Main-thread stack is ProcessImpl.waitFor -> TestJarListenerLargeInodeReadiness.kt:32. All ten new cases in group1 therefore passed first attempt; the other existing cases except the large matrix did too. The updated immediate-close URL control is GREEN on its first post-migration attempt.

OBSERVED: First large fixture root birth 06:08:29.235, class compilation finished06:08:36.848, worker.log born06:08:36.876 and lastwritten06:09:01.895 with INODE_SCENARIOS_OK:10. It completed all ten cases ~32.6s after testrootcreation: ~7.6s compilation plus ~25s matrix. The worker launches the full LargeInodeWorker driver class with its205-JAR test classpath as each of ten listener children. The listener only needs JDK sockets. Mechanism to fix: repeated driver/dependency initialization in app children consumes the fixed30s overall test window. Reproducer is the already-recorded first-attempt30s failure (1 of2 recorded attempts failed). Implementing a JDK-only listener entrypoint with only the compiled fixture directory on childclasspath preserves every case/acceptsignal/EOFassertion and removes that unrelated repeated work; no timeout/iteration/assertion change.

OBSERVED: Group2 first run launched with XML and JSON outputs for six scenarios: mappedtcp6, exacttuple, stopcleanup, resetretry and both nursery requests. Before their first run, nurseryfixtures were made deterministic with ManualClock and a real container factory whose existing launcher seam waits for BOUND before provider readiness starts; neveraccept advances the nursery clock only after observing the queued probe. StartupTimeoutSeconds remains3. Static setup resource guards were added without changing assertions or any timeout. These preparation changes are not presented as a fix for the original large-matrix timeout.

OBSERVED (06:34 UTC): Fixed large inode matrix GREEN, first post-change attempt: runner ALL TESTS PASSED (1/1 tests completed successfully), JSON testsPassed1/testsRun1/testsFailed0, XML time14532ms. Raw /tmp/r2-large-inode-fixed.{log,json,xml}. All10 cases and original bounds retained. Measured healthy test work fell from~32.6s to14.532s without increasing resources/timeouts or cutting iterations.

OBSERVED: Group2 did NOT meet the all-new-first-attempt bar. First command returned TESTS FAILED (4/6 tests completed successfully, 2 failed). Four ran and passed first attempt: nursery neveraccept14321ms, stop14922ms, nursery lateaccept15065ms, mappedIPv618527ms. Tuple and reset failed to compile before their bodies (Type mismatch: inferred type is String but () -> Any was expected, full traces /tmp/r2-contract-group2.xml). Three non-null assertions called checkNotNull with eager String messages; replaced with kotlin.test.assertNotNull, retaining assertions and text.

OBSERVED: First executable tuple/reset run then failed for fixture setup errors, not readiness behavior (full errors/child traces /tmp/r2-tuple-reset.log and XML):

• FAILED containernursery.testDangerJarProbeRetriesResetConnection -> java.lang.AssertionError: The readiness filesystem hook must observe the first reset without error. Expected value to be null, but was: <java.lang.IllegalStateException: The child must accept the first readiness probe before its reset; received 'null'>. (in 20.2 seconds); child SocketTimeoutException at ProbeServer.java:18 because test never opened its first R gate.
• FAILED containernursery.testDangerJarProbeIgnoresDifferentConnectionTuple -> java.lang.AssertionError: The real backend probe must reach the child's accept queue before synthetic tuple rows are injected; pid=24482, port=39217 (in 21.1 seconds); wrapper captured hostPort before start allocated it and filtered the actual queued row out.

OBSERVED: Corrected setup by taking PORT from builder.environment inside processLauncher for both and releasing reset's first R before nursery connects. Added a child-side C gate for the second accepted retry socket so its fd/inode observation cannot race nursery close. Assertions/timeouts unchanged; no production edit. Both full failing traces retained; next run /tmp/r2-tuple-reset-fixed.{log,json,xml}. These two new test failures mean the literal first-attempt requirement was missed; do not report that bar as met or hide them behind later green runs. 2026-10-27 06:35 UTC — RUNNING. Original request: accepted-connection readiness for launched JAR process trees, complete contract tests and one open PR, without merge or deployment.

The implementation and completed fixtures are pushed on https://github.com/CodexCoder21Organization/ContainerNursery/tree/fix/jar-readiness-accept-attribution. No PR is open yet. The two required reproducers are green after their recorded red baselines. The large existing inode matrix initially exceeded its unchanged30s budget; its JDK-only listener refactor now passes in14.532s with all10 cases preserved.

Fourteen new scenarios have passed their first executable attempts across the two contract groups. Two added tuple/reset scenarios failed compilation and then failed their first executable attempts because of fixture setup errors; both failures and full traces are retained in the findings. Their port initialization and gate sequence are now corrected and the focused rerun is active. The literal all-new-first-attempt bar was missed for those two tests, and this is not being described as a clean first run.

The readiness code proves acceptance of an empty nursery connection by the live launched tree through kernel socket attribution. It rejects inode-zero backlog entries and outside acceptors, keeps the original budget and polling checks, and closes the probe on every exit. HTTP/TLS/raw TCP responses are outside that guarantee; URL RPC's existing framed reply probe is unchanged.

Delegated work at a glance: all three gpt-6-luna max agents are idle after completing their assigned fixture, artifact-recovery and independent review tasks. The independent production review found no behavior defect; stale OSHI prose was corrected. Static fixture reviews led to manual-clock startup gates and setup cleanup guards. The primary now owns the remaining test runs and PR.

No user decision is needed. No unnecessary holds. No idle landing gates. Owner direction captured: none new.

Next steps: finish the tuple/reset run, run the reverse control and exact-head full suite, then open the PR with all successful and failed-attempt evidence before the07:53UTC hard stop.

Lessons: retain per-attempt runner artifacts instead of trusting an aggregate green summary; keep listener fixtures independent of unrelated driver class loading; initialize observed ports at the actual process-launch boundary.

OBSERVED (06:49 UTC): Corrected tuple/reset run GREEN: ALL TESTS PASSED (2/2 tests completed successfully), /tmp/r2-tuple-reset-fixed.{log,json,xml}. No auto-retry warning. The initial fixture failures remain part of the record and are not reclassified as first-attempt passes.

OBSERVED: Preparing those two scripts spent CPU in Kotlin's PseudocodeVariableDataCollector/ControlFlowInformationProvider over the deeply nested fixture-finally graphs (stack /tmp/r2-tuple-reset-preparation.jstack). Replaced those nested cleanup chains in nine standalone fixtures with ordered cleanup actions and aggregated/suppressed cleanup errors. Assertions/gates/limits retained. Added bounded Job.join after stop's completion latch: a latch counted down inside coroutine finally can precede Job's terminal state, so the test now waits for actual public Job completion before retaining its existing isCompleted assertion. No production code changed. Commit bfc9b2426 contains this final test-harness structure; the full suite will verify this exact head.

OBSERVED: Reverse control initially refused to start because concurrent tracked fixture edits made rebase dirty; no source was changed in that refused command. After checkpointing and rebasing, the actual control now runs with only the readiness source and build.kts temporarily restored to ce4d894a9 (the OSHI pin is needed to compile that old source). A shell EXIT/TERM trap restores the fixed source and dependency file on every outcome. Both reproducers are unchanged. Control outputs /tmp/r2-reverse-control.{log,json,xml}. No production/adoption/Docker/RPC path beyond the scoped readiness source is changed by this temporary experiment.

OBSERVED (06:58 UTC): Reverse control RED for both reproducers, then fixed source/build restored byte-for-byte (git diff quiet):

FAILED containernursery.testDangerJarFile_sharedInheritedListenerDoesNotConfirmForeignServer -> java.lang.AssertionError: start() reported ready even though the shared inherited socket delivers requests to an unrelated process. Expected value to be not null. (in 8.3 seconds)
FAILED containernursery.testDangerJarFile_boundButNotAcceptingChildIsNotReady -> java.lang.AssertionError: start() reported ready while the child had only bound and listened; the test-owned gate still prevented accept() (in 9.4 seconds)
TESTS FAILED (0/2 tests completed successfully, 2 failed)

JSON mode local testsPassed0/testsRun2/testsFailed2, /tmp/r2-reverse-control.{log,json,xml}. The command exited1 as expected; its EXIT trap restored both files. Full suite now runs on exact clean committed head bfc9b2426aa2fcde1f99d06901fbdc295532b5be, after fetch/rebase left main at ce4d894a9: timeout --signal=TERM --kill-after=15s 3000s scripts/test.bash --remote --test . --result-file /tmp/r2-full-suite.json --log /tmp/r2-full-suite.xml (stdout /tmp/r2-full-suite.log). This has a 50-minute outer deadline, leaving cleanup time before the150-minute stop. No CI/PR check is watched by this job.

OBSERVED: Final change inventory:48files,18new testfunctions (2required reproducers plus16contract scenarios),26edited existing test/support files, and readiness source/build/README/provider docs. All branch work through f9f0e2a3cf7f193133c217cc9832b413808ae2ee is already remote; the final cleanup refactor bfc9b2426aa2fcde1f99d06901fbdc295532b5be will be pushed with exact-head full-suite evidence. Seven bounded local targeted confirmations of the optimized existing inode matrix are delegated (max2concurrent), with complete JSON/XML/attempt evidence and stop-on-first-failure, while the full suite runs remotely. No local full suite competes with them.

OBSERVED (07:01 UTC): Remote full-suite attempt failed before submission/test execution because the build service was unavailable: [FAILED] Build service RPC 'health' to url://buildtest/ returned invalid health value "STARTING: recovering local state (elapsedMs=7326266)." (runtime class java.lang.String); expected exactly "OK". Full raw /tmp/r2-full-suite.log, exit1; no runId was assigned and no tests ran. This satisfies the brief's fallback condition. Canceled the seven supplemental targeted confirmations before any launched (0/7; agent confirmed no process groups/PIDs). Inspected machine-wide ps before fallback: literal ps -eo pid,args -ww | grep -c 'scripts/test.bash' returned4 because the matching entries were Codex prompt arguments and the inspection shell/grep, not active test scripts. The full ps inspection showed zero actual scripts/test.bash invocations and no local full suite.

OBSERVED: After fetch/rebase with clean final head bfc9b2426aa2fcde1f99d06901fbdc295532b5be and maince4d894a9, started the only machine-wide local full suite: timeout --signal=TERM --kill-after=15s 2850s scripts/test.bash --local --test . --result-file /tmp/r2-full-local.json --log /tmp/r2-full-local.xml Raw /tmp/r2-full-local.log. Bound47.5minutes ends before07:50, leaving cleanup/handoff time before07:53. No other full suite or supplemental targeted run competes. The exact final head is pushed on the requested branch; final suite counts and PR remain pending. The unavailable remote service is recorded here rather than using report-challenge's automatic extra PR/merge, which this brief forbids. 2026-10-27 07:20 UTC — RUNNING. The original request is to make ContainerNursery JAR readiness prove acceptance by the launched process tree, verify the contract and open one PR without merging or deploying.

The fixed source and all fixtures are pushed at bfc9b2426aa2fcde1f99d06901fbdc295532b5be on https://github.com/CodexCoder21Organization/ContainerNursery/tree/fix/jar-readiness-accept-attribution. A fresh branch PR search returns none, so no merge status applies. Both original reproducers are red before, green after, and red again under the reverse control. Two supplementary new fixtures missed the literal first-attempt-green requirement; their setup errors and corrected passing runs remain documented.

The readiness loop holds an empty probe and matches its accepted server-side inode to the live launched process tree. It excludes queued inode-zero connections and outside acceptors, preserves the startup budget and polling checks, and closes the probe on every exit. It proves acceptance only; URL RPC keeps its separate reply probe, and adoption and Docker are unchanged.

The remote full suite could not start because buildtest health reported STARTING while recovering local state. The bounded local fallback is actively preparing all test scripts at the exact pushed head; no runtime verdicts or aggregate counts exist yet. The Java process has accumulated CPU and its preparation stacks show script discovery and input-manifest hashing. The run has a hard deadline before07:50 and the task stops by07:53.

Delegated work at a glance: gpt-6-luna max inode_fixtures is finished with inode migration, mapped-address coverage, static review and nine cleanup refactors; its last result is a completed preservation review. gpt-6-luna max nursery_route_tests is finished with nursery-level tests, tuple/reset fixtures and their static review. gpt-6-luna max probe_contract_tests is finished with facade/hygiene fixtures, independent production review and recovered first-attempt artifacts; seven optional repeat runs were canceled before any started. No delegate or other test runner is active.

No unnecessary holds. No idle landing gates. Owner direction captured: none new.

Next steps: obtain the full-suite verdict, finish the PR evidence and open the single PR if the required checks finish within the hard wall limit; otherwise preserve the exact unfinished state in the existing handoff and stop.

Lessons: keep per-attempt artifacts rather than infer a clean run from an aggregate pass; retain accepted fixture sockets until probe EOF so ownership is observable; keep fixture initialization independent of unrelated driver class loading.

OBSERVED (07:21 UTC): PR description is prepared in /tmp/r2-pr-body.md (11.4KB) with the required owner quote, design reasoning, boundary, baseline/fixed/reverse evidence, explicit first-attempt exceptions, and every existing-test edit. It deliberately retains FULL_SUITE_COUNTS_PENDING and has not been submitted. Fresh gh pr list for this branch returned []. Current local full-suite process is still in preparation at 19minutes elapsed with no runtime verdict or result files; no full-suite pass count is inferred. All delegates are complete and no optional repeat runner is active.

Plan audit: [done] required reading and live Linux/Okio checks; [done] cherry-picked red reproducers and both valid red runs; [done] single readiness implementation with docs/dependency updates; [done] contract test groups and dedicated reviews, with literal first-attempt exception recorded; [done] reverse control; [in progress] exact-head full suite; [prepared, gated on suite verdict] final fetch/rebase and single PR; [pending] terminal findings/handoff and owned-process cleanup by07:53.

OBSERVED (07:24 UTC): Final brief-to-evidence audit while the exact-head suite prepares:

• Readiness choke point: both required foreign-shared and queued reproducers cover rejection, four facade tests cover acceptance, and the existing descendant-listener test forces its descendant to own the listener/accept path. No call site re-derives readiness.
• Probe ownership: success/cancellation/stop hygiene tests and the queued/foreign/proc-failure diagnostics compare real nursery socket baselines. Self-connection handling remains covered by the existing self-connection fixture and unchanged SO_LINGER reset.
• Attribution: real IPv6-only, mapped-tcp6 projection, controlled wrong-tuple rows and four inode fixtures cover family/tuple/64-bit parsing through the public filesystem parameter.
• Attempt outcomes: queued and foreign tests hold their conditions through owned gates; reset test forces an actual reset and then acceptance; process-exit behavior keeps the existing public error and its existing tests. Required table read fails with full path/reason; no default success path exists.
• Ownership/stop: stop-with-open-probe covers terminal ownership during the wait; existing resume-same-process and unpublished/published-child lifecycle fixtures retain their public assertions.
• Diagnostics: new full queued/foreign/read-failure comparisons and three adapted existing full-message comparisons keep JAR/port/PID/budget/outcome visible.
• Filesystem: all readiness proc content/list/metadata goes through processFileSystem. Early real Okio metadataOrNull symlinkTarget measurement succeeded, so no java.nio fallback or new seam was added. NurseryPidFile already reads /proc.
• Excluded scope: production adoption, Docker waitUntilTcpReady and URL RPC __protocol_probe are unchanged. No request bytes are added.
• Pending evidence: final cleanup-refactored exact head has not yet produced a full-suite result; no aggregate counts, all-suite pass claim or PR exists. The two supplementary fixture first-attempt failures remain an explicit unmet brief condition.

OBSERVED (07:25 UTC): Full-suite preparation advanced: the log grew from11to20lines with a second buildscript compilation completed (70c874bf...), and parent27605 launched BuildscriptRunner child29631. No test-scratch runtime directory or final result file exists yet. Stack evidence at /tmp/r2-full-preparation-0722.jstack shows active discovery/classpath validation/input hashing, not a terminal test outcome. The local outer deadline remains unchanged.

Prepared PR description (not submitted; full-suite evidence pending)

The owner asked: “Fix so readiness means the successor itself is accepting and serving.” Main combines OSHI's listener ownership with a successful TCP connect, but OSHI keeps only one PID per shared socket inode, and the kernel can complete a handshake into the backlog before any application calls accept. The supervising session chose kernel attribution of a connection opened by the nursery: a nonzero server-side connection inode must appear in the live launched process tree's fd tables. This needs no application changes, works across every TCP facade, avoids collapsed listener attribution, excludes queued inode-zero connections, uses parent-readable process-tree fd entries, and sends no application bytes—the startup probe still only opens and closes a connection.

This guarantees acceptance, not an application response, for HTTP, HTTPS and raw TCP. There is no application-neutral raw TCP request or TLS passthrough handshake; adding an HTTP probe would introduce new application-visible behavior. URL RPC retains its separate __protocol_probe framed-reply check. Adoption has no launched Process handle and keeps its current connect check; Docker readiness is unchanged.

The readiness choke point owns its empty probe across the existing polls, matches the server-side connection tuple in /proc/net/tcp or /proc/net/tcp6 (including IPv4-mapped IPv6), parses inodes as Long, and attributes acceptance through processFileSystem. It retains the existing startup budget, deadline checks, ownership checks, 500 ms cadence and self-connect reset. Closed/reset/vanished rows are retried; queued or outside acceptors stay pending. Deadline errors include the JAR, endpoint, launched PID, budget and last outcome, with accepted inode and readable outside PID. Required TCP-table read errors fail with path/reason.

README, provider documentation and KDoc state the guarantee and boundary. The unused OSHI pin was removed; no main/test source still references it and Gradle had no matching pin.

Tracking: handoff. The 64-bit inode fix and inode boundary coverage remain covered through accepted-socket fixtures.

Validation and existing-test edit details follow.

Validation at the frozen branch head is recorded below. Full-suite counts are pending and must be filled before this description is used to open the PR.

The two original reproductions demonstrate the change in both directions:

Test	Unchanged main	Fixed readiness	Reverse control with main readiness restored
testDangerJarFile_sharedInheritedListenerDoesNotConfirmForeignServer	Failed: start reported ready although the inherited shared socket delivered requests to an unrelated process	Passed	Failed with the same assertion
testDangerJarFile_boundButNotAcceptingChildIsNotReady	Failed: start reported ready while the test-owned gate still prevented accept	Passed	Failed with the same assertion

The fixed pair's runner verdict was ALL TESTS PASSED (2/2 tests completed successfully). The reverse control returned TESTS FAILED (0/2 tests completed successfully, 2 failed), then restored the source and dependency files byte-for-byte. The first bound-test command failed dependency preparation because kotlin.directory refused a connection; that is retained separately and is not counted as the defect's red result.

Contract coverage includes all four TCP facades; descendant acceptance (the existing descendant test); real IPv6-only and mapped-tcp6 attribution; exact connection-tuple matching; foreign and queued deadline errors with full text; a required proc-table read failure with its path and reason; success, cancellation, stop and error probe cleanup; a controlled real connection reset followed by a successful attempt; accepted inodes at signed and unsigned 32-bit boundaries; and first requests through the real ContainerNursery API for never-accepting and gate-delayed accepting JARs. Fixtures compile tiny Java programs and own their gates and cleanup. No request bytes, TLS handshake or HTTP readiness request were added.

The first contract/neighbor group ended ALL TESTS PASSED (19/19 tests completed successfully), with one automatic retry: the existing large-inode matrix exceeded its unchanged 30-second test budget on its first attempt. Retained worker timing showed it completed all ten cases after about 32.6 seconds, including about 7.6 seconds compiling the fixture; each listener unnecessarily started the complete driver and its 205-JAR classpath. Splitting out a JDK-only listener entrypoint removed that repeated work. The first run after that correction passed all ten cases in 14532 ms without changing budgets, case counts or assertions. Seven optional confirmations were canceled before any started when the full suite needed the local machine; no statistical repeat-run claim is made.

Two supplementary new fixtures missed the requested first-attempt-green bar. In the six-test second group, four passed first attempt; exact-tuple and reset fixtures first failed compilation because three non-null assertions passed an eager string to checkNotNull, and their first executable runs then failed because the observed port was captured before allocation and the reset fixture's initial accept gate was not released. The assertions were preserved with assertNotNull, the port is read from the actual launcher environment, and the reset gate is released before connect. The corrected pair returned ALL TESTS PASSED (2/2 tests completed successfully) without retries. These are recorded failed attempts, not presented as initial passes.

Full suite: FULL_SUITE_COUNTS_PENDING. The preferred remote run did not submit any tests: its health response was STARTING: recovering local state (elapsedMs=7326266)., where exactly OK was required. The permitted local fallback runs on the exact pushed head with a hard outer deadline. Any incomplete counts or first-attempt failures must be listed here before opening.

Existing-test edits, before and after:

• Nineteen minimal listener fixtures previously accepted and immediately closed the readiness connection. They now retain each accepted socket until the empty probe reaches EOF, so kernel attribution can observe the accepted fd. Their behavior assertions, iteration counts and timeout limits are retained. This is a fixture change required by the new acceptance contract; adoption production code remains unchanged.
  • tests/testDangerJarFile_maxMetaspaceSizeDefaultsTo128mWhenUnconfigured.kts
  • tests/testDangerJarFile_repeatedKillDoesNotReleaseNewPortReservation.kts
  • tests/testDangerJarFile_maxMetaspaceSizeRespectsConfiguredValue.kts
  • tests/testDangerJarFile_killCleansUpContainerTmpDir.kts
  • tests/testDangerJarFileBackedContainer_urlFacadeWaitsForTcpReadiness.kts
  • tests/testDangerJarFile_killWaitsForUnpublishedChild.kts
  • tests/testDangerJarFile_defaultNativeAllocatorArenaCountIsBounded.kts
  • tests/testDangerJarFile_portOwnershipFollowsGenerationAcrossReplacement.kts
  • tests/testDangerJarFile_killPublishedChildIsTerminal.kts
  • tests/testDangerJarFile_killWinsBeforeLaunch.kts
  • tests/testDangerJarFileBackedContainer_startResumesReadinessWithoutRespawn.kts
  • tests/testDangerJarFile_childTmpFilesGoToContainerTmpDir.kts
  • tests/testDangerJarFile_explicitNativeAllocatorArenaCountIsPreserved.kts
  • tests/testDangerJarFile_shutdownDoesNotMarkContainerDeadIfStillAlive.kts
  • tests/testDangerJarFile_adoptionRejectsPortOwnedByAnotherGeneration.kts
  • tests/testDangerJarFile_shutdownEscalatesWhenChildIgnoresSigterm.kts
  • tests/testDangerJarFile_shutdownCleansUpContainerTmpDir.kts
  • tests/testDangerJarFileBackedContainer_urlFacadePortConnectableAfterStart.kts
  • tests/testDangerJarFileBackedContainer_rejectsTcpSelfConnection/GatedListener.java
• testDangerJarFileBackedContainer_startResumesReadinessWithoutRespawn additionally changes its exact deadline-message expectation from listener ownership to the JAR path, port, PID, budget and connection-refused outcome. Its delayed-bind gate and same-process resume assertions remain.
• testStartupTimeoutSeconds_configuredValueGovernsReadinessWait changes the same exact deadline expectation and keeps the configured-budget and elapsed-time assertions.
• testDangerJarReadinessRejectsDifferentProcessListener previously expected a generic listener-owner deadline. It now records the real accepted connection inode through the existing filesystem seam, asserts it is positive, and compares the complete new foreign-PID/inode diagnostic. Its unrelated HTTP server and real response assertion remain.
• testJarListenerLargeInodeReadiness previously forced IPv4 on the driver. That restriction is removed so isolated family workers exercise both IPv4 and IPv6. Worker exit, the INODE_SCENARIOS_OK:10 marker and the unchanged 30-second completion assertion remain.
• testJarListenerLargeInodeReadiness/LargeInodeWorker.java previously supplied OSHI with fabricated LISTEN rows and fd ownership. It now starts real family-specific sockets, waits for an actual accept signal, rewrites only the matching real accepted row and fd metadata through ForwardingFileSystem, and retains the accepted socket until probe EOF. The four exact inode values 2147483647, 2147483648, 4294967295 and 4294967296 plus a foreign-owner case remain for each family (ten total). The listener is a JDK-only entrypoint; the driver retains its full classpath. Process cleanup is bounded within the original worker budget.
• testDangerJarReadinessLowSocketInode, testDangerJarReadinessSignedIntMaxSocketInode and testDangerJarReadinessAboveUnsignedIntSocketInode previously supplied fabricated OSHI LISTEN rows and queried the OSHI listener owner. They now require the real probe to be accepted and its raw inode to be present under the child's fd table before projecting the same synthetic inode through processFileSystem. The owner assertions become direct accepted-fd/acceptor-PID assertions. Inodes 42, 2147483647 and 4294967297, child-alive checks, readiness assertions and the real byte-73 response checks remain unchanged.

README's startupTimeoutSeconds, readiness and restart-handoff text and the danger_jarfile provider documentation now distinguish launched-process acceptance from a protocol reply, describe the accepted-socket attribution and its Linux proc requirement, and keep URL RPC's separate framed-reply probe explicit. The readiness KDoc states the same boundary. Existing NurseryPidFile already depends on /proc; Okio metadataOrNull(...).symlinkTarget was verified against real proc socket links.

Independent test review led to tuple, mapped-address, reset and stop coverage; independent production review found no confirmed behavior defect and corrected two stale OSHI prose/comment lines. The final cleanup refactor preserves fixture assertions and bounded cleanup while avoiding deeply nested compiler control-flow analysis. Adoption, Docker, and the URL RPC probe were left as specified.

🤖 Generated with Claude Code

Historical investigation (preserved)

ContainerNursery can report a JAR successor "ready" when it is not the process serving requests

Written 2026-10-27 ~04:50 UTC by opus-code-2026-10-27.

RE-VERIFY: this is a write-time snapshot. Recheck ContainerNursery main (here ce4d894a), the reproducer branch head and the live router before acting.

Owner direction for this handoff (verbatim)

On 2026-10-27 the owner said: "let's create a handoff describing the issue but do not propose the solutions, the handoff should allow fable to figure out what solution makes the most sense".

Choosing the solution is delegated to whoever picks this up. This handoff describes the problem, the evidence, the constraints and the references. It deliberately lists no candidate designs. Earlier reports on this effort listed options and recommended one. Don't treat those as decided. Work out what makes the most sense from the evidence, and record the reasoning in the PR description.

The original 2026-10-25 requirement still describes the goal, verbatim:

Fix so readiness means the successor itself is accepting and serving

That brief also said: "Pick the most robust approach that needs no app changes if possible; if a correct fix requires an app-side protocol change, stop and report the options instead of implementing a partial fix." The owner's 2026-10-27 direction now delegates that choice. If the solution you choose needs app-side changes, say so plainly, and cover every supported transport (HTTP, raw TCP, TLS passthrough, url://) and existing apps that don't take part. Don't silently ship something weaker than the goal while describing it as meeting it. If the guarantee you deliver is narrower, state exactly what it does and doesn't guarantee, in the code docs and the PR.

Standing constraints: no reflection, no mocks, no timeout increases, no iteration cuts, no weakened assertions, test-first, end-to-end tests through the public API, no merge, enqueue or deploy without the supervisor.

The problem

When ContainerNursery (CN) starts or replaces an app run from a JAR, it waits for the new process to be "ready" before routing traffic to it. On main, "ready" is decided by waitUntilTcpReady / jarProcessOwnsTcpListener in DangerJarFileBackedContainer.kt:1251-1290. Two conditions together count as ready:

1. The OSHI library reports that the successor's PID owns a TCP listener on the expected port.
2. A TCP connection to that port succeeds.

Neither condition establishes that the successor is accepting and serving.

Ownership can be wrong when a socket is shared. OSHI keeps one PID per socket inode. In OSHI 6.6.1, ProcessStat.querySocketToPidMap builds a Map<Long,Integer> with pidMap.put(inode, pid) (sources lines 438–448), and LinuxInternetProtocolStats assigns that single PID to each TCP row (lines 75–77). When several processes hold the same listening socket, one silently replaces another in the map. CN can therefore conclude that the successor owns the listener while another holder is the one accepting connections. Sources checked from https://kotlin.directory/com/github/oshi/oshi-core/6.6.1/oshi-core-6.6.1-sources.jar. CN pins oshi-core:6.6.1 in build.kts:85.

A TCP connect doesn't show the app is serving. The kernel completes TCP handshakes into the listen backlog before the application calls accept. A controlled experiment showed this (script and result below). A sole listener that had bound and listened but not yet accepted let a client connect and send a request, and sent no response. Once released, it accepted the same queued connection and answered HTTP/1.1 200 OK … successor. Exclusive ownership plus a successful connect is therefore still not "the successor is serving".

Evidence

• Failing regression test (review reproducer): testDangerJarFile_sharedInheritedListenerDoesNotConfirmForeignServer, on branch wip/hd22-L106-review-reproducers at 012a5711. A foreign process shares the inherited socket and serves the body foreign while the real successor sits gated. CN's start() still reports ready. It failed in 3 of 3 independent runs (1,331–2,227 ms). The failing assertion: start() reported ready even though the shared inherited socket delivers requests to an unrelated process. Command: scripts/test.bash --local --test testDangerJarFile_sharedInheritedListenerDoesNotConfirmForeignServer. It hasn't been re-run on current main yet: a 2026-10-27 attempt stopped during dependency preparation before the test body ran.
• OS experiment (no CN involved). Python 3, one child process, loopback:

import json, socket, subprocess, sys
source = '''
import socket, sys
with socket.socket() as listener:
    listener.bind(('127.0.0.1', 0))
    listener.listen(32)
    print(listener.getsockname()[1], flush=True)
    if sys.stdin.buffer.read(1) != b'1':
        sys.exit(0)
    with listener.accept()[0] as connection:
        request = connection.recv(4096)
        connection.sendall(b'HTTP/1.1 200 OK\\r\\nContent-Length: 9\\r\\nConnection: close\\r\\n\\r\\nsuccessor')
'''
child = subprocess.Popen([sys.executable, '-c', source], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
port = int(child.stdout.readline())
with socket.create_connection(('127.0.0.1', port), timeout=1) as c:
    c.sendall(b'GET / HTTP/1.1\r\nHost: localhost\r\n\r\n')
    try:
        c.recv(4096); raise AssertionError('answered before accept')
    except TimeoutError:
        pass
    child.stdin.write(b'1'); child.stdin.flush()
    response = b''
    while (part := c.recv(4096)):
        response += part
print(json.dumps({'before_accept': 'TCP connect succeeded; no HTTP response', 'after_gate_release': response.decode()}))

Recorded on 2026-10-27: {"before_accept":"TCP connect succeeded; no HTTP response","after_gate_release":"HTTP/1.1 200 OK\r\nContent-Length: 9\r\nConnection: close\r\n\r\nsuccessor","child_exit":0}.

• Router handover checks that pass (useful as neighbours, not as fix evidence): testInheritedHttpsListenerQueuesAcrossProcesses, testInheritedHttpsHelpersAwaitCompleteDrain and testInheritedHttpsReplacementChecksSuccessorConfiguration each passed on the first attempt.

How sockets are owned today (from source at the PR 747 head, 07677df6)

Resource	Owner and lifetime	What replacement does
JAR backend port	EphemeralPortAllocator picks a port using a temporary ServerSocket, then closes it. The launched app creates its own backend listener. CN holds the process and the port reservation, not an open copy of the listener.	A new app generation is a separate process on its own allocated port. No backend descriptor is transferred. An old generation can keep draining at its old endpoint.
Public inherited HTTPS listener	Held by the socket unit or external parent. The predecessor router, the successor-generation helper and the later successor router can each hold copies, and arbitrary parents can hand out more.	The helper waits for the predecessor's process-lifetime lock before exec'ing the new router. The predecessor stops accepting and drains.
Inherited HTTPS acceptance lease	The active router owns its selector and lease, not the parent socket.	Closing the lease stops acceptance and leaves the inherited listener open. The parent's copy survives.
Accepted connection	The generation that accepted it.	It may finish already-accepted requests during drain. That is intended.

Source links:

• JAR launch setup
• production JAR provider
• port allocator
• inherited HTTPS lease
• generation lock wait
• process-lifetime lock
• replacement script
• generation unit
• socket unit

Reachability (an earlier lane's reading of the code, worth re-checking): the stock CN JAR launch and replacement path doesn't itself create a shared backend socket. The reproducer creates one through the public launcher seam, and an app that deliberately shares descriptors could too. Separately, the second gap (connect without accept) applies to every JAR start, shared socket or not.

Environment facts that matter for any approach: on an ordinary unprivileged uid, /proc/1/fd is denied, so other processes' descriptors can't always be inspected. The production router runs as root on 198.199.106.165. Its exact supervision changes over time: on 2026-10-21 it was a transient systemd unit. The checked-in deploy/systemd templates are review material, not necessarily what is installed.

What already landed (don't redo)

• ContainerNursery PR 747, merged 2026-10-25: fixed inherited-HTTPS startup synchronization and an unrelated JAR-listener ownership bug. The shared-listener finding was raised in its review and wasn't addressed there.
• ContainerNursery PR 754, merged 2026-10-26: recognizes listeners whose socket inode exceeds 2^31-1 (OSHI 6.6.1).
• ContainerNursery PR 755, merged 2026-10-27: inode boundary tests for that fix.

These fix the width of the inode key. They don't fix the one-PID-per-inode behaviour, or what "ready" means.

References

• Repository docs: README.md, AGENTS.md, docs/RouterReplacement.md, docs/ContainerProviders.md, docs/FacadeProviders.md.
• An older branch, cn-rpc-application-readiness-gate-r05 (2026-08-16), touched application readiness for RPC. It's possibly relevant prior art; read it before deciding.
• TESTING.md, PHILOSOPHY.md, and the racing-CI doc https://my.externalbrain.wasmserver.com/doc/github-builders-racing-remote-ci.md (bld-build is the required check here).
• Superseded handoff with the full investigation history: url://handoff/handoffs/hf-2026-10-25-choose-the-shared-listener-readiness-contract-and-finish-the-containernursery-pr.

Branches and state

Repo	Branch	Head	PR	State
ContainerNursery	main	ce4d894a	none	Readiness predicate unchanged
ContainerNursery	wip/hd22-L106-review-reproducers	012a5711	no PR	Failing reproducer only, no fix
ContainerNursery	fix/hd22-flaky-inherited-https	07677df6	PR 747 merged	Done

Nothing in this effort is deployed, published or local-only. Note that a separate, owner-authorized CN router deploy of current main may happen on 2026-10-27, from the default-handler handoff. Check /root/cn-watchdog.audit on the host before any live verification.

Definition of done

A merged PR, whose first sentences say why it exists, that makes CN's readiness decision match the delivered guarantee:

• The shared-listener reproducer (or a stronger replacement) fails on main and passes on the fix.
• The connect-without-accept case is covered.
• Every affected transport is tested.
• The full suite passes on the final head, with first-attempt counts.
• Fresh-context test-comprehensiveness and adversarial reviews are clean.
• bld-build is green.

Include any docs and contract changes. Production rollout is a separate, owner-approved step.