검토가 필요한 항목 확인
여러 agent의 작업 트리와 commit되지 않은 변경 사항을 한곳에서 확인하세요. 위험한 변경 사항을 검토하고, 수정이 필요한 항목을 조사한 뒤, 변경 사항 페이지에서 코드를 commit하세요.
이 가이드는 Panolayer의 Twitter 예제인 twitter-starter를 사용합니다. Panolayer로 첫 버그 수정하기를 따라 했다면, 이 단계에 따라 삭제 수정 사항을 검토하세요.
스크린샷과 짧은 동영상은 동일한 Twitter 앱의 여러 변경 사항(서식, 검색, 내보내기, 저장된 게시물 변경 포함)을 보여 줍니다. 파일 목록, 위험 점수, commit ID는 검토 중인 작업에 따라 달라집니다. 스크린샷을 클릭하면 전체 크기로 확인할 수 있습니다.
사이드바에서 변경 사항을 여세요. 오른쪽에서 서로 다른 작업 트리와 agent의 commit되지 않은 코드를 볼 수 있습니다. 작업 트리를 선택하면 해당 agent가 변경한 내용을 볼 수 있으며, 파일은 위험도가 높은 순서에서 낮은 순서로 점수가 매겨집니다.
agent의 작업 트리 사이를 이동하고, 변경 사항을 검토하고, 이 페이지에서 코드를 commit하세요. 위험 점수를 통해 어떤 파일에 주의가 필요하고 수정이 필요할 수 있는지 빠르게 확인할 수 있습니다.
기록에서 기존 commit을 선택해 기록된 내용을 검토할 수도 있습니다. 삭제 수정 사항을 이미 병합했다면 거기에서 찾을 수 있습니다. 해당 병합으로 변경 사항이 이미 로컬에 기록되어 있습니다.
위험도가 높은 순서에서 낮은 순서로 변경 사항 검토
변경 사항은 파일에 위험한 것부터 위험하지 않은 것까지 점수를 매기고 무엇이 변경되었는지 설명합니다. commit하기 전에 검토가 필요하고 수정이 필요할 수 있는 항목을 파악하려면 위험도가 가장 높은 파일부터 시작하세요.
위험 스펙트럼, 위험 막대, 중첩 간에 전환하여 동일한 변경 사항을 세 가지 시각적 보기로 살펴보세요.
위험 스펙트럼
변경된 파일이 왼쪽의 높은 위험에서 오른쪽의 낮은 위험까지 가로 스펙트럼을 따라 배열된 것을 확인하세요.
위험 막대
파일을 위험도순으로 정렬된 막대로 비교하세요. 이 보기는 매우 위험함부터 위험하지 않음까지 이어지므로 변경 사항 중 주의가 필요한 부분을 쉽게 확인할 수 있습니다.
중첩
UI 변경, 로직 변경, 위험 변경이 겹치는 부분을 확인하세요. 그룹화된 파일은 변경 사항의 이러한 부분이 서로 어떻게 관련되는지 보여 줍니다.
주의가 필요한 변경 사항 살펴보기
위험 개요는 검토에 집중할 위치를 보여 줍니다. 특정 변경 사항을 더 자세히 이해하려면 파일을 여세요.
- 그래프 또는 변경된 파일 목록에서 파일을 선택합니다.
- 파일 경로, 변경 요약, 위험 설명을 읽습니다.
- 나란히 비교하려면 분할을, 한 화면에서 변경 사항을 읽으려면 인라인을 선택합니다.
- 관련 함수와 해당 호출자를 따라 변경 사항을 살펴봅니다. 관련 테스트, 구성, 의존성 파일도 확인하세요.
삭제 수정 사항의 경우 components/Post.tsx를 열고 handleDelete()를 검사하세요. 변경 사항이 보고된 canDelete 조건을 어떻게 해결하는지, 그리고 사용자 확인, 삭제 요청, 성공 응답 처리가 여전히 함께 타당한지 확인하세요.
분석을 읽고 우려 사항에 대해 질문하기
Panolayer Agent의 심층 분석은 변경 사항에서 항상 사용할 수 있습니다. Panolayer Agent – 심층 분석 패널을 열어 평가, 우려 사항, 소스 참조를 읽으세요. 우려 사항을 관련 파일로 따라가서 무엇을 주의해야 하는지 이해하세요.
시청: Twitter 내보내기 변경 사항 분석 살펴보기
기존 분석 클립은 Twitter 앱의 내보내기 변경 사항을 보여 주며, 우려 사항은 영향을 받은 파일과 연결되어 있습니다.
Panolayer Agent와 검토를 계속하려면 채팅을 사용하세요. 확인 중인 동작과 관련된 질문을 하세요. 예:
“이 변경 사항은 삭제 문제를 어떻게 해결하며, 예상 동작을 다루는 테스트는 무엇인가요?”
답변을 사용하여 변경 사항을 탐색하고 불분명한 부분을 조사하세요.
검토와 함께 검증 결과 읽기
변경 사항은 영향을 받은 함수에 대한 검증 결과를 표시할 수 있습니다. 실패한 규칙과 아직 대기 중이거나 사용할 수 없는 검사를 읽고, 해당 설명을 따라 코드로 이동하세요.
위험 개요는 어디를 살펴볼지 선택하는 데 도움이 됩니다. 심층 분석은 조사할 우려 사항을 제공합니다. 검증은 코드 동작에 대한 기대치와 비교한 검사를 보고합니다. diff 및 관련 테스트와 함께 읽으세요.
삭제 예시의 경우 선택한 실패가 수정되었는지 확인하고, 기존 문제와 별도로 새로운 실패를 검토하세요. 요약 필드와 상태는 검증 결과 이해하기를 참조하세요.
변경 사항에 런타임 확인이 필요하면 애플리케이션을 실행하세요. 이 수정 사항의 경우 게시물 삭제를 시도하고 확인 또는 취소가 예상대로 동작하는지 확인하세요.
Merge the agent’s work when you’re satisfied
When the agent requests a merge, review the verification summary and confirm the target branch. Choose Not now to keep reviewing, or Merge into main to bring the work into the sample’s main branch.
The Merged into main confirmation shows the commit ID. This workflow records the agent’s change in local Git history; you do not need to commit that same change again.
Commit any uncommitted edits
Use this step for your own edits or other uncommitted work in the current workspace. If the agent’s merge already saved the change and you have no further edits, continue to History.
- Check the full changed-file list.
- Review the suggested commit message. Use Edit message if it needs to describe the change more clearly.
- Choose Commit to save the changes to the local branch. Choose Commit & Push if you also want to send the commit to a configured remote.
A Panolayer commit includes every changed file in the workspace. Use Git directly if you need to stage only part of the change. Read any reported check failures before deciding to commit; a commit can still be created when checks fail.
Confirm the result in History
Open History and find the new commit using its message, author, and commit ID. Select it to inspect the recorded change, then return to Working tree to check for remaining uncommitted edits.
Watch: Confirm a Twitter saved-post change in merge confirmation and History
This existing clip follows a saved-post change in the Twitter app. Use the commit ID from your own merge confirmation to find your change.
For the deletion fix, you should be able to find its recorded change and inspect the files that landed. Check that no unexpected uncommitted edits remain.
Push when you’re ready to share the commit
A merge or commit saves work locally. To send an existing local commit to your Git remote, open Git and choose Push.
Pushing requires a configured remote and permission to write to it. If the sample has no remote, the local commit completes this walkthrough. If a push reports an error, read it and resolve the remote or sign-in problem before trying again.
Use your Git host for pull requests and team review.