@hominis/fireforge 0.46.0 → 0.46.2

package/dist/src/core/test-harness-crash.js

@@ -9,16 +9,16 @@
  *  - startup crashes from the mozlog resource monitor on macOS
  *    (`AttributeError: 'SystemResourceMonitor' object has no attribute
  *    'poll_interval'`, `host_statistics64(HOST_VM_INFO64) syscall failed`,
- *    `(ipc/mig) array not large enough` — a psutil/macOS mismatch) which
- *    abort the run before any test executes;
+ *    `(ipc/mig) array not large enough`, a psutil/macOS mismatch) which
+ *    abort the run before any test executes.
  *  - hangs after browser startup that die at the no-output timeout yet still
- *    emit a `Passed: 0` summary;
+ *    emit a `Passed: 0` summary.
  *  - post-green shutdown re-entry, where a fully green run stalls on "must
  *    wait for focus" and records "Application shut down (without crashing)
  *    in the middle of a test!" as the only unexpected failure.
  *
- * Classification therefore keys on `TEST-START` presence — summary lines
- * never count as proof that tests ran — and recognizes the crash shapes
+ * Classification therefore keys on `TEST-START` presence, so summary lines
+ * never count as proof that tests ran, and recognizes the crash shapes
  * above so the command layer can retry them with a bounded budget instead of
  * reporting phantom test failures (or phantom passes).
  */
