Preserve full open-url smoke workflow in plans and support Harmony inputs

[linhay]

Summary

While validating a real multi-platform app route, the agent needed to:

1. rebuild/run the iOS app,
2. install/launch the Harmony app,
3. open the same debug deep link on both platforms, and
4. wait/assert/capture enough evidence for handoff.

TritonKit already exposes pieces of this workflow (xcode run, app open-url, smoke ios, smoke harmony), but the agent-facing plan open-url flow does not currently preserve a complete end-to-end plan when the local server is not already running, and it does not expose Harmony-specific open-url planning inputs.

This made the agent fall back to XcodeBuildMCP for iOS build/run and raw hdc aa start -U for Harmony deep-link launch instead of following one TritonKit plan.

Environment

• TritonKit CLI: 0.1.16
• Host: macOS
• Scenario: real app debug route validation across iOS Simulator and Harmony emulator/device
• Sensitive app names, bundle ids, routes, and paths are redacted below.

Reproduction

Run an open-url task plan while the Triton server is not running:

triton plan open-url \
  --device <ios-simulator-udid> \
  --url '<private-debug-deeplink>' \
  --text '<expected-text>' \
  --json

Observed shape, shortened:

{
  "ok": false,
  "mode": "bootstrap",
  "goal": "open-url",
  "nextStep": "start-server",
  "steps": [
    {
      "id": "start-server",
      "command": "triton serve --host 127.0.0.1 --port 19421"
    },
    {
      "id": "connect-target",
      "command": "triton xcode run --json"
    },
    {
      "id": "diagnose",
      "command": "triton doctor --host 127.0.0.1 --port 19421 --format json"
    }
  ]
}

The returned plan is useful for bootstrap, but it loses the goal-specific steps the agent still needs after recovery: open the URL, wait/assert text, capture screenshot/evidence, and summarize artifacts.

Also, the schema for plan currently accepts task inputs such as --device, --url, --text, --expected-url, and --evidence, but does not expose Harmony-specific task inputs such as --platform harmony, --bundle, --ability, or --hap. smoke harmony supports some of these, but plan open-url cannot recommend the same Harmony path.

For comparison, the schema already has related primitives:

triton xcode run --jsonl
triton app open-url "example://debug" --device iphone15 --json
triton app open-url --device harmony-a --bundle com.example.app --ability EntryAbility example://debug --json
triton smoke ios --device iphone15 --bundle-id com.example.app --open-url myapp://home --wait-text Ready --json
triton smoke harmony --device harmony-a --bundle com.example.app --ability EntryAbility --open-url example://home --wait-text Ready --screenshot /tmp/smoke.jpeg --evidence /tmp/harmony.tritonevidence --json

Expected behavior

For agent use, triton plan open-url ... --json should either:

1. return a full staged plan that includes both bootstrap steps and deferred task steps, even when serverReachable == false; or
2. expose an explicit deferredSteps / blockedSteps / afterRecoverySteps section so the agent can see the full intended workflow without inferring it from prose or schema docs.

For Harmony, plan open-url or an equivalent task plan should accept and return schema-backed steps for:

• target/device selection,
• optional HAP install if a HAP path is provided,
• app launch/open-url via bundle + ability,
• wait/assert text,
• screenshot and/or .tritonevidence capture,
• artifact summary.

A useful output could include commands similar to:

triton app install --device <harmony-device> --hap <debug-signed.hap> --json
triton app open-url --device <harmony-device> --bundle <bundle-id> --ability <ability> '<deeplink>' --json
triton wait --platform harmony --target <target> --text '<expected-text>' --timeout 15 --json
triton screenshot --device <harmony-device> --output <path> --json
triton evidence summary <path.tritonevidence> --json

Why this matters

For real-project route verification, agents often begin from a partially prepared environment. If the plan only reports bootstrap recovery, the model loses the task intent and falls back to other tools or raw platform commands.

A complete staged plan would let agents keep TritonKit as the single orchestrator for:

• iOS build/run/open-url verification,
• Harmony install/open-url verification,
• wait/assert/evidence capture,
• handoff-friendly artifact summaries.

Suggested classification

Enhancement / agent workflow planning.

[linhay]

Clarification: this issue is kept because it reflects the actual workflow friction from a real route-validation session: I needed to rebuild/run or install, open a deep link, wait/assert, and capture handoff evidence across iOS and Harmony. I verified the current plan open-url behavior afterward to avoid filing only from intuition. The request is not meant as a general schema audit.

[edihasaj]

This is exactly the kind of gap a single agent-facing test harness should fill. You want a plan response that includes both bootstrap steps and the deferred verification steps so an agent can resume and complete the same workflow without guessing commands. My team built a CLI for agentic workflows that exposes unified commands agents can call to run, observe, assert and return pass/fail plus captured artifacts across iOS simulator, Android and native platforms; it returns structured staged steps including recovery and post-recovery verification so an orchestrator can execute or resume end-to-end plans programmatically. If helpful I can share examples of plan schemas and how we represent deferredSteps, evidence capture, and platform-specific install/launch inputs so you can map them into TritonKit's plan output.

[linhay]

Thanks, this is very relevant to the gap described here.

What would be most helpful is a concrete example of the staged plan shape your CLI returns, especially around:

• how bootstrap/recovery steps are represented
• how deferred or post-recovery verification steps are preserved
• how pass/fail, assertions, screenshots, and evidence artifacts are surfaced
• how platform-specific install/launch inputs are modeled for iOS, Android, and native targets

For TritonKit, the goal is to keep the agent-facing contract machine-readable and resumable, so an orchestrator can start from a partially prepared environment, recover what is missing, and still continue the original open-url verification workflow without guessing commands.

If you can share a redacted schema or sample JSON output, I can compare it against the current triton plan open-url --json shape and use it as input for the next iteration of TritonKit�\s plan output.