Twitter 예제 따라 하기
이 가이드는 Panolayer의 Twitter 예제에 있는 게시물 삭제 버그를 따라갑니다. 이슈를 읽고, 설명을 따라 코드로 돌아가며, 병합할지 결정하기 전에 검증 요약을 이해합니다.
따라 하려면 샘플 앱 사용해 보기에서 Twitter Clone을 엽니다. twitter-starter로 열립니다. 전체 설정 및 수정 안내는 Panolayer로 첫 버그 수정하기를 참고하세요. 스크린샷은 한 번의 기록된 실행을 보여 주며, 이슈 순서와 개수는 다를 수 있습니다.
이슈에서 시작
코드베이스를 열면 Panolayer 검증 엔진이 실행되기 시작합니다. 코드베이스를 함수, 심볼, 종속성 단위까지 파싱하고, 시각적 아키텍처를 구축하며, 버그를 식별하기 위해 코드를 검사합니다.
이슈를 엽니다. 이 예제에서는 실행이 완료되었고 상태가 검증 완료로 표시됩니다. 조사가 필요한 이슈는 주의 필요 아래에 표시됩니다.
검증 완료는 실행을 설명합니다. 실행이 완료되었음을 의미합니다. 결과를 읽고 실패를 발견했는지 확인하세요.
삭제 이슈 읽기
예제의 첫 번째 이슈는 조건이 확인된 삭제를 중단할 수 있다고 보고합니다:
추가
canDelete가드는 사용자 확인에도 불구하고 삭제를 막을 수 있으며, 이는 명시된 현재 게시물 삭제 동작과 상충합니다.
규칙은 함수의 동작에 대한 기대입니다. 즉, 무엇을 반환해야 하는지, 어떤 작업을 수행해야 하는지, 또는 다른 코드가 해당 함수에 기대하는 것이 무엇인지입니다. 여기서 기대는 사용자가 확인한 후 현재 게시물을 삭제하는 것에 관한 것입니다.
이슈의 파일, 함수, 상태, 설명을 함께 읽으세요:
| 확인할 항목 | 알려주는 내용 |
|---|---|
components/Post.tsx | 조사할 함수가 포함된 파일입니다. |
handleDelete() | 동작이 확인된 함수입니다. |
| 실패 | 확인된 동작이 규칙을 충족하지 않았습니다. |
| 심각도 3 · 기능성 | 이슈의 심각도와 범주는 조사 우선순위를 정하는 데 도움이 됩니다. |
| 세부 정보 | 설명과 소스 위치는 이슈가 보고된 이유를 이해하는 데 도움이 됩니다. |
세부 정보를 클릭하세요. 설명에 따르면 이 함수는 규칙에서 설명한 삭제를 완료하기 전에 canDelete가 false일 때 조기 반환할 수 있습니다. 소스 참조는 관련 코드를 가리킵니다.
무엇을 변경할지 결정하기 전에 규칙이 의도한 동작과 일치하는지 확인하세요. 기대가 잘못되었다면 규칙을 수정하세요. 코드가 잘못되었다면 코드를 수정하세요. 변경은 다른 파일의 호출자에도 영향을 줄 수 있으므로 결과에 표시된 영향을 받는 호출자를 따라가세요.
상태는 무엇을 의미하나요?
상태를 설명과 적용되는 코드와 함께 읽으세요.
| 결과 | 해석 방법 |
|---|---|
| 통과 | 평가된 규칙이 확인한 코드에 대해 통과했습니다. 이는 애플리케이션의 모든 가능한 동작이 아니라 해당 규칙을 설명합니다. |
| 실패 | 평가된 규칙이 성립하지 않았습니다. 설명을 읽고 소스를 검사하여 무엇을 수정해야 할지 결정하세요. |
| 대기 중 또는 실행 중 | 결과가 준비되지 않았습니다. 결론을 내리기 전에 검사가 끝날 때까지 기다리세요. |
| 사용할 수 없음 | 검사를 완료할 수 없었습니다. 함께 표시된 메시지를 읽고 보고된 문제를 해결한 후 다시 확인하세요. |
| 확인되지 않음 | 기대가 평가되지 않았습니다. 통과 결과가 아닙니다. |
검증을 완료할 수 없다면 보고된 오류를 따라가고 설정 및 agent 문제 해결을 참조하세요.
버그를 수정하고 검증을 다시 실행하세요
삭제 이슈에서 수정을 클릭한 다음 Panolayer Agent를 선택하세요. Panolayer가 이슈 컨텍스트를 agent에 전달하므로 버그를 설명하는 프롬프트를 작성할 필요가 없습니다.
Panolayer Agent는 기본 내장되어 있습니다. 설치 후 다른 지원 agent를 사용할 수도 있습니다. 지원되는 agent를 참고하세요.
agent는 자체 Git worktree에서 작업하므로 편집 내용이 브랜치와 분리됩니다. My Agents에서 작업을 따라가거나, 실행 카드에서 열기를 클릭해 agent의 활동과 변경 사항을 검사하세요.
코드가 변경되면 Panolayer는 영향을 받는 함수와 연결된 코드를 다시 확인하며, 다른 파일의 호출자도 포함합니다. 이를 통해 agent가 편집한 줄 외의 회귀도 잡을 수 있습니다.
회귀는 변경으로 인해 새로 발생한 문제입니다. 수정 중 검증에서 회귀를 발견하면 agent가 이를 복구하고 병합을 요청하기 전에 검증을 다시 실행할 수 있습니다. 따라서 작업은 검토할 준비가 되기 전에 여러 번의 검증 실행을 거칠 수 있습니다.
병합 전 검증 요약 읽기
이 실행이 끝나면 Panolayer는 Panolayer Agent가 병합할 준비가 되었습니다라는 메시지를 표시합니다. 대화상자는 작업 중 검증이 확인하고 복구한 내용을 요약합니다.
| 요약 필드 | 이번 실행 | 의미 |
|---|---|---|
| 복구된 실패 | 1 | 이 작업은 작업 시작 전에 이미 존재하던 실패를 복구했습니다. |
| 통과한 규칙 | 21개 중 14개 | 변경된 코드에서 21개 규칙 중 14개가 통과했습니다. 이 수치는 상태 메시지 및 별도의 기존 실패 줄과 함께 확인하세요. |
| 검증 실행 | 1 | 이 작업 중 검증 실행 한 번이 결과에 도달했습니다. 개별 테스트나 규칙이 아니라 검증 실행 횟수를 셉니다. |
| 변경된 파일 | 4 | 작업에서 네 개 파일을 변경했습니다. 테스트와 종속성 파일을 포함한 전체 변경 집합을 검토하세요. |
상태 메시지에는 새로운 실패, 경고 또는 확인되지 않은 규칙이 없습니다. 이 메시지를 수치와 함께 확인하세요. 이 메시지는 이번 작업의 결과를 설명하고, 다음 줄은 작업 시작 전부터 남아 있던 실패를 설명합니다.
“회귀 감지됨”이 표시되면 어떻게 되나요?
일부 실행에는 회귀 감지됨도 표시됩니다. 이는 작업 중 검증에서 감지한 새로운 문제를 보고하여, 해당 문제가 대상 브랜치에 들어가지 않도록 돕습니다. 최신 결과를 확인해 아직 주의가 필요한 항목을 파악하세요. 이 수치는 현재 해결되지 않은 실패 수가 아니라 작업 중 감지된 횟수를 나타냅니다.
이 필드는 이 스크린샷에 표시되지 않습니다. 삭제 예시는 복구된 기존 실패 하나를 보여 주며, 수정 중 감지된 회귀를 보여 주지는 않습니다.
Why can it be ready to merge when failures remain?
Panolayer compares the result with the baseline: the state of the codebase before the change. This separates problems introduced by the task from problems that were already there.
- A new failure was introduced by the change and needs investigation before you accept the work.
- A pre-existing failure was present before the task started. It can still matter, but this task did not introduce it.
- A repaired failure was present before the task and was fixed during the work.
In the screenshot, the dialog reports 7 pre-existing failures that do not block this merge. The selected deletion issue was repaired, and those other issues remain separate work.
The repository’s issue list and an agent’s verification summary can cover different scopes. The issue list shows what needs attention in the codebase; the merge summary describes the agent’s work against its baseline. An agent’s result can report no new failures while the repository still has pre-existing issues.
You can assign a pre-existing issue as another task using Fix. That gives the agent a specific issue to work on next.
Ready to merge does not mean every issue in the repository is resolved. Read what this task repaired, what it introduced, and what was already there.
Decide what reaches your branch
You control the merge. Before accepting the result:
- Check that the repaired issue matches the bug you asked the agent to fix.
- Read the verification summary, including any new failures, warnings, or checks that could not finish.
- Open Details for more context and inspect the agent’s changed files. Review the relevant tests and run the application when the behavior needs a runtime check.
- Confirm the target branch. Choose Merge into main when you’re satisfied, or Not now to keep reviewing.
Verification gives you evidence for the decision. Read it alongside the code and relevant tests; it does not cover every possible bug.