oh-my-llmwikimode 1.1.0 → 1.2.0

package/docs/design/EOS_CHAT_HOME_IA.md

@@ -0,0 +1,129 @@
+# Eos Chat Home Information Architecture
+
+**Status:** Active implementation contract for Eos Chat Command Center MVP  
+**Date:** 2026-05-29  
+**Depends on:** `EOS_DESIGN.md`, `EOS_UI_CONTRACT.md`, `EOS_SIDE_REVIEW_IA.md`
+
+## 1. Purpose
+
+`Eos Chat` is the first screen and local command center for Eos.
+
+The user starts by saying what they want. Eos must capture that intent as a local review-required artifact, then make it visible in `Side Review`. Chat does not execute shell commands, providers, agents, wiki promotion, git actions, or background work by itself.
+
+## 2. Primary promise
+
+Use this product promise when shaping UI copy:
+
+```text
+Tell Eos what you want to prepare. Eos captures it for local review before anything is applied.
+```
+
+## 3. Required regions
+
+1. **Header rail** - `Eos Chat`, short local workspace status, and link to `Side Review`.
+2. **Safety strip** - always-visible copy: `Local review workspace. Nothing is applied automatically.`
+3. **Welcome state** - explains chat-first workflow without starter chips.
+4. **Status cards** - wiki status, review queue count, and harness readiness in compact cards.
+5. **Message list** - local acknowledgements only; no execution transcript unless a future approved execution flow exists.
+6. **Composer** - bottom input with a short placeholder and explicit send button.
+
+## 4. Empty state copy
+
+Approved empty-state copy:
+
+- `Start with a request.`
+- `Eos will capture it as a local review item.`
+- `Open Side Review to inspect drafts, evidence, and decisions.`
+- `Review Required`
+- `Not Applied`
+- `Local Only`
+
+Do not add starter chips in this slice. Shortcuts may return later only after real usage shows which actions matter.
+
+## 5. Composer contract
+
+- Placeholder: `Tell Eos what you want to prepare...`
+- Button label: `Capture for Review`
+- Success acknowledgement: `Captured for review.`
+- Follow-up link/action: `Open Side Review`
+
+The composer must not use copy such as `Run`, `Execute`, `Complete`, `Apply`, or `Push`.
+
+## 6. Data flow
+
+```text
+Eos Chat message
+  -> POST /api/chat/requests
+  -> .system/eos/chat/requests/{id}.json
+  -> .system/eos/chat/audit.jsonl
+  -> GET /api/side-review
+  -> Side Review card in Review Required
+  -> optional local Side Review decision artifact
+```
+
+The original wiki entries are not mutated by this flow.
+
+## 7. Forbidden labels
+
+Do not use these labels in the Eos Chat MVP:
+
+- `Run Now`
+- `Execute`
+- `Auto Apply`
+- `Apply Automatically`
+- `Promote Now`
+- `Merge Now`
+- `Delete Now`
+- `Push to GitHub`
+- `Run in Background`
+- `Completed` for a request that was only captured
+
+## 8. Route contract
+
+- `GET /chat/` serves the Eos Chat local UI.
+- `GET /chat` redirects to `/chat/`.
+- `GET /api/home` remains a read-only home data snapshot.
+- `POST /api/chat/requests` creates a review-required local artifact only.
+
+## 9. Safety contract
+
+- Local-first.
+- Review-required.
+- No hidden execution.
+- No source wiki mutation.
+- No hosted sync.
+- No auto-promotion, auto-merge, auto-delete, or auto-push.
+- Browser UI uses self-only CSP, local assets, and text-node rendering.
+
+## 10. Chat operating loop and intent hints
+
+Chat is the inbox. Side Review is the review desk.
+
+Captured chat requests now carry deterministic intent hint metadata before they appear in Side Review. The hint helps the user quickly see whether the request looks like a knowledge capture, search, plan, issue report, release log, or unknown/ambiguous request. It is always review-only metadata and never approval or execution.
+
+Additional Home status card:
+
+- `Chat Intents` - summarizes waiting chat requests by intent category.
+
+Updated flow:
+
+```text
+Eos Chat message
+  -> POST /api/chat/requests
+  -> request artifact with intent hint
+  -> GET /api/home intent counts
+  -> GET /api/side-review Side Review card
+  -> prepare-only decision artifact
+```
+
+## 11. Command Center Dashboard Slice
+
+`GET /api/home` now exposes an `Eos Command Center` summary for the chat-first workspace. The browser copy may call this panel `Mission Control`, but the data contract remains `command_center` with English technical keys and Korean-friendly display labels.
+
+Required dashboard groups:
+
+- `Waiting Review` - points to `Side Review` and shows review-required pressure.
+- `Recent Requests` - previews the latest captured chat requests without opening raw artifacts.
+- `System Health` - explains local load errors or confirms local review data is readable.
+
+The Chat home panel may show compact `Next Safe Actions` and `Recent Requests`, but these are navigation/review aids only. They must not become starter chips, execution shortcuts, provider dispatch, or hidden agent controls.

