@hominis/fireforge 0.43.1 → 0.44.0

package/dist/src/core/status-binary.d.ts

@@ -2,20 +2,27 @@
  * Binary-aware drift classification for patch-owned files.
  *
  * The text classifier compares utf-8 decoded content against
- * `computePatchedContent`, which cannot apply `GIT binary patch` bodies —
- * so a binary file exported into a patch classified as `patch-owned-drift`
+ * `computePatchedContent`, which cannot apply `GIT binary patch` bodies — so
+ * a binary file exported into a patch classifies as `patch-owned-drift`
  * forever, keeping the engine-clean gate permanently red with nothing
- * actually un-durable. Binary sections DO carry the ground truth, though:
- * `git diff --binary` always records full blob hashes on the section's
+ * actually un-durable. A `GIT binary patch` section DOES carry the ground
+ * truth: `git diff --binary` always records full blob hashes on the section's
  * `index <old>..<new>` line. Comparing the live file's `git hash-object`
- * against the last owning section's new-side hash settles the
- * classification exactly. Bodies without a usable hash (hand-written
- * diffs, `Binary files … differ`) classify as `binary-unsupported` —
- * an honest "cannot compare" instead of a false "not durable".
+ * against the last owning section's new-side hash settles the classification
+ * exactly. Bodies without a usable hash (hand-written diffs) classify as
+ * `binary-unsupported` — an honest "cannot compare" instead of a false "not
+ * durable".
  *
- * Lives in its own module (not `status-classify.ts`) so the classifier
- * stays within the per-file line budget and this module never has to
- * import it back (dpdm-clean: the dependency edge points one way).
+ * That hash is trusted ONLY when the section carries a replayable payload
+ * (`hasBinaryDelta`). A `Binary files … differ` stub carries a correct index
+ * line too, so hashing against it reports `patch-backed` for a body that
+ * cannot rebuild the file at all — precisely the dishonesty this module
+ * exists to avoid. Such a body is `binary-unsupported` here, and an error
+ * from the `binary-body-not-reconstructable` queue lint.
+ *
+ * Lives in its own module (not `status-classify.ts`) so the classifier stays
+ * within the per-file line budget and this module never has to import it
+ * back: the dependency edge points one way, which keeps dpdm clean.
  */
 import type { PatchedContentContext } from './patch-apply.js';
 /** Batched patch lookup, injected by callers that classify many files. */

package/dist/src/core/status-binary.js

@@ -3,20 +3,27 @@
  * Binary-aware drift classification for patch-owned files.
  *
  * The text classifier compares utf-8 decoded content against
- * `computePatchedContent`, which cannot apply `GIT binary patch` bodies —
- * so a binary file exported into a patch classified as `patch-owned-drift`
+ * `computePatchedContent`, which cannot apply `GIT binary patch` bodies — so
+ * a binary file exported into a patch classifies as `patch-owned-drift`
  * forever, keeping the engine-clean gate permanently red with nothing
- * actually un-durable. Binary sections DO carry the ground truth, though:
- * `git diff --binary` always records full blob hashes on the section's
+ * actually un-durable. A `GIT binary patch` section DOES carry the ground
+ * truth: `git diff --binary` always records full blob hashes on the section's
  * `index <old>..<new>` line. Comparing the live file's `git hash-object`
- * against the last owning section's new-side hash settles the
- * classification exactly. Bodies without a usable hash (hand-written
- * diffs, `Binary files … differ`) classify as `binary-unsupported` —
- * an honest "cannot compare" instead of a false "not durable".
+ * against the last owning section's new-side hash settles the classification
+ * exactly. Bodies without a usable hash (hand-written diffs) classify as
+ * `binary-unsupported` — an honest "cannot compare" instead of a false "not
+ * durable".
  *
- * Lives in its own module (not `status-classify.ts`) so the classifier
- * stays within the per-file line budget and this module never has to
- * import it back (dpdm-clean: the dependency edge points one way).
+ * That hash is trusted ONLY when the section carries a replayable payload
+ * (`hasBinaryDelta`). A `Binary files … differ` stub carries a correct index
+ * line too, so hashing against it reports `patch-backed` for a body that
+ * cannot rebuild the file at all — precisely the dishonesty this module
+ * exists to avoid. Such a body is `binary-unsupported` here, and an error
+ * from the `binary-body-not-reconstructable` queue lint.
+ *
+ * Lives in its own module (not `status-classify.ts`) so the classifier stays
+ * within the per-file line budget and this module never has to import it
+ * back: the dependency edge points one way, which keeps dpdm clean.
  */
 import { join } from 'node:path';
 import { toError } from '../utils/errors.js';
