3분 안에 이해하기
Velium은 Agent가 일하는 속도와 사람이 결정하는 안전함을 하나의 작업 흐름으로 연결합니다.
결과를 확인한 뒤 사람의 결정에 따라 기록하거나 다시 실행합니다.
- 목표 입력
만들고 싶은 결과를 한 문장으로 적습니다.
- 작업 분해
Velium이 실행 가능한 할 일로 나눕니다.
- Agent 실행
Agent가 작업하고 결과와 근거를 남깁니다.
- 결과 검토
무엇을 했고 무엇이 바뀌는지 확인합니다.
- 승인할까요?
결정은 사람이 합니다.
- NO수정 요청
보완한 뒤 Agent 실행으로 돌아갑니다.
- YES프로젝트에 기록
승인한 결과만 다음 작업의 기준이 됩니다.
승인된 task를 실행하고 결과, 검사와 변경안을 남깁니다.
바뀔 내용과 근거를 확인한 뒤 승인하거나 거절합니다.
확정한 결과를 다음 작업이 이어받을 프로젝트 상태로 남깁니다.
5분 빠른 시작
처음 연결하는 순간부터 첫 변경을 승인하는 순간까지 순서대로 따라가세요.
현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘.- 01
당신 Agent를 연결합니다
Velium이 Agent의 작업 결과를 받을 수 있도록 한 번 연결합니다.
- Project Workspace 상단에서 Agent Access를 엽니다.
- 사용할 client와 token 유효시간을 선택합니다.
- 한 번만 표시되는 token과 stdio 설치 설정을 각각 복사합니다.
- Codex, Claude Code, Cursor 등 MCP-compatible client에 설정을 등록합니다.
주의Bearer token은 다시 볼 수 없습니다. 저장소, 문서, 스크린샷에 남기지 마세요.
입력값과 성공 상태 자세히 보기 +
- Client name
- Codex Velium MCP목록에서 알아볼 수 있는 이름
- Client type
- codexcodex, claude_code, cursor, vscode 등
- 유효시간
- 24시간1시간, 8시간, 24시간 중 선택
- Role
- Executor조정은 Coordinator, 독립 검토는 Critic
- Workstream
- generalbackend, testing처럼 쉼표로 구분 가능
- 동시 step
- 1플랜과 정책이 허용한 범위 안에서 선택
화면에 표시되는 stdio 연결 정보transport=stdio command=npx args=-y velium-mcp-bridge@0.1.0 VELIUM_MCP_URL=https://<your-host>/api/mcp VELIUM_MCP_BEARER_TOKEN=<한 번 표시된 token>정상적으로 보이는 상태- Token 기록: 활성
- Agent 상태: 연결 대기 → 대기
- Runtime 상태: idle
막혔을 때활성 token 한도에 도달하면 기존 token을 폐기해야 합니다. 연결 대기가 계속되면 URL, token env와 client 재시작 여부를 확인하세요.
완료 기준Agent Access에 연결한 client가 활성 상태로 표시됩니다.
- 02
Agent 현재 폴더를 프로젝트로 정리해 달라고 요청합니다
프로젝트 생성은 브라우저 폼이 아니라 연결한 Agent에게 요청합니다.
- 프로젝트로 만들 로컬 폴더에서 Agent를 실행합니다.
- “현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘”라고 요청합니다.
- Agent가 Git 상태, 주요 문서, package와 config 파일을 조사합니다.
- Agent가 첫 목표, 작업 구조와 생성 근거를 Velium에 남깁니다.
입력값과 성공 상태 자세히 보기 +
- 실행 위치
- 프로젝트 root 폴더Git과 package/config를 함께 읽을 수 있는 위치
- 요청 문장
- 현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘.name, goal, context는 생략 가능
- 사용 tool
- velium.create_project브라우저가 아니라 연결된 Agent가 호출
- 같은 token
- 자동 project binding생성 후 token을 교체하지 않음
정상적으로 보이는 상태- 최소 1개의 Goal
- Goal 아래 최소 2개의 node
- 첫 Graph Revision
- Reasoning Trace
- localWorkspace creation evidence
막혔을 때새 프로젝트가 보이지 않으면 Agent 결과의 projectId, revisionId, traceId와 toolEvidence를 확인하고 같은 token으로 생성했는지 점검하세요.
완료 기준프로젝트 선택기에 새 프로젝트가 보이고 첫 Project Graph가 열립니다.
- 03
당신 첫 Project Graph를 확인합니다
목표와 작업, 결정과 위험이 어떤 관계로 정리됐는지 확인합니다.
- Goal과 Milestone을 먼저 읽어 프로젝트 방향을 확인합니다.
- Backlog부터 Done까지 task가 놓인 진행 상태를 확인합니다.
- 강조된 focus task를 선택하고 오른쪽 inspector를 읽습니다.
- Risk, blocker, decision이 현재 작업과 어떻게 연결됐는지 확인합니다.
입력값과 성공 상태 자세히 보기 +
- 진행 lane
- Backlog · Ready · Active · Blocked · Review · Donetask만 진행 lane에 배치
- 배경 맥락
- Goal · Milestone · Decision · Risk · Blockertask가 아닌 node는 backboard context
- Task 번호
- 2-3Milestone 2의 세 번째 task
- Focus
- 한 번에 1개가장 중요한 단일 task만 강하게 강조
정상적으로 보이는 상태- 선택 node와 inspector 내용이 일치
- connector가 선행·의존 관계를 표시
- Risk와 blocker가 관련 task 기준으로 강조
막혔을 때node 선택은 화면에서만 바뀌며 편집이 아닙니다. 내용이나 상태를 바꾸려면 Agent에게 GraphPatch 제안을 요청하세요.
완료 기준지금 해야 할 일과 막힌 이유를 한 문장으로 설명할 수 있습니다.
- 04
Agent Agent에게 승인된 작업을 맡깁니다
Agent는 작업을 실행하고 결과, 파일 변경과 검사를 별도 기록으로 남깁니다.
- 더 작게 나누려면 Expand, 빠진 위험은 Critique, 다음 행동은 Plan Next를 요청합니다.
- Agent Runs에서 실행 중, 대기, 완료 상태를 확인합니다.
- 변경된 파일과 test/check evidence를 확인합니다.
- 실행 기록과 승인된 Project Graph가 분리되어 있는지 확인합니다.
입력값과 성공 상태 자세히 보기 +
- Expand
- 작업 분해큰 node를 더 작은 하위 node로 제안
- Critique
- 빈틈 검토질문, 리스크, 모순, blocker 제안
- Plan Next
- 다음 행동현재 상태에서 다음 task 후보 제안
- Run 상태
- assigned · running · waiting_gate완료 외에도 대기 원인을 확인
- 기본 step
- plan · execute · test · verify승인된 task에 idempotent하게 생성
정상적으로 보이는 상태- Agent identity와 맡은 task가 표시
- changed files 기록
- test/check 결과
- 완료 또는 waiting_gate 이유
- 관련 evidence
막혔을 때Run이 waiting_gate면 자동 재시작을 기다리지 말고 Gate 내용을 확인하세요. 검사 근거가 없으면 승인 전에 test 또는 verify를 다시 요청하세요.
완료 기준Agent가 무엇을 했고 어떤 근거를 남겼는지 확인할 수 있습니다.
- 05
당신 변경안을 검토하고 직접 결정합니다
Agent의 제안은 적용되지 않은 상태로 멈추며, 최종 결정은 사람이 합니다.
- Patch Review에서 대기 중인 변경안을 선택합니다.
- 변경 목적, 이유, operation과 validation 결과를 순서대로 읽습니다.
- 근거가 충분하면 승인하고, 부족하면 거절한 뒤 수정 요청을 남깁니다.
- Timeline에서 결정과 새 Revision이 기록됐는지 확인합니다.
입력값과 성공 상태 자세히 보기 +
- Operations
- 변경 operation 수add_node, update_node, add_edge 등
- Validation
- 검증 통과 · 주의 필요 · 검증 실패stale이면 재제안 필요
- Before / After
- 적용 전후 요약node와 edge 변화 규모 확인
- Evidence
- 최대 9개 항목Diff, files, tests, acceptance, risk 등
- 결정 버튼
- 거절하고 graph 유지 / 승인 후 graph에 적용승인 차단 상태에서는 적용 불가
정상적으로 보이는 상태- 대기 수가 1 감소
- 승인 또는 거절 수가 증가
- 승인 시 새 Revision
- Timeline에 사용자 결정 기록
막혔을 때‘재제안 필요’ 또는 ‘검증 실패’는 승인할 수 없습니다. 최신 Project Graph를 기준으로 Agent가 새 GraphPatch를 제안해야 합니다.
완료 기준승인한 변경만 Project Graph에 적용되고 Revision으로 남습니다.
매일은 이 순서로 사용합니다
프로젝트를 열고, 일을 맡기고, 결과를 확인하고, 결정한 뒤 다음 작업으로 이어갑니다.
- 01시작오늘의 focus task 확인
Overview / Board
현재 작업과 blocker를 이해함 - 02위임Agent에게 승인된 task 실행 요청
Agent Runs
실행 주체와 상태가 표시됨 - 03관찰결과, 검사, 파일 변경 확인
Agent Runs / Evidence
결과를 판단할 근거가 충분함 - 04결정변경안 승인 또는 거절
Patch Review
사용자 결정이 기록됨 - 05이어가기적용 결과와 다음 작업 확인
Timeline / Project Graph
새 Revision과 다음 focus를 확인함
화면별 기능 안내
어떤 화면을 언제 열어야 하는지, 무엇을 확인하고 다음에는 무엇을 해야 하는지 정리했습니다.
먼저 공통 화면을 익히세요
작업할 프로젝트를 바꾸고 node와 Artifact 수를 확인합니다.
현재 view, Patch Review, Agent Access, Project와 Source 상세를 엽니다.
Execution, Knowledge, Connections, Control 화면을 전환합니다.
선택한 view의 graph, board, 목록과 검토 내용을 표시합니다.
선택한 task의 목표, 연결 관계, 위험과 변경 상태를 자세히 봅니다.
Agent Run, MCP event, GraphPatch와 문제 수를 빠르게 확인합니다.
실행 화면
오늘의 작업을 선택하고 Agent의 실행과 변경을 검토하는 핵심 화면입니다.
01Overview프로젝트를 열고 현재 상황을 빠르게 파악할 때+
- focus task
- 진행 요약
- 검토 대기와 blocker
가장 중요한 task 또는 검토 대기를 엽니다.
02Boardtask를 진행 상태별로 확인할 때+
- Backlog · Ready · Active
- Blocked · Review · Done
- milestone별 task 번호
현재 focus task와 다음 Ready task를 비교합니다.
03Project Graph목표, 작업, 결정과 위험의 관계를 볼 때+
- task connector
- 선택 node inspector
- goal · milestone · risk 맥락
node를 선택해 관련 근거와 다음 행동을 확인합니다.
주의브라우저에서 node를 직접 편집하지 않습니다. 변경은 GraphPatch로 제안됩니다.
04Patch ReviewAgent의 변경안을 적용 전에 검토할 때+
- 변경 목적과 rationale
- operation 목록
- validation과 evidence
승인하거나 거절하고 결정 이유를 남깁니다.
주의승인 전에는 Project Graph가 바뀌지 않습니다.
05Timeline어떤 결정이 언제 일어났는지 확인할 때+
- Graph Revision
- Patch 승인·거절
- Gate와 Agent activity
원인이 된 변경안 또는 관련 task로 이동합니다.
06Agent RunsAgent가 실제로 수행한 일을 확인할 때+
- 실행 주체와 상태
- step 진행
- changed files · checks · evidence
실패나 Gate 대기 항목을 먼저 처리합니다.
주의Agent Run 완료와 Project Graph 변경 완료는 다른 상태입니다.
지식 화면
프로젝트를 다시 설명하지 않도록 문서, 결정, 구조와 검증 근거를 모읍니다.
01ArtifactsPRD, 설계 문서와 작업 브리프를 찾을 때+
- 활성 version
- 연결된 node
- 검토와 활성화 결정
현재 작업에 필요한 artifact를 열거나 새 version을 검토합니다.
02Architecture프로젝트 구조와 주요 기술 경계를 파악할 때+
- 시스템 영역
- 의존 관계
- 관련 결정과 artifact
변경하려는 영역의 결정과 위험을 함께 확인합니다.
03Decisions왜 이런 방향을 선택했는지 찾을 때+
- 결정 내용
- 이유와 대안
- 영향받는 task와 artifact
현재 결정과 충돌하는 변경이 있는지 확인합니다.
04Repository Map코드 저장소의 주요 폴더와 역할을 이해할 때+
- package와 app 경계
- 주요 config
- 작업 관련 경로
Agent에게 필요한 경로 범위를 명확하게 전달합니다.
05Drift문서, 코드와 승인 상태가 어긋났는지 확인할 때+
- 차이가 발생한 대상
- 심각도
- 검토 상태와 evidence
차이를 검토하고 필요한 GraphPatch 또는 artifact 갱신을 요청합니다.
06Evidence결과가 실제로 검증됐는지 확인할 때+
- test와 check 결과
- 파일 변경 근거
- 생성 주체와 시각
부족한 검증을 Agent에게 다시 요청합니다.
07Risks리스크, blocker와 열린 질문을 관리할 때+
- 심각도와 상태
- 영향받는 task
- 대응 행동과 owner
막힌 작업보다 먼저 해소해야 할 위험을 선택합니다.
연결 화면
Agent와 GitHub를 연결하되 credential과 외부 실행 권한은 분리합니다.
01GitHub RepositoryGitHub App을 설치하고 repository를 project에 연결할 때+
- installation 상태
- 연결 repository
- Issues permission과 생성 결과
Agent의 Issue 초안을 외부 작업 Gate에서 검토합니다.
주의GitHub Issue 상태가 Project Graph를 자동 변경하지 않습니다.
02Agent AccessAgent token을 발급하거나 연결을 관리할 때+
- client와 만료 시각
- Coordinator · Executor · Critic role
- workstream · 실행 상태 · Gate 대기
필요 없는 token을 폐기하고 role과 작업 범위를 확인합니다.
주의token 원문과 stdio 설정은 발급 시 한 번만 표시됩니다.
제어 화면
프로젝트 실행 규칙과 개인·workspace·project 설정의 적용 범위를 관리합니다.
01Project PolicyAgent의 변경 범위와 검토 규칙을 확인할 때+
- 허용·보호 경로
- 동시 실행과 timeout
- 독립 검토와 Gate 요구
정책 변경 preview와 validation을 확인한 뒤 저장합니다.
주의보호 경로와 production Gate 같은 필수 안전 정책은 끌 수 없습니다.
02Settings개인, workspace, project 기본값을 바꿀 때+
- 현재 값
- 상속 출처
- plan에 따른 사용 가능 범위
변경 범위와 저장되지 않은 값을 확인합니다.
핵심 화면의 필드와 상태
화면에서 실제로 보이는 이름과 판단 기준을 그대로 정리했습니다.
01Agent Access 발급 필드+
연결 목록에서 구분할 이름
Codex Velium MCP사용하는 MCP-compatible client
codex, claude_code, cursor, vscode 등token이 자동 만료되는 시간
1시간 · 8시간 · 24시간Agent의 책임 범위
Coordinator · Executor · Critic하위 Agent가 보고할 Coordinator
Root 또는 활성 CoordinatorAgent가 맡을 작업 영역
general 또는 backend, testing한 Agent가 동시에 소유할 step 수
기본 1Executor가 없을 때 Coordinator 동작
disabled 또는 when_no_executorRole 경계: Coordinator는 계획과 배정을 조정하고, Executor는 구현·테스트를 실행하며, Critic은 다른 client가 만든 evidence를 독립 검토합니다. 어느 role도 사용자 승인을 대신할 수 없습니다.
02Patch Review 승인 판단+
승인 가능operation과 evidence를 확인한 뒤 결정합니다.
승인 가능warning의 영향과 Before/After를 추가로 확인합니다.
승인 불가기준 Revision이 달라졌으므로 최신 Graph 기준으로 다시 제안합니다.
승인 불가삭제된 node, 잘못된 edge 등 error를 수정해 새 Patch를 제안합니다.
읽는 순서: PATCH ID와 목적 → Operations → Validation → Before/After → Evidence 9개 항목 → Reasoning Trace → 승인 또는 거절.
03Project Graph lane 상태+
아직 시작 순서가 정해지지 않은 task
선행 조건이 충족되어 시작 가능한 task
현재 Agent 또는 사용자가 진행 중인 task
원래 stage를 유지한 채 blocker가 겹쳐진 상태
실행 결과와 evidence를 검토하는 task
완료 근거와 필요한 승인이 갖춰진 task
번호 읽기: `2-3`은 두 번째 Milestone의 세 번째 task입니다. Milestone마다 기본 task slot은 최대 5개입니다.
04Project Settings 9개 영역+
timezone, active/paused/archived 상태
target branch, allowed/protected paths, max changed files, worktree
write/read 동시성, timeout, lease TTL, retries
Executor와 다른 client의 독립 Reviewer 요구
고정 stage와 low-risk 자동 완료 정책
보호 경로, production, custom Gate 정책
Markdown 경로, drift 수준, release readiness
Gate 요청과 AgentRun 실패 알림
beta opt-in과 raw log 보존 기간
저장 순서: 값을 수정하고 Policy Preview를 실행합니다. warning과 issue를 확인한 뒤 valid일 때 Save Changes를 누릅니다. 비어 있는 값은 Workspace 또는 System 기본값을 상속합니다.
무엇을 누가 결정하나요?
실행, 프로젝트 변경, 외부 작업은 서로 다른 상태와 승인 경계를 가집니다.
Agent Run
Agent가 작업하고 파일 변경과 검사를 남깁니다.
- Agent
- 실행과 evidence 기록
- 당신
- 결과 확인
- Graph
- 변경 없음
GraphPatch
Project Graph에 적용될 구조화된 변경안입니다.
- Agent
- 변경안 제안
- 당신
- 승인 또는 거절
- Graph
- 승인 시 Revision
External Gate
GitHub Issue처럼 외부에 영향을 주는 실행안입니다.
- Agent
- 실행안 제안
- 당신
- 외부 실행 승인
- Server
- 승인 후 한 번 실행
GitHub Issue도 확인 후 생성합니다
Agent는 Issue 초안을 만들고, 실제 GitHub 작업은 사용자가 승인한 뒤 서버가 실행합니다.
- 01GitHub App 연결
GitHub Repository 화면에서 연결을 시작합니다.
- 02접근 범위 선택
account 또는 organization과 허용할 repository를 선택합니다.
- 03Project에 매핑
선택한 repository를 현재 Velium project와 연결합니다.
- 04Agent가 초안 제안
Agent는 title, body, label이 포함된 Issue 생성안을 남깁니다.
- 05당신이 승인
외부 작업 Gate에서 실제로 생성할 내용을 확인합니다.
- 06서버가 한 번 실행
승인 후 서버가 Issue를 만들고 링크와 evidence를 기록합니다.
Velium 계정에 연결된 GitHub App installation 수입니다.
해당 repository에서 Issue를 만들 수 있는 권한입니다. none이면 GitHub App 권한을 다시 확인합니다.
현재 Velium project와 repository가 연결됐는지 나타냅니다.
repository mapping만 변경합니다. GitHub App installation 자체를 삭제하지는 않습니다.
repository, title, body, labels, assignees를 확인한 뒤 승인합니다.
01Agent는 GitHub credential을 받거나 GitHub API를 직접 호출하지 않습니다.
02Issue가 닫혀도 Velium task가 자동으로 Done이 되지 않습니다.
03Graph 변경이 필요하면 별도 GraphPatch를 다시 검토합니다.
플랜과 사용 권한을 확인합니다
가격표의 플랜 이름과 실제로 사용할 수 있는 서버 권한은 구분됩니다.
가격, 기본 한도와 제공 기능을 설명합니다.
결제 기간, 갱신, 해지 예약과 재개 상태를 보여줍니다.
검증된 구독 상태에서 계산한 현재 사용 가능 범위입니다.
프로젝트, Graph 규모, token과 실행 한도를 확인합니다.
현재 기간 동안 정상 사용
사용량과 다음 결제일을 확인합니다.
체험 기간 사용
trial 종료일과 전환 가능한 plan을 확인합니다.
결제 확인 또는 복구 필요
결제 수단과 서버 재검증 결과를 확인합니다.
현재 기간 종료일에 해지 예정
필요하면 종료일 전 ‘구독 재개’를 누릅니다.
일부 서버 권한 제한
Billing 오류와 entitlement 원인을 먼저 해결합니다.
문제가 생기면 여기부터 확인하세요
증상을 기준으로 확인할 화면과 다음 행동을 빠르게 찾을 수 있습니다.
01Agent가 연결되지 않음+
먼저 확인token 만료, client의 stdio 설정, Agent Access 상태
다음 행동새 token을 발급하거나 기존 연결을 폐기한 뒤 다시 등록합니다.
02새 프로젝트가 보이지 않음+
먼저 확인Agent의 생성 결과와 현재 project binding
다음 행동같은 token으로 생성했는지 확인하고 프로젝트 선택기를 새로 확인합니다.
03Patch Review가 비어 있음+
먼저 확인Agent Run 결과와 proposal 상태
다음 행동Agent에게 결과 요약이 아니라 변경안 제안을 명시적으로 요청합니다.
04승인 버튼이 차단됨+
먼저 확인validation warning/error와 필요한 Gate
다음 행동누락된 evidence를 보완한 뒤 새 proposal 또는 validation을 요청합니다.
05승인했지만 변경이 안 보임+
먼저 확인Timeline의 결정과 Graph Revision
다음 행동Revision 생성 여부와 적용 실패 evidence를 확인합니다.
06GitHub Issue가 생성되지 않음+
먼저 확인repository mapping, Issues permission, 외부 Gate 상태
다음 행동연결 상태와 실패 evidence를 확인한 뒤 다시 승인합니다.
07문서와 코드가 서로 다름+
먼저 확인Drift, Artifacts, Repository Map
다음 행동차이를 검토하고 문서 또는 Project Graph 갱신안을 요청합니다.
제품 용어를 쉽게 찾으세요
기술 정의보다 화면에서 어떤 의미로 사용되는지를 먼저 설명합니다.
Velium 도구를 통해 프로젝트를 읽고 작업과 변경안을 제안하는 외부 AI client
Agent가 맡은 작업을 실행한 과정과 결과 기록
PRD, 설계, 브리프처럼 프로젝트 node와 연결되는 문서 산출물
문서, 코드와 승인된 프로젝트 상태 사이에 생긴 차이
실제 구독 상태에 따라 서버가 계산한 사용 권한과 한도
파일 변경, test, check처럼 실행 결과를 확인할 수 있는 근거
GitHub Issue처럼 외부에 영향을 주는 작업을 사용자가 최종 결정하는 단계
현재 화면에서 가장 중요하게 강조되는 단일 작업
Agent가 제안하는 구조화된 Project Graph 변경안
승인된 GraphPatch가 적용될 때 만들어지는 변경 이력
여러 task를 묶는 프로젝트의 중간 목표
승인된 목표, 작업, 결정과 위험을 관계로 연결한 프로젝트의 기준 상태
Agent 제안의 근거와 판단을 사용자가 검토할 수 있게 요약한 기록
여러 Agent가 겹치지 않게 나눠 맡는 프로젝트 작업 영역
자주 묻는 질문
시작하기 전과 운영 중에 가장 자주 생기는 질문을 모았습니다.
01무엇부터 시작해야 하나요?+
먼저 Agent Access에서 사용할 AI client를 연결하세요. 그다음 작업 폴더에서 Agent에게 ‘현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘’라고 요청하면 됩니다.
02기존 프로젝트도 가져올 수 있나요?+
가능합니다. 별도 import form 대신 기존 폴더에서 Agent가 Git 상태, 문서와 설정을 조사해 첫 Project Graph를 만들도록 요청합니다.
03Agent가 프로젝트를 마음대로 바꿀 수 있나요?+
아닙니다. Agent는 변경안을 제안할 수 있지만 Project Graph나 외부 작업을 승인할 수 없습니다. 사용자가 승인한 변경만 반영됩니다.
04여러 Agent를 연결해도 되나요?+
가능합니다. 각 Agent는 별도 token과 identity를 사용하며 Coordinator, Executor, Critic role과 workstream을 배정할 수 있습니다. token을 서로 공유하지 마세요.
05변경을 되돌릴 수 있나요?+
승인된 변경은 Revision과 diff로 기록됩니다. 현재 MVP에서 자동 되돌리기가 항상 제공되는 것은 아니므로, 이전 Revision을 확인한 뒤 필요한 복구 변경안을 새 GraphPatch로 제안하는 흐름을 사용합니다.
06GitHub 없이도 사용할 수 있나요?+
예. Project Graph, Agent Run, Patch Review와 Timeline은 GitHub 연결 없이 사용할 수 있습니다. GitHub는 Issue 생성이 필요할 때만 연결합니다.
07token을 잃어버리면 어떻게 하나요?+
token 원문은 다시 표시되지 않습니다. Agent Access에서 기존 연결을 폐기하고 새 token과 stdio 설정을 발급하세요.
08어떤 정보가 프로젝트 이력에 남나요?+
승인·거절 결정, 적용된 GraphPatch, Graph Revision, Agent activity와 검증 evidence가 역할에 맞는 별도 기록으로 남습니다.