01a0ef46c9
- Add startup_command field to ToolType model and API - Execute startup command before interactive shell in terminal sessions - Add tmux and ranger to OpenCode container spec - Update Tool Workshop UI with startup_command input for terminal types - Add backend tests for startup_command CRUD operations - Sync specs: tool-terminal, tool-types-definition, opencode-web-server - New spec: tool-terminal-startup-command Quality gates: Frontend typecheck/lint passed. Backend tests blocked by environment (Python/Docker not available). OpenSpec: terminal-startup-and-container-tools
67 lines
2.5 KiB
Markdown
67 lines
2.5 KiB
Markdown
# Terminal Startup Command Specification
|
|
|
|
## Purpose
|
|
|
|
Allow tool type authors to define a startup command that executes for each new terminal session.
|
|
|
|
## Requirements
|
|
|
|
### Requirement: Terminal tool types can define a startup command
|
|
|
|
The system SHALL allow tool types to specify a `startup_command` that runs before the interactive shell for each new terminal session.
|
|
|
|
#### Scenario: Tool type with startup command
|
|
- **GIVEN** a tool type with `interface_type` = "terminal" and `startup_command` = "cd /workspace && ls"
|
|
- **WHEN** a user opens a terminal session to an instance of this tool type
|
|
- **THEN** the startup command executes before the interactive shell starts
|
|
- **AND** the user sees the output of the startup command in the terminal
|
|
|
|
#### Scenario: Tool type without startup command
|
|
- **GIVEN** a tool type with `interface_type` = "terminal" and no `startup_command`
|
|
- **WHEN** a user opens a terminal session
|
|
- **THEN** the interactive shell starts immediately without any startup execution
|
|
|
|
#### Scenario: Startup command failure does not block shell
|
|
- **GIVEN** a tool type with `startup_command` = "exit 1"
|
|
- **WHEN** a user opens a terminal session
|
|
- **THEN** the startup command runs and fails
|
|
- **AND** the interactive shell still starts afterward
|
|
|
|
### Requirement: Startup command is stored on the tool type
|
|
|
|
The system SHALL persist `startup_command` as a field on the `tool_types` table.
|
|
|
|
#### Scenario: Create tool type with startup command
|
|
- **GIVEN** a user creating a tool type
|
|
- **WHEN** they provide `startup_command` = "source /etc/profile"
|
|
- **THEN** the tool type is created with the startup command stored
|
|
|
|
#### Scenario: Update tool type startup command
|
|
- **GIVEN** an existing tool type with a startup command
|
|
- **WHEN** an admin updates `startup_command` to a new value
|
|
- **THEN** the tool type is updated
|
|
- **AND** new terminal sessions use the updated startup command
|
|
|
|
### Requirement: Startup command is optional
|
|
|
|
The system SHALL treat `startup_command` as an optional field on tool types.
|
|
|
|
#### Scenario: Create tool type without startup command
|
|
- **GIVEN** a user creating a terminal tool type
|
|
- **WHEN** they omit `startup_command`
|
|
- **THEN** the tool type is created successfully
|
|
- **AND** terminal sessions start normally without a startup command
|
|
|
|
## Dependencies
|
|
|
|
- tool-types-definition (model and API)
|
|
- tool-terminal (session execution)
|
|
|
|
## Quality Gates
|
|
|
|
- `pytest` must pass
|
|
- `mypy .` must pass
|
|
- `ruff check .` must pass
|
|
- `npm run typecheck` must pass
|
|
- `npm run lint` must pass
|