Pier-Jean Malandrino fe83dcdf79 feat(settings): paste-image size/type limits for #195 (#196 )

* docs: rename Clean Architecture → Hexagonal Architecture (ports & adapters)

Le backend suit le pattern ports & adapters (ports dans domain/ports.py,
adaptateurs dans infra/), pas Clean Architecture au sens Uncle Bob.
Aligne la terminologie dans README, docs/architecture.md, ADR guide,
audit master, fiche audit 01, et la nav mkdocs.

Les noms de fichiers et la commande /audit:clean-architecture restent
stables pour preserver les liens croises et les skills existants.

* feat(settings): add paste-image size/type limits surfaced via /api/health

Introduces MAX_PASTE_IMAGE_SIZE_MB (default 10) and
PASTE_ALLOWED_IMAGE_TYPES (default image/png,image/jpeg,image/webp)
env vars so the upcoming Verify-mode clipboard-paste handler can
validate client-side against the same limits the backend enforces.

Follows the existing MAX_FILE_SIZE_MB pattern. Ships the accepted
design doc at docs/design/195-copy-paste-image-verify-mode.md.

Refs #195

2026-04-29 14:00:00 +02:00

2.3 KiB

Raw Permalink Blame History

Architecture Decision Records (ADR) — Guide

What is an ADR?

An ADR is a short document that captures a significant architectural decision, along with the context and consequences. ADRs create a decision log so future contributors understand why the codebase looks the way it does.

When to Write an ADR

Write an ADR when:

Choosing or replacing a framework, library, or tool
Changing the architecture (new layer, new pattern, new boundary)
Making a trade-off that future developers might question
Deciding NOT to do something (these are often the most valuable)

Do NOT write an ADR for:

Implementation details that are obvious from the code
Formatting or style choices (those go in coding-standards.md)
Bug fixes or minor refactors

How to Write an ADR

Copy adr-template.md to docs/architecture/adrs/ADR-NNN-short-title.md
Number sequentially (ADR-001, ADR-002, ...)
Fill in all sections — especially Context (the why) and Alternatives Considered
Set status to Proposed
Open a PR for team review
Once merged, update status to Accepted

Existing Decisions (captured retroactively)

These decisions were made before the ADR process was introduced. They are documented here for context:

Decision	Rationale	Date
Hexagonal Architecture (ports & adapters) for backend	Decouple domain from framework — enable converter swapping (local/remote) via ports	2025-01
FastAPI over Django	Async-first, lightweight, Pydantic-native — better fit for a single-purpose API	2025-01
Vue 3 + Pinia over React	Composition API + built-in reactivity — smaller bundle for this use case	2025-01
SQLite over PostgreSQL	Single-file DB, zero ops — appropriate for a document processing tool	2025-01
Karate over Playwright for e2e	Team expertise, unified API+UI testing, JVM ecosystem	2026-03
Feature flags via `/api/health`	No external service needed — backend capabilities drive frontend UI	2026-03

Lifecycle

Proposed → Accepted → [Deprecated | Superseded by ADR-NNN]

Deprecated: The decision is no longer relevant (feature removed, context changed)
Superseded: A newer ADR replaces this one (link to the new ADR)
Never delete an ADR — mark it as deprecated/superseded instead

2.3 KiB Raw Permalink Blame History