[rush] rushd: warm daemon reports a successful no-op build after an operation's output folders were deleted, leaving the outputs missing

The issue is in the daemon's operation invalidation logic. Start by examining PhasedOperationPlugin.ts:139 (shouldEnableOperation) and WorkspaceEngineComponentFactory.ts:273-286. Understand how output fingerprints are currently ignored. The fix involves recording a fingerprint of declared output folders after a successful operation and invalidating when this changes. Run the existing rush-daemon tests to verify changes.

Summary

A warm daemon treats an operation as up to date by comparing only its input state hashes with the retained in-memory result. Build outputs are git-ignored and are not part of any hash, and output-folder changes are never mapped to invalidations. After rm -rf <project>/lib, git clean -xdf or heft clean, the next rush-client build (even --to <that project>) exits 0, runs 0 operations, prints nothing, and leaves the outputs missing. Native rush build restores them from the build cache.

Repro steps

# any workspace, RUSH_DAEMON=1, rush-client from main @ 60007c9a8c, one shell
rush-client build; rush-client build        # warm
rm -rf packages/p03/lib
rush-client build                           # exit 0, 0 ops, 0 bytes
rush-client build --to p03                  # exit 0, 0 ops, 0 bytes
ls packages/p03/lib                         # still missing
rush build --to p03                         # native: restores p01..p03 from cache, lib is back

Expected result: Missing or changed declared outputs (outputFolderNames) invalidate the operation, so it is re-restored from cache or re-executed, and "SKIPPED because already built" always means the outputs exist.

Actual result: The daemon reports success while the workspace is broken. Downstream consumers and tests later fail with confusing errors.

Details

Root cause (main @ 60007c9a8c): the warm skip (PhasedOperationPlugin.ts:139, shouldEnableOperation) compares input hashes only. WorkspaceEngineComponentFactory.ts:273-286 invalidates only hash-changed operations. ProductionDaemonRequestResolver getChangedOperations compares own-state hashes, which ignore outputs. The session watcher does not map output-folder events to invalidations. Only the "dirty native lock" case is guarded (PhasedCommandEngineExecution.ts:36).

Suggested fix: when an operation completes successfully, record a cheap fingerprint of its declared output folders (existence plus directory identity/mtime, or the file list and sizes the cache plugin already computes). During reconciliation, invalidate any retained operation whose output fingerprint changed or is missing. A prototype of this approach invalidated exactly the affected operation (1 cache restore, dependents untouched, no false positives) and passed the existing rush-daemon tests.

This was found during an automated performance/behavior analysis of rush-client/rushd on Linux and independently reproduced twice.

Standard questions