@@ -2893,6 +2893,99 @@ async fn step_manifests_survive_a_restart() {
     );
 }
 
+/// Every surface showing a whole step list uses execution order.
+///
+/// The stored manifest is seeded with declared steps and then appends
+/// synthetic ones as the runner reports them, so its raw order puts
+/// `Set up job` last despite it running first. A step id is a v4 UUID, so it
+/// cannot supply the order either.
+#[tokio::test]
+async fn step_lists_and_job_logs_follow_execution_order() {
+    let temp = tempfile::tempdir().unwrap();
+    let state = AppState::new(temp.path().to_path_buf()).await.unwrap();
+    let app = app(state.clone(), CancellationToken::new());
+    let (run_id, jobs) = three_step_run_for_log_filters(&app, &state).await;
+    let ids = workflow_step_ids(&state, run_id, "build").await;
+    let (plan_id, agent_job_id) = (jobs[0].1.clone(), jobs[0].2.clone());
+
+    // The runner reports `Set up job` first, then the declared steps at the
+    // offset positions the golden capture shows (declared step 1 is number 2).
+    let setup_id = uuid::Uuid::new_v4().to_string();
+    let report = |external_id: &str, number: u64, name: &str| {
+        serde_json::json!({
+            "external_id": external_id,
+            "number": number,
+            "name": name,
+            "status": 6,
+            "conclusion": 2
+        })
+    };
+    let response = request_json(
+        &app,
+        Method::POST,
+        "/twirp/github.actions.results.api.v1.WorkflowStepUpdateService/WorkflowStepsUpdate",
+        json!({
+            "workflow_run_backend_id": plan_id,
+            "workflow_job_run_backend_id": agent_job_id,
+            "steps": [
+                report(&setup_id, 1, "Set up job"),
+                report(&ids[0], 2, "Run echo one"),
+                report(&ids[1], 3, "Run echo two"),
+                report(&ids[2], 4, "Run echo three"),
+            ]
+        }),
+    )
+    .await;
+    assert_eq!(response["ok"], true);
+
+    // The run record lists the synthetic setup step first.
+    let run = get_run_json(&app, &run_id.to_string()).await;
+    let names: Vec<&str> = run["jobs_list"][0]["steps"]
+        .as_array()
+        .unwrap()
+        .iter()
+        .map(|step| step["name"].as_str().unwrap_or_default())
+        .collect();
+    assert_eq!(
+        names,
+        vec![
+            "Set up job",
+            "Run echo one",
+            "Run echo two",
+            "Run echo three"
+        ],
+        "the run record must show execution order, not seeded-then-appended"
+    );
+
+    // The whole-job log concatenates in the same order, even though the ids
+    // sort differently.
+    write_step_job_logs(
+        &temp,
+        &plan_id,
+        &agent_job_id,
+        &[
+            (ids[2].as_str(), "three\n"),
+            (ids[0].as_str(), "one\n"),
+            (setup_id.as_str(), "setup\n"),
+            (ids[1].as_str(), "two\n"),
+        ],
+    )
+    .await;
+    let (status, body) = get_logs(&app, format!("/api/v1/runs/{run_id}/logs?job=build")).await;
+    assert_eq!(status, StatusCode::OK);
+    assert_eq!(
+        String::from_utf8_lossy(&body),
+        "setup\none\ntwo\nthree\n",
+        "whole-job output must follow execution order"
+    );
+
+    // `--step` still counts declared steps only, so setup takes no slot.
+    let (status, body) =
+        get_logs(&app, format!("/api/v1/runs/{run_id}/logs?job=build&step=1")).await;
+    assert_eq!(status, StatusCode::OK);
+    assert_eq!(body, b"one\n");
+}
+
 /// A completion reconciles the attempt that actually reported.
 ///
 /// `job_requests` is keyed by monotonic request id, so picking the first match
 
@@ -143,6 +143,36 @@ impl StepRecord {
             .collect()
     }
 
+    /// Sort key placing a step in execution order.
+    ///
+    /// `runner_number` is the runner's own 1-based timeline position and counts
+    /// every step it ran, so it is the truth once reported. Until then a
+    /// declared step falls back to its manifest position, biased past any
+    /// reported number so freshly seeded steps trail what has actually run.
+    /// A step id is a v4 UUID and sorts randomly, so it is only the final
+    /// tie-break for determinism.
+    fn execution_key(&self) -> (u32, usize, &str) {
+        match self.runner_number {
+            Some(number) => (number, 0, self.id.as_str()),
+            None => (
+                u32::MAX,
+                self.workflow_index.unwrap_or(usize::MAX),
+                self.id.as_str(),
+            ),
+        }
+    }
+
+    /// Order records as the job executed them.
+    ///
+    /// The in-memory manifest is seeded with declared steps and then appends
+    /// synthetic ones as the runner reports them, so its raw order puts
+    /// `Set up job` after the workflow steps despite it running first. A
+    /// restore adds a third order again. Every surface that shows a whole
+    /// step list goes through this instead.
+    pub(crate) fn sort_execution_order(steps: &mut [Self]) {
+        steps.sort_by(|left, right| left.execution_key().cmp(&right.execution_key()));
+    }
+
     /// Locate a step by stable identity, and by nothing else.
     ///
     /// Display names repeat legitimately — two steps may both be named `Test`
 
