Blind 75: Flip Binary Tree

[pertrai1]

Summary by CodeRabbit

• New Features

  • Introduced "Flip Binary Tree" as a new problem in the Trees category

• Documentation

  • Updated overall progress tracker reflecting the latest problem additions
  • Added full documentation for "Flip Binary Tree" including problem description, worked examples, and constraint specifications

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[github-actions]

@codex review

[github-actions]

@codex review

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[github-actions]

Claude finished @pertrai1's task in 1m 10s —— View job

---

Code Review: Flip Binary Tree

Tasks:

• Read solution file and README
• Analyze correctness and edge cases
• Evaluate complexity analysis
• Identify patterns and key insights
• Check code quality and best practices
• Suggest related problems
• Provide learning summary

---

Overall Assessment ✅

This is a clean, correct implementation of the classic binary tree inversion problem. The solution demonstrates solid understanding of tree recursion and produces the expected results.

1. Correctness ✅

The solution correctly handles all cases:

• Empty tree: Returns null (line 12-14)
• Single node: Swaps null children, returns node
• Example cases: Mental trace confirms correctness
  • [2,1,3] → [2,3,1] ✓
  • [43,null,-55] → [43,-55] ✓
  • [12,8,18,6,null,null,20] → [12,18,8,20,null,null,6] ✓

Logic flow: The recursion correctly flips subtrees first (lines 16-17), then swaps them at the current node (lines 19-20). This bottom-up approach ensures complete inversion.

2. Complexity Analysis ✅

The stated complexity is accurate:

Time: O(n) - Each node is visited exactly once

• n is the number of nodes
• Each visit performs constant work (pointer swap)

Space: O(h) - Recursion stack depth

• h is the tree height
• Best case: O(log n) for balanced trees
• Worst case: O(n) for skewed trees

The complexity comments (lines 8-9) are correct and well-documented.

3. Learning Focus 🎓

Pattern: Tree DFS (Depth-First Search) / Post-Order Traversal

This problem uses a post-order traversal pattern where we:

1. Process left subtree
2. Process right subtree
3. Process current node

Why this pattern works: We need to flip children before we can swap them. Post-order ensures subtrees are completely inverted before we handle the parent.

Key Insight 💡

The non-obvious insight: You must recurse into both children before swapping them at the current level.

If you tried to swap first, you'd lose references to the original children before recursing. The temporary variables rightNode and leftNode (lines 16-17) preserve the flipped subtrees before assignment.

This is why iterative solutions often use a queue/stack - they explicitly manage what's been processed.

Common Mistakes ⚠️

1. Swapping before recursion:

   // WRONG - loses references
   [root.left, root.right] = [root.right, root.left];
   flipBinaryTree(root.left);  // Now operating on wrong subtree!

2. Not storing intermediate results: Without rightNode and leftNode, you'd overwrite one child before reading it.

3. Forgetting the null check: Missing the base case causes runtime errors on leaf children.

4. Code Quality ✅

Strengths:

• Clear variable names (rightNode, leftNode)
• Proper TypeScript interface for TreeNode
• Clean, readable structure
• Accurate complexity documentation

Minor observation: The solution is exported, suggesting it's part of a module system - good practice for reusable code.

5. Alternative Approaches

Approach 1: Iterative BFS (Breadth-First)

function flipBinaryTreeBFS(root: TreeNode | null): TreeNode | null {
  if (!root) return null;
  
  const queue = [root];
  while (queue.length > 0) {
    const node = queue.shift()!;
    [node.left, node.right] = [node.right, node.left];
    
    if (node.left) queue.push(node.left);
    if (node.right) queue.push(node.right);
  }
  return root;
}

Trade-offs:

• Same time complexity O(n)
• Space: O(w) where w is max width (could be better for deep, narrow trees)
• More imperative, less elegant

Approach 2: One-liner with destructuring

function flipBinaryTreeConcise(root: TreeNode | null): TreeNode | null {
  if (!root) return null;
  [root.left, root.right] = [flipBinaryTreeConcise(root.right), flipBinaryTreeConcise(root.left)];
  return root;
}

Trade-offs:

• More concise but less readable
• Same complexity
• No intermediate variables needed

Your solution strikes a good balance between clarity and conciseness.

6. Related Problems for Practice

