brooktrails/directory-pacifier
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat: TUI #8

Merged
rcsheets merged 2 commits from feat/dp-tui into main 2026-04-13 07:59:38 +00:00
Conversation 2 Commits 2 Files changed 13 +1336 -7
rcsheets commented 2026-04-13 07:56:33 +00:00
Owner
Copy link
No description provided. 
The operator TUI's history pane needs every plan regardless of status,
ordered most-recent first. Add a typed listing that surfaces the
view's status column alongside the other plan fields. Integration
tests cover ordering, limit enforcement, and input validation.

Extract a seedPlan test helper that proposes a trivial plan via the
typed client — cleaner than hand-rolled SQL, and lets future tests
reuse the same scaffolding.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add cmd/dp: Bubble Tea TUI for the operator
All checks were successful
test / go-test (pull_request) Successful in 22s
Details
test / schema-test (pull_request) Successful in 52s
Details
8655489435 
Third runnable binary. dp is the operator's primary interface:
submit natural-language intents, review and decide on pending plans,
and watch plan status roll forward. Three tabs, switched via 1/2/3
or tab/shift+tab.

Intent — textarea for the intent text, ctrl+enter to submit to the
control loop's /intent endpoint. Response renders inline: plan_id,
the LLM's explanation, and a compact tool-call trace.

Pending — lives on the approval store (operator role). Polls
rollout_plan_status every 2s for status='pending'. j/k to move the
cursor, a to approve (24h expiry), r to reject. Approvals hit the
DB directly, not through the control loop — the control loop can
propose its own plans but cannot decide on them, which is the whole
point of the privilege separation.

History — read-only listing of the 50 most recent plans from
rollout_plan_status. Status colorized for at-a-glance triage.
Polls every 5s.

The root model broadcasts window-resize messages to every tab,
delegates unhandled keys to the active tab, and owns a transient
status line (approve/reject confirmations, errors). Ctrl+C quits
at any point.

Tests cover the HTTP client (happy path, non-2xx, unparseable body,
context cancel), the root model's tab-navigation and broadcast
logic, and pure-function rendering helpers. Bubble Tea UIs are
inherently hard to unit-test at the visual layer — the tests
verify the state machine, not the terminal output.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pr-reviewer-bot commented 2026-04-13 07:56:36 +00:00
Collaborator
Copy link

Automated review by pr-reviewer v0.15.0 | Full Review | anthropic | tracking id r-dca1b3-7df2c6
This is an AI-generated review and may contain mistakes.

Status: ✅ Completed

✅ Verdict: Approve — This is a well-structured TUI implementation with solid error handling, appropriate separation of concerns, and comprehensive test coverage.
Complexity: moderate

TUI Implementation Review

This PR adds a comprehensive terminal user interface (TUI) for the directory-pacifier operator using the Bubble Tea framework. The implementation is well-structured and follows good practices.

Architecture and Design

Strengths:

  • Clean separation of concerns with distinct files for each major component (API client, tabs, models)
  • Well-designed tab-based interface with three logical views: Intent, Pending, History
  • Good use of the Bubble Tea framework's patterns with proper message passing
  • Proper HTTP client with reasonable timeouts (120s) for LLM operations
  • Database operations properly scoped to operator role for privilege separation

Code Organization:

  • Each tab implements the tabModel interface consistently
  • HTTP API client is isolated in api.go with clear error handling
  • Root model properly delegates to active tabs and manages shared state

Error Handling and Edge Cases

HTTP Client (cmd/dp/api.go):

  • Proper context handling with background contexts for async operations
  • Non-2xx status codes are surfaced with server error details
  • JSON marshaling/unmarshaling errors are wrapped with context
  • Response body properly closed in defer

UI Components:

  • Database errors are displayed to user with appropriate styling
  • Empty states handled gracefully ("no plans yet", "nothing pending")
  • Cursor bounds checking prevents out-of-range errors
  • Input validation prevents submission of empty intents

Test Coverage

Comprehensive testing for:

  • HTTP client success/error paths, including context cancellation
  • Tab navigation and key handling
  • Message delegation between root model and tabs
  • Status message updates
  • Data formatting functions
  • Database integration tests for new approval store methods

