문제
작은 설정 변경이나 문서 한 줄 수정도 전체 사이트 빌드, 의존성 캐시, 테스트 출력처럼 큰 임시 산출물을 만들 수 있습니다. 소스부터 고친 뒤 공간 부족을 발견하면 작업 디렉터리에 부분 결과가 남고, 검증되지 않은 변경을 밀어 넣고 싶은 압력이 생깁니다.
운영 패턴
1. 변경 전에 소스 저장소와 빌드 출력이 놓일 파일시스템의 여유 공간을 확인한다.
2. 직전 성공 빌드의 출력 크기와 이번 검증 단계가 만들 임시 산출물을 대략 계산한다.
3. 여유가 부족하면 소스를 건드리지 말고, 재생성 가능한 오래된 캐시나 종료된 작업의 산출물만 안전 기준에 따라 정리한다.
4. 빌드가 시작된 뒤 실패하면 이번 시도에서 생긴 부분 출력만 제거하고 저장소가 깨끗한지 다시 확인한다.
5. 모든 검증이 통과하기 전에는 커밋이나 푸시를 완료 상태로 취급하지 않는다.
왜 중요한가
용량 부족은 단순한 인프라 잡음이 아니라 검증 계약을 끊는 실패입니다. 사전 점검을 변경 게이트 앞에 두면 실패 비용을 줄이고, 원본과 생성물의 경계를 선명하게 유지할 수 있습니다.
완료 기준
예상 산출물을 감당할 여유 공간이 확인되고, 빌드와 테스트가 끝까지 통과하며, 실패 시에도 부분 출력 없이 깨끗한 상태로 되돌아갈 수 있으면 용량 사전 점검이 작동한 것입니다.
Problem
A one-line documentation or configuration change can still trigger a full site build, dependency caches, and large test output. If capacity is discovered only after editing source, partial artifacts remain in the workspace and create pressure to push an unverified change.
Operating pattern
1. Before mutation, check free space on the filesystems that hold both the source tree and build output.
2. Use the previous successful build size to estimate the temporary artifacts required by the current verification path.
3. If capacity is insufficient, do not touch source; remove only safely regenerable caches or artifacts owned by terminal work.
4. If a started build fails, remove only output created by that attempt and confirm the repository is clean again.
5. Do not treat commit or push as complete until every required verification gate passes.
Why it matters
Capacity failure is not harmless infrastructure noise. It breaks the verification contract. Putting a capacity preflight ahead of mutation lowers failure cost and keeps the boundary between source and generated artifacts explicit.
Completion bar
The preflight works when available space covers the estimated output, builds and tests reach their terminal result, and a failed attempt can return to a clean workspace without leftover partial artifacts.
问题
即使只是修改一行文档或配置，也可能触发完整站点构建、依赖缓存和大量测试输出。如果在改完源代码后才发现容量不足，工作区会留下部分产物，并产生推送未经验证变更的压力。
运维模式
1. 变更前检查源代码目录和构建输出所在文件系统的剩余空间。
2. 参考上一次成功构建的输出规模，估算本次验证流程会产生的临时产物。
3. 容量不足时不要修改源代码，只清理可安全再生的缓存或已终结工作的产物。
4. 构建开始后若失败，只删除本次尝试生成的部分输出，并再次确认仓库恢复干净。
5. 在所有必需验证门槛通过前，不要把提交或推送视为完成。
为什么重要
容量不足不是无害的基础设施噪声，而是会切断验证契约的失败。把容量预检放在变更之前，可以降低失败成本，并明确区分源文件与生成产物。
完成标准
确认可用空间足以容纳预计产物，构建与测试能运行到终态，并且失败后可在不残留部分产物的情况下恢复干净工作区时，容量预检才算有效。
問題
ドキュメントや設定の一行変更でも、サイト全体のビルド、依存キャッシュ、大量のテスト出力が発生することがあります。ソースを編集した後で容量不足に気づくと、部分成果物が残り、未検証の変更を push したくなる圧力が生まれます。
運用パターン
1. 変更前に、ソースツリーとビルド出力を置くファイルシステムの空き容量を確認する。
2. 直前の成功ビルドのサイズを基準に、今回の検証経路が作る一時成果物を見積もる。
3. 容量が足りない場合はソースに触れず、安全に再生成できるキャッシュや終端作業の成果物だけを整理する。
4. 開始済みビルドが失敗したら、その試行で生成された部分出力だけを削除し、リポジトリが再び clean か確認する。
5. 必須の検証ゲートがすべて通るまで、commit や push を完了として扱わない。
なぜ重要か
容量不足は無害なインフラノイズではなく、検証契約を切断する失敗です。容量事前確認を変更より前に置けば、失敗コストを下げ、ソースと生成物の境界を明確に保てます。
完了基準
見積もった成果物を収容できる空き容量があり、ビルドとテストが終端まで通り、失敗時にも部分出力を残さず clean な状態へ戻れるなら、容量事前確認は機能しています。