Feature/themes page

.fp/extensions/tsconfig.json

@@ -0,0 +1,17 @@
+{
+  "compilerOptions": {
+    "target": "ESNext",
+    "module": "ESNext",
+    "moduleResolution": "bundler",
+    "strict": true,
+    "noEmit": true,
+    "paths": {
+      "@fiberplane/extensions": [
+        "/Users/mark/.fiberplane/extensions/types"
+      ]
+    }
+  },
+  "include": [
+    "*.ts"
+  ]
+}

.gitignore

@@ -6,3 +6,44 @@
 !fp-report.template.html
 
 **/.DS_Store
+
+# Fiberplane local issue tracking. Extensions are SOURCE (they define this project's
+# status workflow and label vocabulary, which the report mirrors) — track them. As above,
+# the directory must be re-included before anything inside it can be.
+.fp/*
+!.fp/remote.toml
+!.fp/extensions/
+.fp/extensions/**/node_modules/
+
+# Personal convenience symlinks (e.g. _fp-report -> fp-report.sh) — never committed
+/_*
+
+# Sokrates analysis. The rule above would swallow the whole _sokrates dir, so re-include
+# it first: git cannot un-ignore a file whose parent directory is still excluded.
+# Keep config.json (it defines the analysis); ignore everything Sokrates generates.
+!/_sokrates/
+_sokrates/reports
+_sokrates/findings
+_sokrates/history
+
+# fp-report's own label cache — derived from fp state, rebuilt on demand, ~100KB of churn
+# per run. Matched by name, not path, since OUTPUT_DIR is configurable.
+.fp-report.labels.json
+
+# Export bundles written outside dist/
+*.zip
+
+# Secrets. This tool reads no .env (config lives in fp-report.conf, which IS committed) —
+# this is a guard against one being dropped here by habit, not a supported config path.
+.env
+.env.*
+!.env.example
+
+# Editor / IDE
+.idea/
+.vscode/
+*.iml
+*.swp
+
+# Claude Code: shared project settings are committed, personal overrides are not
+.claude/settings.local.json

AGENTS.md

@@ -0,0 +1 @@
+@FP_AGENTS.md

CHANGELOG.md

@@ -6,7 +6,47 @@ template, or tooling — not the issue data a given report happens to show.
 
 ## [Unreleased]
 
+### Changed
+- **The template is now a directory of parts** (`template/`): the page shell plus
+  `styles/*.css` and `app/*.js`, inlined at render time via `<!--#include path -->`.
+  The output is unchanged — still one self-contained HTML file, verified byte-identical
+  to the previous monolith — but the 880-line file is now eleven files of 10–210 lines.
+  The engine aborts on a missing include, and on a directive that isn't alone on its line
+  (which cannot be substituted and would otherwise ship as a literal comment).
+- `install.sh` and `export.sh` moved to `tools/`. The engine itself did not move, so
+  existing `~/bin/fp-report` symlinks keep working — only the install/export commands
+  gain a `tools/` prefix.
+
 ### Added
+- **Themes tab** — a new first/default page of tiles that groups the whole backlog into
+  themes. Each tile carries a **priority distribution** (critical / high / medium / low /
+  unset), every row a bar **segmented by status**, scaled against the largest row across
+  the whole grid so bar length is comparable between tiles. Tiles are grouped by *facet*
+  (Quality / Area / Work type, configurable) and clicking one jumps to the Issues tab
+  filtered to that theme.
+  - **hide done** now also drives the tiles, and **ships ticked**: they open on live work
+    only, so a mostly-complete backlog stops flattening every theme into the same shape.
+    Headline, legend, footer and bar scale all follow the toggle.
+  - The taxonomy is per-project data (`fp-report.themes.json`, `THEMES_FILE`), meant to
+    mirror the project's `.fp/extensions/labels` vocabulary.
+  - Every issue lands in **exactly one theme per facet**, so tiles always partition the
+    backlog. Resolution order: **fp label → inherited from its epic → keyword match →
+    unthemed**, with the page footnoting how many issues came from each source. Labels
+    always win, so labelling an issue is how you correct a tile.
+  - Added a **theme filter** to the Issues tab, following the selected facet.
+  - Tiles count **leaf work items**; epics are reported separately as `N epics (M open)`.
+    An epic's status is a roll-up of its children, so counting both double-counts the
+    same work — that alone put 8 phantom items into MC's WIP figure.
+  - **Epic-scoped priority is kept distinct.** Inside an epic, "critical" ranks a
+    sub-issue against its siblings, not against the backlog; the epic roadmap already
+    scores epics by their own priority for this reason. Each priority row's tooltip
+    splits its count into top-level versus epic-scoped.
+  - A sub-issue **follows its epic's theme** unless it carries its own label, so one
+    initiative stays in one tile instead of fragmenting across five.
+- **Label enrichment.** `fp issue list` omits `properties`, so the engine now fetches
+  each issue's labels via parallel `fp issue show` calls and caches them by `updatedAt`
+  next to the report — a cold run on ~1000 issues takes about a minute, later runs under
+  a second. `--no-labels` skips it; `--refresh-labels` ignores the cache.
 - **Global search** at the top of every report — matches across issue **id, title, and
   spec (description)**, ANDs space-separated terms, ranks id/title hits above spec hits,
   highlights matches, and hides the dashboard while searching. Tap a result to expand its

