uscient-mboxer 0.1.5__tar.gz

uscient_mboxer-0.1.5/.agents/SKILL.md

@@ -0,0 +1,32 @@
+# mboxer Operating Skill Guide
+
+This document outlines the standard operating procedures, core competencies, and execution rules for AI agents, LLMs, or advanced users interacting with the `mboxer` environment.
+
+## 1. System Understanding
+An agent utilizing `mboxer` must understand that it is operating a **local-first** and **privacy-conscious** data pipeline. `mboxer` assumes mail archives contain sensitive material, so raw exports are local-only by default. The system is *not* a tool that uploads raw email archives by default or a cloud-first archive processor.
+
+## 2. Core Execution Workflow
+When instructed to process an email archive, the agent should follow this exact sequence of operations:
+1. **Initialize:** Ensure the SQLite database is ready (`mboxer init`).
+2. **Register:** Verify the target account is registered (`mboxer register`).
+3. **Ingest:** Execute `mboxer ingest` with the `--resume` flag. *Crucial Skill:* Always advise the user to run a test ingest on a small, segmented `.mbox` file before ingesting a large historical archive.
+4. **Classify:** Execute `mboxer classify`.
+5. **Review:** Instruct the user to interactively run `mboxer review-categories` to approve or reject taxonomy proposals.
+6. **Scan:** Execute `mboxer scan` to run configured redaction and security rules.
+7. **Dry-Run:** ALWAYS execute a dry-run (`mboxer export notebooklm --dry-run`) before a real export to validate output shapes and profile limits.
+8. **Export:** Execute the final real export.
+
+## 3. Configuration & Profile Management
+The agent must be adept at modifying the `mboxer.yaml` configuration to select the appropriate NotebookLM limit profile:
+* `standard`: 40 target sources, 300,000 words/source
+* `plus`: 80 target sources, 300,000 words/source
+* `pro`: 250 target sources, 300,000 words/source
+* `ultra`: 525 target sources, 300,000 words/source
+* `ultra_safe`: 450 target sources, 225,000 words/source
+
+*Strategy Rule:* The agent should default to recommending `ultra_safe` for large NotebookLM-oriented workflows to preserve headroom for manual sources, attachments, and later additions.
+
+## 4. Classification Context Preservation
+* **Thread Context:** Recognize that classification runs at both the message and thread level. At the thread level, a matching rule is applied to the whole thread and then inherited down to all messages in the thread. 
+* **Confidence Levels:** Understand that rules support two assignment modes: `assign` for confident matches (confidence 1.0) and `assign_hint` for soft matches (confidence 0.75).
+* **Multi-Account:** Maintain strict separation. `mboxer` utilizes per-account keyed storage to keep multi-account exports completely separated.

uscient_mboxer-0.1.5/.claude/README.md

@@ -0,0 +1,9 @@
+# `.claude/` helper files
+
+This directory contains optional Claude Code command prompts for repeatable mboxer work.
+
+Root `CLAUDE.md` imports `AGENTS.md`, so durable project instructions should live in `AGENTS.md` unless they are Claude-only.
+
+No active project-level `settings.json` is included on purpose. Avoid committing Claude settings that silently change permissions, hooks, or tool behavior for every collaborator unless there is a deliberate review.
+
+After changing `.claude/`, `CLAUDE.md`, `AGENTS.md`, hooks, skills, commands, or related files, start a fresh Claude Code session before relying on the new instructions.

uscient_mboxer-0.1.5/.claude/commands/mboxer-final-readiness.md

@@ -0,0 +1,25 @@
+Perform a final no-code readiness audit for mboxer before any future external API/import handoff work.
+
+Requirements:
+
+- Do not modify files.
+- Do not invent an external intake API.
+- Separate proven behavior from recommendations.
+- Run `git status --short` first.
+- Inspect current repo state.
+- Confirm whether mboxer is ready to produce safe projections for a configured external destination once an API/import boundary exists.
+- Identify blockers versus nice-to-have improvements.
+- Draft a concrete future external API/import adapter plan that keeps mboxer independent.
+- Identify the safest first integration PR once an external intake endpoint is available.
+- Watch for instruction-surface changes and report them.
+
+End with:
+
+- Readiness verdict.
+- Evidence supporting the verdict.
+- Blockers.
+- Nice-to-have improvements.
+- Future external adapter plan.
+- First handoff PR recommendation.
+- Tests/checks run.
+- Instruction-surface findings.

