doc_id: DES-202606-001 feature_id: FEAT-202606-001-unified-entry-client type: design title: Unified Entry Terminal Web Demo Design status: approved owner: 医梦研发团队 created_at: 2026-06-02 updated_at: 2026-06-02 reviewers: [] related_docs:
Build a single-application Web demo for the unified entry terminal client. The demo should feel like an intelligent hospital service entrance rather than a traditional menu system, and it must support one complete outpatient registration flow for next-week customer demonstration.
The first version prioritizes desktop Web demonstration at 1440x900 and 1920x1080. It does not target vertical self-service kiosk screens yet.
The Web demo represents a hospital-facing AI service entrance similar in spirit to a friendly healthcare assistant. The patient should express intent through natural language. The system then recognizes intent, routes to the right backend task, and presents deterministic business cards only when the flow requires selection or confirmation.
The UI must not look like a traditional feature menu. It should not make registration, triage, doctor lookup, and route guidance appear as a growing left navigation tree of agents. The visible UI can explain what the assistant can handle, but the primary entry point is conversation.
message_delta, message_completed, task_updated, card_created, error, and completed.idempotencyKey.mock:true.1440x900 and 1920x1080.Company theme colors:
| Token | Value | Usage |
|---|---|---|
brandPrimary |
#2b1f99 |
Main action, selected task, user message, active progress |
brandAccent |
#3ad4d8 |
Accent border, secondary action, progress highlight, assistant glow |
pageBg |
#f7fbff |
App background |
surface |
#ffffff |
Panels and cards |
softTint |
#f4fdff |
Selected card background and assistant hint background |
border |
#dfe7f7 |
Panel borders |
textPrimary |
#16133a |
Main text |
textSecondary |
#69708a |
Secondary text |
warningBg |
#fff8e8 |
Mock/payment warning surface |
warningText |
#735b14 |
Mock/payment warning text |
The palette should feel clean and medical-tech oriented. It should not drift into a generic blue dashboard or use heavy gradients across the whole page. Gradients are allowed only on the assistant identity mark and doctor image environment.
Use a three-column desktop layout:
Header
├── Left Assistant Context Panel
├── Center Conversation Panel
└── Right Context Panel
The header contains:
医梦门诊助手Web Demo · 门诊大厅 · 联调演示The left panel is not a functional menu. It contains:
说出需求,我来判断下一步我头疼三天,想挂号明天上午有神经内科的号吗我想找李明医生挂号导诊医生查询It must not render large clickable buttons for each agent or workflow.
The center panel is the only input area in the first version.
It contains:
The voice button is visible for future STT affordance but does not implement real STT in this version. It can show a disabled/demo behavior or a short toast depending on implementation readiness.
The right panel is a stateful context panel.
State idle:
医生助手当前仅作为静态形象展示。语音与发送操作仍在中间输入区完成。可听 / 可说 interaction chipsState task:
actionsState error:
traceId when availableState completed:
mock:true label when present完成 to return right panel to idleDo not draw the doctor assistant with CSS primitives.
Use a real static image asset. A generated candidate already exists at:
/Users/destiny/.codex/generated_images/019e8719-cee0-7723-83a4-ac1a9e0a3bd4/ig_037570e350a4f508016a1e882c0c188191b10d3dbe9b5f776a.png
Implementation should copy this image into the frontend project as:
src/assets/doctor-assistant.png
The original generated image must remain in place unless explicitly deleted by the user.
Asset requirements:
#2b1f99 and #3ad4d8 as accents1440x900load app config
→ register device or use demo device
→ heartbeat every 30 seconds
→ load scene profile
→ render idle layout
For Web demo, a demo signer or dev-only bearer/HMAC helper may be used, but signing secrets must not be placed in browser-exposed VITE_* variables for real deployment.
User can type:
我头疼三天,还有点恶心,想挂号
Frontend calls:
POST /api/v1/agent/chat/stream
Frontend must not pass agentId.
SSE handling:
task_updated -> set active task and right panel task state
message_delta -> append assistant text
message_completed -> finalize assistant message
card_created -> fetch card instance and render right panel card
completed -> store conversationId and traceId
error -> show error state
Card flow:
department-selection
→ doctor-selection
→ time-slot-selection
→ confirm-appointment
→ payment-qrcode
→ appointment-success
Every card action posts:
POST /api/v1/cards/{cardInstanceId}/actions/{actionName}
The request must include:
{
"idempotencyKey": "stable-key-for-this-logical-action",
"confirm": true,
"payload": {}
}
The payment card must clearly label:
联调演示 / Mock 支付
The mock payment action can be rendered as a visible demo button only in Web demo mode. It must not use WeChat, Alipay,医保, or any real payment brand.
Core components:
| Component | Responsibility |
|---|---|
AppShell |
Header and three-column layout |
AssistantContextPanel |
Left assistant identity, examples, capability chips |
ConversationPanel |
Message stream, input, voice button, send button |
ContextPanel |
Right panel state switch: idle/task/error/completed |
DoctorAssistantFigure |
Static doctor image display |
RegistrationProgress |
Step progress for registration |
CardRenderer |
Switches cardKey to card component |
DepartmentSelectionCard |
Renders departments and select action |
DoctorSelectionCard |
Renders doctors and select action |
TimeSlotSelectionCard |
Renders slots and select action |
ConfirmAppointmentCard |
Summary and second confirmation |
PaymentQrCard |
Mock payment QR/content and mock paid action |
AppointmentSuccessCard |
Appointment result and mock label |
ErrorCard |
Error message, traceId, retry/restart action |
Use a small frontend store with these slices:
device:
deviceId
deviceType
sceneProfile
heartbeatStatus
conversation:
conversationId
messages[]
streaming
currentTraceId
task:
taskId
taskType
currentStep
status
contextPanel:
mode: idle | task | error | completed
activeCardInstanceId
activeCard
ui:
inputText
pendingActionKey
demoMode
The right panel mode is derived primarily from task/card state:
no active task and no active card -> idle
active card -> task
error event -> error
appointment-success card -> completed
Required behavior:
traceId.Use Playwright for visual and interaction QA.
Viewports:
1440x900
1920x1080
Minimum checks:
联调演示 or Mock.None for the first implementation plan.
The first implementation plan should build the Web demo as a single application. Later work can split it into packages/api-client, packages/medical-cards, and multi-terminal apps when the first Web demo is accepted.
Approved direction:
#3ad4d8 and #2b1f99.