Repository navigation
Conversation
Keep explicit host timeouts as pure total windows, admit progress only from startup modes, and give OpenCode host readiness a margin above the shared ceiling. Add behavioral regressions for each boundary.
|
Speaking as Kun's firstmate: thank you @WTF-Am-ID. This is a careful follow-through on #7791, and the body is unusually honest about what was and wasn't proven. I appreciate that. What I checked at head CI: this fork's runs were waiting for approval. I've approved CI run One ask, warmly: the evidence so far is fixture and lab runs, some on the older Contract-class: new-default. I agree with your own label, based on my own read. With nothing configured, the fixed 25-second window becomes a progress-renewed 25 seconds under a 100-second total. The first cycle gains a startup wait, and OpenCode's host-mode ready budget goes from 30s to 105s. So a stuck startup can now take up to about 100 seconds to reach main. That's a captain decision once it's otherwise ready, and I won't auto-merge it. VISION:
Waiting on you for the live run, and on CI. No rebase or other changes are needed. Once it's green with live evidence, it goes to the captain. |
…ts successful 750 ms CI measurement, with provenance documented. This addresses ci-1/ci-4 packing failures: modeled merge maximum falls from 1,204,351 to 1,199,434 ms without changing budgets or coverage. Passed OpenCode’s four local cases, syntax, documentation checks, lint and diff checks. Local runner verification failed with file-descriptor exhaustion under Bash 3.2, so no complete pass is claimed. ci-2 remains unconfirmed: its ledger records correct hand-back before the fixture timeout; upstream main has similar timing failures. Waits remain unchanged. ci-3 requires the outer executor to repair the missing PR pipeline signature. No pipeline controls or publishing actions were performed
|
The loaded successor published genuine readiness 35.028 seconds after journal creation, then handed the original check reason back unchanged and left its healthy watcher running. The stuck successor returned safely to main in 40.895 seconds. Both runs used The guests used Ubuntu 24.04, eight vCPUs, 12 GiB memory, CPU priority 0, 64 Core commands, with script names relative to the checkout: bin/fm-lock.sh
bin/fm-afk-contract.sh enter --words "Live successor-readiness proof"
FM_POLL=1 FM_CHECK_INTERVAL=1 bin/fm-supervision-host.sh parkAn intentionally registered maintenance check supplied the real close. For the progressing case, a kernel file lock blocked the successor's normal home-configuration load for 14.044 seconds before arm admission. A separate owned process held the actual recovery lock through Observed UTC records: Journal creation and readiness use the files' recorded write times. Stages use observation times. Readiness took 35.028 seconds, with observed intervals of 14.537, 3.182, 15.043 and 2.305 seconds from creation through readiness. The production The stuck successor reached stages 1 and 2 and produced no stage 3 or readiness line. The host returned the original check reason and this fail-safe line in 40.895 seconds from the observed successor attempt: There was no retained successor record and no surviving non-zombie arm or watcher under the recorded PID/starttime identities. The guardian quiesced the workload, archived its evidence and deleted the guest with no cleanup errors. The final checkout remained clean at the stated revision. The archive's verified SHA256 is The earlier positive attempt reached readiness at 24.894 seconds, and the first guest failed on npm DNS before either case. Neither counted as the greater-than-25-second startup proof. The successful runs used an offline official runtime package with verified npm integrity. The PR's CI repair added only the new suite's measured timing hint and its provenance. The required pipeline signature is restored. Workflows for the current head still await maintainer approval. |
|
Speaking as Kun's firstmate: thank you @WTF-Am-ID, this is exactly the live evidence I asked for, and it's documented very thoroughly. Live evidence: accepted. On a loaded Ubuntu 24.04 guest running the real host, arm, and watcher under a real OpenCode primary at New head CI: the earlier run on Contract-class stays new-default. With nothing configured, the fixed 25s window becomes a progress-renewed 25s inside a 100s ceiling, and the first cycle gains a startup wait. My VISION verdict is unchanged from the last comment (aligns on every rule; delegation n/a). Nothing more is needed from you right now. This is waiting on CI, not on you. Once there's a clean run on this head, it goes to the captain for the merge decision. |
bb4ccde to
79403dd
Compare
|
Speaking as Kun's firstmate: quick CI update on Once there's a clean run on this head, this goes to the captain as a decision. It changes the unconfigured successor startup wait, so it's new-default. It won't be waiting on you. |
|
Speaking as Kun's firstmate: two quick notes on this one, @WTF-Am-ID. No-mistakes attestation: the attestation in the PR body now names Overlap: #7873 (@kova1max) also extends the initial arm confirmation while a slow watcher start is making progress. It does that with CPU-time windows capped at Once the attestation matches the head and a clean run exists, this goes to the captain as a new-default decision. It's waiting on you only for the re-raise. |
WTF-Am-ID
changed the title
 [Medium impact] The latest changes appear safe to merge; the earlier Reviews (2) · Last reviewed commit: "no-mistakes(ci): Captain, fixed ci-1 at ..." · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…ry, mirroring OpenCode’s host window plus 5-second margin. Ordinary-arm timing remains unchanged. Reproduced the failure before patching; all four focused cases, canonical lint, and Bash syntax checks now pass. Exact commands, statuses, source hashes, and required PR disclosure are in /Users/daddy/.no-mistakes-upstream-codex/evidence/omp-ci-032.nKb8K7/result.txt. The outer executor must apply that disclosure. No fresh live or loaded validation is claimed
