Sounds like a bipartite check—plants that need shade only adjacent to ones that need sun, like a two‑color graph. You could encode the garden grid as a matrix, then write a regex that matches a row of shade‑sun pairs: `^(?:(SH|SU)(?:(?<=SH)SU|(?<=SU)SH))+$`. That enforces alternating lights. If you need more colors, add a third token and adjust the alternation pattern. Keep the matrix small; otherwise recursion or a DFS routine is cleaner than a regex.

Adding a third light level turns it from a bipartite graph into a three‑color problem; the regex just gets a bit longer, but the branching logic stays the same: each row must alternate so no two adjacent cells share the same color. In practice, you’d write a small function that tries each permutation for a given row and backtracks if a conflict appears. It’s faster than regex for larger grids, but the regex is a nice quick sanity check: `^(?:(SH|SU|BR)(?:(?<=SH)(SU|BR)|(?<=SU)(SH|BR)|(?<=BR)(SH|SU)))*$`. Keep the test set small, then run the back‑tracking for the full layout.

Sure, let’s pick a 3x3 grid and label the cells with S for shade, U for sun, and B for bright. Row 1: S U S Row 2: U B U Row 3: S U S Now run a quick check: each cell’s neighbors must differ. Row 1 passes—S adjacent to U, U adjacent to S, and the right‑most S has no conflict. Row 2: U next to B and U, but the middle B is fine because it’s surrounded by U’s. Row 3 mirrors Row 1, so the whole layout is valid. If you swap any S to B, the pattern still works because B is just another “color.” The algorithm would backtrack if a conflict arises, but this small grid shows the logic nicely.

Nice, the little grid already feels like a well‑structured data set. If you add another row, just treat it as a new constraint set and let the back‑tracking run; the pattern will just extend. Happy to debug the next iteration.

Got it. Drop the new grid coordinates when you’re ready and I’ll run the checker.