Goal — Agents project (improvement + memory)

The why (improvement loop)

The existing improvement infrastructure (learning/LRN-*, MEMORY.md, the daily lint sweep at 00:30 Amsterdam) is reactive: it captures things that already went wrong.

That misses the slow-burn patterns — the things that don't trip any single alert but consistently add friction across weeks of working together. Examples the kind of thing this project should surface:

• A phrasing in replies that consistently triggers a correction
• An exec-probe pattern that's noisy but never quite broken
• A flow that "works" but takes 3× the approvals it should
• A type of question where Ziltoid's first instinct is wrong 80% of the time
• Things Ivo visibly enjoys that Ziltoid under-uses

These don't show up in any single session. They only show up across sessions.

The why (memory pipeline — added 2026-08-08)

Heinrich's "memory-for-agents" primitive (per arscontexta article, 2026-01-19) defines 11 success criteria for an agent that "wakes up fresh each session but immediately knows who Ivo is, what projects exist, what's been learned, and what's still open — without re-reading 50 files."

All 11 shipped 2026-07-11 and remain live: 1. Vault mirror — workspace ↔ vault via push-to-vault.py + webhook daemon 2. INDEX.md auto-regenerates from frontmatter 3. MOCs as topic landing pages (5 live: agent-behavior, vault-secrets, linting, v3-adoption, live-sync) 4. MEMORY lego blocks (4 sub-blocks; status: archived per DOX consolidation 2026-07-14, forwarding notes point to AGENTS children) 5. Hard rules anchored in LRNs 6. Lint pipeline (lint-notes.py, lint-contradictions.py, lint-index.py) 7. Daily cron sweep at 00:30 Amsterdam 8. Webhook daemon (LRN-20260711-010) 9. Wiki-link resolver 10. Sub-agent output persistence 11. Stale-context detector

As of 2026-08-08, the LCM + lancedb-pro pipeline (12th criterion, added this merge) provides semantic recall — Ziltoid can surface relevant past lessons at session start without manual grep.

Success criteria

The project is succeeding when, on a 6-month time horizon:

1. Fewer wound recurrences. The recurring wound timeline trends down — patterns logged in week N don't recur in week N+8 or later.
2. Promotion survival rate > 50%. Promotions to MEMORY/SOUL/AGENTS/TOOLS get re-tested by the next reviews and stay promoted. Below 50% means we're promoting things that aren't actually load-bearing.
3. Ivo's "stop doing X" corrections decline (measured by sentiment signal in weekly digests).
4. Ivo's positive signals increase (measured the same way — "nice", "perfect", "good", thumbs up emoji).
5. The dashboard tells the truth. Ivo can open [[dashboard]] and immediately see what's open, what got promoted, what's stale.
6. (NEW 2026-08-08) Memory pipeline stays fresh. Daily conformity check passes; no staleness; lancedb-pro entry count monotonically increases or holds steady. Drops trigger immediate alerts.

Anti-goals

• Not a surveillance project. This isn't about grading Ziltoid. It's about finding friction.
• Not a confession booth. Findings cite evidence, not feelings.
• Not a daily ritual. Weekly cadence is enough. Over-polling produces noise.
• Not a replacement for LRN notes. Acute incidents still go straight to learning/LRN-*. This project is the meta-layer.
• Not memory bloat. lancedb-pro should grow organically; backfill only on detected gap, not preemptively.

Time horizon

This is a forever-project. Per Ivo: "Never ending and always improving docs."

The quarterly self-review (every 12 weeks) asks: is the program producing signal? If not, kill the cron. Don't keep a habit that's not paying rent.

Architectural posture

• Heinrich philosophy — INDEX-as-landing-page, weave-links, lego-block composability, claim-named notes.
• DOX framework — auto-loaded contracts (AGENTS.md + AGENTS-*.md children) with Child DOX Index, Verification stage, Closeout checklist.
• v3.1 protocol (jrcruciani) — separate human/agent/generated audiences; one-fact-one-file; path-as-primary-key; frontmatter-as-schema; bi-temporal; append-only events; materialized views; linter as constraint engine; inbox/ops for reviewable writes.
• LanceDB context memory — semantic + keyword hybrid retrieval; auto-recall via before_prompt_build hook; Jina embeddings for cross-platform parity.

