Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
79cc2a12a9 | ||
|
|
0ec78567a6 | ||
|
|
2c38f5f46a | ||
|
|
f750b83a2c | ||
|
|
dd1d5faff6 | ||
|
|
ff2c213e41 | ||
|
|
e9a9e1090b | ||
|
|
65e90dac55 | ||
|
|
8ad701db32 |
No files matched your search
@@ -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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1 @@
|
||||
custom: https://www.openhomefoundation.org
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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:
|
||||
- "*"
|
||||
@@ -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
@@ -23,4 +23,4 @@ venv/
|
||||
.env
|
||||
dev.env
|
||||
version.txt
|
||||
version_githash.txt
|
||||
version_githash.txt
|
||||
@@ -0,0 +1,8 @@
|
||||
node_modules
|
||||
package.json
|
||||
package-lock.json
|
||||
pnpm-lock.yaml
|
||||
bun.lock
|
||||
yarn.lock
|
||||
worktrees
|
||||
agent-manager.json
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
Vendored
+7
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"recommendations": [
|
||||
"ms-python.python",
|
||||
"ms-python.vscode-pylance",
|
||||
"kilo.kilocode"
|
||||
]
|
||||
}
|
||||
Vendored
+14
@@ -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"
|
||||
}
|
||||
]
|
||||
}
|
||||
Vendored
+13
@@ -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"
|
||||
}
|
||||
Vendored
+62
@@ -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"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -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
|
||||
@@ -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
@@ -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
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"$schema": "https://app.kilo.ai/config.json",
|
||||
"model": "kilo/codegemma-2b:free",
|
||||
"permission": {
|
||||
"bash": "allow",
|
||||
"read": {
|
||||
"*": "ask"
|
||||
}
|
||||
},
|
||||
"instructions": ["AGENTS.md"]
|
||||
}
|
||||
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"folders": [
|
||||
{
|
||||
"path": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
+45
-7
@@ -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}
|
||||
)
|
||||
)
|
||||
@@ -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}"
|
||||
}
|
||||
@@ -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
|
||||
Reference in new issue
Block a user