Personal projects

A journal you keep without opening an app: you tell your day as it goes to a Telegram bot, which transcribes, files and summarises it.

Context

Personal project started on 13/10/2026, at version 0.8.0 since 17/10. Deliberately kept apart from JARVIS: Memogram stays a journal and only forwards what looks like a request.

Features

Telling:

• Notes by voice, text or captioned photo
• Correct by replying to the note, or add to it with +
• The day ends at 7 am; an account of another day ("my Thursday") is filed under the right day

Reading back:

• A summary every evening, then every week, month and year
• Commands /aujourdhui, /hier, /semaine, /mois, /cherche, /qui
• Search by meaning, without the exact word
• "One year ago" in the evening message
• Reading PWA opened by a single-use link sent by the bot: day, week, month, people, search always visible

Remembering:

• Daily memory exercise: recall a past note from memory, spaced reviews
• Before a meeting: what the journal knows about the person

Links

Private repo. Intimate data: no public demo.

Architecture

Two halves: an always-reachable server, and a PC that does the heavy lifting when it is on.

Telegram (voice/text) ──webhook──▶ Next.js on Vercel + Postgres (Neon)
                                    ├─ immediate cloud transcription (Mistral Voxtral)
                                    ├─ summaries (Mistral): evening cron, Monday, 1st of month
                                    └─ PC work queue
                                                 ▲
PC on ── Python worker (every 15 min) ───────────┘
         ├─ re-transcribes voice notes (faster-whisper large-v3, GPU)
         ├─ writes the summaries the cloud could not (claude -p)
         ├─ archives voice notes locally
         └─ mirrors the journal into the Obsidian vault

Nothing depends on credit

Every cloud pass returns a typed result; a failure (missing key, exhausted credit, outage) moves the work to the PC queue instead of losing it. The bot says the transcription will come the next time the PC is on.

Technical choices

• Two transcriptions: Voxtral, guided by a vocabulary of proper names, is the reference; Whisper on the PC is only used when the cloud failed, and never overwrites a manual correction.
• No audio stored server-side: the Telegram file id is kept, the archive lives on the PC.
• Explicit states: an entry goes pending_cloud → pending_local → done; any edit marks the summaries covering its date as stale, regenerated by the next cron.
• A single cron (Vercel Hobby compatible) that catches up missed days, regenerates from day up to year, and sends the evening draft.
• Memory-frugal worker: it waits for enough free RAM, volunteers as the first target when memory runs out, and retries on the next pass without loss.
• No "logical" LLM correction of the text: in a journal, inventing is worse than misspelling.
• Layers: short routes → services → repositories (Drizzle). Vitest tests on PGlite, no network; pytest on the worker side.

Bridges to other apps

A structured extraction spots what is expressed as an intention (task, reminder, idea) and announces it before handing it to the JARVIS assistant, with 10 minutes to cancel. Nights, job applications and expenses mentioned in a note go to the dedicated apps only when backed by a quote from the note.

Stack

Tech	Role
Next.js 16 / React 19	Webhook, API, reading PWA
Drizzle + Postgres (Neon)	Entries, summaries, work queues
Mistral (Voxtral, large, embed)	Transcription, summaries, semantic search
Python + faster-whisper	PC worker (GPU)
Zod, jose	Validation, sessions
Vitest + PGlite, pytest	Network-free tests

A framework that gets several Claude agents to work together to build whole projects without micro-management.

Context

Personal project started on 2026-02-03. First versions (0.1 → 0.4) the same day, memory system in v0.5.0 (April 24), cross-project dashboard and run history in v0.8.0 (April 25), v1.2.0 on May 1 with memory shared across projects. The Completeness Gate was reworked in July 2026.

Claude Code alone does good work, but long tasks need constant re-prompting. MAO automates that loop: one agent clarifies the need, another plans, a third executes.

Features

Subscription instead of API - The worker goes through Claude Code CLI as a subprocess: MAO uses the subscription, not per-token API billing.

Memory system - MAO records patterns, errors and successes, then feeds them back into the prompts of later runs, including across projects.

Completeness Gate - A run only ends once the checks pass.

Overnight mode - Detached tmux, atomic checkpoint, resume after interruption.

Live web UI - Chef/Worker split view over WebSocket, cross-project dashboard, security approval queue.

Links

Private repo. Tool used locally on WSL, no hosted demo.

Concept

Three Claude agents collaborate to bootstrap a full project:

┌──────────────┐
│ PromptAgent  │  Dialogue with the user
│  (dialogue)  │  → specs, bootstrap, prompts
└──────┬───────┘
       │  mao run
       ▼