package/docs/design/EOS_CHAT_OPERATING_LOOP.md

@@ -0,0 +1,101 @@
+# Eos Chat Operating Loop
+
+**Status:** Active implementation contract for the chat-to-review operating loop  
+**Date:** 2026-05-29  
+**Depends on:** `EOS_CHAT_HOME_IA.md`, `EOS_SIDE_REVIEW_IA.md`, `EOS_DESIGN.md`
+
+## 1. Simple metaphor
+
+Chat is the inbox. Side Review is the review desk.
+
+The user writes a request in `Eos Chat`. Eos files it as a local review item, adds a deterministic intent hint, and places it on the `Side Review` desk. Nothing is executed or applied just because the request was captured.
+
+## 2. Operating loop
+
+```text
+User request in Eos Chat
+  -> local capture endpoint
+  -> chat request artifact
+  -> intent hint metadata
+  -> Side Review card
+  -> prepare-only decision artifact
+  -> human approval path in a later slice
+```
+
+## 3. Intent hint contract
+
+Intent hints are review labels, not decisions.
+
+Supported hint categories:
+
+- `knowledge_request` - the user seems to want a wiki, draft, document, or knowledge capture.
+- `search_request` - the user seems to want lookup, location, or discovery.
+- `planning_request` - the user seems to want a plan, roadmap, design, or ultragoal.
+- `issue_report` - the user seems to report a bug, failure, broken behavior, or improvement need.
+- `release_log` - the user seems to want handoff, changelog, deployment, or sync notes.
+- `unknown` - the request is unclear, ambiguous, or has no deterministic keyword evidence.
+
+Every hint must stay:
+
+- local-only,
+- deterministic,
+- review-hint-only,
+- non-executing,
+- non-approving,
+- safe after secret redaction.
+
+## 4. Artifact flow
+
+```text
+POST /api/chat/requests
+  writes .system/eos/chat/requests/{id}.json
+  appends .system/eos/chat/audit.jsonl
+
+GET /api/home
+  exposes waiting count, intent counts, and recent request summaries
+
+GET /api/side-review
+  exposes chat request cards with intent label, request preview, evidence, and safe next action
+
+POST /api/agent/side-review/decisions
+  writes .system/eos/side-review/decisions/{id}.json
+  appends .system/eos/side-review/audit.jsonl
+```
+
+## 5. UI promise
+
+Chat should answer: "What did I just capture, and where can I review it?"
+
+Side Review should answer: "What is this request, why is it here, what evidence exists, and what safe prepare-only action can I take?"
+
+## 6. Non-goals
+
+This slice must not add:
+
+- shell execution,
+- provider dispatch,
+- hidden agents,
+- Discord bridge behavior,
+- hosted sync,
+- package splitting,
+- NPM publishing,
+- auto-promotion,
+- auto-merge,
+- auto-delete,
+- auto-push,
+- source wiki entry mutation.
+
+## 7. Verification anchors
+
+- `test/eos/chat-intent-hints.test.js`
+- `test/eos/chat-requests.test.js`
+- `test/eos/chat-routes.test.js`
+- `test/eos/home-data.test.js`
+- `test/eos/side-review-routes.test.js`
+- `test/eos/uiux-product-shape.test.js`
+
+## 8. Command Center coordination
+
+`Home` is the mission-control layer between Chat and Side Review. It should tell the user what is waiting, what was recently captured, and whether any local artifact needs attention before the user opens raw files.
+
+`Side Review` adds intent filters so chat-derived requests can be inspected by review hint category: knowledge, search, planning, issue, release log, or unknown. These intent filters are visibility controls, not approval controls. Filtering must not apply, promote, merge, delete, push, publish, or mutate source wiki entries.