|
Speaking as Kun's firstmate: thanks @WTF-Am-ID, the re-raise worked. The no-mistakes attestation now names the current head, Why there's no CI yet: this head conflicts with main in contract-class: new-default, unchanged. Startup now gets a shared, progress-renewed wait capped at 100s, and the OpenCode and OMP host windows get longer. The overlap with #7873 still stands. This one is further along, and the captain will pick. Once a clean run exists on this head, it goes to the captain as a decision. Right now it's waiting on us, not on you. |
|
Speaking as Kun's firstmate: thanks for the re-raise, @WTF-Am-ID. No-mistakes now binds GitHub can't start CI on this head because the PR conflicts with main in contract-class: new-default. Startup progress waits are now bounded and shared across the watcher startup paths, which changes default timing. #7873 overlaps this, and this PR is further along. |
Closes #7791.
Supervision startup now shares one bounded progress allowance across the host, acknowledged hand-back owner, arm and watcher. This is a new-default change: 25 seconds without a new genuine milestone, within a 100-second total ceiling. Repeated states, heartbeats and PID existence do not renew the allowance. An explicit
FM_SUPERVISION_HOST_READY_TIMEOUTremains a strict total window without the default no-progress rule.Progress is advisory and cannot establish readiness. The existing live watcher identity, fresh beacon and valid recovery-generation checks remain required. A dead or stuck successor, invalid proof or expired allowance still hands the wake to main and retires only owned processes. Initial startup confirmation and OpenCode host mode are included, superseding the investigation's original case-40 exclusion. Cancellation has a separate bounded cleanup clock, and replacing an owned attempt removes its old journal.
The follow-up F1 fix suppresses
watcher: startedandwatcher: attachedlines from rejected initial attempts after arm retirement. This prevents rejected readiness from reaching OpenCode while preserving actionable wakes and failure details. The regression failed on the unchanged production code before the fix, then passed for both readiness forms and both close types.OMP's host-owner readiness timeout now mirrors OpenCode: it encloses the shared 100-second startup ceiling or an explicit longer host window with a 5-second publication margin, while preserving the separate ordinary-arm timeout. The focused public-extension regression failed before the change for all three host cases. After the fix, all four cases passed: default host readiness and unready-host expiry use a 105-second owner window, an explicit 120-second host window gets 125 seconds, and the ordinary-arm case keeps its configured 12-second deadline. These portable checks use real child processes and a controlled owner clock; they do not launch a real OMP primary or refresh the earlier loaded proof.
The maintainer accepted the earlier real loaded proof: progressing startup reached genuine readiness in 35.028 seconds, and the genuinely stuck successor handed the wake to main in 40.895 seconds. Those runs used
cd615ed88edaabf83ca2f80688c029c027f7b063, whose production startup files matched79403dd2. F1 and this OMP production change were made after that accepted proof. The current head has not had fresh live or loaded-primary validation. At F1 commit7609b09c, all eight portable checks passed: four OpenCode coordinator cases using substitute children and controlled timers, plus four real host/arm/watcher fixture cases using a controlled clock to cover rejected started/attached readiness, failure details and actionable wakes. F1's eight-case evidence was recorded before the host-comment and fixture-lint commits. These checks do not establish fresh loaded initial/successor completion, the full direct/acknowledged successor failure matrix, or continuity restoration through a real OpenCode primary. Firstmate accepted the current Test exception with those limits; the maintainer can request live re-validation. Follow-up test evidence.In the earlier run, the local pipeline Test step was approved after its 30-minute budget expired on the full
tests/fm-supervision-host.test.shrun. Before the budget cut, it reported passes for initial and successor startup beyond 25 seconds, the explicit 45-second window, stall, unchanged-progress, total-cap, dead-arm, forged-progress, cancellation, journal cleanup, retained successor, cadence, dialog recovery, engine hand-back and latch recovery. All four OpenCode coordinator cases passed. The full host file runs in upstream CI. No complete local full-file pass is claimed.After the Test agent timed out, the local host-file process returned exit 1 at the existing
warm-compact-stalefixture. Its unchanged GNU-stylesed -icommand fails under stock macOS sed and leaves the model setting unchanged. The same command was reproduced separately with exit 1 and unchanged input; Git blame traces the fixture to upstream commitc1669d96d807858f5eee63671f72042b12d235f0, already in the branch's upstream base. This separate fixture issue is unmodified.The loaded CI-box proof ran on
622cb37f0514ae35e3bb7bfb6fcee0e12f5a0e64, before the later timeout, mode, OpenCode and pipeline fixes. Three concurrent canonical calls-35–43 prefixes passed all nine cases each under 64 spinners, exit 0. The lab used factor-8 polling counts, a minimum selected wait of 120 seconds at the unchanged 0.1-second sleep, and a longer prefix backstop. Committed fixture assertions, polling counts and sleeps were not relaxed. A loaded pass with unchanged fixture waits remains unverified. The unloaded isolated case-43 control passed; the loaded isolated phase was deliberately skipped to fit the approved guest lifetime.An earlier G5 run on the same candidate had a case-41 successor fallback whose precise cause remains unknown because the detailed archive was lost. Its other two copies stopped during case 42 at the phase backstop. The subsequent G6 pass does not diagnose that earlier failure.
Review, Test with the approved budget exception, Document and Lint completed through no-mistakes. CI remains pending.
Pipeline
Updates from git push no-mistakes