These problems use similar tree recursion patterns:

1. LeetCode 100 - Same Tree (Easy)

   • Pattern: Tree DFS
   • Practices: Simultaneous tree traversal, base case handling

2. LeetCode 572 - Subtree of Another Tree (Easy)

   • Pattern: Tree DFS with nested recursion
   • Practices: Combining tree algorithms

3. GreatFrontEnd - Binary Tree Maximum Depth (Easy)

   • Pattern: Tree DFS
   • Practices: Post-order calculation (process children, then parent)

Learning Summary 📚

Core concept: Binary tree inversion is a fundamental tree manipulation that tests your understanding of recursion and tree traversal order.

Key takeaways:

1. Post-order traversal processes children before parents
2. Temporary variables preserve values when swapping
3. Base case (null check) prevents infinite recursion
4. The problem is a building block for more complex tree transformations

Interview relevance: This is a classic "Blind 75" problem that frequently appears in interviews. It tests whether you understand:

• Tree recursion mechanics
• When to use DFS vs BFS
• How to reason about tree problems

Real-world application: Tree inversions appear in:

• Mirror/reflection operations in graphics
• Data structure transformations
• UI component tree manipulations (React virtual DOM)

---

Verdict: Excellent solution! Clean implementation with correct complexity analysis. Ready to move forward. ✅

[coderabbitai]

📝 Walkthrough

Walkthrough

A new "Flip Binary Tree" problem is added to the GreatFrontEnd Blind 75 collection, including problem documentation and a TypeScript implementation. The main repository README is updated to reflect the increased problem count from 13 to 14.

Changes

Cohort / File(s)	Summary
Documentation Updates README.md	Updates GreatFrontEnd row from 13 to 14 solved problems; removes Progress subsection with Easy/Medium/Hard breakdown.
Blind 75 Collection Index greatfrontend/blind-75/README.md	Adds new "Flip Binary Tree" problem entry under Trees category with Easy label.
Flip Binary Tree Problem greatfrontend/blind-75/trees/flip-binary-tree/README.md, greatfrontend/blind-75/trees/flip-binary-tree/flip-binary-tree.ts	Adds complete problem documentation and TypeScript implementation. Exports flipBinaryTree() function with O(n) time complexity and O(h) space complexity; includes TreeNode interface definition.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A tree stood tall, left and right,
We flipped it 'round, what a delight!
From root to leaves, a dance so merry,
Fourteen problems now we carry! 🌳✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly describes the main change: adding a Flip Binary Tree problem to the Blind 75 coding challenges, which is the primary focus of this pull request.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch blind-1242026

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🧮 Solution Analysis

PR: Blind 75: Flip Binary Tree
Files Changed: greatfrontend/blind-75/trees/flip-binary-tree/flip-binary-tree.ts

📊 Code Quality Results

ESLint Analysis

• Errors: 0
• Warnings: 0

🔍 Complexity Analysis

flip-binary-tree

📋 Analysis Results:

🔍 Automated Complexity Analysis

⚠️ Disclaimer: This is an automated analysis that may not be 100% accurate.
Always verify the complexity analysis manually, especially for complex algorithms.
Dynamic Programming, recursive, and mathematical algorithms may need manual review.

✅ Manual Override Detected: Using complexity annotations from code comments.

File: greatfrontend/blind-75/trees/flip-binary-tree/flip-binary-tree.ts
Generated: 2026-01-24T13:09:02.005Z

Time Complexity

Estimated: O(n)
Source: Manual annotation (@Complexity or Time: comment)

Space Complexity

Estimated: O(h)
Source: Manual annotation (@Complexity or Space: comment)

Code Metrics

• Lines of Code: 15
• Cyclomatic Complexity: 2
• Max Nesting Level: 2

💡 Analysis Tips

• Time Complexity: Focus on the dominant operation in loops
• Space Complexity: Consider auxiliary data structures
• Optimization: Look for opportunities to improve efficiency
• Edge Cases: Ensure your solution handles empty inputs, null/undefined, edge conditions

📁 Analysis Files Created

Detailed analysis files have been automatically generated and committed to docs/analysis/ for future reference.

🎯 Next Steps

