Compare commits

...
Author SHA1 Message Date
Florian Asche 79cc2a12a9 chore(github): establish repository governance and automation
Introduce essential GitHub configuration files to standardize project maintenance and contribution workflows.

- Add PR and issue templates to improve contribution quality
- Configure Dependabot for automated dependency management
- Implement a workflow for automated PR labeling
- Add FUNDING.yml for project support visibility
- Update copilot-instructions.md with specific PR review standards and title requirements
2026-07-20 17:30:18 +02:00
Florian Asche 0ec78567a6 docs(agents): centralize AI guidelines and project documentation
Refactor documentation structure to consolidate AI agent instructions into AGENTS.md and .github/copilot-instructions.md. Remove redundant LLM-specific files (CLAUDE.md, GEMINI.md) and introduce new governance files for AI policy and contribution guidelines.

- Consolidate agent behavior, code style, and verification rules in AGENTS.md
- Simplify .github/copilot-instructions.md to a quick reference guide
- Add .github/AI_POLICY.md and .github/CONTRIBUTING.md
- Update kilo.json permissions to require explicit consent for file reads
- Remove deprecated model-specific instruction files
2026-07-20 17:14:47 +02:00
Florian Asche 2c38f5f46a feat(skills): add initial skill definitions and capabilities 2026-07-20 02:44:26 +02:00
Florian Asche f750b83a2c docs(agents): add verification checklists and LLM context files
Update AGENTS.md with a verification checklist and specific hardware
caution areas. Add dedicated instruction files for Copilot, Claude,
and Gemini to improve AI-assisted development and context awareness.
2026-07-20 02:37:35 +02:00
Florian Asche dd1d5faff6 refactor(setup): downgrade system dependency check from error to warning
Modify the setup script to treat missing audio libraries as warnings
instead of fatal errors. This accommodates environments like CI
where dependencies are managed separately and prevents setup failures
in non-interactive or containerized contexts.
2026-07-19 17:35:47 +02:00
Florian Asche ff2c213e41 chore(vscode): update Run Application task to use docker-compose 2026-07-19 17:19:43 +02:00
Florian Asche e9a9e1090b chore(dev): improve development environment and documentation
- Add VS Code workspace configuration and recommended extensions
- Update README.md with system requirements and VS Code setup instructions
- Enhance `script/setup` with Python 3.11+ detection and system dependency checks
- Add `SKIP_PULSE_AUDIO_WAIT` option to `docker-entrypoint.sh` for local development
- Update `.gitignore` and VS Code launch/task configurations
2026-07-19 16:52:54 +02:00
Florian Asche 65e90dac55 chore(vscode): add workspace configuration files
Add .vscode settings, extensions, launch, and tasks configurations to
standardize the development environment.
2026-07-19 15:32:45 +02:00
Florian Asche 8ad701db32 docs: add project documentation and agent context
Add AGENTS.md to provide project overview, architecture, and development
guidelines for AI agents. Include .kilo/ directory with command
documentation for linting, running, setup, and testing. Add VS Code
settings and kilo.json configuration.
2026-07-19 15:21:40 +02:00
30 changed files with 843 additions and 26 deletions

No files matched your search

