feat: 添加MinIO文件系统支持并优化外部连接器功能
- 添加MinIO用户文件系统配置选项(BEAVER_MINIO_ROOT_USER等) - 更新外部连接器配置结构，包括BASE_URL和认证令牌设置 - 改进connector provider支持更多类型(official, feishu_bot等) - 实现Mistral模型推理模式支持reasoning_effort参数 - 增强外部连接器策略配置和运行时配置管理 - 添加connector bridge事件验证和安全保护机制 - 优化任务路由逻辑，区分simple_chat和new_task场景 - 更新初始技能工具提示配置，分离authoring admin功能
This commit is contained in:
@ -0,0 +1,60 @@
|
||||
# Auto-Accept Task When a New Topic Starts
|
||||
|
||||
## Goal
|
||||
|
||||
Prevent unrelated follow-up conversation from being appended to the previous
|
||||
Task. When the Intent Agent decides that the user's current message starts a
|
||||
new topic, Beaver should silently accept the previous Task before processing
|
||||
the current message.
|
||||
|
||||
## User Experience
|
||||
|
||||
- No confirmation dialog or extra assistant message is shown.
|
||||
- A related follow-up or requested change continues the existing Task.
|
||||
- An unrelated lightweight message is handled as `simple_chat`.
|
||||
- Unrelated work that needs Task capabilities is handled as `new_task`.
|
||||
- Before either new-topic path continues, the previous Task is formally
|
||||
accepted.
|
||||
|
||||
## Routing Rules
|
||||
|
||||
The existing Intent Agent actions remain unchanged:
|
||||
|
||||
- `continue_task` and `revise_task` belong to the active Task.
|
||||
- `close_task` and `abandon_task` keep their existing explicit semantics.
|
||||
- With an active Task, `simple_chat` means an unrelated lightweight new topic.
|
||||
- With an active Task, `new_task` means unrelated work that needs a separate
|
||||
Task.
|
||||
|
||||
The Intent Agent guidance must explicitly distinguish unrelated lightweight
|
||||
conversation from revisions. A message must not be classified as
|
||||
`revise_task` merely because an active Task is awaiting acceptance.
|
||||
|
||||
## State Transition
|
||||
|
||||
Before processing a `simple_chat` or `new_task` decision:
|
||||
|
||||
1. Check whether the active Task is `awaiting_acceptance`.
|
||||
2. Find its latest completed run.
|
||||
3. Record a normal `accept` acceptance against that run.
|
||||
4. Continue processing the current message using the original routing
|
||||
decision.
|
||||
|
||||
The normal acceptance path must be reused so that the Task becomes `closed`,
|
||||
`final_accepted_run_id` is recorded, acceptance events are persisted, run
|
||||
memory is updated, and skill-learning candidates can be generated.
|
||||
|
||||
Tasks without an acceptance-eligible completed run are left unchanged. Router
|
||||
failures retain the existing conservative `continue_task` fallback and must
|
||||
not auto-accept a Task.
|
||||
|
||||
## Testing
|
||||
|
||||
Backend tests must cover:
|
||||
|
||||
- An unrelated `simple_chat` message accepts the previous Task and is not
|
||||
appended as another Task run.
|
||||
- A `new_task` decision accepts the previous Task and creates a separate Task.
|
||||
- `continue_task` and `revise_task` do not auto-accept the active Task.
|
||||
- Router failure fallback does not auto-accept the active Task.
|
||||
- Auto-accept records the final accepted run and normal acceptance history.
|
||||
@ -0,0 +1,59 @@
|
||||
# Chat Current-Task Timeline Consistency
|
||||
|
||||
## Goal
|
||||
|
||||
Make the chat page's current-session progress panel show the same timeline
|
||||
content as the active Task's detail page.
|
||||
|
||||
## Visibility
|
||||
|
||||
- Show the chat-side timeline only while the current session has an active
|
||||
Task.
|
||||
- Hide the panel immediately when the Task is accepted, auto-accepted,
|
||||
abandoned, closed, or when the user switches sessions.
|
||||
- Do not show the most recently completed Task after it is no longer active.
|
||||
|
||||
## Shared Data Model
|
||||
|
||||
The Task detail page remains the canonical timeline behavior.
|
||||
|
||||
Both surfaces must:
|
||||
|
||||
1. Load the full `BackendTask` payload from `/api/tasks/{task_id}`.
|
||||
2. Combine the task's persisted process data with matching live process data.
|
||||
3. Use one shared task-process filtering helper.
|
||||
4. Build cards with `buildTaskTimelineCards()`.
|
||||
5. Render cards with `TaskTimeline`.
|
||||
|
||||
This keeps card types, ordering, fallback milestones, result history,
|
||||
acceptance history, tool status, and deduplication consistent.
|
||||
|
||||
## Chat Panel
|
||||
|
||||
`CurrentSessionProgressSidebar` becomes a responsive wrapper around
|
||||
`TaskTimeline`.
|
||||
|
||||
- Desktop keeps the existing right sidebar.
|
||||
- Smaller viewports keep the existing floating open button and drawer.
|
||||
- The panel title remains "当前会话的运行进度".
|
||||
- Timeline cards match the Task detail timeline.
|
||||
- Chat does not render duplicate acceptance controls inside the sidebar,
|
||||
because acceptance controls already exist on chat result messages.
|
||||
|
||||
## Data Refresh
|
||||
|
||||
- Whenever the active Task changes, the chat page loads its full Task detail.
|
||||
- Existing message, process, feedback, and WebSocket refresh paths reload both
|
||||
the active Task identity and its full detail.
|
||||
- If the active-task endpoint returns `null`, the cached active Task detail is
|
||||
cleared immediately and the sidebar disappears.
|
||||
- A task-detail load failure hides the sidebar rather than showing stale data.
|
||||
|
||||
## Testing
|
||||
|
||||
- Shared process filtering returns the same task-scoped runs, events, and
|
||||
artifacts for both surfaces.
|
||||
- The chat-side timeline cards are produced by `buildTaskTimelineCards()`.
|
||||
- No active Task produces no chat-side timeline.
|
||||
- Switching to a closed/no-active Task clears the chat-side timeline.
|
||||
- Frontend unit tests, typecheck, and production build pass.
|
||||
Reference in New Issue
Block a user