> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sudocode.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# sudocode feedback dismiss

> Dismiss one or more feedback entries to mark them as addressed or resolved

## Syntax

```bash theme={null}
sudocode feedback dismiss <feedback-id> [<feedback-id>...]
```

## Description

The `feedback dismiss` command marks feedback as resolved or addressed. Dismissed feedback:

* Remains in the database (not deleted)
* Is marked with `dismissed: true`
* Updates the `updated_at` timestamp
* Appears grayed out in `feedback list`
* Can be filtered with `--dismissed true`
* Preserves full audit trail

Use this command when:

* You've addressed the feedback by updating the spec
* The feedback is no longer relevant
* A question has been answered
* A suggestion has been implemented or declined
* An implementation note has been reviewed

<Note>
  Dismissing is a soft operation - feedback remains in the database for historical reference. There is no way to delete feedback permanently.
</Note>

## Arguments

<ParamField path="feedback-id" type="string" required>
  One or more feedback IDs to dismiss

  **Example:** `FB-001` or `FB-001 FB-002 FB-003`

  You can dismiss multiple feedback entries in a single command.
</ParamField>

## Examples

### Dismiss Single Feedback

Mark one feedback as addressed:

```bash theme={null}
sudocode feedback dismiss FB-001
```

<Accordion title="Expected output">
  ```
  ✓ Dismissed feedback FB-001
  ```
</Accordion>

### Dismiss Multiple Feedback

Mark several feedback entries as resolved:

```bash theme={null}
sudocode feedback dismiss FB-001 FB-002 FB-003
```

<Accordion title="Expected output">
  ```
  ✓ Dismissed feedback FB-001
  ✓ Dismissed feedback FB-002
  ✓ Dismissed feedback FB-003
  ```
</Accordion>

### Dismiss After Spec Update

After updating a spec to address feedback:

```bash theme={null}
# Update the spec
vim .sudocode/specs/authentication-system.md

# Dismiss the feedback
sudocode feedback dismiss FB-001
```

<Accordion title="Expected output">
  ```
  ✓ Dismissed feedback FB-001
  ```
</Accordion>

### Dismiss Non-Existent Feedback

Attempt to dismiss feedback that doesn't exist:

```bash theme={null}
sudocode feedback dismiss FB-999
```

<Accordion title="Expected output">
  ```
  ✗ Failed to dismiss feedback
  Feedback not found: FB-999
  ```
</Accordion>

### JSON Output

Get machine-readable output:

```bash theme={null}
sudocode --json feedback dismiss FB-001
```

<Accordion title="JSON output">
  ```json theme={null}
  {
    "id": "FB-001",
    "issue_id": "ISSUE-001",
    "spec_id": "SPEC-001",
    "feedback_type": "request",
    "content": "Token expiration policy not specified. Should we use fixed or sliding window?",
    "agent": "alice",
    "anchor": {
      "line_number": 42,
      "section_heading": "Authentication Flow",
      "text_snippet": "Token expiration policy",
      "anchor_status": "valid",
      "context_before": "...",
      "context_after": "..."
    },
    "dismissed": true,
    "created_at": "2025-10-29T10:15:00Z",
    "updated_at": "2025-10-29T14:30:00Z"
  }
  ```
</Accordion>

Notice `dismissed: true` and the updated `updated_at` timestamp.

## What Happens When You Dismiss

<Steps>
  <Step title="Dismissed flag set">
    The `dismissed` field is set to `true` in the database
  </Step>

  <Step title="Timestamp updated">
    The `updated_at` timestamp is set to the current time
  </Step>

  <Step title="Database updated">
    Changes are written to the SQLite database
  </Step>

  <Step title="JSONL exported">
    The dismissal is recorded in `feedback.jsonl` (if feedback export is enabled)
  </Step>

  <Step title="Appearance changes">
    Feedback appears grayed out in `feedback list` output
  </Step>
</Steps>

## What Doesn't Change

<Info>
  Dismissing feedback does NOT:
</Info>

* Delete the feedback entry
* Change the feedback content
* Modify the anchor location
* Remove the feedback from the spec
* Affect the source issue
* Change creation timestamp

Dismissed feedback remains fully accessible and searchable.

## Common Workflows

### Address Feedback and Dismiss