uscient_mboxer-0.1.5/.claude/commands/mboxer-lineage-hardening.md

@@ -0,0 +1,19 @@
+Harden mboxer export manifest and lineage behavior without adding external custody/API integration.
+
+Requirements:
+
+- Keep changes PR-sized.
+- Do not add network calls or external service dependencies.
+- Prefer additive manifest fields and tests.
+- Do not include raw sensitive body content in manifests.
+- Inspect `src/mboxer/exporters/manifest.py`, NotebookLM exporter, JSONL exporter, export schema usage, config export profile behavior, and export/manifest tests.
+- Preserve current CLI behavior unless a test proves a bug.
+- Watch for instruction-surface changes and report them.
+
+Desired outcome:
+
+Manifests should better record export type, account, source DB/config context where available, export profile, scrub/security posture, category path, generated files, item counts, splitting/limits behavior, and timestamps.
+
+Run targeted tests and broader tests if feasible.
+
+End with the standard task report from `AGENTS.md`.

uscient_mboxer-0.1.5/.claude/commands/mboxer-producer-seam.md

@@ -0,0 +1,24 @@
+Add the smallest useful neutral producer-event seam for mboxer, without connecting to an external custody system.
+
+Requirements:
+
+- Do not add network calls.
+- Do not invent a final external API/import boundary.
+- Keep mboxer independent.
+- Prefer a neutral module name like `events`, `activity`, `audit`, or `producer`.
+- Events should be append-oriented descriptions of local operations, not mutable state.
+- Use JSON-serializable payloads.
+- Do not include sensitive raw body content by default.
+- Add tests.
+- Watch for instruction-surface changes and report them.
+
+Inspect operational evidence around ingest runs, classifications, category review, security findings, exports, and manifests before implementing.
+
+End with:
+
+- What seam you added and why.
+- Files changed.
+- Tests run.
+- Why this does not couple mboxer to any external system.
+- Later abstraction opportunities.
+- Instruction-surface changes.

uscient_mboxer-0.1.5/.claude/commands/mboxer-readiness-audit.md

@@ -0,0 +1,21 @@
+Perform a no-code readiness audit for `mboxer` as a future safe-projection producer for configured external destinations.
+
+Requirements:
+
+- Do not modify files.
+- Run `git status --short` first.
+- Inspect CLI, schema, migrations, ingest, normalize, classify, taxonomy, security, exporters, manifests, config, and tests.
+- Identify existing evidence/producer seams.
+- Identify missing readiness pieces for append-only event emission.
+- Identify fragile coupling risks.
+- Identify test gaps.
+- Watch for instruction-surface files: `AGENTS.md`, `CLAUDE.md`, `.codex/`, `.claude/`, `.agents/`, hooks, rules, skills, prompts, MCP config, and related files.
+
+End with:
+
+- Current readiness assessment.
+- Top gaps.
+- PR-sized tasks in recommended order.
+- Files likely involved.
+- Risks / cautions.
+- Instruction-surface findings.

uscient_mboxer-0.1.5/.claude/commands/mboxer-security-boundary.md

@@ -0,0 +1,18 @@
+Audit mboxer security and export boundary behavior.
+
+Requirements:
+
+- Keep changes PR-sized.
+- Do not inspect real user archives.
+- Do not add external services.
+- Do not claim full DLP or semantic PII detection.
+- Do not change export profile semantics without tests and explicit rationale.
+- Watch for instruction-surface changes and report them.
+
+Inspect security scan, scrub, policy, NotebookLM export, JSONL export, manifest behavior, tests, and config defaults.
+
+Focus on whether `raw`, `reviewed`, `scrubbed`, `metadata-only`, and `exclude` are clear and tested; whether exports can leak raw body text under safer profiles; whether manifests avoid sensitive raw body content; and whether attachments are handled safely.
+
+Implement only focused fixes/tests where there is clear evidence of a gap.
+
+End with the standard task report from `AGENTS.md`.

