Add user profile, goals-as-priority lens, and relationship maintenance

[yustme]

What & why

Gives Scout a qualitative model of the user it serves. While surveying chief-of-staff / second-brain agents, three gaps stood out that Scout lacked (verified by grepping phases/): no qualitative user profile or communication contract, no goals layer filtering prioritization, and task-centric (not relationship-centric) tracking.

Guiding principle: auto-derive first, minimal manual input, value only where data can't reach. Scout derives most of the profile from connectors + the user's own Claude Code sessions and keeps it fresh (confidence-tagged, feedback-driven). Manual input is capped at one optional setup question.

Changes

Profile + communication contract — knowledge-base/profile/

• about-you.md — Scout-maintained snapshot (identity, key people, focus, working rhythm); derived, confidence-tagged, never clobbers hand edits.
• communication.md — authoritative contract for language / tone / length / cadence / escalation; refined by the feedback loop.
• goals.md — confirmed + proposed goals.
• Files use kind: profile (no type:) so the ontology parser ignores them.

Goals as a prioritization lens — action-items.md

• Confirmed goals order items within an urgency band and drive a digest goals/neglect lens. Strictly secondary: never overrides the deadline-distance ceiling, never surfaces noise. Goals are Scout-proposed from activity, user-confirmed.

Relationship maintenance — relationships.md (briefing-time) + last_interaction on person entities

• Cadence-aware reconnect nudges and aging-promise flags, low-key and governed by the communication contract.

Integration

• New core phase 00-about-you.md (empty mode → every assembled brain file): read profile first, comms contract authoritative.
• kb-management, claude-sessions, feedback-processing teach Scout to read / derive / refine the profile.

Migration for existing vaults

• Profile seeds replay idempotently on upgrade() (recorded as profile-files-v1), never clobbering edits.
• First post-upgrade run backfills derived data.
• New /scout-profile command: a gap-filling interview that asks only about what's still missing. /scout-setup adds one optional question; /scout-update points users to /scout-profile.

Tests

engine/tests/unit/test_profile_seed.py — install/upgrade seeding, edit preservation, parser invisibility, migration idempotence, and phase assembly into SKILL/DREAMING/RESEARCH. Full suite: 885 passing (one pre-existing flaky fswatch integration test passes in isolation).

[jordanrburger]

cc @AdamVyborny - I feel like we're getting to the point where we need to figure out how to let users have more configurable control over what sort of Scout features they use.

My first thought is to go straight with Skills, but it's more complicated than that. Honestly, I think it's worth chatting about for a bit to capture our thoughts. Some things here are universal enough to be merged, but I see a few bigger issues that need to be thought about:

• Because these "facets" of Scout need to be weaved into the different session type skills (i.e. dreaming, research, etc.) and they affect the behavior of the Vault, they are not easily reversible. Ofc, aside from just telling Claude to do it.
• Updates become heavier in terms of migration.
• We don't really have any clear guidance or procedures for dealing with "drift" and the accompanying conflicts that emerge.
• We need some standardized procedure for "back-porting" functionality from an individual's Scout vault (Vojta in this case) to the actual Scout engine.