package/docs/design/EOS_DESIGN.md

@@ -2,26 +2,70 @@
 
 ## Status
 
-Active draft design source of truth for the Eos VS Code webview workspace.
+Active design source of truth for the Eos local workspace UI.
 
 This document does not replace implementation tests. It defines the product and visual direction that future UI work must translate into code, tests, and review evidence.
 
 ## Product Role
 
-Eos is a chat-first local AI orchestration harbor for LLM Wiki work. The user starts by saying what they want in chat; Eos then shapes the request into drafts, review requests, dispatch packets, evidence requests, or separate helper panels without hidden execution.
+Eos is a chat-first local AI orchestration workspace for LLM Wiki work. The user starts by saying what they want in chat; Eos then shapes the request into drafts, review requests, dispatch packets, evidence requests, or separate helper panels without hidden execution.
 
-Eos is **not** a cloud assistant surface, marketing landing page, or autonomous execution dashboard.
+Eos is **not** a cloud assistant surface, marketing landing page, autonomous execution dashboard, or a renamed LLM Wiki Mode screen. LLM Wiki Mode remains an attached local knowledge backend through explicit adapters.
 
 ## Design Metaphor
 
-**Dawn Control Room**
+**Clean AI Workspace**
 
-- Dawn: clear, hopeful, calm sky-blue accent, not neon or marketing-heavy.
-- Control Room: state, review gates, local artifacts, and navigation are explicit.
-- Workspace: chat is the center; Library, Graph, Curator, Agent Team, Review Workbench, and Settings open as separate helper panels only when useful.
+- Clean: clear hierarchy, calm surfaces, readable labels, and no decorative noise.
+- AI: the primary gesture is conversation; the interface explains what AI prepared and what still needs review.
+- Workspace: local artifacts, review gates, evidence, and harness state are visible without becoming a dashboard-first product.
 
 The interface should feel like a trustworthy local cockpit where conversation opens separate work panels, not a generic chatbot SaaS clone or button-heavy dashboard.
 
+Compatibility note: the VS Code extension design gate still tracks the earlier `Dawn Control Room` metaphor and the Korean chat prompt `무엇을 맡길까요?`. Treat both as compatible markers for the same calm, chat-first local command center direction, not as permission to add a dashboard-first or execution-first surface.
+
+## Primary Surfaces for This Slice
+
+### Eos Chat
+
+- Home surface and default starting point.
+- Captures user intent in natural language.
+- Shows concise local connection, review, and safety state.
+- Does not use starter chips in this slice.
+- Should make the next safe action obvious without implying hidden execution.
+
+
+### Chat Command Center MVP
+
+- Dedicated local route: `/chat/`.
+- Tone: calm command center, not a generic chatbot landing page.
+- Primary promise: `Tell Eos what you want to prepare. Eos captures it for local review before anything is applied.`
+- Chat messages create review-required local request artifacts only.
+- Captured requests appear in `Side Review` before any write-like decision.
+- The screen must keep `Local Only`, `Review Required`, and `Not Applied` visible.
+- This slice still avoids starter chips; convenience shortcuts can be designed after real usage patterns are visible.
+
+### Side Review
+
+- Separate helper surface for looking at structured material while chat stays focused.
+- Shows drafts, review-required items, evidence, issues, completion reports, and harness status.
+- Cards should expose title, reason, source/evidence, current state, and safe next action.
+- Must keep `Review Required` / `Not Applied Yet` visible before any write-like action.
+- Decision-like actions prepare local review artifacts only. The user may prepare approval, rejection, or defer notes, but Eos must not apply them automatically.
+
+### Side Review Polish MVP
+
+- Dedicated local route: `/side-review/`.
+- Tone: calm review desk, not a command console.
+- Primary promise: `Local Review Artifact` and `Not Applied` must remain visible near decision actions.
+- The user should understand three things at a glance:
+  1. what needs review,
+  2. where the evidence came from,
+  3. which safe prepare-only action can be taken next.
+- A polished card is useful only if it keeps source path, artifact path, workflow state, and evidence visible.
+- Empty and error states should be plain language, not machine logs.
+- The route is an Eos UI surface attached to LLM Wiki data; it is not a new LLM Wiki product surface.
+
 ## Visual System
 
 ### Color Intent