@@ -40,7 +40,7 @@ const GREEN_UNEXPECTED_SUMMARY_PATTERN = /\bUnexpected results:\s*0\b/;
 const NONZERO_UNEXPECTED_SUMMARY_PATTERN = /\bUnexpected results:\s*[1-9]/;
 /**
  * Execution signals emitted by the suite-specific xpcshell dispatch
- * (`mach xpcshell-test`), which does NOT print `TEST-START` lines the way
+ * (`mach xpcshell-test`), which does not print `TEST-START` lines the way
  * the generic `mach test` / browser-chrome dispatch does. A passing
  * single-file xpcshell run prints a result-summary block instead
  * (`TEST_END: Test PASS`, `Ran 16 checks`, `Unexpected results: 0`), so
@@ -49,16 +49,16 @@ const NONZERO_UNEXPECTED_SUMMARY_PATTERN = /\bUnexpected results:\s*[1-9]/;
  *
  * These markers are xpcshell-specific on purpose: the bare `Passed: 0` /
  * `Failed: 0` summary that the no-output hang shape prints is deliberately
- * NOT matched here — that case must still read as `no-tests`.
+ * not matched here, because that case must still read as `no-tests`.
  */
 const XPCSHELL_RESULT_SUMMARY_PATTERN = /\bTEST_END\b|\bRan \d+ checks?\b|\bResult summary:/i;
 const UNEXPECTED_LINE_PATTERN = /^.*\bTEST-UNEXPECTED-[A-Z-]+\b.*$/gm;
 /**
- * A `FAIL` token that is HARNESS-SHAPED. Deliberately not a bare `\bFAIL\b`
+ * A `FAIL` token that is harness-shaped. Not a bare `\bFAIL\b`
  * word match: that matched any output line containing the ordinary English
  * word, so a test's own passing diagnostic could manufacture a red run (see
- * {@link realUnexpectedFailureLines}). It also matched `TEST-KNOWN-FAIL` —
- * an EXPECTED failure — and counted it as a real one.
+ * {@link realUnexpectedFailureLines}). It also matched `TEST-KNOWN-FAIL`,
+ * an expected failure, and counted it as a real one.
  *
  * The `TEST-` prefix is what makes the token the harness's rather than
  * prose, and the negative lookahead is what keeps a known-fail annotation
@@ -67,11 +67,11 @@ const UNEXPECTED_LINE_PATTERN = /^.*\bTEST-UNEXPECTED-[A-Z-]+\b.*$/gm;
 const FAIL_LINE_PATTERN = /^.*\bTEST-(?!KNOWN-FAIL\b)[A-Z-]*FAIL\b.*$/gm;
 /**
  * The three concrete shapes Gecko prints for a real assertion failure.
- * Case-SENSITIVE and punctuation-anchored on purpose: the previous
+ * Case-sensitive and punctuation-anchored on purpose: the previous
  * `/\b(?:Assertion failure|MOZ_ASSERT|ASSERTION)\b/gim` was
  * case-insensitive, so the ordinary English word "assertion" in a passing
  * diagnostic ("If an assertion below times out, this is why") was read as
- * a failure — and the verdict then named that diagnostic as the first real
+ * a failure, and the verdict then named that diagnostic as the first real
  * test failure, pointing the reader at the wrong line.
  */
 const ASSERTION_LINE_PATTERN = /^.*(?:Assertion failure:|MOZ_ASSERT\(|###!!! ASSERTION).*$/gm;
@@ -81,7 +81,7 @@ const TRACEBACK_PATTERN = /Traceback \(most recent call last\)/;
 const NO_OUTPUT_TIMEOUT_PATTERN = /timed out after \d+ seconds with no output/i;
 /**
  * Crash-marker lines mozcrash / the mochitest harness print when the browser
- * process itself died. Matched against the RAW output (never noise-stripped):
+ * process itself died. Matched against the raw output (never noise-stripped):
  * any of these proves the run was truncated by a crash, so an embedded green
  * summary is under-reporting, not a result. `Main app process: killed by
  * SIGSEGV` at the second of eight files with a `Passed: 2 / Failed: 0`
@@ -103,10 +103,10 @@ const CRASH_MARKER_PATTERNS = [
  */
 // A `_DegradedReading` fallback that is not a real namedtuple duck type
 // crashes mozsystemmonitor on the fallback itself (`_build_meta` subscripts
-// the reading; `_collect` unpacks it); a startup abort with zero TEST-START
+// the reading, `_collect` unpacks it). A startup abort with zero TEST-START
 // lines from this family is a crash, not a test failure. The `_collect
-// failed` variant is caught-and-logged, so it carries no Traceback header —
-// it gets its own zero-TEST-START check in `detectHarnessCrashSignature`
+// failed` variant is caught-and-logged, so it carries no Traceback header.
+// It gets its own zero-TEST-START check in `detectHarnessCrashSignature`
 // besides joining the traceback cluster.
 const DEGRADED_READING_CRASH_SIGNALS = [
     /'_DegradedReading' object is not subscriptable/,
@@ -123,7 +123,7 @@ const STARTUP_TRACEBACK_SIGNALS = [
     // On a degraded host every collector sample is rejected, aggregation has
     // nothing, and mozbuild's log_resource_usage dies on
     // usage["io"].read_bytes AFTER a fully successful compile ("Error running
-    // mach" with complete artifacts). Environmental, not a build regression —
+    // mach" with complete artifacts). Environmental, not a build regression:
     // the protected build retries it, since an incremental retry is cheap and
     // the guard keeps the retry green.
     /AttributeError: 'NoneType' object has no attribute 'read_bytes'/,
@@ -165,8 +165,8 @@ const BENIGN_TRACEBACK_CONTEXT = /telemetry|glean/i;
  * Strips non-signal noise from captured output before crash-signature
  * matching: resource-monitor degradation warnings, and traceback blocks
  * that mach caught itself (telemetry submission tracebacks are printed but
- * never abort the run). The stripped text is used ONLY as crash evidence —
- * classification of test results still reads the full output.
+ * never abort the run). The stripped text is used only as crash evidence.
+ * Classification of test results still reads the full output.
  */
 export function stripNonSignalNoise(output) {
     const lines = output.split(/\r?\n/);
@@ -219,9 +219,9 @@ export function findCrashMarkerLine(output) {
 /**
  * True when the summary lines LOOK green: execution signal, `Unexpected
  * results: 0` with no non-zero count, `SUITE_END`, no real
- * `TEST-UNEXPECTED-*` lines. Deliberately blind to crash/truncation
- * evidence — {@link hasCompletedGreenSummary} layers that on top, and
- * {@link classifyHarnessRun} needs the distinction to report WHY a
+ * `TEST-UNEXPECTED-*` lines. Blind to crash/truncation
+ * evidence: {@link hasCompletedGreenSummary} layers that on top, and
+ * {@link classifyHarnessRun} needs the distinction to report why a
  * green-shaped summary was rejected.
  */
 function hasGreenShapedSummary(output) {
@@ -232,15 +232,15 @@ function hasGreenShapedSummary(output) {
         realUnexpectedFailureLines(output).length === 0);
 }
 /**
- * True when the output embeds a COMPLETED, GREEN suite summary: an execution
+ * True when the output embeds a completed, green suite summary: an execution
  * signal, `Unexpected results: 0` (and no non-zero unexpected count), a
- * `SUITE_END` marker, no real `TEST-UNEXPECTED-*` lines — and NO crash
+ * `SUITE_END` marker, no real `TEST-UNEXPECTED-*` lines, and no crash
  * marker. Such a run finished its suite, so any startup-traceback-shaped
- * noise in the same output is by definition non-fatal and this vetoes
- * signature-based crash classification; without the veto, fully green
+ * noise in the same output is non-fatal and this vetoes
+ * signature-based crash classification. Without the veto, fully green
  * sharded runs report `CRASH (N attempts)` because degradation warnings
- * match the psutil signals. A summary printed after a crash marker is NOT
- * "completed" — it only covers the files that ran before the crash.
+ * match the psutil signals. A summary printed after a crash marker is not
+ * "completed": it only covers the files that ran before the crash.
  * Exported for direct unit testing.
  */
 export function hasCompletedGreenSummary(output) {
@@ -252,7 +252,7 @@ const TEST_FILE_BASENAME_PATTERN = /^(?:browser|test)_.*\.m?js$/;
  * Start/end execution markers, both log dialects: the structured mozlog
  * `TEST_START`/`TEST_END` pair and the human browser-chrome
  * `TEST-START`/`TEST-OK` pair. `TEST-UNEXPECTED-*` end shapes are
- * irrelevant here — any such line already fails the green-summary check
+ * irrelevant here, since any such line already fails the green-summary check
  * before completeness is consulted.
  */
 const START_MARKER_PATTERN = /\bTEST[-_]START\b[:| ]*\s*(\S+)?/;
@@ -262,11 +262,11 @@ const END_MARKER_PATTERN = /\bTEST[-_]END\b|\bTEST-OK\b/;
  * requested file must produce a start marker, and every started test must
  * produce an end marker (the harness emits both even for failing files).
  *
- * Ends are paired with starts POSITIONALLY (last open start is closed by
- * the next end), not by filename — the xpcshell dialect's `TEST_END: Test
+ * Ends are paired with starts positionally (last open start is closed by
+ * the next end), not by filename: the xpcshell dialect's `TEST_END: Test
  * PASS` lines do not name the file. Requested paths that are not
  * test-file-shaped (directories, manifests) are skipped for the
- * never-started check; the start/end pairing scan covers them regardless.
+ * never-started check. The start/end pairing scan covers them regardless.
  * Exported for direct unit testing.
  */
 export function analyzeTestCompleteness(output, requestedPaths) {
@@ -302,7 +302,7 @@ export function analyzeTestCompleteness(output, requestedPaths) {
 function hasXpcshellResultSummary(output) {
     return XPCSHELL_RESULT_SUMMARY_PATTERN.test(output);
 }
-/** Unexpected-failure lines that are NOT the shutdown re-entry artifact. */
+/** Unexpected-failure lines that are not the shutdown re-entry artifact. */
 function realUnexpectedFailureLines(output) {
     const matches = [
         ...(output.match(UNEXPECTED_LINE_PATTERN) ?? []),
@@ -319,8 +319,8 @@ function realUnexpectedFailureLines(output) {
     return [...new Set(matches.map((line) => line.trim()))].filter((line) => !SHUTDOWN_REENTRY_PATTERN.test(line));
 }
 /**
- * Non-global copies of the unexpected/assertion patterns for per-line use —
- * the `g`-flagged module patterns carry `lastIndex` state across `.test()`
+ * Non-global copies of the unexpected/assertion patterns for per-line use.
+ * The `g`-flagged module patterns carry `lastIndex` state across `.test()`
  * calls and must never be reused line-by-line.
  */
 const UNEXPECTED_LINE_SINGLE = /\bTEST-UNEXPECTED-[A-Z-]+\b/;
@@ -338,7 +338,7 @@ const FAILURE_BLOCK_CONTEXT_LIMIT = 6;
  * assertion/diff context, one string per block. The shutdown-reentry
  * artifact is excluded (it is harness noise, not a test result). When more
  * than `limit` blocks exist, a final `…(+N more …)` note is appended so the
- * operator knows the echo was truncated. Pure; exported for unit tests.
+ * operator knows the echo was truncated. Pure. Exported for unit tests.
  */
 export function collectUnexpectedFailureBlocks(output, limit = 5) {
     const lines = output.split(/\r?\n/);
@@ -404,7 +404,7 @@ export function detectHarnessCrashSignature(output) {
     // A completed green embedded summary vetoes signature-based crash
     // classification outright: the suite finished, so any startup-shaped
     // noise in the same output was non-fatal. (The post-green shutdown
-    // re-entry shape below is exempt — it is deliberately a crash verdict on
+    // re-entry shape below is exempt: it is a crash verdict on
     // an otherwise-green log, keyed on its own explicit markers.)
     const greenSummaryVeto = hasCompletedGreenSummary(output);
     // Startup traceback cluster (resource monitor / psutil), scanned over
@@ -443,7 +443,7 @@ export function detectHarnessCrashSignature(output) {
     }
     // Post-green shutdown re-entry: every unexpected line is the
     // shutdown-mid-test artifact, the run stalled on focus, and at least one
-    // such artifact exists — an otherwise green log.
+    // such artifact exists, on an otherwise green log.
     const shutdownLine = findLine(output, [SHUTDOWN_REENTRY_PATTERN]);
     if (shutdownLine && realFailures.length === 0 && FOCUS_STALL_PATTERN.test(output)) {
         return { reason: 'post-green shutdown re-entry during harness teardown', line: shutdownLine };
@@ -454,20 +454,20 @@ export function detectHarnessCrashSignature(output) {
  * Classifies a completed harness run. The decision tree, in order:
  *
  * 1. A recognized crash signature wins regardless of exit code (the
- *    shutdown re-entry shape exits non-zero on an otherwise green run;
- *    the hang shape can even exit zero with a `Passed: 0` summary).
- * 2. No execution signal with explicit paths requested means no test ran —
+ *    shutdown re-entry shape exits non-zero on an otherwise green run,
+ *    and the hang shape can even exit zero with a `Passed: 0` summary).
+ * 2. No execution signal with explicit paths requested means no test ran:
  *    `no-tests`, even when the exit code is zero. The execution signal is
  *    a `TEST-START` line (generic `mach test` / browser-chrome dispatch)
- *    OR the suite-specific xpcshell result-summary block (the xpcshell
+ *    or the suite-specific xpcshell result-summary block (the xpcshell
  *    dispatch prints no `TEST-START`). Bare `Passed:`/`Failed:` summary
  *    lines are still not trusted as evidence of execution.
- * 3. Exit code zero with tests started is a pass; anything else is a
- *    test failure for the regular diagnosis chain — except a non-zero
- *    exit whose embedded summary completed green AND shows no crash
+ * 3. Exit code zero with tests started is a pass. Anything else is a
+ *    test failure for the regular diagnosis chain, except a non-zero
+ *    exit whose embedded summary completed green and shows no crash
  *    marker and no truncated/never-started requested file, which is a
  *    pass with a `greenSummaryOverride` note (harness noise owns the
- *    exit code). A green-shaped summary WITH such evidence is rejected
+ *    exit code). A green-shaped summary with such evidence is rejected
  *    (`greenSummaryRejected`) and fails.
  */
 export function classifyHarnessRun(exitCode, output, requestedPaths) {
@@ -476,10 +476,10 @@ export function classifyHarnessRun(exitCode, output, requestedPaths) {
     const firstRealFailure = realFailures[0];
     const failureBlocks = collectUnexpectedFailureBlocks(output);
     const secondaryHarnessSignature = firstRealFailure !== undefined ? detectSecondaryHarnessNoise(output) : undefined;
-    // Checked BEFORE signature detection: a suite that ran clean and then died
-    // in KNOWN upstream teardown noise is a PASS, not a crash. The teardown
+    // Checked before signature detection: a suite that ran clean and then died
+    // in known upstream teardown noise is a pass, not a crash. The teardown
     // traceback matches the startup-traceback cluster, and the green-summary
-    // veto over that cluster requires a `SUITE_END` marker — which this very
+    // veto over that cluster requires a `SUITE_END` marker, which this very
     // traceback is what prevents from printing. Without this check a
     // substantively green suite (`Ran N checks` / `Unexpected results: 0`, no
     // unexpected lines) reports CRASH, indistinguishable at the summary level
@@ -558,17 +558,17 @@ export function classifyHarnessRun(exitCode, output, requestedPaths) {
  * unexplained residue is the recognized mozsystemmonitor teardown
  * traceback.
  *
- * Requires, all of them: tests actually executed; the summary printed
- * `Ran N checks` with an explicit `Unexpected results: 0`; no non-zero
- * unexpected count anywhere; no real `TEST-UNEXPECTED-*`/assertion line;
- * no crash marker; every requested test file both started and ended; and
+ * Requires, all of them: tests actually executed, the summary printed
+ * `Ran N checks` with an explicit `Unexpected results: 0`, no non-zero
+ * unexpected count anywhere, no real `TEST-UNEXPECTED-*`/assertion line,
+ * no crash marker, every requested test file both started and ended, and
  * the recognized teardown traceback is present. Anything short of that
- * falls through to the normal (failing) chain — with the failing condition
- * NAMED, so the next occurrence is a filed bug rather than another
+ * falls through to the normal (failing) chain, with the failing condition
+ * named, so the next occurrence is a filed bug rather than another
  * undiagnosable re-run.
  *
- * The conditions are evaluated in a fixed order and the FIRST failing one
- * is reported; a run can violate several, and reporting one deterministic
+ * The conditions are evaluated in a fixed order and the first failing one
+ * is reported. A run can violate several, and reporting one deterministic
  * condition beats an unordered list of everything that happened to be true.
  */
 function evaluateGreenTeardownOverride(output, counts, realFailures, requestedPaths) {
@@ -601,7 +601,7 @@ function evaluateGreenTeardownOverride(output, counts, realFailures, requestedPa
     if (crashLine !== undefined)
         return reject(`crash marker present: ${truncateEvidence(crashLine)}`);
     // The post-green shutdown re-entry shape is deliberately a crash verdict
-    // on an otherwise-green log; it must not be swept up here.
+    // on an otherwise-green log. It must not be swept up here.
     if (SHUTDOWN_REENTRY_PATTERN.test(output)) {
         return reject('post-green shutdown re-entry shape present');
     }
@@ -616,8 +616,8 @@ function evaluateGreenTeardownOverride(output, counts, realFailures, requestedPa
 }
 /**
  * Parses the numeric counts from the harness's embedded result summary
- * (`Ran N checks` / `Unexpected results: N`). The LAST occurrence of each
- * wins — a multi-suite run prints one summary per suite and the final one
+ * (`Ran N checks` / `Unexpected results: N`). The last occurrence of each
+ * wins: a multi-suite run prints one summary per suite and the final one
  * covers the aggregate the operator sees. Absent counts are omitted (the
  * `FIREFORGE-VERDICT:` contract: an absent key means "summary did not
  * print it", never zero).
@@ -642,9 +642,9 @@ function lastCapturedCount(output, pattern) {
     return last;
 }
 /**
- * Formats the machine-readable `FIREFORGE-VERDICT:` line — the stable,
+ * Formats the machine-readable `FIREFORGE-VERDICT:` line: the stable,
  * greppable last line every `fireforge test` run prints so harness-verdict
- * consumers stop regexing mach internals. The status follows THIS
+ * consumers stop regexing mach internals. The status follows this
  * classifier, never the raw exit code: a crash-classified run says
  * `FAIL reason=crash` even at exit 0, and a green-summary-override pass
  * says `PASS` despite a non-zero mach exit. Count keys are omitted when
@@ -716,18 +716,18 @@ const SIGSEGV_EXIT_CODES = new Set([-11, 139]);
  * `xpcshell return code: -11` with zero output is the signature of an
  * `.sys.mjs` that a packaged module imports but whose `EXTRA_JS_MODULES`
  * registration never landed: the module loader faults before any logging
- * exists, so there is no import error, no stack, no test output — just a
+ * exists, so there is no import error, no stack, no test output, just a
  * dead process. It is indistinguishable from a genuine product crash
  * unless someone names the cause.
  *
- * "Produced no evidence" is deliberately semantic rather than a byte
+ * "Produced no evidence" is semantic rather than a byte
  * budget: no execution signal, no real failure line, and no mozcrash
  * marker. A run that got far enough to start a test, report a failure, or
  * leave a crash dump has evidence of its own, and the regular diagnosis
- * chain reads it — this branch is only for the case where there is
+ * chain reads it. This branch is only for the case where there is
  * nothing else to say.
  *
- * Pure; exported for direct unit testing.
+ * Pure. Exported for direct unit testing.
  *
  * @param exitCode - The harness process exit code
  * @param output - Combined stdout/stderr from the run
@@ -767,7 +767,7 @@ export function buildSilentSegfaultMessage(exitCode, requestedPaths) {
 }
 /**
  * Builds the message for a run that produced no `TEST-START` despite
- * requesting paths — including exit-code-zero runs whose `Passed: 0`
+ * requesting paths, including exit-code-zero runs whose `Passed: 0`
  * summary would otherwise read as a silent false green.
  */
 export function buildNoTestsRanMessage(exitCode, requestedPaths) {

package/dist/src/core/test-harness-output.d.ts

@@ -11,20 +11,20 @@ export interface PostRebuildFailureContext {
 /**
  * Finds the first high-signal failure line from captured mach test output.
  *
- * Selection is FIRST-MATCHING-LINE, not first-matching-pattern, so the bare
- * `AttributeError:` arm above has exactly the same standing as
- * `TEST-UNEXPECTED-FAIL` — whichever appears earlier in the text wins. That
+ * Selection is by first matching line, not by first matching pattern, so the
+ * bare `AttributeError:` arm above has exactly the same standing as
+ * `TEST-UNEXPECTED-FAIL`: whichever appears earlier in the text wins. That
  * is how a run whose real defect was an export shard's file-count assertion
- * got diagnosed as the recognized mozsystemmonitor teardown crash: the
- * information was present and the SELECTION was wrong, which is the
+ * got diagnosed as the recognized mozsystemmonitor teardown crash. The
+ * information was present and the selection was wrong, which is the
  * expensive kind of wrong, because the named cause is a real, documented,
  * unrelated upstream defect and therefore reads as an answer.
  *
  * So a capture carrying the recognized teardown incident gets two passes:
  * candidates excluding its `AttributeError` header first, and only if that
  * finds nothing does the full set apply. The narrowness the rest of the
- * codebase maintains is preserved exactly — the exclusion is gated on
- * `hasKnownTeardownNoise` for the WHOLE capture, so it requires both the
+ * codebase maintains is preserved exactly: the exclusion is gated on
+ * `hasKnownTeardownNoise` for the whole capture, so it requires both the
  * closed attribute allowlist and a `resourcemonitor.py` frame. A novel
  * attribute, or a traceback from anywhere else, stays a real failure and is
  * still eligible to be reported.

package/dist/src/core/test-harness-output.js

@@ -26,20 +26,20 @@ const FAILURE_LINE_PATTERNS = [
 /**
  * Finds the first high-signal failure line from captured mach test output.
  *
- * Selection is FIRST-MATCHING-LINE, not first-matching-pattern, so the bare
- * `AttributeError:` arm above has exactly the same standing as
- * `TEST-UNEXPECTED-FAIL` — whichever appears earlier in the text wins. That
+ * Selection is by first matching line, not by first matching pattern, so the
+ * bare `AttributeError:` arm above has exactly the same standing as
+ * `TEST-UNEXPECTED-FAIL`: whichever appears earlier in the text wins. That
  * is how a run whose real defect was an export shard's file-count assertion
- * got diagnosed as the recognized mozsystemmonitor teardown crash: the
- * information was present and the SELECTION was wrong, which is the
+ * got diagnosed as the recognized mozsystemmonitor teardown crash. The
+ * information was present and the selection was wrong, which is the
  * expensive kind of wrong, because the named cause is a real, documented,
  * unrelated upstream defect and therefore reads as an answer.
  *
  * So a capture carrying the recognized teardown incident gets two passes:
  * candidates excluding its `AttributeError` header first, and only if that
  * finds nothing does the full set apply. The narrowness the rest of the
- * codebase maintains is preserved exactly — the exclusion is gated on
- * `hasKnownTeardownNoise` for the WHOLE capture, so it requires both the
+ * codebase maintains is preserved exactly: the exclusion is gated on
+ * `hasKnownTeardownNoise` for the whole capture, so it requires both the
  * closed attribute allowlist and a `resourcemonitor.py` frame. A novel
  * attribute, or a traceback from anywhere else, stays a real failure and is
  * still eligible to be reported.

package/dist/src/core/test-harness-verdict-notes.d.ts

@@ -2,7 +2,7 @@
  * Verdict-note helpers for the harness classifier.
  *
  * Split out of `test-harness-crash.ts` (at its per-file line budget). These
- * decide the ADVISORY parenthetical on the `FIREFORGE-VERDICT:` line; none
+ * decide the advisory parenthetical on the `FIREFORGE-VERDICT:` line. None
  * of them changes a status or a reason key, which the verdict contract's
  * consumers parse.
  */
@@ -21,12 +21,12 @@ interface SummaryCountsView {
  * `Unexpected results: 0`, yet the run is still classified `test-failures`
  * on evidence lines that carry NO `TEST-UNEXPECTED-*` marker.
  *
- * `unexpected=0` printed beside `reason=test-failures` is the tell that the
- * verdict rests on pattern matching rather than on a harness result, and a
+ * `unexpected=0` printed beside `reason=test-failures` means the verdict
+ * rests on pattern matching rather than on a harness result, and a
  * reader who cannot see that spends hours attributing a red run to the
  * change under test. The note says so on the verdict line itself.
  *
- * Deliberately a NOTE and not a reclassification: a non-zero exit with no
+ * This is a note and not a reclassification: a non-zero exit with no
  * green-shaped summary is still a failing run, and inventing a new `reason`
  * would break the `FIREFORGE-VERDICT:` contract its consumers parse.
  */
@@ -36,16 +36,15 @@ export declare function truncateEvidence(line: string): string;
 /**
  * Outcome of the green-teardown belt.
  *
- * `accepted` is the pass. A rejection carries `rejectedBy` ONLY when the
- * recognized teardown noise was present — i.e. when the belt was the thing
- * that could have applied and did not. That distinction is the whole point
- * of the field: a run with no teardown traceback was never a candidate and
- * naming a "rejecting condition" for it would be noise, whereas a run that
- * DOES carry the traceback and still fails is the shape an operator
- * otherwise cannot diagnose from outside — every condition is
- * all-or-nothing, so the failing verdict looks identical whichever one
- * rejected it, and a downstream report spent a re-run and a filed-bug's
- * worth of effort guessing between them.
+ * `accepted` is the pass. A rejection carries `rejectedBy` only when the
+ * recognized teardown noise was present, i.e. when the belt was the thing
+ * that could have applied and did not. That is what the field is for: a run
+ * with no teardown traceback was never a candidate and naming a "rejecting
+ * condition" for it would be noise, whereas a run that does carry the
+ * traceback and still fails is the shape an operator otherwise cannot
+ * diagnose from outside. Every condition is all-or-nothing, so the failing
+ * verdict looks identical whichever one rejected it, and a downstream report
+ * spent a re-run and a filed-bug's worth of effort guessing between them.
  */
 export interface GreenTeardownOverride {
     accepted: boolean;

package/dist/src/core/test-harness-verdict-notes.js

@@ -3,7 +3,7 @@
  * Verdict-note helpers for the harness classifier.
  *
  * Split out of `test-harness-crash.ts` (at its per-file line budget). These
- * decide the ADVISORY parenthetical on the `FIREFORGE-VERDICT:` line; none
+ * decide the advisory parenthetical on the `FIREFORGE-VERDICT:` line. None
  * of them changes a status or a reason key, which the verdict contract's
  * consumers parse.
  */
@@ -19,12 +19,12 @@ const UNEXPECTED_MARKER = /TEST-UNEXPECTED-\w+/;
  * `Unexpected results: 0`, yet the run is still classified `test-failures`
  * on evidence lines that carry NO `TEST-UNEXPECTED-*` marker.
  *
- * `unexpected=0` printed beside `reason=test-failures` is the tell that the
- * verdict rests on pattern matching rather than on a harness result, and a
+ * `unexpected=0` printed beside `reason=test-failures` means the verdict
+ * rests on pattern matching rather than on a harness result, and a
  * reader who cannot see that spends hours attributing a red run to the
  * change under test. The note says so on the verdict line itself.
  *
- * Deliberately a NOTE and not a reclassification: a non-zero exit with no
+ * This is a note and not a reclassification: a non-zero exit with no
  * green-shaped summary is still a failing run, and inventing a new `reason`
  * would break the `FIREFORGE-VERDICT:` contract its consumers parse.
  */

package/dist/src/core/test-path-scope.d.ts

@@ -1,22 +1,22 @@
 /**
  * Directory-argument scope analysis for `fireforge test`.
  *
- * mozbuild's test resolver matches command-line paths by STRING PREFIX, so
+ * mozbuild's test resolver matches command-line paths by string prefix, so
  * `fireforge test browser/base/content/test/hominis` also runs the sibling
- * directory `browser/base/content/test/hominis-tiles` — silently, and with
+ * directory `browser/base/content/test/hominis-tiles`, silently, and with
  * no indication the scope widened.
  *
- * FireForge therefore treats a directory argument as meaning EXACTLY that
+ * FireForge therefore treats a directory argument as meaning exactly that
  * directory: {@link analyzeTestPathScopes} enumerates the test files of
- * exactly that directory and dispatches THAT explicit file list to mach,
+ * exactly that directory and dispatches that explicit file list to mach,
  * because a file list cannot prefix-match anything. Normalizing the
- * directory with a trailing `/` does NOT work — mach still sweeps in the
+ * directory with a trailing `/` does not work. Mach still sweeps in the
  * prefix-named sibling. The prefix-matching sibling directories are still
  * reported so the command layer can tell the operator what was excluded.
  *
  * FireForge already rejects non-existent paths up front, so raw
- * prefix-widening was never something an operator could invoke
- * deliberately — it only ever happened by accident.
+ * prefix-widening was never something an operator could invoke on purpose.
+ * It only ever happened by accident.
  */
 /** A sibling directory the raw mach prefix match would have included. */
 export interface SiblingPrefixMatch {
@@ -34,7 +34,7 @@ export interface TestPathScope {
      * list for a directory (mach cannot prefix-widen an explicit file
      * list), or the argument unchanged for files. A directory containing
      * no enumerable test files falls back to the trailing-`/` directory
-     * form — there is nothing to list, and mach owns the "no tests found"
+     * form: there is nothing to list, and mach owns the "no tests found"
      * failure.
      */
     dispatchPaths: string[];

package/dist/src/core/test-path-scope.js

@@ -2,22 +2,22 @@
 /**
  * Directory-argument scope analysis for `fireforge test`.
  *
- * mozbuild's test resolver matches command-line paths by STRING PREFIX, so
+ * mozbuild's test resolver matches command-line paths by string prefix, so
  * `fireforge test browser/base/content/test/hominis` also runs the sibling
- * directory `browser/base/content/test/hominis-tiles` — silently, and with
+ * directory `browser/base/content/test/hominis-tiles`, silently, and with
  * no indication the scope widened.
  *
- * FireForge therefore treats a directory argument as meaning EXACTLY that
+ * FireForge therefore treats a directory argument as meaning exactly that
  * directory: {@link analyzeTestPathScopes} enumerates the test files of
- * exactly that directory and dispatches THAT explicit file list to mach,
+ * exactly that directory and dispatches that explicit file list to mach,
  * because a file list cannot prefix-match anything. Normalizing the
- * directory with a trailing `/` does NOT work — mach still sweeps in the
+ * directory with a trailing `/` does not work. Mach still sweeps in the
  * prefix-named sibling. The prefix-matching sibling directories are still
  * reported so the command layer can tell the operator what was excluded.
  *
  * FireForge already rejects non-existent paths up front, so raw
- * prefix-widening was never something an operator could invoke
- * deliberately — it only ever happened by accident.
+ * prefix-widening was never something an operator could invoke on purpose.
+ * It only ever happened by accident.
  */
 import { readdir, stat } from 'node:fs/promises';
 import { basename, dirname, join } from 'node:path';
@@ -26,7 +26,7 @@ const TEST_FILE_PATTERN = /^(?:browser|test)_.*\.(?:m?js|x?html)$/;
 /**
  * Recursively enumerates test-implementation files under a directory,
  * returned engine-relative and sorted for deterministic dispatch order.
- * Returns [] when the directory cannot be read — the caller then falls
+ * Returns [] when the directory cannot be read. The caller then falls
  * back to the directory form and mach owns the failure.
  */
 async function collectTestFiles(dir, relPrefix) {
@@ -95,13 +95,13 @@ async function analyzeTestPathScope(engineDir, requestedPath) {
         }
     }
     catch {
-        // Unreadable parent: skip the sibling probe; exactness via the
+        // Unreadable parent: skip the sibling probe. Exactness via the
         // explicit file list is preserved regardless.
     }
     const testFiles = await collectTestFiles(absolute, `${stripped}/`);
     return {
         requestedPath,
-        // The explicit file list is what makes the selection exact; an empty
+        // The explicit file list is what makes the selection exact. An empty
         // enumeration falls back to the directory form.
         dispatchPaths: testFiles.length > 0 ? testFiles : [`${stripped}/`],
         isDirectory: true,
@@ -135,7 +135,7 @@ export function formatScopeNotice(scope) {
         .join(', ');
     if (scope.testFileCount === 0) {
         // Fallback dispatch: with nothing to enumerate, the raw directory form
-        // goes to mach, whose prefix matching CAN sweep the siblings in.
+        // goes to mach, whose prefix matching can sweep the siblings in.
         // Claiming exclusion here would be a lie.
         return (`${requestedDir}/ contains no enumerable test files, so the directory is passed to mach ` +
             `as-is — mach resolves paths by string prefix, which may also select: ${siblings}.`);