# MeetVault — Agent Guide

## Repo layout

```text
MeetVault/
├── Overview/          # Architecture docs, schema, data flow
│   └── README.md
├── Wireframes/         # Desktop client design notes
│   └── Desktop/
│       ├── Desktop_README.md
│       └── Desktop-Demo/  # Runnable Tauri + React demo
│           └── speech-engine/  # Local Whisper transcription engine
```

## Core architecture (remember this)

- **User machine**: records audio/video, runs local Whisper for STT, sends transcript to backend. Keeps compute and cost on the device.
- **Backend API**: auth, meeting metadata, presigned upload URLs, transcript ingestion, summarization jobs, task extraction, reminder scheduling.
- **PostgreSQL**: structured app data + `processing_jobs` table used as a job queue (no external broker needed for MVP).
- **SeaweedFS**: S3-compatible object storage for large media files.

## PostgreSQL gotchas

### Enable UUID generation first

```sql
CREATE EXTENSION IF NOT EXISTS pgcrypto;
```

### Always set `updated_at` manually

PostgreSQL does not auto-update it. Create a shared trigger function and apply to every table that tracks changes:

```sql
CREATE OR REPLACE FUNCTION set_updated_at()
  RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = NOW();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- then attach per-table triggers, e.g.:
CREATE TRIGGER trg_meetings_updated_at
  BEFORE UPDATE ON meetings FOR EACH ROW EXECUTE FUNCTION set_updated_at();
```

### Job queue pattern (no external broker)

Workers pick jobs with this exact query:

```sql
SELECT *
FROM processing_jobs
WHERE status = 'queued'
  AND available_at <= NOW()
ORDER BY priority DESC, created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;
```

Key indexes for workers:

```sql
CREATE INDEX idx_schedules_due ON meeting_schedules(status, scheduled_at);
CREATE INDEX idx_processing_jobs_queue ON processing_jobs(status, available_at, priority DESC);
```

### SeaweedFS object paths

Files live under: `meeting-storage/users/{user_id}/meetings/{meeting_id}/original/`

## Testing flow

1. Run the desktop demo locally (Tauri + React) to verify UI and local transcription without backend dependencies.
2. Spin up PostgreSQL, run the schema SQL from `Overview/README.md`, then start the backend API.
3. End-to-end: record a short clip on the desktop client → upload via presigned URL → ingest transcript → trigger summarization job → verify summary appears in DB.

## What is intentionally out of scope for MVP

- Kafka, Elasticsearch, Kubernetes, vector DBs, Redis (unless job volume grows), microservices. PostgreSQL + SeaweedFS + workers is sufficient.