1. Review any ESLint errors/warnings above
2. Consider the complexity analysis - is this the optimal approach?
3. Test with edge cases mentioned in the problem description
4. Add comments explaining complex logic
5. Check the docs/analysis/ directory for detailed complexity analysis files

---

Analysis generated for PR files only

[github-actions]

---

🤖 Gemini Code Review (Model: gemini-2.5-flash)

Here's a review of your flipBinaryTree solution:

---

1. Pattern Identification

This solution uses the Depth-First Search (DFS) algorithmic pattern, specifically a post-order traversal variant.

• DFS: It explores as far as possible along each branch before backtracking.
• Post-order variant: The processing (swapping of children) for a node happens after the recursive calls for its children have completed. This is crucial because we need the children's subtrees to be flipped before we swap them at the current node.

2. Complexity Verification

• Time Complexity: O(n) where n is the number of nodes in the tree.
  • Verification: The stated complexity is accurate. Each node in the tree is visited exactly once. For each node, a constant amount of work is performed (two recursive calls, two assignments). Therefore, the total time complexity is directly proportional to the number of nodes.
• Space Complexity: O(h) where h is the height of the tree.
  • Verification: The stated complexity is accurate. This space is used by the recursion call stack. In the worst-case scenario (a skewed tree, resembling a linked list), the height h can be equal to n (the number of nodes), leading to O(n) space. In the best-case scenario (a perfectly balanced tree), the height h is log n, leading to O(log n) space.

3. Key Insight

The key insight for this problem is realizing that the "flipping" operation at a given node depends on its children already being flipped. This naturally leads to a recursive, post-order traversal approach:

1. Recursively flip the left subtree. After this call, root.left will point to the root of the flipped version of its original left subtree.
2. Recursively flip the right subtree. Similarly, after this call, root.right will point to the root of the flipped version of its original right subtree.
3. Swap the (now flipped) left and right children of the current root node. This effectively inverts the current node's direct children.

By performing the recursive calls first and then the swap, you ensure that when you swap root.left and root.right, you are swapping the already inverted subtrees, which correctly propagates the inversion up the tree.

4. Edge Case Analysis

The current solution handles the following edge cases correctly:

• Empty tree (root = null): The base case if (root === null) { return null; } handles this perfectly, returning null.
• Single node tree (root = [val]):
  • flipBinaryTree(root.right) and flipBinaryTree(root.left) will both return null.
  • root.left becomes null, root.right becomes null.
  • The original root is returned, correctly flipped (no children to swap).
• Tree with only a left child:
  • root.right is null, so flipBinaryTree(root.right) returns null.
  • root.left is processed recursively.
  • After the recursive calls, root.left will be assigned the (flipped) right subtree (which was null), and root.right will be assigned the (flipped) left subtree. This correctly moves the original left child to the right.
• Tree with only a right child: Similar logic to the above, correctly moving the original right child to the left.
• Skewed trees (e.g., a tree resembling a linked list): The recursive approach handles these naturally, as each node is processed sequentially along the "path."

The solution appears robust for all standard binary tree structures and constraints specified.

5. Learning Points

• Similar problems using this pattern:
  • Maximum Depth of Binary Tree: Also uses DFS, often post-order to calculate depth after children.
  • Symmetric Tree: Involves comparing two subtrees recursively, similar to how you traverse.
  • Same Tree: Checks if two trees are identical, another common recursive tree problem.
  • Invert Binary Tree (LeetCode 226): This is essentially the same problem, often called "Invert Binary Tree."
  • Path Sum (I, II, III): Many path-related problems in trees use DFS.
• Common mistakes with this pattern:
  • Incorrect base case: Forgetting to handle null nodes or having an incorrect return value for the base case.
  • Incorrect order of operations: Swapping children before recursively flipping them. If you swap root.left and root.right first, then flipBinaryTree(root.left) would be called on the original right subtree, not the original left subtree. The post-order approach (recurse, then process current node) is key here.
  • Modifying the tree incorrectly: Losing references to children before they are processed. Your solution correctly stores the results of the recursive calls in temporary variables (rightNode, leftNode) before reassigning root.left and root.right.
• Variations of this problem:
  • Invert a specific subtree: Only flip the tree starting from a particular node, not necessarily the root.
  • Flip a k-ary tree: Extend the concept to trees where nodes can have k children instead of just two. This would involve iterating through all children and reversing their order.
  • Flip a tree iteratively: Solve using an iterative BFS (queue) or iterative DFS (stack) approach.

