Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions AGENTS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Contributor agent guide

VidXP is a Python application with CLI, HTTP, MCP, and Desktop surfaces that
share the same application contracts. Read
[`docs/CONTRIBUTING.md`](docs/CONTRIBUTING.md) before making changes.

## Working in the repository

- Keep pull requests focused on one outcome and preserve unrelated work.
- Put shared behavior in the application or control plane; keep CLI, HTTP,
MCP, and Desktop code as thin adapters.
- Keep capability-specific models, schemas, dependencies, indexing, and search
logic under `src/vidxp/capabilities/`.
- Do not commit generated environments, model weights, media, indexes, build
outputs, or local data.
- Follow the Conventional Commit and release-note rules in the contributing
guide. State explicitly when a change is internal-only.

## Validation

Run the smallest relevant checks while developing, then the applicable checks
from the contributing guide before submitting a pull request. Common checks:

```bash
uv run --no-sync ruff check .
uv run --no-sync pytest -q
npm --prefix desktop run check
```

Do not describe mocked tests as end-to-end validation. Report the exact
commands run and any required validation that could not be completed.
14 changes: 14 additions & 0 deletions CODEX.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# Codex contributor notes

Start with [`AGENTS.md`](AGENTS.md) and
[`docs/CONTRIBUTING.md`](docs/CONTRIBUTING.md).

1. Inspect the affected implementation, shared contracts, and existing tests.
2. Make the smallest coherent change at the correct architecture boundary.
3. Reuse repository tooling and generated-file workflows instead of manually
recreating derived artifacts.
4. Run validation appropriate to the changed surface.
5. Summarize the outcome, exact validation performed, and remaining risks.

Ask before introducing a new dependency, migration, public contract change, or
architecture direction that is not already established by the repository.