openclaw - 💡(How to fix) Fix Runtime parity needs standard and optional first-hour scenario tiers [1 comments, 2 participants]

Part of #80171 and follow-up to #80323.

The Phase 1-5 runtime parity harness now exists, but the current scenario selection does not yet distinguish standard vs optional tiers for Codex-vs-Pi runtime coverage.

Audit snapshot from #80323:

• The broader qa/scenarios catalog has 97 parsed markdown scenarios plus 3 curated JSONL transcripts.
• The release runtime-pair lane runs only --parity-pack agentic, which currently expands to 12 scenarios.
• The live token-efficiency lane runs only approval-turn-tool-followthrough on schedule.
• Scenario metadata supports lane, risk, and category, but current scenarios do not populate standard/optional tier labels.

Why this matters:

When Codex becomes the default runtime, maintainers need a clear "first hour of OpenClaw use" gate that is neither the full universe of QA scenarios nor a single narrow parity pack. The standard tier should cover common first-hour behaviors: first turn, follow-up turn, default tool use, auth-profile selection, plugin install/readiness, memory recall, subagent handoff, cron/heartbeat, gateway restart/recovery, config apply/restart, and basic channel/control-ui behavior. Optional tiers can then hold slower live, soak, media, and workspace-heavy scenarios.

Acceptance sketch:

• Add explicit scenario tier metadata such as runtimeParityTier: standard|optional|soak|live-only or equivalent lane tags.
• Add a CLI selector for the standard first-hour runtime parity suite.
• Wire the standard tier into release checks separately from optional/live-only tiers.
• Document which scenarios are required, optional, live-only, and soak-only.
• Keep mock-only token reports disabled; token efficiency remains live-only.