ccqa 1.15.0 → 1.16.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 +14 -5
- package/dist/bin/ccqa.mjs +2464 -1955
- package/dist/hub-client/index.d.mts +95 -10
- package/dist/hub-client/index.mjs +20 -0
- package/dist/package.json +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -101,7 +101,7 @@ So ccqa asks the cheap question before the expensive one:
|
|
|
101
101
|
still describes it ───┴─── no longer describes it
|
|
102
102
|
│ │
|
|
103
103
|
▼ ▼
|
|
104
|
-
run it
|
|
104
|
+
run it a person repairs it
|
|
105
105
|
│
|
|
106
106
|
re-audited next round;
|
|
107
107
|
unverified until then
|
|
@@ -114,8 +114,16 @@ re-recorded; a stale spec goes to a human and stays **unverified** —
|
|
|
114
114
|
neither passing nor failing — until repaired.
|
|
115
115
|
|
|
116
116
|
`ccqa run --only-hub-rerun-needed` asks the hub which specs are worth
|
|
117
|
-
running: cleared by the audit *and* invalidated by a deploy. A drifted
|
|
118
|
-
|
|
117
|
+
running: cleared by the audit *and* invalidated by a deploy. A drifted spec —
|
|
118
|
+
or one whose last run failed — answers `needsRepair` and is never run. A run
|
|
119
|
+
repairs neither, and it costs dollars to learn that.
|
|
120
|
+
|
|
121
|
+
Selecting nothing is only an answer when every spec was answered. If any spec
|
|
122
|
+
is waiting on the audit, or the hub could not judge it, the run **exits
|
|
123
|
+
non-zero** rather than report a green run that verified nothing. And while a
|
|
124
|
+
run executes it claims its specs, so a cycle that starts before the last one
|
|
125
|
+
finishes skips what is already running instead of driving the same flow
|
|
126
|
+
twice.
|
|
119
127
|
|
|
120
128
|
When a clean spec still fails, `--on-fail-explain` labels whose problem
|
|
121
129
|
it is: `TEST_DRIFT`, `SPEC_CHANGE`, `PRODUCT_BUG`, or `UNKNOWN`. You
|
|
@@ -126,14 +134,15 @@ grade the calls on the hub, and it learns from your grades.
|
|
|
126
134
|
```
|
|
127
135
|
deploy lands
|
|
128
136
|
├─ ccqa hub deploy record --select what shipped, which specs it reaches
|
|
129
|
-
├─ ccqa audit --report-to-hub
|
|
137
|
+
├─ ccqa audit --only-hub-audit-needed --report-to-hub
|
|
138
|
+
│ does each spec still describe it?
|
|
130
139
|
└─ ccqa run --only-hub-rerun-needed --on-fail-explain \
|
|
131
140
|
--hub-profile ci --report-to-hub
|
|
132
141
|
```
|
|
133
142
|
|
|
134
143
|
The audit costs cents; a live spec costs dollars. Filtering first leaves
|
|
135
144
|
a run whose failures are worth reading. Record every deploy with
|
|
136
|
-
`--select` — a range recorded without it answers `
|
|
145
|
+
`--select` — a range recorded without it answers `unanswerable` forever, and
|
|
137
146
|
nothing fills the hole later.
|
|
138
147
|
|
|
139
148
|
| Job | Trigger | Question it answers |
|