Logbook
Projects | | Links:
The private dashboard and configuration system behind my development practice: 650+ logged sessions across 20+ projects, built with 11ty, Pagefind, Cloudflare Pages and GitHub Actions.
Status: private infrastructure, in daily use. The logbook is the dashboard of my development practice; this entry is about it and the system it belongs to: the configuration, conventions and guardrails that keep work across 20+ projects coherent.
At a glance
| For | My own development practice |
| Scope | 20+ projects, 650+ logged sessions since January 2026, two synced machines |
| Stack | 11ty, Pagefind, Cloudflare Pages and Access, GitHub Actions |
| My role | All mine: conventions, configuration, dashboard |
| Live since | March 2026, private behind access control |
The problem
I build and maintain many projects in parallel: live sites, university platforms, research writing, documentation, internal tools. The work happens in focused sessions with an AI coding agent, on two machines. Working this way is fast, but it fails quietly without structure: sessions are ephemeral, context does not carry to the next session by itself, machines drift apart, and there is no record of what was done, when, or why. The remedy is the same one any serious operation applies to its servers: configuration management and observability.
The control plane
One git repository holds the configuration of the whole practice: global rules that every project inherits, session protocols that open and close each working session, custom skills for recurring procedures, hooks that enforce a safety policy on anything the tooling runs unattended, sandboxing, and the configuration of external tool servers (MCP). All of it is versioned, documented and synced, so a session behaves identically on either machine, and a third machine would bootstrap from a single script. The tooling itself is updated on a written procedure: versions pinned, release notes reviewed before adopting, changes rolled out deliberately.
Continuity is a convention. Every session closes by writing a short handoff for the next one, each project carries a work queue that both I and the tooling read, and every session ends with an export.
None of this arrived ready-made. It grew over months of daily use, following the tooling’s development release by release and the practices of an active community around it. Beyond the practical benefits, I consider the process that led to this workflow a significant personal asset in itself, adapted to modern development practice. I also believe it needs balance: modern AI tools genuinely raise productivity, but the widely repeated claim that they replace traditional techniques, and above all knowledge, is wrong. Supervising them takes both the background knowledge and the time and care to apply it; without those, unpleasant surprises are inevitable, in security above all, but also in architecture and in how deliverables are designed and built. That balance, together with a deep working knowledge of tools like Claude Code, is what motivated the research, testing and constant refinement behind all of it, along of course with the productivity it brings to quality implementations.
The dashboard
The exports feed the logbook: full transcripts plus metadata measured from them, duration and active time, tool usage, context size. A scheduled GitHub Actions workflow also pulls every project’s work queue from its repository, every hour. The site renders it all statically: a hub of project cards with latest activity and open work, each session as a readable page with a table of contents, and stats dashboards that aggregate the whole history into an activity heatmap, weekly and monthly rhythm, duration distributions and a sortable per-project table. Full-text search covers every transcript. A session open anywhere shows live on its project card, marked with the machine it runs on.
The build is deliberately plain: 11ty renders markdown, Pagefind indexes at build time, GitHub Actions rebuilds on every push, and Cloudflare Pages serves the result behind access control. No database, no framework, nothing to operate.
In practice
Nothing here is a product; it exists because I rely on it every working day. It is what makes fast, tool-assisted work dependable, reviewable and repeatable: every change traceable to a session, every session readable in full, the whole history searchable. The harness is Claude Code, adopted early (September 2025), configured deeply, extended with a custom MCP server, and often driven by voice. The design still intentionally keeps harness and model separable: everything that defines the practice lives client-side, so the same setup can point at models from other vendors (OpenAI, Moonshot, Z.ai) or at small local ones for lighter tasks where they save cost and time. Local models are already part of the practice: I have set up and used them for speech transcription and translation and for voice analysis, among other tasks. That path is researched, documented and kept current.
The interest behind it is not only practical. My PhD research concerns AI in programming education, and I am writing detailed notes, shaped as a university course whether or not one materializes, on how large language models work, hands-on, around small open models running on my own hardware (a 4B Gemma, an 8B Greek Krikri, and the voice models I already use in practice).
Screenshots
