// Pure decision for the "Files deleted on the server" (teammate-deletion) prompt.
//
// Two signals feed it:
//   - goneFromPrev: a file that WAS in the depot tree a moment ago and just
//     disappeared while still on disk (a teammate deleted it while the app was
//     open). Reliable, because we observed it present then absent.
//   - goneFromManifest: a file with a recorded synced base hash, still on disk,
//     but absent from the current depot tree. This catches a fresh login /
//     first refresh, when there is no prior in-memory head to diff against.
//
// The manifest signal has a race: right after THIS client submits a new file,
// the manifest records it as synced immediately, but the depot-tree snapshot
// (`serverFiles`) can still be the pre-submit view for a beat — so the file
// looks "synced but missing from the server" and falsely triggers the prompt.
// `recentlySubmitted` suppresses exactly those paths until the depot tree
// catches up (the caller clears a path once `serverFiles` confirms it), the
// same pattern `pullingPaths` uses to hide notAdded flicker mid-pull.
export function computeServerDeletions({
  prevServerFiles,
  serverFiles,
  localFiles,
  baseHashes,
  changelistDel,
  answered,
  recentlySubmitted,
}) {
  const goneFromPrev =
    prevServerFiles && prevServerFiles.size
      ? [...prevServerFiles.keys()].filter(
          (path) => !serverFiles.has(path) && localFiles.has(path)
        )
      : [];
  const goneFromManifest = [...baseHashes.keys()].filter(
    (path) => baseHashes.get(path) && localFiles.has(path) && !serverFiles.has(path)
  );
  return [...new Set([...goneFromPrev, ...goneFromManifest])].filter(
    (path) =>
      !changelistDel.has(path) &&
      !answered.has(path) &&
      !recentlySubmitted.has(path)
  );
}
