[🚀 사이클1 - 미션 (보드 초기화 + 기물 이동)] 서여 미션 제출합니다. by yeo-li · Pull Request #254 · woowacourse/java-janggi

yeo-li · 2026-03-29T08:31:26Z

체크 리스트

미션의 필수 요구사항을 모두 구현했나요?
Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
애플리케이션이 정상적으로 실행되나요?

실행 전 유의 사항

1. 콘솔의 폰트를 D2Coding으로 설정해주세요.

D2Coding 폰트가 아니라면, 장기판과 장기판 좌표의 위치가 어긋나게 출력될 수 있습니다.

2. 장기판의 상단이 한, 하단이 초에요.

입력 좌표 기준은 출력된 보드 기준 그대로이며, y=1이 한, y=10이 초입니다.

3. 좌표 입력은 반드시 숫자로 입력해주세요.

현재 좌표 입력은 Scanner.nextInt()를 사용하고 있어, 문자 입력 시 InputMismatchException으로 프로그램이 종료됩니다.

어떤 부분에 집중하여 리뷰해야 할까요?

1. 이동 규칙 검증 책임 분리 구조의 적절성

Board.movePiece에서 턴/소유권/경로/목적지 검증을 수행하고, 실제 이동 가능 경로 계산은 MovementStrategy(PathMovement, LinearMovement)로 분리했습니다.
이 책임 분리가 유지보수/확장 측면에서 적절한지 피드백 해주시면 감사하겠습니다:)

2. 예외 메시지 일관성과 입력 안정성

도메인 예외 메시지를 중심으로 사용자에게 출력을 하고 있는데, 메시지의 의미/정확성이 충분한지와
입력 파싱(nextInt) 예외 처리를 View/Controller/Domain 어디에서 담당하는 게 좋은지 의견 부탁드립니다!

3. 테스트 커버리지의 적절성

기물별 이동 규칙과 보드 이동 케이스는 테스트했지만, 콘솔 입력(문자 입력 등)과 장기 진행 통합 시나리오는 부족합니다.
테스트 보강이 필요한 영역을 짚어주시면 감사하겠습니다!

리뷰어에게

안녕하세요 로키!
이번 리뷰어로 참여해주셔서 감사합니다 :)
편하실때 리뷰 해주시면 저도 빠르게 피드백 반영하겠습니다!
좋은 하루 되세요🍀

yeo-li

코드와 관련된 질문 남겨두었습니다☺️ 편하실 때 읽어주시면 감사하겠습니다!

yeo-li · 2026-03-29T08:45:32Z

src/main/java/domain/piece/Cannon.java

+    @Override
+    public void checkRoute(List<Piece> pieces) {
+        int count = 0;
+        for (Piece piece : pieces) {
+            if (piece instanceof Cannon) {
+                throw new IllegalArgumentException(CANNOT_JUMP_WITH_CANNON);
+            }
+            if (!(piece instanceof Empty)) {
+                count++;
+            }
+        }
+        if (count != 1) {
+            throw new IllegalArgumentException(INVALID_TARGET_POSITION);
+        }
+    }
+
+    @Override
+    public void checkTarget(Piece piece) {
+        if (piece.getSide().equals(side)) {
+            throw new IllegalArgumentException(CANNOT_CAPTURE_OWN_PIECE);
+        }
+
+        if (piece instanceof Cannon) {
+            throw new IllegalArgumentException(CANNOT_CAPTURE_CANNON_WITH_CANNON);
+        }
+    }


포를 제외한 checkRoute, checkTarget의 구현이 동일하여, 부모 클래스 Piece에 공통 로직을 구현하고 포만 오버라이드하도록 설계했습니다.

이 방식은 중복 제거와 직관성 측면에서는 장점이 있다고 생각합니다. 하지만 Piece에 구현된 메서드는 모든 자식 클래스가 그대로 사용할 수 있어야 좋은 설계라고 생각했는데, 현재처럼 특정 자식(포)만 오버라이드가 필요한 구조도 괜찮은 설계인지 궁금합니다:)

이런 상황에서 부모에 기본 구현을 두고 일부만 override 하는 방식이 적절한지 혹은 처음부터 추상 메서드로 강제하는 것이 더 좋은지 의견 남겨주시면 감사하겠습니다☺️

