Reusable scenarios are additive workspace data, stored/versioned/synchronized through the existing owned CAS workspace service. Old documents retain collection execution without scenarios. A scenario selects a root collection and references original requests in its subtree. Its ordered steps have stable IDs, labels, group names and enable flags; repeated references are allowed. This preserves the latest saved interface definitions instead of copying credentials or request definitions into scenario snapshots.
The testing page offers scenario creation/edit/deletion, canonical request selection, labels/groups, enable flags, accessible up/down controls and scenario selection next to the existing collection/data runner. Frequent step editing/reordering has no added animation. English and Chinese catalogs cover new controls. Changes save explicitly through workspace CAS; failed saves retain edits. Editors are keyed to account/workspace/root boundaries.
Runs use the active selected environment, optional saved/temporary datasets and iteration settings. Existing execution scopes, response extractions, pre/post scripts, inherited authentication, per-collection overlays, owner gates, capacity, cancellation and reports are reused. Disabled steps do not execute. Each report item carries step ID and privacy-screened label/group. Script request-ID/name jumps require a unique enabled occurrence, so repeated references do not silently jump to the first. An empty enabled plan or a root mismatch fails before execution. The canonical workspace is unchanged by execution.
Limits are100 scenarios and1000 saved steps per workspace, with existing1000 execution,100 iteration,300-second and8MiB report bounds. Missing request/root references and duplicate scenario/step IDs reject workspace saves. Deleting a referenced interface/root requires updating or deleting its scenarios first; broken definitions are not silently accepted. Default native backups screen metadata copies of known private values; explicit backups retain exact scenario definitions. A remote server discarding scenarios cannot acknowledge successful sync.
Three real server fixtures cover reordered/repeated/disabled requests, extraction transfer, unchanged workspace/private history, ambiguous repeated jump targets, missing references, hosted owner isolation, wrong root, duplicate step IDs and no enabled plan. A remote old-server fixture proves synchronization refuses lost scenario definitions. Formats proves privacy screening, importability and exact explicit backup. Editor and runner-selection tests prove repeated/reordered references, groups, nested-root filtering, CAS calls and scenario options. Existing script-flow regressions, bilingual catalogs, TypeScript and production frontend build passed. Native OS/package/database-matrix and rendered visual verification remain for the final unified phase.
Saved sequential scenarios now also support conditions, explicit true/false step targets and bounded repeats/backwards loops; see scenario control semantics and evidence. Parallel request batches are also available; see parallel scope and evidence. Nested group controls, multi-step parallel branch graphs, visual graph orchestration, scheduled/durable execution, persisted reports and other full-product requirements remain unfinished; this is not a full Apifox/Postman parity claim or a release.
Owned durable report summaries/diagnostics and JSON/CSV/JUnit/bilingual HTML exports are now available; see saved report scope and evidence. Detailed response linking, richer report comparison/sharing and scheduling remain unfinished.