┌──────────────┐       ┌──────────────┐
│  ChefAgent   │ ────▶ │ WorkerAgent  │
│  (plans)     │ ◀──── │ (executes)   │
└──────────────┘       └──────────────┘
                        Claude Code CLI → real code on disk

Workflow: mao init → conversation → mao run → bootstrapped project.

Subscription instead of API

The main provider calls Claude Code CLI as a subprocess (claude --print --output-format=json) instead of the Anthropic API. MAO uses the Claude Code subscription; the returned JSON is used to track tokens and estimated cost per run. The direct API provider is still a stub.

Memory system

MAO records what it learns during execution, in five types: PATTERN, LEARNING, DECISION, ERROR, SUCCESS.

• Retrieval without embeddings: weighted sum of tag match, keyword overlap, confidence and recency (exponential decay, 30-day half-life)
• Markdown injection into system prompts, within a character budget
• Since v1.2: a global memory pool shared across projects

Hierarchical execution

For large projects, an ArchitectAgent splits the work into subsystems before delegating to Chef/Workers. Coordination goes through an internal message bus. Specialised workers (backend, frontend, test, devops) are routed by capability tags. Effort is set per task (low → max).

Completeness Gate

A run is only marked complete after a set of registered checks pass (including a smoke test of the project's scripts). Since July 2026, rejection accounting is progress-aware, and an opt-in setting lets a run close with caveats when the gate is exhausted.

Web UI

Seven React pages (Vite + shadcn/ui components + Zustand + Tailwind 4):

• Prompt - chat with PromptAgent + project list
• Dashboard - cross-project view: statuses, 30-day runs, memory by type
• Settings - Chef/Worker configuration
• Approvals - security queue + audit log
• Split View - live Chef ↔ Worker over WebSocket (NarratorAgent, timers, effort)
• Stats - timeline, files and languages produced
• Memory - entry CRUD, retrieval preview

Security module

• Modes: autonomous (default, checks disabled) or strict (checks on, risky commands blocked or sent for approval)
• Auto-whitelist in strict: detected dev scripts (package.json, Makefile, pyproject.toml)
• JSONL audit log

Overnight mode

For multi-hour runs: uvicorn backend in a detached tmux session, atomic per-run checkpoint (temp + swap), resume of an interrupted run from the UI, manual pause/resume.

Stack

Tech	Version	Role
Python	3.11+	Orchestration core
Pydantic	2.x	Typed models and settings
Typer	0.12+	CLI
Loguru	0.7+	Structured logs
FastAPI	0.109+	Web UI backend
WebSockets	12+	Live streaming
React	19	Web UI
Vite	7	Front build
Zustand	5	Front state

The single access point of my personal ecosystem: it keeps the keys, the other apps ask.

Context

Personal project started in July 2026, first to feed my browser's "new tab" page without storing any token in it. It became the hub of my personal assistant: every new service goes through it rather than through one more connector.

Features

Centralized reads:

• Read feeds for my notes, calendars, mail, tasks, repositories, deployments and bank balances
• Several accounts per service, connected from a private console

Controlled actions:

• Mail drafts and sending, file organisation, calendar writes, quick capture into my notes
• Human approval on mobile for sensitive actions, trust rules for the rest

Governance:

• Device tokens revocable one at a time from the console
• Every access logged and viewable, never purged without my decision

Links

Private repo. Personal infrastructure, no public demo.

Role

A single entry point between my apps and my online accounts (mail, calendar, storage, code repositories, hosting, banks). Client apps never hold a service token: each one gets its own device token, revocable one at a time, and the hub makes the calls on their behalf.

Browser extension ────┐
Assistant routines ───┤                       ┌─► Mail / calendar / storage accounts
Personal apps ────────┼─► Hub (gatekeeper) ───┼─► Code repositories / hosting
Phone / PC ───────────┘    │                  └─► Banks (read)
                           └─► Access log (written before any access)

Access control

• One device token per client, stored hashed, bound to a list of scopes ("doors") and rate-limited
• One door = one line in a central registry: adding an access happens in a reviewed commit
• Strict CORS, never open to everyone; an unconfigured door answers an explicit error
• Multi-tenant: the tenant is derived from the token presented, never from a variable; doors backed by owner-only credentials refuse a guest token

Secrets

• Refresh tokens encrypted (AES-256-GCM) with associated data bound to owner, provider and account, plus a key version
• Access tokens kept in memory only, never written to the database
• Fail-closed owner login (empty user list = nobody gets in), signed OAuth state + PKCE
• Logs redact anything that looks like a token

Traceability and approval

• Fail-closed access log: every sensitive read and every action is recorded (what, who, why) before it runs; if the row cannot be written, nothing happens
• Closed list of actions: a routine can only request actions declared in code, never a free parameter
• Human approval: a sensitive action waits for my go-ahead on mobile, expires if I do not answer, and is refused if it was altered after being sent (digest checked)
• Trust rules: some repetitive actions can run without a button press, under an explicit rule, capped over 24 h and announced before acting; at the slightest doubt, back to the button

Stack

Tech	Role
Next.js 16 (App Router)	Machine doors + owner console
TypeScript	Strict typing
PostgreSQL + Drizzle	Tokens, encrypted accounts, log, rules
NextAuth	Owner login
Vitest	Tests (encryption, redaction, gatekeeper, actions)

Route → service → repository layers, additive-only migrations, replayed idempotently at build time.

The right film in under a minute: say what you feel like watching the way you would on the couch, Nightjar answers with a poster, its reason, and where to watch it tonight.

Context

Personal project started on 30/10/2026, live since 02/11. Born from an evening spent looking for a film longer than watching it.

Features

Choosing:

• "Tonight": one main film and four others, tuned by mood, length, who you are with, and only on your subscriptions
• Free-text mood, with the understood words highlighted and editable
• "Like…": neighbours of one or more starting films
• Trailer, rating, length and platforms on every card

Learning taste:

• Seen, liked, loved, keep, not for me, more or less like this
• Quick calibration on posters at first launch
• A bank of kept films, with those just arrived on your platforms

Together:

• A watch party shared by link, guests without an account, voting and a common ranking

Links

Private repo, personal app: no public demo.

Architecture

TMDB + IMDb ratings ──nightly sync (GitHub Actions)──▶ Postgres (Neon)
                                                        ├─ ~18,000 films, French availability per platform
                                                        └─ mood axes (rules, refined at night)
Free text ──rule-based parsing──▶ filters + deterministic score ──▶ cards with their "why"
Gestures (seen, liked, loved, kept, not for me) ──▶ taste profile as poles

Search without paid AI

A sentence like "tense locked-room, not too gory, under 1 h 45, on my subscriptions" is split by rules: duration, years, platforms, exclusions, context, quoted titles. Ranking is a deterministic score shown on every card, with the sentence that explains it. No request goes through a model: answers in under two seconds, at zero cost.

Mood, measured

Genres are too coarse ("horror" puts a slow psychological film next to a jump-scare one). Each film gets seven continuous axes (tension, jump scares, gore, humour, pace…): a first rule-based pass at every sync, then a nightly refinement by Claude on the subscription, never during a search.

Technical choices

• Taste as poles: each loved film is a pole of its own, with its own era; an era factor avoids suggesting a 1950s film to someone who only likes recent ones.
• Diversity: MMR selection so the five suggestions are not five copies of the same film.
• Sync outside Vercel: the initial import is about 18,000 calls, it runs in GitHub Actions, with a rate limiter on a monotonic clock.
• Watching together: a shared link, guests without an account who vote, a common ranking.
• Machine bridges by token: the Memogram journal sends the films you talk about, Magpie the films spotted in saved videos; Nightjar stays the single source of truth for a film's state.
• Layers: short Server Actions and routes → services → repositories (Drizzle). Vitest tests on PGlite, no network; ten written architecture decisions.

Stack

Tech	Role
Next.js 16 / React 19	App, Server Actions, offline PWA
Drizzle + Postgres (Neon)	Catalogue, taste, watch parties
TMDB, JustWatch, IMDb	Film data, French availability, ratings
GitHub Actions + Claude	Nightly sync and mood scoring
next-auth + passkeys	Face ID sign-in
Vitest + PGlite	Network-free tests

Access your Obsidian notes from any device - mobile, tablet, desktop.

Context

Personal project started in November 2025.

Initial need: access my Obsidian notes on mobile without paying for Obsidian Sync ($8/month). Solution: use GitHub as a free and reliable sync layer.

What it does

Editing:

• Markdown editor with keyboard shortcuts
• Quick switcher (Ctrl+P) for fast navigation
• Automatic daily notes
• Full tag and backlink support

Visualization:

• Graph view of note connections
• Activity heatmap (commit history)
• Media support: images, PDFs, Excalidraw

Mobile & Offline:

• Installable as native app (PWA)
• Works offline
• Sync via GitHub, no proprietary server

Links

• Open the app
• GitHub

Architecture

100% client-side - no proprietary backend. All operations go directly through the GitHub API.

Browser/PWA ◄──► Next.js API ◄──► GitHub API ◄──► obsidian-vault (repo)
     │                │
     └── Service Worker (Cache + Offline)

Data flow:

• Read: Octokit → Parse frontmatter → Extract wikilinks → Markdown render
• Write: CodeMirror → SHA validation → GitHub commit → Sync

Tech Stack

Tech	Version	Role
Next.js	16	SSR Framework + API Routes
TypeScript	5.9	Strict typing
NextAuth.js	5.x	GitHub OAuth + Sessions
Octokit	4.x	Official GitHub API client
CodeMirror	6	Mobile-friendly Markdown editor
D3.js	7	Force-directed graph visualization
Zustand	5.x	Lightweight state management
PostgreSQL	16	Tags/backlinks/graph index
TailwindCSS	4	Utility-first styling

Metrics & Features

• 36 color themes (18 dark + 18 light) via OKLCH
• Implemented phases: P0 (Auth) → P7 (CRUD Notes/Folders)
• Offline support via Service Worker + Cache API
• Private notes: path-based (_private/) + frontmatter + #private tag
• Lock System: SHA-256 PIN, configurable auto-lock timer
• Media: images, PDFs, canvas (React Flow), audio, Excalidraw

Security

• Data never passes through third-party server: GitHub OAuth → encrypted JWT cookie
• Access restriction via ALLOWED_USERS (whitelist)
• PIN hashed with SHA-256, never stored in plaintext

A web app to log your nights and understand your sleep, designed for the phone and for privacy.

Context

Personal project started on 01/07/2026, deployed on Vercel. Personal use. "Celestial planisphere" art direction: starry vault, sleep stages as layers of the sky, score as a sextant.

Features

Logging:

• Quick night entry, retroactive entry, naps
• Factors, tags and notes per night
• Generic CSV import (with mapping), Oura CSV, Apple Health export, without duplicates

Understanding:

• Dashboard, calendar, night detail with hypnogram
• Trends, weekday averages, correlation insights
• Composite score with every component explained
• Non-clinical circadian coaching and evening wind-down

Motivation:

• Personal goals with progress bars
• Weekly challenges, personal records, streaks, rewards
• Evening journal (mood, dream, reflection), covered by the same consent

Account and privacy:

• Sign-in by password or passkey (Face ID, Touch ID, Windows Hello)
• Full data export and erasure
• Installable, offline reading, bedtime reminder notification

Links

Private repo. The live app is behind a login: no public demo.

Architecture

Flat structure at the root (app/, components/, lib/, db/, core/), layers enforced by ESLint:

Route / Server Action (≤ 20 lines) → Service → Repository → Drizzle schema

app/** cannot import the database layer (no-restricted-imports rule).

Pure metrics engine

Calculations live in lib/metrics/*, with no database access, tested by vectors (one assertion per formula): duration, efficiency, rolling averages, 14-day sleep debt, social jetlag, regularity, chronotype (MSFsc), weighted composite score, streaks, Pearson and Spearman correlations.

Recorded decisions (15 ADRs)

• A night's date is the wake-up date
• Sleep stages stored as aggregates on the session
• Regularity = a documented proxy, not an SRI
• Composite score = a transparent weighted blend, broken down on screen
• Offline: server is authoritative, last write wins by updatedAt
• File import only, no live wearable sync
• Forgotten password without email: single-use link, only its hash is stored

Health data

Nights are treated as health data (GDPR art. 9): granular consent at onboarding, CSV + JSON export (art. 20), full cascading deletion (art. 17). The service worker only caches static assets, never the API or the data.

Machine gates

Two entry points for other personal apps, each behind a token whose hash alone is stored, with a trace written before any read or write (refused if the trace fails): a last-night summary read by the JARVIS assistant (dedicated consent, off by default), and writing nights told to Memogram, which never overwrites a manual entry.

Stack

Tech	Role
Next.js 16 / React 19	App Router, Server Actions
Drizzle + postgres-js	Postgres database (Neon in prod)
next-auth v5 + SimpleWebAuthn	bcrypt password and passkeys
Tailwind v4 + shadcn/ui	Interface
recharts + custom components	Charts, heatmap
Vitest + PGlite	Unit and integration tests on the real migrations
gitleaks	Secret scanning in the verify gate

A personal logbook for Honkai: Star Rail: the game data on one side, my characters on the other, and engines that answer "which team?", "which build?", "should I pull on this banner?".

Context

Personal project started on 22/07/2026. v0.1.0 and v0.2.0 (team analysis) shipped the same day, followed in October by the "Astral Express conductor's logbook" art direction and passkey sign-in. The data comes from a public guide site, credited as the source in the interface and never republished: the app is single-user.

Features

Knowledge base:

• Character, light cone and relic set sheets
• Versioned tier lists with a diff between two snapshots
• Current, announced and past banners

My account:

• Editable roster, light cones, teams and gacha profile
• "My build" on every character sheet

Advice:

• Team builder and team analysis with an explained score
• One-click replacement suggestions
• Pull Advisor: PULL, WAIT or SKIP based on the actual roster

Admin:

• Data freshness and coverage, staleness cron

Links

Private repo. Single-user app behind a login: no public demo.

Architecture

scripts/ingest: crawler → parsers (cheerio) → Zod validation → normalisation
                      → data/kb/*.json (committed) → database load
app/ (RSC) → lib/server/services → lib/server/repositories → Postgres
                   └── lib/domain/engines: pure engines, no I/O

Ingestion pipeline

• Polite crawl: strictly sequential requests at least 1 s apart with jitter, on-disk cache of raw HTML, robots.txt respected, explicit user agent.
• Parsers tested against committed HTML fixtures, recent and legacy layouts.
• No guessed fields: a parser that cannot find a value writes null, and the coverage report flags it.
• Drift guard: if a field's coverage drops by more than 5 % versus the previous run, ingestion fails loudly.
• Versioned data: the canonical JSON is committed, so git history doubles as the meta changelog. ingest:diff shows what would change without writing.
• Idempotent load, skipped when the file hash has not changed.

Decision engines

Pure functions in lib/domain/engines:

• Validator for per-game-mode constraints (exclusivity, non-stackable variants)
• Team builder with explained substitutions and duplicate prevention
• Team analysis: comparison with a corpus of reference compositions, a score out of 10 split into 4 components (meta alignment, tiers, roles, mode fit), one-click replacement suggestions, redirection to the closest achievable compositions
• Character builder: target build versus owned gear, remaining farming cost
• Pull Advisor over 5 axes, verdict PULL / WAIT / SKIP

Operations

Daily read-only Vercel cron that detects stale data without ever writing to the knowledge base. Single-user auth (next-auth v5, bcrypt, passkeys), account created through a first-login link.

Stack

Tech	Role
Next.js 16 / React 19	App Router, PWA
Drizzle + postgres-js	Postgres (Neon in prod)
cheerio + tsx	Ingestion parsers
Zod v4	Knowledge base contract
Vitest	Parsers and engines
Playwright	Visual check screenshots

A personal cash book that works with no account and no network, and syncs across devices when you want it to.

Context

Personal project started in July 2026. The goal: track expenses with fast entry, amounts that are always exact, and data that stays in the browser by default. Art direction v2, "the household cash book, kept clean", has been in production since October 2026.

Features

Entry:

• Amount-first quick entry (numeric keypad, category grid with a pre-selected suggestion), opened with the n key on the web
• Expenses, income and transfers, with notes, tags and reversible deletion
• Recurrences materialized on launch, with bounded catch-up

Organization:

• Multiple accounts, each with its own currency and opening balance
• Default and custom categories, with keywords feeding the suggestion
• Budgets per category or per account, with an explicit state when an exchange rate is missing
• Multi-currency with manually entered rates

Reading:

• Dashboard with summaries and charts over a period
• French and English interface, light or dark theme

Import:

• Bank CSV statement import: encoding, delimiter, decimals and dates detected, offline categorization and de-duplication
• Optional AI pass on uncertain rows only, sending nothing but the merchant label
• Being integrated, not yet in service: on the owner side, bank operations imported through his personal hub, simulated by default, and matched with expenses told in his Memogram journal

Links

• Open the app

Private repo.

Architecture

A single Flutter web app, organized by feature: each lib/features/<name>/ folder holds three layers.

presentation/  screens, widgets, @riverpod controllers
     │
domain/        immutable freezed entities, interfaces, pure services (no Hive import)
     │
data/          Hive DTOs + hand-written mappers + repositories

Data lives in the browser (Hive). An account stays optional: signed in, the app pushes and pulls a delta to TypeScript Vercel serverless functions backed by Neon Postgres (Drizzle). The local store remains the source of truth; sync runs in the background and never blocks a read or a write.

Technical choices

• Exact amounts: integers in the currency's smallest unit; the number of decimals is derived from ISO-4217 (0 for the yen, 3 for some dinars), never hardcoded to 2.
• Derived balance: an account's balance is computed from its transactions, never stored.
• Cross-currency transfers: debited amount, credited amount and the applied rate frozen at creation.
• Conflicts: last-write-wins per row, server revision cursor, deletions synced as tombstones.
• Frozen registries: Hive type ids and field numbers reserved for life, versioned schema with idempotent migrations.
• Authentication: argon2id password hashing, JWT session in an httpOnly cookie.
• State: 100% Riverpod code generation, no StateNotifier or ChangeNotifier.

Quality

• Strict very_good_analysis and riverpod_lint lints.
• Flutter tests on the app side, Vitest on the API side with an in-memory Postgres (PGlite): no test needs a real database.
• GitHub Actions CI on both halves; 24 architecture decisions recorded as ADRs.

A strength-training and nutrition coach that shows its calculations instead of asking to be trusted.

Context

Personal project started on 20/10/2026, in development. A private app, designed for a single user. Version 0.4.0 covers the first five phases of the plan: foundation, "the instrument" art direction, nutrition engine, workouts, food log and weekly review. The last three are awaiting validation in real conditions.

Features

Nutrition:

• Calorie and macro targets computed during onboarding, each number with its formula
• Food log: accent-tolerant search, favourites, custom foods, "same as yesterday"
• Morning weigh-in and remaining kcal for the day

Workouts:

• Ready-made programs, thumb-friendly log with rest timer and screen kept awake
• Suggested progression with the calculation expanded, history and records
• Works without a network at the gym

Weekly loop:

• Sunday review: trend curve, measured expenditure, new target explained in plain words
• Plateau detection and deload week

Links

Private repo. Personal app with restricted access, no public demo.

Principle

A 100% deterministic engine: no AI, every target and every recommendation comes from a published formula, shown expanded on screen. The engines are pure modules, with no database, tested against vectors, with their sources cited in the code.

Screens (workout, meals, review) ─► Services ─► Repositories ─► PostgreSQL
                                      │
                                      ├─► lib/nutrition (targets, trend, expenditure, review)
                                      └─► lib/training  (programs, progression, e1RM, plateau)

Nutrition engine

• Basal metabolism: Mifflin-St Jeor, Katch-McArdle, Cunningham
• Weight trend: exponential moving average (α = 0.1), missing days interpolated
• Measured expenditure: logged intake minus change in stores (7,700 kcal/kg), least-squares line over 2 to 8 weeks; without enough data the app refuses to measure and says why
• Sunday review: new target, change capped at ±200 kcal per review
• Simulator of 8 weeks of noisy fictional life: expenditure recovered within ±50 kcal (median 21 kcal over 200 draws)

Training engine

• 44 exercises in French, 3 programs (full body 3 d, upper/lower 4 d, PPL 6 d)
• Double progression, Epley e1RM, records
• Plateau detected after 3 sessions without progress → lighter session; deload week on signal

Offline

The workout log works in airplane mode: every action goes into a local queue replayed in order, without duplicates (IDs generated by the phone). The service worker caches static assets only, never health data.

Data and compliance

• Single account created through a first-login link, passkeys (WebAuthn), no public sign-up
• Database hosted in the EU; GDPR export and erasure covering every table
• Foods: embedded CIQUAL table + Open Food Facts called server-side with a 7-day cache; values frozen at entry time
• Additive migrations applied by the production build; a destructive migration fails both tests and build

Stack

Tech	Role
Next.js 16 / React 19	App Router, mobile-first PWA
TypeScript	Strict mode
Tailwind 4 + shadcn/ui	Interface
Drizzle + PostgreSQL	Data
next-auth v5 + SimpleWebAuthn	Login + passkeys
Vitest + PGlite	Unit and integration tests

Who sits where, who voted for what: French political life, sourced line by line.

Context

Personal project started in June 2026 and published online. Phases 0 to 6 and seven follow-up iterations are delivered. The project is on pause, waiting for feedback from its first testers.

Features

People and organisations:

• French MPs, senators, government members and MEPs, with search on every keystroke
• Profiles with mandates and attendance rate
• Parties and groups: description, neutral summary, link to the official programme, left-right placement

Votes and bills:

• Votes with For / Against / Abstain results, individual votes collapsed
• Amendments: lifecycle from filing to outcome, text and explanatory statement, search by author, group or bill

Territory and relationships:

• Constituency map and 2024 legislative election results
• Relationship graph between political actors

Transparency:

• Methodology and sources page, CSV export with provenance, correction requests
• Light or dark theme, automatic or manual

Links

• Visit the site
• Private repo.

Principle

The priority was set from day one: accuracy > completeness > freshness, and no invented data. Every displayed value comes from a raw snapshot kept with its provenance; the whole database can be re-derived from those snapshots.

Official sources ─► Connectors ─► Raw snapshot + provenance (content_hash)
                                        │
                                        ▼
                    Identities + bitemporal versioned facts ─► Services ─► Pages

Data model

• Identity + fact satellites versioned bitemporally (what was true, and when we learned it)
• Each value typed FAIT_SOURCE (taken from a source) or ANALYSE_DERIVEE (calculation documented in the methodology)
• Idempotent ingestion: a replayed job creates no duplicates

Connectors

French National Assembly (MPs, votes, amendments), Senate, government composition (DILA), 2024 legislative elections (Ministry of the Interior), European Parliament, Wikidata (descriptions, left-right placement) and Wikipedia (party summaries), the last two flagged as third-party sources. The amendments connector filters the archive by file name so that only the targeted bill is unpacked.

Public mode

• Rate limiting, CSP and HSTS headers
• Legal notice, GDPR page, data protection impact assessment (DPIA), per-entity correction requests
• Robots and sitemap depending on the mode (private or public)

Quality

• Route (≤ 20 lines) → service → repository layers; the database is imported only in repositories
• Network-free tests (a real-network health signal runs separately, non-blocking)
• Fixed headcounts checked (577 MPs, 348 senators), secret scan before commit
• Decisions recorded as ADRs; light and dark palettes checked for AA contrast

Stack

Tech	Role
Next.js 16 / React 19	App Router, server rendering
TypeScript + zod	Strict typing, validation
PostgreSQL + Drizzle	Bitemporal data, linear migrations
MapLibre	Choropleth map of constituencies
d3-force	Relationship graph
Tailwind 4	Interface
Vitest + PGlite	Tests

Introspective mobile app to bring people closer through questions that matter. No winner, no score - just listening.

Context

Idea and first prototype in August 2024. Project restarted in 2026, full release planned for late 2026. Designed and built solo. Personal IP.

What it does

11 themes - Each round digs into one topic (self, others, time passing, fear…). 5 question pairs per theme.

Mirror mechanic - For each subject, two complementary questions: one that pushes you to share what hurts, one that pushes you to acknowledge what helps. You choose which side to flip.

"Toward others" variant - Instead of answering for yourself, you guess what the other person would say.

Filterable catalog - All questions browsable outside a game, by theme.

Distribution

Public web beta in progress - testable without signup. EAS iOS and Android builds planned for late May 2026. Private repo.

Links

• Closed beta, invitation only.

Concept

Card game for 1+ players, no competition, built to strengthen listening and respect (playable solo or in group). Each themed round serves 5 mirror pairs: a dark side (vulnerability, doubts) and a light side (gratitude, strength).

Architecture

┌─────────────────────────────────────────┐
│              App (Expo)                 │
├─────────────┬───────────────────────────┤
│  Navigation │  React Navigation v7      │
│  Theme      │  Centralized tokens       │
│  Constants  │  Animation durations      │
│  Screens    │  Home / Game / Catalog    │
│  Components │  Card / Flip / Gradient   │
│  Data       │  11 themes × 5 pairs      │
└─────────────┴───────────────────────────┘

3D Animation

Card flips use a custom 3D perspective via react-native-reanimated 4.1, without useNativeDriver (incompatible with matrix-based 3D transforms). Interpolation on rotateY with fine-grained front/back opacity control.

Design System

Token	Value
Deep black	#0D0D0D
Gold	#D4A574
Cream	#F0E6D8
Headers	Playfair Display
Body	DM Sans

Stack

Tech	Version	Role
React Native	0.81	Mobile runtime
Expo	SDK 54	Build, OTA, linking
TypeScript	5.9 (strict)	Typing
Reanimated	4.1	3D flip
React Navigation	v7	Native stack
EAS	latest	Build + Submit

Quality Shield

• Strict TS, 0 any
• 0 magic number: every token lives in theme/ and constants/
• Files <300 lines, components <150
• 42 TS files, 1420 lines, 0 type errors

Offline-first

Everything ships in the bundle: no backend, no network calls, fully standalone. The 115 questions are typed data, split across 3 files for readability.

A drinking card game for nights with friends, in two formats: the printed deck, and a PWA that runs the game on a phone.

Context

Personal project started in July 2026, for 1 or 2 copies, not published. The physical deck comes first; the PWA is a companion. Adults only, drink responsibly: a soft option swaps sips for a dare or a non-alcoholic drink.

Features

The game:

• Each turn, the active player draws a Question card and a Special card
• Four question types: Secret, Public, "Who is the most…" (a superlative to guess) and Action
• In progress, not yet released: a fifth type, "The verdict" (an accusation settled by a group vote), and an assigned theme shown during the superlative timer
• 20 kinds of special cards to deflect, block or send an effect back
• The number of sips grows each round
• Deck adjusted to the player count with three tier symbols

The companion PWA:

• Full game playable offline, installable
• Dark neon theme
• Screens reworked for quick reading: who plays, what to do, which effect

The physical deck:

• Printer-ready PDFs, generated from the same faces as the screen
• Printing and cutting guide in the project docs

Links

• Open the PWA

Private repo.

Architecture

Strict separation, enforced by an ESLint no-restricted-imports rule:

core/        pure domain: card data + game engine
             (reducer, resolution stack, deck, RNG, drinks)
             no React, Next or browser import
     │
lib/         adapters: design tokens, PDF pipeline, IndexedDB, hooks
     │
components/  React UI, including CardFace (SVG card faces)
app/         screens: setup, table, deck, rules, print preview
scripts/     print.ts, verify-print.ts, generate-icons.mjs

One card face for screen and print

Each face is an SVG-React component. On screen it renders as is; for print it is serialized (renderToStaticMarkup), then rasterized by sharp at 300 dpi. No headless browser in the chain. Face colors are sRGB hex for rasterization, mirrored as CSS variables on screen.

Print pipeline

• pnpm print outputs double-sided PDFs: A4 and A3 impositions, and single cards
• Poker size 63 × 88 mm, 3 mm bleed, crop marks
• pnpm print:verify checks dimensions, TrimBox/BleedBox and resolution

Game engine

• Immutable, JSON-serializable state, persisted offline (localStorage + IndexedDB, no database)
• Deck assembled by player count, reproducible seeded draw (mulberry32)
• Card totals per tier are derived by code: the original spec was inconsistent, and a test prints the discrepancy report
• Structured event log with a v2 state migration
• Vitest unit tests on the engine, Playwright end-to-end runs in a mobile viewport; 6 ADRs

Endless French arrow-word grids, with real words and hand-written clues, on phone as well as computer.

Context

Personal project started on October 17, 2026, for my own use and a few guests. The target: newspaper puzzle pages, with difficulty levels 1 to 4. It went from 0.1.0 to 0.8.1, in production, between October 17 and 19.

Features

The grids:

• Generated on demand, difficulty 1 to 4, several sizes
• Three clue levels per word
• Daily grid, numbered like an edition, with difficulty following the week; it earns extra points and past days stay available
• The clue strip tells whether the typed word is right or not yet
• "Corrected in the margin" screen at the end of a grid

Progress:

• Ten achievements and ten items to unlock (colors, paper, effect, titles)
• Found-word effects: ink stamp on the whole word, sparks, halo, letter rain
• A single Customize page: theme, color, letters, effect, paper, icon; the change shows at once

Account:

• Optional, with passkeys
• Invite a friend with a single-use link, the guest picks their own address
• Report a clue in two taps

Links

• Play

Private repo.

Generation engine

The engine (lib/engine/) is pure and deterministic: no framework or database import, it runs from the command line as well as in the browser. A seed always yields the same grid.

mask.ts      grid shape
   │
slots.ts     word slots
   │
assign.ts    clue placement by matching
             (max 2 clues per cell, every cell used)
   │
fill.ts      constraint-based filling
             (MRV + forward checking + node budget)
   │
generate.ts  final grid

In the app, generation runs in a Web Worker. A bench (pnpm bench) measures success rate, time and grid quality.

Clue bank

• Base lexicon: Lexique 3.83 (CC BY-SA 4.0)
• 8,877 words, each with three clue levels: direct, classic, cryptic
• Written in batches following a guide, checked at merge time: a clue never contains the word or its family, 28 characters max
• The generator only sees defined words

Device first, server second

• Grids stored in IndexedDB, the game is fully playable without a database or account
• Signed in, grids in progress and finished sync
• Layered server: API routes → services → repositories → Drizzle schema; pages never import the database
• Account with a first-login link and passkeys (next-auth v5 + SimpleWebAuthn)

Progress protection

• Migrations applied at build time, and any destructive migration fails the build
• Replaced versions of each grid kept 60 days on the server
• Catalogue locked by a fingerprint registry: a published grid can no longer change its words
• Size rules (file, component, function) enforced by ESLint; 5 ADRs