yeo-li · 2026-03-29T08:59:58Z

src/main/java/domain/piece/PieceType.java

PieceType enum을 각 기물의 생성 책임을 담당하도록 사용했습니다. 각 기물마다 생성 시 필요한 전략(LinearMovement, PathMovement)이 다르기 때문에, enum 내부에서 create 메서드를 오버라이드하여 기물 생성 로직과 전략을 함께 묶었습니다!

이렇게 하면 Board나 Formation에서는 PieceType만 알면 되기 때문에 구체적인 생성 방식이나 전략에 의존하지 않아도 된다고 생각했습니다. 반면, enum에 생성 로직까지 포함되면서 책임이 커지고 enum이 비대해지는 구조가 되는 것 같다는 고민도 있습니다.

크루들과 이야기했을 때는 이 구조가 오버 엔지니어링이고, 별도의 Factory 클래스를 두고 Map으로 관리하는 것이 더 단순하다는 의견도 있어 각각의 장단점이 있는 것 같단 생각이 들었어요.

저는 enum에 생성 책임까지 포함시키는 방식이 적절한 설계인지, 생성 책임은 분리해서 별도의 Factory로 두는 것이 더 좋은지 혹은 현재 구조가 유지보수나 확장성 측면에서 실제로 의미 있는 추상화인지 궁금합니다!

PieceType이 기물 생성 책임까지 가지는 현재 구조는, 이번 미션 규모에서는 충분히 자연스러운 선택이라고 생각합니다. 👍👍
사용하는 쪽에서 구체적인 생성 방식과 전략을 몰라도 된다는 장점이 분명해서, 지금 단계에서 별도 Factory를 두는 것이 꼭 더 단순하다고 보이지는 않아요. 다만 생성 정책이 더 복잡해진다면 enum이 비대해질 수 있으니, 그 시점에는 책임 분리를 다시 고민해볼 수 있을 것 같습니다.

피드백 감사해요!☺️ 우선 현재 구조를 유지하는 방향으로 리팩토링 해보겠습니다:)

yeo-li · 2026-03-29T12:02:42Z

src/main/java/domain/Position.java

+    public static Position of(int x, int y) {
+        validateOutOfRange(x, y);
+        return CACHE.computeIfAbsent(x * 100 + y, k -> new Position(x, y));
+    }


Position을 생성할 때, 입력값을 어디서 파싱하는 것이 적절한지에 대해 고민이 있습니다. 현재 구조에서는 InputView에서 scanner.nextInt()를 사용해 좌표를 int로 파싱한 뒤 Position으로 전달하고 있습니다.

이때 int 범위를 초과하는 값이 들어오면, InputView 단계에서 예외가 발생하면서 "숫자를 입력해 주세요"와 같은 메시지가 출력될 수 있는데, 사용자 입장에서는 숫자를 입력했기 때문에 부정확한 메시지라고 느낄 수 있다고 생각했습니다.

그래서 String을 그대로 Position까지 넘겨서 형변환과 범위 검증을 Position 내부에서 함께 처리하는 방식도 페어와 논의를 해보았습니다. 저희가 내린 결론은 of() 메서드 안에서 형변환을 해주는 것은 과도한 책임이기 때문에, 외부에서 형변환을 한 뒤에 그 값에 대한 유효성 검증을 하는게 더 좋은 설계라고 결론 내렸습니다.

하지만 개인적으로는 좌표 입력값에 대한 형변환 자체도 Position을 생성하는 과정의 일부라면 형변환 역시 Position.of()의 책임으로 보는 것이 맞지 않을까 하는 생각도 들었습니다.

이 상황에서 입력값의 파싱을 InputView에서 처리하는 것이 적절한지, 아니면 Position 내부에서 처리하는 것이 더 나은 설계인지 고민이 됩니다. 이에 대해 피드백 주시면 감사하겠습니다:)

이 상황에서 입력값의 파싱을 InputView에서 처리하는 것이 적절한지, 아니면 Position 내부에서 처리하는 것이 더 나은 설계인지 고민이 됩니다. 이에 대해 피드백 주시면 감사하겠습니다:)

Position은 좌표 값 객체인 만큼, 문자열 파싱보다는 파싱된 값의 유효성 검증에 집중하는 편이 역할이 더 선명하다고 생각해요. 😃

