@3f-consulting/spec-controller-core 0.1.0-alpha.5 → 0.1.0-alpha.51
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 +6 -4
- package/dist/assemble/evidenceReconciliationFromSources.d.ts +5 -40
- package/dist/assemble/evidenceReconciliationFromSources.d.ts.map +1 -1
- package/dist/assemble/evidenceReconciliationFromSources.js +29 -324
- package/dist/assemble/evidenceReconciliationFromSources.js.map +1 -1
- package/dist/assemble/renderInput.d.ts +6 -72
- package/dist/assemble/renderInput.d.ts.map +1 -1
- package/dist/assemble/renderInput.js +3 -45
- package/dist/assemble/renderInput.js.map +1 -1
- package/dist/census/evidenceObligations.d.ts +10 -46
- package/dist/census/evidenceObligations.d.ts.map +1 -1
- package/dist/census/evidenceObligations.js +15 -25
- package/dist/census/evidenceObligations.js.map +1 -1
- package/dist/domain/evidenceOrder.d.ts +3 -0
- package/dist/domain/evidenceOrder.d.ts.map +1 -0
- package/dist/domain/evidenceOrder.js +15 -0
- package/dist/domain/evidenceOrder.js.map +1 -0
- package/dist/domain/evidenceReconciliation.d.ts +16 -386
- package/dist/domain/evidenceReconciliation.d.ts.map +1 -1
- package/dist/domain/evidenceReconciliation.js +79 -375
- package/dist/domain/evidenceReconciliation.js.map +1 -1
- package/dist/domain/featureCode.d.ts +4 -0
- package/dist/domain/featureCode.d.ts.map +1 -0
- package/dist/domain/featureCode.js +12 -0
- package/dist/domain/featureCode.js.map +1 -0
- package/dist/domain/journal.d.ts +7 -392
- package/dist/domain/journal.d.ts.map +1 -1
- package/dist/domain/journal.js +6 -118
- package/dist/domain/journal.js.map +1 -1
- package/dist/domain/ledger.d.ts +4 -328
- package/dist/domain/ledger.d.ts.map +1 -1
- package/dist/domain/ledger.js +11 -317
- package/dist/domain/ledger.js.map +1 -1
- package/dist/domain/outcome.d.ts +3 -0
- package/dist/domain/outcome.d.ts.map +1 -0
- package/dist/domain/outcome.js +2 -0
- package/dist/domain/outcome.js.map +1 -0
- package/dist/domain/posting.d.ts +5 -102
- package/dist/domain/posting.d.ts.map +1 -1
- package/dist/domain/posting.js +3 -55
- package/dist/domain/posting.js.map +1 -1
- package/dist/domain/qualityCheckFault.d.ts +1 -41
- package/dist/domain/qualityCheckFault.d.ts.map +1 -1
- package/dist/domain/qualityCheckFault.js +0 -24
- package/dist/domain/qualityCheckFault.js.map +1 -1
- package/dist/domain/qualityCheckFaultMessages.d.ts +0 -35
- package/dist/domain/qualityCheckFaultMessages.d.ts.map +1 -1
- package/dist/domain/qualityCheckFaultMessages.js +0 -28
- package/dist/domain/qualityCheckFaultMessages.js.map +1 -1
- package/dist/domain/qualityCheckReconciliation.d.ts +5 -278
- package/dist/domain/qualityCheckReconciliation.d.ts.map +1 -1
- package/dist/domain/qualityCheckReconciliation.js +53 -453
- package/dist/domain/qualityCheckReconciliation.js.map +1 -1
- package/dist/domain/qualityCheckReconciliationFault.d.ts +0 -19
- package/dist/domain/qualityCheckReconciliationFault.d.ts.map +1 -1
- package/dist/domain/qualityCheckReconciliationFault.js +0 -23
- package/dist/domain/qualityCheckReconciliationFault.js.map +1 -1
- package/dist/domain/scenarioCodeError.d.ts +16 -0
- package/dist/domain/scenarioCodeError.d.ts.map +1 -0
- package/dist/domain/scenarioCodeError.js +4 -0
- package/dist/domain/scenarioCodeError.js.map +1 -0
- package/dist/domain/scenarioReconciliation.d.ts +0 -205
- package/dist/domain/scenarioReconciliation.d.ts.map +1 -1
- package/dist/domain/scenarioReconciliation.js +1 -98
- package/dist/domain/scenarioReconciliation.js.map +1 -1
- package/dist/domain/scnAllocation.d.ts +27 -0
- package/dist/domain/scnAllocation.d.ts.map +1 -0
- package/dist/domain/scnAllocation.js +33 -0
- package/dist/domain/scnAllocation.js.map +1 -0
- package/dist/domain/verdictCode.d.ts +10 -0
- package/dist/domain/verdictCode.d.ts.map +1 -0
- package/dist/domain/verdictCode.js +16 -0
- package/dist/domain/verdictCode.js.map +1 -0
- package/dist/index.d.ts +12 -38
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +6 -86
- package/dist/index.js.map +1 -1
- package/dist/internal.d.ts +3 -25
- package/dist/internal.d.ts.map +1 -1
- package/dist/internal.js +3 -93
- package/dist/internal.js.map +1 -1
- package/dist/lib/bareTerm.d.ts +0 -39
- package/dist/lib/bareTerm.d.ts.map +1 -1
- package/dist/lib/bareTerm.js +0 -39
- package/dist/lib/bareTerm.js.map +1 -1
- package/dist/lib/portablePath.d.ts.map +1 -1
- package/dist/lib/portablePath.js +0 -14
- package/dist/lib/portablePath.js.map +1 -1
- package/dist/lib/scnCitation.d.ts +0 -32
- package/dist/lib/scnCitation.d.ts.map +1 -1
- package/dist/lib/scnCitation.js +2 -42
- package/dist/lib/scnCitation.js.map +1 -1
- package/dist/model.d.ts +0 -23
- package/dist/model.d.ts.map +1 -1
- package/dist/model.js +0 -23
- package/dist/model.js.map +1 -1
- package/dist/parse/checkScriptsRunInCI.d.ts +3 -151
- package/dist/parse/checkScriptsRunInCI.d.ts.map +1 -1
- package/dist/parse/checkScriptsRunInCI.js +5 -143
- package/dist/parse/checkScriptsRunInCI.js.map +1 -1
- package/dist/parse/ciStepRecord.d.ts +2 -117
- package/dist/parse/ciStepRecord.d.ts.map +1 -1
- package/dist/parse/ciStepRecord.js +12 -218
- package/dist/parse/ciStepRecord.js.map +1 -1
- package/dist/parse/commandRuns.d.ts +0 -39
- package/dist/parse/commandRuns.d.ts.map +1 -1
- package/dist/parse/commandRuns.js +0 -58
- package/dist/parse/commandRuns.js.map +1 -1
- package/dist/parse/cucumber.d.ts +0 -52
- package/dist/parse/cucumber.d.ts.map +1 -1
- package/dist/parse/cucumber.js +37 -143
- package/dist/parse/cucumber.js.map +1 -1
- package/dist/parse/discoveryScope.d.ts +0 -45
- package/dist/parse/discoveryScope.d.ts.map +1 -1
- package/dist/parse/discoveryScope.js +0 -55
- package/dist/parse/discoveryScope.js.map +1 -1
- package/dist/parse/fitnessCitations.d.ts +1 -72
- package/dist/parse/fitnessCitations.d.ts.map +1 -1
- package/dist/parse/fitnessCitations.js +3 -55
- package/dist/parse/fitnessCitations.js.map +1 -1
- package/dist/parse/reconcilerSteps.d.ts +0 -46
- package/dist/parse/reconcilerSteps.d.ts.map +1 -1
- package/dist/parse/reconcilerSteps.js +0 -63
- package/dist/parse/reconcilerSteps.js.map +1 -1
- package/dist/parse/runningStaticChecks.d.ts +2 -118
- package/dist/parse/runningStaticChecks.d.ts.map +1 -1
- package/dist/parse/runningStaticChecks.js +14 -273
- package/dist/parse/runningStaticChecks.js.map +1 -1
- package/dist/parse/scenarioCodeErrors.d.ts +12 -0
- package/dist/parse/scenarioCodeErrors.d.ts.map +1 -0
- package/dist/parse/scenarioCodeErrors.js +88 -0
- package/dist/parse/scenarioCodeErrors.js.map +1 -0
- package/dist/parse/scenarios.d.ts +3 -228
- package/dist/parse/scenarios.d.ts.map +1 -1
- package/dist/parse/scenarios.js +11 -447
- package/dist/parse/scenarios.js.map +1 -1
- package/dist/parse/stepAccounting.d.ts +0 -46
- package/dist/parse/stepAccounting.d.ts.map +1 -1
- package/dist/parse/stepAccounting.js +0 -54
- package/dist/parse/stepAccounting.js.map +1 -1
- package/dist/parse/stepExclusions.d.ts +0 -47
- package/dist/parse/stepExclusions.d.ts.map +1 -1
- package/dist/parse/stepExclusions.js +0 -45
- package/dist/parse/stepExclusions.js.map +1 -1
- package/dist/parse/stepNames.d.ts +0 -27
- package/dist/parse/stepNames.d.ts.map +1 -1
- package/dist/parse/stepNames.js +0 -27
- package/dist/parse/stepNames.js.map +1 -1
- package/dist/parse/targetCorpus.d.ts +1 -78
- package/dist/parse/targetCorpus.d.ts.map +1 -1
- package/dist/parse/targetCorpus.js +4 -46
- package/dist/parse/targetCorpus.js.map +1 -1
- package/dist/parse/targetManifest.d.ts +8 -146
- package/dist/parse/targetManifest.d.ts.map +1 -1
- package/dist/parse/targetManifest.js +47 -198
- package/dist/parse/targetManifest.js.map +1 -1
- package/dist/parse/vitest.d.ts +0 -60
- package/dist/parse/vitest.d.ts.map +1 -1
- package/dist/parse/vitest.js +1 -81
- package/dist/parse/vitest.js.map +1 -1
- package/dist/provenance/provenance.d.ts +2 -110
- package/dist/provenance/provenance.d.ts.map +1 -1
- package/dist/provenance/provenance.js +2 -58
- package/dist/provenance/provenance.js.map +1 -1
- package/dist/render/behaviouralRunners.d.ts +0 -29
- package/dist/render/behaviouralRunners.d.ts.map +1 -1
- package/dist/render/behaviouralRunners.js +0 -64
- package/dist/render/behaviouralRunners.js.map +1 -1
- package/dist/render/configurationNotRead.d.ts +3 -0
- package/dist/render/configurationNotRead.d.ts.map +1 -0
- package/dist/render/configurationNotRead.js +17 -0
- package/dist/render/configurationNotRead.js.map +1 -0
- package/dist/render/discoveryScope.d.ts +0 -37
- package/dist/render/discoveryScope.d.ts.map +1 -1
- package/dist/render/discoveryScope.js +0 -37
- package/dist/render/discoveryScope.js.map +1 -1
- package/dist/render/evidenceGrid.d.ts +1 -35
- package/dist/render/evidenceGrid.d.ts.map +1 -1
- package/dist/render/evidenceGrid.js +18 -100
- package/dist/render/evidenceGrid.js.map +1 -1
- package/dist/render/excludedSteps.d.ts +0 -26
- package/dist/render/excludedSteps.d.ts.map +1 -1
- package/dist/render/excludedSteps.js +0 -29
- package/dist/render/excludedSteps.js.map +1 -1
- package/dist/render/json.d.ts +0 -11
- package/dist/render/json.d.ts.map +1 -1
- package/dist/render/json.js +0 -11
- package/dist/render/json.js.map +1 -1
- package/dist/render/markdown.d.ts +0 -54
- package/dist/render/markdown.d.ts.map +1 -1
- package/dist/render/markdown.js +88 -426
- package/dist/render/markdown.js.map +1 -1
- package/dist/render/provenanceSection.d.ts +0 -22
- package/dist/render/provenanceSection.d.ts.map +1 -1
- package/dist/render/provenanceSection.js +0 -44
- package/dist/render/provenanceSection.js.map +1 -1
- package/dist/render/reconcilerSteps.d.ts +0 -25
- package/dist/render/reconcilerSteps.d.ts.map +1 -1
- package/dist/render/reconcilerSteps.js +0 -26
- package/dist/render/reconcilerSteps.js.map +1 -1
- package/dist/render/runVerdict.d.ts +0 -38
- package/dist/render/runVerdict.d.ts.map +1 -1
- package/dist/render/runVerdict.js +68 -127
- package/dist/render/runVerdict.js.map +1 -1
- package/dist/render/scenarioCodeErrorsSection.d.ts +3 -0
- package/dist/render/scenarioCodeErrorsSection.d.ts.map +1 -0
- package/dist/render/scenarioCodeErrorsSection.js +42 -0
- package/dist/render/scenarioCodeErrorsSection.js.map +1 -0
- package/dist/render/staticChecks.d.ts +0 -20
- package/dist/render/staticChecks.d.ts.map +1 -1
- package/dist/render/staticChecks.js +1 -59
- package/dist/render/staticChecks.js.map +1 -1
- package/dist/render/stepAccounting.d.ts +0 -36
- package/dist/render/stepAccounting.d.ts.map +1 -1
- package/dist/render/stepAccounting.js +0 -44
- package/dist/render/stepAccounting.js.map +1 -1
- package/dist/render/testVolume.d.ts +0 -25
- package/dist/render/testVolume.d.ts.map +1 -1
- package/dist/render/testVolume.js +0 -32
- package/dist/render/testVolume.js.map +1 -1
- package/package.json +4 -1
- package/dist/domain/checkCharacteristics.d.ts +0 -88
- package/dist/domain/checkCharacteristics.d.ts.map +0 -1
- package/dist/domain/checkCharacteristics.js +0 -109
- package/dist/domain/checkCharacteristics.js.map +0 -1
- package/dist/domain/fitnessChecks.d.ts +0 -79
- package/dist/domain/fitnessChecks.d.ts.map +0 -1
- package/dist/domain/fitnessChecks.js +0 -81
- package/dist/domain/fitnessChecks.js.map +0 -1
- package/dist/lib/featureCode.d.ts +0 -21
- package/dist/lib/featureCode.d.ts.map +0 -1
- package/dist/lib/featureCode.js +0 -24
- package/dist/lib/featureCode.js.map +0 -1
- package/dist/parse/corpusCodeFaults.d.ts +0 -76
- package/dist/parse/corpusCodeFaults.d.ts.map +0 -1
- package/dist/parse/corpusCodeFaults.js +0 -121
- package/dist/parse/corpusCodeFaults.js.map +0 -1
- package/dist/parse/corpusFaults.d.ts +0 -124
- package/dist/parse/corpusFaults.d.ts.map +0 -1
- package/dist/parse/corpusFaults.js +0 -72
- package/dist/parse/corpusFaults.js.map +0 -1
- package/dist/parse/corpusGrammarFaults.d.ts +0 -71
- package/dist/parse/corpusGrammarFaults.d.ts.map +0 -1
- package/dist/parse/corpusGrammarFaults.js +0 -292
- package/dist/parse/corpusGrammarFaults.js.map +0 -1
|
@@ -1,81 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* THE FITNESS CHECK ROWS — what a CONVERTED check says about itself, keyed by the `@SCN` it is
|
|
3
|
-
* about.
|
|
4
|
-
*
|
|
5
|
-
* @SCN the row what the corpus then reads
|
|
6
|
-
* SCN-FIT-001 { characteristic: complexity } a @fitness scenario owes `complexity`
|
|
7
|
-
*
|
|
8
|
-
* THE TAG NAMES THE AXIS AND THE ROW NAMES THE SUBJECT. A bare characteristic tag answered two
|
|
9
|
-
* questions at once — how a claim is proved, and what it is about — and the tier tags answer only
|
|
10
|
-
* the first. So a converted scenario carries `@fitness` alone, and the characteristic moves here,
|
|
11
|
-
* where it stays a first-class word the roll-up still groups by.
|
|
12
|
-
*
|
|
13
|
-
* NOT A SECOND OBLIGATION SHAPE. What a `@fitness` scenario raises is the same
|
|
14
|
-
* `{ qualityCheck: "lint", staticCheck: <characteristic> }` a registered bare tag raises today, so
|
|
15
|
-
* the pair key, the reconciler's static arm and the report's roll-up are all untouched. What
|
|
16
|
-
* changed is only where the word came from.
|
|
17
|
-
*
|
|
18
|
-
* NOT THE (RETIRED) CHECK REGISTRY, AND THE DIFFERENCE IS THE SEAM THIS RETIRES. That registry
|
|
19
|
-
* answered "which check is this runnable script handle", because a handle does not know what it
|
|
20
|
-
* is for; the `@SCN`
|
|
21
|
-
* is then resolved through the corpus, a second hop. A converted check is never discovered as a
|
|
22
|
-
* handle — it is a scenario that ran, carrying its own tag line — so the `@SCN` is the KEY here
|
|
23
|
-
* rather than something a lookup has to recover.
|
|
24
|
-
*
|
|
25
|
-
* PURE AND INJECTED — the rows arrive as data, read from the TARGET's own manifest at the app edge
|
|
26
|
-
* (`specController.fitnessChecks`), the stance the retired `thresholdsOf` took. A target that
|
|
27
|
-
* configures nothing raises nothing, so the reading is inert on a corpus
|
|
28
|
-
* nobody has converted.
|
|
29
|
-
*/
|
|
30
|
-
import { bareTerm } from "../lib/bareTerm.js";
|
|
31
|
-
/**
|
|
32
|
-
* One entry as a manifest spells it, read into the pair a lookup can use, or `null` where it names
|
|
33
|
-
* nothing one can.
|
|
34
|
-
*
|
|
35
|
-
* BOTH TERMS ARE STORED BARE. A manifest written by hand will sooner or later spell an `@SCN` — and
|
|
36
|
-
* a characteristic — the way a feature file does, and both lookups match bare; stripping once here
|
|
37
|
-
* rather than at every call site is the stance the retired `thresholdsOf` took.
|
|
38
|
-
*
|
|
39
|
-
* A ROW NAMING NEITHER TERM IS DROPPED WHOLE, never half-read. The two terms make one claim
|
|
40
|
-
* together — THIS scenario asserts THIS characteristic — so a row missing either says nothing a
|
|
41
|
-
* lookup can act on, and there is no lenient reading that does not invent one of them.
|
|
42
|
-
*/
|
|
43
|
-
function fitnessCheckOf(entry) {
|
|
44
|
-
// THE TWO STRING READS ARE THE WHOLE GUARD, and a shape test ahead of them would add no teeth: a
|
|
45
|
-
// string, a number, a list and a function all answer `undefined` here, so each is refused by the
|
|
46
|
-
// read that matters rather than by a clause restating it. The optional chain is what covers the
|
|
47
|
-
// two values a property read would throw on.
|
|
48
|
-
const named = entry;
|
|
49
|
-
if (typeof named?.scn !== "string" || typeof named.characteristic !== "string")
|
|
50
|
-
return null;
|
|
51
|
-
const scnId = bareTerm(named.scn);
|
|
52
|
-
const characteristic = bareTerm(named.characteristic);
|
|
53
|
-
if (scnId === "" || characteristic === "")
|
|
54
|
-
return null;
|
|
55
|
-
return [scnId, { characteristic }];
|
|
56
|
-
}
|
|
57
|
-
/**
|
|
58
|
-
* Build the index from the rows a manifest holds.
|
|
59
|
-
*
|
|
60
|
-
* A LIST, NOT A BLOCK KEYED BY `@SCN`, and the shape is the row's own argument: a row is what a
|
|
61
|
-
* check says about ITSELF — its `@SCN`, its characteristic, its command — so no one of those three
|
|
62
|
-
* is promoted above the others by being the key somebody has to write it under. The `@SCN` becomes
|
|
63
|
-
* the key HERE, where a lookup needs one.
|
|
64
|
-
*
|
|
65
|
-
* A MALFORMED ROW IS DROPPED, NOT TRUSTED AND NOT THROWN ON — the defensive stance the whole
|
|
66
|
-
* `specController.*` family takes. Config is data from outside, and a reader that throws on a typo
|
|
67
|
-
* turns one bad character into a run that produces no verdict at all, which is loud nowhere; a
|
|
68
|
-
* dropped row leaves its scenario naming no characteristic, which the corpus reports.
|
|
69
|
-
*/
|
|
70
|
-
export function fitnessChecksOf(entries) {
|
|
71
|
-
if (!Array.isArray(entries))
|
|
72
|
-
return new Map();
|
|
73
|
-
const index = new Map();
|
|
74
|
-
for (const entry of entries) {
|
|
75
|
-
const row = fitnessCheckOf(entry);
|
|
76
|
-
if (row !== null)
|
|
77
|
-
index.set(row[0], row[1]);
|
|
78
|
-
}
|
|
79
|
-
return index;
|
|
80
|
-
}
|
|
81
|
-
//# sourceMappingURL=fitnessChecks.js.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"fitnessChecks.js","sourceRoot":"","sources":["../../src/domain/fitnessChecks.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AAEH,OAAO,EAAE,QAAQ,EAAE,MAAM,oBAAoB,CAAC;AAkB9C;;;;;;;;;;;GAWG;AACH,SAAS,cAAc,CAAC,KAAc;IACpC,iGAAiG;IACjG,iGAAiG;IACjG,gGAAgG;IAChG,6CAA6C;IAC7C,MAAM,KAAK,GAAG,KAAuE,CAAC;IACtF,IAAI,OAAO,KAAK,EAAE,GAAG,KAAK,QAAQ,IAAI,OAAO,KAAK,CAAC,cAAc,KAAK,QAAQ;QAAE,OAAO,IAAI,CAAC;IAC5F,MAAM,KAAK,GAAG,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;IAClC,MAAM,cAAc,GAAG,QAAQ,CAAC,KAAK,CAAC,cAAc,CAAC,CAAC;IACtD,IAAI,KAAK,KAAK,EAAE,IAAI,cAAc,KAAK,EAAE;QAAE,OAAO,IAAI,CAAC;IACvD,OAAO,CAAC,KAAK,EAAE,EAAE,cAAc,EAAE,CAAC,CAAC;AACrC,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,eAAe,CAAC,OAAgB;IAC9C,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC;QAAE,OAAO,IAAI,GAAG,EAAE,CAAC;IAC9C,MAAM,KAAK,GAAG,IAAI,GAAG,EAAwB,CAAC;IAC9C,KAAK,MAAM,KAAK,IAAI,OAA6B,EAAE,CAAC;QAClD,MAAM,GAAG,GAAG,cAAc,CAAC,KAAK,CAAC,CAAC;QAClC,IAAI,GAAG,KAAK,IAAI;YAAE,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC;IAC9C,CAAC;IACD,OAAO,KAAK,CAAC;AACf,CAAC"}
|
|
@@ -1,21 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* The `scnId → feature-code` grammar helper — the pure core of the feature-code
|
|
3
|
-
* registry (split out of the old spec/featureCodes.ts). Per Evidence
|
|
4
|
-
* Manifesto §9A a scenario id is `SCN-<FFF>-<NNN>` where `<FFF>` is 2–5 uppercase
|
|
5
|
-
* alphanumerics. This is the ONE engine-side owner of parsing the `<FFF>` off a bare
|
|
6
|
-
* scenario id; the impure feature-file discovery (`discoverFeatures`) lives in
|
|
7
|
-
* ingest/ingestScenarios.ts. The duplicate-code lint was product-side in
|
|
8
|
-
* tests/checks/featureCodes.ts until 3F-3313 and is now @SCN-STG-010, a rule of the shipped
|
|
9
|
-
* `spec-controller tags` command in parse/corpusFaults.ts.
|
|
10
|
-
*
|
|
11
|
-
* Reused by the by-feature report grouping (@SCN-RPT-006).
|
|
12
|
-
*/
|
|
13
|
-
/**
|
|
14
|
-
* Parse the feature code (the `<FFF>`) from a bare scenario id of the form
|
|
15
|
-
* `SCN-<FFF>-<NNN>` (no leading `@`). Returns null when the id is malformed. The
|
|
16
|
-
* single owner of `scnId → feature-code` parsing — callers reuse this rather than
|
|
17
|
-
* re-deriving a regex (Evidence Manifesto §9A: a scenario id is `SCN-<FFF>-<NNN>`
|
|
18
|
-
* where `<FFF>` is 2–5 uppercase alphanumerics).
|
|
19
|
-
*/
|
|
20
|
-
export declare function featureCodeOf(scnId: string): string | null;
|
|
21
|
-
//# sourceMappingURL=featureCode.d.ts.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"featureCode.d.ts","sourceRoot":"","sources":["../../src/lib/featureCode.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH;;;;;;GAMG;AACH,wBAAgB,aAAa,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAG1D"}
|
package/dist/lib/featureCode.js
DELETED
|
@@ -1,24 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* The `scnId → feature-code` grammar helper — the pure core of the feature-code
|
|
3
|
-
* registry (split out of the old spec/featureCodes.ts). Per Evidence
|
|
4
|
-
* Manifesto §9A a scenario id is `SCN-<FFF>-<NNN>` where `<FFF>` is 2–5 uppercase
|
|
5
|
-
* alphanumerics. This is the ONE engine-side owner of parsing the `<FFF>` off a bare
|
|
6
|
-
* scenario id; the impure feature-file discovery (`discoverFeatures`) lives in
|
|
7
|
-
* ingest/ingestScenarios.ts. The duplicate-code lint was product-side in
|
|
8
|
-
* tests/checks/featureCodes.ts until 3F-3313 and is now @SCN-STG-010, a rule of the shipped
|
|
9
|
-
* `spec-controller tags` command in parse/corpusFaults.ts.
|
|
10
|
-
*
|
|
11
|
-
* Reused by the by-feature report grouping (@SCN-RPT-006).
|
|
12
|
-
*/
|
|
13
|
-
/**
|
|
14
|
-
* Parse the feature code (the `<FFF>`) from a bare scenario id of the form
|
|
15
|
-
* `SCN-<FFF>-<NNN>` (no leading `@`). Returns null when the id is malformed. The
|
|
16
|
-
* single owner of `scnId → feature-code` parsing — callers reuse this rather than
|
|
17
|
-
* re-deriving a regex (Evidence Manifesto §9A: a scenario id is `SCN-<FFF>-<NNN>`
|
|
18
|
-
* where `<FFF>` is 2–5 uppercase alphanumerics).
|
|
19
|
-
*/
|
|
20
|
-
export function featureCodeOf(scnId) {
|
|
21
|
-
const match = /^SCN-([A-Z0-9]{2,5})-\d+$/.exec(scnId);
|
|
22
|
-
return match ? match[1] : null;
|
|
23
|
-
}
|
|
24
|
-
//# sourceMappingURL=featureCode.js.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"featureCode.js","sourceRoot":"","sources":["../../src/lib/featureCode.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH;;;;;;GAMG;AACH,MAAM,UAAU,aAAa,CAAC,KAAa;IACzC,MAAM,KAAK,GAAG,2BAA2B,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;IACtD,OAAO,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAE,CAAC,CAAC,CAAC,IAAI,CAAC;AAClC,CAAC"}
|
|
@@ -1,76 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* THE CODE RULES of `spec-controller tags` — everything about a feature CODE binding to a feature
|
|
3
|
-
* FILE. Its sibling holds the other question: `corpusGrammarFaults.ts` whether a tag on a scenario
|
|
4
|
-
* means anything. `corpusFaults.ts` composes the two and is the only entry point either of them
|
|
5
|
-
* has.
|
|
6
|
-
*
|
|
7
|
-
* WHY THE MODULE IS SPLIT AT ALL, AND WHY ON THIS SEAM. The rules were authored in one module and
|
|
8
|
-
* that module reached the 400-line `max-lines` ceiling with four more grammar clauses still to
|
|
9
|
-
* land. The ceiling is not negotiable and an exception entry would have bought silence rather than
|
|
10
|
-
* a smaller module (@SCN-FIT-001), so the split is the answer canon already named. The seam is the
|
|
11
|
-
* one the rules themselves have: a code rule asks *does this code name exactly one file, and is
|
|
12
|
-
* this scenario written in the file its own code names* — questions answered from the corpus's
|
|
13
|
-
* SHAPE, needing nothing about the target. A grammar rule asks *does this word mean anything
|
|
14
|
-
* here*, and answers it off the target's own manifest. Two questions, two inputs, two modules.
|
|
15
|
-
*
|
|
16
|
-
* THE PAIR BELOW IS ONE RULE READ FROM BOTH ENDS. `duplicateFeatureCodes` holds one code to one
|
|
17
|
-
* file; `foreignScenarioCodes` holds a file's scenarios to the code that file carries. Together
|
|
18
|
-
* they are what the hand-kept 33-entry allocation table was really enforcing — this code belongs
|
|
19
|
-
* to this file — asked of the corpus about itself rather than of a second list a consumer has
|
|
20
|
-
* never seen.
|
|
21
|
-
*/
|
|
22
|
-
import type { CorpusFault, CorpusFile } from "./corpusFaults.js";
|
|
23
|
-
/**
|
|
24
|
-
* A feature code carried by more than one feature file (@SCN-STG-010).
|
|
25
|
-
*
|
|
26
|
-
* THE FAULT IS THE PAIR, NOT EITHER FILE, which is why one finding names them all rather than
|
|
27
|
-
* one finding naming each. Neither file is the offender: what is wrong is that a code names two
|
|
28
|
-
* of them, and a message naming one has already decided which of the two should change.
|
|
29
|
-
*
|
|
30
|
-
* WHAT GOES WRONG WITHOUT IT, MEASURED. Over a corpus whose `one.feature` and `two.feature` both
|
|
31
|
-
* carry `@TGT`, `balance` runs clean through and prints ONE by-feature row — `two (TGT)` —
|
|
32
|
-
* claiming a scenario that lives in `one`. Not a red and not a warning: a report cell that says
|
|
33
|
-
* something false, in the section a reader goes to first.
|
|
34
|
-
*
|
|
35
|
-
* AN UNCODED FILE IS NOT A FAULT HERE, and that is a scope line rather than an omission. A file
|
|
36
|
-
* carrying no header code while its scenarios carry `@SCN` ids is admitted unchanged; whether
|
|
37
|
-
* that should red is a policy question about gradual adoption, filed as its own ticket (3F-3314).
|
|
38
|
-
* `null` is therefore skipped rather than treated as a code two files could share.
|
|
39
|
-
*/
|
|
40
|
-
export declare function duplicateFeatureCodes(features: readonly CorpusFile[]): CorpusFault[];
|
|
41
|
-
/**
|
|
42
|
-
* A scenario whose `@SCN` names a feature its own file is not (@SCN-STG-011).
|
|
43
|
-
*
|
|
44
|
-
* THE OTHER HALF OF THE PAIR ABOVE. That rule holds one code to one file; this one holds a
|
|
45
|
-
* file's scenarios to the code that file carries.
|
|
46
|
-
*
|
|
47
|
-
* WHAT GOES WRONG WITHOUT IT, MEASURED. Over a corpus whose `@TGT`-headed file holds
|
|
48
|
-
* `@SCN-ZZZ-001`, `balance` runs clean through and prints a by-feature row for a feature `ZZZ`
|
|
49
|
-
* it INVENTED from the id alone — no file in the corpus carries that code — and the
|
|
50
|
-
* feature-code lint over the same tree reports every code a header names unique and registered.
|
|
51
|
-
* Silent in both readers, which is exactly the pair of places a reader looks.
|
|
52
|
-
*
|
|
53
|
-
* THE FINDING NAMES THREE THINGS AND ONE SCENARIO. The file and the id say where to go; the
|
|
54
|
-
* code the file CARRIES is the half of the disagreement the author cannot read off the id, and
|
|
55
|
-
* it is what decides which of the two remedies they want — re-code the scenario, or move it.
|
|
56
|
-
* And it is raised per offending scenario, never per file: a file may hold many scenarios of
|
|
57
|
-
* which one is wrong, and a finding naming the file alone convicts the rest of them.
|
|
58
|
-
*
|
|
59
|
-
* AN UNCODED FILE RAISES NOTHING, deliberately rather than by omission. A file carrying no
|
|
60
|
-
* header code has nothing for an id to be foreign TO. Whether that should red is a policy
|
|
61
|
-
* question about gradual adoption, filed as its own ticket (3F-3314) — and it is the same
|
|
62
|
-
* `null`-is-not-a-code line the duplicate rule draws, drawn once more here so the two cannot
|
|
63
|
-
* come to disagree about what an uncoded file is.
|
|
64
|
-
*
|
|
65
|
-
* AND A MALFORMED ID RAISES NOTHING EITHER, because something else already does. `featureCodeOf`
|
|
66
|
-
* is the ONE owner of the `SCN-<FFF>-<NNN>` grammar in this engine, and an id it cannot parse
|
|
67
|
-
* has no feature part to compare — that fault is `no-scn-code`, which a reconciliation raises
|
|
68
|
-
* and names by id. A second diagnostic here would print one fault's remedy at the other's author.
|
|
69
|
-
*
|
|
70
|
-
* The tag walk is `parseTaggedScenarios`, which inherits Feature- and Rule-level tags exactly as
|
|
71
|
-
* cucumber does. A hand-rolled scan of the tag lines is the second reading that walk was
|
|
72
|
-
* extracted to end, and it is what a rule ABOUT ids can least afford: an id hoisted to a `Rule:`
|
|
73
|
-
* belongs to every scenario beneath it, and a scan that missed that would pass over the file.
|
|
74
|
-
*/
|
|
75
|
-
export declare function foreignScenarioCodes(features: readonly CorpusFile[]): CorpusFault[];
|
|
76
|
-
//# sourceMappingURL=corpusCodeFaults.d.ts.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"corpusCodeFaults.d.ts","sourceRoot":"","sources":["../../src/parse/corpusCodeFaults.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAGH,OAAO,KAAK,EAAE,WAAW,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAGjE;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,qBAAqB,CAAC,QAAQ,EAAE,SAAS,UAAU,EAAE,GAAG,WAAW,EAAE,CAuBpF;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,wBAAgB,oBAAoB,CAAC,QAAQ,EAAE,SAAS,UAAU,EAAE,GAAG,WAAW,EAAE,CAoBnF"}
|
|
@@ -1,121 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* THE CODE RULES of `spec-controller tags` — everything about a feature CODE binding to a feature
|
|
3
|
-
* FILE. Its sibling holds the other question: `corpusGrammarFaults.ts` whether a tag on a scenario
|
|
4
|
-
* means anything. `corpusFaults.ts` composes the two and is the only entry point either of them
|
|
5
|
-
* has.
|
|
6
|
-
*
|
|
7
|
-
* WHY THE MODULE IS SPLIT AT ALL, AND WHY ON THIS SEAM. The rules were authored in one module and
|
|
8
|
-
* that module reached the 400-line `max-lines` ceiling with four more grammar clauses still to
|
|
9
|
-
* land. The ceiling is not negotiable and an exception entry would have bought silence rather than
|
|
10
|
-
* a smaller module (@SCN-FIT-001), so the split is the answer canon already named. The seam is the
|
|
11
|
-
* one the rules themselves have: a code rule asks *does this code name exactly one file, and is
|
|
12
|
-
* this scenario written in the file its own code names* — questions answered from the corpus's
|
|
13
|
-
* SHAPE, needing nothing about the target. A grammar rule asks *does this word mean anything
|
|
14
|
-
* here*, and answers it off the target's own manifest. Two questions, two inputs, two modules.
|
|
15
|
-
*
|
|
16
|
-
* THE PAIR BELOW IS ONE RULE READ FROM BOTH ENDS. `duplicateFeatureCodes` holds one code to one
|
|
17
|
-
* file; `foreignScenarioCodes` holds a file's scenarios to the code that file carries. Together
|
|
18
|
-
* they are what the hand-kept 33-entry allocation table was really enforcing — this code belongs
|
|
19
|
-
* to this file — asked of the corpus about itself rather than of a second list a consumer has
|
|
20
|
-
* never seen.
|
|
21
|
-
*/
|
|
22
|
-
import { featureCodeOf } from "../lib/featureCode.js";
|
|
23
|
-
import { parseTaggedScenarios } from "./scenarios.js";
|
|
24
|
-
/**
|
|
25
|
-
* A feature code carried by more than one feature file (@SCN-STG-010).
|
|
26
|
-
*
|
|
27
|
-
* THE FAULT IS THE PAIR, NOT EITHER FILE, which is why one finding names them all rather than
|
|
28
|
-
* one finding naming each. Neither file is the offender: what is wrong is that a code names two
|
|
29
|
-
* of them, and a message naming one has already decided which of the two should change.
|
|
30
|
-
*
|
|
31
|
-
* WHAT GOES WRONG WITHOUT IT, MEASURED. Over a corpus whose `one.feature` and `two.feature` both
|
|
32
|
-
* carry `@TGT`, `balance` runs clean through and prints ONE by-feature row — `two (TGT)` —
|
|
33
|
-
* claiming a scenario that lives in `one`. Not a red and not a warning: a report cell that says
|
|
34
|
-
* something false, in the section a reader goes to first.
|
|
35
|
-
*
|
|
36
|
-
* AN UNCODED FILE IS NOT A FAULT HERE, and that is a scope line rather than an omission. A file
|
|
37
|
-
* carrying no header code while its scenarios carry `@SCN` ids is admitted unchanged; whether
|
|
38
|
-
* that should red is a policy question about gradual adoption, filed as its own ticket (3F-3314).
|
|
39
|
-
* `null` is therefore skipped rather than treated as a code two files could share.
|
|
40
|
-
*/
|
|
41
|
-
export function duplicateFeatureCodes(features) {
|
|
42
|
-
const filesByCode = new Map();
|
|
43
|
-
for (const file of features) {
|
|
44
|
-
if (file.featureCode === null)
|
|
45
|
-
continue;
|
|
46
|
-
filesByCode.set(file.featureCode, [
|
|
47
|
-
...(filesByCode.get(file.featureCode) ?? []),
|
|
48
|
-
`${file.slug}.feature`,
|
|
49
|
-
]);
|
|
50
|
-
}
|
|
51
|
-
const faults = [];
|
|
52
|
-
for (const [code, files] of filesByCode) {
|
|
53
|
-
if (files.length < 2)
|
|
54
|
-
continue;
|
|
55
|
-
faults.push({
|
|
56
|
-
kind: "duplicate-feature-code",
|
|
57
|
-
message: `duplicate-feature-code: the feature code @${code} is carried by ${files.length} feature ` +
|
|
58
|
-
`files — ${files.join(", ")}. A feature code names exactly one feature file: a ` +
|
|
59
|
-
`reconciliation's by-feature cut groups on it, so two files sharing a code report as one ` +
|
|
60
|
-
`row and attribute one file's scenarios to the other. Give one of them a code of its own.`,
|
|
61
|
-
});
|
|
62
|
-
}
|
|
63
|
-
return faults;
|
|
64
|
-
}
|
|
65
|
-
/**
|
|
66
|
-
* A scenario whose `@SCN` names a feature its own file is not (@SCN-STG-011).
|
|
67
|
-
*
|
|
68
|
-
* THE OTHER HALF OF THE PAIR ABOVE. That rule holds one code to one file; this one holds a
|
|
69
|
-
* file's scenarios to the code that file carries.
|
|
70
|
-
*
|
|
71
|
-
* WHAT GOES WRONG WITHOUT IT, MEASURED. Over a corpus whose `@TGT`-headed file holds
|
|
72
|
-
* `@SCN-ZZZ-001`, `balance` runs clean through and prints a by-feature row for a feature `ZZZ`
|
|
73
|
-
* it INVENTED from the id alone — no file in the corpus carries that code — and the
|
|
74
|
-
* feature-code lint over the same tree reports every code a header names unique and registered.
|
|
75
|
-
* Silent in both readers, which is exactly the pair of places a reader looks.
|
|
76
|
-
*
|
|
77
|
-
* THE FINDING NAMES THREE THINGS AND ONE SCENARIO. The file and the id say where to go; the
|
|
78
|
-
* code the file CARRIES is the half of the disagreement the author cannot read off the id, and
|
|
79
|
-
* it is what decides which of the two remedies they want — re-code the scenario, or move it.
|
|
80
|
-
* And it is raised per offending scenario, never per file: a file may hold many scenarios of
|
|
81
|
-
* which one is wrong, and a finding naming the file alone convicts the rest of them.
|
|
82
|
-
*
|
|
83
|
-
* AN UNCODED FILE RAISES NOTHING, deliberately rather than by omission. A file carrying no
|
|
84
|
-
* header code has nothing for an id to be foreign TO. Whether that should red is a policy
|
|
85
|
-
* question about gradual adoption, filed as its own ticket (3F-3314) — and it is the same
|
|
86
|
-
* `null`-is-not-a-code line the duplicate rule draws, drawn once more here so the two cannot
|
|
87
|
-
* come to disagree about what an uncoded file is.
|
|
88
|
-
*
|
|
89
|
-
* AND A MALFORMED ID RAISES NOTHING EITHER, because something else already does. `featureCodeOf`
|
|
90
|
-
* is the ONE owner of the `SCN-<FFF>-<NNN>` grammar in this engine, and an id it cannot parse
|
|
91
|
-
* has no feature part to compare — that fault is `no-scn-code`, which a reconciliation raises
|
|
92
|
-
* and names by id. A second diagnostic here would print one fault's remedy at the other's author.
|
|
93
|
-
*
|
|
94
|
-
* The tag walk is `parseTaggedScenarios`, which inherits Feature- and Rule-level tags exactly as
|
|
95
|
-
* cucumber does. A hand-rolled scan of the tag lines is the second reading that walk was
|
|
96
|
-
* extracted to end, and it is what a rule ABOUT ids can least afford: an id hoisted to a `Rule:`
|
|
97
|
-
* belongs to every scenario beneath it, and a scan that missed that would pass over the file.
|
|
98
|
-
*/
|
|
99
|
-
export function foreignScenarioCodes(features) {
|
|
100
|
-
const faults = [];
|
|
101
|
-
for (const file of features) {
|
|
102
|
-
if (file.featureCode === null)
|
|
103
|
-
continue;
|
|
104
|
-
for (const scenario of parseTaggedScenarios(file.source)) {
|
|
105
|
-
const named = featureCodeOf(scenario.scnId);
|
|
106
|
-
if (named === null || named === file.featureCode)
|
|
107
|
-
continue;
|
|
108
|
-
faults.push({
|
|
109
|
-
kind: "foreign-scenario-code",
|
|
110
|
-
message: `foreign-scenario-code: ${file.slug}.feature carries the feature code ` +
|
|
111
|
-
`@${file.featureCode}, but holds the scenario @${scenario.scnId}, whose feature part ` +
|
|
112
|
-
`names ${named}. A scenario's code names the file it is written in: a ` +
|
|
113
|
-
`reconciliation's by-feature cut groups on the id, so this one opens a row for a ` +
|
|
114
|
-
`feature no file in the corpus carries and files the scenario under it. Re-code the ` +
|
|
115
|
-
`scenario for @${file.featureCode}, or move it to the file headed @${named}.`,
|
|
116
|
-
});
|
|
117
|
-
}
|
|
118
|
-
}
|
|
119
|
-
return faults;
|
|
120
|
-
}
|
|
121
|
-
//# sourceMappingURL=corpusCodeFaults.js.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"corpusCodeFaults.js","sourceRoot":"","sources":["../../src/parse/corpusCodeFaults.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH,OAAO,EAAE,aAAa,EAAE,MAAM,uBAAuB,CAAC;AAEtD,OAAO,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAC;AAEtD;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,qBAAqB,CAAC,QAA+B;IACnE,MAAM,WAAW,GAAG,IAAI,GAAG,EAAoB,CAAC;IAChD,KAAK,MAAM,IAAI,IAAI,QAAQ,EAAE,CAAC;QAC5B,IAAI,IAAI,CAAC,WAAW,KAAK,IAAI;YAAE,SAAS;QACxC,WAAW,CAAC,GAAG,CAAC,IAAI,CAAC,WAAW,EAAE;YAChC,GAAG,CAAC,WAAW,CAAC,GAAG,CAAC,IAAI,CAAC,WAAW,CAAC,IAAI,EAAE,CAAC;YAC5C,GAAG,IAAI,CAAC,IAAI,UAAU;SACvB,CAAC,CAAC;IACL,CAAC;IAED,MAAM,MAAM,GAAkB,EAAE,CAAC;IACjC,KAAK,MAAM,CAAC,IAAI,EAAE,KAAK,CAAC,IAAI,WAAW,EAAE,CAAC;QACxC,IAAI,KAAK,CAAC,MAAM,GAAG,CAAC;YAAE,SAAS;QAC/B,MAAM,CAAC,IAAI,CAAC;YACV,IAAI,EAAE,wBAAwB;YAC9B,OAAO,EACL,6CAA6C,IAAI,kBAAkB,KAAK,CAAC,MAAM,WAAW;gBAC1F,WAAW,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,qDAAqD;gBAChF,0FAA0F;gBAC1F,0FAA0F;SAC7F,CAAC,CAAC;IACL,CAAC;IACD,OAAO,MAAM,CAAC;AAChB,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,MAAM,UAAU,oBAAoB,CAAC,QAA+B;IAClE,MAAM,MAAM,GAAkB,EAAE,CAAC;IACjC,KAAK,MAAM,IAAI,IAAI,QAAQ,EAAE,CAAC;QAC5B,IAAI,IAAI,CAAC,WAAW,KAAK,IAAI;YAAE,SAAS;QACxC,KAAK,MAAM,QAAQ,IAAI,oBAAoB,CAAC,IAAI,CAAC,MAAM,CAAC,EAAE,CAAC;YACzD,MAAM,KAAK,GAAG,aAAa,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;YAC5C,IAAI,KAAK,KAAK,IAAI,IAAI,KAAK,KAAK,IAAI,CAAC,WAAW;gBAAE,SAAS;YAC3D,MAAM,CAAC,IAAI,CAAC;gBACV,IAAI,EAAE,uBAAuB;gBAC7B,OAAO,EACL,0BAA0B,IAAI,CAAC,IAAI,oCAAoC;oBACvE,IAAI,IAAI,CAAC,WAAW,6BAA6B,QAAQ,CAAC,KAAK,uBAAuB;oBACtF,SAAS,KAAK,yDAAyD;oBACvE,kFAAkF;oBAClF,qFAAqF;oBACrF,iBAAiB,IAAI,CAAC,WAAW,oCAAoC,KAAK,GAAG;aAChF,CAAC,CAAC;QACL,CAAC;IACH,CAAC;IACD,OAAO,MAAM,CAAC;AAChB,CAAC"}
|
|
@@ -1,124 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* THE `@SCN` SCHEME'S OWN RULES, asked of a target's Gherkin corpus — the rule half of
|
|
3
|
-
* `spec-controller tags`.
|
|
4
|
-
*
|
|
5
|
-
* WHY IT SHIPS AT ALL. The tool hands a consumer the `@SCN` scheme and then made them write
|
|
6
|
-
* the guards that keep it usable; 816 lines of exactly that sat in this repository's own check
|
|
7
|
-
* tree, published nowhere. An adopter got the codes and inherited none of the policing, so
|
|
8
|
-
* nobody's tags were policed but ours. These rules are the kind that CAN ship: every one of
|
|
9
|
-
* them reads a corpus the engine already parses, rather than needing to know what a piece of
|
|
10
|
-
* text IS.
|
|
11
|
-
*
|
|
12
|
-
* WHY IT IS IN CORE AND NOT AT THE CLI EDGE. It is `evidenceReconciliationFromSources`'s shape,
|
|
13
|
-
* taken deliberately rather than by analogy. The published CLI module may reach core only
|
|
14
|
-
* through the ROOT barrel — `./internal` is dropped by `publishConfig.exports` at pack time,
|
|
15
|
-
* which is how an installed `balance --help` once threw ERR_PACKAGE_PATH_NOT_EXPORTED behind
|
|
16
|
-
* thirteen green gates (3F-3086). So the CALLER lives on this side of the boundary and the app
|
|
17
|
-
* hands over bytes; nothing internal is re-exported to buy it.
|
|
18
|
-
*
|
|
19
|
-
* WHAT SEPARATES A FAULT FROM A VERDICT. `balance`'s exit code IS its verdict — balanced, out of
|
|
20
|
-
* balance, pending-under-strict, unsound, nothing-to-reconcile — and a corpus fault is not a
|
|
21
|
-
* reconciliation verdict. It
|
|
22
|
-
* is a statement that the corpus itself is malformed, which is why it is a second command with
|
|
23
|
-
* its own status ladder rather than a fourth meaning bolted onto a status a consumer's CI
|
|
24
|
-
* branches on.
|
|
25
|
-
*
|
|
26
|
-
* NOTHING HERE READS A FILE, AND NOTHING HERE RE-READS ONE. Every input arrives already read,
|
|
27
|
-
* for `evidenceReconciliationFromSources`'s reason: an engine handed a reader is an engine doing
|
|
28
|
-
* I/O wearing a callback, and `lint:boundaries`' `core-imports-io` rule reds over exactly that
|
|
29
|
-
* (@SCN-EPG-001's `io-import` arm until 3F-3437).
|
|
30
|
-
*
|
|
31
|
-
* WHAT IS LEFT IN THIS MODULE, AND WHAT MOVED OUT. The rules themselves live in two siblings —
|
|
32
|
-
* `corpusCodeFaults.ts` (a code binding to a file) and `corpusGrammarFaults.ts` (a tag meaning
|
|
33
|
-
* something) — because the joined module reached the 400-line `max-lines` ceiling, and canon rules
|
|
34
|
-
* that split rather than an exception entry (@SCN-FIT-001). A third sibling held the claim rule
|
|
35
|
-
* (how many checks one scenario claims) until it left with the measured axis (3F-3516). What
|
|
36
|
-
* stays here is the composition and the VOCABULARY: the fault kinds, the shape of a discovered
|
|
37
|
-
* file, and the one entry point any sibling has. Splitting on any other seam would have put a
|
|
38
|
-
* rule's inputs in one module and its finding's wording in another.
|
|
39
|
-
*/
|
|
40
|
-
import type { PackageJsonScripts } from "./checkScriptsRunInCI.js";
|
|
41
|
-
/**
|
|
42
|
-
* A target's manifest as these rules read it — its scripts, and its `specController` block.
|
|
43
|
-
*
|
|
44
|
-
* Spelled here rather than imported for the reason the reconcile composition spells its own:
|
|
45
|
-
* every field of it is `unknown` until a resolver narrows it, so the type is a statement about
|
|
46
|
-
* what a manifest on disk IS rather than a contract owed to anybody.
|
|
47
|
-
*/
|
|
48
|
-
export type TargetManifest = PackageJsonScripts & {
|
|
49
|
-
specController?: {
|
|
50
|
-
deferralTags?: unknown;
|
|
51
|
-
fitnessChecks?: unknown;
|
|
52
|
-
};
|
|
53
|
-
};
|
|
54
|
-
/**
|
|
55
|
-
* One way a corpus breaks the `@SCN` scheme's own rules.
|
|
56
|
-
*
|
|
57
|
-
* THREE KINDS, NOT ONE, because they are three faults with three different fixes — the same
|
|
58
|
-
* argument that split the tier-tag check's findings three ways. `duplicate-feature-code` says
|
|
59
|
-
* *give one of these files a code of its own*; `foreign-scenario-code` says *this id names a
|
|
60
|
-
* file it is not written in*; and `unrecognised-tag` says *this word means nothing here*. A
|
|
61
|
-
* fourth, `multiple-check-tags`, left with the measured axis (3F-3516). Collapsing any two would
|
|
62
|
-
* print one fault's remedy at the other's author, which is precisely how a mistyped tier tag
|
|
63
|
-
* stayed invisible for as long as it did.
|
|
64
|
-
*
|
|
65
|
-
* THE UNION IS THE COMMAND'S WHOLE VOCABULARY, and it is stated once here rather than grown a
|
|
66
|
-
* member at a time by whichever rule landed last. That is also why it stayed in this module when
|
|
67
|
-
* the rules left it: the two rule modules each raise a subset of these kinds, and a union
|
|
68
|
-
* assembled from both sides would be a statement about the command that no single file made. The
|
|
69
|
-
* two CODE rules have producers — `duplicate-feature-code` (@SCN-STG-010) and
|
|
70
|
-
* `foreign-scenario-code` (@SCN-STG-011); so does `unrecognised-tag` (@SCN-STG-002, and the
|
|
71
|
-
* clauses that narrow what it reaches at @SCN-STG-003, @SCN-STG-004 and @SCN-STG-005). Every
|
|
72
|
-
* member of the union is raised by a rule with a scenario of its own, which is the state the kinds
|
|
73
|
-
* were written down ahead of.
|
|
74
|
-
*/
|
|
75
|
-
export interface CorpusFault {
|
|
76
|
-
readonly kind: "unrecognised-tag" | "duplicate-feature-code" | "foreign-scenario-code";
|
|
77
|
-
readonly message: string;
|
|
78
|
-
}
|
|
79
|
-
/** One discovered feature file, as the edge read it. */
|
|
80
|
-
export interface CorpusFile {
|
|
81
|
-
/** The feature-file basename without the `.feature` extension. */
|
|
82
|
-
slug: string;
|
|
83
|
-
/**
|
|
84
|
-
* The file's `@<FFF>` header code, or null where it carries none.
|
|
85
|
-
*
|
|
86
|
-
* IT ARRIVES; IT IS NEVER RE-DERIVED HERE. The header is read by exactly one thing — the
|
|
87
|
-
* ingest edge's `extractFeatureCode` — and that is also the reading a reconciliation's
|
|
88
|
-
* *Out-of-balance by feature* cut groups on. A second reading inside this module would be free
|
|
89
|
-
* to disagree with the report about the very field these rules are ABOUT, and the check could
|
|
90
|
-
* then pass clean over a corpus whose report mis-attributes a scenario. So it is a parameter.
|
|
91
|
-
*/
|
|
92
|
-
featureCode: string | null;
|
|
93
|
-
/** The file's raw Gherkin source, read once at the edge. */
|
|
94
|
-
source: string;
|
|
95
|
-
}
|
|
96
|
-
/**
|
|
97
|
-
* Every way this corpus breaks the scheme, in a stable order.
|
|
98
|
-
*
|
|
99
|
-
* THE ONE ENTRY POINT, and the reason the rules' own modules are not on the barrel. A consumer's
|
|
100
|
-
* route to this capability is the CLI; a second route through an imported rule would be a second
|
|
101
|
-
* surface to freeze, and it would let the code rules and the grammar rules be run over two
|
|
102
|
-
* different readings of one corpus.
|
|
103
|
-
*
|
|
104
|
-
* @param input.features the target's discovered feature files — slug, header code and source,
|
|
105
|
-
* read ONCE at the edge so two discoveries can never disagree about which corpus was judged.
|
|
106
|
-
* @param input.packageJson the TARGET's manifest, from which the recognised deferral set is
|
|
107
|
-
* resolved INSIDE this engine — through the same resolver the reconciliation reads it with, so the
|
|
108
|
-
* rules here admit exactly what the reconciliation honours as a skip. READ SINCE 3F-3303, by the
|
|
109
|
-
* grammar rules and only by them: the deferral set (@SCN-PND-021) is resolved from it. The
|
|
110
|
-
* check-tag halves once read from it — the REGISTERED half (@SCN-STG-005) and the MEASURED half
|
|
111
|
-
* — are retired (3F-3161, 3F-3516). The code rules never see it, which is the seam the module
|
|
112
|
-
* split was drawn on.
|
|
113
|
-
* @param input.deferralTags the application layer's STARTER deferral set, which a target's
|
|
114
|
-
* config may only extend. Product policy, single-sourced there and never here — the same
|
|
115
|
-
* argument, and the same parameter, as the reconcile composition's. Read since 3F-3303, and
|
|
116
|
-
* handed onward unresolved: what turns it into the target's recognised set is
|
|
117
|
-
* `resolveDeferralTags`, called once beside the rule that asks the question.
|
|
118
|
-
*/
|
|
119
|
-
export declare function corpusFaults(input: {
|
|
120
|
-
features: readonly CorpusFile[];
|
|
121
|
-
packageJson: TargetManifest;
|
|
122
|
-
deferralTags: readonly string[];
|
|
123
|
-
}): CorpusFault[];
|
|
124
|
-
//# sourceMappingURL=corpusFaults.d.ts.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"corpusFaults.d.ts","sourceRoot":"","sources":["../../src/parse/corpusFaults.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AAEH,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,0BAA0B,CAAC;AAInE;;;;;;GAMG;AACH,MAAM,MAAM,cAAc,GAAG,kBAAkB,GAAG;IAChD,cAAc,CAAC,EAAE;QACf,YAAY,CAAC,EAAE,OAAO,CAAC;QACvB,aAAa,CAAC,EAAE,OAAO,CAAC;KACzB,CAAC;CACH,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,WAAW,WAAW;IAC1B,QAAQ,CAAC,IAAI,EACT,kBAAkB,GAClB,wBAAwB,GACxB,uBAAuB,CAAC;IAC5B,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;CAC1B;AAED,wDAAwD;AACxD,MAAM,WAAW,UAAU;IACzB,kEAAkE;IAClE,IAAI,EAAE,MAAM,CAAC;IACb;;;;;;;;OAQG;IACH,WAAW,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,4DAA4D;IAC5D,MAAM,EAAE,MAAM,CAAC;CAChB;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAgB,YAAY,CAAC,KAAK,EAAE;IAClC,QAAQ,EAAE,SAAS,UAAU,EAAE,CAAC;IAChC,WAAW,EAAE,cAAc,CAAC;IAC5B,YAAY,EAAE,SAAS,MAAM,EAAE,CAAC;CACjC,GAAG,WAAW,EAAE,CAMhB"}
|
|
@@ -1,72 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* THE `@SCN` SCHEME'S OWN RULES, asked of a target's Gherkin corpus — the rule half of
|
|
3
|
-
* `spec-controller tags`.
|
|
4
|
-
*
|
|
5
|
-
* WHY IT SHIPS AT ALL. The tool hands a consumer the `@SCN` scheme and then made them write
|
|
6
|
-
* the guards that keep it usable; 816 lines of exactly that sat in this repository's own check
|
|
7
|
-
* tree, published nowhere. An adopter got the codes and inherited none of the policing, so
|
|
8
|
-
* nobody's tags were policed but ours. These rules are the kind that CAN ship: every one of
|
|
9
|
-
* them reads a corpus the engine already parses, rather than needing to know what a piece of
|
|
10
|
-
* text IS.
|
|
11
|
-
*
|
|
12
|
-
* WHY IT IS IN CORE AND NOT AT THE CLI EDGE. It is `evidenceReconciliationFromSources`'s shape,
|
|
13
|
-
* taken deliberately rather than by analogy. The published CLI module may reach core only
|
|
14
|
-
* through the ROOT barrel — `./internal` is dropped by `publishConfig.exports` at pack time,
|
|
15
|
-
* which is how an installed `balance --help` once threw ERR_PACKAGE_PATH_NOT_EXPORTED behind
|
|
16
|
-
* thirteen green gates (3F-3086). So the CALLER lives on this side of the boundary and the app
|
|
17
|
-
* hands over bytes; nothing internal is re-exported to buy it.
|
|
18
|
-
*
|
|
19
|
-
* WHAT SEPARATES A FAULT FROM A VERDICT. `balance`'s exit code IS its verdict — balanced, out of
|
|
20
|
-
* balance, pending-under-strict, unsound, nothing-to-reconcile — and a corpus fault is not a
|
|
21
|
-
* reconciliation verdict. It
|
|
22
|
-
* is a statement that the corpus itself is malformed, which is why it is a second command with
|
|
23
|
-
* its own status ladder rather than a fourth meaning bolted onto a status a consumer's CI
|
|
24
|
-
* branches on.
|
|
25
|
-
*
|
|
26
|
-
* NOTHING HERE READS A FILE, AND NOTHING HERE RE-READS ONE. Every input arrives already read,
|
|
27
|
-
* for `evidenceReconciliationFromSources`'s reason: an engine handed a reader is an engine doing
|
|
28
|
-
* I/O wearing a callback, and `lint:boundaries`' `core-imports-io` rule reds over exactly that
|
|
29
|
-
* (@SCN-EPG-001's `io-import` arm until 3F-3437).
|
|
30
|
-
*
|
|
31
|
-
* WHAT IS LEFT IN THIS MODULE, AND WHAT MOVED OUT. The rules themselves live in two siblings —
|
|
32
|
-
* `corpusCodeFaults.ts` (a code binding to a file) and `corpusGrammarFaults.ts` (a tag meaning
|
|
33
|
-
* something) — because the joined module reached the 400-line `max-lines` ceiling, and canon rules
|
|
34
|
-
* that split rather than an exception entry (@SCN-FIT-001). A third sibling held the claim rule
|
|
35
|
-
* (how many checks one scenario claims) until it left with the measured axis (3F-3516). What
|
|
36
|
-
* stays here is the composition and the VOCABULARY: the fault kinds, the shape of a discovered
|
|
37
|
-
* file, and the one entry point any sibling has. Splitting on any other seam would have put a
|
|
38
|
-
* rule's inputs in one module and its finding's wording in another.
|
|
39
|
-
*/
|
|
40
|
-
import { duplicateFeatureCodes, foreignScenarioCodes } from "./corpusCodeFaults.js";
|
|
41
|
-
import { unrecognisedTags } from "./corpusGrammarFaults.js";
|
|
42
|
-
/**
|
|
43
|
-
* Every way this corpus breaks the scheme, in a stable order.
|
|
44
|
-
*
|
|
45
|
-
* THE ONE ENTRY POINT, and the reason the rules' own modules are not on the barrel. A consumer's
|
|
46
|
-
* route to this capability is the CLI; a second route through an imported rule would be a second
|
|
47
|
-
* surface to freeze, and it would let the code rules and the grammar rules be run over two
|
|
48
|
-
* different readings of one corpus.
|
|
49
|
-
*
|
|
50
|
-
* @param input.features the target's discovered feature files — slug, header code and source,
|
|
51
|
-
* read ONCE at the edge so two discoveries can never disagree about which corpus was judged.
|
|
52
|
-
* @param input.packageJson the TARGET's manifest, from which the recognised deferral set is
|
|
53
|
-
* resolved INSIDE this engine — through the same resolver the reconciliation reads it with, so the
|
|
54
|
-
* rules here admit exactly what the reconciliation honours as a skip. READ SINCE 3F-3303, by the
|
|
55
|
-
* grammar rules and only by them: the deferral set (@SCN-PND-021) is resolved from it. The
|
|
56
|
-
* check-tag halves once read from it — the REGISTERED half (@SCN-STG-005) and the MEASURED half
|
|
57
|
-
* — are retired (3F-3161, 3F-3516). The code rules never see it, which is the seam the module
|
|
58
|
-
* split was drawn on.
|
|
59
|
-
* @param input.deferralTags the application layer's STARTER deferral set, which a target's
|
|
60
|
-
* config may only extend. Product policy, single-sourced there and never here — the same
|
|
61
|
-
* argument, and the same parameter, as the reconcile composition's. Read since 3F-3303, and
|
|
62
|
-
* handed onward unresolved: what turns it into the target's recognised set is
|
|
63
|
-
* `resolveDeferralTags`, called once beside the rule that asks the question.
|
|
64
|
-
*/
|
|
65
|
-
export function corpusFaults(input) {
|
|
66
|
-
return [
|
|
67
|
-
...duplicateFeatureCodes(input.features),
|
|
68
|
-
...foreignScenarioCodes(input.features),
|
|
69
|
-
...unrecognisedTags(input.features, input.packageJson, input.deferralTags),
|
|
70
|
-
];
|
|
71
|
-
}
|
|
72
|
-
//# sourceMappingURL=corpusFaults.js.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"corpusFaults.js","sourceRoot":"","sources":["../../src/parse/corpusFaults.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AAGH,OAAO,EAAE,qBAAqB,EAAE,oBAAoB,EAAE,MAAM,uBAAuB,CAAC;AACpF,OAAO,EAAE,gBAAgB,EAAE,MAAM,0BAA0B,CAAC;AA+D5D;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,MAAM,UAAU,YAAY,CAAC,KAI5B;IACC,OAAO;QACL,GAAG,qBAAqB,CAAC,KAAK,CAAC,QAAQ,CAAC;QACxC,GAAG,oBAAoB,CAAC,KAAK,CAAC,QAAQ,CAAC;QACvC,GAAG,gBAAgB,CAAC,KAAK,CAAC,QAAQ,EAAE,KAAK,CAAC,WAAW,EAAE,KAAK,CAAC,YAAY,CAAC;KAC3E,CAAC;AACJ,CAAC"}
|
|
@@ -1,71 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* THE GRAMMAR RULES of `spec-controller tags` — everything about whether a TAG on a scenario
|
|
3
|
-
* means anything. Its sibling holds the other question: `corpusCodeFaults.ts` whether a feature
|
|
4
|
-
* code binds to one feature file. `corpusFaults.ts` composes the two and is the only entry point
|
|
5
|
-
* either of them has.
|
|
6
|
-
*
|
|
7
|
-
* THE SEAM, STATED FROM THIS SIDE. A grammar rule asks *is this word part of the `@SCN` scheme*,
|
|
8
|
-
* and the answer is assembled from places that are not this module's: the engine's own
|
|
9
|
-
* quality-check maps, the `SCN-<FFF>-<NNN>` spelling `featureCodeOf` owns, and the target's own
|
|
10
|
-
* manifest. A code rule needs none of those; it reads the corpus's shape. Two questions, two
|
|
11
|
-
* modules; the split happened when the joined module reached the 400-line `max-lines` ceiling
|
|
12
|
-
* with four more grammar clauses still to land (@SCN-FIT-001, and never an exception entry). The
|
|
13
|
-
* claim rule that once made a third sibling left with the measured axis (3F-3516): once the axis
|
|
14
|
-
* word is the only word that names a check, no scenario can claim two.
|
|
15
|
-
*
|
|
16
|
-
* AND THE TARGET'S HALF IS RESOLVED HERE, NOT HANDED IN RESOLVED. The composition hands this
|
|
17
|
-
* module a manifest rather than an answer, so the read lives beside the rule that uses it — the
|
|
18
|
-
* arrangement the parent's Design settled for the check-tag union and applied here first, because
|
|
19
|
-
* the whole reason the floor and the obligation rule once disagreed about a set was that each
|
|
20
|
-
* assembled its own. The composition passes bytes and policy; what a word MEANS is decided in one
|
|
21
|
-
* place.
|
|
22
|
-
*
|
|
23
|
-
* NOTHING HERE IS RESTATED. The recognised set is the whole subject of this module, and every
|
|
24
|
-
* member of it is DERIVED from the place that already owns it — a list written out here would
|
|
25
|
-
* agree with its source by diligence and then drift, and the check that then reds is the one
|
|
26
|
-
* telling authors which words are legitimate.
|
|
27
|
-
*/
|
|
28
|
-
import type { CorpusFault, CorpusFile, TargetManifest } from "./corpusFaults.js";
|
|
29
|
-
/**
|
|
30
|
-
* A tag on an `@SCN` scenario that means nothing here (@SCN-STG-002, @SCN-STG-003, @SCN-STG-004).
|
|
31
|
-
*
|
|
32
|
-
* ONE VERDICT, AND THE DIAGNOSIS IS SEPARATE FROM IT. Whether a tag is grammar is decided by
|
|
33
|
-
* `isGrammar` alone; what the message then SAYS about it is `unrecognisedTagFault`'s. Keeping the
|
|
34
|
-
* two apart is what lets the group-prefixed reading be as broad as it is (@SCN-STG-004) without
|
|
35
|
-
* ever widening or narrowing what reds.
|
|
36
|
-
*
|
|
37
|
-
* THE TYPO THE REST OF THE MODEL CANNOT SEE, measured rather than argued. `@untit` ALONE
|
|
38
|
-
* reconciles both-missing, so half of this fault a reconciliation does cover. Planted beside a
|
|
39
|
-
* real tier — `@unit @untit` — the only reconciling item is the absent unit Evidence Observation:
|
|
40
|
-
* the typo contributes nothing and is named nowhere, in any cell, at any exit status.
|
|
41
|
-
*
|
|
42
|
-
* PER TAG, NOT PER SCENARIO, because two junk tags are two things to fix and a finding naming one
|
|
43
|
-
* of them leaves the author to re-run the command to discover the other.
|
|
44
|
-
*
|
|
45
|
-
* ONLY `@SCN` SCENARIOS ARE ASKED, which comes free from `parseTaggedScenarios` — it yields
|
|
46
|
-
* nothing for a scenario carrying no id. That is the same scope the tier floor drew and it is
|
|
47
|
-
* drawn for the same reason: a corpus mid-adoption has scenarios the scheme has not reached yet,
|
|
48
|
-
* and policing their tag lines would make adopting the scheme a whole-corpus edit.
|
|
49
|
-
*
|
|
50
|
-
* AND A PARKED SCENARIO IS ASKED TOO (@SCN-STG-003). There is no clause anywhere below that
|
|
51
|
-
* excuses a scenario for carrying a deferral tag, and that absence is the discipline rather than
|
|
52
|
-
* an oversight: parking defers what a scenario OWES, never whether its tags are spelled right.
|
|
53
|
-
* This very set is what lets the walk recognise the parking tag, so excusing the walk on a parked
|
|
54
|
-
* scenario would hide `@wip @untit` — a check whose teeth come off by writing one more tag. The
|
|
55
|
-
* resolve happens once, before the walk, for that reason as much as for the cost.
|
|
56
|
-
*
|
|
57
|
-
* @param features the target's discovered feature files, read once at the edge.
|
|
58
|
-
* @param packageJson the TARGET's manifest, read HERE through the same resolvers the ingest edge
|
|
59
|
-
* reads it with — one reading of `specController.deferralTags` (@SCN-PND-021), so the words this
|
|
60
|
-
* rule calls legitimate are exactly the words the engine beside it honours as a skip.
|
|
61
|
-
* The target's own check registry is retired and read nowhere in this assembly (@SCN-STG-005,
|
|
62
|
-
* 3F-3161). A set handed in already resolved would have been a second answer travelling under the
|
|
63
|
-
* first's name.
|
|
64
|
-
* @param starterDeferralTags the APPLICATION layer's starter set, which a target's config may only
|
|
65
|
-
* extend and never replace. It is a parameter because it is product policy — an evolvable list of
|
|
66
|
-
* strings — and a copy held in core would be a second statement of it. Pass none and this clause
|
|
67
|
-
* recognises nothing it was not given, which is the difference between owning a policy and
|
|
68
|
-
* hard-coding someone else's.
|
|
69
|
-
*/
|
|
70
|
-
export declare function unrecognisedTags(features: readonly CorpusFile[], packageJson: TargetManifest, starterDeferralTags: readonly string[]): CorpusFault[];
|
|
71
|
-
//# sourceMappingURL=corpusGrammarFaults.d.ts.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"corpusGrammarFaults.d.ts","sourceRoot":"","sources":["../../src/parse/corpusGrammarFaults.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAGH,OAAO,KAAK,EAAE,WAAW,EAAE,UAAU,EAAE,cAAc,EAAE,MAAM,mBAAmB,CAAC;AA2NjF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AACH,wBAAgB,gBAAgB,CAC9B,QAAQ,EAAE,SAAS,UAAU,EAAE,EAC/B,WAAW,EAAE,cAAc,EAC3B,mBAAmB,EAAE,SAAS,MAAM,EAAE,GACrC,WAAW,EAAE,CAqBf"}
|