tykimos/agent-native-agent/app-shell

app-shell — where things live

One workspace, six tabs, in this order:

UX spec

Mobile (≤768px)                                        Desktop
┌───────────────────────────────────┐                  [logo ANA]  PRD  Work  Knowledge  Requests•3  Evolve•1  Update•2   (Chip)(✎)(⟳)(A)
│[logo]                  (Chip)(A)  │                  ─────────────────────────────────────────
│ Tasks  Calendar  Notes            │  ← sub-tabs      Tasks  Calendar  Notes
│ …                                  │
│                        (chat FAB)  │  FAB sits above the bottom nav
├───────────────────────────────────┤
│ PRD Work Knowl. Requests Evolve Upd│
└───────────────────────────────────┘

• The profile avatar is always the rightmost item in the header; on phones the top tab strip is hidden (the bottom menu does its job) and the Chip switch group sits at the right (#modeToggle { margin-left: auto }).
• The last tab is remembered (localStorage ana-tab), and each tab's sub-tab too (ana-subtabs).
• Work sub-tabs switch screens: each Work screen (todoView, scheduleView, memoView) carries the same <nav class="subtabs" data-sub="work">; picking one shows that screen. A domain ANA replaces them with its own kinds of work.
• Status sub-tabs (Requests, Evolve, Update): Waiting · In progress · Done (STATUS_TABS). Done also holds failed and cancelled items; each card still shows its own state and actions. Waiting and In progress show a count.
• Sub-tabs and .toolbar never wrap on phones (they scroll sideways). Views get bottom padding so the nav never covers content. The chat FAB moves up (bottom: 74px + safe-area).
• Badges on Requests, Evolve and Update count what is waiting (setBadge('data-reqbadge' | 'data-evobadge' | 'data-updbadge', n)).
• New version pill: when /api/health.build changes, "New version available — tap to reload" appears under the header. Its onclick must reload.

Anchors / code (upstream dashboard.html)

Top tabs and bottom-menu buttons carry data-view = prd | work | knowledge | requests | evolve | update. TABS, WORK_VIEWS, VIEWS list them. Functions: selectTab(b) (the one place that switches tabs; for Work it shows curSub('work')), showTab(v) (any screen, including a Work screen → picks that sub-tab), syncBottomNav(tab), setBadge. Sub-tabs: SUBTABS, renderSubtabs (renders every .subtabs[data-sub=v], toggles [data-subsec]), openSub, curSub, setSubCount, RENDER_SUB (re-renders a status list when its sub-tab changes), REFRESH_TAB (loads a tab's data when it opens).

Porting

1. Decide the target's Work sub-tabs with the user (its own kinds of work). Put the Work <nav class="subtabs" data-sub="work"> at the top of each Work screen and list them in SUBTABS.work and WORK_VIEWS.
2. Copy the top tab strip, the <nav class="bottomnav"> block, their CSS, and the JS block from /* ================= 탭 전환 through the first setTimeout(() => selectTab(…), 0), plus the sub-tab block. Replace the target's tab click handlers with selectTab / showTab.
3. Never call button.click() inside a click handler to switch tabs (re-entrant clicks are dropped). Call selectTab or showTab.

Verify (390px and 1280px)

• Six tabs on desktop and in the bottom menu on phones, in the order PRD · Work · Knowledge · Requests · Evolve · Update; the app opens on Work. No horizontal scroll.
• Work: each sub-tab opens its screen; a relation chip that points to an event opens Work › Calendar.
• Requests / Evolve / Update: Waiting · In progress · Done each show their items; badges count Waiting.
• Reload returns to the same tab and sub-tab. An instruction card's Open goes to its tab and sub-tab.