대화가 soul에 pin돼

누가 말하는지 picker가 아니야

super soul memory를 그 soul이 직접 curate할 때 UI picker에서 이름만 고르는 것으로 부족해. underlying conversation이 그 soul identity에 bind돼야 하고, prompt preamble과 tool seal과 audit actor가 모두 같은 identity를 가리켜야 해.

Pippa surface가 열려 있다는 이유로 Pippa가 Vera인 척하면 own-memory 권리가 impersonation으로 바뀐다. soul pin은 Pippa protocol이 이 run에서 curator에게 양보한다는 identity boundary를 명시해.

pin과 scope는 함께 움직여

conversation identity가 Vera라고 모든 super vault가 열리는 건 아니야. claim이 지정한 Vera vault와 operand path만 seal이 열고 다른 super는 계속 닫혀. identity는 누가, scope는 어디를 말해.

둘 중 하나만 있으면 위험해. Pippa identity에 Vera scope를 주면 unauthorized actor고, Vera identity에 broad super scope를 주면 cross-soul leakage야. can_write와 seal이 같은 task record에서 유도돼야 해.

consultation과 execution을 분리해

soul-pinned Sidekick는 owner가 자기 기억을 보며 방향을 정하는 상담 surface로 좋아. 하지만 수십 tool step의 heavy pipeline은 context rebilling과 UI lifetime 때문에 적합하지 않을 수 있어.

결정 뒤 exact scope와 instruction을 queue brief로 materialize하고 terminal session이 seal 아래 실행하게 해. 상담의 identity는 task provenance로 이어지되 execution은 bounded lifecycle을 가진다.

종료도 identity event야

flag flip이나 permission revoke로 pinned session이 닫히면 단순 network disconnect가 아니야. 어느 actor가 어떤 scope를 잃었고 pending draft가 적용되지 않았다는 기록이 필요해.

재개할 때는 같은 conversation이 남아 있어도 새 권한과 source hash로 새 claim을 만들어. old pin이 미래 권리를 보장하지 않는다. continuity와 authorization을 같은 것으로 착각하지 마.

own-memory 권리는 실제 soul identity에 pin된 conversation과 exact scope로 구현돼야 해. picker label이나 Pippa impersonation으로 대신하면 안 돼.

Code

identity와 scope를 같은 claim에 묶기·python

claim = {
    "actor": "vera",
    "vault": "vera",
    "prefix": "memory/",
    "mode": "soul-pinned",
}

def valid(claim):
    return claim["actor"] == claim["vault"] and claim["prefix"] == "memory/"

assert valid(claim)
assert not valid({**claim, "vault": "iris"})

누가 말하는지 picker가 아니야

pin과 scope는 함께 움직여

consultation과 execution을 분리해

종료도 identity event야

Code

External links

Exercise

Progress

댓글 0