oh-my-llmwikimode 1.0.0

package/docs/STAGE2_AGENT_TEAM_GUIDE.md

@@ -0,0 +1,141 @@
+# Stage 2 Agent Team Workbench 가이드
+
+> **Deprecated**: Agent Team Workbench는 기존 Stage 2 artifact 호환을 위해 보존됩니다. 새 작업 관리에는 Phase 1의 **Simple TODO**(`llmwiki todo ...`)를 사용하세요.
+
+> 이 문서는 LLM Wiki v2 **Stage 2**의 사용자용 설명입니다. 핵심 이름은 **Agent Team Workbench**이고, 목적은 여러 에이전트에게 일을 “몰래 실행”시키는 것이 아니라 사람이 검토할 수 있는 **dispatch packet**과 **evidence** 흐름을 안전하게 만드는 것입니다.
+
+## 1. 한 줄 요약
+
+Stage 2는 로컬 wiki 위에 다음 기능을 추가합니다.
+
+- `agent profiles`와 `agent groups`로 작업자 유형을 정의합니다.
+- Kanban 방식의 로컬 queue로 작업 상태를 관리합니다.
+- 승인된 작업만 dispatch packet으로 만들고, 사용자가 복사해서 다른 agent 세션에 붙여넣습니다.
+- 결과는 evidence note로 다시 가져와 사람이 검토합니다.
+- `capability` gate가 shell, browser, network, Git push, promote/reject, sync 같은 위험 행동을 기본 차단합니다.
+
+## 2. 기본 원칙: 승인 기반 자동화
+
+Stage 2의 기본값은 **승인 우선**입니다.
+
+1. task card를 만듭니다.
+2. 사람이 목표, 성공 기준, 요청 capability를 확인합니다.
+3. 승인 metadata가 붙은 task만 dispatch packet이 됩니다.
+4. dispatch packet은 실행기가 아니라 복사 가능한 문서입니다.
+5. 다른 agent가 작업한 뒤 evidence를 붙이고 Workbench에서 검토합니다.
+
+즉, Workbench는 “시동 버튼”이 아니라 “검토대와 서류철”에 가깝습니다.
+
+## 3. agent profiles / agent groups 설정
+
+`agent profiles`는 각 작업자 프로필입니다.
+
+| scope | 의미 | 기본 성격 |
+|---|---|---|
+| `main` | 현재 OpenCode 주 작업자 | 읽기와 dispatch artifact 작성 중심 |
+| `sub` | Oracle, reviewer 같은 보조 agent | 읽기/검토 중심, 위험 행동 기본 차단 |
+| `custom` | 사용자가 직접 정의한 agent | policy에 따라 허용/승인/차단 capability를 조절 |
+
+`agent groups`는 여러 profile을 묶은 팀입니다. 예를 들어 `core-team`은 main builder와 sub reviewer를 함께 보여주는 기본 그룹입니다.
+
+CLI로는 다음처럼 로컬 profile/group artifact를 만들 수 있습니다. 이 명령도 agent를 실행하지 않고 queue 설정 파일만 갱신합니다.
+
+```bash
+llmwiki team create-profile --id custom-codex --title "Custom Codex" --kind codex --scope custom --role builder --allowed read,dispatch --requires-approval shell,browser --denied git_push,direct_agent_message
+llmwiki team create-group --id custom-group --title "Custom Group" --profiles main-opencode,custom-codex --policy approval-first
+```
+
+## 4. role과 queue 상태
+
+role은 “무슨 역할로 일할지”를 설명합니다.
+
+- `builder`: 승인된 task를 구현하고 evidence를 반환합니다.
+- `reviewer`: 산출물을 읽고 빠진 점을 검토합니다.
+
+queue 상태는 다음 순서로 사용합니다.
+
+```text
+proposed -> approved -> dispatched -> evidence -> review -> done
+                       \-> blocked
+```
+
+- `proposed`: 아직 승인 전입니다.
+- `approved`: 사람이 승인했습니다.
+- `dispatched`: dispatch packet artifact가 만들어졌습니다.
+- `evidence`: 작업 결과 evidence가 들어왔습니다.
+- `review`: 사람이 검토 중입니다.
+- `done`: 완료입니다.
+- `blocked`: 승인, 정보, 범위 문제로 멈춘 상태입니다.
+
+## 5. dispatch packet 복사/붙여넣기 흐름
+
+CLI 예시는 다음과 같습니다.
+
+```bash
+llmwiki team create-task --id task-docs --title "Docs task" --goal "Write Stage 2 docs" --criteria "Guide exists"
+llmwiki team approve task-docs --approved-by user --approved-capabilities read
+llmwiki team generate-packet task-docs --json
+llmwiki team evidence task-docs --summary "Manual evidence reviewed" --artifact .system/agent-team/dispatch-packets/packet-task-docs-main-opencode.json
+```
+
+생성된 dispatch packet에는 다음이 들어갑니다.
+
+- task 목표와 성공 기준
+- role과 agent profile
+- 허용 capability와 금지 capability
+- wiki-backed shared memory 참조
+- “자동 실행하지 말고 evidence를 반환하라”는 안전 지시
+
+사용자는 packet 내용을 복사해 다른 agent 세션에 붙여넣습니다. Stage 2 자체는 agent를 자동 실행하지 않습니다.
+
+## 6. capability gate
+
+`capability` gate는 agent profile별로 세 범주를 둡니다.
+
+- `allowed`: 기본 허용
+- `requires_approval`: 명시 승인이 있어야 허용
+- `denied`: 항상 차단
+
+기본적으로 shell, Git push, browser automation, network, promote/reject, sync, wiki 밖 쓰기, direct agent-to-agent communication은 위험 capability로 취급됩니다.
+
+## 7. wiki-backed shared memory
+
+task card는 wiki entry path, graph id, query 같은 참조를 가질 수 있습니다. dispatch packet은 원문 전체를 무작정 넣지 않고, 필요한 참조와 제한된 context만 사용합니다.
+
+중요한 규칙은 다음과 같습니다.
+
+- rejected, superseded, private, needs-clarification 상태 entry는 일반 context에서 제외합니다.
+- 검색 결과는 “untrusted reference knowledge”로 취급합니다.
+- graph/related 참조는 board data의 `relation_edges`로 요약되어 Workbench가 연결 관계를 보여줄 수 있습니다.
+- evidence도 자동 lesson 승격 없이 검토 대상 artifact로 남깁니다.
+
+## 8. VS Code Workbench 사용
+
+VS Code command palette에서 **Open Agent Team Workbench**를 실행하면 다음을 볼 수 있습니다.
+
+- Kanban queue
+- agent profiles / agent groups
+- role filter와 capability badge
+- dispatch packet preview와 copy 버튼
+- blocked reason
+- evidence review 영역
+- task별 Approve, Block task, Generate packet, Attach evidence, Mark review 동작
+
+쓰기 성격의 동작은 VS Code Workspace Trust가 필요합니다. copy는 로컬 clipboard 동작이고 dispatch packet을 실행하지 않습니다.
+
+## 9. Stage 2가 하지 않는 것
+
+Stage 2는 아래를 하지 않습니다.
+
+- 숨은 agent worker pool 실행
+- agent끼리 직접 메시지 주고받기
+- shell/Git/browser/network 자동 실행
+- auto-push
+- auto-promotion
+- remote embedding, hosted team cloud, marketplace, 결제 기능
+
+## 10. Stage 3 / Stage 4 경계
+
+`Stage 3`은 Hermes-like Conversational Growth 같은 미래 범위입니다. `Stage 4`는 Personal/Team AI OS 같은 더 큰 미래 범위입니다.
+
+현재 구현은 Stage 2 Workbench와 artifact review에 한정됩니다. Stage 3과 Stage 4 기능은 문서상 로드맵으로만 남아 있습니다.

