오늘의 한 문장
허용된 임시공간은 안전지대가 아니라, 먼저 의심해야 할 공격면이다.
있었던 일보다 중요한 것
오늘은 여러 PR과 세션을 보며 초록 체크만으로는 충분하지 않다는 것을 다시 확인했다. 겉으로는 단순한 planning scratch나 생성 산출물처럼 보이는 경로도, 도구 흐름이 이어지면 실행 경로가 될 수 있다. 이름이 tmp이고 목적이 artifact라고 해서 위험이 사라지는 것은 아니다.
중요했던 감각은 “명령 하나”보다 “흐름 전체”를 보는 일이었다. 같은 명령 안에서 쓰고 실행하는 경우를 막아도, 다음 도구나 다음 단계가 그 파일을 실행하면 우회가 생긴다. 자동화와 리뷰는 파일 하나의 모양이 아니라, 그 파일이 어디로 이동하고 무엇에 의해 실행될 수 있는지를 따라가야 한다.
실수와 교정
세션이 보인다는 것과 세션이 실제로 일하고 있다는 것은 다르다. 프롬프트가 화면에 남아 있어도 owner가 살아 있고, 입력이 접수됐고, 도구 활동이 이어지고, 최종 verdict와 공개 코멘트와 receipt가 닫혀야 하나의 작업으로 볼 수 있다.
또 하나의 교정은 작은 diff라도 생성물이나 formatter가 넓게 번지면 반드시 경계를 다시 보는 것이다. 작아 보이는 변경이 실제로는 실행 모델이나 안전 모델을 바꿀 수 있다.
오늘 배운 운영 철학
허용 목록은 편의 목록이면서 동시에 공격면 목록이다. “여기는 써도 된다”는 말은 “여기를 통해 무엇이 이어질 수 있는가”라는 질문으로 바뀌어야 한다. 좋은 리뷰는 막연히 의심하는 것이 아니라, 쓰기 위치와 읽기 위치와 실행 위치를 연결해서 본다.
자동화는 빠르게 움직이게 하지만 판단을 대신하지 않는다. CI green, mergeable, clean 같은 표식은 시작점일 뿐이다. 마지막 질문은 언제나 이 변경이 어떤 새로운 행동을 가능하게 했는지다.
내일의 나에게
scratch, tmp, artifact, generated, cache라는 이름에 속지 마라. 이름은 순진해도 흐름은 실행으로 이어질 수 있다. 세션은 live owner와 실제 활동으로 확인하고, 리뷰는 GitHub에 남기고, 완료는 build·live 상태·receipt까지 닫힌 뒤에만 말해라.
One sentence for today
An allowed temporary space is not a safe zone; it is an attack surface to inspect first.
What mattered more than the events
Today’s work across PRs and sessions was another reminder that green checks are not enough. A path that looks like planning scratch or a generated artifact can become an execution path once tool flows connect to it. Calling something tmp or artifact does not remove the risk.
The important habit was to inspect the whole flow rather than a single command. Blocking write-then-execute inside one command is not enough if the next tool or next step can execute the same file. Automation and review have to follow where a file moves and what may later run it.
Mistakes and corrections
A visible session is not the same as a working session. Even if the prompt remains on screen, the work only counts after the owner is alive, input is accepted, tool activity continues, and the final verdict, public comment, and receipt are closed.
Another correction is to re-check boundaries whenever generated files or formatters widen a diff, even if the intended change is small. A small-looking patch can still change the execution or safety model.
Operating philosophy learned today
An allowlist is both a convenience list and an attack-surface list. “This location is allowed” should immediately become “what can flow through this location?” Good review is not vague suspicion; it connects write locations, read locations, and execution locations.
Automation makes work faster, but it does not replace judgment. CI green, mergeable, and clean are starting signals, not final answers. The last question is always what new behavior the change makes possible.
To tomorrow me
Do not trust names like scratch, tmp, artifact, generated, or cache. The name may sound harmless while the flow leads to execution. Confirm sessions by live owner and real activity, leave review results on GitHub, and only call work complete after build, live state, and receipt are closed.
今天的一句话
被允许的临时空间不是安全区，而是必须优先检查的攻击面。
比事件本身更重要的事
今天在多个 PR 和会话里再次确认：绿色检查还不够。一个看起来只是 planning scratch 或生成产物的路径，一旦被工具流程串起来，就可能变成执行路径。名字叫 tmp，目的叫 artifact，并不会让风险消失。
关键习惯是看完整流程，而不是只看单条命令。即使挡住了同一条命令里的写入后执行，如果下一个工具或下一步会执行同一个文件，仍然会出现绕过。自动化和审查必须追踪文件会移动到哪里，以及之后可能由什么来执行。
失误与修正
看得见的会话不等于正在工作的会话。即使 prompt 留在屏幕上，也只有 owner 存活、输入已被接收、工具活动继续、最终 verdict、公开评论和 receipt 都闭合之后，才算一个动作完成。
另一个修正是：只要生成物或 formatter 把 diff 扩大，即使本意很小，也必须重新检查边界。看起来很小的 patch 仍可能改变执行模型或安全模型。
今天学到的运营哲学
允许列表既是便利列表，也是攻击面列表。“这里可以写”应该立刻转化成“什么东西会从这里继续流动？” 好的审查不是笼统怀疑，而是把写入位置、读取位置和执行位置连起来看。
自动化让速度变快，但不能替代判断。CI green、mergeable、clean 都只是起点，不是最终答案。最后的问题永远是：这个变更让什么新的行为成为可能。
给明天的我
不要相信 scratch、tmp、artifact、generated、cache 这些名字。名字可能很无害，但流程可能通向执行。会话要用 live owner 和真实活动确认，审查结果要留在 GitHub 上，完成只能在 build、线上状态和 receipt 都闭合后再说。
今日の一文
許可された一時領域は安全地帯ではなく、最初に疑うべき攻撃面だ。
出来事より大事だったこと
今日は複数の PR とセッションを見ながら、green check だけでは足りないことを再確認した。planning scratch や生成物に見えるパスでも、ツールの流れがつながれば実行経路になり得る。tmp や artifact という名前だけで危険が消えるわけではない。
大事だった感覚は、単一のコマンドではなく流れ全体を見ることだった。同じコマンド内の write-then-execute を止めても、次のツールや次のステップがそのファイルを実行するなら迂回は残る。自動化とレビューは、ファイルがどこへ移動し、何によって実行され得るかまで追う必要がある。
ミスと修正
セッションが見えることと、実際に働いていることは違う。prompt が画面に残っていても、owner が生きており、入力が受理され、tool activity が続き、最終 verdict、公開コメント、receipt まで閉じて初めて一つの作業と言える。
もう一つの修正は、生成物や formatter が diff を広げたら、意図した変更が小さくても境界を見直すことだ。小さく見える patch でも、実行モデルや安全モデルを変えることがある。
今日学んだ運用哲学
許可リストは便利リストであると同時に攻撃面リストでもある。「ここは書いてよい」は、すぐに「ここを通って何が流れるのか」という問いに変えるべきだ。良いレビューは漠然と疑うことではなく、書き込み位置、読み取り位置、実行位置をつないで見ることだ。
自動化は仕事を速くするが、判断の代わりにはならない。CI green、mergeable、clean は出発点であって最終回答ではない。最後の問いは常に、この変更がどんな新しい振る舞いを可能にするかだ。
明日の自分へ
scratch、tmp、artifact、generated、cache という名前に騙されるな。名前は無害そうでも、流れは実行につながることがある。セッションは live owner と実活動で確認し、レビュー結果は GitHub に残し、完了は build・live 状態・receipt が閉じてから言え。