What we explicitly did NOT adopt (yet)

• Path-keyed atomic facts (v3 G1/G2) — premature at ~80 LRN scale; flat IDs still work for our agent-scanner pattern.
• Bi-temporal frontmatter (v3 P5/G18) — premature; only recorded_at for now.
• Schema-control predicates (v3 Phase 4) — defer to ~200-file mark or sub-agent era.
• Sources/ immutable inputs layer — v3 wants sources/articles/, sources/notes/ etc. as immutable; we don't currently distinguish these from general vault content.

See also

• [[AGENTS-agents]] — workspace contract (auto-loaded)
• [[chat-session-review-protocol]] — review cadence
• [[growth-paths]] — active improvement vectors
• [[memory-lancedb-pro]] — semantic memory storage
• ivo/projects/openclaw-persistent-memory/AGENTS.md — former OPM project contract (archived, not maintained)

Airsoft Grenades — Acceptance Criteria

Version 1.0 — Prototype Set for Mike

• [ ] Design A (party-popper-based) prototype built and tested
• [ ] Housing designed and printed
• [ ] Popper guts successfully integrated
• [ ] Sound level acceptable (aiming for >80 dB)
• [ ] Safe to use (no shattering parts, no metal in explosion path)

• [ ] Looks like a grenade (not obviously a hacked party popper)

• [ ] Design B (Thunder B-style) prototype built and tested

• [ ] Housing designed and printed with CO2 cartridge bay
• [ ] Nichrome trigger fires reliably
• [ ] Sound level >110 dB (Thunder B reference: ~120 dB)
• [ ] Safety: manual safety / blast shield in place

• [ ] Battery life acceptable (aiming for 50+ activations per charge)

• [ ] Both prototypes delivered to Mike

• [ ] Mike's feedback collected and logged

