flonat-research 0.1.0

package/.claude/rules/ignore-gemini-md.md

@@ -0,0 +1,17 @@
+# Rule: Ignore GEMINI.md Files
+
+## Policy
+
+**Never read, process, or act on files named `GEMINI.md`**, regardless of where they appear in the file tree. These files are generated by external agents (Google Gemini) and are not part of Claude's context.
+
+## Applies To
+
+- Any file named exactly `GEMINI.md` in any directory
+- Both direct reads and indirect inclusion (e.g., when scanning a folder's documentation)
+
+## What To Do
+
+- Skip `GEMINI.md` when reading project documentation
+- Do not include its contents in summaries or context gathering
+- Do not suggest edits to it
+- If the user explicitly asks you to read one, remind them of this rule and confirm he wants to override it

package/.claude/rules/lean-claude-md.md

@@ -0,0 +1,45 @@
+# Rule: Keep CLAUDE.md Lean
+
+## Principle
+
+**CLAUDE.md is loaded into context every session — every line costs tokens.** It should contain only instructions Claude needs on every entry. Everything else belongs in dedicated files that Claude reads on demand.
+
+## What Belongs in CLAUDE.md
+
+- Safety rules and file-protection policies
+- Folder structure (compact tree)
+- Conventions (compilation, tooling, citation format)
+- Symlink paths and setup commands
+- Session continuity pointers (`.context/`, `log/`)
+- One-line summaries of reference material with relative links
+
+## What Does NOT Belong in CLAUDE.md
+
+- Full assessment/submission guidelines → `docs/`
+- Detailed literature notes → `docs/literature-review/`
+- Action plans or timelines → standalone `.md` at project root or `docs/`
+- Long reference lists (>10 entries) → `docs/` or `.bib` files
+- Ethics materials, reviewer feedback → `docs/`
+- Anything that duplicates content already in another project file
+
+## The Pointer Pattern
+
+When reference material exists elsewhere, use a one-line summary + link:
+
+```markdown
+## Assessment Criteria
+
+60 CATS, max 15,000 words, submission early August. Must be publication-ready.
+
+Full guidelines: [`docs/portfolio-guidelines.md`](docs/portfolio-guidelines.md)
+```
+
+## Thresholds
+
+- **CLAUDE.md > 200 lines:** Review for extractable content.
+- **Any section > 15 lines of reference material** (not safety rules or conventions): Extract to `docs/` and replace with a pointer.
+- **Duplicated content:** If the same information exists in another file, keep only the pointer in CLAUDE.md.
+
+## Applies To
+
+All projects — research, code, infrastructure, personal. The principle is universal: CLAUDE.md is an instruction file, not a knowledge base.

package/.claude/rules/learn-tags.md

@@ -0,0 +1,99 @@
+# Rule: Record Learnings with [LEARN] Tags
+
+## Format
+
+```
+[LEARN:category] Incorrect → Correct
+```
+
+## Categories
+
+| Category | What to record |
+|----------|---------------|
+| `notation` | Math/LaTeX notation conventions (e.g., `$x_i$` vs `$x_{i}$`) |
+| `citation` | Bibliography and citation issues (wrong keys, format) |
+| `code` | Programming patterns, bugs, language-specific gotchas |
+| `method` | Econometric/statistical method corrections |
+| `domain` | Domain knowledge corrections (institutional details, definitions) |
+
+## When to Record
+
+- **Immediately** when a correction is discovered — do not batch
+- When the user corrects something during a session
+- When a compilation error reveals a recurring mistake
+- When a reviewer/supervisor flags an issue
+
+## Where to Write
+
+Append to `MEMORY.md` in the project root, under the matching category section.
+
+If `MEMORY.md` does not exist, create it using the Knowledge Base template below. To choose the right variant: check the project's `CLAUDE.md` for keywords like "course", "workshop", or "teaching" → use the **teaching** template. Otherwise → use the **research** template (default).
+
+## Tier Routing
+
+Learnings are routed to one of two files based on portability:
+
+| Tier | File | Committed? | Examples |
+|------|------|-----------|----------|
+| Generic | `MEMORY.md` (project root) | Yes | Notation conventions, method corrections, citation fixes, design decisions |
+| Machine-specific | `.claude/state/personal-memory.md` | No (gitignored) | Local path workarounds, tool version quirks, machine-specific build flags |
+
+**Decision rule:** "Would this help a collaborator on a different machine?" Yes → Generic. No → Machine-specific. **Default: Generic** (~95% of entries).
+
+Machine-specific examples:
+- `[LEARN:code] On this Mac, latexmk needs /Library/TeX path explicitly`
+- `[LEARN:code] uv 0.5.x on ARM has slow lock resolution — use --frozen`
+- `[LEARN:code] Zotero DB at ~/.local/share/user-papers/ not default path`
+
+If `.claude/state/personal-memory.md` does not exist, create it on first machine-specific entry (see `init-project-research` templates for the seed format). Create the directory too: `mkdir -p .claude/state`.
+
+## Examples
+
+```
+[LEARN:notation] In this paper, treatment is $D_i$ not $T_i$
+[LEARN:citation] Sant'Anna & Zhao (2020) key is santanna2020doubly not santanna2020
+[LEARN:code] R: use <- for assignment, not = (the user's preference)
+[LEARN:method] TWFE is biased with staggered treatment — use CS or Sun-Abraham
+[LEARN:domain] UK universities use "marks" not "grades" for assessment scores
+```
+
+## Knowledge Base in MEMORY.md
+
+Beyond one-liner `[LEARN]` tags, MEMORY.md should build structured knowledge tables. These are faster to scan than narrative and immediately actionable in new sessions.
+
+### Research Project Template
+
+When `MEMORY.md` is created for a research project, seed it with these sections:
+
+| Section | Columns | When to populate |
+|---------|---------|-----------------|
+| **Notation Registry** | Variable / Convention / Anti-pattern | When notation is first established or corrected |
+| **Estimand Registry** | What we estimate / Identification / Key assumptions | When research design is discussed |
+| **Key Decisions** | Decision / Rationale / Date | When a methodological choice is made |
+| **Citations** | One-liner corrections | On `[LEARN:citation]` |
+| **Anti-Patterns** | What went wrong / Correction | On `[LEARN:method]` or `[LEARN:domain]` |
+| **Code Pitfalls** | Bug / Impact / Fix | On `[LEARN:code]` |
+
+### Teaching Project Template
+
+For teaching or workshop projects, use these sections instead:
+
+| Section | Columns |
+|---------|---------|
+| **Lecture Progression** | Topic / Core question / Key method |
+| **Student Misconceptions** | Misconception / Correction / How to address |
+| **Empirical Applications** | Paper / Dataset / Purpose |
+
+### How [LEARN] Tags Feed In
+
+When recording a `[LEARN]` tag, also add the correction to the appropriate table:
+- `[LEARN:notation]` → Notation Registry
+- `[LEARN:code]` → Code Pitfalls
+- `[LEARN:method]` or `[LEARN:domain]` → Anti-Patterns or Key Decisions
+- `[LEARN:citation]` → Citations section (one-liners)
+
+## Important
+
+- Keep entries concise — one line per learning
+- Include the correction direction (wrong → right)
+- These accumulate over time and inform future sessions

package/.claude/rules/overleaf-separation.md

@@ -0,0 +1,67 @@
+# Rule: Overleaf Separation — No Code or Data in Paper Directories
+
+## Principle
+
+**The `paper/` directory (Overleaf symlink inside `paper-{venue}/paper/`) is for LaTeX source files ONLY.** All code, data, and computational artifacts belong in the project directory itself — never inside `paper/`.
+
+## What Belongs in `paper/`
+
+- LaTeX source files: `.tex`, `.sty`, `.cls`, `.bst`, `.bbl`
+- Bibliography files: `.bib`
+- Figures for the paper: `.pdf`, `.png`, `.eps`, `.jpg`, `.svg`, `.tikz`
+- LaTeX config: `.latexmkrc`, `latexmkrc`
+- Build output directory: `out/`
+
+## What NEVER Belongs in `paper/`
+
+- **Code files:** `.py`, `.R`, `.jl`, `.m`, `.sh`, `.ipynb`, `.do`
+- **Data files:** `.csv`, `.xlsx`, `.json`, `.dta`, `.parquet`, `.rds`, `.pkl`, `.feather`, `.h5`
+- **Computational output:** raw results, logs, intermediate artifacts
+- **Scripts that generate figures** — the script goes in `code/` or `src/`, only the exported figure goes in `paper/`
+- **Notebooks** — analysis notebooks belong in `code/` or `experiments/`, never in `paper/`
+- **Virtual environments, package files:** `.venv/`, `requirements.txt`, `pyproject.toml`, `renv/`
+
+## Where Code and Data Go Instead
+
+| Content | Location |
+|---------|----------|
+| Python/R scripts | `code/python/`, `code/R/`, or `src/` |
+| Data (raw) | `data/raw/` |
+| Data (processed) | `data/processed/` |
+| Generated figures | Export to `paper/figures/` or `paper/` directly (the *image file* only) |
+| Generated tables | Export `.tex` table files to `paper/` (the *table file* only) |
+| Experiment configs | `experiments/configs/` |
+| Results | `results/` or `output/` |
+
+## When This Applies
+
+- **Always.** Every research project, every session, no exceptions.
+- When creating new files — never place code/data inside `paper/`
+- When reorganising projects — move any code/data out of `paper/`
+- When writing scripts that generate outputs — script in project, output exported to `paper/`
+- When running `/init-project-research` — the scaffold already enforces this separation
+
+## What To Do If You Find Violations
+
+1. **Flag immediately:** "I found code/data files inside `paper/` — this violates the Overleaf separation rule."
+2. **Propose moves:** Show where each file should go in the project directory.
+3. **Wait for approval** before moving anything.
+4. **Never silently leave** code or data in `paper/`.
+
+## Overleaf Folder Lifecycle
+
+Creating a folder in the Overleaf root automatically creates an Overleaf project. This has implications for what Claude can and cannot do:
+
+| Action | Claude allowed? | Notes |
+|--------|:-:|-------|
+| **Create** | Yes | `mkdir` in the Overleaf root creates a project. Use during `/init-project-research` scaffolding. |
+| **Rename** | No — ask user | Renaming loses Overleaf project history. The user must rename via the Overleaf UI to preserve history. Flag as a manual TODO. |
+| **Delete** | Break the glass | Deleting a folder destroys the Overleaf project and all its history. Requires explicit confirmation per the `break-the-glass` rule. |
+
+**When scaffolding:** Ask if the Overleaf project already exists. If yes, get the folder name and symlink to it. If no, create the folder via `mkdir` and then symlink.
+
+**When renaming:** Never rename an Overleaf folder. Update the symlink to point to the new name only after the user confirms they've renamed it in the Overleaf UI.
+
+## Why This Matters
+
+`paper/` syncs to Overleaf. Code and data in Overleaf causes sync bloat, version confusion, and breaks the clean separation between the paper (collaborative, LaTeX-only) and the research project (local, computational). Overleaf is not a code repository.

package/.claude/rules/plan-first.md

@@ -0,0 +1,175 @@
+# Rule: Plan Before Implementing
+
+## When This Applies
+
+- Multi-file edits (touching 3+ files)
+- New features or significant additions
+- Unclear or ambiguous scope
+- Refactoring existing code or structure
+
+## When to Skip
+
+- Single-file fixes (typos, one-line bugs)
+- Running existing skills (`/proofread`, `/bib-validate`, etc.)
+- Informational questions ("What does this function do?")
+- Updating context files (`.context/current-focus.md`)
+
+## Assumption Check (Medium Tasks)
+
+For tasks that don't need a full plan but involve choices that could go wrong (1-2 files, clear goal, ambiguous *how*). This is the gap where most "wrong approach" friction occurs.
+
+**When this applies:**
+- Edits where output location, format, naming, or convention could be ambiguous
+- Any task where you're choosing between options without being told which
+- Merging, moving, or renaming files where the target path isn't explicit
+- Tasks where scope boundaries are fuzzy ("fix this" — just the bug, or also surrounding issues?)
+
+**What to do:**
+Before making changes, state in 2-4 lines:
+1. What you're about to do and which files you'll touch
+2. Key assumptions (target paths, format, naming conventions, scope boundaries)
+
+Then **wait for confirmation**. One word from the user ("yes", "go", thumbs up) is enough. No saved plan file needed.
+
+**Examples of assumptions worth stating:**
+- "I'll write output to `paper/figures/`, not `output/`"
+- "I'll use BBT-format keys from the existing .bib"
+- "I'll compile with Beamer, not reveal-md"
+- "I'll edit only the 3 lines you mentioned, not the surrounding block"
+- "I'll put the report in the current project directory, not the Projects root"
+
+**When to skip the assumption check:**
+- the user's instruction is fully explicit (exact file paths, exact format, exact scope)
+- The task is a direct follow-up where assumptions were already confirmed
+- the user says "just do it" or similar
+
+## Quick Mode
+
+When the task is clearly experimental or exploratory, skip the full planning protocol.
+
+**Triggers** (any of these):
+- the user says "quick", "try this", "experiment", "prototype", "just see if"
+- Task is a single-file script exploration or simulation test
+- the user explicitly says "skip planning"
+
+**What changes:**
+- Skip plan-first (no plan file, no approval step)
+- Orchestrator still runs but threshold drops to 60/100 (vs 80/90 normally)
+- Must-haves: code runs, results are correct, goal documented in a comment at the top
+- Not needed: docs, tests, perfect style, session log
+
+**What stays:** Verification (code must run), learn tags, all safety rules.
+
+**Kill switch:** the user can say "stop" or "abandon" at any point — no guilt, no cleanup needed.
+
+**Escalation:** If the exploration succeeds and the user wants to build on it, normal plan-first + orchestrator rules resume.
+
+## Protocol
+
+1. **Draft a plan** before writing any code or making changes
+2. **Save the plan** to `log/plans/YYYY-MM-DD_description.md`
+3. **Get approval** — present the plan to the user and wait for confirmation
+4. **Implement via orchestrator** — see `orchestrator-protocol.md` for the verify/review/fix/score loop. For tasks where the orchestrator doesn't apply (see its "When to Skip"), implement directly, noting any deviations.
+
+### Plan Format
+
+```markdown
+# Plan: [Short Description]
+
+## Context
+[Why this is needed]
+
+## Changes
+[List of files to create/modify with brief descriptions]
+
+## Order of Operations
+1. Write session log (`/session-log`)
+2. Update project context (`/update-focus` or `/save-context`)
+3. [Implementation steps...]
+
+## Risks / Open Questions
+[Anything that could go wrong or needs clarification]
+```
+
+## Phase Boundaries
+
+When a plan spans 2+ distinct activities (e.g., code + experiments + writing), split into phases with explicit stop points:
+
+1. Each phase gets its own session (or section of a session)
+2. At each phase boundary, create `HANDOFF.md` in the project root summarising:
+   - What was accomplished
+   - What outputs exist and where
+   - What the next phase should use
+3. Run `/session-log` at each boundary, not just at session end
+4. Do NOT start the next phase without the user's go-ahead
+
+Signs a plan needs phases: 5+ implementation steps, multiple distinct tool chains (Python + LaTeX), or estimated context usage that could hit compression.
+
+### Dependency Notation
+
+Phases declare `depends_on:` rather than relying on sequential numbering. This makes mid-pipeline entry and parallel work explicit:
+
+```markdown
+### Phase A: Literature Review
+depends_on: none
+### Phase B: Research Design
+depends_on: Phase A (partial — needs key papers identified)
+### Phase C: Data Collection
+depends_on: Phase B
+### Phase D: Code Pipeline
+depends_on: Phase B, Phase C
+### Phase E: Paper Draft
+depends_on: Phase D (results), Phase A (lit review complete)
+```
+
+### Mid-Pipeline Entry
+
+When resuming a project or starting mid-way through an existing plan:
+
+1. Read existing outputs to determine which phases are "satisfied"
+2. Mark satisfied phases as `[DONE]` in the plan
+3. Start from the first phase whose dependencies are all satisfied
+4. State explicitly: "Entering at Phase X — Phases A, B already satisfied because [evidence]"
+
+### Parallel Activation
+
+Phases with independent dependency chains can run concurrently. Flag these for the user:
+
+> "Phases C and D have independent dependencies — both can start now. Want to run them in parallel?"
+
+Do not auto-parallelise — let the user decide.
+
+### Re-Entry and Invalidation
+
+If a phase's output becomes invalid (e.g., data changes, design revision):
+
+1. Mark it `[INVALIDATED]` in the plan
+2. Cascade to all dependent phases — mark them `[INVALIDATED]` too
+3. State which phases need re-running and why
+4. Wait for the user's go-ahead before re-executing
+
+## Session Recovery
+
+When starting a new session or after context compression:
+
+1. Read the most recent file in `log/plans/`
+2. Read the most recent file in `log/`
+3. Read `.context/current-focus.md`
+
+This provides enough context to continue without re-explaining.
+
+## Execution Stall Detector
+
+When a plan already exists (in `log/plans/` or stated by the user), enforce execution momentum:
+
+- **2-message rule:** If 2 consecutive messages pass after a plan is confirmed and no file has been edited, STOP reading/auditing and start implementing immediately. Print: "Stall detected — starting execution now."
+- **No re-planning approved plans:** Do not re-read, re-audit, or re-draft a plan that the user has already approved. Start from step 1 and make changes.
+- **File-edit-first:** When implementing, make the first file change within your next response. Read only the files you need to edit, not the entire project.
+
+This rule exists because planning loops were the single biggest friction source across 232 sessions (53 wrong-approach events, multiple full sessions lost to re-planning without a single edit).
+
+## Important
+
+- **Never `/clear`** — rely on auto-compression to manage context
+- Plans are living documents — update them if scope changes mid-implementation
+- Quick plans (3-5 lines) are fine for medium tasks; full format for large ones

package/.claude/rules/read-docs-first.md

@@ -0,0 +1,50 @@
+# Rule: Read Documentation Before Searching
+
+## Principle
+
+**Never explore when documentation already answers your question.** Broad codebase searches (Glob, Grep, web searches) burn tokens and time. Project docs exist precisely to avoid this.
+
+## On Every New Session
+
+Before doing any work, read these files **in order** (they are fast reads, not searches). The `startup-context-loader.sh` hook auto-loads most of these, but follow the pointers in case you need more detail:
+
+1. `CLAUDE.md` — already auto-loaded, but follow its pointers
+2. `.context/current-focus.md` — what the user is working on NOW
+3. `.context/projects/_index.md` — overview of all projects
+4. `MEMORY.md` (if it exists) — structured knowledge tables and `[LEARN]` corrections
+5. The latest file in `log/` — where the last session left off
+6. The latest file in `log/plans/` (if any) — where the last plan left off
+
+This takes seconds and prevents minutes of aimless searching.
+
+## Before Any Search
+
+When you need information about the project, check in this order:
+
+1. **CLAUDE.md and .context/ files** — they cover identity, projects, workflows, conventions
+2. **Project-specific docs** (README.md, docs/ folder) — they cover that project's structure
+3. **Existing code comments and docstrings** — read the relevant file directly
+4. **Only then** use Grep/Glob for targeted searches
+5. **Web search is a last resort** — never search the web for something already documented locally
+
+## Anti-Patterns (Do NOT Do These)
+
+- Globbing for `**/*.md` across the entire repo to "find" documentation you were already told about
+- Grepping for keywords when CLAUDE.md explicitly lists where things are
+- Using the Explore agent to "understand the codebase" when `.context/` files describe it
+- Web-searching for tool usage or conventions that are documented in project files
+- Reading 10+ files "to understand context" when current-focus.md summarizes it
+
+## For Other Projects (Not Task Management)
+
+When starting a session in a research project:
+
+1. Read that project's `CLAUDE.md` (if it exists)
+2. Read that project's `MEMORY.md` (if it exists) — notation, decisions, pitfalls
+3. Read that project's `README.md` (if it exists)
+4. Check for a `docs/` folder
+5. Only then explore the file tree
+
+## Why This Matters
+
+the user's context library (`.context/`) is specifically designed to give you everything you need upfront. Ignoring it to do your own research wastes tokens and produces worse results because you miss the curated context.

package/.claude/rules/scope-discipline.md

@@ -0,0 +1,28 @@
+# Rule: Scope Discipline
+
+## Principle
+
+**Only make changes the user explicitly requested.** Do NOT fix additional issues you notice (e.g., extra proofreading, reformatting, style improvements) unless asked. When in doubt, list what you'd like to also fix and ask for permission.
+
+## What This Means
+
+- If asked to fix 6 issues, fix exactly those 6 — not 6 plus 3 more you spotted
+- If asked to proofread major issues, do not also fix minor ones
+- If asked to update one file, do not "while I'm here" edit neighbouring files
+- If asked to add a feature, do not also refactor surrounding code
+
+## When You Notice Something Else
+
+1. Complete the requested task first
+2. At the end, mention what else you noticed: "I also spotted X, Y, Z — want me to fix those too?"
+3. Wait for explicit approval before touching anything beyond scope
+
+## Exceptions
+
+- **Security vulnerabilities** — fix immediately and flag to the user
+- **Broken compilation** caused by your own changes — fix as part of the current task
+- **Trivial typos in lines you're already editing** — acceptable if truly on the same line
+
+## Why This Matters
+
+Scope overreach forces reverts, wastes time, and erodes trust. Doing less than asked is annoying; doing more than asked is destructive.

package/.claude/settings.json

@@ -0,0 +1,125 @@
+{
+  "permissions": {
+    "deny": [
+      "Bash(pip install:*)",
+      "Bash(pip3 install:*)",
+      "Bash(pip:*)",
+      "Bash(pip3:*)",
+      "Bash(python -m:*)",
+      "Bash(python3 -m:*)",
+      "Bash(python:*)",
+      "Bash(python3:*)"
+    ],
+    "allow": [
+      "Edit",
+      "Glob",
+      "Grep",
+      "Read",
+      "WebFetch",
+      "WebSearch",
+      "Write",
+      "Bash(curl:*)",
+      "Bash(gh:*)",
+      "Bash(git add:*)",
+      "Bash(git commit:*)",
+      "Bash(git diff:*)",
+      "Bash(git log:*)",
+      "Bash(git push:*)",
+      "Bash(git status *)",
+      "Bash(latexmk *)",
+      "Bash(ls:*)",
+      "Bash(mkdir:*)",
+      "Bash(pdflatex *)",
+      "Bash(tree:*)",
+      "Bash(uv:*)",
+      "Bash(wc:*)",
+      "Bash(which:*)",
+      "Bash(xelatex *)"
+    ]
+  },
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$HOME/.claude/hooks/startup-context-loader.sh"
+          }
+        ]
+      },
+      {
+        "matcher": "resume",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$HOME/.claude/hooks/resume-context-loader.sh"
+          }
+        ]
+      },
+      {
+        "matcher": "compact",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 $HOME/.claude/hooks/postcompact-restore.py"
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$HOME/.claude/hooks/protect-source-files.sh"
+          }
+        ]
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$HOME/.claude/hooks/block-destructive-git.sh"
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$HOME/.claude/hooks/promise-checker.sh"
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Bash|Task",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 $HOME/.claude/hooks/context-monitor.py",
+            "timeout": 5000
+          }
+        ]
+      }
+    ],
+    "PreCompact": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 $HOME/.claude/hooks/precompact-autosave.py"
+          }
+        ]
+      }
+    ]
+  }
+}