@@ -2104,7 +2104,10 @@ pub(crate) fn latest_attempt_steps(
         .filter(|request| request.run_id == run_id && request.job_id == *job_id)
         .max_by_key(|request| request.request_id)
         .map(|request| request.agent_job_id)?;
-    inner.job_steps.get(&agent_job_id).cloned()
+    let mut steps = inner.job_steps.get(&agent_job_id).cloned()?;
+    // The stored vector is seeded-then-appended, so it is not execution order.
+    StepRecord::sort_execution_order(&mut steps);
+    Some(steps)
 }
 
 pub(crate) async fn get_run(
@@ -2353,6 +2356,9 @@ async fn resolve_job_logs(
     results_dir: &std::path::Path,
     fallback_blocks: Vec<Vec<u8>>,
     workflow_step_ids: Option<&[String]>,
+    // Every id the attempt's manifest knows, in execution order, used only to
+    // order the whole-job concatenation.
+    execution_step_ids: Option<&[String]>,
     prefer_steps: bool,
 ) -> Result<JobLogs, ApiError> {
     let merged = match tokio::fs::read(results_dir.join("job-logs.txt")).await {
@@ -2409,9 +2415,19 @@ async fn resolve_job_logs(
             )));
         }
     }
-    // Only for the unfiltered read, where this is a concatenation order and
-    // not a step selector. `--step` goes through `workflow` below.
-    step_files.sort_by(|left, right| left.0.cmp(&right.0));
+    // Concatenation order comes from the manifest, which knows what ran when.
+    // A step id is a v4 UUID, so sorting by it emitted the whole-job log in
+    // random order; blobs the manifest does not know keep a stable tail.
+    let position = |id: &str| {
+        execution_step_ids
+            .and_then(|ids| ids.iter().position(|known| known == id))
+            .unwrap_or(usize::MAX)
+    };
+    step_files.sort_by(|left, right| {
+        position(&left.0)
+            .cmp(&position(&right.0))
+            .then_with(|| left.0.cmp(&right.0))
+    });
 
     if !step_files.is_empty() {
         let workflow = workflow_step_ids.filter(|ids| !ids.is_empty()).map(|ids| {
@@ -2590,21 +2606,31 @@ pub(crate) async fn get_run_logs(
                     }
                 });
                 // The attempt's own manifest, keyed by the agent job id that
-                // also names this request's results directory. Declared steps
-                // only: a synthetic "Set up job" record must not occupy a
-                // `--step` slot. The broker message is deliberately not
-                // consulted — it is broker delivery state that a restart or a
-                // retirement can drop, while the manifest is run state.
-                let workflow_step_ids = inner
-                    .job_steps
-                    .get(&request.agent_job_id)
+                // also names this request's results directory. The broker
+                // message is deliberately not consulted — it is broker
+                // delivery state that a restart or a retirement can drop,
+                // while the manifest is run state.
+                //
+                // Two views: declared steps in workflow order decide `--step`,
+                // because a synthetic "Set up job" record must not occupy a
+                // slot; every id in execution order decides the whole-job
+                // concatenation, where synthetic output belongs in place.
+                let manifest = inner.job_steps.get(&request.agent_job_id);
+                let workflow_step_ids = manifest
                     .map(|records| {
                         StepRecord::workflow_steps(records)
                             .into_iter()
                             .map(|step| step.id.clone())
                             .collect::<Vec<_>>()
                     })
                     .filter(|ids| !ids.is_empty());
+                let execution_step_ids = manifest
+                    .map(|records| {
+                        let mut ordered = records.clone();
+                        StepRecord::sort_execution_order(&mut ordered);
+                        ordered.into_iter().map(|step| step.id).collect::<Vec<_>>()
+                    })
+                    .filter(|ids| !ids.is_empty());
                 (
                     request.plan_id.clone(),
                     request.agent_job_id.to_string(),
@@ -2614,14 +2640,23 @@ pub(crate) async fn get_run_logs(
                         .map(|(_, block)| block.to_vec())
                         .collect::<Vec<_>>(),
                     workflow_step_ids,
+                    execution_step_ids,
                 )
             })
             .collect::<Vec<_>>();
         (shared.state.state_dir.clone(), sources)
     };
 
     let mut merged = Vec::new();
-    for (plan_id, agent_job_id, job_label, fallback_blocks, workflow_step_ids) in sources {
+    for (
+        plan_id,
+        agent_job_id,
+        job_label,
+        fallback_blocks,
+        workflow_step_ids,
+        execution_step_ids,
+    ) in sources
+    {
         let results_dir = state_dir
             .join("replay")
             .join("results")
@@ -2631,6 +2666,7 @@ pub(crate) async fn get_run_logs(
             &results_dir,
             fallback_blocks,
             workflow_step_ids.as_deref(),
+            execution_step_ids.as_deref(),
             query.step.is_some(),
         )
         .await?;
 
@@ -1417,7 +1417,8 @@ impl SqliteStore {
             "SELECT agent_job_id, step_id, kind, workflow_index, runner_number,
                     context_name, name_blob, conclusion, started_at_us, finished_at_us
              FROM job_steps
-             ORDER BY agent_job_id, kind, workflow_index, step_id",
+             ORDER BY agent_job_id, COALESCE(runner_number, 2147483647),
+                      COALESCE(workflow_index, 2147483647), step_id",
         )?;
         for row in step_stmt.query_map([], |row| {
             Ok((
 
@@ -624,7 +624,8 @@ impl Store for PgStore {
                 "SELECT agent_job_id, step_id, kind, workflow_index, runner_number,
                         context_name, name_blob, conclusion, started_at_us, finished_at_us
                  FROM job_steps
-                 ORDER BY agent_job_id, kind, workflow_index, step_id",
+                 ORDER BY agent_job_id, COALESCE(runner_number, 2147483647),
+                          COALESCE(workflow_index, 2147483647), step_id",
                 &[],
             )
             .await?;