@@ -102,7 +109,7 @@ export async function classifyBinaryOwnedFile(args) {
             // The last binary section expects the file to exist.
             return { ...entry, classification: 'patch-owned-drift', owner };
         }
-        if (section.indexNewHash !== undefined) {
+        if (section.hasBinaryDelta && section.indexNewHash !== undefined) {
             const fullPath = join(engineDir, entry.file);
             const live = (await hashObjectBatch(engineDir, [fullPath])).get(fullPath);
             if (live !== undefined) {

package/dist/src/core/status-classify.d.ts

@@ -7,38 +7,34 @@
  */
 /**
  * Classification buckets for engine file changes:
- * - `patch-backed`: content matches the expected post-patch state —
- *   normal after `fireforge import`.
- * - `patch-owned-drift`: the file is claimed by exactly one patch, but
- *   the live engine content no longer matches that patch's expected
- *   post-apply content. This includes furnace-prefixed paths: a path
- *   can be both Furnace-managed and patch-claimed (export a deployed
- *   component, then edit the workspace source and `furnace deploy`
- *   again — the deployed copy now has content the patch body lacks).
- *   Before 0.38.0 the furnace prefix check ran first and silently
- *   bucketed such files as `furnace`, so `status` reported the stale
- *   patch as owned.
- * - `unmanaged`: edits not explained by any patch or tool — local
- *   drift to export or discard.
+ * - `patch-backed`: content matches the expected post-patch state — normal
+ *   after `fireforge import`.
+ * - `patch-owned-drift`: the file is claimed by exactly one patch, but the
+ *   live engine content no longer matches that patch's expected post-apply
+ *   content. This includes furnace-prefixed paths: a path can be both
+ *   Furnace-managed and patch-claimed (export a deployed component, then
+ *   edit the workspace source and `furnace deploy` again — the deployed copy
+ *   now has content the patch body lacks). Checking the furnace prefix first
+ *   would bucket such files as `furnace` and report the stale patch as
+ *   owned.
+ * - `unmanaged`: edits not explained by any patch or tool — local drift to
+ *   export or discard.
  * - `branding`: files under tool-managed branding paths, written by
  *   FireForge's branding pipeline.
- * - `furnace`: files under Furnace-managed component prefixes. When
- *   exactly one patch also claims the path, this bucket asserts the
- *   live content matches that patch's expected post-apply content —
- *   a mismatch is reported as `patch-owned-drift` instead (see above).
+ * - `furnace`: files under Furnace-managed component prefixes. When exactly
+ *   one patch also claims the path, this bucket asserts the live content
+ *   matches that patch's expected post-apply content — a mismatch is
+ *   reported as `patch-owned-drift` instead (see above).
  * - `conflict`: the file is claimed by two or more patches in
- *   `patches.json`. The human `--ownership` mode already surfaces
- *   this bucket as `CONFLICT`; the classification is carried through
- *   the JSON pipeline so machine consumers can detect the same
- *   ownership breakage the human output shows. Before 0.16.0,
- *   cross-patch conflicts silently rolled into the `unmanaged` bucket
- *   in `--json`, which misled scripts built on top of the JSON view
- *   into treating the file as routine local drift.
+ *   `patches.json`. The human `--ownership` mode surfaces this bucket as
+ *   `CONFLICT`; carrying the classification through the JSON pipeline lets
+ *   machine consumers detect the same ownership breakage rather than seeing
+ *   it rolled into `unmanaged` as routine local drift.
  * - `binary-unsupported`: the file's comparison is binary and the owning
- *   patch body records no usable blob hash to compare against — an
- *   honest "binary — comparison unsupported" instead of a permanent
- *   false `patch-owned-drift`. Deliberately NOT in the default
- *   `--check` fail set; opt in with `--fail-on binary-unsupported`.
+ *   patch body records no usable blob hash to compare against — an honest
+ *   "binary — comparison unsupported" instead of a permanent false
+ *   `patch-owned-drift`. Deliberately NOT in the default `--check` fail set;
+ *   opt in with `--fail-on binary-unsupported`.
  */
 export type FileClassification = 'patch-backed' | 'patch-owned-drift' | 'unmanaged' | 'branding' | 'furnace' | 'conflict' | 'binary-unsupported';
 export interface StatusFile {
@@ -91,13 +87,11 @@ export declare function isGeneratedBrandingPath(file: string, binaryName: string
  * Classifies files into patch-backed, unmanaged, branding, furnace, or
  * conflict buckets.
  *
- * Tracks patch ownership as a `Map<file, patchFilename[]>` rather than
- * a plain `Set<file>` so the classifier can surface cross-patch
- * ownership conflicts the same way the human `--ownership` mode does.
- * The 2026-04-21 eval's `status --json` run reported
- * `classification: "unmanaged"` on two files (`browser/base/jar.mn`,
- * `browser/themes/shared/jar.inc.mn`) that `--ownership` correctly
- * flagged as `CONFLICT`; the JSON output was effectively lying to
- * machine consumers about the nature of the drift.
+ * Tracks patch ownership as a `Map<file, patchFilename[]>` rather than a
+ * plain `Set<file>` so the classifier can surface cross-patch ownership
+ * conflicts the same way the human `--ownership` mode does. With only a Set,
+ * `status --json` reports `classification: "unmanaged"` on files that
+ * `--ownership` correctly flags as `CONFLICT`, which lies to machine
+ * consumers about the nature of the drift.
  */
 export declare function classifyFiles(files: StatusFile[], engineDir: string, patchesDir: string, binaryName: string, furnacePrefixes: Set<string>): Promise<ClassifiedFile[]>;

package/dist/src/core/status-classify.js

@@ -120,14 +120,12 @@ async function classifySingleOwnerFile(entry, engineDir, patchesDir, matchClassi
  * Classifies files into patch-backed, unmanaged, branding, furnace, or
  * conflict buckets.
  *
- * Tracks patch ownership as a `Map<file, patchFilename[]>` rather than
- * a plain `Set<file>` so the classifier can surface cross-patch
- * ownership conflicts the same way the human `--ownership` mode does.
- * The 2026-04-21 eval's `status --json` run reported
- * `classification: "unmanaged"` on two files (`browser/base/jar.mn`,
- * `browser/themes/shared/jar.inc.mn`) that `--ownership` correctly
- * flagged as `CONFLICT`; the JSON output was effectively lying to
- * machine consumers about the nature of the drift.
+ * Tracks patch ownership as a `Map<file, patchFilename[]>` rather than a
+ * plain `Set<file>` so the classifier can surface cross-patch ownership
+ * conflicts the same way the human `--ownership` mode does. With only a Set,
+ * `status --json` reports `classification: "unmanaged"` on files that
+ * `--ownership` correctly flags as `CONFLICT`, which lies to machine
+ * consumers about the nature of the drift.
  */
 export async function classifyFiles(files, engineDir, patchesDir, binaryName, furnacePrefixes) {
     // One manifest load + patch discovery + memoized body reads for the
@@ -135,13 +133,12 @@ export async function classifyFiles(files, engineDir, patchesDir, binaryName, fu
     // every dirty file (O(dirtyFiles × patches) redundant IO on a broad
     // engine edit session).
     const ctx = await createPatchedContentContext(patchesDir, engineDir);
-    // Build a multimap from file path → list of claiming patch
-    // filenames so we can detect cross-patch ownership conflicts. The
-    // previous `Set<string>` captured only whether a path was claimed,
-    // not by whom, and collapsed multi-owner files into the single-owner
-    // branch where the expected-vs-actual content comparison then routed
-    // them into `unmanaged` when the content didn't match either owner's
-    // expectation.
+    // Build a multimap from file path → list of claiming patch filenames so
+    // cross-patch ownership conflicts are detectable. A plain `Set<string>`
+    // captures only whether a path was claimed, not by whom, and collapses
+    // multi-owner files into the single-owner branch where the
+    // expected-vs-actual content comparison then routes them into `unmanaged`
+    // when the content matches neither owner's expectation.
     const patchClaims = buildPatchClaims(ctx.manifestPatches);
     const deps = {
         engineDir,
@@ -176,11 +173,10 @@ async function classifyEntry(entry, deps) {
         };
     }
     // Branding paths are tool-managed for generated edits, but a brand-new
-    // unowned branding asset must not disappear from `status --unmanaged`.
-    // The Hominis Firefox 152 side-grade added Assets.car under the active
-    // branding tree; classifying every branding path before checking
-    // ownership hid that new patch candidate as "branding" even though no
-    // patch claimed it yet.
+    // unowned branding asset must not disappear from `status --unmanaged`:
+    // classifying every branding path before checking ownership hides a new
+    // patch candidate (an Assets.car appearing under the active branding tree,
+    // for instance) as "branding" even though no patch claims it yet.
     const isUnownedNewFile = owners === undefined && (primaryCode === '?' || primaryCode === 'A');
     if (isBrandingManagedPath(entry.file, binaryName) &&
         (!isUnownedNewFile || isGeneratedBrandingPath(entry.file, binaryName))) {
@@ -197,12 +193,11 @@ async function classifyEntry(entry, deps) {
         }
         if (isFurnace) {
             // A furnace path claimed by exactly one patch gets the same
-            // expected-vs-actual comparison as any other single-owner path:
-            // after a `furnace deploy` of an edited component the deployed
-            // copy has content the owning patch's body lacks, and the old
-            // unconditional short-circuit silently bucketed that drift as
-            // `furnace`. Multi-owner and unowned furnace paths keep the
-            // short-circuit.
+            // expected-vs-actual comparison as any other single-owner path: after
+            // a `furnace deploy` of an edited component the deployed copy has
+            // content the owning patch's body lacks, and an unconditional
+            // short-circuit here would silently bucket that drift as `furnace`.
+            // Multi-owner and unowned furnace paths keep the short-circuit.
             if (owners && owners.length === 1 && owners[0] !== undefined) {
                 return classifySingleOwnerFile(entry, engineDir, patchesDir, 'furnace', owners[0], ctx);
             }

package/dist/src/core/test-changed-prefs.d.ts

@@ -0,0 +1,30 @@
+/**
+ * Recognizer for the one mochitest failure shape that is a function of run
+ * LENGTH rather than of the code under test: the time-driven
+ * changed-preference checks.
+ *
+ * Separate from `test-harness-crash.ts` because it is not a crash
+ * classification — the run failed, and the classifier's verdict is correct.
+ * What this adds is which KIND of failure it was, which is a different
+ * question and one that only grows as more such shapes are recorded.
+ */
+/**
+ * Describes a failure set that consists ENTIRELY of changed-preference
+ * checks on {@link TIME_DRIVEN_PREF_NAMES}.
+ *
+ * Deliberately keyed on the pref NAMES rather than on the harness's phrasing
+ * of its changed-preference report: the phrasing is upstream copy that has
+ * no stable contract with us, and the names are the part that identifies the
+ * shape. A single block that names anything else — a real assertion, a
+ * different pref — disqualifies the whole set, because the point is to
+ * describe a run whose every failure is this noise, never to explain away
+ * one real failure sitting beside it.
+ *
+ * Pure; returns undefined when the shape does not apply.
+ *
+ * @param output - Combined harness stdout+stderr
+ * @returns Operator-facing explanation, or undefined
+ */
+export declare function describeChangedPrefNoise(output: string): string | undefined;
+/** Short verdict-line note for the changed-preference-noise shape. */
+export declare function changedPrefNoiseVerdictNote(output: string): string | undefined;

package/dist/src/core/test-changed-prefs.js

@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: EUPL-1.2
+/**
+ * Recognizer for the one mochitest failure shape that is a function of run
+ * LENGTH rather than of the code under test: the time-driven
+ * changed-preference checks.
+ *
+ * Separate from `test-harness-crash.ts` because it is not a crash
+ * classification — the run failed, and the classifier's verdict is correct.
+ * What this adds is which KIND of failure it was, which is a different
+ * question and one that only grows as more such shapes are recorded.
+ */
+import { collectUnexpectedFailureBlocks } from './test-harness-crash.js';
+/**
+ * Preferences that move on their own as a function of how LONG a run takes,
+ * not of what it tested.
+ *
+ * Both are time-driven: a long run crosses the cold-startup check interval
+ * and the pref moves under the harness. The observable consequence is that
+ * chunk length, not the change under test, decides whether the suite is
+ * red — the same work at a smaller `--chunk` passes. FireForge cannot
+ * suppress the check (it is the harness's, not ours) but it can stop the
+ * pair being indistinguishable from two real assertion failures, which is
+ * the whole cost of the shape.
+ *
+ * Matched as substrings: the harness prints fully-qualified pref names and
+ * the leading namespace has moved upstream more than once.
+ */
+const TIME_DRIVEN_PREF_NAMES = ['lastColdStartupCheck', 'globalprivacycontrol'];
+/** A failure block that is a changed-preference report rather than an assertion. */
+const CHANGED_PREF_BLOCK_PATTERN = /pref(?:erence)?s?\b/i;
+/**
+ * Describes a failure set that consists ENTIRELY of changed-preference
+ * checks on {@link TIME_DRIVEN_PREF_NAMES}.
+ *
+ * Deliberately keyed on the pref NAMES rather than on the harness's phrasing
+ * of its changed-preference report: the phrasing is upstream copy that has
+ * no stable contract with us, and the names are the part that identifies the
+ * shape. A single block that names anything else — a real assertion, a
+ * different pref — disqualifies the whole set, because the point is to
+ * describe a run whose every failure is this noise, never to explain away
+ * one real failure sitting beside it.
+ *
+ * Pure; returns undefined when the shape does not apply.
+ *
+ * @param output - Combined harness stdout+stderr
+ * @returns Operator-facing explanation, or undefined
+ */
+export function describeChangedPrefNoise(output) {
+    const blocks = collectUnexpectedFailureBlocks(output, CHANGED_PREF_BLOCK_LIMIT).filter((block) => !block.startsWith('…'));
+    if (blocks.length === 0)
+        return undefined;
+    const namesSeen = new Set();
+    for (const block of blocks) {
+        if (!CHANGED_PREF_BLOCK_PATTERN.test(block))
+            return undefined;
+        const matched = TIME_DRIVEN_PREF_NAMES.filter((name) => block.includes(name));
+        if (matched.length === 0)
+            return undefined;
+        for (const name of matched)
+            namesSeen.add(name);
+    }
+    return (`Every unexpected result in this run is a changed-preference check on ${[...namesSeen].join(' / ')}. ` +
+        'Those preferences are TIME-DRIVEN: they move once a run is long enough to cross the ' +
+        'cold-startup check interval, so they correlate with run LENGTH rather than with the ' +
+        'change under test or with the build. The first probe is to halve the chunk size ' +
+        '(`--chunk 8` where a 40-row chunk tripped it) and see whether the same work passes; ' +
+        'if it does, this was harness noise, not a regression. FireForge cannot forgive the ' +
+        'check — it belongs to the harness — only tell you which kind of failure you are ' +
+        'looking at.');
+}
+/** Failure blocks inspected before the changed-pref shape is abandoned. */
+const CHANGED_PREF_BLOCK_LIMIT = 20;
+/** Short verdict-line note for the changed-preference-noise shape. */
+export function changedPrefNoiseVerdictNote(output) {
+    return describeChangedPrefNoise(output) === undefined
+        ? undefined
+        : 'all unexpected results are time-driven changed-pref checks';
+}

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

@@ -1,5 +1,5 @@
 /**
- * Harness-crash classification for `fireforge test` (field reports C1/C2).
+ * Harness-crash classification for `fireforge test`.
  *
  * The wrapped mach harness exhibits flaky non-test failures that an exit
  * code (or a "did it print a summary" grep) cannot distinguish from real
@@ -10,25 +10,22 @@
  *    '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;
- *  - hangs after browser startup that die at the no-output timeout yet
- *    still 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.
+ *  - hangs after browser startup that die at the no-output timeout yet still
+ *    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
- * above so the command layer can retry them with a bounded budget instead
- * of reporting phantom test failures (or phantom passes).
+ * above so the command layer can retry them with a bounded budget instead of
+ * reporting phantom test failures (or phantom passes).
  */
-import type { DisplaySleepState } from './display-state.js';
+export type { HarnessCrashSignature } from './test-harness-signature.js';
+import type { HarnessCrashSignature } from './test-harness-signature.js';
+export { headedDisplayAsleepVerdictNote, headedNoOutputTimeoutHint } from './test-stall-triage.js';
 /** How a completed harness run should be interpreted. */
 export type HarnessRunClassification = 'tests-ran-ok' | 'test-failures' | 'harness-crash' | 'no-tests';
-/** A recognized harness-crash shape with its evidence line. */
-export interface HarnessCrashSignature {
-    reason: string;
-    line: string;
-}
 /** Numeric counts parsed from the harness's embedded result summary. */
 export interface HarnessSummaryCounts {
     /** Total checks the suite ran (`Ran N checks`), when the summary prints one. */
@@ -61,10 +58,10 @@ export interface HarnessRunVerdict extends HarnessSummaryCounts {
     /**
      * Set when the output embeds a green-LOOKING summary that was REJECTED:
      * crash or truncation evidence proves the suite never completed, so the
-     * "green" counts only cover the files that ran before the run died
-     * (field report: a SIGSEGV at the second of eight files left a
-     * `Passed: 2 / Failed: 0` summary that 0.35.0 green-washed into a pass).
-     * Callers must fail the run and surface the evidence.
+     * "green" counts only cover the files that ran before the run died — a
+     * SIGSEGV at the second of eight files leaves a `Passed: 2 / Failed: 0`
+     * summary that reads as a pass. Callers must fail the run and surface the
+     * evidence.
      */
     greenSummaryRejected?: GreenSummaryRejection;
     /**
@@ -99,16 +96,16 @@ export declare function stripNonSignalNoise(output: string): string;
  */
 export declare function findCrashMarkerLine(output: string): string | undefined;
 /**
- * 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 marker. Such a run finished its suite; any startup-traceback-
- * shaped noise in the same output is by definition non-fatal, so this
- * vetoes signature-based crash classification (field report: fully green
- * sharded runs reported `CRASH (N attempts)` because degradation warnings
- * matched the psutil signals). A summary printed after a crash marker is
- * NOT "completed" — it only covers the files that ran before the crash
- * (0.35.0 green-wash field report). Exported for direct unit testing.
+ * 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
+ * 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
+ * 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.
+ * Exported for direct unit testing.
  */
 export declare function hasCompletedGreenSummary(output: string): boolean;
 /**
@@ -193,41 +190,6 @@ export declare function formatFireforgeVerdictLine(verdict: HarnessRunVerdict, s
 export declare function buildGreenSummaryRejectedMessage(rejection: GreenSummaryRejection, exitCode: number): string;
 /** Builds the operator-facing failure message after retries are exhausted. */
 export declare function buildHarnessCrashMessage(signature: HarnessCrashSignature, attempts: number, commandLabel?: string): string;
-/**
- * Optional hint appended to the harness-crash message when a HEADED run on
- * macOS died at the no-output timeout.
- *
- * When `displayState` names a MEASURED display state, the hint states it
- * as fact rather than as one of three possibilities — that is the whole
- * point of probing: an operator staring at a bare test failure should not
- * have to rediscover that their machine dimmed. `caffeinate` is described
- * accurately (it prevents sleep; it cannot wake an already-sleeping
- * display), because the previous wording sent operators to a command that
- * could not have helped them.
- *
- * Pure — the platform and the probed state are injected so unit tests need
- * no mocking.
- *
- * @param signature - The recognized crash shape
- * @param context - Run mode, platform, and the probed display state
- * @returns The hint text, or undefined when the shape does not apply
- */
-export declare function headedNoOutputTimeoutHint(signature: HarnessCrashSignature, context: {
-    headless: boolean;
-    platform: string;
-    displayState?: DisplaySleepState;
-}): string | undefined;
-/**
- * Verdict-line note for a headed no-output stall whose display was
- * measured asleep. Returned as the parenthetical the verdict line carries,
- * so the one greppable line an automated consumer reads already names the
- * environmental cause instead of a bare `FAIL reason=crash`.
- */
-export declare function headedDisplayAsleepVerdictNote(signature: HarnessCrashSignature, context: {
-    headless: boolean;
-    platform: string;
-    displayState: DisplaySleepState;
-}): string | undefined;
 /**
  * True when a harness run died on SIGSEGV having produced no test evidence
  * whatsoever.