@@ -35,13 +79,13 @@ Use VS Code theme variables first. Eos accent colors are allowed only as semanti
 | Text | `--vscode-foreground` |
 | Muted text | `--vscode-descriptionForeground` |
 | Border | `--vscode-panel-border`, `--vscode-widget-border` |
-| Primary action | Eos sky token mapped to theme-safe blue |
+| Primary action | restrained Eos blue token mapped to theme-safe blue |
 | Warning/review | VS Code warning color or local amber token |
 | Error/blocked | `--vscode-errorForeground` or local danger token |
 
 ### Eos Accent Rules
 
-- Sky blue is the primary accent, not the whole interface.
+- Blue is a restrained primary accent, not the whole interface.
 - Large gradients are allowed only in deliberate hero/brand moments, not repeated in every header.
 - Header, menu, and button blue must come from tokens, not ad hoc hex values.
 - Dark, light, high-contrast, and reduced-motion modes must remain usable.
@@ -49,7 +93,7 @@ Use VS Code theme variables first. Eos accent colors are allowed only as semanti
 ### Typography
 
 - Use VS Code default UI font.
-- Korean copy should be short, direct, and user-action oriented.
+- User-facing labels should be short, direct, and action oriented.
 - Use `Eos` casing everywhere unless a VS Code label mechanically uppercases it.
 - Avoid mixing `EOS`, `Eos Workspace`, `Eos Home`, and `Eos Chat` without an explicit naming rule.
 
@@ -70,6 +114,7 @@ Use VS Code theme variables first. Eos accent colors are allowed only as semanti
 
 - Local-first: no cloud runtime assumption.
 - Review-required: suggestions are visible artifacts, not automatic actions.
+- Explicit approval only for write-like behavior.
 - No hidden execution, no auto-promotion, no auto-merge/delete, no auto-push.
 - UI may prepare drafts, packets, and review proposals, but must label them as such.
 
@@ -77,18 +122,179 @@ Use VS Code theme variables first. Eos accent colors are allowed only as semanti
 
 Good:
 
-- "무엇을 맡길까요?"
-- "검토할 정보가 없습니다. 새 정보가 생기면 여기에 표시합니다."
-- "로컬 위키 기준으로 정리 제안만 만들었습니다."
+- `What do you want AI to help with?`
+- `Wiki Mode Connected`
+- `Write Mode: Review Required`
+- `Review Queue Ready`
+- `No review items yet. New drafts will appear here as Not Applied Yet.`
+- `Prepare Review`
+- `Prepare Approval Request`
+- `Prepare Rejection Note`
+- `Defer Review`
+- `Open Evidence`
+- `Evidence Available`
 
 Avoid:
 
-- "제가 알아서 처리했습니다."
-- "자동으로 편집했습니다."
-- "실행 중입니다" when no explicit user-approved execution exists.
+- `I applied it for you` before explicit approval.
+- `Merged automatically` or `Promoted automatically`.
+- `Executing now` when no explicit user-approved execution exists.
+- Cryptic machine status strings as primary UI copy.
+- Corrupted/mojibake copy in user-facing surfaces.
 
 ## Future Direction
 
 - Discord should become a conversational entry or notification bridge only after the VS Code chat-first contract is stable.
 - Agent/harness UX should explain capability and safety before offering dispatch actions.
 - Quick chips may return later, but only when real usage patterns prove which shortcuts matter.