<Steps>
  <Step title="Review feedback">
    ```bash theme={null}
    sudocode feedback show FB-001
    ```
  </Step>

  <Step title="View spec">
    ```bash theme={null}
    sudocode spec show SPEC-001
    ```
  </Step>

  <Step title="Update spec">
    Edit the spec to address the feedback

    ```bash theme={null}
    vim .sudocode/specs/authentication-system.md
    ```
  </Step>

  <Step title="Dismiss feedback">
    ```bash theme={null}
    sudocode feedback dismiss FB-001
    ```
  </Step>

  <Step title="Commit changes">
    ```bash theme={null}
    git add .sudocode/
    git commit -m "Address feedback: clarify token expiration policy"
    ```
  </Step>
</Steps>

### Bulk Dismiss After Spec Update

Dismiss all feedback for a spec you've updated:

<Steps>
  <Step title="Update spec">
    Make comprehensive spec improvements
  </Step>

  <Step title="List feedback">
    ```bash theme={null}
    sudocode feedback list --spec SPEC-001 --dismissed false
    ```
  </Step>

  <Step title="Review and dismiss">
    ```bash theme={null}
    sudocode feedback dismiss FB-001 FB-002 FB-003
    ```
  </Step>
</Steps>

### Dismiss Obsolete Feedback

Remove feedback that's no longer relevant:

<Steps>
  <Step title="Find stale or outdated feedback">
    ```bash theme={null}
    sudocode feedback list --spec SPEC-001
    ```
  </Step>

  <Step title="Review details">
    ```bash theme={null}
    sudocode feedback show FB-005
    ```
  </Step>

  <Step title="Dismiss if obsolete">
    ```bash theme={null}
    sudocode feedback dismiss FB-005
    ```
  </Step>
</Steps>

### Dismiss Implementation Notes

After reviewing implementation feedback:

```bash theme={null}
# List implementation notes
sudocode feedback list --type comment --spec SPEC-001

# Review and acknowledge
sudocode feedback show FB-002

# Dismiss after review
sudocode feedback dismiss FB-002
```

## Scripting Examples

### Dismiss All Feedback for a Spec

```bash theme={null}
# Dismiss all active feedback for a spec
sudocode --json feedback list --spec SPEC-001 --dismissed false | \
  jq -r '.[] | .id' | \
  xargs sudocode feedback dismiss
```

<Warning>
  Be careful with bulk dismissals - review feedback first to ensure it's been addressed.
</Warning>

### Dismiss All Comment-Type Feedback

```bash theme={null}
# Dismiss all informational comments (already reviewed)
sudocode --json feedback list --type comment --dismissed false | \
  jq -r '.[] | .id' | \
  xargs sudocode feedback dismiss
```

### Conditional Dismiss

```bash theme={null}
# Dismiss feedback from a specific issue
sudocode --json feedback list --issue ISSUE-001 --dismissed false | \
  jq -r '.[] | .id' | \
  while read fb_id; do
    echo "Dismiss $fb_id? (y/n)"
    read answer
    if [[ "$answer" == "y" ]]; then
      sudocode feedback dismiss "$fb_id"
    fi
  done
```

### Generate Dismissal Report

```bash theme={null}
# Show what was dismissed today
today=$(date '+%Y-%m-%d')
sudocode --json feedback list --dismissed true | \
  jq --arg today "$today" '.[] | select(.updated_at | startswith($today))'
```

## Dismiss vs Delete

<CardGroup cols={2}>
  <Card title="Dismiss (Available)" icon="check">
    **Marks as addressed**

    * Feedback retained in database
    * Full audit trail preserved
    * Can be viewed later
    * Appears in filtered lists
    * Reversible (manually update DB)
  </Card>

  <Card title="Delete (Not Available)" icon="trash">
    **Permanent removal**

    * Not supported by CLI
    * Would lose audit trail
    * No way to recover
    * Breaks historical context
    * Not recommended for feedback
  </Card>
</CardGroup>

**Best practice:** Always dismiss rather than delete. Feedback provides valuable historical context for how specs evolved.

## Viewing Dismissed Feedback

<Steps>
  <Step title="List dismissed feedback">
    ```bash theme={null}
    sudocode feedback list --dismissed true
    ```
  </Step>

  <Step title="Show details">
    ```bash theme={null}
    sudocode feedback show FB-001
    ```

    The status will show "Dismissed"
  </Step>

  <Step title="View in spec">
    ```bash theme={null}
    sudocode spec show SPEC-001
    ```

    Dismissed feedback may be hidden or grayed out
  </Step>
</Steps>

## "Un-dismissing" Feedback

There's no dedicated command to reactivate dismissed feedback. If needed:

### Manual Database Update

