Skip to content

Preserve full mission output in the web UI - #29

Draft
hanshenmesen wants to merge 2 commits into
lbx154:mainfrom
hanshenmesen:codex/fix-mission-full-output
Draft

Preserve full mission output in the web UI#29
hanshenmesen wants to merge 2 commits into
lbx154:mainfrom
hanshenmesen:codex/fix-mission-full-output

Conversation

@hanshenmesen

Copy link
Copy Markdown

What changed

  • keep the existing compact mission summary for status surfaces
  • persist the complete operator-facing Engineer handoff as final_output
  • project full output through both Python and TypeScript mission views
  • recover complete output for older missions from their persisted Engineer message
  • render mission summaries as Markdown and add a localized View full output disclosure in Mission Control
  • regenerate the release bundles and manifest

Why

Mission completion currently flattens the Engineer handoff and slices it to 1,200 characters. Mission Control labels that value as the completed result, so long-form reports appear to end mid-sentence even though the original engineer.progress event still contains the full text. Role work is also capped, leaving no reliable full-deliverable path from the mission view.

User impact

Long reports remain compact at first glance, but users can expand and read the complete result in the same mission view. Existing missions in the recent event window also recover their full output without being rerun.

Validation

  • ./.venv/bin/pytest -q tests/life/test_mission_outcome.py tests/core/test_mission_view.py
  • ./.venv/bin/ruff check on all changed Python sources and tests
  • npm test in frontend/web — 176 tests passed
  • npm run typecheck in frontend/web
  • python3 -m argus_skill.release_tools.generate_event_types --check
  • python -m argus_skill.release_tools.build_release
  • manually verified the affected project: the previously clipped Chinese RSI report now exposes 查看完整输出 and includes the final methodology, expected-contributions, and delivery-check sections

@lbx154
lbx154 requested a review from Chenxxxxxx06 August 14, 2026 12:57
Prefer the final in-mission Engineer delivery over a longer superseded
message, and do not recover across a missing mission-start boundary.

Co-Authored-By: GPT-5.6-Sol <noreply@anthropic.com>
@Chenxxxxxx06

Copy link
Copy Markdown
Collaborator

I pushed a small maintainer follow-up in d5dd69f for the author to consider.

The historical fallback previously selected the longest Engineer message, which could surface a superseded draft, and it scanned from the start of the event window when the matching mission-start boundary was absent. The follow-up now:

  • keeps the latest visible Engineer handoff in the live reducers;
  • prefers the last final_delivery message during historical recovery;
  • declines recovery when the matching mission-start boundary is unavailable;
  • covers a longer obsolete draft followed by a shorter final delivery, plus the missing-boundary case.

Validation:

  • targeted Python regression tests: 2 passed
  • targeted Web tests: 46 passed
  • Web TypeScript check: passed
  • Ruff on the changed Python files: passed

I intentionally did not rebase or regenerate the stale release artifacts in this follow-up. Please review the semantic adjustment; the branch still needs to be rebased onto current main and rebuilt before merge.

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.

2 participants