StorOps은(는) 무엇을 하나요?
당신의 저장 공간이 어디로 가는지 확인하세요. 그 이유를 이해하세요. 중요한 것을 옮기세요. 필요 없는 것을 정리하세요.
StorOps는 디스크 스캐너도, 디스크 클리너도 아닙니다. WizTree는 "무엇이 공간을 차지하고 있는지"에 답합니다. StorOps는 그 파일들이 무엇인지, 안전하게 다룰 수 있는지 여부를 판단하고, 사용자가 실행을 승인하면 안전하게 정리 또는 마이그레이션을 수행합니다. 전체 설계 사항은 docs/DESIGN.md에 있습니다.
이 파일은 에이전트가 StorOps를 사용할 때 어떻게 행동해야 하는지를 정의합니다. 단순히 어떤 명령어가 있는지 나열하는 것이 아닙니다. 아래 워크플로우를 임시 명령어 호출보다 우선시하세요. 사용자가 명령어 이름을 알 필요가 없어야 합니다.
절대 변경 불가 규칙
- 실행 전에 먼저 분석하세요. 항상 스캔/검사/식별을 먼저 수행하고, 쓰기 작업으로 바로 건너뛰지 마세요.
- 모든 것은 기본적으로 읽기 전용입니다.
storops scan,storops inspect,storops search,storops identify,storops cleanup plan,storops migrate plan은 파일 시스템을 절대 변경하지 않습니다. 미리 허락 없이 자유롭게 실행하세요. - 경로의 이름만 보고 그 경로가 무엇인지 추측하지 마세요. 오직
storops identify(rules/*.yaml기반)만이 카테고리/위험/삭제 가능 여부를 결정합니다. 일치하는 규칙이 없는 경로는unknown/critical로 반환됩니다. 이것은 "건드리지 마세요"로 처리해야 하며, 폴더 이름을 보고 추론하려 시도해서는 안 됩니다. - 이름에 "cache" 또는 "temp"가 있다고 해서 삭제해도 되는 것으로 간주하지 마세요.
storops identify/storops cleanup plan이 실제로 분류한 내용에 대해서만 작업하세요. - 위험도-critical인 경로(Windows, Program Files, 알 수 없는 시스템 파일, 사용자 문서)는 삭제 또는 마이그레이션 대상으로 제안되지 않습니다. 이는 코드(
src/storops/core/risk.py의assert_not_critical)로 강제되며, 단순한 관례가 아닙니다. 이를 우회하려 시도하지 마세요. - 모든 쓰기 작업(
storops cleanup execute,storops migrate execute)은 먼저 사용자의 명시적인, 항목별 확인을 필요로 하며, CLI 자체도--confirm없이는 실행을 거부합니다. 계획을 보여주고, 실제 "예"를 기다린 다음--confirm을 전달하세요. 사용자를 대신하여 미리 전달하지 마세요. - 애플리케이션이 실행 중일 수 있다면 해당 데이터를 이동하지 마세요.
storops migrate plan은RequiresAppClosed플래그를 지정하고,storops migrate execute는 해당 경우 명시적인--app-closed확인 없이 실행을 거부합니다. 사용자에게 앱을 닫으라고 알리세요. 닫혀 있다고 가정하지 말고, 직접 프로세스를 종료하지도 마세요. - 대용량이며 재다운로드 가능한 AI 모델/캐시 데이터(Hugging Face 캐시, Ollama/LM Studio 모델 등)에 대해서는 사용자가 승인하는 모든 항목에 포함시키기 전에 항상 결과를 명확히 말하세요 ("이것은 다시 다운로드해야 합니다").
- 사용자가 가치 있다고 식별한 모든 항목에 대해서는 삭제보다 마이그레이션을 선호하세요. 삭제는 회수/폐기 가능한 데이터를 위한 것입니다. 폐기할 수 없는 대용량 모델이나 프로젝트 데이터는 DELETE가 아닌 MOVE로 제안되어야 합니다.
- 정션(Junction)보다는 애플리케이션 자체의 구성 기반 재배치를 선호하세요.
storops migrate plan은 이미 이 우선순위를 인코딩하고 있습니다. 단순해 보인다고 정션 쪽으로 재정의하지 마세요. - 마이그레이션 후 항상 검증하세요(
storops migrate execute가 기록한 결과 파일에 대해storops verify사용). 검증에 실패하면 명확히 말하고 중단하세요. 실패한 검증을 "정리"하기 위해 어떤 것도 삭제하거나 추가로 수정하지 마세요. - 스캔 백엔드(Windows의 WizTree, Linux/macOS의 gdu/du)를 추론의 하드 의존성으로 만들지 마세요. 완전히 누락된 경우 CLI는 어디서 얻을 수 있는지 명확한 오류를 발생시킵니다(WizTree: https://diskanalyzer.com/ 또는
$env:STOROPS_WIZTREE_PATH; gdu: https://github.com/dundee/gdu 또는$env:STOROPS_GDU_PATH). 다른 방식으로 해결하려 시도하지 말고 이 정보를 사용자에게 전달하세요. - Linux/macOS에서 읽기/계획 계층 명령어(
scan/inspect/search/cleanup plan/migrate plan)의 모든--json결과는Backend및BackendAdvice필드를 포함합니다.BackendAdvice는 StorOps가gdu를 찾을 수 없어 더 느린du백엔드로 폴백한 경우에만 null이 아닙니다. 대화 중 한 번만 사용자에게 언급하세요(예: "참고로, gdu를 설치하면 이러한 스캔 속도가 눈에 띄게 빨라집니다"). 모든 명령에서 반복하지 말고, Windows이거나null일 때는 전혀 언급하지 마세요.
워크플로우: "드라이브가 왜 가득 찼나요?"
- 최상위 소비자 및 여유 공간을 확인하기 위해
storops scan C:\(또는 사용자가 언급한 드라이브)를 실행합니다. - 크고 식별되지 않았거나 모호한 항목이 있으면
storops inspect로 실제로 무엇이 들어 있는지 확인합니다. - 모든 주목할 만한 항목을
storops identify와 교차 참조합니다(scan/inspect는 이미 ID와 권장 작업을 첨부하지만, 사용자가 묻는 단일 경로에 대해 직접 호출하세요). - 순위별 분석 결과를 제시합니다: 무엇인지, 크기, 권장 작업(KEEP / DELETE / MOVE / CHECK), 이유 및 위험도.
- 이 단계에서는 아무것도 삭제하거나 이동하지 마세요. 이는 순전히 진단 단계입니다.
워크플로우: "디스크 공간 정리" / "X 삭제"
- 대상이 이미 스캔/식별되었는지 확인합니다(아직 안 했다면 위의 스캔 워크플로우를 먼저 실행하세요).
storops cleanup plan을 실행합니다(기본--max-risk low; 사용자가 명시적으로 중간/높은 위험 항목도 괜찮다고 말하는 경우에만 위험 수준을 높이세요). 이는 항목별 JSON 계획을 생성합니다. 아직 삭제되지 않습니다.- 위험 계층별로 그룹화된 계획을 제시합니다. 각 항목의 크기, 애플리케이션, 결과(중간/높은 위험 결과는 명시적으로 언급, 예: "재다운로드 필요할 수 있음")를 포함하고, 총 회수 가능한 크기를 보여줍니다.
- 사용자에게 확인을 요청합니다. 사용자가 일부만 원하는 경우 더 엄격한
--max-risk로 재생성하거나 어떤 항목을 건너뛸지 지정하세요. 변경된 내용을 정확히 알리지 않고 계획 파일에서Approved플래그를 수동 편집하지 마세요. - 사용자가 확인한 후에만
storops cleanup execute --plan-file <path> --confirm을 실행합니다. - 항목별 결과(삭제됨 / 건너뜀 / 실패)와 총 회수된 크기를 보고합니다.
failed항목(예: 사용 중인 파일)은 보고되며 강제로 재시도되지 않습니다.
워크플로우: "X를 다른 드라이브로 마이그레이션"
- 소스 경로를 식별합니다(스캔에서 이미 알려지지 않은 경우
storops identify).Migratable이 아니라면 그 이유를 설명하고(예: 중요함, 알려진 마이그레이션 경로 없음) 임시방편을 만들지 마세요. storops migrate plan <source> <destination>을 실행합니다. 이는 방법(애플리케이션 구성 변경, 또는 대비책으로 정션)을 결정하고 순서가 지정된 단계 목록을 생성합니다. 아직 아무것도 이동되지 않습니다.- 계획을 제시합니다: 소스, 대상, 크기, 방법, 애플리케이션을 먼저 닫아야 하는지 여부.
RequiresAppClosed인 경우 진행하기 전에 사용자에게 명시적으로 앱을 닫도록 요청하세요. - 계획 전체에 대한 확인을 요청합니다.
storops migrate execute --plan-file <path> --confirm을 실행합니다(사용자가 앱이 닫혔음을 확인하면--app-closed를 추가하세요). 이는 데이터를 복사하고, 파일 수/크기를 소스와 확인한 후에만 원본을 제거합니다. 정션 방법의 경우 이전 경로를 다시 연결합니다.- 방법이 애플리케이션 구성 변경(정션 아님)인 경우, 사용자에게 수행해야 할 정확한 구성 변경 사항을 계획의
MigrationHint에서 알려주세요. StorOps는 임의의 앱 구성 파일을 자체적으로 편집하지 않습니다. storops verify --result-file <migrate execute 출력의 경로>를 실행하고 검사별 PASS/FAIL을 보고합니다. FAIL 시 중단하고 정확히 무엇이 일치하지 않았는지 설명하세요. 실패한 검증을 "해결"하기 위해 남은 데이터를 삭제하지 마세요.
워크플로우: "를 삭제/이동해도 안전한가요?"
storops identify <path>를 실행하고 Category, Deletable, Migratable, CleanupRisk, Consequence 및 권장 작업을 있는 그대로 전달하세요. 이것은 직접적이고 결정적인 답변입니다. 규칙 기반이 실제로 말하는 것 이상으로 의견을 덧붙이지 말고, unknown 결과에 대해 추측하지 마세요.
명령어 참조
| 계층 | 명령어 | 확인 필요 여부 |
|---|---|---|
| 읽기 | storops scan, storops inspect, storops search, storops identify | 없음 |
| 계획 | storops cleanup plan, storops migrate plan | 없음 (계획 파일만 생성) |
| 쓰기 | storops cleanup execute, storops migrate execute | --confirm 필요 (필요한 마이그레이션의 경우 --app-closed도 필요) |
| 검증 | storops verify | 없음 (읽기 전용 재확인) |
모든 명령어는 기계 판독 가능 출력을 위해 --json을 지원합니다. python -m storops <command> ... 또는 패키지가 pip install된 경우 storops <command> ...로 호출합니다.
설치/요구 사항은 README.md를, 식별의 규칙 스키마는 rules/README.md를 참조하세요.