```bash theme={null}
# WARNING: Direct database manipulation - use with caution
sqlite3 .sudocode/sudocode.db "UPDATE feedback SET dismissed = 0 WHERE id = 'FB-001'"

# Then export to JSONL
sudocode sync
```

<Warning>
  Direct database updates are not recommended. Consider adding new feedback instead.
</Warning>

### Better Alternative

Add new feedback instead:

```bash theme={null}
sudocode feedback add ISSUE-010 SPEC-001 \
  --type request \
  --content "Follow-up on previous feedback..." \
  --line 42
```

## Common Questions

<AccordionGroup>
  <Accordion title="Can I undo a dismissal?">
    Not through the CLI. You would need to manually update the database:

    ```bash theme={null}
    sqlite3 .sudocode/sudocode.db "UPDATE feedback SET dismissed = 0 WHERE id = 'FB-001'"
    ```

    Better approach: Add new feedback if still relevant.
  </Accordion>

  <Accordion title="Does dismissing notify anyone?">
    No, sudocode doesn't have built-in notifications. Dismissals are tracked via git commits.
  </Accordion>

  <Accordion title="Should I dismiss or delete feedback?">
    Always dismiss. There's no delete command because feedback should be preserved for audit trail.
  </Accordion>

  <Accordion title="What happens to dismissed feedback in specs?">
    Dismissed feedback remains linked to specs but may be hidden or grayed out in `spec show` output.
  </Accordion>

  <Accordion title="Can I add a reason for dismissal?">
    No, the command doesn't accept a reason parameter. Document dismissal reasons in git commit messages:

    ```bash theme={null}
    sudocode feedback dismiss FB-001
    git commit -m "Dismiss FB-001: token policy now specified in section 3.2"
    ```
  </Accordion>

  <Accordion title="How do I know who dismissed feedback?">
    Check git history:

    ```bash theme={null}
    git log -p .sudocode/sudocode.db | grep -A 5 "FB-001"
    ```

    Or for JSONL:

    ```bash theme={null}
    git log -p .sudocode/feedback.jsonl | grep -A 5 "FB-001"
    ```
  </Accordion>
</AccordionGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Error: Feedback not found">
    **Cause:** The feedback ID doesn't exist

    **Solution:**
    List all feedback to find the correct ID:

    ```bash theme={null}
    sudocode feedback list
    ```
  </Accordion>

  <Accordion title="Feedback still appears in active list after dismissing">
    **Cause:** Using wrong filter

    **Solution:**
    Show all feedback including dismissed:

    ```bash theme={null}
    sudocode feedback list
    ```

    Or show only dismissed:

    ```bash theme={null}
    sudocode feedback list --dismissed true
    ```
  </Accordion>

  <Accordion title="Can't dismiss already dismissed feedback">
    **Cause:** Feedback is already dismissed

    **Solution:**
    Check status:

    ```bash theme={null}
    sudocode feedback show FB-001
    ```

    Dismissing again is harmless but has no effect.
  </Accordion>

  <Accordion title="Dismissal didn't update timestamp">
    **Cause:** Possible database sync issue

    **Solution:**
    Run sync:

    ```bash theme={null}
    sudocode sync
    ```

    Then check again:

    ```bash theme={null}
    sudocode feedback show FB-001
    ```
  </Accordion>
</AccordionGroup>

## Related Commands

<CardGroup cols={3}>
  <Card title="feedback list" icon="list" href="/cli/feedback-list">
    List all feedback
  </Card>

  <Card title="feedback show" icon="eye" href="/cli/feedback-show">
    View feedback details
  </Card>

  <Card title="feedback add" icon="plus" href="/cli/feedback-add">
    Add new feedback
  </Card>

  <Card title="spec show" icon="file-lines" href="/cli/spec-show">
    View spec with feedback
  </Card>

  <Card title="issue show" icon="list-check" href="/cli/issue-show">
    View issue with feedback
  </Card>
</CardGroup>

## Next Steps

<Steps>
  <Step title="Review feedback">
    ```bash theme={null}
    sudocode feedback show FB-001
    ```
  </Step>

  <Step title="Address the feedback">
    Update spec or respond as appropriate
  </Step>

  <Step title="Dismiss">
    ```bash theme={null}
    sudocode feedback dismiss FB-001
    ```
  </Step>

  <Step title="Commit changes">
    ```bash theme={null}
    git add .sudocode/
    git commit -m "Address and dismiss feedback FB-001"
    ```
  </Step>
</Steps>

<Card title="Feedback System Concept Guide" icon="book" href="/concepts/feedback">
  Learn more about the feedback system and bidirectional learning
</Card>