uscient_mboxer-0.1.5/.codex/README.md

@@ -0,0 +1,11 @@
+# `.codex/` helper files
+
+Codex reads repository instructions from root `AGENTS.md`. These `.codex/` files are optional helper prompts/templates for repeatable mboxer work.
+
+Use them by pasting the prompt into Codex from the repo root, or by invoking Codex with the file content in your own shell workflow.
+
+Important:
+
+- Do not assume edits to this directory affect an already-running Codex session.
+- After changing `.codex/`, `AGENTS.md`, or other instruction-surface files, start a fresh Codex session before relying on the new instructions.
+- These prompts intentionally avoid inventing a downstream API. They prepare mboxer for possible configured external intake/export paths without coupling it to any service that does not exist here.

uscient_mboxer-0.1.5/.codex/prompts/01-readiness-audit.md

@@ -0,0 +1,35 @@
+# mboxer readiness audit
+
+You are working in the `mboxer` repo.
+
+Goal: inspect the current repo and produce a readiness map for making `mboxer` a strong future safe-projection producer for configured external destinations, without implementing external custody/API integration yet.
+
+Constraints:
+
+- Do not modify files.
+- Do not redesign the app.
+- Do not add external service dependencies.
+- Do not invent an external intake API.
+- Do not make broad speculative recommendations without tying them to current code.
+- Treat `mboxer` as a local-first email archive processor whose job is to ingest Gmail/Takeout MBOX archives, normalize emails, store durable SQLite evidence, classify, scan/scrub, and export NotebookLM/JSONL packs.
+- Watch for instruction-surface files: `AGENTS.md`, `CLAUDE.md`, `.codex/`, `.claude/`, `.agents/`, hooks, rules, skills, prompts, MCP config, and related files. Report anything discovered.
+
+Tasks:
+
+1. Run `git status --short`.
+2. Inspect CLI, schema, migrations, ingest, normalize, classify, taxonomy, security, exporters, manifests, config, and tests.
+3. Identify the strongest existing producer/evidence seams.
+4. Identify missing readiness pieces for future append-only event emission.
+5. Identify fragile areas where future external API/import integration could cause drift or coupling.
+6. Identify test gaps that should be closed before adding any external integration.
+7. Recommend a PR-sized implementation sequence, ordered by safety and value.
+
+Output only:
+
+- Summary of what you inspected.
+- Current readiness assessment.
+- Top gaps.
+- Recommended PR-sized tasks.
+- Files likely involved.
+- Risks / cautions.
+- Any instruction-surface files discovered or changed.

uscient_mboxer-0.1.5/.codex/prompts/02-manifest-lineage-hardening.md

@@ -0,0 +1,43 @@
+# mboxer manifest and lineage hardening
+
+You are working in the `mboxer` repo.
+
+Goal: harden existing export manifest and lineage behavior so future external systems can understand what was produced, from what inputs, under what config/policy, without adding external custody/API integration yet.
+
+Constraints:
+
+- Keep changes PR-sized.
+- Do not add external service dependencies.
+- Do not invent a network client.
+- Preserve current CLI behavior unless a test proves a bug.
+- Do not mutate existing historical data unexpectedly.
+- Prefer additive manifest fields and tests.
+- Do not include raw sensitive body content in manifests.
+- Watch for instruction-surface changes and report them explicitly.
+
+Inspect first:
+
+- `src/mboxer/exporters/manifest.py`
+- NotebookLM exporter
+- JSONL exporter
+- `exports` / `export_items` schema usage
+- config paths and export profile behavior
+- tests around manifests and exports
+
+Desired direction:
+
+- Manifest should clearly record export type, account, source DB/config context where available, export profile, scrub/security posture, category path, generated files, item counts, limits/splitting behavior, and timestamps.
+- Keep enough information for a future external API/import adapter to emit an append-only handoff record about the export.
+- Add or strengthen tests.
+
+Before final report, run targeted tests and then broader tests if feasible.
+
+Output:
+
+- Summary of inspection.
+- Files changed.
+- Tests added/updated.
+- Exact behavior changes.
+- Limitations left intentionally unresolved.
+- Abstraction seams noticed for later integration.
+- Instruction-surface changes.

