
Planner, reviewer, coder를 늘리지.
OkayJing이 역할극형 planner/reviewer/coder 분리보다 Hermes Hub와 project/profile spoke 격리를 택한 이유를 정리합니다.
OkayJing Local을 ops dashboard로만 보면 성공 기준은 낮다. 상태가 보이고, 버튼이 눌리고, ticket count가 맞으면 된다. 그런데 목표가 Discord replacement라면 전혀 다르다. 대체해야 하는 것은 표가 아니라 매일 쓰는 대화와 작업 흐름이다.
desktop에서는 Office, Sessions, Code가 2–3 pane workspace로 이어져야 한다. session과 artifact, code diff를 나란히 보고, worker detail과 verification, ticket report로 바로 넘어갈 수 있어야 한다.
tablet에서는 split view나 collapsible review/planning view가 필요하다. 긴 코드와 대화가 서로 밀어내면 안 되고, approval이나 draft 조작이 터치로 가능해야 한다.
mobile에서는 기준이 더 명확하다. bottom nav, one active surface, drilldown이 필요하다. floor → worker → detail, session → chat → artifact, code list → detail이 한 번에 하나씩 열려야 한다. desktop panel을 세로로 쌓아놓은 형태면 실패다.
Discord를 당장 버린다는 뜻은 아니다. fallback channel로 남을 수 있다. 다만 primary surface가 되려면 대화, 파일, 코드, 승인, 브리핑, 알림, restart recovery가 Local에서 이어져야 한다.
이 기준을 통과해야 OkayJing Local은 dashboard가 아니라 서식지가 된다. 매일 들어가서 일하고, 확인하고, 다시 말을 거는 공간이 된다.
Discord를 쓰지 않는 자체 표면을 만들고 싶다면 먼저 기능 목록을 비교하면 안 된다. 채널, 스레드, 알림을 흉내 내는 것보다 중요한 것은 매일 돌아오는 이유다. 사용자가 대화를 시작하고, 작업 상태를 보고, 결과물을 열고, 다시 이어 말할 수 있어야 한다.
그래서 평가 기준은 화면 크기별로 달라진다. desktop에서는 여러 작업과 evidence를 넓게 봐야 한다. tablet에서는 읽기와 승인 흐름이 편해야 한다. mobile에서는 한 번에 하나의 active surface만 보여주고, bottom navigation과 drilldown으로 이동해야 한다. 세 기기에서 모두 말 걸기와 작업 확인이 자연스러워야 dashboard를 넘어선다.
Post Q&A
OkayJing Local이 Discord를 대체하려면 — dashboard가 아니라 daily surface여야 한다 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!

OkayJing이 역할극형 planner/reviewer/coder 분리보다 Hermes Hub와 project/profile spoke 격리를 택한 이유를 정리합니다.

큰 모델 호출 전에 로컬 모델이 무엇을 해도 되고 무엇을 하면 안 되는지, OkayJing의 local evidence router 기준을 정리합니다.

OkayJing Local을 단순 ops dashboard가 아니라 desktop, tablet, mobile에서 실제 대화와 작업을 대체하는 표면으로 평가하는 기준을 정리합니다.
OkayJing 서식지가 ticket list 중심 UI를 넘어 worker, session, artifact, verification이 연결된 Pixel Office로 가야 하는 이유를 정리합니다.

DB, Markdown, ticket 같은 원천 리소스 동시성은 API가 맡고, chat/voice/approval은 Hermes gateway 의미를 따라야 한다는 경계를 정리합니다.
OkayJing이 플러그인, MCP, gateway, memory 같은 확장점을 기능 추가 지점이 아니라 책임과 권한의 경계면으로 보는 이유를 정리합니다.
OkayJing Local의 worker와 profile-spoke UI를 역할극이 아니라 capability, handoff contract, artifact lifecycle로 설계해야 하는 이유를 정리합니다.
Dreaming이 새 에이전트 프레임워크와 도구를 발견했을 때, 오케이징이 설치보다 표준 정렬·watch·검증 기준을 먼저 남기기로 한 이유를 정리합니다.
Jing Factory를 아이디어에서 프로토타입까지 밀어붙이는 흐름으로 다시 보면서, 화면보다 요구사항·DTO·API 계약·MSW mock API를 먼저 남기도록 Jing Studio skill을 바꾼 이유를 정리합니다.
OpenClaw-era Jing Factory와 jing-bridge 실험에서 남길 개념을 고르고, Hermes 단일 체계 안에서 다시 설계한다면 어떤 흐름이 자연스러운지 정리합니다.