satoru/AGENTS.md

57 lines
1.6 KiB
Markdown

# Satoru Agent Notes
## Project Intent
Satoru is a restic-based backup control plane for Linux hosts over SSH.
Core model:
1. Satoru pulls from edge hosts (no direct edge->B2 writes).
2. Stages data locally.
3. Runs restic locally for deduplicated snapshots.
4. Syncs restic data to B2 (scheduled).
## Current Direction
1. Background job execution for site operations.
2. Preflight-first workflow before full backup runs.
3. Strong operational visibility through structured logs and job events.
## Run The Server
```bash
cd /Users/peterli/git/satoru
go run ./cmd/satoru
```
Default URL:
- `http://localhost:8080`
## Logging
Satoru uses structured logging and supports:
1. `LOG_FORMAT=console|json` (default `json`)
2. `LOG_LEVEL=debug|info|warn|error` (default `info`)
3. `LOG_FILE=/path/to/file.log` (optional; logs still go to stdout)
Examples:
```bash
LOG_FORMAT=console LOG_LEVEL=debug go run ./cmd/satoru
```
```bash
LOG_FORMAT=json LOG_LEVEL=debug LOG_FILE=./logs/satoru.log go run ./cmd/satoru
tail -f ./logs/satoru.log | jq
```
## Debug Logging Expectation
Be proactive with debug-level logging for:
1. DB state changes (job/site/session mutations).
2. Job lifecycle transitions and step boundaries.
3. Scan and backup target-level decisions/results.
4. External command start/finish, duration, and failures.
Logs should include useful identifiers where possible:
- `job_id`, `site_id`, `job_type`, `target_path`, `target_mode`, `status`, `error`.
## Data Safety
Do not delete `data/satoru.db` during normal development, smoke checks, or troubleshooting.
Use forward migrations to evolve schema/data for soft-launched deployments.