uscient_mboxer-0.1.5/.codex/prompts/03-producer-event-seam.md

@@ -0,0 +1,51 @@
+# mboxer neutral producer event seam
+
+You are working in the `mboxer` repo.
+
+Goal: add a small internal abstraction seam for future producer events, without connecting to an external custody system and without changing core behavior unnecessarily.
+
+Important framing:
+
+`mboxer` is the local email/MBOX specialist. A future external evidence store may receive safe projections through configured intake routes, but no external system exists in this repo. This task should make future integration easier while keeping `mboxer` independent.
+
+Constraints:
+
+- Do not add network calls.
+- Do not add external service package names.
+- Do not invent a final event schema that pretends to be an external API.
+- Keep it local, testable, and boring.
+- Prefer a neutral module name like `events`, `activity`, `audit`, or `producer`.
+- Events should be append-oriented descriptions of local operations, not mutable state.
+- Do not include sensitive raw body content by default.
+- Watch for instruction-surface changes and report them explicitly.
+
+Tasks:
+
+1. Inspect existing places where operational evidence already exists:
+   - ingest runs
+   - classifications
+   - category review/approval/rejection
+   - security findings
+   - exports/manifests
+2. Propose the smallest neutral internal event abstraction.
+3. Implement only if the seam is clearly useful and does not require broad rewrites.
+4. Add tests.
+5. Document how a future external API/import adapter could consume these events.
+
+Preferred shape:
+
+- A simple dataclass or typed structure for local producer events.
+- Stable event names for operations like ingest completed, classification completed, security scan completed, export completed, category reviewed.
+- JSON-serializable payloads.
+- No external delivery.
+- Clear boundaries around local evidence, safe projections, and exported content.
+
+Output:
+
+- What you inspected.
+- What seam you added and why.
+- Files changed.
+- Tests run.
+- Why this does not couple `mboxer` to any external system.
+- Later abstraction/refactor opportunities discovered, without implementing them.
+- Instruction-surface changes.

uscient_mboxer-0.1.5/.codex/prompts/04-security-export-boundary-audit.md

@@ -0,0 +1,45 @@
+# mboxer security and export boundary audit
+
+You are working in the `mboxer` repo.
+
+Goal: audit and, if safe, tighten tests around scan/scrub/export boundary behavior before mboxer becomes a future safe-projection producer for configured external custody systems.
+
+Constraints:
+
+- Keep changes PR-sized.
+- Do not claim full DLP or semantic PII detection.
+- Do not inspect real user archives.
+- Do not add external services.
+- Do not change export profile semantics without tests and explicit rationale.
+- Watch for instruction-surface changes and report them explicitly.
+
+Inspect:
+
+- `src/mboxer/security/scan.py`
+- `src/mboxer/security/scrub.py`
+- `src/mboxer/security/policy.py`
+- NotebookLM exporter
+- JSONL exporter
+- manifest behavior
+- tests for scan/scrub/export profiles
+- config defaults around cloud-style exports
+
+Focus questions:
+
+1. Are `raw`, `reviewed`, `scrubbed`, `metadata-only`, and `exclude` behavior clear and tested?
+2. Can exported files accidentally include raw body text when a safer profile is expected?
+3. Do manifests avoid sensitive raw body content?
+4. Are security findings represented clearly without overstating scanner capability?
+5. Are attachments excluded, referenced, or represented safely in exports?
+
+Implement only focused fixes/tests where there is clear evidence of a gap.
+
+Output:
+
+- What you inspected.
+- Findings.
+- Files changed.
+- Tests run.
+- Remaining risks.
+- Recommended next step.
+- Instruction-surface changes.