+
+## Implemented Slice - 2026-05-28
+
+The Eos UIUX Product Shape Longrun implemented the first Clean AI Workspace slice across:
+
+- `Eos Chat` data contract: readable prompt, status strip, empty/blocked copy, and safe next actions.
+- `Side Review` view model: readable groups, card hierarchy, evidence/source labels, count/status labels, and safe action language.
+- Static Academy UI: calmer Clean AI Workspace copy/colors, review-required/local-only status text, narrow webview handling, reduced-motion handling, and no mojibake metadata separator.
+
+Verification anchors:
+
+- `test/eos/home-data.test.js`
+- `test/eos/workspace-boundary-side-review-view-model.test.js`
+- `test/eos/academy.test.js`
+- `test/eos/uiux-product-shape.test.js`
+
+## Implemented Workflow Slice - 2026-05-28
+
+The Eos Side Review Workflow MVP adds the first decision-preparation layer without broad visual redesign:
+
+- Workflow states: `Not Applied Yet`, `Needs Review`, `Ready for Human Decision`, `Evidence Missing`, and `Deferred`.
+- Card metadata: candidate type, priority hint, age hint, evidence status, and multiple safe next actions.
+- Local artifacts: `POST /api/agent/side-review/decisions` writes review-required decision JSON under `.system/eos/side-review/decisions/` and appends `.system/eos/side-review/audit.jsonl`.
+- Read API: `GET /api/side-review` returns the workflow-ready Side Review view model from the attached LLM Wiki backend.
+- Boundary: no Discord expansion, no package split, no publish, no auto-promotion, no auto-merge/delete, no auto-push, and no source wiki entry mutation.
+
+Verification anchors:
+
+- `test/eos/workspace-boundary-side-review-workflow.test.js`
+- `test/eos/workspace-boundary-side-review-view-model.test.js`
+- `test/eos/side-review-artifacts.test.js`
+- `test/eos/side-review-routes.test.js`
+- `scripts/verify-eos-workspace-boundary.js`
+- `scripts/verify-eos-boundary-policy.js`
+
+## Implemented Side Review UI Polish MVP - 2026-05-29
+
+The Eos Side Review UI Polish MVP adds a dedicated local review desk at `/side-review/`.
+
+What changed:
+
+- Eos now has a visible Side Review surface for structured review work instead of API-only Side Review data.
+- The screen uses a Clean AI Workspace layout: header rail, safety strip, group tabs, card grid, and prepare-only decision panel.
+- Cards keep workflow state, priority, age, source, artifact, and evidence visible.
+- Decision controls are explicitly local review artifact preparation, not execution.
+- Theme/accessibility pass covers VS Code token fallbacks, keyboard focus, reduced motion, and forced-colors handling.
+
+Product boundary:
+
+- Eos is the UI/workspace that helps the user inspect and prepare review artifacts.
+- LLM Wiki is the attached knowledge backend that stores drafts, queues, evidence, and local review artifacts.
+- This slice does not split packages, add Discord, publish NPM, add cloud sync, or create automatic promotion/merge/delete/push behavior.
+- Side Review browser hardening is scoped to self-only CSP, text-node rendering, and server-provided action metadata. `daemonToken` mode stays protected by Bearer-token auth; default local no-token browser UX is the MVP path.
+
+User-facing route:
+
+```text
+/side-review/
+```
+
+Verification anchors:
+
+- `test/eos/side-review-routes.test.js`
+- `test/eos/uiux-product-shape.test.js`
+
+## Implemented Chat Operating Loop Slice - 2026-05-29
+
+The Eos Chat Operating Loop slice connects the chat inbox to the review desk with deterministic intent hints.
+
+What changed:
+
+- `Eos Chat` captures each request as a local artifact with a review-only intent hint.
+- `GET /api/home` summarizes waiting chat request intent counts and recent request previews.
+- `Side Review` cards show intent label, redacted request preview, evidence, artifact path, and safe next action.
+- Prepare-only decision artifacts preserve intent metadata so later review can understand why the card exists.
+
+Boundary:
+
+- Intent hints are labels for review, not AI decisions.
+- The flow does not execute, dispatch, approve, promote, merge, delete, push, sync, or mutate source wiki entries.
+
+Verification anchors:
+
+- `test/eos/chat-intent-hints.test.js`
+- `test/eos/chat-requests.test.js`
+- `test/eos/chat-routes.test.js`
+- `test/eos/home-data.test.js`
+- `test/eos/side-review-routes.test.js`
+- `test/eos/uiux-product-shape.test.js`
+
+## Implemented Command Center UX Slice - 2026-05-29
+
+The Eos Command Center UX slice makes the existing chat-to-review loop easier to understand without expanding runtime power.
+
+What changed:
+
+- `GET /api/home` now returns a `command_center` summary with `Waiting Review`, `Recent Requests`, `System Health`, Korean-friendly display labels, and safe next actions.
+- `Eos Chat` shows a compact `Mission Control` panel with local status, `Next Safe Actions`, and `Recent Requests` so the user can decide what to inspect next without opening every raw artifact.
+- `Side Review` exposes intent filters and a safer card sort order so chat-derived requests are easier to scan by issue, planning, knowledge, search, release log, or unknown intent.
+- Shared copy keeps the same product language: `Chat`, `Home`, `Side Review`, `Review Queue`, `Request Artifact`, `Local`, `Review Required`, and `Not Applied`.
+
+Boundary:
+
+- The dashboard and filters are review/navigation surfaces only.
+- This slice does not add live execution, hidden agent runs, Discord behavior, hosted sync, package split, npm publish, auto-apply, auto-promotion, auto-merge/delete, auto-push, or source wiki entry mutation.
+
+Verification anchors:
+
+- `test/eos/home-data.test.js`
+- `test/eos/chat-routes.test.js`
+- `test/eos/side-review-routes.test.js`
+- `test/eos/workspace-boundary-side-review-view-model.test.js`
+- `test/eos/uiux-product-shape.test.js`
+
+## Visual QA and Release Readiness Pass - 2026-05-29
+
+The Eos Visual QA and Release Readiness longrun reviewed Chat, Mission Control, and Side Review as a release candidate surface set.
+
+What changed:
+
+- Chat safety copy now uses `Not Applied` instead of `Not Executing` so the first screen matches the Side Review promise.
+- The copy-only polish is locked by route/static UI tests.
+- Text-based DOM/CSS/API evidence is recorded in `.omx/ultragoal/eos-visual-qa-surface-evidence.json`.
+- Release-readiness notes are captured in `docs/design/EOS_VISUAL_QA_RELEASE_READINESS_2026-05-29.md`.
+
+Boundary:
+
+- This pass did not merge PR #8 into `main`, publish npm, bump versions, split packages, add Discord runtime, add hosted sync, add hidden execution, or mutate source wiki entries.
+- PR #8 remains a human-review release candidate after the stacked visual-QA PR is reviewed.
+
+Verification anchors:
+
+- `test/eos/chat-routes.test.js`
+- `test/eos/uiux-product-shape.test.js`
+
+## Visual Screenshot Harness MVP
+
+Eos now has a local screenshot evidence harness for visual QA. The harness starts a temporary local Eos server, seeds safe review-required fixture data, captures PNG evidence for Chat + Mission Control and Side Review, writes ignored local artifacts under `.system/eos/visual-qa/screenshots/`, and then removes temporary wiki/profile data.
+
+Boundary:
+
+- This is a release-readiness aid only. It does not add cloud browser infrastructure, hosted sync, source wiki mutation, publish, push, hidden execution, or automatic UI approval.
+- The default command skips with a report when Chrome, Edge, or Chromium is not available; strict runs can opt into `--require-browser`.
+
+Verification anchors:
+
+- `npm run eos:visual-screenshots`
+- `test/eos/visual-screenshot-harness.test.js`
+- `test/eos/home-data.test.js`
+- `test/eos/side-review-routes.test.js`
+- `test/eos/workspace-boundary-side-review-view-model.test.js`

