No user deny messages in history (vibe-kanban) (#928)
* Perfect! The implementation is clean and follows the existing patterns. Let me create a summary:
I've successfully implemented the backend solution for displaying user denial messages in the conversation history.
**File: `crates/services/src/services/approvals.rs`**
1. **Added import** (line 8):
- Imported `EntryIndexProvider` from `executors::logs::utils`
2. **Modified `respond()` method** (lines 153-166):
- After updating the tool status to `Denied`
- Check if the `ApprovalStatus::Denied` variant has a `Some(reason)`
- If yes:
- Create an `EntryIndexProvider` initialized from the message store to get the next available index
- Create a `NormalizedEntry` with `UserMessage` type containing the denial reason
- Add it to the conversation using `ConversationPatch::add_normalized_entry()`
1. **Backend owns the state**: The conversation history lives in `MsgStore` on the backend - this is the proper source of truth
2. **Follows existing patterns**: Uses the same pattern as Claude executor (claude.rs:508-527) for adding user messages
3. **Proper indexing**: `EntryIndexProvider::start_from(&store)` ensures correct sequence numbering
4. **No frontend hackery**: Frontend just renders what backend provides
5. **Type safe**: Uses existing `NormalizedEntryType::UserMessage` - no new types needed
6. **Clean separation**: Backend manages state, frontend displays it
When a user denies an approval with feedback like "Please try a different approach":
1. Backend receives the denial in `approvals.rs:respond()`
2. Updates the tool entry status to `Denied { reason }`
3. Immediately adds a new `UserMessage` entry with the denial text to the conversation stream
4. Frontend receives this as a normal user message patch and displays it
5. The agent sees it as a user message in the conversation history
- ✅ TypeScript compilation passes
- ✅ Rust compilation passes
- ✅ No breaking changes
- ✅ Follows existing architectural patterns
Cleanup script changes for task attempt 8122f303-889b-4333-8024-e79b9ea7dc7e
Great question! Let me explain how a new `UserFeedback` variant would work - it might actually be cleaner. Let me check what that would look like:
A new variant would mean:
1. Add `UserFeedback` to `NormalizedEntryType` enum in `crates/executors/src/logs/mod.rs`
2. Backend uses `NormalizedEntryType::UserFeedback` instead of `UserMessage`
3. Frontend displays it like a user message (same UI component)
4. No filtering issues - it's a distinct type that won't be filtered
5. TypeScript types auto-generated, so frontend gets the type
Let me show you what this would look like:
**Pros:**
- Type-safe, explicit intent
- No filtering workarounds needed
- Clear semantic meaning
- Auto-generates TypeScript types
**Cons:**
- Larger change (need to update Rust enum, regenerate types, update frontend display logic)
- Need to run `npm run generate-types`
Let me present both options clearly so you can choose:
Perfect! Both frontend and backend compile successfully. Let me create a summary of what was implemented:
I've successfully implemented **Option 2: New `UserFeedback` Variant** to display denial messages in the conversation history.
**1. Backend: Added `UserFeedback` entry type** (`crates/executors/src/logs/mod.rs`)
- Added `UserFeedback` variant to `NormalizedEntryType` enum
- Marked with `#[ts(export)]` for TypeScript generation
**2. Backend: Use `UserFeedback` for denial messages** (`crates/services/src/services/approvals.rs`)
- When a denial has a reason, create a `NormalizedEntry` with type `UserFeedback`
- Add it to the conversation stream after the denied tool
- Removed unused metadata structs (cleaner than Option 1)
**3. TypeScript Types: Regenerated** (`shared/types.ts`)
- Ran `npm run generate-types`
- New type `{ "type": "user_feedback" }` added to `NormalizedEntryType`
**4. Frontend: Display `UserFeedback` as user message** (`DisplayConversationEntry.tsx`)
- Check for both `user_message` and `user_feedback` types
- Render both with the same `<UserMessage>` component
- Use same User icon for both types
1. **No filtering issues**: `UserFeedback` is a distinct type, won't be filtered by the user message filter
2. **Type-safe**: Explicit enum variant with auto-generated TypeScript types
3. **Semantic clarity**: Clear distinction between initial prompts and feedback
4. **Natural display**: Appears as a user message in the conversation flow
5. **Extensible**: Can be used for other user feedback scenarios in the future
When a user denies an approval with feedback like "Please try a different approach":
1. Backend creates a `UserFeedback` entry with that text
2. Frontend receives it and displays it as a user message
3. It appears in the conversation history naturally, right after the denied tool
4. The agent sees it in the context as user input
- ✅ Backend (Rust) compiles
- ✅ Frontend (TypeScript) compiles
- ✅ Types regenerated successfully
- ✅ Clean, type-safe implementation
Perfect! So the tool result IS processed. But looking at the log entry you provided, the denial message appears in a `tool_result` with `is_error: true`. Let me check what tool this corresponds to:
Perfect! Both backend and frontend compile successfully. Let me create a summary of the complete solution:
I implemented a **normalization-based approach** that works with both live sessions and old logs by extracting denial reasons from the tool_result that's already in the raw logs.
**1. Added `UserFeedback` Entry Type** (`crates/executors/src/logs/mod.rs:56`)
- New variant in `NormalizedEntryType` enum
- Represents user feedback during execution (like denial reasons)
- Auto-exported to TypeScript types
**2. Added Denial Reason Extraction** (`crates/executors/src/executors/claude.rs:316-339`)
- New function `extract_denial_reason()` that parses hook denial messages
- Pattern: `"operation blocked by hook:\n- {user's reason}"`
- Extracts the text after `"- "`
**3. Create UserFeedback During Normalization** (`crates/executors/src/executors/claude.rs:598-612` and `717-731`)
- When processing tool_result with `is_error: true`
- Call `extract_denial_reason()` to check for denial pattern
- If found, create a `UserFeedback` entry with the extracted reason
- Add it right after the denied tool
- Applies to both command tools and other tools (MCP, etc.)
**4. Display UserFeedback in Frontend** (`frontend/src/components/NormalizedConversation/DisplayConversationEntry.tsx`)
- Handle `user_feedback` type same as `user_message`
- Display with `<UserMessage>` component
- Use User icon
**5. Cleaned Up Approvals Service** (`crates/services/src/services/approvals.rs`)
- Removed the live-session-only code that added UserFeedback
- Removed unused `EntryIndexProvider` import
- Let normalization handle everything
1. **Denial reason IS in raw logs**: The hook sends denial as tool_result with `is_error: true` containing the user's feedback
2. **Survives restarts**: Raw logs are persisted to DB, including the tool_result
3. **Works for old logs**: When logs are re-normalized after restart, the extraction logic runs and creates the UserFeedback entry
4. **Type-safe**: New enum variant with proper TypeScript types
5. **No filtering issues**: `UserFeedback` is a distinct type, won't be filtered out
- ✅ Live sessions: Denial feedback appears as user message
- ✅ After restart: Old logs show denial feedback when re-normalized
- ✅ Type-safe: Proper enum variant, auto-generated TypeScript types
- ✅ Both compilations pass
When a user denies a tool with feedback like "Please try a different approach", it now appears as a separate user message in the conversation history, immediately after the denied tool.
Cleanup script changes for task attempt 8122f303-889b-4333-8024-e79b9ea7dc7e
Perfect! Both backend and frontend compile successfully. Let me create a final summary of all the changes:
1. ✅ **Duplicate code block removed** - Consolidated denial detection into one place after both command/non-command branches
2. ✅ **Pattern matching improved** - Changed from `"operation blocked by hook:"` to `"blocked by hook:"` to match both "Edit operation blocked by hook" and "operation blocked by hook"
3. ✅ **Magic strings replaced with constants** - Added `HOOK_DENIAL_PATTERN` and `HOOK_DENIAL_REASON_PREFIX` constants
**1. Added `UserFeedback` Entry Type** (`crates/executors/src/logs/mod.rs:56`)
- New variant in `NormalizedEntryType` enum for user feedback during execution
**2. Added Constants for Hook Patterns** (`crates/executors/src/executors/claude.rs:42-45`)
```rust
const HOOK_DENIAL_PATTERN: &str = "blocked by hook:";
const HOOK_DENIAL_REASON_PREFIX: &str = "- ";
```
**3. Added Denial Extraction Function** (`crates/executors/src/executors/claude.rs:321-345`)
- Detects hook denial messages in tool_result content
- Extracts user's reason from lines starting with `"- "`
- Uses constants for maintainability
**4. Create UserFeedback During Normalization** (`crates/executors/src/executors/claude.rs:703-717`)
- After processing any tool_result with `is_error: true`
- Extract denial reason and create `UserFeedback` entry
- Add it immediately after the denied tool
- **Single consolidated check** for both command and non-command tools
**5. Display UserFeedback in Frontend** (`frontend/src/components/NormalizedConversation/DisplayConversationEntry.tsx`)
- Handle `user_feedback` type same as `user_message`
- Display with `<UserMessage>` component
- Use User icon
**6. Regenerated TypeScript Types** (`shared/types.ts:287`)
- Added `{ "type": "user_feedback" }` to `NormalizedEntryType`
**7. Cleaned Up Approvals Service** (`crates/services/src/services/approvals.rs`)
- Removed unused live-session code
- Let normalization handle everything
1. **Works with old logs**: Denial reason is in persisted tool_result, extracted during re-normalization
2. **Works with live sessions**: Denial extracted during initial normalization
3. **No magic strings**: Uses constants for pattern matching
4. **No duplication**: Single denial check after tool processing
5. **Flexible pattern**: Matches "Edit operation blocked by hook" and "operation blocked by hook"
6. **Type-safe**: Proper enum variant with TypeScript types
- ✅ Backend compiles
- ✅ Frontend compiles
- ✅ No duplicate code
- ✅ Pattern improved to match your example
Cleanup script changes for task attempt 8122f303-889b-4333-8024-e79b9ea7dc7e
Perfect! Everything compiles. Let me create a summary of the final solution:
**1. Python Hook - Natural Language Marker** (`crates/executors/src/executors/hooks/confirm.py:14`)
- Prefix denial reason with `"User feedback: {reason}"`
- Natural language format that's both readable to LLM and parseable
- Example output: `"User feedback: Could you add something about a goose?"`
**2. Rust Constant** (`crates/executors/src/executors/claude.rs:44`)
```rust
const USER_FEEDBACK_MARKER: &str = "User feedback: ";
```
**3. Robust Extraction Function** (`crates/executors/src/executors/claude.rs:320-340`)
- Search for `USER_FEEDBACK_MARKER` in tool_result content
- Extract everything after the marker
- No dependency on Claude Code's error message format
**4. Added `UserFeedback` Entry Type** (`crates/executors/src/logs/mod.rs:56`)
- New variant for user feedback during execution
**5. Create UserFeedback During Normalization** (`crates/executors/src/executors/claude.rs:703-717`)
- When tool_result has `is_error: true`, check for user feedback
- Create `UserFeedback` entry with extracted text
- Works for both live sessions and old logs (persisted in raw logs)
**6. Frontend Display** (`frontend/src/components/NormalizedConversation/DisplayConversationEntry.tsx`)
- Render `user_feedback` same as `user_message`
1. ✅ **We control the format**: The `"User feedback: "` prefix is added by OUR Python script
2. ✅ **Claude Code independent**: Works regardless of how Claude Code formats hook errors
3. ✅ **Natural language**: Reads naturally - LLM sees "User feedback: {reason}" which is clear
4. ✅ **Survives restarts**: Tool_result is in persisted raw logs, re-extracted on normalization
5. ✅ **Backward compatible**: Old logs without marker simply won't match (no errors)
6. ✅ **Simple**: One constant, one natural prefix
**User denies with**: `"Could you add something about a goose?"`
**Raw log contains**:
```json
{"type":"tool_result","content":"Edit operation blocked by hook:\nUser feedback: Could you add something about a goose?","is_error":true}
```
**Extraction**: Finds `"User feedback: "`, extracts `"Could you add something about a goose?"`
**Display**: Shows as user message in conversation history
**Result**: User's feedback is visible to both user and LLM, survives restarts!
Perfect! The solution is complete. Let me create a final summary:
**Single Source of Truth:** The marker `"User feedback: "` is defined ONLY in Rust and injected into Python at runtime.
**1. Rust Constant** (`crates/executors/src/executors/claude.rs:44`)
```rust
const USER_FEEDBACK_MARKER: &str = "User feedback: ";
```
**2. Python Script Placeholder** (`crates/executors/src/executors/hooks/confirm.py:15-16`)
```python
USER_FEEDBACK_MARKER = "{{USER_FEEDBACK_MARKER}}"
formatted_reason = f"{USER_FEEDBACK_MARKER}{reason}" if reason else None
```
**3. Template Replacement** (`crates/executors/src/executors/claude.rs:241-244`)
```rust
let script_content = CONFIRM_HOOK_SCRIPT.replace(
"{{USER_FEEDBACK_MARKER}}",
USER_FEEDBACK_MARKER,
);
file.write_all(script_content.as_bytes()).await?;
```
**4. Extraction Function** (`crates/executors/src/executors/claude.rs:320-340`)
- Searches for `USER_FEEDBACK_MARKER` in tool_result content
- Extracts feedback text after the marker
**5. UserFeedback Entry Creation** (`crates/executors/src/executors/claude.rs:703-717`)
- During normalization, detects denials and creates UserFeedback entries
**6. Frontend Display** (`frontend/src/components/NormalizedConversation/DisplayConversationEntry.tsx`)
- Renders UserFeedback as user messages
**7. TypeScript Types** (`shared/types.ts`)
- `user_feedback` variant generated
**At deployment time:**
1. Rust defines `USER_FEEDBACK_MARKER = "User feedback: "`
2. Python script has placeholder `{{USER_FEEDBACK_MARKER}}`
3. When writing hook, Rust replaces `{{USER_FEEDBACK_MARKER}}` → `"User feedback: "`
4. Python script executes with actual value
**When user denies:**
1. Python outputs: `"User feedback: Could you add something about a goose?"`
2. This goes into tool_result in raw logs (persisted)
3. During normalization, Rust finds `"User feedback: "` and extracts the text after it
4. Creates UserFeedback entry
5. Frontend displays it as a user message
✅ **Single source of truth**: Marker defined only in Rust constant
✅ **No duplication**: Python gets value via template replacement
✅ **Format independent**: Works regardless of Claude Code's error format
✅ **Natural language**: LLM sees readable "User feedback: {text}"
✅ **Survives restarts**: Tool_result persisted in DB, re-extracted on normalization
✅ **Maintainable**: Change constant in one place, both Rust and Python updated
- ✅ Backend compiles
- ✅ Frontend compiles
- ✅ Single source of truth maintained
Cleanup script changes for task attempt 8122f303-889b-4333-8024-e79b9ea7dc7e
Perfect! Everything compiles. Let me create a final summary:
**1. Backend: Added Tool Name to UserFeedback** (`crates/executors/src/logs/mod.rs:55-57`)
```rust
UserFeedback {
denied_tool: String,
}
```
**2. Backend: Capture Display Tool Name** (`crates/executors/src/executors/claude.rs:573-589`)
- Extract tool name before processing branches
- For MCP tools, format as `mcp:server:tool` instead of `mcp__server__tool`
- Store in `display_tool_name` variable
**3. Backend: Include Tool Name in UserFeedback** (`crates/executors/src/executors/claude.rs:734-735`)
```rust
entry_type: NormalizedEntryType::UserFeedback {
denied_tool: display_tool_name.clone(),
},
```
**4. Backend: Single Source of Truth for Marker** (`crates/executors/src/executors/claude.rs:44`)
```rust
const USER_FEEDBACK_MARKER: &str = "User feedback: ";
```
**5. Python: Placeholder Template** (`crates/executors/src/executors/hooks/confirm.py:15-16`)
```python
USER_FEEDBACK_MARKER = "{{USER_FEEDBACK_MARKER}}"
formatted_reason = f"{USER_FEEDBACK_MARKER}{reason}" if reason else None
```
**6. Backend: Template Replacement** (`crates/executors/src/executors/claude.rs:241-244`)
```rust
let script_content = CONFIRM_HOOK_SCRIPT.replace(
"{{USER_FEEDBACK_MARKER}}",
USER_FEEDBACK_MARKER,
);
```
**7. Frontend: Custom Red Accent Display** (`DisplayConversationEntry.tsx:648-666`)
- Red background (`bg-red-50 dark:bg-red-950/20`)
- Red border (`border-red-400/40`)
- Bold header showing: `"{ToolName} denied by user"`
- Red text for the feedback content
- **NO** edit/retry buttons (read-only display)
**8. TypeScript Types Regenerated** (`shared/types.ts`)
```typescript
{ "type": "user_feedback", denied_tool: string }
```
When user denies "Edit" tool with "Could you add something about a goose?":
```
┌─────────────────────────────────────────┐
│ Edit denied by user │ ← Bold red text
│ Could you add something about a goose? │ ← Red feedback text
└─────────────────────────────────────────┘ ← Red border/background
```
✅ **Single source of truth**: Marker defined only in Rust, injected into Python
✅ **Tool name included**: Shows which tool was denied
✅ **Distinct styling**: Red accent makes it clear this is a denial
✅ **No edit/retry**: Simple read-only display, no complex user message features
✅ **Works with old logs**: Tool_result persisted, re-extracted on normalization
✅ **Type-safe**: Tool name field in enum, auto-generated TypeScript types
- ✅ Backend compiles
- ✅ Frontend compiles
- ✅ Types regenerated
- ✅ No duplication
Cleanup script changes for task attempt 8122f303-889b-4333-8024-e79b9ea7dc7e
Perfect! The new styling should be much more subtle and blend better with the existing UI:
- **Background**: Same as user messages (no bright red)
- **Border**: Dashed like user messages, with subtle red tint (30% opacity)
- **Header**: Small text (`text-xs`), muted red, 80% opacity
- **Content**: Same font-light styling as regular user messages
This keeps the denial feedback visible but not overwhelming, similar to how the regular user message integrates into the conversation flow.
Perfect! The new styling is much more subtle:
- **Background**: Same `bg-background` as user messages (no bright red)
- **Border**: Standard dashed border (no red tint)
- **Header**: Uses semantic `--destructive` color with 70% opacity for subtlety
- **Content**: Standard user message styling (no red text)
This approach:
- ✅ Uses semantic CSS variables for proper dark mode support
- ✅ Much less visually intense - just a subtle red label
- ✅ Blends better with the conversation flow
- ✅ The small "denied by user" label provides context without overwhelming
The visual hierarchy is now: subtle header hint → main content, which matches the rest of the UI better.
* Tool denial feedback (vibe-kanban 35abbc86)
The last commit implement log entries for tool denials, it has some problems though:
Update json_error in crates/executors/src/executors/hooks/confirm.py so the marker is only prefixed when an actual user denial reason is passed—fallback errors (network failure, invalid JSON, timeouts) must keep their original text to avoid generating fake user_feedback entries.
Adjust the hook deployment in write_python_hook (crates/executors/src/executors/claude.rs) to refresh existing confirm.py files when the bundled script changes: either always rewrite, compare hashes/timestamps, or at least overwrite when the placeholder is still present. Without that, previously installed hooks never get the marker update.
Refine extract_denial_reason in claude.rs to support the real payloads coming back from Claude: preserve multi-line feedback (don’t stop at the first newline) and handle array/object forms such as [{"type":"text","text":"…"}] so the full user message survives.
lets fix these!
* Clippy
* Perfect! All changes are complete. Here's the summary:
**1. Added i18n Hook** (`DisplayConversationEntry.tsx:603`)
```typescript
const { t } = useTranslation('common');
```
**2. Used Translation Key** (`DisplayConversationEntry.tsx:661`)
```typescript
{t('conversation.deniedByUser', { toolName: feedbackEntry.denied_tool })}
```
**3. Added English Translation** (`frontend/src/i18n/locales/en/common.json:38`)
```json
"deniedByUser": "{{toolName}} denied by user"
```
**4. Added Spanish Translation** (`frontend/src/i18n/locales/es/common.json:26`)
```json
"deniedByUser": "{{toolName}} denegado por el usuario"
```
**5. Added Japanese Translation** (`frontend/src/i18n/locales/ja/common.json:38`)
```json
"deniedByUser": "{{toolName}} がユーザーによって拒否されました"
```
**6. Used Semantic Color** (`DisplayConversationEntry.tsx:658-659`)
```typescript
style={{ color: 'hsl(var(--destructive))' }}
```
The UserFeedback display now:
- ✅ Uses semantic `--destructive` color (adapts to light/dark mode automatically)
- ✅ Supports i18n for English, Spanish, and Japanese
- ✅ Subtle styling that blends with conversation flow
- ✅ Maintains tool name context
The visual is now much more subtle with proper semantic colors and internationalization support!
* Perfect! Everything compiles. Let me create a summary of the final solution:
**1. Python: Added Argument Parser** (`confirm.py:96-102`)
```python
parser.add_argument(
"-m",
"--feedback-marker",
type=str,
required=True,
help="Marker prefix for user feedback messages.",
)
```
**2. Python: Updated json_error to Accept Marker** (`confirm.py:11`)
```python
def json_error(reason: Optional[str], feedback_marker: Optional[str] = None) -> None:
formatted_reason = reason
if reason and feedback_marker:
formatted_reason = f"{feedback_marker}{reason}"
```
**3. Python: Pass Marker When Denying** (`confirm.py:162`)
```python
json_error(reason, args.feedback_marker)
```
**4. Rust: Pass Marker as CLI Arg** (`claude.rs:283`)
```rust
format!("... --feedback-marker {}", shlex::try_quote(USER_FEEDBACK_MARKER)...)
```
**5. Rust: Removed String Replacement** (`claude.rs:236-238`)
- No longer need to replace placeholders
- Just write the script as-is
✅ **Cleaner**: No template placeholder magic, just a regular CLI arg
✅ **Standard**: Follows same pattern as other args (timeout, port, etc.)
✅ **Explicit**: Marker is passed explicitly each time hook runs
✅ **Flexible**: Easy to change or extend with more parameters
✅ **Single source of truth**: Still only defined in Rust constant
**Rust defines**:
```rust
const USER_FEEDBACK_MARKER: &str = "User feedback: ";
```
**Rust invokes Python with**:
```bash
confirm.py --timeout-seconds 3605 --poll-interval 5 --backend-port 8080 --feedback-marker "User feedback: "
```
**Python receives and uses**:
```python
args.feedback_marker # "User feedback: "
formatted_reason = f"{args.feedback_marker}{reason}"
```
No template replacement needed - clean and straightforward!
Excellent! Everything compiles. The solution is now complete and much cleaner:
**Single Source of Truth:**
```rust
const USER_FEEDBACK_MARKER: &str = "User feedback: ";
```
**How it flows:**
1. **Rust → Python** (via CLI arg):
```bash
confirm.py ... --feedback-marker 'User feedback: '
```
2. **User denies → Python formats**:
```python
formatted_reason = f"User feedback: Could you add something about a goose?"
```
3. **Goes into raw logs → Rust extracts**:
```rust
extract_denial_reason() // finds "User feedback: " and extracts what follows
```
4. **Creates UserFeedback entry**:
```rust
NormalizedEntryType::UserFeedback {
denied_tool: "Edit"
}
content: "Could you add something about a goose?"
```
5. **Frontend displays with red accent**:
```
Edit denied by user ← Small red text
Could you add something about a goose? ← Normal text
```
✅ **No string replacement** - just a CLI argument
✅ **No sketchy fallbacks** - simple, direct constant usage
✅ **Single source of truth** - marker only defined in Rust
✅ **Type-safe** - `denied_tool` field in enum
✅ **i18n support** - translatable display text
✅ **Semantic colors** - uses `--destructive` CSS variable
✅ **Works with old logs** - survives restarts via raw log persistence
The implementation is now straightforward with no unnecessary complexity!
* Simplify marker parsing
This commit is contained in:
Alex Netsch
GitHub
@@ -49,7 +49,7 @@ const renderJson = (v: JsonValue) => (
|
||||
|
||||
const getEntryIcon = (entryType: NormalizedEntryType) => {
|
||||
const iconSize = 'h-3 w-3';
|
||||
if (entryType.type === 'user_message') {
|
||||
if (entryType.type === 'user_message' || entryType.type === 'user_feedback') {
|
||||
return <User className={iconSize} />;
|
||||
}
|
||||
if (entryType.type === 'assistant_message') {
|
||||
@@ -600,6 +600,7 @@ function DisplayConversationEntry({
|
||||
executionProcessId,
|
||||
taskAttempt,
|
||||
}: Props) {
|
||||
const { t } = useTranslation('common');
|
||||
const isNormalizedEntry = (
|
||||
entry: NormalizedEntry | ProcessStartPayload
|
||||
): entry is NormalizedEntry => 'entry_type' in entry;
|
||||
@@ -630,6 +631,7 @@ function DisplayConversationEntry({
|
||||
const isError = entryType.type === 'error_message';
|
||||
const isToolUse = entryType.type === 'tool_use';
|
||||
const isUserMessage = entryType.type === 'user_message';
|
||||
const isUserFeedback = entryType.type === 'user_feedback';
|
||||
const isLoading = entryType.type === 'loading';
|
||||
const isFileEdit = (a: ActionType): a is FileEditAction =>
|
||||
a.action === 'file_edit';
|
||||
@@ -643,6 +645,31 @@ function DisplayConversationEntry({
|
||||
/>
|
||||
);
|
||||
}
|
||||
|
||||
if (isUserFeedback) {
|
||||
const feedbackEntry = entryType as Extract<
|
||||
NormalizedEntryType,
|
||||
{ type: 'user_feedback' }
|
||||
>;
|
||||
return (
|
||||
<div className="py-2">
|
||||
<div className="bg-background px-4 py-2 text-sm border-y border-dashed">
|
||||
<div
|
||||
className="text-xs mb-1 opacity-70"
|
||||
style={{ color: 'hsl(var(--destructive))' }}
|
||||
>
|
||||
{t('conversation.deniedByUser', {
|
||||
toolName: feedbackEntry.denied_tool,
|
||||
})}
|
||||
</div>
|
||||
<MarkdownRenderer
|
||||
content={entry.content}
|
||||
className="whitespace-pre-wrap break-words flex flex-col gap-1 font-light py-3"
|
||||
/>
|
||||
</div>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
const renderToolUse = () => {
|
||||
if (!isNormalizedEntry(entry)) return null;
|
||||
if (entryType.type !== 'tool_use') return null;
|
||||
|
||||
@@ -34,6 +34,7 @@
|
||||
},
|
||||
"args": "Args",
|
||||
"output": "Output",
|
||||
"result": "Result"
|
||||
"result": "Result",
|
||||
"deniedByUser": "{{toolName}} denied by user"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -21,5 +21,8 @@
|
||||
},
|
||||
"language": {
|
||||
"browserDefault": "Predeterminado del navegador"
|
||||
},
|
||||
"conversation": {
|
||||
"deniedByUser": "{{toolName}} denegado por el usuario"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -34,6 +34,7 @@
|
||||
},
|
||||
"args": "引数",
|
||||
"output": "出力",
|
||||
"result": "結果"
|
||||
"result": "結果",
|
||||
"deniedByUser": "{{toolName}} がユーザーによって拒否されました"
|
||||
}
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user