6. Code Quality

The code quality is excellent:

• Variable Naming: root, leftNode, rightNode are clear and descriptive.
• Code Structure: The function is concise, follows a standard recursive tree traversal pattern, and is easy to understand.
• Readability: The logic is straightforward, and the use of const for leftNode and rightNode is good practice.
• TypeScript Best Practices: The TreeNode | null type annotation is correct and export is used appropriately.
• Comments: The @time and @space complexity comments are helpful and accurate.

No significant improvements are needed for code quality; it's already very clean and idiomatic.

7. Alternative Approaches

1. Iterative BFS (Level Order Traversal):

   • Approach: Use a queue. Add the root to the queue. While the queue is not empty, dequeue a node. Swap its left and right children. If the new left child (which was the original right child) is not null, enqueue it. If the new right child (which was the original left child) is not null, enqueue it.
   • Trade-offs:
     • Pros: Avoids recursion stack depth issues, which can be beneficial for very deep trees in languages with limited stack size (though less of a concern in JavaScript/TypeScript for typical LeetCode constraints).
     • Cons: Can be slightly more verbose than the recursive solution. Might be conceptually harder for some to visualize the "flip" happening level by level. Same O(N) time and O(W) space, where W is the maximum width of the tree (which can be O(N) in the worst case).

2. Iterative DFS (Pre-order Traversal with Stack):

   • Approach: Use a stack. Push the root onto the stack. While the stack is not empty, pop a node. Swap its left and right children. Then, push its children onto the stack (e.g., push new_left_child then new_right_child to process the new left child first, or vice-versa depending on desired traversal order).
   • Trade-offs:
     • Pros: Also avoids recursion stack depth. Mimics the recursive DFS more closely.
     • Cons: Similar to iterative BFS, can be slightly more verbose. Still O(N) time and O(H) space (where H is height, O(N) worst case).

Both iterative approaches achieve the same O(N) time complexity and O(H) or O(W) space complexity (both O(N) worst case) as the recursive solution. The recursive solution is often preferred for its elegance and conciseness in tree problems like this one.

[github-actions]

✅ Test Results

Tests have been executed for this pull request.

📊 Coverage Summary

Metric	Coverage
Statements	94.61%
Branches	89.26%
Functions	85.71%
Lines	94.68%

Check the workflow logs for detailed test output.

[github-actions]

---

🤖 Gemini Code Review (Model: gemini-2.5-flash)

This is an excellent solution for flipping a binary tree! It's concise, correct, and demonstrates a fundamental tree traversal pattern.

Here's a detailed review:

---

1. Pattern Identification

This solution uses Recursion and a Depth-First Search (DFS) traversal pattern. Specifically, it's a post-order traversal variant where the recursive calls to process children are made first, and then the current node's operation (swapping children) is performed.

---

2. Complexity Verification

• Time Complexity: O(n) where n is the number of nodes in the tree.
  • Verification: This is accurate. The function visits each node in the tree exactly once. For each node, it performs a constant amount of work (two recursive calls and two pointer assignments). Therefore, the total time complexity is directly proportional to the number of nodes.
• Space Complexity: O(h) where h is the height of the tree.
  • Verification: This is also accurate. The space complexity is determined by the maximum depth of the recursion call stack. In the worst case (a skewed tree, resembling a linked list), the height h can be equal to n (the number of nodes). In the best case (a perfectly balanced tree), h is log n.

---

3. Key Insight

The key insight that makes this solution work is the recursive definition of a flipped tree. To flip a binary tree rooted at node:

1. You first recursively flip its left subtree.
2. Then, you recursively flip its right subtree.
3. Finally, you swap the (now flipped) left and right children of the current node.

This approach leverages the self-similar nature of trees, breaking down the problem into smaller, identical subproblems until it reaches the base case of a null node (which has nothing to flip).

---

4. Edge Case Analysis

The current solution handles all standard edge cases correctly:

