Robot Room Navigation Take-Home

Factory-monitoring backend take-home: parse a room map from stdin and simulate a robot moving from start to finish through obstacles, direction-changing tags, jumpers, and configurable search-direction rules. Requirements Input comes from stdin as an ASCII room map surrounded by # boundary characters. The room contains a start, an end, obstacles, direction-changing tags, jumpers, and configuration symbols that can change obstacles and search direction. Search direction may be clockwise or counterclockwise depending on configuration. Output a string of cardinal directions (N, S, E, W style) representing the route, or print loop when the robot enters a cycle and cannot reach the target. Correct loop detection is required; edge cases around cycles were a failure point. Notes Model the state as more than just (row, col). Direction, active configuration, and jumper effects may all be part of the visited-state key. Use deterministic simulation for forced movement and graph search only where choices exist. If the rule set is deterministic, a repeated full state proves a loop. Robot-grid prompts often require orientation-aware backtracking or simulation; a path that returns to the same cell with a different direction may not be equivalent. Be cautious with provided examples. One candidate found an example whose expected output appeared inconsistent with the direction rules; make assumptions explicit in the README / solution comments. Preparation Define a State(row, col, direction, config) tuple before coding and write a transition function that returns the next state plus emitted move character. Create fixtures for simple success, wall turn, jumper, config toggle, and a cycle that revisits the same coordinate with the same direction. Practice the blind-robot DFS/backtracking pattern separately so direction restoration becomes automatic when the take-home rules add forced moves or jumpers.