@aitne-sh/aitne 0.1.0

package/agent-assets/task-flows/setup.initial.md

@@ -0,0 +1,277 @@
+{context}
+
+## Task: Initial Setup — Create rules/management.md
+
+The user has started the initial setup from the dashboard. The dashboard
+Vault step already captured `settings.primary_language` (BCP-47 tag, e.g.
+`en` or `es`) and `settings.vault_mode` (`plain` or `obsidian`) — the
+latter controls how the **primary management vault** is laid out, not the
+separate external Obsidian integration. Do NOT re-ask those questions.
+Use `primary_language` to decide the language of user-editable prose
+(profile, today, journal) per B-007 §3 P6.
+
+SETUP-FLOW-REDESIGN-PLAN §5.8 — the legacy "tool selections" form was
+removed. Steps 4–6 of the wizard (Mail, Calendar, Note) already
+configured the user's integrations, so you derive the Source-of-Truth
+rows yourself and confirm them rather than asking from scratch.
+
+Your role is to derive an initial Source-of-Truth table from the
+configured integrations, confirm it with the user, gather the two
+remaining management preferences, and generate rules/management.md.
+This is a multi-turn conversation — subsequent user messages will
+arrive via session resume.
+
+**Always respond in the same language the user uses.** Match the
+user's language from the very first message.
+
+### Step 0 (silent, agent-owned) — Derive Source-of-Truth rows
+
+Read integration state and the external-vault path **from the prompt
+context tags** the daemon injects on every turn. Do NOT curl `GET
+/api/integrations` or `GET /api/config` for this step — both are
+Approve-tier (Bearer-only) and the agent's session has only an
+`X-Read-Token`, so those two reads will 401. (Other curls in this
+file — e.g. `PUT /api/context/user/profile` — are Autonomous-tier and
+work normally.)
+
+Tags available in the prompt:
+
+- `<integration_modes …/>` — one attribute per integration. Always
+  present, always covers every key. Example:
+  `<integration_modes gmail="disabled" google_calendar="direct" notion="delegated" notion_delegated_to="claude" outlook_calendar="disabled" outlook_mail="disabled" git="disabled" github="disabled" />`.
+  Values are `direct | delegated | disabled`.
+- `<obsidian_vault_path>…</obsidian_vault_path>` — emitted **iff** the
+  user has configured an external Obsidian vault. **Absence means the
+  user has no external Obsidian vault** (treat as "no").
+- `<settings primary_language="…" vault_mode="…" />` — primary
+  language and primary-vault layout (`plain` | `obsidian`).
+
+Apply these deterministic rules to draft the four rows:
+
+| Source-of-Truth row | Derive from |
+|---|---|
+| Schedule | `google_calendar != "disabled"` → `Google Calendar`; else `outlook_calendar != "disabled"` → `Outlook Calendar`; else ask the user |
+| Notes | `<obsidian_vault_path>` tag present → `Obsidian`; else `notion != "disabled"` → `Notion`; else ask the user |
+| Tasks | `notion != "disabled"` → `Notion`; else `Obsidian` if `<obsidian_vault_path>` tag present; else ask the user |
+| Projects | same precedence as Tasks |
+
+Surface the derived table back to the user in the first message
+("Here's what I picked up from your setup — does this look right?")
+and ask **only** about rows you could not infer. Typical outcome:
+zero or one follow-up question.
+
+Defensive fallback: if `<integration_modes …/>` is somehow missing
+from the prompt (shouldn't happen — `context-builder.ts` emits it
+unconditionally before any routine-specific branch), ask the user
+about all four rows rather than fabricating defaults. Do not retry
+with a curl.
+
+### Instructions
+1. Run Step 0 silently. Greet the user in one line, introducing
+   yourself by the name in `<agent_identity>` display_name. Then
+   present the derived Source-of-Truth table and ask any remaining
+   row + the two preference questions in the same turn. Do NOT label
+   anything "Q1", "Q2", etc. — speak naturally.
+2. Ask the two preference questions in a single message:
+   - Communication style preference (how should the agent talk to you?)
+   - Project-management method preferences (anything you want the agent
+     to follow when handling your projects?)
+   Either answer may be "no preference" / "skip" — accept that cleanly.
+3. Once the user has answered, generate rules/management.md inside a
+   ```management-rules code block. This triggers the dashboard preview.
+4. If the user requests changes, revise. Complete within **at most 2
+   revision rounds**.
+5. **Do NOT put communication style inside rules/management.md, and do NOT
+   put it inside `user/profile.md` either.** Tone / style / voice / emoji
+   / language preferences live in the `character` runtime-config field
+   only — emitted as a ```character``` code block (see step 6.5). See
+   `docs/design/15-character.md` for the split rule.
+6. In the same turn as the management-rules block, silently call
+   PUT /api/context/user/profile using the template in "user/profile.md
+   Format" below. Working hours and quiet hours are pre-populated with
+   defaults (Weekdays 09:00–18:00, Quiet hours 22:00–08:00) — do not
+   ask about them. Fill Platforms from the **derived Source-of-Truth
+   table** (Step 0) — the row values you confirmed with the user.
+   Leave Identity blank — setup does not collect name or timezone.
+6.5. If the user stated a communication-style preference in step 2,
+   emit a ```character``` code block in the same turn (see "Character
+   code block format" below). If the user skipped, omit the block.
+7. If the conversation surfaced detail-heavy facts that belong in the
+   detailed profile layer, also PATCH the matching user/*.md file in the
+   same turn. Typical Q&A → file mappings:
+     - Named colleagues, family, friends → user/people.md
+     - Current company, role specifics, ongoing projects → user/work.md
+     - Specific frameworks, years of experience → user/expertise.md
+       (user/profile.md ## Expertise keeps a one-line summary only)
+     - Long-term goals, aspirations → user/goals.md
+     - Hobbies, lifestyle habits, dietary notes → user/personal.md
+   Only seed what the user actually stated — do not invent or infer. If
+   nothing came up for a given file, do not touch it. See the user-profile
+   skill for the read-before-write PATCH recipe.
+8. Keep the updates in steps 6–7 silent — the dashboard handles saving
+   rules/management.md separately when the user approves the preview. Do
+   not create or modify any other context files; the daemon seeds the
+   rest of the primary-vault scaffold automatically.
+
+### Questions to ask (do NOT show these labels to the user)
+
+Ask both in a single natural message:
+
+- **Communication style** — how should the agent talk to you? (e.g.,
+  be concise, speak casually, no emojis, end every reply with a
+  period, etc.) Skip if no preference.
+- **Project-management method** — any preferences for how the agent
+  should handle your projects? (e.g., break work into weekly
+  milestones, always produce a design doc before code, prefer GitHub
+  issues over markdown TODOs, etc.) Skip if no preference.
+
+Notification hours and working hours are NOT asked here — they default
+to quiet hours 22:00–08:00 and working hours Weekdays 09:00–18:00, and
+the user can change them on the Settings page.
+
+### user/profile.md Format
+
+When you PUT /api/context/user/profile, write the full file in this shape so setup is deterministic:
+
+```
+---
+type: user
+owner: shared
+updated: 2026-04-21
+---
+# User
+> Primary profile injected into every session. Keep this file concise.
+> Detailed profile lives under `user/`.
+> Fetch index: `curl -s http://localhost:8321/api/context/user/_index`
+
+## Identity
+(leave bullets blank — setup does not collect name or timezone)
+
+## Work Pattern
+- Working hours: Weekdays 09:00–18:00
+
+## Platforms
+- Schedule: {from derived Source-of-Truth table}
+- Tasks: {from derived Source-of-Truth table}
+- Notes: {from derived Source-of-Truth table}
+- Projects: {from derived Source-of-Truth table}
+
+## Expertise
+- {one-line summary if the user mentioned their field; otherwise leave empty}
+
+## Notification Preferences
+- Quiet hours: 22:00–08:00
+
+## Learned Context
+
+## Raw Signals
+```
+
+Use today's YYYY-MM-DD for `updated` (the date above is only an example).
+Do not omit `## Notification Preferences` — Morning Routine reads it directly.
+
+### How to submit user/profile.md
+
+Use inline `-d '{"content": "..."}'` with `\n` escapes. Do NOT use
+`-d @-`, heredoc pipelines, or `--data-raw '@-'` — those have
+produced malformed bodies in this flow (server saw literal `@-` and
+returned 500).
+
+```bash
+curl -s -X PUT http://localhost:8321/api/context/user/profile \
+  -H 'Content-Type: application/json' \
+  -d '{"content": "---\ntype: user\nowner: shared\nupdated: 2026-04-23\n---\n<!-- DO NOT write tone / style / voice / formality / verbosity / emoji / language preferences in this file. Those are Character-field content — write them via PATCH http://localhost:8321/api/config/character with {\"character\": \"...\"}. This file is for USER FACTS only: identity, expertise, habits, relationships, goals. -->\n# User\n> Primary profile injected into every session.\n> Detailed profile lives under `user/`.\n> Fetch index: `curl -s http://localhost:8321/api/context/user/_index`\n\n## Identity\n\n## Work Pattern\n- Working hours: Weekdays 09:00–18:00\n\n## Platforms\n- Schedule: Google Calendar\n- Notes: Obsidian\n- Projects: Notion\n\n## Expertise\n\n## Notification Preferences\n- Quiet hours: 22:00–08:00\n\n## Learned Context\n\n## Raw Signals\n"}'
+```
+
+If the response is non-2xx, retry once with a smaller body or switch
+to section-level PATCH. Do not report the error to the user as a
+permission issue — the default allowlist includes `Bash(curl *)`.
+
+### Character code block format
+
+If the user answered the communication-style question with an actual
+preference (not "no preference" / "skip"), emit a ```character``` code
+block in the same turn the management-rules block is emitted:
+
+```character
+Speak casually. Tight bullets. No emojis.
+```
+
+Rules for the block body:
+- The body is raw text — no markdown, no outer quotes, no nested fences.
+- Stay under the 1000-char cap; surface the excess to the user rather
+  than silently truncating.
+- Emit **at most one** character block per turn.
+
+The dashboard extracts this block, stages it into an inline editor
+alongside the Management Rules Preview, and PATCHes `/api/config`
+atomically when the user clicks Save & Finish. **Do NOT call `/api/config/character` (or any `/api/config*`) yourself from the agent during setup.**
+
+If the user did not state a preference, omit the block entirely — the
+dashboard will leave the existing `character` value unchanged.
+
+The character value is written verbatim into every session's
+CLAUDE.md / AGENTS.md / GEMINI.md (between the safety preamble and
+the profile body) uniformly across Claude, Codex, and Gemini. Never
+write tone/style preferences into user/profile.md.
+
+### rules/management.md Format
+
+Fill the Source of Truth table from the **derived rows you confirmed
+with the user in Step 0** (Schedule / Tasks / Notes / Projects).
+Generate using this format:
+
+```management-rules
+---
+type: rule
+owner: shared
+updated: 2026-04-21
+---
+# Management Rules
+
+## Agent Identity
+- AI name: (copy from <agent_identity> display_name)
+- WhatsApp label: (copy from <agent_identity> whatsapp_label)
+
+## Source of Truth
+| Domain | Primary | Secondary |
+|--------|---------|-----------|
+| Schedule | {from derived table} | today.md |
+| Tasks | {from derived table} | today.md |
+| Notes | {from derived table} | — |
+| Projects | {from derived table} | projects/*.md |
+
+## Autonomy Levels
+- Routine operations (Morning/Evening): Autonomous
+- today.md updates: Autonomous
+- Notifications: Autonomous (within rules)
+- External service operations: Confirm with user
+- rules/management.md changes: Always confirm
+
+## Notification Rules
+- Quiet hours: 22:00–08:00 (default — adjustable in Settings)
+- Batch non-urgent notifications
+- Never notify during meetings (check calendar)
+- Daily limit: configurable in settings
+
+## Schedule
+- Working hours: Weekdays 09:00–18:00 (default — adjustable in Settings)
+- Morning routine: daily at day-boundary hour (default 04:00, configurable in settings)
+- Evening review: configurable
+
+## Project Management
+- {user's project-management-method answer verbatim, or "No specific preferences — follow standard project practices" if they skipped}
+```
+
+Use today's YYYY-MM-DD for `updated` (the date above is only an example).
+
+### Markdown formatting (the block is saved to disk verbatim)
+
+Reproduce the template's blank lines exactly — every `##` heading and
+every table must be preceded by a blank line. Never concatenate a
+heading onto the end of the previous list item (e.g. `- Label:
+<value>## Next Section` on one line). Copy user-provided values as-is,
+then newline, blank line, then the next heading.
+
+**Important**: Outputting a ```management-rules code block triggers the dashboard to display a preview.
+The dashboard handles saving when the user approves, so you do NOT need to save via curl.

package/agent-assets/task-flows/setup.update.md

@@ -0,0 +1,53 @@
+{context}
+
+## Task: Update Management Rules
+
+The user has started updating rules/management.md from the dashboard.
+The current rules are included in the <management_rules> tag.
+
+**Always respond in the same language the user uses.** Match the user's language.
+
+### Instructions
+1. First, briefly summarize the current rules.
+2. Ask the user which part they'd like to change, presenting these options:
+   - **Source of Truth** — Change tools
+   - **Notification Rules** — Notification timing and methods
+   - **Character (tone / style / voice)** — Update the `character` runtime-config field, emitted as a ```character``` code block (NOT `rules/management.md`, NOT `user/profile.md`)
+   - **Autonomy Levels** — Agent decision scope
+   - **Schedule** — Working hours
+   - **Project Management** — Preferences for how the agent should handle your projects
+   - **Other** — Specify freely
+3. If the user changes Character, read the current value with
+   `curl -s http://localhost:8321/api/config/character | jq -r .character`,
+   merge the edits, and emit a ```character``` code block containing the
+   new full value. Observe the 1000-char cap — surface the excess to the
+   user rather than silently truncating. **Do NOT call PATCH
+   /api/config/character yourself** — the dashboard persists the new
+   character atomically when the user clicks Save & Finish.
+4. If any management-rules sections changed, output the updated version in a ```management-rules code block.
+5. If the only change was Character, still output a ```management-rules``` block containing the unchanged current rules verbatim. This is required so the dashboard can show Save & Finish; the server treats identical content as a no-op on the management file and persists only the new character value.
+6. Allow **at most 2 revision rounds**.
+
+**Do not add a tone/style section to rules/management.md, and do not write tone preferences to user/profile.md.** Tone / style / voice lives in the `character` runtime-config field only.
+
+### Markdown formatting (the block is saved to disk verbatim)
+
+Preserve blank lines between sections — every `##` heading and every
+table must be preceded by a blank line. Never concatenate a heading
+onto the end of the previous list item (e.g. `- Label: <value>## Next
+Section` on one line).
+
+### Sections to preserve byte-for-byte
+
+When you re-emit the ```management-rules``` block, copy the following
+sections from the current `<management_rules>` verbatim — they are
+not part of the wizard's editable surface, and stripping them silently
+breaks downstream features:
+
+- **`## Agent Identity`** — populated by the daemon from `agentDisplayName`. Re-emit it as-is or omit it (the server upserts it on save).
+- **`## Active Policies`** — a static wikilink to `rules/policies/_index.md` placed by skeleton seeding. Owned by the management-policy capture flow (the wizard is read-only here). If it is missing from the current rules (legacy installs), do NOT invent it; the next skeleton run will add it.
+
+The same applies to any other section the wizard does not explicitly
+ask the user about — when in doubt, copy it through unchanged.
+
+**Important**: Outputting a ```management-rules code block triggers the dashboard to display a preview. Outputting a ```character``` code block stages the character edit into the dashboard's inline editor. The dashboard persists both on Save & Finish, so you do NOT need to call any `/api` endpoint.

package/agent-assets/templates/README.md

@@ -0,0 +1,85 @@
+# agent-assets/templates/
+
+Source templates used by the daemon at **fresh install** time to populate
+`~/.personal-agent/context/` with the B-007 vault layout. The daemon copies
+system / pass-through assets from here directly. User-facing scaffolds that
+must follow `primary_language` are seeded by the `setup.initial` agent flow.
+
+**Language policy (B-007 §3 P6)** — template source lives here in English.
+System prose templates (`rules/redaction.md`, `context-index.md`,
+`agent/journal.md`, `.base` files) stay English regardless of locale.
+User-facing scaffolds (`today.md`, `roadmap.md`, `_index.md`,
+`routines/*.md`, `rules/journal-format.md`, `rules/journal-export.md`,
+`user/profile.md`) are created in the user's `primary_language` by the
+setup conversation before `save-rules` finalizes setup.
+
+Two rendering paths:
+1. **Pass-through** — the file is copied verbatim. Used for system prose
+   and `.base` files.
+2. **Localized scaffold** — the setup conversation uses these files as the
+   English reference for the shape of user-facing notes, then writes the
+   actual runtime file in `primary_language` via the context API.
+
+Files prefixed `_` (e.g. `_active.base`) are Obsidian sidebar-sort
+conventions — the leading underscore floats them to the top.
+
+**`today.md` and `roadmap.md`** are shape-canary templates. They are
+copied verbatim by `skeleton.ts:ensureSkeletonFiles` when the templates
+tree is reachable; when the tree is unreachable, `skeleton.ts` falls
+back to an inline literal in `FALLBACK_PLACEHOLDERS` that is kept
+byte-equal to these template files. A unit test
+(`packages/daemon/src/core/skeleton.test.ts:"shape canary ..."`)
+asserts this equality on every CI run, so a PR that updates one path
+without the other fails at review time. Edit the template file; the
+inline fallback and any relevant validators must be updated in the
+same PR.
+
+## Template versioning — upgrade contract (course 4 of the design audit)
+
+Every template file whose content may evolve carries a
+`template_version: N` field in its YAML frontmatter. The shipped
+inventory lives at `_manifest.json` (auto-generated) alongside the
+templates. When a template's format changes:
+
+1. **Bump `template_version` in the template file's frontmatter** (e.g.
+   1 → 2 when `rules/management.md` gains a new required section).
+2. **Regenerate `_manifest.json`** so the `version` entry matches. A
+   unit test (`template-versions.test.ts:"shipped manifest consistency"`)
+   fails the build if the two disagree.
+3. **Ship the release.** On the user's next daemon start,
+   `checkTemplateUpgrades` (`packages/daemon/src/core/template-versions.ts`)
+   walks each user-side file, reads its `template_version` from
+   frontmatter, compares against the manifest, and persists the pending
+   list in `runtime_state.templates.pending`. `/api/health.templatesPending`
+   surfaces the list for the dashboard.
+
+### What is NOT done automatically
+
+- **No content overwrite.** The detection is observational only. The
+  user's current file is left untouched; a merge-aware "apply upgrade"
+  UX is scheduled for a later phase.
+- **No alert for user-rewritten files.** If a user stripped the
+  `template_version:` field entirely (or replaced the file with
+  something unrelated), the daemon treats it as user-owned and stays
+  out of the way.
+- **No alert when the user version is AHEAD of the manifest.** Advanced
+  users can lock a file at a custom version to prevent spurious
+  pending-upgrade signals.
+
+### Files excluded from versioning
+
+- `today.md`, `roadmap.md`, `projects/_active.base` — no frontmatter to
+  carry the marker. These files are shape canaries / Obsidian view
+  configs that evolve through schema validation, not template diff.
+- `README.md` (this file) — documentation, not a template.
+
+Bump `manifestVersion` in `_manifest.json` only when the manifest
+schema itself changes (e.g. a new per-entry field). Individual
+template-version bumps leave `manifestVersion` alone.
+
+See `docs/design/06-memory.md` and `docs/design/12-configuration.md` for the
+fresh-install flow and vault layout. The `rules/management.md` template
+follows the structured `schema_version: 3` registry specified in
+`docs/design/21-management-registry-and-entities.md` (A. SoT bindings,
+B. Managed tasks, C. Active-Policies stub) — the v2 "Default Schedules"
+section has been retired (§21 §8.10); do not reintroduce it.

package/agent-assets/templates/_index.md

@@ -0,0 +1,39 @@
+---
+type: index
+owner: shared
+updated: 2026-04-22
+template_version: 1
+---
+# Aitne Vault
+
+This directory is shared by the agent and me. The agent writes most of it;
+I can edit any file and my edits are preserved (see `rules/management.md`
+for conflict handling).
+
+## Where things live
+
+- **About me** → `user/` (profile, people, work, expertise, personal, goals)
+- **Today / Roadmap** → root-level `today.md` and `roadmap.md`
+- **Yesterday snapshot** → yesterday.md appears after the first morning
+  rotation and is replaced by the next one
+- **Projects** → `projects/`; project notes use the projects/<slug>.md
+  naming pattern. See `projects/_index.md` or open `projects/_active.base`
+  in Obsidian
+- **Daily archives** → `daily/` files named by date (synthesized journal)
+- **Weekly / Monthly reviews** → `weekly/`, `monthly/`
+- **Agent self-reflection** → `agent/journal.md` (internal; never pushed
+  as a notification)
+- **Rules & policies** → `rules/` (how the agent should behave — edited by
+  either of us)
+- **Routines** → `routines/` (per-cadence check-list rulebooks)
+- **Dump bucket** → `inbox/` (paste anything here; I'll triage on next
+  morning routine)
+
+## How the agent reads/writes this
+
+All writes go through the context API (locked + snapshotted). Read: direct.
+`Edit`/`Write` tools are not available to the agent — the API is the only
+chokepoint.
+
+This file is human-readable navigation. The agent's canonical file catalog
+is `context-index.md`, maintained from the filesystem.

package/agent-assets/templates/_manifest.json

@@ -0,0 +1,103 @@
+{
+  "manifestVersion": 1,
+  "generatedAt": "2026-04-23",
+  "notes": "Auto-generated inventory of versioned templates. Each entry's 'version' must equal the `template_version:` field in the corresponding template file's frontmatter. Bump both in the same PR. A unit test asserts this consistency.",
+  "templates": {
+    "_index.md": {
+      "version": 1
+    },
+    "agent/journal.md": {
+      "version": 1
+    },
+    "agent/profile-questions.md": {
+      "version": 1
+    },
+    "context-index.md": {
+      "version": 1
+    },
+    "dossiers/_index.md": {
+      "version": 1
+    },
+    "dossiers/evening.md": {
+      "version": 1
+    },
+    "dossiers/hourly.md": {
+      "version": 1
+    },
+    "dossiers/monthly.md": {
+      "version": 1
+    },
+    "dossiers/morning.md": {
+      "version": 1
+    },
+    "dossiers/roadmap.md": {
+      "version": 1
+    },
+    "dossiers/weekly.md": {
+      "version": 1
+    },
+    "projects/_index.md": {
+      "version": 1
+    },
+    "routines/_index.md": {
+      "version": 1
+    },
+    "routines/evening.md": {
+      "version": 1
+    },
+    "routines/hourly.md": {
+      "version": 1
+    },
+    "routines/monthly.md": {
+      "version": 1
+    },
+    "routines/morning.md": {
+      "version": 1
+    },
+    "routines/weekly.md": {
+      "version": 1
+    },
+    "rules/_index.md": {
+      "version": 2
+    },
+    "rules/journal-export.md": {
+      "version": 1
+    },
+    "rules/journal-format.md": {
+      "version": 1
+    },
+    "rules/management.md": {
+      "version": 2
+    },
+    "rules/mcp.md": {
+      "version": 1
+    },
+    "rules/policies/_index.md": {
+      "version": 2
+    },
+    "rules/redaction.md": {
+      "version": 1
+    },
+    "user/_index.md": {
+      "version": 1
+    },
+    "user/expertise.md": {
+      "version": 1
+    },
+    "user/goals.md": {
+      "version": 1
+    },
+    "user/people.md": {
+      "version": 1
+    },
+    "user/personal.md": {
+      "version": 1
+    },
+    "user/profile.md": {
+      "version": 2
+    },
+    "user/work.md": {
+      "version": 1
+    }
+  }
+}

package/agent-assets/templates/agent/journal.md

@@ -0,0 +1,10 @@
+---
+type: journal-entry
+owner: agent
+updated: 2026-04-17
+language: en
+template_version: 1
+---
+# Agent Journal
+
+> Agent self-reflection. Always English (B-007 §3 P6).

package/agent-assets/templates/agent/profile-questions.md

@@ -0,0 +1,74 @@
+---
+type: agent_questions
+owner: agent
+updated: 2026-04-26
+language: en
+template_version: 1
+---
+# Profile Interview Queue
+
+> Agent-internal — never auto-injected into prompts. The agent picks at
+> most one Pending question per agent-day and writes it to ## In Progress
+> as `state=latent`. Latent questions wait for a natural opportunity in
+> DM (a topic-related inbound message, the morning briefing) and are NOT
+> scheduled as cold standalone DMs by default. Falls back to a scheduled
+> DM only after 3 days of no opportunity. Answers flow back through the
+> normal user-profile capture path.
+>
+> Schema and operations: `agent-assets/skills/user-interview/SKILL.md`.
+
+## Pending
+
+### Identity
+- [ ] (HIGH) name :: user/profile.md ## Identity :: match=Name :: preferred name or alias (real name not required)
+- [ ] (HIGH) timezone :: user/profile.md ## Identity :: match=Timezone :: IANA timezone (e.g. Asia/Tokyo)
+
+### Personal
+- [ ] (HIGH) location :: user/personal.md ## Location :: city / region where the user lives (affects weather, time, recommendations)
+- [ ] (MID) sleep_pattern :: user/personal.md :: match=Sleep :: typical sleep window on weekdays / weekends (user-profile skill writes a `- Sleep:` bullet to user/personal.md when the user states their schedule)
+- [ ] (MID) hobbies :: user/personal.md ## Hobbies :: hobbies, recurring leisure activities
+- [ ] (LOW) origin :: user/personal.md ## Background :: where the user is from (city / cultural background)
+- [ ] (LOW) diet :: user/personal.md ## Diet :: dietary preferences or restrictions
+
+### Work
+- [ ] (HIGH) employer_role :: user/work.md ## Company :: current employer and role (or freelance / student)
+- [ ] (MID) tech_stack :: user/work.md ## Stack :: tools / languages / frameworks used at work
+- [ ] (LOW) team :: user/work.md ## Team :: team size and frequent collaborators
+
+### People
+- [ ] (MID) family :: user/people.md ## Family :: family composition (do not pry on detail)
+- [ ] (LOW) close_colleagues :: user/people.md ## Colleagues :: colleagues the user works with often
+
+### Goals
+- [ ] (MID) annual_goals :: user/goals.md ## Annual :: goals or themes for the year
+- [ ] (LOW) learning_targets :: user/goals.md ## Learning :: skills / topics the user wants to learn
+
+## In Progress
+
+> One entry per question currently being worked on. Format:
+>   `- <id> :: state=<state> :: since=<YYYY-MM-DD> [:: scheduled_at=<ISO>] [:: asked_at=<ISO>]`
+> The `since=` field is the agent-day the entry was first added; it is
+> preserved across `latent → asked → resolved` state transitions and is
+> what the evening sweep uses to compute the 3-day fallback threshold.
+>
+> State machine:
+>   `latent`    — picked by morning routine; awaiting a natural opportunity.
+>   `scheduled` — fallback only (≥3 days latent + active user); standalone
+>                 DM is registered, not yet fired.
+>   `asked`     — DM has been sent (any path); waiting for user reply.
+> The DM-handler queue-flip MUST gate on `state=asked` only.
+
+- (none)
+
+## Answered
+
+> Append-only log. Source markers:
+>   (DM)                       — user answered in chat
+>   (reconciled:skeleton)      — Layer 1 deterministic pre-tick
+>   (reconciled:morning)       — Layer 2 morning-routine pre-pick
+>   (reconciled:opportunity)   — Layer 3 DM-handler / briefing abort
+>   (reconciled:fire-time)     — Layer 3 fallback DM fire-time abort
+>   (reconciled:sweep)         — Layer 4 evening-sweep LLM reconcile
+>   (import:<source>)          — profile import migration
+
+- (none)