@getmagical/cli 0.12.2 → 0.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +122 -0
- package/dist/index.js +2165 -1577
- package/dist/index.js.map +4 -4
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -80,6 +80,128 @@ The count applies only when creating a regression test. Repeating the command
|
|
|
80
80
|
for the same automation and agent version pair returns the existing test;
|
|
81
81
|
changing the count does not expand or rerun it.
|
|
82
82
|
|
|
83
|
+
### Current automation scenarios
|
|
84
|
+
|
|
85
|
+
Select distinct inputs and available recordings for the scenarios defined by an
|
|
86
|
+
immutable automation version:
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
mgcl pathway-regression coverage --automation-version-id <uuid> --org <org> --max-candidate-runs 1000 --runs-per-scenario 2 --max-recording-checks 100 --json
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
The supplied version determines the target scenarios. Compatible historical runs
|
|
93
|
+
from any version of the same automation can supply examples. Scenario identity
|
|
94
|
+
uses durable agent pathway keys and required nested calls. Required agents must
|
|
95
|
+
be present; reordered or redundant repeated historical calls do not create new
|
|
96
|
+
scenarios. API agents have one pathway per stable agent ID. Code and Extract
|
|
97
|
+
agents are opaque and pinned to their agent version. Separately queued automation
|
|
98
|
+
runs remain separate candidates.
|
|
99
|
+
|
|
100
|
+
Discovery uses existing definitions, structured input conditions, and historical
|
|
101
|
+
input witnesses. Feasible scenarios remain visible even without historical
|
|
102
|
+
examples. Missing definitions, unresolved conditions or calls, recursion, and
|
|
103
|
+
expansion limits produce `targetDiagnostics` and incomplete discovery, rather
|
|
104
|
+
than a complete denominator. Expansion is limited to 1,000 scenarios and 10,000
|
|
105
|
+
feasibility evaluations, reported with actual evaluations in `targetDiscovery`.
|
|
106
|
+
This read-only command does not generate definitions,
|
|
107
|
+
backfill signatures, or start runs.
|
|
108
|
+
|
|
109
|
+
Only record-mode runs with status `COMPLETE` or `EARLY_TERMINATION` qualify,
|
|
110
|
+
including implicit and explicit recordings, with draft/test runs excluded.
|
|
111
|
+
`--max-candidate-runs` accepts 1–10,000 and defaults to **1,000**; the limit applies
|
|
112
|
+
before classification. Compatible signatures identify historical pathways without
|
|
113
|
+
requiring a deviation-free run. Each historical input must also satisfy the
|
|
114
|
+
current scenario's structured conditions; a retained pathway key alone does not
|
|
115
|
+
make an older input applicable after a condition changes. Missing or ambiguous
|
|
116
|
+
evidence appears in
|
|
117
|
+
`unclassifiedRuns`; incompatible historical routes appear in `excludedRuns`.
|
|
118
|
+
Coverage does not reconstruct missing links from raw memories.
|
|
119
|
+
|
|
120
|
+
`--runs-per-scenario` accepts 1–20 and defaults to **2** distinct inputs. The same
|
|
121
|
+
input is offered only once across the report. JSON object-key order does not
|
|
122
|
+
change input identity; array order and value types do. Store-backed identities
|
|
123
|
+
include immutable starting Store contents. Missing starting data is diagnostic.
|
|
124
|
+
When observations of one input disagree, the newest compatible observation wins,
|
|
125
|
+
with ascending run ID breaking ties; `inputConflicts` records the alternatives.
|
|
126
|
+
|
|
127
|
+
Repeated runs of one input are alternative recording sources. Selection prefers
|
|
128
|
+
newest verified recordings and falls back to older matching runs. Each recording
|
|
129
|
+
stays paired with its actual source input, work-item ID, and signature evidence.
|
|
130
|
+
`initialStore` preserves immutable starting Store values alongside each example.
|
|
131
|
+
Every JSON example in `selectedRuns` and `inputOnlyRuns` also includes
|
|
132
|
+
`draftRunPayload`, the launch data accepted by `runDraftAutomation`:
|
|
133
|
+
|
|
134
|
+
```json
|
|
135
|
+
{
|
|
136
|
+
"input": { "currency": "USD", "paymentMethod": "Cash" },
|
|
137
|
+
"initialStore": { "request": { "currency": "USD", "paymentMethod": "Cash" } }
|
|
138
|
+
}
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
The payload contains the source run's original `input` and immutable starting
|
|
142
|
+
`initialStore`, omitting either field when absent. To start a draft run on a clone,
|
|
143
|
+
combine it with the clone's `draftAutomationId`, trigger `agentId`, and a new
|
|
144
|
+
`idempotencyKey` (reuse that key when retrying the same launch). The API creates a
|
|
145
|
+
new work item when work items are enabled; the historical `workItemId` is only
|
|
146
|
+
provenance and must not be reused. With `mgcl automations run-draft`, pass the
|
|
147
|
+
present payload fields as `--input-json` and `--initial-store-json`.
|
|
148
|
+
If migration changes the Store schema, map these values to the clone's new paths
|
|
149
|
+
first: legacy `input` is not automatically converted into Store contents. The
|
|
150
|
+
payload never uses the source work item's mutable final state.
|
|
151
|
+
|
|
152
|
+
`inputOnlyRuns` preserves matching examples with no verified recording. These
|
|
153
|
+
examples have `recordingId: null` and do not increase recorded sample or coverage
|
|
154
|
+
counts. Each scenario reports `distinctInputCount` and a `gapReason`:
|
|
155
|
+
`no_matching_history`, `recordings_unavailable`, `inputs_assigned_elsewhere`, or
|
|
156
|
+
null when there is no confirmed gap. `inputs_assigned_elsewhere` means compatible
|
|
157
|
+
history exists, but its inputs belong to other scenarios under the newest-observation
|
|
158
|
+
rule; it is a distinct-input shortfall rather than a recording gap. Unchecked recordings and storage errors remain unknown. No compatible
|
|
159
|
+
history yields scenarios with gaps and no fabricated examples.
|
|
160
|
+
|
|
161
|
+
`--max-recording-checks` accepts 1–10,000 and defaults to **100**. Verification is
|
|
162
|
+
allocated fairly across scenarios, with concurrency 8. A 120-second analysis
|
|
163
|
+
deadline cancels pending database work. No recording archive is downloaded;
|
|
164
|
+
availability does not guarantee future retention or replay fidelity.
|
|
165
|
+
|
|
166
|
+
Human-readable output includes target pathway keys and labels, required nested
|
|
167
|
+
calls, opaque steps, distinct-input counts, `1/2 selected` recording counts, gaps,
|
|
168
|
+
and diagnostics. Input-only examples include their original inputs and work-item
|
|
169
|
+
IDs. JSON also includes recorded samples' original inputs and signature evidence.
|
|
170
|
+
Errors and warnings go to stderr; `--json` stdout remains valid JSON, including partial results.
|
|
171
|
+
A scenario is covered after its first verified recording, independently of the
|
|
172
|
+
requested sample count.
|
|
173
|
+
|
|
174
|
+
`coverageStatus` is `complete`, `gaps`, `incomplete`, or `no_scenarios`. Completed
|
|
175
|
+
analysis exits **0**, including genuine gaps and exhausted distinct-input
|
|
176
|
+
shortfalls. When target discovery and recording selection finish and every target
|
|
177
|
+
scenario has a verified recording, coverage is `complete` and exits **0** even if
|
|
178
|
+
some historical runs remain unclassified. These runs remain in `unclassifiedRuns`
|
|
179
|
+
and produce a warning on stderr. Their historical classification diagnostics stay
|
|
180
|
+
in `analysis.incompleteReasons`; they do not invalidate established coverage.
|
|
181
|
+
Incomplete target discovery, unfinished recording selection (including recording
|
|
182
|
+
errors, budget limits, and deadlines), or unclassified history with uncovered
|
|
183
|
+
target scenarios exits **1**, retaining partial results. `analysis.targetDiscoveryComplete`,
|
|
184
|
+
`analysis.historyClassificationComplete`, and `analysis.selectionComplete`
|
|
185
|
+
distinguish these stages. `analysis.discoveryComplete` aggregates target discovery
|
|
186
|
+
and historical classification. Scenario counts are a lower bound only when target
|
|
187
|
+
discovery is incomplete. `no_scenarios` requires complete target discovery with no
|
|
188
|
+
scenarios; an empty history alone does not imply this status. `search.truncated`
|
|
189
|
+
separately identifies older history outside the window and does not itself cause
|
|
190
|
+
failure. Interrupting cancels the GET request without starting background work.
|
|
191
|
+
|
|
192
|
+
Unsigned agent runs with known baseline disqualifications (human intervention or
|
|
193
|
+
self-heal, including loop recovery) exclude their automation run from examples.
|
|
194
|
+
`excludedRuns` reports `baseline_disqualified` with the reasons in `details`.
|
|
195
|
+
These exclusions do not make classification incomplete, hide current scenarios,
|
|
196
|
+
or refill the historical window with older runs. Missing signatures without a
|
|
197
|
+
known disqualification, and invalid signatures, still make historical
|
|
198
|
+
classification incomplete. They are nonblocking warnings when all target scenarios
|
|
199
|
+
have verified recordings and the remaining analysis has finished.
|
|
200
|
+
|
|
201
|
+
The command requires only `regressions:read`, `runs:read`, and `captures:read`.
|
|
202
|
+
Deploy backend changes before releasing CLI updates that depend on them. Existing
|
|
203
|
+
`mgcl regression run|show` commands are unchanged.
|
|
204
|
+
|
|
83
205
|
## Typed classification
|
|
84
206
|
|
|
85
207
|
Use `mgcl classify` for focused typed judgments over context you already have.
|