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
71 changes: 33 additions & 38 deletions CLAUDE.md
Original file line number Diff line number Diff line change
@@ -1,51 +1,46 @@
# Claude Code Guidelines for OpenAdapt

## Repository Overview
This is the main OpenAdapt meta-package repository. It provides a unified CLI that coordinates sub-packages:
## Repository role

- `openadapt-capture` - GUI recording
- `openadapt-ml` - ML training/inference
- `openadapt-evals` - Benchmark evaluation
- `openadapt-viewer` - HTML visualization
- `openadapt-grounding` - UI element localization
- `openadapt-retrieval` - Multimodal retrieval
- `openadapt-privacy` - PII/PHI scrubbing
This public repository is the Beta launcher/meta-package and stable community
entry point for OpenAdapt. It owns `pip install openadapt`, the unified
`openadapt` CLI, release compatibility, and launcher packaging.

## Important Rules
The canonical compiler and governed runtime live in
[`OpenAdaptAI/openadapt-flow`](https://github.com/OpenAdaptAI/openadapt-flow).
Engine, replay, verification, repair, policy, and backend changes belong there;
do not implement a second engine in this repository.

### Always Use Pull Requests
**NEVER push directly to the `main` branch.** Always create a feature branch and submit a PR, even for small changes.
The current product compiles demonstrated GUI workflows into deterministic,
locally executable programs. Healthy runs make no model calls. Training,
retrieval, and general computer-use agents are separate research surfaces.

```bash
# Create a new branch
git checkout -b feature/my-change
## Before changing the repository

# Make changes and commit
git add .
git commit -m "Description of change"
1. Read the workspace `AGENTS.md` and current `STATUS.md` when available.
2. Fetch `origin` and base findings and changes on fresh `origin/main`.
3. Read [README.md](README.md) and [CONTRIBUTING.md](CONTRIBUTING.md).
4. Keep public installation centered on `pip install openadapt` and
`openadapt ...`; `openadapt-flow` remains the contributor/engine package.
5. Preserve local-first use, fail-closed execution, and the open-core boundary.

# Push branch and create PR
git push -u origin feature/my-change
gh pr create --title "Title" --body "Description"
```
## Repository layout

- `openadapt/`: launcher package and unified CLI
- `tests/`: launcher, integration-seam, and release-artifact tests
- `legacy/`: frozen pre-1.0 monolith
- `docs/`: noncanonical historical repository documentation;
docs.openadapt.ai is maintained in `OpenAdaptAI/openadapt-ops`
- `.github/`: CI, security, dependency, and release workflows

Branch protection is configured but can be bypassed by admins - don't do it.
## Development and delivery

### Development Setup
```bash
pip install -e ".[dev]"
python -m pip install -e '.[dev]'
pytest
ruff check openadapt tests
```

### Key Directories
- `src/openadapt/` - Main package code (CLI, lazy imports)
- `docs/` - Documentation (architecture, permissions guide)
- `legacy/` - Archived monolithic codebase (v0.46.0)
- `.github/` - CI/CD workflows, issue templates

### Release Process
Releases are automated via GitHub Actions using python-semantic-release.
Tag format: `vX.Y.Z`

## Related Repositories
- Website: https://github.com/OpenAdaptAI/openadapt-web
- All sub-packages: https://github.com/OpenAdaptAI/openadapt-*
Use a focused branch and pull request for every change. Do not push directly to
`main`. Releases are performed only through the reviewed GitHub Actions release
workflow after explicit authorization; never publish from a development task.
46 changes: 27 additions & 19 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,20 +2,15 @@

Thank you for your interest in contributing to OpenAdapt!

## Current Product Boundary
## Product boundary

`OpenAdaptAI/OpenAdapt` is the Beta launcher/meta-package and compatibility
surface. The canonical compiler and governed runtime live in
[`openadapt-flow`](https://github.com/OpenAdaptAI/openadapt-flow). New engine,
replay, repair, policy, and backend work belongs there.

| Lifecycle | Repositories | Contribution scope |
|-----------|--------------|--------------------|
| **Beta product** | `OpenAdapt`, `openadapt-flow` | Launcher here; engine in `openadapt-flow` |
| **Experimental support** | `openadapt-capture`, `openadapt-privacy`, `openadapt-desktop` | Native capture, scrubbing, and authoring surfaces |
| **Agent integration** | `openadapt-agent` | MCP and Agent Skills bridge over governed Flow bundles |
| **Research** | `openadapt-ml`, `openadapt-evals`, `openadapt-grounding`, `openadapt-retrieval` | GUI-agent research and evaluation, not the product runtime |
| **Deprecated/history** | `legacy/`, pre-v2 `openadapt-agent` | Migration fixes only; no new features |
This repository's lifecycle is **Beta**. Each sibling repository publishes its
own lifecycle status; do not infer that status from package availability here.

## Where to Contribute

Expand All @@ -27,21 +22,34 @@ replay, repair, policy, and backend work belongs there.
- **Other repositories**: open issues only when their stated lifecycle and
contribution guide match the proposed work.

## Getting Started
## Getting started

1. Fork the repository
2. Clone your fork
3. Install in development mode: `pip install -e ".[dev]"`
4. Create a branch for your changes
5. Make your changes and test locally
6. Submit a pull request
1. Fork and clone the repository.
2. Create a focused branch from current `origin/main`.
3. Install the launcher in development mode:

```bash
python -m pip install -e '.[dev]'
```

4. Run the focused test suite and formatting checks:

```bash
pytest
ruff check openadapt tests
```

5. Open a pull request. The pull-request template lists the required release
and source-boundary checks.

## Guidelines

- Follow existing code style
- Add tests for new functionality
- Update documentation as needed
- Keep PRs focused and small
- Follow the existing code style.
- Test durable behavior and package contracts rather than ordinary copy.
- Keep changes focused and update the canonical documentation when behavior
changes.
- Never place customer-derived data, deployment recipes, or secrets in a public
fixture or package artifact.

## Licensing and the open-core boundary

Expand Down
Loading