Skip to content

feat(landing): Apollo 11 action scene on the ExecuteAction trace - #1782

Merged
HuiJun merged 12 commits into
developfrom
feat/landing-action-scene
Oct 31, 2026
Merged

HuiJun merged 12 commits into
developfrom
feat/landing-action-scene

Conversation

@devin-ai-integration

@devin-ai-integration devin-ai-integration Bot commented Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

What and why

The homepage hero gains an Apollo 11 mission tab: MissionSequence::LunarMission (from examples/runtime-showcase/mission-sequence.sysml) drawn as an action diagram, whose Run performs the action on apollo11 through the in-browser engine with ExecuteAction's new trace: true and replays the records the engine wrote. Nothing on the page is computed by the page: the token moves to the node each step record names, each remaining appears under the burn whose assign record reported it, the decide record says which branch the engine took, and the run ends on the wait record at awaitGo with the engine's own deadlock message naming GoForDescent.

Toggles under the stage (as the mass scene's):

  • Send GoForDescent — the same run with events: ["GoForDescent"]: the engine posts it to the waiting accept and the trace goes on through descent, surfaceOperations, ascent, transEarthInjection, splashdown to done; the status line prints the outputs the engine returned (landed = true, returned = true, remaining = 480 'm/s').
  • Fly Apollo 8 — performer MissionSequence::apollo8: its 5500 m/s budget fails the guard and the decide takes 2->transEarthInjection.
  • Remove the start — view and action LunarMissionUnordered: the engine does not refuse an action with no first step today; it starts a token on each of the three actions, records the order it took them as a choice, and completes. The scene shows exactly that; the status line reads the engine's records.

Code

  • scene.ts: a SceneAction program (symbol, performer, events) and LUNAR_MISSION_SCENE (id: "apollo") with the three variants; present.ts: presentedMission.
  • model.ts: LandingAction/LandingActionNode — an action view is kept as its nodes keyed by the name the trace records carry, beside the part-shaped and machine-shaped models (actionModel, stateIdOf resolves action nodes too); TraceRecord carries token, step, feature, value; runAction calls executeAction with the performer, events and trace and keeps the printed outputs or the failed run's partial trace; debugSteps follows step/wait/decide/assign records and accumulates the Assignments so far (an accept followed by a step counts as fired).
  • main.ts: runActed replays the trace through the existing showStep, so the Debug panel steps through an action run exactly as it steps through a state run; syncValues writes each assigned value under its node (text.osml-value); action nodes get the osml-step class the live styling lights.
  • overrides/home.html: the tab, caption, debug hint, edit hint and the two style rules.
  • tests/wasm/landing_mission_test.go pins mission.json (the first paint) and the four traced runs: the node kinds and successions RenderView draws, the wait at awaitGo, the assignments and completion with GoForDescent, Apollo 8's branch, and what the engine does with LunarMissionUnordered.

The Debug panel is reused as is: its record list, step/play and "now" line work on the action's records (the decide shows as chose 1->awaitGo). Its send buttons stay journey-only — the action's events are the scene's toggles, posted by the engine as the run waits, not sent from the panel.

Landing order. This PR is built on #1778 (feat/execute-action-trace-events), which it needs for ExecuteAction's trace/events in the wasm engine; #1778 carries develop (with #1777, now landed) merged in as merge commits, no rebase. Order: #1778 → this PR. Until #1778 lands, this branch's diff includes it; after, it is the hero change alone. The branch dry-merges onto current develop without conflicts.

How it was verified

On the head with #1778's current head (and so develop) merged in:

  • cd editors/vscode && npm run build && npm run typecheck && npm test — 454 pass, 0 fail; npm run build:landing builds the bundle.
  • go build ./... && go vet ./... && gofmt -l . — clean; go test -count=1 ./tests/wasm — ok (TestLandingLunarMissionModel pins mission.json and the four runs the scene offers).
  • cd client/node && npm run build && npm test — 473 pass on the same engine code (run on feat(grpc): trace and events for ExecuteAction #1778's merged head; this PR adds no client change).
  • Browser-verified on the built MkDocs site (make docs-engine-assets, mkdocs build, served statically) against the real wasm module, cache disabled, no console errors beyond the theme's two api.github.com 403s. The status line and the values under the nodes below are read from the page, not typed in:
    • Run on Apollo 11: 9 records, stops on wait GoForDescent at awaitGo — status "ExecuteAction performed LunarMission on apollo11 in 15 ms and stopped after 9 trace records: action execution failed: execute action: accept deadlock in action LunarMission: nothing can post the awaited message (accept go waiting since step 5 for a message of type GoForDescent)"; values under the nodes remaining = 6350 'm/s', remaining = 5450 'm/s'.
    • Send GoForDescent: 23 records over 1 token, completes with landed = true, remaining = 480 'm/s', returned = true; values 6350, 5450, 3350, landed = true, 1480, 480, returned = true under their burns.
    • Fly Apollo 8: 13 records, decide takes 2->transEarthInjection, completes with landed = false, remaining = 450 'm/s'.
    • Remove the start: 14 records over 3 tokens; the status ends on the engine's own record, "choice step 1: tokens 1@outbound, 2@lunarOps, 3@returnJourney (unordered; took 3@returnJourney first; independent)".
    • Debug the run: the panel lists the action's records (step, assign, decide, wait) and stepping through them moves the token and lands each value; the failed run's error is the last row, as for a state run.

First paint (snapshot) and the Apollo 11 run stopped at awaitGo:

Apollo 11 scene, first paint
Apollo 11 run waiting at awaitGo

With GoForDescent sent, and Apollo 8:

Apollo 11 with GoForDescent sent
Apollo 8 takes the trans-Earth branch

LunarMissionUnordered, and the Debug panel on the Apollo 11 run:

LunarMissionUnordered as the engine performs it
Debug panel stepping through the action's records

Known cosmetic, not from this PR: RenderView draws awaitGo's three parameters as ports and their labels overlap under the box.

Checklist

  • make test and make lint pass locally
  • Tests added or updated for the change
  • Documentation extended where it already covers the surface (see CONTRIBUTING.md)
  • Changelog entry added as changes/unreleased/<slug>.<section>.md, not as an edit to CHANGELOG.md
  • baselines regenerated and make docs-counts run if a gate count moved (compliance rows need nothing: the census is counted at docs build)
  • No internal work-item labels (waves, slices, F4, K5) in the body, docs, or changelog

Link to Devin session: https://nasa-jpl-demo.devinenterprise.com/sessions/ea449771e507498985e128186c5ad7e5
Open in Devin Desktop: https://nasa-jpl-demo.devinenterprise.com/desktop/session/ea449771e507498985e128186c5ad7e5?variant=devin
Requested by: @HuiJun

The homepage hero gains an "Apollo 11 mission" scene drawing
MissionSequence::LunarMission as an action diagram. Run performs the
action on apollo11 through the wasm engine with trace: true and replays
the records the engine wrote: the token at each node a step reached,
each assigned value written under the node that assigned it, the branch
the decide took, and the wait at awaitGo for GoForDescent. Toggles post
GoForDescent to the waiting accept, fly apollo8, or perform
LunarMissionUnordered, showing whatever the engine answers.

model.ts keeps an action view as a LandingAction (its nodes by the name
the trace records carry) beside the part-shaped and machine-shaped
models; debugSteps follows step/wait/decide/assign records and
accumulates the assignments. The first paint is pinned by
tests/wasm/landing_mission_test.go, which also pins the four traced
runs the scene offers.

Co-Authored-By: jason.han <hanhuijun@gmail.com>
@devin-ai-integration

Copy link
Copy Markdown
Contributor Author

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

  • Disable automatic comment, CI, and merge conflict monitoring

devin-ai-integration Bot and others added 3 commits October 30, 2026 19:44
…fter a toggle is switched off

valueText prints an instance value as its id, so the action's outputs
read 'go = instance #3' rather than its kind; readSummary counts an
action's steps and successions; switching a variant off on an unchanged
root no longer leaves the status line on 'Reading … again'.

Co-Authored-By: jason.han <hanhuijun@gmail.com>
The status line after a run counts the tokens the records name and
says how the run ended: the completion record, or the last record the
engine wrote, so LunarMissionUnordered shows the engine's own account
of its three unordered tokens.

Co-Authored-By: jason.han <hanhuijun@gmail.com>
@devin-ai-integration
devin-ai-integration Bot marked this pull request as ready for review October 30, 2026 20:00
devin-ai-integration[bot]

This comment was marked as resolved.

devin-ai-integration Bot and others added 7 commits October 30, 2026 20:23
The value badges of the previous run stayed on a replacement diagram; adopting a model or
forgetting a run now clears them. The mission test reads the held value of each assignment.

Co-Authored-By: jason.han <hanhuijun@gmail.com>
@HuiJun
HuiJun merged commit f0f51f8 into develop Oct 31, 2026
65 of 151 checks passed
@HuiJun
HuiJun deleted the feat/landing-action-scene branch October 31, 2026 13:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant