Mission

1. 포지셔닝

opt-shell는 또 하나의 UI 컴포넌트 패키지가 아닙니다. opt-ui가 재료와 표현 규칙을 제공한다면, opt-shell는 제품 화면을 어떤 구조와 리듬으로 만들지 고정하는 런타임 프레임입니다. 핵심 목표는 사람이든 에이전트든 화면을 만들 때 결과 품질이 개인 감각에 흔들리지 않게 하는 것입니다. 화면이 따르는 규약을 계약으로 검증하는 도구(opt harness check/doctor, completeness scoring, lint 룰)는 opt-cli가 소유하고, opt-shell는 그 계약을 런타임에서 구현·렌더합니다.

이제 범위는 runtime API를 넘습니다. Builder의 harness manager처럼 사용자가 draft harness를 만들고 preview, design proof, review, approval, activation까지 시각적으로 다루는 운영 surface도 opt-shell의 일부입니다. 즉, 좋은 화면을 만드는 규약과 그 규약을 안전하게 적용하는 workflow, 그리고 그 이력을 timeline/learnings로 다시 읽는 운영 read model을 함께 소유합니다.

2. DESIGN.md와의 경계

3. 해결하려는 문제

• theme와 primitive는 통일되어도 제품 화면의 정보 구조와 상태 UX는 쉽게 흔들립니다.
• DataGrid와 Editor처럼 강한 엔진이 들어오면 주변 toolbar, inspector, footer chrome이 화면마다 제각각 생깁니다.
• 에이전트가 화면을 생성할 때도 "그럴듯한 UI"는 나오지만 제품급 일관성은 recipe와 audit 없이는 유지되지 않습니다.
• 사용자는 후보 harness가 실제로 어떻게 적용되는지 preview와 review evidence, fresh proof, searchable activity intelligence로 이해해야 하고, 승인되지 않았거나 stale proof인 draft가 바로 runtime으로 올라가면 안 됩니다.

4. 핵심 명제

5. 무엇을 소유하는가

6. 비목표

• 새로운 button, input, card primitive를 다시 만드는 것
• opt-ui 전체를 re-export해서 또 다른 UI 라이브러리가 되는 것
• opt-datagrid, opt-editor 엔진 책임을 흡수하는 것
• 모든 화면을 자유 조합 가능하게 두어 품질 기준을 흐리는 것
• review와 approval을 우회한 채 draft harness를 바로 운영 정책으로 쓰는 것