Add claude instruction files

Author: filippomc

CLAUDE.md

@@ -0,0 +1,66 @@
+# Cloud Harness
+
+Cloud Harness provides software infrastructure and tools for neuroscience data computing and analysis in a monorepo.
+
+## Repository Layout
+
+- `applications/` — Cloud Harness custom server applications
+- `client/` — generated client API
+- `deployment/` — deployment-related scripts and files
+- `deployment-configuration/` — deployment customization files
+- `infrastructure/` — infrastructure utilities
+- `libraries/` — Cloud Harness shared libraries
+- `docs/` — developer documentation
+- `tools/` — Cloud Harness CLI and other tools
+- `test/` — test utilities and test code
+
+Before working on a task, identify which application/component is in scope and read any `CLAUDE.md` inside that subtree.
+
+## Environment Setup
+
+- **Conda environment**: `ch` (Python 3.12+) — activate with `conda activate ch`
+- **Frontend package manager**: Yarn — **never** use npm
+- **Backend package manager**: pip — only inside the conda environment
+
+Always activate `conda activate ch` before any backend command.
+
+## Development Principles
+
+- Configuration lives in `values.yaml` files and is injected via Helm templates and Kubernetes manifests. Never hardcode configuration in application code or templates.
+- Structured configuration can be injected via resources processed by Helm templates and loaded as ConfigMaps automatically (e.g. `applications/accounts/deploy/resources/realm.json`).
+- The Cloud Harness configuration API is defined as an [OpenAPI spec](libraries/models/api/openapi.yaml). Run `harness-generate models` after changing the spec.
+
+## Code Style
+
+- Keep architecture lean — avoid unnecessary layers and abstractions.
+- Use **utils** for stateless pure functions that don't touch external data sources or the ORM.
+- Use **helpers** for pieces of business logic; keep them stateless when possible.
+- Use **services** for business workflows and cross-model coordination.
+- Keep model logic close to the model when it represents domain rules or invariants.
+- Handle exceptions only at the highest level; let lower layers raise. Never catch in helpers or services unless adding context and re-raising.
+- Cover critical logic with unit tests, especially helpers and services. Use mocks to isolate units.
+- Prefer model classes for helpers and services. Use typed dicts for structured data not covered by schema classes. Use plain dicts only for genuinely unstructured data. Avoid returning tuples.
+- Bubble exceptions up to where they can be handled. Avoid return-value error signalling. Wrap library and untyped exceptions in custom exceptions with clear meaning.
+
+## Important Constraints
+
+- **Never** create README or documentation files unless explicitly requested.
+- **Never** start development servers — assume they are already running.
+- **Always** ask before opening a browser.
+- **Frontend**: Yarn only. **Backend**: pip inside the `ch` conda environment only.
+
+
+# Using Cloudharness CLI Tools
+
+## Environment
+- Activate `conda activate ch` before any backend command.
+- Run `sh install.sh` to install cli tools
+
+## Key Scripts
+
+- `harness-generate` — generate code
+- `harness-deployment` — generate deployment files (Helm charts, CI/CD files, etc.)
+- `harness-application` — generate application code (e.g. Django apps)
+- `harness-migrate` — migration helper
+- `ch_cli_tools` — Python package for deployment and other tools
+- `tests/` — unit test utilities

test/e2e/CLAUDE.md

@@ -0,0 +1,19 @@
+# E2E Tests
+
+**Framework**: Jest + Puppeteer. Follow patterns in existing `*.spec.ts` files.
+
+## Login Flow
+
+Tests that point `APP_URL` at the accounts domain must handle the 2-step login redirect:
+
+1. Navigate to `APP_URL` and detect the redirect to accounts.
+2. Enter the username from `USERNAME`, submit, wait for the password field.
+3. Enter the password from `PASSWORD`, submit.
+4. Wait for redirect back to the app and confirm the expected route.
+
+## Stability Requirements
+
+- **Waits**: always use explicit Puppeteer waits (`waitForSelector`, `waitForFunction`, `waitForNavigation`) with timeouts.
+- **Selectors**: use stable custom selectors from `test/e2e/selectors.ts`. Never depend on UI copy, text content, or fragile DOM structure.
+- **No fixed sleeps** unless there is no deterministic signal — prefer state-based waits.
+- **Resilience**: guard against flaky overlays (cookie/announcement modals) where possible.

tools/deployment-cli-tools/CLAUDE.md

@@ -0,0 +1,32 @@
+# Deployment CLI Tools
+
+## Environment
+
+- Activate `conda activate ch` before any backend command.
+- Use pip (inside `ch`) for backend dependencies; Yarn for any frontend work.
+
+## Key Scripts
+
+- `harness-generate` — generate code
+- `harness-deployment` — generate deployment files (Helm charts, CI/CD files, etc.)
+- `harness-application` — generate application code (e.g. Django apps)
+- `harness-migrate` — migration helper
+- `ch_cli_tools` — Python package for deployment and other tools
+- `tests/` — unit test utilities
+
+## Code Style
+
+Follow the project-wide style in the root [CLAUDE.md](../../CLAUDE.md). Key points for this package:
+
+- Keep architecture lean — avoid unnecessary layers and abstractions.
+- Utils: stateless pure functions, no ORM or external data sources.
+- Helpers: stateless business logic pieces.
+- Services: business workflows and cross-model coordination.
+- Bubble exceptions up; never swallow them silently in helpers or services.
+- Cover critical logic with unit tests using mocks to isolate units.
+
+## Constraints
+
+- Never start development servers.
+- Never create documentation files unless explicitly asked.
+- Always use pip inside `ch` conda env; never use npm.