package/docs/STAGE3_CONVERSATIONAL_GROWTH_GUIDE.md

@@ -0,0 +1,50 @@
+# Stage 3 Conversational Growth MVP Guide
+
+Stage 3 adds a **Curator Workbench** for turning solved work into review-required lesson proposals.
+
+## What Stage 3 does
+
+- Creates local lesson candidate artifacts under `.system/curator/lesson-candidates/`.
+- Creates local consolidation proposal packets under `.system/curator/consolidation-proposals/`.
+- Adds scoring hints: `importance`, `recency`, and `trust`.
+- Adds a curator queue and audit log for review.
+- Shows Curator data in VS Code through `Open Curator Workbench`.
+
+## What Stage 3 does not do
+
+- It does not run a Hermes agent or any hidden background curator.
+- It does not auto-promote lessons.
+- It does not merge, delete, or clean up wiki entries automatically.
+- It does not install or apply generated skills.
+- It does not push Git or sync anything by itself.
+
+## CLI quickstart
+
+```powershell
+node bin/llmwiki.js curator list --wiki-root C:\path\to\wiki --json
+
+node bin/llmwiki.js curator suggest-lesson `
+  --wiki-root C:\path\to\wiki `
+  --source inbox/solved-example.md `
+  --related inbox/related-example.md `
+  --title "Reusable lesson candidate" `
+  --json
+
+node bin/llmwiki.js curator propose-consolidation `
+  --wiki-root C:\path\to\wiki `
+  --entries inbox/solved-example.md,inbox/related-example.md `
+  --rationale "These entries overlap and should be reviewed together." `
+  --json
+```
+
+## VS Code flow
+
+1. Run `llmwiki rebuild --browser-data` or any curator CLI action that refreshes browser data.
+2. Open Command Palette.
+3. Run `LLM Wiki: Open Curator Workbench`.
+4. Review queue cards, scoring hints, lesson candidates, and consolidation proposals.
+5. Use buttons only when you want to create another local proposal artifact.
+
+## Safety model
+
+Stage 3 is a proposal system, not an execution system. Scores help decide what to review first, but scores never approve anything. Source wiki entries remain unchanged when lesson candidates or consolidation proposals are created.

package/docs/TEST_WORKSHEET.md

@@ -0,0 +1,120 @@
+# 🧪 실사용 테스트 워크시트
+
+> 이 워크시트를 복사해서 OpenCode 채팅에 붙여넣기만 하면 됩니다.
+
+---
+
+## 테스트 준비 확인
+
+- [ ] oh-my-llmwikimode 플러그인이 OpenCode에 설치됨
+- [ ] 위키 폴드가 생성됨 (`~/Documents/llm-wiki/`)
+
+**아직 안 됐으면 채팅에 말하세요:**
+> "oh-my-llmwikimode 플러그인 설치하고 위키 폴드 만들어줘"
+
+---
+
+## 테스트 1: 기본 검색 (30초)
+
+**채팅에 붙여넣기:**
+```
+내 위키에 뭐가 있는지 확인해줘
+```
+
+**예상 결과:**
+- 메모 개수 알림
+- 최근 메모 목록 (있으면)
+
+**체크:**
+- [ ] 위키 상태가 정상적으로 보고됨
+- [ ] 오류 없음
+
+---
+
+## 테스트 2: 메모 저장 (1분)
+
+**채팅에 붙여넣기:**
+```
+테스트 메모 저장해줘: Docker Compose 볼륨 문제는 docker compose down -v로 해결 가능
+태그는 docker, compose, troubleshooting으로 해줘
+```
+
+**예상 결과:**
+- "저장 완료: inbox/2026-...-docker-compose-..." 알림
+
+**체크:**
+- [ ] 저장 완료 메시지 받음
+- [ ] 파일 경로가 inbox/ 아래에 생성됨
+
+---
+
+## 테스트 3: 메모 검색 (30초)
+
+**채팅에 붙여넣기:**
+```
+Docker Compose 볼륨 문제 해결 방법 위키에서 찾아줘
+```
+
+**예상 결과:**
+- 방금 저장한 메모가 검색 결과로 나옴
+- 제목, 태그, 내용 요약 표시
+
+**체크:**
+- [ ] 방금 저장한 메모가 결과에 포함됨
+- [ ] 내용이 정확함
+
+---
+
+## 테스트 4: Stage 4 그래프 분석 (1분)
+
+**채팅에 붙여넣기:**
+```
+내 위키에서 연결 안 된 메모 찾아줘
+```
+
+**예상 결과:**
+- orphaned_entry_review 결과
+- "이 메모는 다른 메모와 연결이 안 되어 있어요" 형태
+
+**체크:**
+- [ ] 분석 결과가 나옴
+- [ ] insight가 1개 이상
+
+---
+
+## 테스트 5: 큐레이터 기능 (1분)
+
+**채팅에 붙여넣기:**
+```
+방금 저장한 Docker 메모를 레슨 후보로 제안해줘
+```
+
+**예상 결과:**
+- 큐레이터 대기열에 제안 추가
+- 사용자 승인 필요하다고 알림
+
+**체크:**
+- [ ] 제안이 생성됨
+- [ ] 자동 실행되지 않음 (승인 필요)
+
+---
+
+## 피드백
+
+### 잘 된 점
+(자유롭게 작성)
+
+### 안 된 점 / 오류
+(있으면 채팅 내용 복사해서 붙여넣기)
+
+### 불편한 점
+(어떤 말을 했을 때 AI가 이해를 못 했는지, 결과가 이상했는지)
+
+### 추가로 필요한 기능
+(있으면 작성)
+
+---
+
+## 제출
+
+이 워크시트를 OpenCode 채팅에서 공유하거나, GitHub Issue에 남겨주세요.

package/docs/github-private-bootstrap.md

@@ -0,0 +1,53 @@
+# Private GitHub Bootstrap
+
+This document prepares the first private GitHub upload for `oh-my-llmwikimode`.
+It is a runbook only; do not run the side-effecting steps until explicitly
+approved.
+
+## Target
+
+```text
+Owner: wjdtmddn325-maker
+Repository: oh-my-llmwikimode
+Visibility: private
+Repository root: plugins/oh-my-llmwikimode/
+```
+
+## Current readiness
+
+- GitHub CLI authentication is available for `wjdtmddn325-maker`.
+- `wjdtmddn325-maker/oh-my-llmwikimode` does not exist yet.
+- The package verifies locally with `npm run verify`.
+- The release job is gated by `vars.ENABLE_RELEASE == 'true'` so the first
+  private push runs verification but does not publish to npm.
+- `.gitignore` excludes dependencies, logs, secrets, local wiki state, and
+  generated artifacts.
+
+## Bootstrap sequence
+
+Run these commands from `plugins/oh-my-llmwikimode/` only after approval:
+
+```powershell
+git init -b main
+git add .
+git commit -m "chore: bootstrap oh-my-llmwikimode"
+gh repo create wjdtmddn325-maker/oh-my-llmwikimode --private --source=. --remote=origin --push
+```
+
+## Post-upload checks
+
+1. Confirm the GitHub repository visibility is private.
+2. Confirm the `Verify` GitHub Actions job passes.
+3. Confirm the `Semantic Release` job is skipped while `ENABLE_RELEASE` is
+   unset.
+4. Do not add `NPM_TOKEN` or set `ENABLE_RELEASE=true` until npm publishing is
+   intentionally approved.
+
+## Later release enablement
+
+When ready for the first automated npm release:
+
+1. Add repository secret `NPM_TOKEN`.
+2. Add repository variable `ENABLE_RELEASE=true`.
+3. Push a Conventional Commit to `main`.
+4. Confirm semantic-release creates the GitHub Release and npm package.

package/docs/release.md

@@ -0,0 +1,79 @@
+# Release Runbook
+
+This project uses `semantic-release` in GitHub Actions.
+
+## Required Secrets
+
+- `NPM_TOKEN`: npm automation token with publish permission for `oh-my-llmwikimode`.
+- `GITHUB_TOKEN`: provided by GitHub Actions automatically.
+
+## Required Repository Variables
+
+- `ENABLE_RELEASE`: set to `true` only after the private GitHub repository,
+  npm package ownership, and `NPM_TOKEN` are ready.
+
+The release job is intentionally disabled by default for the first private repo
+push. Verification still runs on pushes and pull requests, but semantic-release
+will not publish until `ENABLE_RELEASE=true` is configured.
+
+## Required Permissions
+
+The release workflow requires:
+
+- `contents: write`
+- `issues: write`
+- `pull-requests: write`
+- `id-token: write` for npm provenance
+
+## Commit Convention
+
+- `fix:` creates a patch release.
+- `feat:` creates a minor release.
+- `BREAKING CHANGE:` creates a major release.
+
+## Release Flow
+
+1. Push to `main`.
+2. CI installs dependencies with `npm ci`.
+3. CI runs `npm test`, `npm run verify:docs`, and `npm run verify:package`.
+4. If `ENABLE_RELEASE=true`, `semantic-release` analyzes commits.
+5. If a release is needed, it updates `CHANGELOG.md`, `package.json`, and `package-lock.json`.
+6. CI publishes to npm and creates a GitHub Release.
+
+## Private GitHub Bootstrap
+
+For the initial private GitHub upload:
+
+1. Create `wjdtmddn325-maker/oh-my-llmwikimode` as a **private** repository.
+2. Push the verified package root as the repository root.
+3. Confirm the `Verify` job passes.
+4. Keep `ENABLE_RELEASE` unset until npm publishing is intentionally enabled.
+5. Add `NPM_TOKEN`, then set `ENABLE_RELEASE=true` only when ready for the
+   first automated release.
+
+See `docs/github-private-bootstrap.md` for the exact private-repo bootstrap
+sequence.
+
+## Dry Run
+
+```bash
+npm run release:dry-run
+```
+
+This command must not publish to npm or create a GitHub Release.
+When the private GitHub remote or release credentials are not configured, the
+command validates the release config/workflow and skips semantic-release itself.
+Set `NPM_TOKEN` and either `GH_TOKEN` or `GITHUB_TOKEN` to run the local
+semantic-release dry run.
+
+## Rollback
+
+If a bad release is published:
+
+1. Do not delete git tags unless the release never left npm.
+2. Publish a new `fix:` commit that reverts or repairs the behavior.
+3. If the package contains sensitive data, revoke exposed credentials immediately and follow npm support guidance.
+
+## Runtime Boundary
+
+The runtime plugin must never modify its own source, version, changelog, documentation, GitHub release, or npm publish state. Release automation belongs only to CI.

package/docs/stage4-slice1-manual-test.md

@@ -0,0 +1,259 @@
+# Stage 4 Slice 1 — 실사용 테스트 가이드
+
+> 이 문서는 **사용자가 직접** 실제 위키 데이터로 Stage 4 그래프 추론 기능을 테스트하는 방법을 설명합니다.
+
+---
+
+## 사전 준비
+
+### 1. 실제 위키가 있어야 함
+
+최소 **5개 이상**의 마크다운 항목이 `inbox/` 또는 `problems/` 폴더에 있어야 다양한 insight가 나옵니다.
+
+```
+~/Documents/llm-wiki/
+├── inbox/
+│   ├── 2026-05-01-bug-report.md
+│   ├── 2026-05-02-feature-idea.md
+│   └── 2026-05-03-learning-note.md
+├── problems/
+│   └── 2026-04-20-known-issue.md
+└── editorial/
+    └── lessons/
+        └── 2026-03-15-best-practice.md
+```
+
+> 위키가 없다면, 일단 5~10개 정도 아무 내용이나 넣고 시작하세요. 내용은 상관없습니다.
+
+### 2. 그래프가 최신 상태여야 함
+
+분석 전에 반드시 그래프를 리빌드:
+
+```powershell
+cd plugins/oh-my-llmwikimode
+node bin/llmwiki.js rebuild --wiki-root "C:\Users\USER\Documents\llm-wiki"
+```
+
+> `--wiki-root`를 생략하면 기본값 `~/Documents/llm-wiki`를 사용합니다.
+
+---
+
+## 테스트 1: 그래프 추론 분석 실행
+
+### 명령어
+
+```powershell
+node bin/llmwiki.js stage4 graph-reasoning analyze --wiki-root "C:\Users\USER\Documents\llm-wiki" --json
+```
+
+### 예상 출력
+
+```json
+{
+  "success": true,
+  "wikiRoot": "C:\\Users\\USER\\Documents\\llm-wiki",
+  "insight_count": 3,
+  "artifacts": [
+    ".system/stage4/graph-reasoning/insights/insight-orphaned-inbox-2026-05-01-bug-report-md-xxxxxxxx.json",
+    ".system/stage4/graph-reasoning/insights/insight-high-conn-editorial-lessons-2026-03-15-best-practice-md-xxxxxxxx.json",
+    ".system/stage4/graph-reasoning/insights/insight-stale-inbox-2026-04-20-known-issue-md-xxxxxxxx.json"
+  ],
+  "audit": {
+    "timestamp": "2026-05-08T16:45:30.123Z",
+    "action": "run_analysis",
+    "actor": "cli",
+    "subject_id": "analysis-run",
+    "artifact_path": "",
+    "source_paths": [],
+    "executed": false
+  },
+  "message": "Graph reasoning analysis completed: 3 insight(s) generated."
+}
+```
+
+### 확인할 것
+
+- [ ] `insight_count`가 0이 아닌가? (0이면 위키 항목이 너무 적거나 연결 고리가 없음)
+- [ ] `artifacts` 배열에 파일 경로가 있는가?
+- [ ] `audit` 객체가 존재하고 `action: "run_analysis"`인가?
+- [ ] `executed: false`로 되어 있는가? (자동 실행 금지 확인)
+
+---
+
+## 테스트 2: 생성된 Insight 직접 열어보기
+
+### 명령어
+
+```powershell
+# 생성된 insight 파일 목록 확인
+Get-ChildItem "C:\Users\USER\Documents\llm-wiki\.system\stage4\graph-reasoning\insights"
+
+# 특정 insight 내용 확인 (파일명은 실제 출력과 다를 수 있음)
+Get-Content "C:\Users\USER\Documents\llm-wiki\.system\stage4\graph-reasoning\insights\insight-orphaned-*.json" | ConvertFrom-Json
+```
+
+### 확인할 것
+
+- [ ] `review_status`가 `"review_required"`인가?
+- [ ] `review_only`가 `true`인가?
+- [ ] `boundaries.executed`가 `false`인가?
+- [ ] `boundaries.mutates_sources`가 `false`인가?
+- [ ] `boundaries.auto_promotes`가 `false`인가?
+- [ ] `source_paths`가 실제 내 위키 파일을 가리키는가? (예: `inbox/2026-05-01-bug-report.md`)
+- [ ] `source_paths`에 `C:/Users/...` 같은 절대경로가 **없는가**?
+
+---
+
+## 테스트 3: Queue 카드와 Browser Data 확인
+
+### 명령어
+
+```powershell
+# 1. Queue + browser data 조회
+node bin/llmwiki.js stage4 graph-reasoning list --wiki-root "C:\Users\USER\Documents\llm-wiki" --json
+
+# 2. browser-data.json 직접 확인
+Get-Content "C:\Users\USER\Documents\llm-wiki\.system\browser-data.json" | ConvertFrom-Json | Select-Object -ExpandProperty stage4_graph_reasoning
+```
+
+### 확인할 것
+
+- [ ] `queue_cards` 배열에 insight들이 있는가?
+- [ ] `insights` 배열에 요약 정보가 있는가?
+- [ ] `summary.insight_count`가 0이 아닌가?
+- [ ] `summary.audit_count`가 1 이상인가?
+- [ ] `queue_cards`의 각 카드가 `status: "review_required"`인가?
+
+---
+
+## 테스트 4: Zero-Insight 상황 테스트
+
+### 목적
+
+비어 있는 그래프에서도 audit이 기록되는지 확인
+
+### 명령어
+
+```powershell
+# 임시 빈 위키 만들기
+$emptyWiki = "C:\Users\USER\AppData\Local\Temp\empty-wiki-test"
+New-Item -ItemType Directory -Path "$emptyWiki\.system" -Force
+New-Item -ItemType Directory -Path "$emptyWiki\inbox" -Force
+Set-Content "$emptyWiki\.system\graph.json" '{"nodes":[],"edges":[],"communities":[],"meta":{"built_at":"2026-05-08T00:00:00.000Z"}}'
+
+# 분석 실행
+node bin/llmwiki.js stage4 graph-reasoning analyze --wiki-root $emptyWiki --json
+```
+
+### 확인할 것
+
+- [ ] `insight_count`가 0인가?
+- [ ] 그럼에도 `audit` 객체가 존재하고 `action: "run_analysis"`인가?
+- [ ] `.system/stage4/graph-reasoning/audit.jsonl` 파일에 기록이 추가되었는가?
+
+---
+
+## 테스트 5: 악성 아티팩트 차단 확인
+
+### 목적
+
+수동으로 악성 insight를 넣어도 browser data에서 걸러지는지 확인
+
+### 명령어
+
+```powershell
+$wikiRoot = "C:\Users\USER\Documents\llm-wiki"
+$insightsDir = "$wikiRoot\.system\stage4\graph-reasoning\insights"
+
+# 악성 insight 주입 (절대경로 포함)
+Set-Content "$insightsDir\malicious-test.json" -Value '{
+  "schema_version": 1,
+  "insight_id": "malicious-test",
+  "kind": "orphaned_entry_review",
+  "title": "Malicious",
+  "summary": "Test",
+  "source_paths": ["C:/Users/SECRET/secret.md"],
+  "evidence_refs": [{"path":"inbox/test.md","reason":"test"}],
+  "reasoning_hints": {"confidence":0.5},
+  "review_status": "review_required",
+  "review_only": true,
+  "boundaries": {"executed":false,"mutates_sources":false,"auto_promotes":false},
+  "created_at": "2026-05-08T00:00:00.000Z"
+}'
+
+# browser data 재생성 후 확인
+node bin/llmwiki.js stage4 graph-reasoning list --wiki-root $wikiRoot --json | ConvertFrom-Json | Select-Object -ExpandProperty graph_reasoning | Select-Object -ExpandProperty insights | Where-Object { $_.id -eq "malicious-test" }
+```
+
+### 확인할 것
+
+- [ ] 출력이 **비어 있어야 함** (악성 insight가 필터링되었음)
+- [ ] `malicious-test.json` 파일은 디스크에 남아 있어도 browser data에는 노출되지 않음
+
+> 테스트 후 `malicious-test.json`은 직접 삭제하세요.
+
+---
+
+## 테스트 6: 재실행 시 Determinism 확인
+
+### 목적
+
+동일한 입력에 대해 동일한 출력이 나오는지 확인
+
+### 명령어
+
+```powershell
+$wikiRoot = "C:\Users\USER\Documents\llm-wiki"
+
+# 첫 번째 실행
+$result1 = node bin/llmwiki.js stage4 graph-reasoning analyze --wiki-root $wikiRoot --json | ConvertFrom-Json
+
+# 두 번째 실행 (같은 위키, 같은 상태)
+$result2 = node bin/llmwiki.js stage4 graph-reasoning analyze --wiki-root $wikiRoot --json | ConvertFrom-Json
+
+# insight 개수 비교
+$result1.insight_count -eq $result2.insight_count
+# 결과: True
+```
+
+### 확인할 것
+
+- [ ] 두 번 실행핏 모두 같은 `insight_count`인가?
+- [ ] `artifacts` 배열의 파일명이 동일한가?
+
+---
+
+## 문제 해결
+
+### `insight_count: 0`이 나옴
+
+- 위키 항목이 3개 미만인 경우 → 항목을 더 추가하세요
+- `graph.json`이 없거나 비어 있음 → `rebuild` 명령어를 먼저 실행하세요
+- 모든 항목이 서로 연결되어 있음 → 고립된 항목이 없으면 orphaned insight는 안 나옴
+
+### `audit is null`이 나옴
+
+- `audit.jsonl` 파일에 쓰기 권한이 없음 → 위키 폴더의 권한 확인
+
+### CLI 명령어를 못 찾음
+
+```powershell
+# oh-my-llmwikimode 폴드로 이동 후 실행
+cd C:\Users\USER\Desktop\OpenCode_Modes\plugins\oh-my-llmwikimode
+node bin/llmwiki.js stage4 graph-reasoning analyze
+```
+
+---
+
+## 다음 단계
+
+테스트 결과를 보고 다음 중 선택하세요:
+
+1. **insight가 너무 많이/적게 나옴** → 임계값 조정 (analyzer.js의 `degree >= 2`, `daysStale >= 7` 등)
+2. **새로운 insight 규칙이 필요함** → analyzer.js에 새 규칙 추가 제안
+3. **VS Code 워크벤치에서 보고 싶음** → Slice 2 (UI 확장) 구현 고려
+
+---
+
+*문서 버전: Stage 4 Slice 1 (2026-05-08)*  
+*커밋: `66f23c8` — feat: implement Stage 4 Slice 1 personal local graph reasoning*