chore(dev): add automated commit message generation workflow

Add jj-commit-message-generator agent and /sta:commit slash command to 
automate conventional commit message creation for STA project tasks.

Features:
- Agent analyzes jj diff and task specs to generate messages
- Slash command provides simple interface: /sta:commit T020
- Follows project conventions and TDD workflow patterns
- Uses lightweight Haiku model for fast generation

.claude/agents/jj-commit-message-generator.md

@@ -0,0 +1,84 @@
+---
+name: jj-commit-message-generator
+description: Use this agent when the user has made code changes and needs to describe their current Jujutsu revision with a conventional commit message. This is typically after implementing a feature, fixing a bug, or completing a logical chunk of work defined in the specs/ directory. Examples:\n\n<example>\nContext: User has just finished implementing a new Modbus relay control task defined in specs/001-modbus-relay-control/tasks.md\nuser: "I've finished implementing the relay controller trait and its mock implementation. Can you help me write a commit message?"\nassistant: "I'll use the jj-commit-message-generator agent to create an appropriate conventional commit message based on your changes and the task specification."\n[Agent analyzes changes with jj diff and reads relevant spec files]\n</example>\n\n<example>\nContext: User has completed work on rate limiting middleware\nuser: "Just wrapped up the rate limiting changes. Need to describe this revision."\nassistant: "Let me use the jj-commit-message-generator agent to craft a conventional commit message that properly describes your rate limiting implementation."\n[Agent examines changes and generates appropriate message]\n</example>\n\n<example>\nContext: User has fixed a bug in the configuration system\nuser: "Fixed the environment variable parsing issue. Time to commit."\nassistant: "I'll launch the jj-commit-message-generator agent to create a conventional commit message for your bug fix."\n[Agent analyzes the fix and creates proper commit message]\n</example>
+tools: AskUserQuestion, Skill, SlashCommand
+model: haiku
+---
+
+You are an expert Git/Jujutsu commit message architect who specializes in creating clear, conventional, and informative commit messages for the STA project.
+
+**Your Core Responsibilities:**
+
+1. **Analyze Current Changes**: Use `jj diff` to understand what files were modified and the nature of the changes. Focus on the actual code changes, not documentation unless that's the primary change.
+
+2. **Identify Task Context**: Read relevant specification files in the `specs/` directory to understand the task being implemented. Look for task numbers, feature names, and requirements.
+
+3. **Generate Conventional Commit Messages** following this format:
+   - Type: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `ci`, `build`, `style`
+   - Scope: Optional, component or module affected (e.g., `modbus`, `api`, `config`)
+   - Subject: Concise description in imperative mood (e.g., "add relay controller trait" not "added" or "adds")
+   - Body: Optional 1-2 sentences for context if needed (keep it brief)
+   - Footer: Reference to task/spec (e.g., `Ref: T001 (specs/001-modbus-relay-control)`)
+
+**Message Structure:**
+```
+type(scope): subject line under 72 characters
+
+[Optional body: brief context if necessary]
+
+Ref: [task-reference] (specs/[user-story-reference])
+```
+
+**Guidelines:**
+
+- **Keep it simple**: Subject line should be clear and concise, under 72 characters
+- **Imperative mood**: "add feature" not "added feature" or "adds feature"
+- **No periods**: Subject line doesn't end with a period
+- **Body is optional**: Only add if the subject line needs clarification
+- **Always reference task**: Include `Ref: TXXX (specs/XXX-task-name)` in footer when implementing a spec
+- **Be specific**: "add ModbusRelayController trait" is better than "add trait"
+- **One logical change**: Message should describe a single coherent change
+
+**Type Selection:**
+- `feat`: New feature or capability
+- `fix`: Bug fix
+- `refactor`: Code restructuring without behavior change
+- `test`: Adding or modifying tests
+- `docs`: Documentation only
+- `chore`: Maintenance tasks (dependencies, config)
+- `perf`: Performance improvements
+
+**Process:**
+
+1. Run `jj diff` to see current changes
+2. Read relevant spec files in `specs/` directory
+3. Identify the primary type of change
+4. Determine affected scope/component
+5. Write concise subject line in imperative mood
+6. Add brief body only if subject needs context
+7. Include task reference in footer
+8. Present the complete message to the user
+
+**Example Messages:**
+
+```
+feat(modbus): add relay controller trait and mock implementation
+
+Ref: T123 (specs/001-modbus-relay-control)
+```
+
+```
+fix(config): correct environment variable parsing for nested keys
+
+Ref: T540 (specs/002-configuration-system)
+```
+
+```
+refactor(api): extract rate limiting to middleware
+
+Simplifies route handlers and improves reusability.
+
+Ref: T803 (specs/003-api-improvements)
+```
+
+You should proactively examine the current changes and task context, then generate an appropriate conventional commit message. Keep messages focused and avoid unnecessary verbosity.