CLAUDE.md

@@ -0,0 +1 @@
+@FP_CLAUDE.md

FP_AGENTS.md

@@ -0,0 +1,77 @@
+<!-- This file is managed by fp init. Do not edit by hand. -->
+
+## FP Issue Tracking
+
+This project uses **fp** for issue tracking. AI agents must follow these rules.
+
+## Workflow Primers
+
+Run `fp guide` for workflow primers and a snapshot of this project (registered statuses, properties, extensions).
+
+```bash
+fp guide              # List available primers
+fp guide plan         # Planning workflow (alias: planning)
+fp guide implement    # Implementation workflow
+fp guide brainstorm   # Brainstorm authoring (alias: bs)
+fp guide extension    # Extension authoring (aliases: extensions, ext)
+```
+
+Some primers bundle references reachable via `--references`, e.g. `fp guide brainstorm --references mermaid` for the Mermaid diagram guide.
+
+### Task Tracking
+
+- Use `fp issue` for all task tracking - do not use built-in todo tools
+- Create subissues with `--parent` flag - never use markdown checklists (`- [ ]`)
+- Break work into atomic tasks (1-3 hours each)
+
+### Work Session Flow
+
+1. `fp issue list --status todo` - find available work
+2. `fp issue update --status in-progress <id>` - claim it before starting
+3. `fp comment <id> "progress..."` - log at every milestone
+4. `fp issue update --status done <id>` - mark complete when finished
+
+When you commit work, mention the fp issue in the message, unless otherwise instructed.
+
+### Progress Logging
+
+- Run `fp comment <id> "..."` at every milestone
+- Write comments after significant commits
+- Always leave a final comment before ending session
+
+### Commands Reference
+
+```bash
+fp tree [parent-id]        # View issue hierarchy (optionally only show tree of parent-id)
+fp issue list --status X   # Filter by status (todo/in-progress/done)
+fp search <query>          # Search issues (AND by default, OR, "phrases", -negation)
+fp issue create --title "..." --parent X --property key=value
+fp issue update --status X <id> --property key=value
+fp comment <id> "message"
+fp comment update <comment-id> "new message"  # Alias: edit
+fp comment delete <comment-id>                # Soft-delete/hide a comment
+fp context <id>            # Load full issue context
+fp guide extension         # Print the extensions authoring guide
+fp guide brainstorm        # Print the brainstorm-authoring guide
+```
+
+### Flag Conventions
+
+- Standard attributes use dedicated flags: `--status`, `--priority`, `--parent`, `--title`, `--description`
+- `fp issue update --depends "<ids>" <id>` replaces the entire dependency set. It does not append. To add one dependency, first inspect the current dependencies and pass the full desired set.
+- `--property key=value` is for **extension-registered custom properties only** (e.g., labels, env, notes)
+- Do not use `--property` for standard attributes — use the dedicated flags instead
+
+### Extensions
+
+FP is extensible via TypeScript extensions. Extensions can hook into issue and comment lifecycle events (e.g., before marking issues done, after comments are added) to automate workflows.
+
+- Guide: `.fp/extensions/EXTENSIONS.md` (or run `fp guide extension` if the file is not present)
+- Extensions live in `.fp/extensions/` as `.ts` files
+
+### Brainstorms
+
+Brainstorm plans (`fp brainstorm create` / `fp bs create`) support a rich markdown + Mermaid authoring surface. Before writing or editing one, load the bundled authoring docs:
+
+- `fp guide brainstorm` — entrypoint; read this first
+- `fp guide brainstorm --references mermaid` — diagram authoring reference

FP_CLAUDE.md

@@ -0,0 +1,42 @@
+# FP Claude Instructions
+
+This file is managed by `fp agent setup claude` and `fp init --agent claude`.
+
+This project uses **fp** for issue tracking. Claude Code agents must follow these rules.
+
+## Guides
+
+Run `fp guide` for workflow primers and a snapshot of this project (registered statuses, properties, extensions).
+
+```bash
+fp guide plan
+fp guide implement
+fp guide brainstorm
+fp guide extension
+```
+
+## Issue Workflow
+
+- Before starting implementation work, load the relevant issue with `fp context <id>`.
+- Mark claimed work in progress with `fp issue update --status in-progress <id>`.
+- Add comments at meaningful checkpoints with `fp comment <id> "<update>"`.
+- Use `fp tree` and `fp issue list` to inspect nearby work before creating duplicate issues.
+- When work is complete and verified, mark the issue done with `fp issue update --status done <id>`.
+
+## Commands Reference
+
+```bash
+fp tree [parent-id]        # View issue hierarchy
+fp issue list --status X   # Filter by status
+fp issue create --title "..." --parent X --property key=value
+fp issue update --status X <id> --property key=value
+fp comment <id> "message"
+fp comment update <comment-id> "new message"  # Alias: edit
+fp comment delete <comment-id>                # Soft-delete/hide a comment
+fp context <id>            # Load full issue context
+```
+
+## Project Notes
+
+- Treat this file as fp-managed. Put project-specific Claude Code preferences in `CLAUDE.md`.
+- Keep user-authored content in `CLAUDE.md`; fp only ensures that file includes `@FP_CLAUDE.md`.