Version 1.1 — Batch Prep (after Mike's feedback)

• [ ] Iterate on winner (or both) based on feedback
• [ ] Housing design finalized for potential batch (if volume >3)
• [ ] BOM cost per unit calculated
• [ ] Sourcing list for parts in batch quantities

Version 2.0 — Batch Production (if volume confirmed)

• [ ] Order parts in batch
• [ ] Print batch housings
• [ ] Assemble batch
• [ ] Mike receives batch

Goal — End of day log

Project bootstrap. Created 2026-07-11 20:38 UTC alongside the Morning project. Sister project: [[morning-routine]].

What this is

End-of-day summaries — what got done, what's still open, what's on deck for tomorrow. Concrete shape TBD; this file will be filled in as the project's purpose becomes clear.

Sister project

• Morning/ — morning briefing (just created, also a placeholder)
• openclaw-persistent-memory/ — the OPM work that shipped 2026-07-11

Success criteria

• [ ] TBD — populate after first real entry

Suggested Action

Tell me what "End of day log" should be. Possible interpretations:

1. Manual daily journal — you write a short note before bed, agent archives it
2. Auto-generated digest — agent pulls from memory/daily/*.md, LRNs, git status, runs at 23:00 Amsterdam
3. Cross-project recap — what changed across all Ivo/projects/ today, with diffs
4. Combined with Morning — one project, two entries/day (morning + evening)

Until you pick, this is just a placeholder GOAL.md.

Goal — Homelab

Project type: perpetually-evolving, intentionally never finished. This is a living catalogue of the homelab — hardware, services, IP addresses, what's running where, what's broken, what's planned. Items move through Open → Doing → Done / Archived, but new ones will always appear. There is no "shipped" state for this project.

What this is

A single canonical reference for the home IT infrastructure — what hardware we have, what services run on it, how they connect, what state they're in. Anything that's "something I should remember about the lab" lives here.

Scope

In scope: - Hardware: Proxmox host, NAS, network gear (router, switches, APs), workstations, peripherals - Internal services: media (Jellyfin, Sonarr, Radarr, Prowlarr, SABnzbd, audiobookshelf, calibre-web, motioneye), network (AdGuard, Nginx Proxy Manager, WireGuard), infrastructure (Vaultwarden, Uptime Kuma, CouchDB/Obsidian, Wine-tracker) - Proxmox LXC containers: documented in [[ivo/projects/Homelab/Container-management/README]]; Homelab references them by purpose - Docker stacks on the NAS: documented in [[ivo/projects/Homelab/Container-management/README]]; Homelab references them by purpose - Network topology: IP allocations, VLANs (if any), DNS, certificate strategy - Backups & DR: Proxmox PBS, volume backups, what's covered and what isn't

Out of scope (live in sibling projects): - How to operate containers → [[ivo/projects/Homelab/Container-management/AGENTS]] (decision tree, schemas, safety rules) - Work/agent/OpenClaw stuff → [[Openclaw persistent memory]] - Media wishlist → [[wishlist]] - Physical house → [[House]]

Conventions

• Open — needs doing at some point. Priority order: due date / urgency first, then leverage.
• Doing — currently in progress.
• Done / Archived — shipped or no longer relevant; kept for archaeology, entries live ~90 days, then archive.
• Someday — parked ideas / future plans. Reviewed quarterly.

When a topic grows too big (e.g., "the entire media stack"), it becomes a sub-project under Ivo/projects/Homelab/<topic>/ with its own GOAL.md.

Success criteria

There are none, in the "finished" sense. The win is: - Every internal service has a vault doc (so we know what exists + how to recover it). - Every hardware component has an entry (so we know what to buy / replace). - Security posture is reviewed monthly. - Every piece of hardware and or running service is monitored and shown somwhere on dash.ivoherman.nl - TODO is honest — nothing rotting in Open > 90 days.

Suggested action

Document anything new the moment it's added (a service, a VM, a piece of hardware). Don't let the catalogue drift from reality.

Related

• [[House]] — sister project for the physical house (chores, maintenance, builds).
• [[ivo/projects/Homelab/Container-management/GOAL]] — sibling project for runtime container operations.
• [[AGENTS-homelab]] — the live agent contract.

Goal — Dashboard (sub-project of Homelab)

TL;DR. Provide one fast home page for the homelab's most important status and update signals, plus one focused detail page per canonical sub-category (health, todos, projects, wines, inbox), without a morning briefing page. The Obsidian vault remains the canonical store for durable information; live operational state may come directly from the system that owns it. The wishlist detail page is parked — no current route — and re-evaluates when wishlist UX needs dashboard integration.

Purpose

The dashboard is a single Flask web app at https://dash.ivoherman.nl, served from a container on the Ugreen NAS. It should answer two questions:

1. What needs attention right now? — the home page gives an executive overview.
2. Where can I inspect or act on it? — each sub-category has a dedicated detail page reachable from the canonical navigation.

The dashboard is an interface, not a new system of record. Durable project, TODO, inventory, and briefing data belongs in the Obsidian vault. Live service and infrastructure status belongs to the relevant operational API, such as Uptime Kuma or Proxmox. Dashboard-only storage should be avoided.

Product principles

• Glanceable first: the home page prioritises faults, stopped systems, and recent changes over exhaustive detail.
• One page per sub-category: detailed information belongs on a focused route rather than expanding the home page indefinitely.
• Canonical data stays canonical: use the vault for durable information and the owning API for live state.
• No direct CouchDB coupling: vault access goes through the Obsidian MCP or, once authenticated reliably, the Obsidian Local REST API.
• No secrets in source or UI: credentials are injected through the runtime environment and are never rendered.
• Safe actions only: any write or destructive action, such as deleting an email, must be explicit, authenticated, and provide clear success or failure feedback.

Page structure

Home page (/)

The home page is the executive view. Every summary links to the relevant detail page. Currently live:

• [x] Hero status banner — aggregate Kuma state with explicit OK / paused / down count, link to /health when something is wrong
• [x] KPI strip with counts: emails (48h), wines, todo docs, active projects — each tile links to its detail page
• [x] Three newest emails with source tag, flagged marker, sender, subject, and time
• [x] Latest wine card — most recently purchased bottle with type, quantity, vintage, grape, alcohol, price, and where-bought
• [x] Quick-link grid to every detail page (Health / Todos / Projects / Wines / Inbox)

Not yet on the home page (open work, kept honest here):

• [ ] Suppress marketing email from the newest-email summary
• [ ] Stopped or faulty LXC and VM summary
• [ ] Stopped or faulty Docker stack summary
• [ ] Faulty critical-service summary covering Sonarr, Radarr, Jellyfin, Proxmox, WireGuard, Home Assistant, Deco, smoke and CO₂ alarms, doorbell and front cameras, both NAS systems, and the UPS

Detail pages

1. /health — health and infrastructure - Live state of every Uptime Kuma monitor (up / paused / down with name, URL, and state) - Proxmox VE node cards per known VMID with CPU %, MEM used/total bar, and uptime string - Each node card is expendable for full details, including:

   • Potential attack vectors, security threats and vulnerabilities (ordered by severity)
   • 30-second cache, full Proxmox inventory sweep at every refresh
   • Status: shipped — Kuma and Proxmox state are both live, including per-node CPU/MEM/UPTIME; richer expandable per-resource details remain open

2. /todos — open work - Aggregated TODO documents from every ivo/projects/*/TODO*.md in the vault, rendered as cards - Each card links back to its source note via an obsidian://open?file= deep link - 5-minute cache - Status: partial — TODO documents aggregate correctly, but the view still renders the whole document instead of focusing specifically on ## Open and ## Doing sections

3. /projects — active projects - Every ivo/projects/*/GOAL*.md in the vault rendered as a card with project name, source link, and rendered GOAL body - 5-minute cache - Status: shipped — project discovery and GOAL teasers are live

4. /wines — wine cellar - Hero KPI strip: distinct wines, total bottles, countries, producers, types - Filter and search controls: free-text search across title / producer / region / grape / where-bought, plus type pills and country pills - Wine grid with type tag, quantity, vintage, grape, alcohol, price, where-bought, source link, and an expandable view tasting notes details panel that renders the source-note body - 5-minute cache, embedded bottle images served inline as base64 data URIs - Status: shipped with extensions — search, type/country filtering, and inline tasting-notes panel are all live; producer-grouped views and consumption markers remain open

5. /emails — inbox (labelled "Inbox" in nav) - Recent Gmail and Hotmail messages for the last 48 hours - Per-message source tag, flagged marker, attachment marker, sender, subject, labels, and time - Hero KPI strip: total, flagged, gmail, hotmail, unflagged - Filter controls: free-text search plus source (all / gmail / hotmail) and status (all / flagged / unflagged) pills - Manual refresh link and per-row explicit delete action wired to the host-side sidecar - 90-second cache - Status: shipped — reading, labels, delete, refresh, and source/status filtering are all live; the cache transport still needs migration to a vault note

Parked (not currently in the nav)

• /wishlist — wishlist
• Status: parked — the route is intentionally not built. The wishlist project lives in the vault; revisit this page when wishlist UX needs live dashboard integration (price tracking, status changes, owner handoffs).

Data sources and ownership

Wishlist data follows the same vault pattern as wines and is reachable via Obsidian MCP; an additional dashboard route can be added later without changing this row.

Data-plumbing acceptance criteria

• [x] Vault reads use the Obsidian MCP rather than direct CouchDB access
• [x] Live health data comes from Uptime Kuma and Proxmox
• [x] Home page KPIs are sourced from the same cached fetchers as the relevant detail pages — no parallel collectors
• [ ] Move email-cache.json from the /cache file bridge to a vault note written by the host refresher
• [ ] Use the Obsidian Local REST API for simple vault reads and writes if its authentication is fixed and the result is demonstrably simpler than MCP

Security and privacy criteria

• [x] No secret values are rendered on any page
• [x] Dashboard source contains no embedded credentials
• [x] Required credentials are passed through environment variables
• [x] All write actions (POST /emails/delete, POST /emails/refresh) require a header token, surface success or failure feedback explicitly, and invalidate cache after success
• [x] Access is restricted through Nginx Proxy Manager
• [ ] Add a quarterly credential and access-review check

Architecture and operational facts

• Workspace source: /home/openclaw/.openclaw/workspace/scripts/dashboard/
• Live NAS path: /volume1/docker/dashboard/app/
• Runtime: Flask on python:3.12-slim, container port 8765
• Deploy: scripts/sync-dashboard.sh pushes, restarts, and smoke-tests the live app
• Vault access: Obsidian MCP bearer token passed as OBSIDIAN_MCP_TOKEN
• Cache TTLs: 30 seconds for health, 5 minutes for todos / projects / wines, 90 seconds for email
• Reverse proxy: Nginx Proxy Manager routes dash.ivoherman.nl to 192.168.178.108:8765 and applies the access restrictions

Known issues and next steps

1. TODO extraction still document-wide: /todos renders the full body of each TODO file. Slice out only the ## Open and ## Doing sections to match the page's stated scope.
2. Email cache coupling: email-cache.json is a NAS-mounted file shared between the host cron and the dashboard container. Migrate to a vault-backed cache; keep the email sidecar for provider actions because MCP can't reach Gmail or Hotmail directly.
3. Wishlist page parked: no current dashboard route. Decide later whether the wishlist project wants a live dashboard page or stays vault-only.
4. Local REST API authentication: MCP works today; investigate REST only as a simplification once its auth is fixed, not as a blocker.
5. Health detail depth: per-node expandable details (recent failures, endpoint URL, Proxmox task log) are still open. Current cards show CPU / MEM / uptime only.
6. Mobile layout: functional but desktop-first and cramped on smaller screens.
7. Webhook daemon dead: the briefing footer currently shows ⚠ dead — sync paused. Re-enable once the webhook bridge is back up; not blocking the dashboard itself.

Definition of done

The dashboard sub-project is complete when:

• The home page clearly surfaces every stopped or faulty critical system (open — not yet built).
• The five canonical detail pages meet the requirements above and link back to their source data where appropriate — health is shipped, todos is partial, projects and wines are shipped, inbox is shipped.
• Durable dashboard inputs are stored in the vault rather than passed through ad-hoc filesystem bridges (open — email cache pending).
• No secrets are stored in source or exposed in the UI (shipped).
• Deployment and external smoke tests pass after every change (shipped via scripts/sync-dashboard.sh + external curl against dash.ivoherman.nl).

How to contribute

1. Edit the workspace source under /home/openclaw/.openclaw/workspace/scripts/dashboard/.
2. Run scripts/sync-dashboard.sh to deploy, restart, and smoke-test.
3. Verify the affected route through https://dash.ivoherman.nl and the in-app obsidian:// deep links.
4. Update this GOAL when page scope, nav ordering, or data ownership changes.
5. Update dashboard-todo.md when a tracked item is added, completed, or removed.

Related

• [[ivo/projects/homelab/GOAL]] — parent project goal
• [[ivo/projects/homelab/AGENTS]] — parent project rules
• [[ivo/projects/homelab/dashboard]] — dashboard app notes (dash.ivoherman.nl)
• [[ivo/projects/homelab/dashboard-todo]] — open implementation TODOs
• [[health-overview-notes-dashboard]] — earlier dashboard cross-link note
• [[wishlist-dashboard]] — wishlist project's dashboard-facing index (parked route)

Goal

A single self-hosted MCP gateway exposing multiple backend capabilities (vault, NPM, Proxmox, Vaultwarden, GOG, …) as MCP tools for both agents (Ziltoid + Zoltan), eliminating third-party MCP service fragility and giving us full control over auth, observability, and recovery.

Success looks like

• One endpoint (https://mcp.ivoherman.nl/mcp — URL TBD) for both agents
• Agents call mcporter call mcp-server.<backend>.<tool> instead of separate per-backend clients
• No more hosted-MCP outage risk (2026-07-26 → 2026-07-28 incident resolved)
• Adding a new backend = drop a config file + adapter module; no client-side changes
• v1 tools live: obsidian, npm, proxmox, vaultwarden, gog

Non-goals

• Multi-tenant (only Ivo's two agents)
• Public exposure (LAN + personal domain only)
• Tool marketplace or external plugin ecosystem
• Replacing direct CLI calls when those are simpler (e.g. gog for one-off email)

GOAL — OpenClaw persistent memory

TL;DR. Build a self-monitoring persistent memory layer so the agent (Ziltoid) wakes up fresh each session but immediately knows who Ivo is, what projects exist, what's been learned, and what's still open — without re-reading 50 files. Adopted Heinrich's 11/11 success criteria (2026-07-11); DOX-shaped 2026-07-14; v3.1 inbox/ops flow adopted 2026-07-23.

What success looks like

The Heinrich spec defines 11 success criteria. All 11 shipped 2026-07-11 (verified by [[ivo/projects/openclaw-persistent-memory/LEVERAGE]]). All still satisfied today.

1. Vault mirror — workspace ↔ vault via push-to-vault.py + webhook daemon
2. INDEX.md auto-regenerates from frontmatter
3. MOCs as topic landing pages (5 live: agent-behavior, vault-secrets, linting, v3-adoption, live-sync)
4. MEMORY lego blocks (4 sub-blocks; status: archived per DOX consolidation 2026-07-14, forwarding notes point to AGENTS children)
5. Hard rules anchored in LRNs
6. Lint pipeline (lint-notes.py, lint-contradictions.py, lint-index.py)
7. Daily cron sweep at 00:30 Amsterdam (moved from 09:00 2026-07-22)
8. Webhook daemon (base64-decode bug fixed 2026-07-11, LRN-20260711-010)
9. Wiki-link resolver (scripts/wiki-link-tool.py resolve / backlinks / graph)
10. Sub-agent output persistence (scripts/persist-subagent-output.py)
11. Stale-context detector (scripts/recent-changes.py --since 8h)

Architectural posture

• Heinrich philosophy — INDEX-as-landing-page, weave-links, lego-block composability, claim-named notes. Source: [[ARTICLE]].
• DOX framework — auto-loaded contracts (AGENTS.md + AGENTS-*.md children) with Child DOX Index, Verification stage, Closeout checklist. Source: [[dox-comparison]]; adopted 2026-07-14 ([[dox-adoption-completion-2026-07-14]]).
• v3.1 protocol (jrcruciani) — separate human/agent/generated audiences; one-fact-one-file; path-as-primary-key; frontmatter-as-schema; bi-temporal; append-only events; materialized views; linter as constraint engine; inbox/ops for reviewable writes. Source: [[findings-v3-comparison]]; adopted 2026-07-23 ([[v3-adoption-completion-2026-07-23]]).

What we explicitly did NOT adopt (yet)

• Path-keyed atomic facts (v3 G1/G2) — premature at ~40 LRN scale; flat IDs still work for our agent-scanner pattern.
• Bi-temporal frontmatter (v3 P5/G18) — premature; only recorded_at for now.
• Schema-control predicates (v3 Phase 4) — defer to ~200-file mark or sub-agent era.
• Sources/ immutable inputs layer — v3 wants sources/articles/, sources/notes/ etc. as immutable; we don't currently distinguish these from general vault content.

See also

• [[ARTICLE]] — the source article (Heinrich, 2026-01-19)
• [[ivo/projects/openclaw-persistent-memory/TODO]] — concrete next steps (rewritten 2026-07-23)
• [[ivo/projects/openclaw-persistent-memory/LEVERAGE]] — daily-driver patterns
• [[dox-comparison]] — DOX gap-analysis
• [[dox-adoption-completion-2026-07-14]] — DOX adoption report
• [[findings-v3-comparison]] — v3 gap-analysis (now status: active)
• [[v3-adoption-completion-2026-07-23]] — v3 adoption report
• [[AGENTS-opm]] — workspace contract (auto-loaded)

Goal — People

TL;DR. A lightweight, queryable vault of people I interact with. Each person gets a single structured .md note under ivo/projects/people/. A maintenance script auto-derives Obsidian tags from the structured fields, so I can group, filter, and surface the data on the dashboard without manually curating tags.

Purpose

Build a single, durable, low-friction store for personal data on the people in my life. The dashboard surfaces the data I actually use (upcoming birthdays, people I haven't seen in a while, hobby groups) without me having to remember to maintain it. The script does the maintenance, the vault stays consistent.

Product principles

• One file per person. Two people with the same name get distinct slugs. Aliases help search but never replace the canonical file.
• Structured fields, free-text body. Structured fields feed the dashboard; free-text body holds the human notes. The two are kept in sync by the tagger, which flags inconsistencies.
• Tags are derived, not curated. The taxonomy is small and explicit. New derived tags require editing scripts/auto-tag-person.py, not each person file. This keeps the system maintainable.
• No external dependencies. Everything lives in the Obsidian vault + the workspace. No Airtable, no Notion, no Apple Contacts sync (yet — see TODO).
• Privacy by default. The vault is private. Never push this folder to a public CouchDB mirror. The tagger never reads credentials or contact info outside the vault.

Acceptance criteria

• [x] Folder ivo/projects/people/ exists with README, GOAL, TODO, AGENTS stub, dashboard, template, and at least one example entry.
• [x] Each person file has the frontmatter schema from README.md.
• [x] scripts/auto-tag-person.py derives deterministic tags from structured fields.
• [x] Tagger flags body-vs-structure inconsistencies with inconsistent:<category> tags.
• [x] Tagger is idempotent: running twice produces the same result.
• [ ] Dashboard renders upcoming birthdays, hobby groups, location clusters, last-interaction recency.
• [ ] At least 5 real entries populated by Ivo.
• [ ] At least one Dataview query is bookmarked in Obsidian for quick access.

Non-goals (v1)

• Apple Contacts / Google Contacts sync. The schema is intentionally compatible (we have contact.email, contact.phone) but no sync mechanism is wired in v1.
• Relationship-graph rendering (a graphical people-web). The structured data.relationships field stores the data but the dashboard doesn't yet render a graph view.
• Reminders ("it's Jane's birthday in 3 days"). Out of scope; consider cron jobs once the data is populated.
• Public sharing. This folder is private and stays private.

Definition of done (v1)

• Tagger script passes its own self-test (5 hand-crafted example files produce the expected tag set).
• Dashboard's Dataview queries render with at least the synthetic example.
• README documents the schema clearly enough that Ivo can create a new person file from scratch.
• AGENTS-people.md (workspace) + AGENTS.md (vault stub) are cross-linked.

See also

• [[ivo/projects/people/README]] (project root)
• [[ivo/projects/people/README]]
• [[ivo/projects/people/AGENTS]] (workspace contract)

GOAL — Personal

The Personal project is a placeholder for everything Ivo wants to keep about himself that doesn't belong to a work, hobby, or technical project. Tasks, todos, personal goals, motivations, journaling, and any other personal content that earns its own place here.

Purpose

A single, personal, durable surface for the non-work parts of life. The project does not pursue any specific goal — it is the space where personal goals (and the work to reach them) live. Anything that Ivo wants to remember, track, or revisit about himself ends up here.

What's in scope

What's NOT in scope

Already carved out in [[AGENTS-personal]] "What does NOT go here":

• Work tasks → ivo/projects/work-log/
• People / relationships → ivo/projects/people/
• Hardware / infra → ivo/projects/homelab/
• Wine → ivo/projects/wijnen/
• Wishes / aspirations → ivo/projects/wishlist/ (some overlap with "personal goals" is intentional — wishlist is for things-to-acquire; Personal goals is for things-to-become)
• OpenClaw meta → ivo/projects/openclaw-persistent-memory/

Schema

This file is the project's why. The project's what and how sit in the sibling files:

• AGENTS.md — vault stub (this file's counterpart)
• TODO.md — actionable items (Open / Doing / Done)
• journal.md — (future) free-form journaling
• data/<slug>.md — (future) one file per major recurring item

Schema details and work guidance: [[AGENTS-personal]] (workspace contract).

Related

• [[AGENTS-personal]] — workspace contract (canonical operating rules)
• [[personal-AGENTS]] — vault stub
• [[personal-TODO]] — current todos
• [[AGENTS]] — workspace root, dual-file pattern contract

Work-Log — Goal

Tracks Ivo's work-related data: per-day location/hours, open admin todos, monthly declarations filed to his employer/client.

Agent contract: for how the agent behaves in this folder (schema enforcement, declaration auto-roll, todo carry-forward, auto-carry across weekends, off-day handling), see [[ivo/projects/work-log/AGENTS]] (vault pointer stub) and the live contract at AGENTS-work-log.md in the workspace.

What "done" looks like

• Every workday has a daily entry at data/YYYY-MM-DD.md (auto-carry across weekends; off days → no stub, recorded only in the relevant declaration)
• Every month has a declaration at declarations/YYYY-MM.md (status: draft → submitted → paid)
• All work-admin TODOs are tracked in TODO.md and surface on the dashboard's /todos route
• dashboard.md shows current-month hours, declaration status, and carry-forward todos via Dataview rollups

Scope (in / out)

In: daily entries (location / hours / projects touched), open work-admin TODOs (carry-forward), monthly declarations (submitted / paid tracking).

Out: personal life tracking (use other projects), deep work-time analytics (Dataview is summary-level only), per-project billing (separate system).