loggi

Minimalist, mobile-first life tracking app. Track anything — sleep, habits, symptoms, moods — through three primitives:

• Timerange — start/stop tracking (sleep, work sessions, naps)
• Timepoint — one-tap "this happened" logging (medication, events)
• Diary — timestamped text notes (reflections, milestones)

Quick start

cp .env.example .env   # then edit .env with your values
docker compose up --build

Open http://localhost:5000 and register a user.

Stack

• Backend: Flask + PostgreSQL + SQLAlchemy
• Frontend: Jinja templates + Tailwind CSS + DaisyUI
• Deploy: Docker Compose (Postgres + Flask containers)

Development

CSS rebuild

npm install              # first time only
npx tailwindcss -i ./app/static/css/input.css -o ./app/static/css/app.css --watch

Docker rebuild

docker compose build loggi-frontend && docker compose up -d

Issue Tracking

Issues are tracked with beads (bd) and synced to Forgejo.

bd ready                          # See available work
bd show <id>                      # Issue details
python3 scripts/forgejo_sync.py   # Push changes to Forgejo

For full agent workflow, see AGENTS.md.

AI-driven development

Loggi grows organically through AI agents that discover work, create issues, implement features, refactor code, and audit quality — all autonomously. The human steers by reviewing issues on Forgejo and adjusting priorities. The codebase evolves toward a well-designed app through continuous small improvements rather than big-bang rewrites.

How beads work

Beads (bd) is the local issue tracker. Every task, bug, epic, and decision lives as a bead with a unique ID (e.g. loggi-7ux). Beads form a dependency graph: tasks block and are blocked by other tasks, so work naturally sequences itself.

bd ready                          # Show unblocked tasks (safe to start now)
bd list                           # Show everything, including blocked work
bd show loggi-7ux                 # Full description, deps, status
bd children loggi-7ux             # Subtasks of an epic

Issues sync to Forgejo via python3 scripts/forgejo_sync.py, so the human always has a web view of project state.

Autonomous task creation

Agents don't just execute tasks — they create them. During any session an agent may:

• Discover bugs while implementing a feature → open a bug issue
• Spot missing tests → open a task for test coverage
• Notice code smells → open a refactoring task
• Identify follow-up work → break an epic into smaller subtasks
• Propose new features → create a backlog item with rationale

Every new issue gets a description (why it matters, what to do) and is wired into the dependency graph so nothing gets lost or done out of order.

bd create --title="Extract chart config into shared module" \
  --description="Three plot components duplicate axis/color config. \
  Extract to app/static/js/chart-config.js to reduce drift." \
  --type=task --priority=2
bd dep add <new-id> loggi-gft     # Link to Code Health epic
python3 scripts/forgejo_sync.py   # Push to Forgejo immediately

Parallel agents without interference

Multiple agents can work on the project simultaneously. The rules that prevent collisions:

1. Claim before coding. An agent runs bd update <id> --status in_progress before touching any files. Other agents see that task as taken when they run bd ready.
2. One task per agent. Each agent claims exactly one task, implements it, tests it, closes it, and pushes — then picks the next one. No hoarding.
3. Dependency graph enforces ordering. A task with unresolved blockers won't appear in bd ready, so two agents can't accidentally work on conflicting changes.
4. Small, scoped commits. Each task produces a focused commit (feat(stats): add calendar heatmap) that merges cleanly because it touches a narrow slice of the codebase.
5. Rebase before push. Every agent runs git pull --rebase before pushing, catching conflicts early.

A typical multi-agent session looks like:

Agent A: bd ready → claims loggi-7ux.2 (API endpoints) → implements → pushes
Agent B: bd ready → claims loggi-gft.1 (code health audit) → audits → opens 3 new issues → pushes
Agent C: bd ready → claims loggi-kyp subtask (UI fix) → implements → pushes

All three work in parallel on different parts of the codebase with no coordination overhead.

Growth cycle

The project improves through a repeating loop:

┌─────────────┐     ┌──────────────┐     ┌───────────────┐
│  Code Health │────▶│ Open Issues  │────▶│  Implement &  │
│    Audit     │     │ for findings │     │    Refactor   │
└──────┬──────┘     └──────────────┘     └───────┬───────┘
       │                                         │
       │         ┌──────────────────┐            │
       └─────────│  New features &  │◀───────────┘
                 │   bug fixes land │
                 └──────────────────┘

1. Audit — Run the code-health skill periodically. It scans for bloated files, dead code, poor naming, missing tests, and over-engineering.
2. Triage — Findings become beads with priorities and dependencies. Critical issues block feature work; cosmetic ones go to backlog.
3. Implement — Agents pick tasks from bd ready, implement them, and push.
4. Repeat — After a batch of features lands, the next health audit catches new debt introduced along the way.

Over many cycles, the codebase converges on clean architecture without ever needing a "stop the world" rewrite.

Skills

The project ships four Pi skills in .pi/skills/. The agent loads them on-demand when a task matches, or you can invoke them explicitly with /skill:name.

Command	Description
/skill:work [bead-id]	Hands-off session. Completes exactly one task per invocation. Without an argument, picks the highest-value ready task. With a bead ID, works toward that goal — if the goal is ready it's worked directly, if blocked the agent walks the blocker chain and picks the ready task on the critical path to unblock it. Claims, implements, creates follow-up issues, commits and pushes — no human intervention needed.
/skill:task <idea>	Task creation. Give it a rough idea (e.g. /skill:task add dark mode toggle) and it surveys the existing backlog, decides on type/priority/scope, writes a rich description with acceptance criteria, creates the bead(s), wires dependencies, and syncs to Forgejo. Turns half-formed thoughts into actionable work items.
/skill:triage	Backlog hygiene. Pure planning, no code changes. Reads every open bead, kills duplicates, closes stale tasks, reprioritizes, fixes broken dependency wiring, improves vague descriptions, breaks down oversized tasks, discovers missing work, and reports on overall backlog health.
/skill:health	Code health strategy. Runs a fresh audit (bloat, dead code, duplication, missing tests, security gaps), compares findings against existing health beads, adjusts the task graph to maintain a ~30% health / 70% feature work ratio, and schedules health checkpoints after upcoming milestones.

Typical usage patterns:

# Fully autonomous — agent picks work and ships it
/skill:work

# Work toward a specific goal (walks blocker chain if needed)
/skill:work loggi-7ux

# You have a feature idea — let the agent structure it properly
/skill:task add weekly summary email with sparkline charts

# Periodic maintenance — clean up the backlog before a planning session
/skill:triage

# Quality gate — run after a batch of features lands
/skill:health

Giving agents work

To kick off a session (or many parallel sessions), just point an agent at the repo and say:

bd ready    # then pick a task

Or be more directive:

Run a code health audit, open issues for anything you find, then pick
the highest-priority ready task and implement it.

Or hands-off:

Pick whatever is ready and work on it. Create follow-up issues for
anything you discover along the way.

The agent reads AGENTS.md for the full workflow, claims a task, does the work, syncs to Forgejo, commits, and pushes. Rinse and repeat.

Design principles

• Mobile-first — primary use is on a phone, one-handed
• Privacy — no user directory; sharing requires exact username
• Simple — three entry types, clean UI, no bloat