uscient_mboxer-0.1.5/.codex/prompts/05-final-readiness-audit.md

@@ -0,0 +1,33 @@
+# mboxer final external intake readiness audit
+
+You are working in the `mboxer` repo.
+
+Goal: perform a final no-code readiness audit after the manifest, event seam, and security/export boundary work is complete.
+
+Constraints:
+
+- Do not modify files.
+- Do not invent an external intake API.
+- Do not recommend broad rewrites unless there is a concrete blocker.
+- Separate proven code behavior from recommendations.
+- Watch for instruction-surface files and report them explicitly.
+
+Tasks:
+
+1. Run `git status --short`.
+2. Inspect the current repo state.
+3. Confirm whether `mboxer` is ready to produce safe projections for a configured external destination once an API/import boundary exists.
+4. Identify remaining blockers vs nice-to-have improvements.
+5. Draft a concrete future external API/import adapter plan that keeps `mboxer` independent.
+6. Identify the safest first integration PR once an external intake endpoint is available.
+
+Output:
+
+- Readiness verdict.
+- Evidence supporting the verdict.
+- Blockers, if any.
+- Nice-to-have improvements.
+- Future adapter plan.
+- First integration PR recommendation.
+- Tests or checks run.
+- Instruction-surface changes.

uscient_mboxer-0.1.5/.codex/templates/task-report.md

@@ -0,0 +1,15 @@
+# Task report template
+
+## What I inspected
+
+## Files changed
+
+## Behavior changes
+
+## Tests run
+
+## Risks / limitations
+
+## Instruction-surface changes
+
+## Suggested next step

uscient_mboxer-0.1.5/.env.example

@@ -0,0 +1,7 @@
+# Optional local LLM settings
+MBOXER_OLLAMA_ENDPOINT=http://localhost:11434/api/generate
+MBOXER_OLLAMA_MODEL=llama3.1:8b
+
+# Optional defaults
+MBOXER_CONFIG=config/mboxer.yaml
+MBOXER_DB=var/mboxer.sqlite

uscient_mboxer-0.1.5/.github/dependabot.yml

@@ -0,0 +1,33 @@
+version: 2
+
+updates:
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "09:00"
+      timezone: "America/New_York"
+
+    open-pull-requests-limit: 5
+
+    labels:
+      - "dependencies"
+      - "python"
+
+    commit-message:
+      prefix: "deps"
+      include: "scope"
+
+    groups:
+      python-runtime-dependencies:
+        dependency-type: "production"
+        update-types:
+          - "minor"
+          - "patch"
+
+      python-development-dependencies:
+        dependency-type: "development"
+        update-types:
+          - "minor"
+          - "patch"

uscient_mboxer-0.1.5/.github/workflows/bandit.yml