package/docs/design/EOS_PACKAGE_SPLIT_MIGRATION_BACKLOG.md

@@ -0,0 +1,89 @@
+# Eos Package Split Migration Backlog
+
+Generated: 2026-05-27T22:54:41.581Z
+
+## P0
+
+### P0-001 ? Keep boundary policy verifier green
+
+- Why: Prevents new private cross-boundary imports while split readiness work continues.
+- Evidence: `scripts/eos-boundary-policy.json`, `scripts/verify-eos-boundary-policy.js`
+- Acceptance criteria:
+  - npm run verify:eos-boundary-policy passes with 0 findings
+  - New production cross-boundary imports require explicit policy review
+
+### P0-002 ? Public LLM Wiki adapter facade
+
+- Why: Eos imports wiki store/query/curator internals directly today.
+- Evidence: `g003 import graph`, `g006 adapter proposal`
+- Acceptance criteria:
+  - Eos imports adapter facade for status/drafts/review queue/candidates
+  - No auto-promotion or hidden execution paths
+  - Adapter tests cover failure/degraded states
+
+### P0-003 ? Eos daemon/CLI facade without renaming llmwiki
+
+- Why: Standalone Eos package needs explicit entrypoints while current OpenCode compatibility remains stable.
+- Evidence: `g012 compatibility review`, `g015 install smoke plan`
+- Acceptance criteria:
+  - Future Eos facade can start daemon/help locally
+  - llmwiki compatibility wrapper continues to work
+  - No npm publish until local install smoke passes
+
+## P1
+
+### P1-001 ? Move Eos Home browser-data composition behind BrowserDataPort
+
+- Why: Core wiki browser-data currently imports Eos home data.
+- Evidence: `g013 browser-data contract review`
+- Acceptance criteria:
+  - buildBrowserData remains deterministic
+  - Eos home data is optional/redacted/degraded when unavailable
+  - browser-data tests pass
+
+### P1-002 ? Provider neutralization for OpenCode Go
+
+- Why: LLM Wiki agent provider imports Eos provider internals.
+- Evidence: `g010 SHARED-005`
+- Acceptance criteria:
+  - Shared provider is neutral or public
+  - Eos route and agent provider tests pass
+  - No provider behavior regression
+
+### P1-003 ? Pack import/share public surface
+
+- Why: Eos academy imports wiki pack internals.
+- Evidence: `g010 SHARED-007`
+- Acceptance criteria:
+  - Small public re-export or adapter exists
+  - pack tests and academy tests pass
+
+## P2
+
+### P2-001 ? Graph/librarian service ports
+
+- Why: Broad service movement is risky and should follow adapter stabilization.
+- Evidence: `g010 SHARED-006`
+- Acceptance criteria:
+  - Ports documented before implementation
+  - No behavior move without tests
+  - Agent scanner and Eos routes remain green
+
+### P2-002 ? Standalone Eos npm package skeleton
+
+- Why: Eos is still embedded and should not be separately published yet.
+- Evidence: `g005 package audit`, `g014 pack dry-run`, `g015 smoke plan`
+- Acceptance criteria:
+  - package name/bin/exports decided
+  - files/dependencies minimized
+  - local install smoke passes
+  - independent review approves
+
+### P2-003 ? Distribution decision for Codex bridge and VS Code package
+
+- Why: Current npm package excludes codex-plugins and packages folders.
+- Evidence: `g014 pack dry-run summary`
+- Acceptance criteria:
+  - Distribution ownership documented
+  - No accidental files inclusion
+  - Install docs match actual package contents

package/docs/design/EOS_SCREEN_INVENTORY.md

@@ -43,6 +43,7 @@ Type a message and send it.
 
 - The assistant persona name `Hermes` is not yet fully resolved for user-facing copy.
 - Chat response is still a local draft acknowledgement, not a full orchestration conversation.
+- Captured chat requests appear in Side Review as review-required cards.
 
 ### Acceptance criteria