Repository navigation
Conversation
Size Report
Startup median (7 runs, lower is better):
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 18 files
Reply with feedback, questions, or to request a fix.
View guided diff | Turn on auto-fix | Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 7 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
View guided diff | Turn on auto-fix | Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 6 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
View guided diff | Turn on auto-fix | Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 4 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
View guided diff | Turn on auto-fix | Re-trigger cubic
8e07d31 to
b55d10a
Compare
|
The code at b55d10a looks sound, but the claim "Fixes #3702" is not proven yet. I found no run on iOS 17.5, or any 17.x, so the fix is unverified for the reported case. The regression fixture ( Not blocking, and fine to take or leave: CI is red on all four failing jobs (Lint/Typecheck, Repo Guards, Integration, both Smoke) with Before merge, the 17.x first deep-link open at b55d10a needs to show |
…ch confirmation The runner read the alert title by walking every descendant of the resolution root, so a SpringBoard confirmation whose root carries host chrome (a page readout on iOS 17.5) reported that label instead of the alert's title, and the launch-confirmation title rule refused it. The title now reads the alert's own static texts, then its own label. An unanswered launch confirmation now reaches the caller: open reports launchConfirmation 'unanswered' with its typed reason and a warning pointing at alert accept, instead of exiting 0 with no field.
The outcome and its reason travel as one discriminated report from the settle through the daemon and client, so no printing site invents a fallback token. An unrecognized alert warns to inspect it before answering; an unresolved URL owner keeps the direct alert-accept guidance. The runner title read keeps the labelled-descendant walk as the fallback after the static-text and own-label reads.
…ir reasons A hung or failing URL-owner lookup left the recognized prompt on screen while the open succeeded silently; it now reports the same url-owner-unresolved outcome as an unresolved owner, whose warning says the owner could not be resolved rather than claiming none exists. The client reads the unanswered reason only for an unanswered outcome, OpenApplicationOutcome derives its variants from LaunchConfirmationOutcome, and the tests cover both reasons at the client and daemon seams.
An unreadable alert read or an unresolvable runner left open silent about a prompt that may still be up. The outcome now carries the failed step as a typed launchConfirmationProbeFailure on the absent arm, and the daemon appends a warning telling the caller to check with alert get. No launchConfirmation value is invented: the state is unknown, not unanswered. The launch-URL confirmation tests also split out of lifecycle.test.ts to stay under the test-size tripwire.
Every attempt now states the latest the probe knows: a failed accept read-back or an unreadable probe after a re-hand replaces an earlier accepted with the unknown prompt state, and a completed probe that sees nothing resolves the unknown. The seen arms of the contract forbid a probe failure beside a confirmation, and the versioned help documents the warnings for both unanswered reasons and for an unreadable probe.
An unreadable alert accept was invoked and could not be verified, so "could not run" was false for that step. The type and its comments now say the step failed or its result could not be verified, which holds for every step.
The exception lived implied in two comments and contradicted the lookup case they described. applyAttemptReport now owns the sentence: alert-read, alert-accept and runner settle to the unknown state, while url-owner reports the seen url-owner-unresolved. The settle doc and the test-table header point at that rule instead of restating it.
…s arms client-side The typed step named the failed read but ended as prose in a warning, so a machine reader could not tell "no prompt" from "prompt state unreadable". It now travels on the response beside its warning: the report builder passes the absent arm through, buildOpenResult takes either arm, the normalizer reads the step, the serializer carries it, and AppOpenResult reuses the discriminated outcome union instead of flat optional fields. Also: the LaunchConfirmation doc names it an alert seen in place of the launch, the single-row runner-step test.each becomes a plain test, and the CHANGELOG and commands.md document the widened launchConfirmation.
b55d10a to
c7e29d8
Compare
|
|
Rebased onto main after #3740 (clean, one Swift test-file conflict with #3715 resolved by keeping both tests) and pushed 17.x proof. No 17.x runtime is installable or downloadable here ( CI / linux.gap. Agreed at the time (I hit the identical TS2339 on an unmodified base worktree at Swift conflict verification. Both alert unit tests — CHANGELOG + commands.md. Added. commands.md gains the Probe failure on test.each → plain test. Done; the dead else branch is gone. Doc reword. Ready for the 17.5 lane whenever someone can run it; everything else above is at |
|
Correction to the live-evidence paragraph above: for the accepted run at |
This branch has not been deployed
1 participant
Summary
On iOS 17.5,
open --launch-urlleft SpringBoard's first-deep-link confirmation unanswered and exited 0 with nolaunchConfirmation.preferredAlertTitlewalked every descendant of the resolution root, so root-carried host chrome (the Home Screen page readout, labelled "0 pages" on 17.5) became the reported title and the launch-title rule refused it. It now reads the alert's own static texts first, then its own label; the walk stays as fallback.applyAttemptReport) maps the final answer attempt to what the settle reports. A seen confirmation returnslaunchConfirmation: "unanswered"with typedlaunchConfirmationReasonplus a reason-specific warning; the discriminated arms forbid a probe failure beside a seen outcome. When a probe step failed or could not be verified (alert read, accept, or runner — latest attempt wins over an earlieraccepted), the response carries a typedlaunchConfirmationProbeFailurestep plus a check-with-alert getwarning — deliberately nolaunchConfirmation: the state is unknown, not observed. Proven-failed accepts still fail withlaunch_confirmation_unanswered. The read trims the iOS alert resolution reads every element of the app window when a popover is found #2905 full walk on the common path but does not close it. CHANGELOG and commands.md document the widened fields.Part of #3702 — the 17.5 accepted-prompt proof is still owed; the issue stays open.
Validation
c7e29d8, rebased onto main after test(coverage): record Linux uninstall as an accepted limitation #3740/docs(agents): simplify review scope and follow-up rounds #3741.pnpm check:affected --run --head c7e29d8passed,exactCommit: true. TS suites 147 pass; both Swift alert unit tests (this PR's + fix(ios): alert dismiss picks a listed decline, never a guessed one #3715's, i.e. the conflict resolution) compile and pass on an iOS 27.0 simulator.c7e29d8, fresh iPhone-Duo iOS 27.1 sims + first installs: English first deep link →"accepted", no warning; French-locale first deep link →unanswered+alert-unrecognized+ warning,alert getread the localized title. A real accept whose dispatch stayed unconfirmed failed live withlaunch_confirmation_unanswered. Pre-rebase heads also passed their gates (exactCommit: true) except one stopped only by main's then-brokenlinux.gap(fixed by test(coverage): record Linux uninstall as an accepted limitation #3740).🤖 Generated with Claude Code