다만 현재처럼 InputView에서 바로 nextInt()를 사용하는 방식은 입력 예외 메시지를 세밀하게 다루기 어려워 보여, 문자열 입력은 View에서 받고 형변환과 재입력 흐름은 Controller에서 관리하는 구조도 고려할 수 있을 것 같아요. 🤔

의견 감사합니다☺️ 그렇다면 혹시 Position이 형변환을 하지 않고 파싱된 값의 유효성 검증에만 집중하기 때문에, 정적 팩토리 메서드를 사용하지 않고 생성자에 검증 로직을 추가해도 괜찮을지도 궁금합니다!

Rok93

서여 안녕하세요~
장기 미션을 함께하게된 로키입니다.

꽤 어려운 미션인데 전체적으로 잘 진행해주셨네요. 👍👍

남겨주신 질문에대해서 제 생각들 남겨두었고 추가로 몇몇 코멘트도 남겨두었으니 확인 부탁드릴게요 😄

Rok93 · 2026-03-30T11:17:10Z

src/test/java/domain/piece/ElephantTest.java

+import org.junit.jupiter.params.ParameterizedTest;
+import org.junit.jupiter.params.provider.CsvSource;
+
+class ElephantTest {


현재 깨지는 테스트가 있어보이네요.
리뷰 요청 전에는 꼭 한번 애플리케이션이 정상 동작하는지, 작성한 테스트 코드가 모두 통과하는지 확인해주세요. 😃

앗 죄송합니다..!ㅠ 다음엔 관련해서 꼭 확인한 뒤 제출하겠습니다🥲

Rok93 · 2026-03-30T11:24:58Z

src/main/java/domain/piece/Piece.java

+    public void checkRoute(List<Piece> pieces) {
+        for(Piece piece : pieces) {
+            if(!(piece instanceof Empty)) {
+                throw new IllegalArgumentException(CANNOT_CAPTURE_OWN_PIECE);


"아군 기물을 잡을 수 없습니다." 라는 에러 메시지를 던지고있는데요.
실제 상황은 경로가 중간에 막혀서 예외를 던진 것으로 보여요. 🤔

경로가 막혔기 때문에 "이동할 수 없다"는 메세지를 출력해야겠네요! 바로 수정하겠습니다🥲 감사합니다!

Rok93 · 2026-03-30T11:28:58Z

src/main/java/view/InputView.java

+    public int readTargetXPosition() {
+        System.out.println();
+        System.out.println("목적지 x 좌표를 입력해주세요. (x 범위 1 ~ 9)");
+        return scanner.nextInt();


현재 좌표 입력은 Scanner.nextInt()를 사용하고 있어, 문자 입력 시 InputMismatchException으로 프로그램이 종료됩니다.

실수로 문자를 입력한 경우에대해서 프로그램을 바로 종료하기보다는 재입력을 받도록해주면 어떨까요?
지금과 같은 콘솔 게임은 실수로 잘못된 값을 입력하기가 매우 쉬운 환경이라 생각해요. 🥹

InputView에서 Scanner.nextInt()를 이용해 반환하던 기존의 구조에서 InputView에서 String을 반환하고 중간에 Parser.parseInput()이라는 유틸 메서드를 만들어 String을 int로 반환하도록 변경했습니다! 피드백 감사합니다☺️

Rok93 · 2026-03-30T11:40:47Z

src/main/java/domain/strategy/MovementStrategy.java

+
+import java.util.List;
+
+public abstract class MovementStrategy {


이동 규칙 검증 책임 분리 구조의 적절성
Board.movePiece에서 턴/소유권/경로/목적지 검증을 수행하고, 실제 이동 가능 경로 계산은 MovementStrategy(PathMovement, LinearMovement)로 분리했습니다.
이 책임 분리가 유지보수/확장 측면에서 적절한지 피드백 해주시면 감사하겠습니다:)

지금 구조 방향은 나쁘지 않습니다. 특히 Board가 "이동 요청을 조율하는 객체"로서 턴, 소유권, 목적지 점유 상태를 확인하고, 각 기물이 MovementStrategy를 통해 자신의 이동 경로를 계산하게 한 점은 책임을 분리하려는 의도가 분명해서 좋았어요. 👍 👍

제가 느끼기에는

Board는 경기 진행 담당자

Piece와 MovementStrategy는 각 기물의 움직임 규칙 담당
의 역할을 가지는 것으로 이해했어요.

다만 현재 Board가 이동 규칙까지 함께 판단하고 있어 역할 범위가 다소 넓어 보여요.
개인적인 생각으로는 이동 규칙 판단을 기물 쪽에 더 모으면 이동 규칙의 응집도를 더 높일 수 있지 않을까 싶어요. 🤔

피드백 감사합니다! 😊
말씀해주신 방향대로 Board에서 이동 규칙 판단 책임을 분리해보려 했고, 처음에는 Piece에 규칙을 모으는 방식을 고민했습니다.
다만 실제 검증 과정에서 Board가 Piece의 이동 검증 순서를 강하게 조합하고 있어, 완전히 분리하기가 쉽지 않다고 느꼈습니다.

그래서 Board는 기물 이동과 상태 조회만 담당하도록 단순화하고, Game 클래스를 도입해 이동 규칙 검증과 턴 관리를 맡기도록 구조를 변경했습니다.
이렇게 하면 Board는 규칙 판단 책임에서 벗어나고, Piece는 각 기물의 구체적인 이동 규칙에 집중할 수 있으며, Game은 규칙 실행 흐름과 턴 전환을 담당하게 됩니다.

역할 경계를 명확히 해서 응집도를 높이는 방향으로 리팩터링해봤습니다.
혹시 여전히 부족한 부분이 있다면 편하게 피드백 부탁드립니다!

Rok93 · 2026-03-30T11:45:21Z

src/main/java/controller/JanggiController.java

+import view.InputView;
+import view.OutputView;
+
+public class JanggiController {


예외 메시지 일관성과 입력 안정성
도메인 예외 메시지를 중심으로 사용자에게 출력을 하고 있는데, 메시지의 의미/정확성이 충분한지와
입력 파싱(nextInt) 예외 처리를 View/Controller/Domain 어디에서 담당하는 게 좋은지 의견 부탁드립니다!

서여는 아마도 전체를 통틀어서 질문을 하신 것 같은데요..!
상황에 따라 조금 다른 것 같아요.

단순히 입력값에대한 입력 형식 문제는 View나 Controller 쪽에서 처리하는게 자연스럽지만
졸병을 두 칸 전진시켰다거나하는 케이스는 도메인 규칙에 위배되는 경우이므로 이런 경우에는 Domain에서 예외처리를 해야한다고 생각해요. 😃

메시지의 의미/정확성은 꼼꼼하게 다 살펴보지는 못했지만, 남긴 코멘트중에서 상황에 맞지않는 예외 처리가 있었던 것 같은데요. 예외 메시지의 의미/정확성이란게 딱 정의된 것은 없지만, 결국 예외 메시지를 왜 남기는지?에 대해서 고민해보면 좋을 것 같아요.

결국에는 예외 상황을 표시하고 적절한 처리를 하기위함이라고 생각하는데요.
그렇다면 해당 예외 상황이 왜 발생했는지를 잘 드러내야한다고 생각해요.
또 더 나아가서 실제 운영환경에서 버그가 발생하여 장애대응을 한다고 생각해보면 결국 디버깅의 시작점이 이 예외메시지라고 생각해요.

이 예외메시지가 디버깅의 시작 포인트라고 생각하면....! 정말 중요하다고 생각하시지 않나요? 😄

예외 메세지에 신경을 잘 쓰지 못하는 경우도 있었는데, 앞으로 더 면밀히 작성하도록 하겠습니다☺️ 답변 정말 감사합니다!

Rok93 · 2026-03-30T12:02:09Z

src/main/java/domain/Position.java

+    public static Position of(int x, int y) {
+        validateOutOfRange(x, y);
+        return CACHE.computeIfAbsent(x * 100 + y, k -> new Position(x, y));
+    }


이 상황에서 입력값의 파싱을 InputView에서 처리하는 것이 적절한지, 아니면 Position 내부에서 처리하는 것이 더 나은 설계인지 고민이 됩니다. 이에 대해 피드백 주시면 감사하겠습니다:)

Position은 좌표 값 객체인 만큼, 문자열 파싱보다는 파싱된 값의 유효성 검증에 집중하는 편이 역할이 더 선명하다고 생각해요. 😃

다만 현재처럼 InputView에서 바로 nextInt()를 사용하는 방식은 입력 예외 메시지를 세밀하게 다루기 어려워 보여, 문자열 입력은 View에서 받고 형변환과 재입력 흐름은 Controller에서 관리하는 구조도 고려할 수 있을 것 같아요. 🤔

Rok93 · 2026-03-30T12:05:17Z

src/main/java/domain/Board.java

+    public Board(Formation choFormation, Formation hanFormation) {
+        createBoard(choFormation, hanFormation);
+    }


Board 객체가 생성되는 순간에 바로 piece를 배치하기보다는, Board 객체를 생성하는 역할을 다른 객체에게 위임해보면 어떨까요?

주생성자는 생성자 파라미터로 Map<Position, Piece>를 받아서 단순히 초기화해주는 역할을 해보면 어떨까요?

Suggested change

public Board(Formation choFormation, Formation hanFormation) {

createBoard(choFormation, hanFormation);

}

public Board(Map<Position, Piece> board) {

this.board = board;

}

기존에는 기물 이동/상태 조회뿐 아니라 초기 배치(초기화)까지 함께 담당하고 있었고,
특히 초기화 로직이 커지면서 Board의 책임이 다소 무거워져 보여, 해당 부분을 BoardFactory로 분리했습니다:)
이제 Board는 생성자로 Map<Position, Piece>를 받아 상태를 초기화하고, 이후에는 본래 책임인 상태 관리와 이동에 집중하도록 정리했어요☺️
이렇게 분리하니 Board의 응집도가 높아졌습니다:)
좋은 피드백 주셔서 감사합니다!

Rok93 · 2026-03-30T12:10:59Z

src/main/java/domain/Position.java

+
+    public static Position of(int x, int y) {
+        validateOutOfRange(x, y);
+        return CACHE.computeIfAbsent(x * 100 + y, k -> new Position(x, y));


현재 범위에서는 동작에 문제는 없어 보이지만, 캐시 키를 x * 100 + y로 만드는 방식은 처음 읽는 입장에서 조금 추론이 필요한 표현처럼 느껴졌습니다. 좌표 범위에 기대는 규칙이 숨어 있어서, 의도가 더 잘 드러나는 형태면 가독성이 더 좋아질 것 같아요. 🤔

예를들면 그냥 단순히 Map<Integer, Map<Integer, Point>>로 CACHE를 관리하는게 더 직관적이지 않나 싶었어요. 😃

단순한 key여도 의미 추론이 쉽게 직관적으로 적어야하는 걸 처음 생각해본 것 같아요! 바로 적용해보겠습니다! 피드백 감사합니다🍀

Rok93 · 2026-03-30T12:13:03Z

src/main/java/domain/Side.java

+public enum Side {
+    CHO,
+    HAN,
+    NONE;


NONE의 경우 어떤 경우에 발생할 수 있는걸까요? 🤔

피드백 감사합니다! 😊

처음에 Side.NONE을 둔 이유는 Empty 칸의 진영을 명시해서, getSide() 호출이나 진영 비교 시 NullPointerException을 예방하려는 목적이었습니다.

다만 크루들과 논의해보니, Empty는 본질적으로 기물이 없는 상태이기 때문에 임의의 진영 값을 갖는 것보다 side = null이 도메인 의미상 더 자연스럽다는 결론을 내렸습니다. 그래서 현재는 Side.NONE을 제거하고 isSameSide() 중심으로 비교하도록 수정했습니다.

그런데 말씀해주신 것처럼 여전히 side.equals()를 사용할 수 있는 지점이 남아 있어 null 안전성 리스크가 완전히 사라진 것은 아닙니다.

도메인 의미(Empty의 null)와 안정성(null 방지) 사이에서, 로키라면 Side.NONE으로 안전성을 우선하실지, 아니면 null을 허용하되 위험을 추가적으로 통제하실지 피드백 해주시면 감사하겠습니다! 👍🏻

Rok93 · 2026-03-30T12:16:02Z

src/main/java/domain/piece/PieceType.java

PieceType이 기물 생성 책임까지 가지는 현재 구조는, 이번 미션 규모에서는 충분히 자연스러운 선택이라고 생각합니다. 👍👍
사용하는 쪽에서 구체적인 생성 방식과 전략을 몰라도 된다는 장점이 분명해서, 지금 단계에서 별도 Factory를 두는 것이 꼭 더 단순하다고 보이지는 않아요. 다만 생성 정책이 더 복잡해진다면 enum이 비대해질 수 있으니, 그 시점에는 책임 분리를 다시 고민해볼 수 있을 것 같습니다.

win9-tech and others added 24 commits March 25, 2026 17:29

feat: 각 플레이어 진형 입력 기능 구현

1b6e5a4

test: Board 초기화 테스트 코드 구현

7e578e4

test: Position 테스트 코드 구현

903920f

feat: Board 초기화 기능 구현

9be4c87

feat: 장기판 상태 출력 기능 구현

d96f899

refactor: Board 초기 배치 로직 중복 제거

a9010a4

feat: 움직일 기물 좌표 입력 기능 구현

08e53e3

feat: 목적지 좌표 입력 기능 구현

7b91ab8

feat: 턴제 시스템 및 장기 진행상태 출력 기능 구현

6ca130e

test: 기물 이동 테스트 코드 구현

1f698a8

feat: 기물 이동 기능 구현

0b0a46c

feat: 턴 관리를 위한 Turn 도메인 객체 추가

668aced

fix: KingTest에서 Horse로 생성하던 버그 수정

8542552

refactor: 기물 배치 로직의 하드코딩을 상수 기반으로 개선

4c158e8

refactor: movePiece 내부 로직을 메서드로 분리

4895748

refactor: MovementStrategy 패턴 적용 및 에러 메시지 상수화

50f7d45

test: 기물 테스트 코드 수정

b797150

test: 기물 이동 테스트 if 분기 제거 및 유효/무효 케이스 분리

46319b0

refactor: 기물 이동 전략 분리 및 경로 계산 구조 개선

ccf486f

docs: README.md 업데이트

3fa6172

refactor: Position 캐싱 적용

d9dd2fa

test: Position canMove 테스트 코드 구현

6b196a3

refactor: ERROR 메시지 상수처리

cfe69c0

refactor: findRoute 메서드 movementStrategy.findRoute()로 변경

88cfd05

yeo-li commented Mar 29, 2026

View reviewed changes

Rok93 requested changes Mar 30, 2026

View reviewed changes

yeo-li added 4 commits April 1, 2026 09:04

fix: findRoute() targetPosition이 List<Position>의 마지막인지 확인하도록 변경

909b7c5

feat(input): 좌표 입력 파싱 로직 추가 및 유효성 검증 강화

cb5d39d

fix: Piece.checkRoute() 에러 메세지 수정

6694397

refactor: Board 게임 비지니스 로직 제거 및 Game으로 이동

e4bb045

yeo-li added 6 commits April 2, 2026 20:55

refactor: BoardFactory 도입 및 Game/Board 테스트 생성 방식 정리

bd6c89a

refactor: Elephant 생성자 의존성 주입으로 통일

bfc79bc

refactor: BoardSpec 도입으로 보드 범위와 시작 턴 하드코딩 제거

9b17899

refactor: Position CACHE key-value 구조 변경

0cf6e2e

refactor: Side.NONE 제거 및 게임 종료 조건(isGameEnd) 도입

3f4be1b

style: 공백 및 메서드 순서 정리

8569773


		import java.util.List;

		public abstract class MovementStrategy {

Conversation

yeo-li commented Mar 29, 2026

체크 리스트

실행 전 유의 사항

1. 콘솔의 폰트를 D2Coding으로 설정해주세요.

2. 장기판의 상단이 한, 하단이 초에요.

3. 좌표 입력은 반드시 숫자로 입력해주세요.

어떤 부분에 집중하여 리뷰해야 할까요?

1. 이동 규칙 검증 책임 분리 구조의 적절성

2. 예외 메시지 일관성과 입력 안정성

3. 테스트 커버리지의 적절성

리뷰어에게

Uh oh!

yeo-li left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Rok93 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yeo-li Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yeo-li Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yeo-li Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

yeo-li Apr 1, 2026 •

edited

Loading

yeo-li Apr 2, 2026 •

edited

Loading

yeo-li Apr 2, 2026 •

edited

Loading