Reorder ATVM status output and standardize push reminders

atvm/docs/automation/guide.md

@@ -213,11 +213,12 @@ When asked for one VM or a VM set:
 ## Status Reporting Format
 When the operator asks for the status of an ATVM automation run, report in this order:
 1. Heading/title using the run `build_name`.
-2. `COVERAGE:` section describing what the run was intended to cover, excluding the target-host list.
+2. `SUMMARY:` section with finished, passed, failed, and skipped counts.
-3. `TEST FLOW:` section describing the template-specific numbered run flow for the test.
+3. `HOSTS:` section with the machine rows.
-4. Completed machines with machine name first and status second for each machine.
+4. `TIMING:` section with start, end, total, quickest, longest, and average.
-5. Notes.
+5. `COVERAGE:` section describing what the run was intended to cover, excluding the target-host list.
-6. Skipped machines with reason.
+6. `TEST FLOW:` section describing the template-specific numbered run flow for the test.
+7. `NOTES:` section for broader context and anomalies.
 7. Remaining machines still to run.
 8. Summary counts for finished, passed, failed, and skipped machines.
 9. Timing details:
@@ -233,6 +234,7 @@ Status-report expectations:
 - Use the same display layout for every ATVM automation status response regardless of test type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
 - Use `/home/aw/code/cds/atvm/docs/automation/status-template.md` as the default template for both local status output and Mattermost status posts.
 - The default ATVM status template uses flat bullet-list sections for `COVERAGE:` and `TEST FLOW:`, Markdown tables for `SUMMARY:`, `HOSTS:`, and `TIMING:`, and uses `NOTES:` for flat operator-facing notes.
+- Order the status sections as `SUMMARY:`, `HOSTS:`, `TIMING:`, `COVERAGE:`, `TEST FLOW:`, then `NOTES:`.
 - The `HOSTS:` table includes `Host`, `Kernel`, `Status`, and `Detail` columns in that order.
 - In `COVERAGE:`, describe the template, datastore/config family, migration style, and plugin/integration path, but do not list target hosts there.
 - In `TEST FLOW:`, show the template-specific numbered run flow once for the whole test, not per host.

atvm/docs/automation/run-learnings.md

@@ -252,3 +252,9 @@ This file stores run-specific examples only when a run produced a new learning r
 - Action for future runs:
   - For non-categorized runs, post only the parent run status and do not also post the single synthetic subrun.
   - Keep the static `cmc-e2e` watcher flow aligned with the current 22-step ATVM E2E sequence.
+
+## Run Learning: 2026-03-27 (Use summary-first status layout for ATVM run results)
+- Observed requirement:
+  - The operator wants ATVM run results ordered as `SUMMARY:`, `HOSTS:`, `TIMING:`, `COVERAGE:`, `TEST FLOW:`, then `NOTES:`.
+- Action for future runs:
+  - Render ATVM status output in that section order for both local output and Mattermost posts.

atvm/docs/automation/status-template.md

@@ -10,16 +10,6 @@ Use this as the default ATVM automation run-status template for:
 ## ATVM Run Status
 ### <build_name>
 
-**COVERAGE:**
-- template: `<template-name>`
-- datastore/config family: `<config family>`
-- migration style: `<high-level test style>`
-- integration/plugin path: `<integration/plugin>`
-- scope of this run: `<batch or run scope>`
-
-**TEST FLOW:**
-- <template-specific numbered steps>
-
 **SUMMARY:**
 
 | Metric | Value |
@@ -49,13 +39,23 @@ Use this as the default ATVM automation run-status template for:
 | longest | <host> - <runtime> or n/a |
 | average | <runtime> or n/a |
 
+**COVERAGE:**
+- template: `<template-name>`
+- datastore/config family: `<config family>`
+- migration style: `<high-level test style>`
+- integration/plugin path: `<integration/plugin>`
+- scope of this run: `<batch or run scope>`
+
+**TEST FLOW:**
+- <template-specific numbered steps>
+
 **NOTES:**
 - <note>
 - <note>
 ```
 
 ## Rules
-- Keep `COVERAGE:`, `TEST FLOW:`, `SUMMARY:`, `HOSTS:`, `TIMING:`, and `NOTES:` in that order.
+- Keep `SUMMARY:`, `HOSTS:`, `TIMING:`, `COVERAGE:`, `TEST FLOW:`, and `NOTES:` in that order.
 - Use the title format:
   - `## ATVM Run Status`
   - `### <build_name>`

atvm/watcher-service/atvm_run_watcher.py

@@ -623,16 +623,6 @@ def build_status_markdown(
         "## ATVM Run Status",
         f"### {build_name}",
         "",
-        "**COVERAGE:**",
-        f"- template: `{metadata['template']}`",
-        f"- datastore/config family: `{metadata['config_family']}`",
-        f"- migration style: {metadata['migration_style']}",
-        f"- integration/plugin path: `{metadata['integration_plugin']}`",
-        f"- scope of this run: {metadata['scope_description']}",
-        "",
-        "**TEST FLOW:**",
-        *test_flow_lines,
-        "",
         "**SUMMARY:**",
         "",
         "| Metric | Value |",
@@ -657,6 +647,16 @@ def build_status_markdown(
         f"| longest | {f'{longest.host} - {format_duration(longest.duration_seconds)}' if longest else 'n/a'} |",
         f"| average | {format_duration(average) if average is not None else 'n/a'} |",
         "",
+        "**COVERAGE:**",
+        f"- template: `{metadata['template']}`",
+        f"- datastore/config family: `{metadata['config_family']}`",
+        f"- migration style: {metadata['migration_style']}",
+        f"- integration/plugin path: `{metadata['integration_plugin']}`",
+        f"- scope of this run: {metadata['scope_description']}",
+        "",
+        "**TEST FLOW:**",
+        *test_flow_lines,
+        "",
         "**NOTES:**",
         notes_block,
     ]

git-guide.md

@@ -37,7 +37,8 @@ This file records repo-specific git workflow preferences for `/home/aw/code/cds`
 - If `git commit` did not actually create a commit, report that clearly and leave the changes as uncommitted.
 
 ## Push Requests
-- When the user asks to push, use `git push -u origin main` by default unless the user explicitly asks for a different remote or branch.
+- When the user asks to push, show `git push origin main` by default unless the user explicitly asks for a different remote or branch.
+- When reminding the user about the push command after a commit proposal or completed commit, display `git push origin main` instead of `git push`.
 - Do not execute `git push -u origin main` or any other git push command from the assistant when credentials or an SSH key passphrase might be required.
 - Instead, show the exact push command and tell the user to run it directly in the terminal.
 - Do not accept passwords or passphrases through chat for git operations.