Missing test coverage:
The automated observation correctly notes that several source files lack corresponding tests:

  • cmd/dp/history.go - could benefit from unit tests for message handling
  • cmd/dp/intent.go - UI logic tests would be valuable
  • cmd/dp/main.go - minimal coverage needed given simplicity
  • cmd/dp/model.go - already has good test coverage
  • cmd/dp/pending.go - could use tests for decision workflow

However, the core business logic is well-tested through the API client tests and integration tests.

Security and Performance

Security:

  • Proper privilege separation: approvals go directly to Postgres as operator role
  • No injection vulnerabilities in SQL queries (uses parameterized queries)
  • Input sanitization for display (newlines stripped in truncateForDisplay)

Performance:

  • Reasonable refresh intervals (2-5s) with manual refresh options
  • Database queries use appropriate limits and timeouts
  • UI prevents duplicate operations in flight (decideOp guard)

Minor Issues

  1. Line 67 in cmd/dp/api.go: The io.ReadAll error is intentionally ignored with _, but a comment explaining why would be helpful.

  2. Line 19 in cmd/dp/pending.go: Comment mentions "rpcserver" but elsewhere the code refers to "rpc_server" - minor inconsistency.

  3. Dependency management: The Go version 1.26.2 in go.mod is newer than my training cutoff, but appears to be a valid recent version.

Positive Highlights

  • Excellent use of lipgloss for consistent styling and theming
  • Smart handling of tab navigation vs text input (tabConsumesDigits)
  • Good UX with visual feedback for loading states and operations in flight
  • Proper resource cleanup with defer statements
  • Well-documented code with clear comments explaining design decisions

The implementation demonstrates solid Go practices and thoughtful UX design. The test coverage, while not complete, covers the critical paths well.

