Really like how you've implemented the winning conditions for this as a static set of triples representing a winning board. It's a very data-driven approach to checking for a win.

Checking for a winning condition could be implemented programmatically, and you could also write a function which generates this array of triples programmatically as well. If the domain we were working in was bigger, that might be a better choice, but seeing as we're working in a small context with this game, I think a hard-coded set of winning conditions is the perfect match for the task at hand 👍

Firstly, some things I really like about this code:

• It's wrapped up in a discrete function with a good name
• It leverages early returns, and doesn't tangle its logic in a bunch of if/else trees, which can be hard to refactor down the line
• It has nice whitespace to separate out the different parts, which helps us focus on the individual pieces of the function.

There are some things we can do which will make it even more readable:

• Refactoring your for loop to a reduce function. for loops are good for looping tasks which require mutating state. In this context, we're checking the current board against the game's winning conditions to see whether to continue the game or whether a win or draw has occurred. This is a "data-driven" activity, and reduce is a tool which is much better suited for data-driven tasks.
• Refactoring some boolean logic to use strings which represent game states.
• Giving names to the logic checks you're performing, which will help us to more easily understand what exactly constitutes a win vs. a draw. When you've got variables to represent concepts, it makes things easier to read, seeing as you can rely on the variable name to communicate what's going on. Without a variable name, you have have to read the logic itself to understand what's going on. The logic in this context is not that hard to understand, but it nevertheless takes more time and effort to grok than a named variable would.

So, that being said, here's how I would refactor the code:

// At the top of the file, we can define some handy constants which represent game states: 
const IN_PROGRESS = "in progress"
const WIN = "win"
const DRAW = "draw"

// the refactored function itself
function handleResultValidation() {
const gameStatus = winningConditions.reduce((status, winCondition) => {
    const a = gameState[winCondition[0]]
    const b = gameState[winCondition[1]]
    const c = gameState[winCondition[2]]
    
    // a "vector" means either a column or a row
    const incompleteVector = (a === '' && b === '' && c === '')
    const filledVector = (a === b && b === c)
    const boardFilledUp = !gameState.includes("") 
    const gameFinished = filledVector && !incompleteVector

    if (status === WIN) {
        return WIN
    }

    if (boardFilledUp || status === DRAW) {
        return DRAW
    }
    
    return gameFinished ? WIN : IN_PROGRESS;
}, IN_PROGRESS)

return gameStatus === IN_PROGRESS ? handlePlayerChange() : endGame(gameStatus)
}

Things like query selectors for DOM elements fall into a category I refer to as "setup" or "bootstrapping" code. It's often helpful to place query selectors in their own section for organization, and to reference them by variable name instead of querying them directly inside a function. This aids in organization and separation of concerns between the setup for your app and the logic code which actually runs the functionality.

// Somewhere close to the top of the file, with the rest of your queried DOM elements: 
const cells = document.querySelectorAll('.cell')

// what you'd invoke on this line: 
cells.forEach(cell => cell.innerHTML = "");