docs: 페르소나 고정·성장 작성 계약 확정 (018, D24) - #26
Merged
Merged
Conversation
에이전트별 페르소나 프롬프트를 쓰기 전에 무엇을 고정으로 적고 무엇을 성장에 맡길지 판단할 근거가 한곳에 없었다. 층의 우선순위는 persona.ts의 권위 문구에, 잠금 판정은 persona-schema.ts에, 정체성 자료 생성은 fleet/life-runtime.ts에 흩어져 있어 작성자가 모아서 읽을 수 없었다. 018을 신설해 층 우선순위, 명시적 대화 선호의 적용 범위, evolution과 축별 잠금으로 하는 고정·성장 선언, 필드 소유권, 불완전한 정체성 자료 다섯 경우의 처리, 작성에서 소비까지의 연결표, 대표 예시와 프롬프트 작성 착수 판정을 기록한다. 정본에는 D24로 남기고 016·017·031에서 연결한다. 현재 생산자와 D18이 의도한 소유권, 아직 없는 저장 필드를 구분해 적었다. 개인별 선택 잠금을 저장할 곳이 없어 제품에서 실효 있는 선택이 manual과 adaptive 둘뿐이라는 사실과, PersonaSchema 파생 함수에 제품 호출자가 없다는 사실을 그대로 남겼다. 잠금 저장과 생성기 전환은 후속 작업이다. Refs: JUN-28
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
코드리뷰가 018에서 두 가지를 짚었고 소스로 확인해 둘 다 맞았다. 첫째, 축을 성장에서 빼려면 공개 허용 목록에서 제외하라고 안내했는데 틀렸다. LIFE의 성장 검증·적용과 사회 효과는 evolution과 축별 잠금만 보고 허용 목록을 보지 않는다. LIFE 회고에 넘기는 자기 성향에도 그 필터가 없다. 허용 목록에서 뺀 축도 LIFE 경로로는 계속 변한다. 그 안내는 비공개이면서 성장하는 축이라는 정상 조합도 막았다. 반대로 잠금과 manual만이 성장을 막는다고 적지도 않는다. 허용 목록은 네이티브 개인 성향 해석의 대상을 실제로 제한하고, 그 밖에도 각 경로가 근거·범위·현재성·예산 검사를 따로 건다. 잠그지 않았다는 것은 변할 자격이 있다는 뜻이지 변화가 일어난다는 뜻이 아니다. 둘째, 잠금 id를 한 세계 기준으로만 설명했다. 잠금 목록은 개인 소유인데 축 id는 세계마다 정의되고 전역 이름공간이 없어서, 한 세계에서 유효한 잠금이 다른 세계에서 이름만 같은 다른 축을 잠글 수 있다. 표현 방식은 미해결로 남기고 잠정 규칙을 적었다. 초안에 어느 세계의 축인지 함께 적고 다른 세계로 옮겨 쓰지 않는다. LifeDefinition 소유를 기각한 것이 AgentStore가 소유하는 세계 범위 정책까지 금지하지는 않는다는 점도 분명히 했다. 덧붙여 아직 없는 동작을 현재형으로 적은 세 곳을 고쳤다. 없는 잠금 id 거부와 잠금 목록 생략 시의 기본값은 작성 경계에 요구하는 규칙이고, 대상 개인이 없는 자료의 거부는 후속 PR에서 적용되는 채택 규칙이다. Refs: JUN-28
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
층 표의 작성 정체성 행이 AgentProfile만 소유자로 적었다. 실제로 corePrompt는 AgentProfile 필드와 대화 방식·예시, 확정된 온보딩 장을 한 블록에 렌더링한 뒤 그 전체를 완전한 작성 정체성이라고 선언한다. 대화 설정은 ConversationStore에서, 확정 장은 OnboardingStore에서 온다. 온보딩 장은 가치·기질·관심·관계·표현을 담으므로, 빠뜨리면 그 항목들이 우선순위 계약 밖에 남아 나중에 성장과 충돌할 때 해결 규칙이 없다. 층 안의 순서도 적었다. AgentProfile 필드가 안정된 기준점이고, 확정 장은 덧붙인 작성 설정이며 겪은 일이 아니고, 대화 예시는 허구의 문체 참고라 현재 요청과 정한 말투보다 뒤에 온다. Refs: JUN-28
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
대표 예시가 고정·선택 잠금·자료 미제공 순서로 설명해 놓고 digest는 자료 미제공·고정·선택 잠금 순서로 적었다. 세 값이 모두 어긋나 있어서 예시를 따라간 작성자가 각 정책에 틀린 digest를 연결하게 된다. 순서에 기대지 않도록 각 값에 어느 경우인지 붙여 적었다. 실측은 고정 87fb41e7, 선택 잠금 aa57cfc0, 자료 미제공 b7ade1a1이다. 일시 상태 층이 Dynamics만 소유자로 적었다. 네이티브 모드에서는 Dynamics를 비운 채로 넘기고 EngineState의 비공개 개인 맥락을 대신 붙인다. 그 맥락은 대상이 사용자가 아닌 적격 관심·선호·기분·태도 기록만 담고, 지원된 항목은 표현에만 쓰며 잠정 항목은 확정된 성향으로 올리지 않는다. manual이면 붙지 않는다. 제품이 실제로 쓰는 경로라 층 모델에 넣었다. 온보딩 장 목록에서 빠져 있던 정체를 채웠고, 층 순서가 런타임 문구로 전부 규정되는 것은 아니라 이 문서가 채택한 계약임을 밝혔다. Refs: JUN-28
저장된 대화 설정이 없으면 프리셋 기본값이 쓰인다. installPersona는 ConversationStore의 revision이 0이면 그 값을 버리고 data/personas/conversations.json의 기본값을 읽는다. 프리셋으로 만든 에이전트는 저장된 행이 없으므로 기본값 쪽이 프롬프트에 들어간다. 계약이 두 경로를 모두 ConversationStore가 공급하는 것처럼 적어서, 작성자가 대화 방식을 바꾸려 할 때 엉뚱한 곳을 고칠 수 있었다. 두 출처를 나눠 적고 어느 쪽을 고치는지 먼저 확인하라고 명시했다. Refs: JUN-28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change
에이전트별 페르소나 프롬프트를 쓰기 전에 무엇을 고정으로 적고 무엇을 성장에 맡길지 판단할 근거가 한곳에 없었다. 층의 우선순위는
persona.ts의 권위 문구에, 잠금 판정은persona-schema.ts에, 정체성 자료 생성은fleet/life-runtime.ts에 흩어져 있어 작성자가 모아서 읽을 수 없었다.docs/plans/platform/018_persona_authoring_contract.md를 신설해 다음을 확정한다.evolution과 축별 잠금 목록으로 선언한다. 프롬프트 산문에는 강제력이 없다.정본에는 D24로 기록하고 016·017·031에서 연결한다. 거부 동작의 실제 구현은 이 PR을 base로 하는 후속 PR에서 한다.
Refs: JUN-28
Verification
문서 변경이라 CI가 애플리케이션 검사를 건너뛴다(
scripts/ci/plan.ts의isProse). 그래서 자동 게이트가 이 문서를 의미 수준에서 읽지 않는다는 점을 먼저 밝힌다.biome는packages/**·scripts/**만 보고,ci:validate의 링크 검사는POLICY.md·CONTRIBUTING.md·docs/CI.md에만 걸린다. 형식은changes작업의git diff --check와 비밀 스캔이 관찰한다.내용 정확성은 아래를 직접 돌려 확인했다.
b7ade1a1, manual87fb41e7, 선택 잠금aa57cfc0으로 분기b7ade1a1git diff --checkbun run lintdocs/**를 읽지 않으므로 계약 정확성의 증거가 아니다digest 앞 8자는
persona-schema.test.ts의 픽스처에 한정된 값이다.Risks and remaining work
이 PR은 문서만 바꾸므로 실행 동작이 달라지지 않는다. 계약을 적었다는 것이 제품이 그 계약을 따른다는 뜻은 아니다.
personaSchemaFromLifeDefinition에는 아직 제품 호출자가 없고, 개인별 선택 잠금을 저장할 필드도 없다. 그래서 지금 제품에서 실효 있는 선택은manual과adaptive둘뿐이며 018에 그대로 적었다.미해결 6건(잠금 저장 위치, 개인별 시작값 재정의, 자료 미제공 허용 유지, 상대별 태도 잠금, manual과 잠금 목록의 공존, revision이 바뀐 schema의 처리)은 단정하지 않고 후속 작업으로 넘겼다. 잠금 저장과 정체성 자료 생성기 전환은 JUN-35 범위다.