+39
View File
@@ -0,0 +1,39 @@
# Linux Voice Assistant - AI Policy
We support using AI (i.e., LLMs) as tools when contributing to Linux Voice Assistant. However, you are responsible for any contributions you submit, and we are responsible for any contributions we merge and release. We hold a high bar for all contributions to our projects.
Our maintainers dedicate their time and expertise to reviewing contributions. Submitting AI-generated content that you have not personally reviewed and understood wastes that time and will not be accepted.
## Autonomous agents
We do not allow autonomous agents to be used for contributing to our projects. We will close any pull requests or issues that we believe were created autonomously, and may mark automated comments as spam. This includes contributions that bypass the provided issue or pull request templates.
## Communication on issues, pull requests, and code reviews
We don't mind if you use AI tools to help you write. However, do not have tools post unreviewed content on your behalf. Keep responses to the minimum needed to communicate your intent. We may hide any comments that we believe are unreviewed AI output.
If you are opening a pull request, we expect you to be able to explain the proposed changes in your own words. This includes the pull request description and responses to questions. If you use AI to help generate the pull request summary, you must review it for technical accuracy.
**Do not use AI to generate answers to questions from maintainers.** You should understand and be able to explain your own work. Using AI to improve grammar or clarity is fine, but the substance of your responses must be your own.
If you wish to include context from an interaction with AI in your comments, it must be in a quote block (e.g., using `>`) and disclosed as such. It must be accompanied by your own commentary explaining the relevance and implications of the context. Do not share long snippets.
## Non-native English speakers
We understand that AI is useful when communicating as a non-native English speaker. If you are using AI to translate your comments, please ensure the translation accurately reflects your intent. Including your original text in a details block shows the effort behind your contribution, helps maintainers verify the translation if needed, and keeps the conversation readable.
## Code and documentation contributions
AI can be a helpful tool for writing code and documentation. However, due to the foundational open source nature of our projects, we require a human in the loop who understands the work produced by AI.
All contributions must be reviewed and understood by the contributor before submission. You should be able to explain every change in a pull request you submit. Pull requests that appear to be unreviewed AI output will be closed without review.
## Our use of AI
Some of our projects use AI tools to assist with code reviews, issue triaging, reporting, and other project management tasks. These tools may leave comments on pull requests or issues. As with any automated tooling, these comments are not always correct.
If an AI tool leaves a comment on your contribution, treat it as you would any other review comment. If you believe it is incorrect, say so; a brief explanation is sufficient. Maintainers always have the final say. If in doubt, ask a maintainer.
## Enforcement
Contributions that do not follow this policy will be closed. Repeated violations may result in being blocked from contributing to LVA projects.
+22
View File
@@ -0,0 +1,22 @@
# Contributing to Linux Voice Assistant
Everybody is invited and welcome to contribute to Linux Voice Assistant. Even if you are not a developer, perhaps you would like to help with the documentation? If you are a developer and have a feature that isn't supported by LVA yet, why not spend some time and help to integrate it?
The process is straight-forward.
- Fork the LVA repository.
- Write the code for your feature or fix.
- Ensure tests pass and linting succeeds (`./script/lint` and `./script/tests`).
- Create a Pull Request against the `main` branch.
## Feature suggestions
If you want to suggest a new feature for LVA, please open a discussion on GitHub.
## Issue Tracker
If you want to report an issue, please create an issue on the repository.
## AI Policy
Linux Voice Assistant is an [Open Home Foundation](https://www.openhomefoundation.org/) project and follows the [OHF AI Policy](https://github.com/music-assistant/.github/blob/main/AI_POLICY.md). Please read it before submitting AI-assisted contributions. The TLDR: AI tools are allowed, but a human is responsible and must review and understand every change. Autonomous agents and unreviewed AI output will be rejected.
+1
View File
@@ -0,0 +1 @@
custom: https://www.openhomefoundation.org
+14
View File
@@ -0,0 +1,14 @@
blank_issues_enabled: false
contact_links:
- name: "🐛 Report a bug"
url: https://github.com/OHF-Voice/linux-voice-assistant/issues/new?template=bug_report.md
about: Report bugs in the Linux Voice Assistant.
- name: "💬 Discord community & support"
url: https://discord.com/channels/330944238910963714/1464387232201703547
about: Chat with the community and get help from other users.
- name: "❓ Questions & how-to (Q&A)"
url: https://github.com/OHF-Voice/linux-voice-assistant/discussions
about: Ask how-to questions and search previous answers.
- name: "💡 Feature requests & ideas"
url: https://github.com/OHF-Voice/linux-voice-assistant/discussions
about: Suggest and vote on new features and enhancements.
+29
View File
@@ -0,0 +1,29 @@
# What does this implement/fix?
<!-- Quick description and explanation of changes. -->
**Related issue (if applicable):**
- Fixes #<issue number>
## Types of changes
<!--
Tick exactly one box. CI derives the label from the ticked box.
-->
- [ ] Bugfix (non-breaking change which fixes an issue) — `bugfix`
- [ ] New feature (non-breaking change which adds functionality) — `new-feature`
- [ ] Enhancement to an existing feature — `enhancement`
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) — `breaking-change`
- [ ] Refactor (no behaviour change) — `refactor`
- [ ] Documentation only — `documentation`
- [ ] Maintenance / chore — `maintenance`
- [ ] CI / workflow change — `ci`
- [ ] Dependencies bump — `dependencies`
## Checklist
- [ ] The code change is tested and works locally.
- [ ] `./script/lint` passes.
- [ ] `./script/tests` passes, and tests have been added/updated under `tests/` where applicable.
+36
View File
@@ -0,0 +1,36 @@
# Linux Voice Assistant - Copilot Instructions
For comprehensive development guidelines, see [AGENTS.md](../AGENTS.md).
## Quick Reference
**Development Commands:**
```bash
./script/setup --dev # Install dev dependencies
./script/lint # Run all linting checks
./script/tests # Run pytest unit tests
```
## PR Review Standards
### Review Philosophy
- Only comment when confident an issue exists
- Be concise: one sentence per comment when possible
- Focus on actionable feedback, not observations
- When reviewing text, only comment on clarity issues if the text is genuinely confusing or could lead to errors
- If you're uncertain whether something is an issue, don't comment
### What to Analyze
- Code quality and style consistency with the existing codebase
- Potential bugs or issues
- Performance implications
- Blocking IO in async code
- Security concerns
- Test coverage
- Documentation updates if needed
### Project Standards
Respect the project standards as outlined in AGENTS.md. Any deviations must be raised as `[PROBLEM]`.
### PR Title
The PR title must be a functional description of the change. It must NOT contain conventional commit prefixes such as `feat:`, `fix:`, `refactor:`, `chore:`, etc. Labels categorize PRs, not the title. Flag as `[PROBLEM]` if the title uses such prefixes.
+14
View File
@@ -0,0 +1,14 @@
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: daily
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: weekly
groups:
dependencies:
patterns:
- "*"
+87
View File
@@ -0,0 +1,87 @@
name: PR Labels
on:
pull_request_target:
types:
- opened
- edited
- synchronize
- labeled
- unlabeled
- reopened
- ready_for_review
branches:
- main
permissions:
pull-requests: write
jobs:
apply_label:
name: Apply
runs-on: ubuntu-latest
if: github.event.pull_request.user.type != 'Bot'
steps:
- name: 🏷 Apply label from PR description checkbox
uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3
with:
script: |
const known = [
'breaking-change', 'bugfix', 'refactor',
'new-feature', 'enhancement', 'maintenance',
'ci', 'dependencies', 'documentation',
];
const { owner, repo } = context.repo;
const issue_number = context.payload.pull_request.number;
const current = (context.payload.pull_request.labels || [])
.map(l => l.name);
const alreadyLabelled = current.filter(n => known.includes(n));
if (alreadyLabelled.length === 1) {
core.info(
`Skipping: PR already labelled '${alreadyLabelled[0]}'.`
);
return;
}
const body = context.payload.pull_request.body || '';
const re = /^\s*-\s*\[x\][^`\n]*`([^`]+)`/gim;
const ticked = [];
for (const m of body.matchAll(re)) {
const name = m[1];
if (known.includes(name) && !ticked.includes(name)) {
ticked.push(name);
}
}
if (ticked.length === 0) {
core.setFailed(
'No "Types of changes" checkbox is ticked in the PR ' +
'description. Edit the description and tick exactly ' +
'one box so this PR can be release-noted.'
);
return;
}
if (ticked.length > 1) {
core.setFailed(
`Multiple "Types of changes" checkboxes are ticked ` +
`(${ticked.join(', ')}). Tick exactly one.`
);
return;
}
const desired = ticked[0];
for (const name of current) {
if (known.includes(name) && name !== desired) {
await github.rest.issues.removeLabel({
owner, repo, issue_number, name,
}).catch(() => {});
}
}
if (!current.includes(desired)) {
await github.rest.issues.addLabels({
owner, repo, issue_number, labels: [desired],
});
}
+1 -1
View File
@@ -23,4 +23,4 @@ venv/
.env
dev.env
version.txt
version_githash.txt
version_githash.txt
+8
View File
@@ -0,0 +1,8 @@
node_modules
package.json
package-lock.json
pnpm-lock.yaml
bun.lock
yarn.lock
worktrees
agent-manager.json
+14
View File
@@ -0,0 +1,14 @@
# Lint Command
Runs all linting checks for the project (black, isort, flake8, mypy, pylint).
## Usage
```
/lint # Run all linting checks
/lint --auto # Auto-fix formatting issues (black, isort)
```
## Command
./script/lint
+14
View File
@@ -0,0 +1,14 @@
# Run Command
Runs the Linux Voice Assistant application.
## Usage
```
/run # Run the application
/run --help # Show CLI help
```
## Command
./script/run
+14
View File
@@ -0,0 +1,14 @@
# Setup Command
Installs project dependencies in a virtual environment.
## Usage
```
/setup # Install dependencies
/setup --dev # Install dev dependencies (linting, testing tools)
```
## Command
./script/setup
+15
View File
@@ -0,0 +1,15 @@
# Test Command
Runs the pytest unit tests for the project.
## Usage
```
/tests # Run all tests
/tests <path> # Run tests in specific path
/tests -k <pattern> # Run tests matching pattern
```
## Command
./script/tests
+70
View File
@@ -0,0 +1,70 @@
# PR Review Standards
## Review Philosophy
- Only comment when confident an issue exists
- Be concise: one sentence per comment when possible
- Focus on actionable feedback, not observations
- When reviewing text, only comment on clarity issues if the text is genuinely confusing or could lead to errors
## What to Analyze
Review all code changes for:
- Code quality and style consistency with the existing codebase
- Potential bugs or issues
- Performance implications
- Blocking IO in async code
- Security concerns
- Test coverage
- Documentation updates if needed
## Project Standards
Respect the project standards as outlined in AGENTS.md. Any deviations must be raised as `[PROBLEM]`.
Key standards for LVA:
- Python 3.11, 3.12, 3.13 supported
- Black formatting with 200 char line length
- isort import sorting with black profile
- mypy type checking with strict settings
- pylint code quality checks (many checks disabled in pyproject.toml)
## Architecture-Specific Checks
- `linux_voice_assistant/wake_word.py` - Wake word model loading is hardware-dependent, verify no assumptions about specific hardware
- `linux_voice_assistant/mpv_player.py` - Audio output requires `libmpv-dev`, check for proper error handling
- `linux_voice_assistant/webrtc.py` - Noise suppression/gain algorithms need careful review for audio quality
- `linux_voice_assistant/satellite.py` - ESPHome API protocol handling must be robust
## CI Context
Lint runs on Python 3.13, tests run on Python 3.12 with libmpv-dev.
### What CI Checks
- **Lint**: `.github/workflows/lint.yml` runs all linting checks
- **Tests**: `.github/workflows/tests.yml` runs pytest unit tests
## Skip These (Low Value)
Do not comment on:
- Style/formatting (pre-commit handles this)
- Test failures (CI catches this)
- Missing dependencies (CI catches this)
- Minor naming suggestions
- Suggestions to add comments
- Logging suggestions unless security-related
## Issue Categories
Categorize every issue as:
- `[CRITICAL]` — must fix before merging (bugs, security issues, broken functionality)
- `[PROBLEM]` — should fix (code quality, bad patterns, missing tests)
- `[SUGGESTION]` — optional improvement (style, minor refactors, nice-to-haves)
## PR Title
The PR title must be a functional description of the change. It must NOT contain conventional commit prefixes such as `feat:`, `fix:`, `refactor:`, `chore:`, etc. Labels categorize PRs, not the title. Flag as `[PROBLEM]` if the title uses such prefixes.
+44
View File
@@ -0,0 +1,44 @@
name: review-pr
description: Use when asked to review a GitHub pull request, PR link is shared, or user says /review-pr
# Review GitHub Pull Request
Review the GitHub pull request: $ARGUMENTS.
## Steps
1. Run `gh pr view` to get PR details and description.
2. Run `gh pr diff` to see all changes.
3. Compare the local commit hash with the remote PR head commit.
- Make sure to do your work in a git worktree to avoid affecting the checked out branch.
- If they don't match, run `gh pr checkout` to check out the PR locally.
- **HARD STOP**: If `gh pr checkout` fails for ANY reason, STOP immediately. Do NOT attempt workarounds. Alert about the failure and wait for instructions.
- After checkout, verify the local commit hash matches the remote one. If they still don't match, STOP.
4. Run `gh pr checks` to see CI status.
5. Apply the review standards defined in `REVIEW_STANDARDS.md` (same directory).
6. Output review feedback to the CONSOLE only. DO NOT act on GitHub (no posting comments, no approving, no requesting changes).
## Output Format
List specific comments per file/line that need attention. Do not list things that are already correct.
Each comment:
1. State the severity ([CRITICAL], [PROBLEM], [SUGGESTION])
2. State the problem (1 sentence)
3. Why it matters (1 sentence, if needed)
4. Suggested fix (snippet or specific action)
End with an overall assessment and summary:
```
Overall assessment: <approve | request changes | comment>
- [CRITICAL] <issue>
- [PROBLEM] <issue>
- [SUGGESTION] <improvement>
```
## Constraints
- DO NOT make any changes to the code.
- No need to run tests or linters, just review the code changes.
+7
View File
@@ -0,0 +1,7 @@
{
"recommendations": [
"ms-python.python",
"ms-python.vscode-pylance",
"kilo.kilocode"
]
}
+14
View File
@@ -0,0 +1,14 @@
{
"version": "0.2.0",
"configurations": [
{
"name": "Run Linux Voice Assistant",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/linux_voice_assistant/__main__.py",
"console": "integratedTerminal",
"justMyCode": true,
"envFile": "${workspaceFolder}/.env"
}
]
}
+13
View File
@@ -0,0 +1,13 @@
{
"python.defaultInterpreterPath": "./.venv/bin/python",
"python.testing.pytestEnabled": true,
"python.testing.pytestArgs": ["tests"],
"python.testing.pytestAutoInclude": false,
"python.linting.enabled": true,
"python.linting.flake8Enabled": true,
"python.linting.mypyEnabled": true,
"python.formatting.provider": "none",
"python.terminal.activateEnvironment": true,
"python.terminal.executeInShell": true,
"python.pythonPath": "./.venv/bin/python"
}
+62
View File
@@ -0,0 +1,62 @@
{
"version": "2.0.0",
"tasks": [
{
"label": "Setup (incl. dev dependencies)",
"type": "shell",
"command": "./script/setup --dev",
"group": "build",
"presentation": {
"echo": true,
"reveal": "always",
"focus": false,
"panel": "new",
"clear": true
},
"problemMatcher": []
},
{
"label": "Run Linter",
"type": "shell",
"command": "./script/lint",
"group": "build",
"presentation": {
"echo": true,
"reveal": "always",
"focus": false,
"panel": "new"
},
"problemMatcher": []
},
{
"label": "Run Tests",
"type": "shell",
"command": "./script/tests",
"group": "test",
"presentation": {
"echo": true,
"reveal": "always",
"focus": false,
"panel": "new"
},
"problemMatcher": []
},
{
"label": "Run Application (Docker)",
"type": "shell",
"command": "docker-compose",
"args": ["-f", "docker-compose.dev.yml", "up"],
"group": "none",
"presentation": {
"echo": true,
"reveal": "always",
"focus": false,
"panel": "new"
},
"problemMatcher": [],
"options": {
"envFile": "${workspaceFolder}/.env"
}
}
]
}
+129
View File
@@ -0,0 +1,129 @@
# Project Context for AI Agents
## Behaviour
- NEVER automatically reply on Github (PRs or Discussions) without explicit consent from the developer.
- Always run `./script/lint` and `./script/tests` after code changes to ensure standards are met.
## Project Overview
**Linux Voice Assistant (LVA)** - A Linux-based voice satellite software for Home Assistant using the ESPHome protocol.
### Purpose
- Provides voice control and interaction for Home Assistant via the Assist integration
- Runs on x64/ARM64 Linux hardware with PulseAudio/PipeWire audio support
- Performs local wake word detection (OpenWakeWord/MicroWakeWord) and on-device processing
### Architecture
- **Protocol**: ESPHome API via `aioesphomeapi` for Home Assistant integration
- **Wake Words**: Supports both OpenWakeWord and MicroWakeWord engines
- **Audio**: Uses `soundcard` library for input, `python-mpv` for output
- **Peripherals**: WebSocket API for LEDs, buttons, HAT boards
- **Discovery**: mDNS/ZeroConf for auto-discovery by Home Assistant
### Key Components
- `linux_voice_assistant/__main__.py` - Main entry point with CLI argument parsing
- `linux_voice_assistant/satellite.py` - VoiceSatelliteProtocol implementation (ESPHome API)
- `linux_voice_assistant/wake_word.py` - Wake word model loading and detection
- `linux_voice_assistant/webrtc.py` - WebRTC noise gain/NS processing
- `linux_voice_assistant/mpv_player.py` - MPV-based media player
- `linux_voice_assistant/entity.py` - Entity definitions (MediaPlayer, MuteSwitch, etc.)
- `linux_voice_assistant/api_server.py` - Peripheral WebSocket API server
- `linux_voice_assistant/models.py` - Preferences and ServerState dataclasses
## Development Commands
### Setup
```bash
./script/setup --dev # Install dev dependencies in virtual environment
```
### Linting
```bash
./script/lint # Run all linting checks
./script/lint_black # Black formatting check (add --auto to fix)
./script/lint_isort # isort import sorting check (add --auto to fix)
./script/lint_flake8 # flake8 style checks
./script/lint_mypy # mypy type checking
./script/lint_pylint # pylint code quality checks
```
### Testing
```bash
./script/tests # Run pytest unit tests
```
## Code Quality Standards
- **Python**: 3.11, 3.12, 3.13 supported
- **Formatting**: Black (200 char line length, py312/py312 target)
- **Import Sorting**: isort with black profile
- **Type Checking**: mypy with strict settings
- **Linting**: pylint (many checks disabled in pyproject.toml for practical reasons)
## Testing Strategy
- Unit tests in `tests/unit/` using pytest with asyncio mode
- Test helper `make_state()` in `tests/unit/conftest.py` for creating state fixtures
- Mocks used heavily for hardware dependencies (audio devices, MPV, wake words)
## CI/CD
- GitHub Actions for lint checks and unit tests
- Tests run on Python 3.12 with libmpv-dev system dependency
- Lint runs on Python 3.13
## Branching and PRs
- All PRs target `main` (primary development branch). `stable` is for production releases.
- PRs labeled `bugfix` + `backport-to-stable` are automatically backported to `stable` — use only for bugs also present in `stable`.
## Agent Commands
When making code changes, run these commands in order:
1. **Format code**: `./script/lint_black --auto` and `./script/lint_isort --auto`
2. **Run linting**: `./script/lint`
3. **Run tests**: `./script/tests`
## Code Style
### Comments
Only use comments to explain complex, multi-line blocks of code. Do not comment obvious operations. Inline comments are there to explain code parts that need explaining - keep them when editing code.
### Docstring Format
Use Sphinx-style docstrings with `:param:` syntax. For simple functions, a single-line docstring is fine. The docstring should provide clarity to the caller, not explain how it works technically.
```python
def my_function(param1: str, param2: int, param3: bool = False) -> str:
"""
Brief one-line description of the function.
:param param1: Description of what param1 is used for.
:param param2: Description of what param2 is used for.
:param param3: Description of what param3 is used for.
"""
```
Do **not** use Google-style (`Args:`) or bullet-style (`- param:`) docstrings.
### File structure
Private methods should be at the bottom of the file, public at the top.
## Verification Checklist
Before claiming completion:
- [ ] Ran `./script/lint` - all checks passed
- [ ] Ran `./script/tests` - all tests passed
- [ ] For audio-related changes: Note that hardware testing (microphone/speaker) was NOT performed
- [ ] Did NOT claim hardware behavior is verified unless actually exercised
- [ ] Changes are focused on one feature or fix per change
## Areas Requiring Extra Care
- `linux_voice_assistant/wake_word.py` - Wake word model loading is hardware-dependent
- `linux_voice_assistant/mpv_player.py` - Audio output requires `libmpv-dev`
- `linux_voice_assistant/webrtc.py` - Noise suppression/gain algorithms
- `linux_voice_assistant/satellite.py` - ESPHome API protocol handling
+30
View File
@@ -131,6 +131,36 @@ The documentation for the build process can be found in the [GitHub Actions Work
## Development
### System Requirements
**System packages (Linux):**
- libmpv-dev (`sudo apt install libmpv-dev`)
- PulseAudio/PipeWire (`sudo apt install pulseaudio pipewire`)
- ALSA utils (`sudo apt install alsa-utils`)
**Python:**
- Python 3.11+ must be installed on your system (`python3 --version` should show 3.11+)
- On Ubuntu/Debian: `sudo apt install python3.11 python3.11-venv python3.11-dev`
### VS Code Setup
VS Code development uses a local Python virtual environment (`.venv/`):
1. Open workspace in VS Code
2. Accept Workspace Trust (bottom-left status bar)
3. Install recommended extensions when prompted:
- `ms-python.python` - Python language support
- `ms-python.vscode-pylance` - Python language server
- `kilo.kilocode` - Kilo AI assistant
4. **Terminal** → **New Terminal** (or `` Ctrl+` ``) - Opens integrated terminal (uses .venv when available)
5. Run `./script/setup --dev` to create `.venv` and install dev dependencies
6. VS Code automatically detects `.venv/bin/python` as the Python interpreter
**Available VS Code Tasks:**
- `Ctrl+Shift+B` - Run Setup or Linter
- `Ctrl+Shift+T` - Run Tests
- `Ctrl+Shift+P` → "Tasks: Run Task" - Show all tasks (Setup, Linter, Tests, Run App)
### Code Quality Checks
The project uses the following tools to ensure code quality:
+20 -18
View File
@@ -145,26 +145,28 @@ fi
### Wait for PulseAudio
# Wait for PulseAudio to be available before starting the application
CP_MAX_RETRIES=30
CP_RETRY_DELAY=1
### while maybe besser?
echo "Checking PulseAudio service status..."
for i in $(seq 1 $CP_MAX_RETRIES); do
# Check if PulseAudio is running
if pactl info >/dev/null 2>&1; then
echo "✅ PulseAudio is running"
break
fi
# Skip wait if SKIP_PULSE_AUDIO_WAIT is set (for local development)
if [ "$SKIP_PULSE_AUDIO_WAIT" != "1" ]; then
CP_MAX_RETRIES=30
CP_RETRY_DELAY=1
### while maybe besser?
echo "Checking PulseAudio service status..."
for i in $(seq 1 $CP_MAX_RETRIES); do
# Check if PulseAudio is running
if pactl info >/dev/null 2>&1; then
echo "✅ PulseAudio is running"
break
fi
if [ $i -eq $CP_MAX_RETRIES ]; then
echo "❌ PulseAudio did not start after $CP_MAX_RETRIES seconds"
exit 2
fi
if [ $i -eq $CP_MAX_RETRIES ]; then
echo "❌ PulseAudio did not start after $CP_MAX_RETRIES seconds"
exit 2
fi
echo "⏳ PulseAudio not running yet, retrying in $CP_RETRY_DELAY s..."
sleep $CP_RETRY_DELAY
done
echo "⏳ PulseAudio not running yet, retrying in $CP_RETRY_DELAY s..."
sleep $CP_RETRY_DELAY
done
fi
### Start application
+11
View File
@@ -0,0 +1,11 @@
{
"$schema": "https://app.kilo.ai/config.json",
"model": "kilo/codegemma-2b:free",
"permission": {
"bash": "allow",
"read": {
"*": "ask"
}
},
"instructions": ["AGENTS.md"]
}
+7
View File
@@ -0,0 +1,7 @@
{
"folders": [
{
"path": "."
}
]
}
+45 -7
View File
@@ -1,8 +1,10 @@
#!/usr/bin/env python3
import argparse
import subprocess
import venv
import os
import shutil
import sys
import ctypes.util
from pathlib import Path
_DIR = Path(__file__).parent
@@ -15,10 +17,47 @@ parser.add_argument("--cxxflags", type=str, help="CXXFLAGS for compilation (defa
parser.add_argument("--makeflags", type=str, help="MAKEFLAGS for compilation (default: -j1)")
args = parser.parse_args()
# Find Python 3.11+ interpreter
def find_python_311():
for candidate in ["python3.13", "python3.12", "python3.11"]:
path = shutil.which(candidate)
if path:
result = subprocess.run([path, "--version"], capture_output=True, text=True)
version_str = result.stdout.strip() or result.stderr.strip()
ver_parts = version_str.replace("Python ", "").split(".")
if len(ver_parts) >= 2 and int(ver_parts[0]) == 3 and int(ver_parts[1]) >= 11:
return path
return None
python_311_exe = find_python_311()
if not python_311_exe:
print("ERROR: Python 3.11+ is required but not found on this system.")
print(" Ubuntu/Debian: sudo apt install python3.11 python3.11-venv python3.11-dev")
print(" macOS: brew install python@3.11")
sys.exit(1)
print(f"Using Python: {python_311_exe}")
subprocess.run([python_311_exe, "--version"])
# Check system dependencies (warning only, CI installs them separately)
missing = []
try:
if not ctypes.util.find_library("mpv"):
missing.append("libmpv-dev")
if not ctypes.util.find_library("asound"):
missing.append("libasound2-dev")
except Exception:
pass # Ignore errors in environments without ctypes
if missing:
print(f"\nWARNING: Missing system libraries (required for audio): {', '.join(missing)}")
print("For Docker/local dev: sudo apt install libmpv-dev pulseaudio pipewire alsa-utils")
# Create virtual environment
builder = venv.EnvBuilder(with_pip=True)
context = builder.ensure_directories(_VENV_DIR)
builder.create(_VENV_DIR)
if _VENV_DIR.exists():
shutil.rmtree(_VENV_DIR)
subprocess.check_call([python_311_exe, "-m", "venv", str(_VENV_DIR), "--symlinks"])
# Set environment variables
env = {}
@@ -28,17 +67,16 @@ if args.makeflags:
env["MAKEFLAGS"] = args.makeflags
# Upgrade dependencies
pip = [context.env_exe, "-m", "pip"]
pip = [str(_VENV_DIR / "bin" / "python"), "-m", "pip"]
subprocess.check_call(pip + ["install", "--upgrade", "pip"])
subprocess.check_call(pip + ["install", "--upgrade", "setuptools", "wheel"])
# Install requirements
subprocess.check_call(pip + ["install", "-e", str(_PROGRAM_DIR)])
# Install dev requirements
if args.dev:
subprocess.check_call(
pip + ["install", "-e", f"{_PROGRAM_DIR}[dev]"],
env={**dict(os.environ), **env}
)
)
+29
View File
@@ -0,0 +1,29 @@
# PR Review Workflow for Linux Voice Assistant
## Review Procedure
When reviewing a PR, follow this checklist:
### 1. Understanding the Change
- Identify the files modified and their purpose
- Check if changes align with project architecture
- Verify no unrelated rewrites are suggested
### 2. Bug Detection
- Check for logic errors in `satellite.py`, `wake_word.py`, `webrtc.py`
- Verify type safety (mypy compliance)
- Check for proper error handling
### 3. Testing
- Verify tests exist for changed code
- Check that `./script/tests` passes
- Note if hardware-dependent code lacks simulation
### 4. Areas Requiring Extra Care
- `linux_voice_assistant/wake_word.py` - hardware-dependent
- `linux_voice_assistant/mpv_player.py` - requires libmpv-dev
- `linux_voice_assistant/webrtc.py` - noise suppression algorithms
- `linux_voice_assistant/satellite.py` - ESPHome API protocol
### 5. Output Format
Keep summary concise, cite file:line numbers, mention test coverage.
@@ -0,0 +1,20 @@
# Completion Receipt Template
```
subject: {CHANGE_DESCRIPTION}
files_modified:
- {FILES_MODIFIED}
checks_run:
- {CHECKS_RUN}
not_checked:
- {NOT_CHECKED}
verdict: pass | fail | incomplete
reason: {REASON}
```
## Verification Checklist
- [ ] Ran `./script/lint` - all checks passed
- [ ] Ran `./script/tests` - all tests passed
- [ ] For audio-related changes: Note hardware testing NOT performed
- [ ] Did NOT claim hardware behavior verified unless exercised
- [ ] Changes focused on one feature or fix
@@ -0,0 +1,16 @@
# PR Review - Output Template
## Summary
{BRIEF_SUMMARY}
## Issues Found
| File | Line | Issue | Severity |
|------|------|-------|----------|
{
"subject": "PR review",
"files_reviewed": [{FILES_REVIEWED}],
"checks_run": [{CHECKS_RUN}],
"not_checked": [{NOT_CHECKED}],
"verdict": "pass | fail | incomplete",
"reason": "{REASON}"
}
+18
View File
@@ -0,0 +1,18 @@
# PR Review Verification
When reviewing PRs, explicitly state what was and wasn't verified:
## Required Evidence
- Lines changed and why
- Tests touched or added
- Linter/type checks run
## Common Gaps to Note
- Hardware/audio paths not tested
- Integration behavior not verified
- Performance implications not measured
## Outcome Labels
- **pass**: All checks passed, no issues found
- **fail**: Issues found that block merge
- **incomplete**: Changes look correct but some verification gaps exist