full과 light는 context 모양이야

full은 관계와 연속성을 싣는다

복잡한 curation은 한 note만 봐선 못 해. soul의 identity, 최근 결정, 여러 memory 사이 tension, Dad와의 대화까지 이어져야 해. full lane은 canonical conversation에 bind된 Sidekick에서 그 연속성을 제공해.

대신 매 tool step 큰 context가 다시 청구되고, scope가 넓을수록 오염 위험도 커. 그래서 full은 상담과 방향 결정에 쓰고, 반복적인 대량 edit loop를 무심코 넣지 않아.

light는 operand를 좁힌다

light lane은 exact fragment, instruction, permission facts, base hash만 싣고 vault 전체 prepend를 생략해. 기억을 편집할 때 stale snapshot과 두 writer 위험을 줄이고 비용도 bounded하게 만든다.

light가 정체성 없는 generic model이라는 뜻은 아니야. Pippa identity와 safety contract는 유지하되 task와 무관한 memory context를 안 싣는 거야. context 최소화와 persona 제거를 혼동하지 마.

mode가 provider를 고르지 않아

full=특정 vendor, light=다른 vendor로 hardcode하면 rate limit 하나가 mode availability가 돼. mode는 context shape를 고르고 brain registry가 현재 provider와 fallback을 선택해야 해.

provider switch가 있어도 actor, task id, context mode, source hash provenance는 유지된다. model name은 execution detail로 기록하되 product contract의 identity가 되지 않아.

escalation은 새 task여야 해

light가 판단 부족을 발견하면 몰래 더 많은 vault를 읽지 않고 needs_full_context로 멈춰. Dad가 full consultation을 열거나 soul-pinned session으로 escalation해야 해.

반대로 full session이 반복 mechanical changes를 시작하려면 bounded operands를 queue에 materialize해 light 또는 terminal pipeline으로 넘겨. 한 mode가 다른 mode로 조용히 팽창하지 않게 handoff record를 남겨.

full과 light의 차이는 똑똑함이 아니라 어떤 context와 책임을 싣느냐야. mode는 context shape를, registry는 provider를, permission matrix는 노출을 결정해.

Code

mode와 provider 선택 분리하기·python

modes = {
    "full": {"include_conversation": True, "include_vault": True},
    "light": {"include_conversation": False, "include_vault": False},
}
providers = ["primary", "fallback"]

def route(mode, available):
    context = modes[mode]
    provider = next(p for p in providers if p in available)
    return context, provider

context, provider = route("light", {"fallback"})
assert not context["include_vault"] and provider == "fallback"

full은 관계와 연속성을 싣는다

light는 operand를 좁힌다

mode가 provider를 고르지 않아

escalation은 새 task여야 해

Code

External links

Exercise

Progress

댓글 0