• Empty tree (root = null): The if (root === null) check correctly returns null, which is the expected behavior for an empty tree.
• Single node tree (root = [val]): Both root.left and root.right will be null. The recursive calls flipBinaryTree(null) will return null. The node's left and right pointers will then be set to null, which is correct as a single-node tree remains a single-node tree after being flipped.
• Tree with only left children (left-skewed tree): For a node with only a left child, its rightNode will be null. After the swap, its left will become null and its right will become the flipped version of its original left child. This effectively mirrors the left-skewed tree into a right-skewed tree.
• Tree with only right children (right-skewed tree): Similarly, this will be correctly mirrored into a left-skewed tree.
• General balanced/unbalanced trees: The recursive logic applies uniformly to all nodes, correctly flipping entire subtrees and then swapping them at their parent.

---

5. Learning Points

• Similar problems using this same pattern:
  • Calculating Height/Depth of a Binary Tree: Recursively find the height of left and right subtrees and combine.
  • Counting Nodes in a Binary Tree: Recursively count nodes in left and right subtrees and add 1 for the current node.
  • Maximum/Minimum Value in a Binary Tree: Recursively find max/min in subtrees and compare with current node's value.
  • Symmetric Tree (LeetCode 101): This problem asks if a tree is a mirror image of itself. It uses a very similar recursive idea, comparing two subtrees for symmetry.
  • Same Tree (LeetCode 100): Checks if two trees are structurally identical and have the same values.
• Common mistakes people make with this pattern:
  • Incorrect Base Case: Forgetting to handle root === null or having an incorrect condition can lead to infinite recursion or null pointer exceptions.
  • Incorrect Order of Operations: Swapping children before recursively flipping them would lead to incorrect results. The current solution correctly flips children first, then performs the swap at the current node.
  • Not Returning the Modified Node: Forgetting return root; means the changes made within the function wouldn't propagate back up the call stack.
• Variations of this problem:
  • Invert Binary Tree (LeetCode 226): This is virtually the same problem, often referred to as "invert" rather than "flip."
  • Flip Equivalent Binary Trees (LeetCode 951): A more complex variation where you need to determine if two trees can become identical by any number of flip operations on their nodes.

---

6. Code Quality

The code quality is excellent:

• Variable Naming: root, rightNode, leftNode are standard, clear, and descriptive.
• Code Structure: The function is concise, well-structured, and easy to follow. The recursive calls are immediately apparent.
• Readability: The solution is highly readable.
• TypeScript Best Practices:
  • The TreeNode interface is correctly defined.
  • Type annotations (TreeNode | null) are used appropriately, enhancing type safety and clarity.
  • The export keyword is correctly used for modularity.
  • The JSDoc comments for time and space complexity are very helpful.

No significant improvements are needed here. The code is already very clean and idiomatic TypeScript.

---

7. Alternative Approaches

While the recursive DFS approach is generally the most elegant for this problem, here are a couple of alternatives:

1. Iterative Approach (BFS using a Queue):

   • How it works: Use a queue to perform a level-order traversal (BFS). Start by adding the root to the queue. In each iteration, dequeue a node, swap its left and right children, and then enqueue its (new) left child and then its (new) right child (if they exist).
   • Trade-offs:
     • Time Complexity: Still O(n) as each node is visited and processed once.
     • Space Complexity: O(w) where w is the maximum width of the tree. In the worst case (a complete binary tree), w can be O(n/2), so effectively O(n).
     • Readability: Often slightly more verbose than the recursive solution for tree problems, but can be preferred by developers who want to avoid deep recursion stacks or prefer explicit iteration.
     • No Recursion Stack: Avoids potential stack overflow issues for extremely deep trees, though for the given constraint of 100 nodes, recursion is perfectly safe.