*Automated review by [pr-reviewer](https://git.brooktrails.org/brooktrails/pr-reviewer) v0.15.0 | Full Review | anthropic | tracking id `r-dca1b3-7df2c6`* *This is an AI-generated review and may contain mistakes.* **Status:** ✅ Completed --- **✅ Verdict: Approve** — This is a well-structured TUI implementation with solid error handling, appropriate separation of concerns, and comprehensive test coverage. **Complexity:** moderate # TUI Implementation Review This PR adds a comprehensive terminal user interface (TUI) for the directory-pacifier operator using the Bubble Tea framework. The implementation is well-structured and follows good practices. ## Architecture and Design **Strengths:** - Clean separation of concerns with distinct files for each major component (API client, tabs, models) - Well-designed tab-based interface with three logical views: Intent, Pending, History - Good use of the Bubble Tea framework's patterns with proper message passing - Proper HTTP client with reasonable timeouts (120s) for LLM operations - Database operations properly scoped to operator role for privilege separation **Code Organization:** - Each tab implements the `tabModel` interface consistently - HTTP API client is isolated in `api.go` with clear error handling - Root model properly delegates to active tabs and manages shared state ## Error Handling and Edge Cases **HTTP Client (`cmd/dp/api.go`):** - Proper context handling with background contexts for async operations - Non-2xx status codes are surfaced with server error details - JSON marshaling/unmarshaling errors are wrapped with context - Response body properly closed in defer **UI Components:** - Database errors are displayed to user with appropriate styling - Empty states handled gracefully ("no plans yet", "nothing pending") - Cursor bounds checking prevents out-of-range errors - Input validation prevents submission of empty intents ## Test Coverage **Comprehensive testing for:** - HTTP client success/error paths, including context cancellation - Tab navigation and key handling - Message delegation between root model and tabs - Status message updates - Data formatting functions - Database integration tests for new approval store methods **Missing test coverage:** The automated observation correctly notes that several source files lack corresponding tests: - `cmd/dp/history.go` - could benefit from unit tests for message handling - `cmd/dp/intent.go` - UI logic tests would be valuable - `cmd/dp/main.go` - minimal coverage needed given simplicity - `cmd/dp/model.go` - already has good test coverage - `cmd/dp/pending.go` - could use tests for decision workflow However, the core business logic is well-tested through the API client tests and integration tests. ## Security and Performance **Security:** - Proper privilege separation: approvals go directly to Postgres as operator role - No injection vulnerabilities in SQL queries (uses parameterized queries) - Input sanitization for display (newlines stripped in truncateForDisplay) **Performance:** - Reasonable refresh intervals (2-5s) with manual refresh options - Database queries use appropriate limits and timeouts - UI prevents duplicate operations in flight (`decideOp` guard) ## Minor Issues 1. **Line 67 in `cmd/dp/api.go`**: The `io.ReadAll` error is intentionally ignored with `_`, but a comment explaining why would be helpful. 2. **Line 19 in `cmd/dp/pending.go`**: Comment mentions "rpcserver" but elsewhere the code refers to "rpc_server" - minor inconsistency. 3. **Dependency management**: The Go version 1.26.2 in go.mod is newer than my training cutoff, but appears to be a valid recent version. ## Positive Highlights - Excellent use of lipgloss for consistent styling and theming - Smart handling of tab navigation vs text input (tabConsumesDigits) - Good UX with visual feedback for loading states and operations in flight - Proper resource cleanup with defer statements - Well-documented code with clear comments explaining design decisions The implementation demonstrates solid Go practices and thoughtful UX design. The test coverage, while not complete, covers the critical paths well.
pr-reviewer-bot commented 2026-04-13 07:56:45 +00:00
Collaborator
Copy link

Automated review by pr-reviewer v0.15.0 | Full Review | anthropic | tracking id r-dca1bc-f1c473
This is an AI-generated review and may contain mistakes.

Status: ✅ Completed

✅ Verdict: Approve — This is a well-structured TUI implementation with comprehensive tests, proper architecture, and good error handling.
Complexity: complex

Review of TUI Implementation

This PR introduces a comprehensive Terminal User Interface (TUI) for the directory-pacifier system. The implementation is well-structured and demonstrates good architectural patterns.

Strengths

Architecture & Design

  • Clean separation of concerns: Each tab is a separate module with clear responsibilities (intent submission, pending approvals, history viewing)
  • Proper MVC pattern: Clear separation between model (data), view (rendering), and controller (update logic)
  • Bubble Tea integration: Good use of the framework's command/message patterns for async operations
  • Dependency injection: Clean dependency wiring in newRootModel()

Error Handling

  • Comprehensive error propagation: Errors from HTTP requests, database operations, and JSON parsing are properly surfaced to the UI
  • Context cancellation: Proper use of context timeouts (5s for DB ops, 120s for HTTP)
  • Graceful degradation: UI remains functional when backend services are unavailable

Testing

  • Excellent test coverage: Both unit tests for individual components and integration tests
  • Realistic test scenarios: Tests cover success cases, error conditions, edge cases, and user interactions
  • Good test isolation: Use of stub implementations and proper cleanup

Code Quality

  • Clear documentation: Good comments explaining design decisions and usage patterns
  • Consistent naming: Clear, descriptive names throughout
  • Proper resource management: HTTP response bodies are closed, database connections are managed properly

Technical Implementation

HTTP Client (cmd/dp/api.go)

  • Appropriate timeout (120s) for LLM operations
  • Proper error message formatting including response body on failures
  • Good use of context for cancellation

Database Integration

  • New ListRecentPlans() method in approvalstore is well-implemented
  • Proper limit validation and error handling
  • Consistent with existing patterns in the codebase

UI Components

  • Intent Tab: Clean textarea integration with proper focus management
  • Pending Tab: Good keyboard navigation (j/k/a/r) and cursor management
  • History Tab: Auto-refreshing with manual refresh option
  • Status styling: Appropriate color coding for different plan statuses

Minor Observations

Positive

  • Smart digit key handling: digits are consumed by text input when focused, otherwise used for tab navigation
  • Proper operator identity handling with fallback to "dp-operator"
  • Good use of batched commands for related operations
  • Auto-refresh intervals are reasonable (2s for pending, 5s for history)

Areas for Future Enhancement

  • Consider adding keyboard shortcuts documentation in the UI
  • The 24-hour approval window is hardcoded - could be configurable
  • Error messages could potentially include retry suggestions

Security & Performance

  • No obvious security issues
  • Database queries are properly parameterized
  • HTTP client has reasonable timeouts
  • Context usage prevents resource leaks

Dependencies

The new dependencies (Bubble Tea ecosystem) are appropriate for a TUI application and are actively maintained projects.

Conclusion

This is a high-quality implementation that adds significant value to the operator experience. The code is well-structured, thoroughly tested, and follows good practices throughout. The TUI provides a clean interface for the core workflow (submit intents → review plans → approve/reject → monitor execution).

*Automated review by [pr-reviewer](https://git.brooktrails.org/brooktrails/pr-reviewer) v0.15.0 | Full Review | anthropic | tracking id `r-dca1bc-f1c473`* *This is an AI-generated review and may contain mistakes.* **Status:** ✅ Completed --- **✅ Verdict: Approve** — This is a well-structured TUI implementation with comprehensive tests, proper architecture, and good error handling. **Complexity:** complex # Review of TUI Implementation This PR introduces a comprehensive Terminal User Interface (TUI) for the directory-pacifier system. The implementation is well-structured and demonstrates good architectural patterns. ## Strengths ### Architecture & Design - **Clean separation of concerns**: Each tab is a separate module with clear responsibilities (intent submission, pending approvals, history viewing) - **Proper MVC pattern**: Clear separation between model (data), view (rendering), and controller (update logic) - **Bubble Tea integration**: Good use of the framework's command/message patterns for async operations - **Dependency injection**: Clean dependency wiring in `newRootModel()` ### Error Handling - **Comprehensive error propagation**: Errors from HTTP requests, database operations, and JSON parsing are properly surfaced to the UI - **Context cancellation**: Proper use of context timeouts (5s for DB ops, 120s for HTTP) - **Graceful degradation**: UI remains functional when backend services are unavailable ### Testing - **Excellent test coverage**: Both unit tests for individual components and integration tests - **Realistic test scenarios**: Tests cover success cases, error conditions, edge cases, and user interactions - **Good test isolation**: Use of stub implementations and proper cleanup ### Code Quality - **Clear documentation**: Good comments explaining design decisions and usage patterns - **Consistent naming**: Clear, descriptive names throughout - **Proper resource management**: HTTP response bodies are closed, database connections are managed properly ## Technical Implementation ### HTTP Client (`cmd/dp/api.go`) - Appropriate timeout (120s) for LLM operations - Proper error message formatting including response body on failures - Good use of context for cancellation ### Database Integration - New `ListRecentPlans()` method in approvalstore is well-implemented - Proper limit validation and error handling - Consistent with existing patterns in the codebase ### UI Components - **Intent Tab**: Clean textarea integration with proper focus management - **Pending Tab**: Good keyboard navigation (j/k/a/r) and cursor management - **History Tab**: Auto-refreshing with manual refresh option - **Status styling**: Appropriate color coding for different plan statuses ## Minor Observations ### Positive - Smart digit key handling: digits are consumed by text input when focused, otherwise used for tab navigation - Proper operator identity handling with fallback to "dp-operator" - Good use of batched commands for related operations - Auto-refresh intervals are reasonable (2s for pending, 5s for history) ### Areas for Future Enhancement - Consider adding keyboard shortcuts documentation in the UI - The 24-hour approval window is hardcoded - could be configurable - Error messages could potentially include retry suggestions ## Security & Performance - No obvious security issues - Database queries are properly parameterized - HTTP client has reasonable timeouts - Context usage prevents resource leaks ## Dependencies The new dependencies (Bubble Tea ecosystem) are appropriate for a TUI application and are actively maintained projects. ## Conclusion This is a high-quality implementation that adds significant value to the operator experience. The code is well-structured, thoroughly tested, and follows good practices throughout. The TUI provides a clean interface for the core workflow (submit intents → review plans → approve/reject → monitor execution).
rcsheets deleted branch feat/dp-tui 2026-04-13 07:59:41 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
pr-reviewer-bot
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
brooktrails/directory-pacifier!8
No description provided.