@@ -0,0 +1,52 @@
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+
+# Bandit is a security linter designed to find common security issues in Python code.
+# This action will run Bandit on your codebase.
+# The results of the scan will be found under the Security tab of your repository.
+
+# https://github.com/marketplace/actions/bandit-scan is ISC licensed, by abirismyname
+# https://pypi.org/project/bandit/ is Apache v2.0 licensed, by PyCQA
+
+name: Bandit
+on:
+  push:
+    branches: [ "master" ]
+  pull_request:
+    # The branches below must be a subset of the branches above
+    branches: [ "master" ]
+  schedule:
+    - cron: '16 13 * * 0'
+
+jobs:
+  bandit:
+    permissions:
+      contents: read # for actions/checkout to fetch code
+      security-events: write # for github/codeql-action/upload-sarif to upload SARIF results
+      actions: read # only required for a private repository by github/codeql-action/upload-sarif to get the Action run status
+
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Bandit Scan
+        uses: shundor/python-bandit-scan@ab1d87dfccc5a0ffab88be3aaac6ffe35c10d6cd
+        with: # optional arguments
+          # exit with 0, even with results found
+          exit_zero: true # optional, default is DEFAULT
+          # Github token of the repository (automatically created by Github)
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information.
+          # File or directory to run bandit on
+          # path: # optional, default is .
+          # Report only issues of a given severity level or higher. Can be LOW, MEDIUM or HIGH. Default is UNDEFINED (everything)
+          # level: # optional, default is UNDEFINED
+          # Report only issues of a given confidence level or higher. Can be LOW, MEDIUM or HIGH. Default is UNDEFINED (everything)
+          # confidence: # optional, default is UNDEFINED
+          # comma-separated list of paths (glob patterns supported) to exclude from scan (note that these are in addition to the excluded paths provided in the config file) (default: .svn,CVS,.bzr,.hg,.git,__pycache__,.tox,.eggs,*.egg)
+          # excluded_paths: # optional, default is DEFAULT
+          # comma-separated list of test IDs to skip
+          # skips: # optional, default is DEFAULT
+          # path to a .bandit file that supplies command line arguments
+          # ini_path: # optional, default is DEFAULT
+

uscient_mboxer-0.1.5/.github/workflows/ci.yml

@@ -0,0 +1,66 @@
+name: CI
+
+on:
+  push:
+    branches:
+      - master
+  pull_request:
+    branches:
+      - master
+
+jobs:
+  lint:
+    name: Lint (ruff)
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+          cache: pip
+      - name: Install dependencies
+        run: pip install -e ".[dev]"
+      - name: Run ruff
+        run: ruff check src/
+
+  typecheck:
+    name: Type Check (mypy)
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+          cache: pip
+      - name: Install dependencies
+        run: pip install -e ".[dev]"
+      - name: Run mypy
+        run: mypy src/
+
+  test:
+    name: Test (pytest) / Python ${{ matrix.python-version }}
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version:
+          - "3.11"
+          - "3.12"
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python-version }}
+          cache: pip
+      - name: Install dependencies
+        run: pip install -e ".[dev]"
+      - name: Generate synthetic test fixtures
+        run: python tests/fixtures/make_synthetic.py
+      - name: Run pytest
+        run: pytest --tb=short -q

uscient_mboxer-0.1.5/.github/workflows/dependency-review.yml

@@ -0,0 +1,15 @@
+name: Dependency Review
+
+on:
+  pull_request:
+
+jobs:
+  dependency-review:
+    name: Dependency Review
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/dependency-review-action@v4

uscient_mboxer-0.1.5/.github/workflows/publish.yml

@@ -0,0 +1,60 @@
+name: Publish to PyPI
+
+on:
+  release:
+    types: [published]
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    name: Build distribution
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          persist-credentials: false
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+          cache: pip
+
+      - name: Install build tooling
+        run: python -m pip install --upgrade build
+
+      - name: Build package
+        run: python -m build
+
+      - name: Store distributions
+        uses: actions/upload-artifact@v4
+        with:
+          name: python-package-distributions
+          path: dist/
+
+  publish:
+    name: Publish distribution to PyPI
+    needs: build
+    runs-on: ubuntu-latest
+
+    environment:
+      name: pypi
+      url: https://pypi.org/p/uscient-mboxer
+
+    permissions:
+      id-token: write
+
+    steps:
+      - name: Download distributions
+        uses: actions/download-artifact@v4
+        with:
+          name: python-package-distributions
+          path: dist/
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1

uscient_mboxer-0.1.5/.github/workflows/schema.yml

@@ -0,0 +1,21 @@
+name: Schema
+
+on:
+  push:
+    paths:
+      - "src/mboxer/db/schema.sql"
+      - "src/mboxer/db/migrations/**"
+      - "schema_ingest_tracking.sql"
+
+jobs:
+  validate:
+    name: Validate SQLite schema
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+      - name: Apply schema to a fresh database
+        run: |
+          sqlite3 /tmp/test.sqlite < src/mboxer/db/schema.sql
+          echo "Schema applied cleanly"