2. Iterative Approach (DFS using a Stack):

   • How it works: Use a stack to perform an iterative DFS. Push the root onto the stack. While the stack is not empty, pop a node, swap its left and right children, then push its (new) left child and then its (new) right child onto the stack (order of pushing depends on desired traversal, but for swapping, it doesn't matter as much).
   • Trade-offs:
     • Time Complexity: O(n).
     • Space Complexity: O(h) in the worst case (a skewed tree), similar to the recursive solution.
     • Readability: Similar to iterative BFS, can be less intuitive than recursion for some tree problems.

For this specific problem, the recursive solution is often considered the most natural and concise, making it the preferred approach.

[Copilot]

Pull request overview

This PR adds a new solution for the "Flip Binary Tree" problem from GreatFrontEnd's Blind 75 collection. The solution implements a recursive algorithm to invert a binary tree by swapping left and right children at each node. The PR also includes documentation and updates the repository's problem count from 13 to 14 GreatFrontEnd problems.

Changes:

• Added TypeScript implementation with O(n) time and O(h) space complexity
• Created comprehensive README with problem description, examples, and constraints
• Updated GreatFrontEnd Blind 75 index with the new problem entry
• Cleaned up redundant LeetCode progress information in main README

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
greatfrontend/blind-75/trees/flip-binary-tree/flip-binary-tree.ts	New TypeScript implementation of recursive tree flipping algorithm with proper type definitions
greatfrontend/blind-75/trees/flip-binary-tree/README.md	Complete problem documentation including description, examples, constraints, and problem link
greatfrontend/blind-75/README.md	Added "Flip Binary Tree" entry to the Trees section
README.md	Updated GreatFrontEnd problem count to 14 and removed redundant LeetCode progress section

[Copilot]

The JSDoc tags should include hyphens after @time and @space for consistency with other files in the repository. Other GreatFrontEnd solutions use the format @time - and @space - (with hyphens). For example, see array-product-excluding-current.ts and binary-tree-level-order-traversal.ts which use this format.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@greatfrontend/blind-75/trees/flip-binary-tree/README.md`:
- Around line 19-41: The README currently specifies `root: TreeNode` and "1 <=
Number of nodes <= 100" but the implementation accepts `TreeNode | null`; update
the spec to reflect empty-tree handling by allowing `root: TreeNode | null` (or
"0 <= Number of nodes <= 100") and add an example for `root = []`/`null`, or
alternatively change the implementation to require non-null by removing `null`
from the function signature and ensuring callers construct a non-empty tree;
reference the `root` type in README and the function signature that accepts
`TreeNode | null` to keep docs and code consistent.

🧹 Nitpick comments (1)

greatfrontend/blind-75/trees/flip-binary-tree/flip-binary-tree.ts (1)

11-23: Add targeted tests for edge cases.
Please add tests for null root, single-node trees, and skewed trees to lock in behavior for in-place mutation. As per coding guidelines, ...

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Clarify empty-tree handling in the spec.
The README says root: TreeNode with at least 1 node, but the implementation accepts TreeNode | null. Please align the input/constraints (allow 0 nodes) or enforce non-null in code. As per coding guidelines, ...

🤖 Prompt for AI Agents

In `@greatfrontend/blind-75/trees/flip-binary-tree/README.md` around lines 19 -
41, The README currently specifies `root: TreeNode` and "1 <= Number of nodes <=
100" but the implementation accepts `TreeNode | null`; update the spec to
reflect empty-tree handling by allowing `root: TreeNode | null` (or "0 <= Number
of nodes <= 100") and add an example for `root = []`/`null`, or alternatively
change the implementation to require non-null by removing `null` from the
function signature and ensuring callers construct a non-empty tree; reference
the `root` type in README and the function signature that accepts `TreeNode |
null` to keep docs and code consistent.

[github-actions]

📅 Spaced Repetition Reviews Scheduled!

Great job solving #GFE-5951 - Flip Binary Tree! 🎉

To help you retain this knowledge long-term, I've scheduled 5 review sessions using spaced repetition:

Review	Interval	Schedule Logic
1st Review	1 day after solving	Scheduled now
2nd Review	3 days after 1st review	Auto-scheduled when 1st completes
3rd Review	7 days after 2nd review	Auto-scheduled when 2nd completes
4th Review	14 days after 3rd review	Auto-scheduled when 3rd completes
5th Review	30 days after 4th review	Auto-scheduled when 4th completes

What to expect:

• Your 1st review is scheduled for tomorrow
• Each subsequent review is scheduled automatically when you complete the previous one
• This ensures proper spacing even if you complete a review a few days late
• GitHub issues will be created automatically for each review
• Each issue will link back to your solution

🧠 Why Spaced Repetition?

Research shows that reviewing material at increasing intervals dramatically improves retention. This adaptive scheduling ensures optimal spacing based on when you actually complete each review!

Check docs/reviews/review-schedule.json to see your review schedule.