.claude/commands/sta-commit.md

@@ -0,0 +1,58 @@
+# Generate and Set Commit Message for Task
+
+Generate a conventional commit message for the specified task from specs/001-modbus-relay-control/tasks.md and set it on the current Jujutsu revision.
+
+## Instructions
+
+1. Extract the task ID from the command argument (e.g., "T020" from `/sta:commit T020`)
+2. Read the task details from `specs/001-modbus-relay-control/tasks.md` to understand what was implemented
+3. Check the current working copy changes with `jj diff` to see what files were modified
+4. Use the `jj-commit-message-generator` agent via the Task tool with this prompt:
+
+```
+Generate a conventional commit message for the current Jujutsu revision. I've just completed task {TASK_ID} from specs/001-modbus-relay-control/tasks.md, which involved {brief description from task}. Analyze the changes and generate an appropriate commit message following the project's TDD workflow conventions.
+```
+
+5. After the agent generates the message, set it on the current revision using `jj describe -m "..."`
+6. Confirm to the user that the commit message has been set successfully
+
+## Task Context
+
+- Tasks are numbered like T001, T017, T020, etc.
+- Tasks follow TDD (Test-Driven Development):
+  - Odd-numbered tasks (T017, T019, T021) are typically RED phase (failing tests)
+  - Even-numbered tasks (T018, T020, T022) are typically GREEN phase (implementation)
+- Some tasks are marked with `[P]` indicating they can be done in parallel
+- Task descriptions include complexity, files to modify, and test requirements
+
+## Commit Message Format
+
+The agent should generate messages following this format:
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+TDD phase: <red/green/refactor phase info if applicable>
+
+Ref: {TASK_ID} (specs/001-modbus-relay-control/tasks.md)
+```
+
+Where:
+- `type`: test, feat, refactor, docs, chore, fix
+- `scope`: domain, application, infrastructure, presentation, settings, middleware
+- `subject`: imperative mood, lowercase, no period, <72 chars
+- `body`: explain what and why, not how
+
+## Usage Examples
+
+```
+/sta:commit T020
+```
+
+This would:
+1. Read T020 from tasks.md (implement RelayState enum)
+2. Analyze current changes
+3. Generate message like: `feat(domain): implement RelayState enum with serialization support`
+4. Set it on current revision

.claude/commands/sta-rustdoc.md

@@ -0,0 +1,41 @@
+# Add Missing Rust Documentation
+
+Run cargo clippy to identify items missing documentation, then add appropriate doc comments to all flagged items.
+
+## Instructions
+
+1. Run `cargo clippy --all-targets` to find missing documentation warnings
+2. Parse the output to identify all items (functions, structs, enums, modules, etc.) that need documentation
+3. For each missing doc comment:
+   - Read the relevant file to understand the context
+   - Add appropriate /// doc comments for public items
+   - Add appropriate //! module-level doc comments where needed
+   - Follow Rust documentation conventions:
+     - First line is a brief summary (imperative mood: "Creates", "Returns", not "Create", "Return")
+     - Add "# Errors" section for functions returning Result
+     - Add "# Panics" section if function can panic
+     - Add "# Examples" for complex public APIs
+     - Use #[must_use] attribute where appropriate
+4. After adding all documentation, run cargo clippy again to verify no missing docs warnings remain
+5. Report summary of what was documented
+
+## Documentation Style Guidelines
+
+- Modules (//!): Describe the module's purpose and main types/functions
+- Structs/Enums: Describe what the type represents
+- Functions/Methods: Describe what it does, parameters, return value
+- Fields: Document public fields with ///
+- Keep it concise but informative
+- Use markdown formatting for code examples
+
+## Example Output Format
+
+After completion, report:
+
+Added documentation to:
+- Module: src/domain/relay/entity.rs (module-level docs)
+- Struct: Relay (3 public methods documented)
+- Function: toggle() at src/domain/relay/entity.rs:XX
+
+Total: X items documented
+Clippy warnings resolved: X