osk-system
Health Uyari
- License — License: NOASSERTION
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Low visibility — Only 5 GitHub stars
Code Gecti
- Code scan — Scanned 12 files during light audit, no dangerous patterns found
Permissions Gecti
- Permissions — No dangerous permissions requested
Bu listing icin henuz AI raporu yok.
Source-grounded MCP memory runtime and Obsidian-compatible vault template for LLM agents.
osk-system
에이전트의 장기 기억을 위한 지식 그래프 체계.
Problem
에이전트가 쓰는 지식 저장소에서는 한 가지가 계속 흐려진다 — 무엇이 사용자가
확인한 것이고 무엇이 에이전트가 만든 후보인가. 그 구별이 흔들리면 저장소는
"그럴듯한 것이 쌓인 곳"이 되고, 회상은 신뢰할 수 없게 된다.
osk-system은 그 구별을 사람의 기억이나 관행이 아니라 기계가 틀리지 않게
판정하도록 만든 체계다. 세 구조가 그것을 떠받친다.
권위를 노드 밖으로 뺐다. 승인은 노드 안의 필드가 아니라 별도 대장의
기록이다 — 사용자가 마지막으로 승인한 구획 전체의 상태(승인본)를 엔진이
따로 보존한다. 에이전트가 노드를 고쳐도 권위를 고칠 수 없고, 고치면 그 차이가
변경집합으로 남아 사용자의 승인이나 반려를 기다린다. 지정·해제·승인·반려의
발의는 사용자 전속이다.
판정을 시간이 아니라 인과로 한다. 대장의 각 기록은 직전 head를 참조해
인과 DAG를 이루고, 판정은 시간순 마지막이 아니라 인과 극대다. 여러 기기의
병합으로 극대가 하나로 정해지지 않으면 보수적으로 미확정이며, 갈래 전부를 잇는
사용자의 새 기록이 이를 해소한다. 모르면 유효라고 하지 않는다.
외부 표면이 계약 검증의 강제 지점이다. 에이전트가 파일을 손으로 쓰면 노드
계약도 참조 위상도 거치지 않는다. 그래서 MCP 도구를 두되, 그은 선은 "읽기
전용"이 아니라 권위 비노출이다 — 보호영역 권위와 pin은 영구히 노출하지
않고, 노드 쓰기는 검증을 통과시켜 연다.
관통하는 태도가 하나 있다. 강제할 수 없는 것을 강제한 척하지 않는다. 권한
검사는 적용 봉투를 기계로 평가할 수 있기 전까지 언제나 보류를 낸다.
Harness coverage
자동 포착·주기 통합·구독 fork의 하네스 어댑터는 현재 Codex와 Claude Code에
한정되어 있다. 다른 MCP 클라이언트에서 도구를 호출할 수 있다는 사실만으로
세션 훅과 자율적인 지식 성장이 연결되었다고 보지 않는다.
| 실행 조건 | 대화 검토 경로 |
|---|---|
| 지원 하네스의 훅과 구독 CLI가 연결되고 로그인·판본 검사를 통과 | 성공한 최종 답변 Stop 9회마다 같은 하네스·모델의 백그라운드 fork |
| CLI 미설정·미설치·미로그인·구독 인증 불확실·판본 불일치·보존 불가능한 권한·Codex 비Git 작업 폴더 등 | 검토 경고와 함께 현재 세션의 UserPromptSubmit 9·15턴 통합으로 전환 |
| 아직 어댑터가 없는 하네스 | 자동 포착·계수·fallback을 보장하지 않음. 하네스별 연결과 검증이 필요 |
입력 계수는 백그라운드 모드에서도 유지한다. 실행 경로가 바뀌어도 검토 대기와
두 계수를 초기화하지 않으며, 전환 시 이미 9턴을 넘긴 대기는 바로 안내한다.
로그인이 복구되면 Stop 실행으로 돌아간다. 구독 확인 실패를 API 과금으로 대체하지 않는다.
캐시 재사용은 별도 검증 대상이다. 실제 Codex 앱의 최종 답변 직후 같은 Sol
모델로 fork하여 98.74% 적중을 확인했다. 같은 원세션도 기본 CLI 구성은 0%였으므로,
앱에서 출발하면 앱용 도구 정의를 자동 보존한다. 판본·모델별 보편적 보장은 아니며,
구현·설치·캐시 적중·실제 노드 성장을 구별한다.
설치와 fallback 동작, 실험 결과와 한계를 본다.
하네스 커버리지 확대는 후속 과제다. 새로운 하네스마다 대화/완료 식별자, 전사
저장 경계, 훅 이벤트, 구독 인증, 일회성 실행과 실패 시 대체 경로를 검증해야 한다.
Governance
체계를 규정하는 규범은 어느 지식 Space에도 속하지 않는 상설 통치 구획_governance/에 있다 — system을 규정하는 규범은 system이 조직하는 지식이
아니기 때문이다.
| 문서 | 무엇을 정하는가 |
|---|---|
| Constitution.md | 헌법 — Space·노드·참조 위상·위임·보호영역·사건·개정의 기본 질서 |
| Bylaws.md | 시행령 — 헌법이 맡긴 운영 규칙: 노드 계약, _raw 계약, 군집과 pin, 율령, 위임 운영, 보호영역, 사건부 |
| Mechanism.md | 물리 최소 사양 — 배치 선언표, id·시각 형식, 대장 규약, 외부 표면(MCP) 계약, 링크 문법, 비밀값 필터 |
| Workbench-Contract.md | Workbench 계약 — 운영 활동 scope의 특별 지위와 정돈 규율 |
처음 읽는다면 Constitution → Bylaws → Mechanism 순서를 권한다. Mechanism의
§3(승인 기록부)과 §6-2(외부 표면)가 위에서 말한 세 구조의 물리 사양이다.
통치 문서의 비준은 이 정본 저장소에 대한 사용자의 확정 행위이며, 정식
릴리스의 비준증빙(release.json, 파일별 내용 해시 목록)으로 고정된다.
인스턴스는 릴리스를 갱신으로 받고, 갱신이 통치 문서를 덮으면 그 차이가 통치
구획 보호영역의 변경집합으로 남는다 — 사용자의 승인이 그 인스턴스의 수용
기록이다. 승인은 수용의 기록이지 효력의 요건이 아니다
(docs/SETUP.md).
Not included
지식 코퍼스(개념·결정·프로젝트 노드), 승인 기록부를 비롯한 모든 대장,
운영 세션 기록.
빈 = Scope/·= Domain/·= Person/ 디렉터리는 내려받은 사람이 자기
인스턴스를 시작할 자리다 — 규범이 정하는 배치(Mechanism §1)와 동형이다.
설치·운용 방법은 docs/SETUP.md를 본다.
License
MIT
Yorumlar (0)
Yorum birakmak icin giris yap.
Yorum birakSonuc bulunamadi