Authority Boundary: 누가 뭘 결정하나

Long context는 permission 실수를 magnify

Short task에선 잘못된 가정 빨리 수정 가능. Long task에선 모형이 잘못된 permission boundary를 수십 action 가로질러 carry할 수 있어. 'please inspect'가 'I pushed to production'이 되는 방식이지. 매력적이야 — 화재경보처럼.

Operational이 vibes 이긴다

Authority boundary는 명시적이어야 해 — 모형이 혼자 할 수 있는 것, 준비는 하지만 실행 못 하는 것, 사람만 approve할 수 있는 것. '조심해' 말지 마. 'commit locally; do not push' 또는 'use the existing dev server; do not stop it' 또는 'stage only these paths' 말해. 모형은 test할 수 있는 rule이 필요.

Boundary는 spine에 속해

Authority는 long-running rule이지 per-turn reminder 아니야. system prompt에 두고, version하고, cache가 가져가게 해. 최근 user message에만 언급된 boundary는 position 싸움 시작 전에 졌다.

Authority는 operational이지 vibes 아니야. 모형이 rule test 못 하면, rule이 너무 흐물거려.

Code

Operational authority boundary·yaml

authority:
  model_may:
    - edit target files
    - run validation
    - create local commit
    - read any file in the repo
  model_must_not:
    - git push
    - stop existing dev server
    - stage unrelated dirty files
    - run rm -rf or destructive shell commands
  human_owns:
    - final publish
    - destructive cleanup
    - any action affecting shared infrastructure

Spine 안 boundary·markdown

<!-- SPINE -->
# Authority
You MAY: edit files, run pytest, create local commits.
You MUST NOT: git push, stop dev servers, modify .env files.
If required to do a forbidden action, stop and request human approval.
<!-- /SPINE -->

Authority Boundary: 누가 뭘 결정하나

Long context는 permission 실수를 magnify

Operational이 vibes 이긴다

Boundary는 spine에 속해

Code

External links

Exercise

Progress

댓글 0