package/.context/current-focus.md

@@ -0,0 +1,33 @@
+# Current Focus
+
+> Last updated: 2026-02-20
+
+## This Week's Goals
+
+1. Finish draft of Paper 1 (decision making under uncertainty)
+2. Prepare slides for supervisor meeting on Friday
+3. Review literature on experimental design for Paper 2
+
+## Active Sessions
+
+### 2026-02-20 — Paper 1 drafting
+- Completed methodology section
+- Started results section — need to finish Table 2
+- Open loop: waiting for co-author feedback on introduction
+
+### 2026-02-18 — Literature review
+- Found 12 new papers on choice architecture
+- Updated bibliography with 8 new entries
+- Next: synthesise findings into lit review section
+
+## Open Loops
+
+| Loop | Status | Next action |
+|------|--------|-------------|
+| Paper 1 intro feedback | Waiting | Follow up with co-author by Friday |
+| Ethics application | Submitted | Check portal next week |
+| Conference abstract | Due March 15 | Draft after Paper 1 is sent |
+
+## Mental State
+
+Focused. Paper 1 is the priority — everything else can wait until it's submitted.

package/.context/preferences/priorities.md

@@ -0,0 +1,36 @@
+# Priority Framework
+
+> How to help the user prioritise tasks.
+
+## Principle: Priority is Contextual
+
+Priority depends on three factors:
+
+1. **Deadlines** — hard deadlines (journal, conference, supervisor) always win
+2. **PhD Progress Impact** — does this move the PhD forward?
+3. **Blocking Others** — is someone waiting on this?
+
+## Priority Matrix
+
+| Deadline | PhD Impact | Blocking? | Priority |
+|----------|-----------|-----------|----------|
+| < 48h | Any | Any | **Critical** |
+| < 1 week | High | Yes | **High** |
+| < 1 week | High | No | **High** |
+| < 2 weeks | Medium | Yes | **Medium** |
+| < 2 weeks | Medium | No | **Medium** |
+| None | Low | No | **Low** |
+
+## Anti-Patterns
+
+- Making everything high priority
+- Urgency without importance
+- Perfectionism before "good enough"
+- Ignoring soft deadlines until they become hard
+
+## How AI Should Help
+
+- Ask about deadlines before assigning priority
+- Check if someone is waiting on this
+- Consider energy and time of day
+- Don't create false urgency