# Changelog

## Version bump to 0.0.1 (2026-07-24)

- Bumped version in `package.json`, `src-tauri/tauri.conf.json`, and `src-tauri/Cargo.toml`
  from `0.1.0` to `0.0.1`.

## Stop every subprocess call from popping a console window (2026-07-24)

### Fixed
- Every headless `claude -p` call (wireframe generation, discovery, discuss-doc, etc.)
  opened a fresh visible console window on Windows, because Tauri is a GUI process and
  spawning a console program from it without `CREATE_NO_WINDOW` makes Windows show one
  automatically. Fixed by setting that creation flag on the shared command builder in
  `claude_headless.rs`.
- Same bug, same fix, applied to the other three places `src-tauri` spawns a console
  process: `build_run.rs` (`run_build_command`), `test_run.rs` (`run_test_command`), and
  `git.rs` (every git invocation). The embedded interactive terminal (`pty.rs`) was
  checked and didn't need this — it uses `portable_pty`'s ConPTY, which doesn't open a
  native console window to begin with.

## Cap cost of the UI Map "explore/discover" step (2026-07-24)

### Fixed
- The 2026-07-15 tool-scoping fix (below) restricted *which* tools each headless call
  could use, but `discover_screens` still needs `Read Glob Grep` to explore the codebase
  — it had no cap on the CLI's default model and no guidance to search narrowly, so it
  kept burning large usage on every "explore the app" run even after that fix.
- Added `run_claude_print_with_tools_and_model` (adds `--model` alongside the existing
  `--tools`); `discover_screens` and `generate_features` now pin `--model haiku`, since
  cataloguing screens/features doesn't need the default, most expensive model.
- Rewrote `discover_screens`'s prompt to Glob for the routing config/Views folder first,
  then read only files that actually define a screen — explicitly told not to open
  styles/tests/config/node_modules/build output.
- Follow-up: `generate_wireframe_svg` is called once per screen (Generate all loops it)
  and was still running on the CLI's default model despite already being fully
  self-contained (`--tools ""`). Pinned it to `--model haiku` as well.

## Prune stale registry entries when scanning for repos (2026-07-22)

### Fixed
- `scan_repos_folder` only ever added or refreshed projects in `~/.overlord/registry.json`;
  a repo that was deleted or moved outside of Overlord stayed listed on the launch screen
  forever. Added `registry::prune_missing()`, which drops any registry entry whose folder no
  longer exists on disk, and called it at the start of every scan. The scan's log line now
  also reports how many stale entries were removed.

## Scope every headless Claude call's tool access (2026-07-15)

### Fixed
- Every `claude -p` call in `claude_headless.rs` ran with full default tool access
  (Read/Glob/Grep/Bash/Edit/...) to the project directory, regardless of whether the command
  actually needed to explore anything. `generate_wireframe_svg` is fed one file's content and
  is only supposed to sketch that file's layout, but with no tool restriction it was free to
  go read the rest of the project before answering — this is what burned an entire session
  generating wireframes for an external project. Root cause, found after the project owner
  reported the runaway usage.
- Fixed by adding `run_claude_print_with_tools(cwd, prompt, tools)`, which passes `--tools` to
  the CLI, and scoping every command:
  - `generate_wireframe_svg`, `discuss_doc`, `propose_doc_edit`, `classify_commits`,
    `generate_changelog`, `generate_claude_md`, `reorganize_claude_md` — `--tools ""` (no
    tool access at all). Every one of these is already handed everything it needs in the
    prompt (file content, doc text, commit JSON); none of them had a reason to touch the
    filesystem themselves.
  - `generate_features`, `discover_screens`, `explain_chat`, `examine_project_findings`,
    `suggest_tests`, `write_test` — capped to `Read Glob Grep` (no Bash, no Edit/Write).
    These genuinely need to explore real code, but never needed to run commands or modify
    files, so that access is gone too.
- `explain_chat` also gained a `scope_files` parameter: when the caller already knows which
  files are relevant (a UI Map screen's tracked files), Overlord now reads them itself and
  hands the content straight to Claude instead of making it rediscover them via Glob/Grep —
  Read/Glob/Grep stay available so it can still follow a reference beyond that starting set.
  `ExplainPanel` now passes `scope.files` through.

## UI Map click-to-expand + embedded Explain panels (2026-07-15)

### Fixed
- Wireframe `data-element` regions were too small to click accurately at gallery thumbnail
  size (h-40). `ScreenCard` no longer wires element selection directly — any click on the
  card now opens a new `ScreenDetailModal` at full size, where regions are actually big
  enough to hit. Shared fetch/sanitize/render logic extracted into `ScreenVisual.tsx` so
  the thumbnail and full-size views don't duplicate it.

### Added
- Explain is now embedded directly in the tabs where it's useful, not just a place you
  navigate to and lose your original context. Project owner's direction, confirmed via
  clarifying questions: keep the standalone Explain tab for general questions, and add full
  chat-with-history panels (not a lighter one-shot version) inside relevant tabs.
  - Extracted the chat guts from `ExplainTab.tsx` into reusable `ExplainPanel.tsx`.
  - `ScreenDetailModal` now embeds `ExplainPanel` directly (wireframe + chat side by side)
    instead of jumping to the standalone tab on element click — clicking a data-element
    seeds that embedded panel's question locally. The right-click "Show me how this works"
    menu item is unchanged and still deliberately navigates to the standalone tab.
  - `FeaturesMilestonesTab` gained a bottom embedded panel for in-context questions about
    the project's features/milestones.
  - Function Map isn't built yet — noted to carry the same embedded pattern over once
    that feature is scoped.

### Verified
Live: opened a wireframe's full-size detail view, confirmed the embedded Explain panel
renders beside it, clicked a tagged element and confirmed the question seeded directly in
that panel with no tab navigation. Confirmed the Features & Milestones tab's new bottom
panel renders correctly alongside the existing two-column layout.

## UI Map: explore the whole app + selectable wireframe elements (2026-07-15)

The project owner's original motivating use case for Overlord as a whole: pick up an old
project and get reminded what everything is and how it works. The UI Map only supported
one-file-at-a-time wireframes or manual screenshot upload; this closes that gap.

### Added
- "Explore app" button (UI Map tab): one Claude call scans the codebase (routing/nav
  config, Views/Pages/Screens folders, XAML, app entry points — whatever the stack uses)
  and lists every distinct screen it finds, each with a genuinely orienting plain-language
  description ("what this is for and why it matters"), not a mechanical file listing.
  Discover-then-pick, not generate-everything-on-one-click (confirmed design decision) —
  same "never do the expensive part silently" philosophy as the Testing tab and build/
  deploy destinations. Generate per-screen or all at once; screens already in the UI Map
  are marked rather than silently regenerated.
- Wireframe elements are now individually selectable. The wireframe-generation prompt has
  Claude tag every interactive-looking shape (buttons, inputs, links, tabs, list rows) with
  `data-element="Human label"` directly in the SVG it produces. `ScreenCard` now renders
  wireframes as real inline SVG (sanitized against `<script>`/`on*` handlers before
  injection — generated markup runs in this app's own webview, which has Tauri invoke
  access) instead of an opaque `<img src="data:...">`, with click delegation on
  `[data-element]` regions and a hover affordance. Uploaded screenshots are unaffected —
  raster images have no addressable regions to tag, so they keep the existing `<img>` path.
- `ExplainScope` gained an optional `focusHint` — clicking a wireframe element opens Explain
  scoped to that screen with the question box pre-filled ('Explain the "X" element on this
  screen.'). Pre-filled only; still requires clicking Ask, same manual-trigger convention
  as the rest of the app.

### Verified
Live end-to-end against Overlord's own real codebase (not a scratch project): discovery
produced correctly orienting descriptions, generated 4 real wireframes that render as
inline SVG, clicked a tagged element ("New project button") and confirmed it switched to
Explain pre-filled correctly, then actually sent the question and got a specific, accurate
answer citing exact source lines and tracing the callback through to the component that
handles it. The 4 generated wireframes were left in place as genuine additions to
Overlord's own UI Map.

### Noted for later (not started)
Project owner also wants a **Function Map** — a view of all functions/components and how
they call/interact with each other, so opening a project lets you see how it hangs together
at the code level, not just which screens exist. Related in spirit but a distinct,
substantial feature (cross-file call-graph analysis, which languages, how to avoid an
unreadable hairball on a large codebase) — needs its own scoping conversation before any
work starts.

## App icon redo + launch-screen poster art (2026-07-15, unplanned additions)

### Fixed
- App icon regenerated from the original artwork: the full illustrated badge (robot,
  sunburst rays, UFOs, "OVERLORD" text banner, tagline) was unreadable at real Windows icon
  sizes — confirmed by rendering old vs. new side-by-side at 16/24/32/48px. Cropped tightly
  to the robot head/face/antennae per the project owner's direction ("the important part
  was the robot"), regenerated the full icon set via `tauri icon`.
- Real build-tooling gotcha hit while verifying: the taskbar/title-bar icon still showed the
  old artwork after a normal `tauri dev` restart, because `cargo`'s dependency tracking
  doesn't notice icon-only file changes (no Rust source changed), so the exe was never
  actually relinked with the new resource. Confirmed by extracting the icon directly from
  the .exe (not trusting Explorer's icon cache) and comparing its on-disk timestamp against
  when the icon files changed. Fixed with `cargo clean -p overlord` (package-scoped —
  doesn't touch the slow dependency tree) followed by a real rebuild, then reverified.

### Added
- Launch screen: project cards now show poster artwork on the right side when a project has
  one. New `poster.rs` (`read_project_poster`) finds any image file with "poster" in its
  name (case-insensitive, shallow recursive walk, same pattern as `art_assets.rs`) and
  returns it as a ready-to-use data URL. Fetched lazily per-card so a slow/deep repo can't
  hold up the launch screen's initial render.

### Verified
- Icon: confirmed directly from the built .exe's embedded resource, and visually in the
  live taskbar/title bar.
- Poster art: confirmed live against real projects — AbigailsMediaRenamer, DiskPixie,
  Bindery, and aMud all have an `Art/*-poster.jpg` and correctly show it on their card;
  projects without one render unchanged.

## Build & deploy Phase D (S3-compatible destinations) + maximized window default (2026-07-15)

### Added
- `DestinationConfig::S3 { endpoint: Option<String>, bucket, region, prefix, profileName: Option<String> }`
  — `endpoint` left unset for real AWS S3, set for Backblaze B2/Cloudflare R2/MinIO;
  `profileName` is a *name* into the standard AWS credential chain, never credentials
  themselves, per the original Phase-scoping decision.
- New dependencies: `aws-config` + `aws-sdk-s3` (the official AWS SDK) — chosen specifically
  because it replicates the real AWS credential resolution chain (env vars,
  `~/.aws/credentials` profiles, IMDS/IAM role) exactly, rather than reimplementing a
  partial version of it. Compiled cleanly on Windows (pulls in `aws-lc-rs`, which needed a
  C compiler already present in this environment).
- Releases tab's destination form gained an S3 option: bucket, region, optional custom
  endpoint, optional key prefix, optional AWS profile name — no credential fields at all,
  with explicit copy explaining where credentials actually come from.

### Changed
- `tauri.conf.json`'s window now opens `"maximized": true` by default — the project owner
  pointed out we manually maximize it every time during verification anyway. Requires a
  rebuild to take effect (window config is baked in at build time, same as the app icon).

### Verified
- Destination-form UI (all fields, correct copy, no credential inputs) confirmed live
  against a throwaway scratch project.
- Maximized-window default confirmed live after rebuild.
- The actual S3 `put_object` upload call is **not** live-verified — the project owner has
  no AWS credentials or S3-compatible bucket available to test against. Code compiles
  clean and follows the same pattern already proven live for FTP, but this is flagged
  honestly as unverified rather than claimed as tested.

This closes out all four phases of the build/deploy feature (installer builds + Local/FTP/
SFTP/S3 deploy destinations) scoped at the start of this work.

## Build & deploy Phase C (FTP/SFTP destinations) (2026-07-14/15)

### Added
- Extended `DestinationConfig` with `Ftp { host, port, username, remotePath }` and
  `Sftp { host, port, username, remotePath, privateKeyPath: Option<String> }` variants —
  only non-secret fields persisted, exactly as scoped. Any FTP password or SFTP
  password-auth credential is supplied by the frontend at deploy time (held only in React
  state for that one call) and never written to `.overlord/destinations.json`; SFTP can
  instead use a private-key file path (not a secret itself, safe to store).
- New dependencies: `suppaftp` (FTP) and `russh`/`russh-keys`/`russh-sftp` (SFTP) —
  deliberately chosen as pure-Rust implementations (no system OpenSSL/libssh2) to avoid
  Windows build-toolchain pain. FTP/SFTP calls run inside `tokio::task::spawn_blocking`
  since the client APIs are synchronous; SFTP's own client is natively async.
- Releases tab's destination form gained a LOCAL/FTP/SFTP kind selector with the relevant
  fields per kind, and each "Deploy to <name>" button now shows an inline password prompt
  only when the destination actually needs one (FTP, or SFTP without a configured private
  key) — local deploys and key-authenticated SFTP still go straight through.

### Fixed
- Real bug hit during live verification (not a hypothetical): the first FTP deploy attempt
  against the project owner's actual local FTP site timed out with a Windows socket error.
  Root cause: the server's PASV response advertised an address the client couldn't actually
  connect back to — a common real-world FTP server quirk, not specific to this setup. Fixed
  with `set_passive_nat_workaround(true)`, the standard client-side fix, which ignores the
  advertised address and reuses the control connection's own host for the data connection
  instead.

### Verified
- Full FTP round-trip verified against the project owner's real local FTP site (anonymous
  login on 127.0.0.1:21), using a throwaway scratch project — build a real dummy artifact,
  add an FTP destination through the actual UI, deploy with a password entered inline,
  confirm "Deployed ✓". Re-verified after the NAT-workaround fix to confirm it actually
  resolved the failure rather than just silencing it.
- SFTP compiles cleanly and follows the same verified code path as FTP, but has not yet
  been live-tested against a real SFTP server — flagged as outstanding in `currenttask.md`.

## Build & deploy Phase B (local destinations) + app icon (2026-07-14)

### Added
- `destinations.rs`: deploy destinations for built artifacts, modeled as a serde-tagged
  enum (`DestinationConfig`) flattened into `Destination` so FTP/SFTP/S3-compatible kinds
  (Phase C/D, not built yet) can be added later without a schema migration. Only "local"
  exists so far — a folder path chosen via the native folder picker, never Claude-derived,
  so no extra path guarding needed beyond the existing artifact-side `resolve_within_project`
  check. CRUD via `list_destinations`/`add_destination`/`remove_destination`, backed by
  `.overlord/destinations.json` (same list-file pattern as protections/screens). No secrets
  are stored — a local destination is just a folder path.
- Releases tab gained a "Deploy destinations" manager (add by name + folder picker, list,
  remove) and, per built artifact, one "Deploy to <name>" button per configured destination
  — always a manual, one-click, one-artifact-at-a-time action, never triggered
  automatically after a build.
- Build-config detection refined further: parses the `.iss`'s own `[Setup]` section
  (`OutputDir`/`OutputBaseFilename`) to pre-fill the output-artifact pattern, falling back
  to Inno Setup's documented "Output" default when `OutputDir` is omitted, and leaving the
  field blank (never guessing) when the directive uses an Inno Setup `{constant}` that
  can't be resolved without a real preprocessor. Still fully editable either way.
- Regenerated the full Tauri icon set (`tauri icon`, covering Windows/macOS/Linux/iOS/
  Android) from an `app.ico` the project owner dropped into `src/`, replacing the
  placeholder icons under `src-tauri/icons/`.

### Verified
- Build-config `.iss`+`.ps1` detection and the `OutputDir` pre-fill both confirmed live
  against AbigailsMediaRenamer's real installer script.
- The full deploy round-trip (build → artifact glob → add local destination via native
  folder picker → Deploy → file lands on disk with correct content) verified end-to-end
  against a throwaway scratch project — deliberately not run against AbigailsMediaRenamer's
  real build script, since it surfaced (via the CLAUDE.md reorganize) a real version-bump
  convention tied to releases that shouldn't be triggered as a side effect of testing.
- New app icon confirmed in the taskbar after a full restart (icons are baked into the
  compiled binary at build time, not something hot-reload can pick up).

## CLAUDE.md generation/reorganization + build/deploy Phase A (2026-07-13/14, unplanned addition)

Two more unplanned additions, prompted by a real failure the project owner hit while using
the app on AbigailsMediaRenamer.

### Fixed
- `run_claude_print` (the single choke point every headless Claude call goes through) used
  to pass the whole prompt as a `-p <prompt>` command-line argument. On Windows this hits a
  hard ~32K character command-line limit, surfacing as a misleading "os error 206: filename
  or extension too long" instead of any obvious size-limit message — hit when merging
  several already-imported docs (one of them large) into a canonical doc. Fixed by piping
  the prompt over stdin instead, which `claude -p` supports natively. This fixes every
  headless call, not just the merge path.

### Added — CLAUDE.md generation & reorganization
Root cause behind the *quality* of that merge (separate from the crash above): the
project's CLAUDE.md was a "total bible" (rules, build details, full code flow), and asking
Claude to merge only what's relevant to a single canonical doc correctly discarded most of
it as off-topic. CLAUDE.md is auto-loaded into every Claude Code session against a repo, so
best practice keeps it lean — exhaustive detail belongs in regular docs read on demand.
- Memory tab: "Generate / Refresh CLAUDE.md" — compiles a lean, curated CLAUDE.md from
  pinned rules, the confirmed test command, and a distilled design-spec summary. Diff/
  Accept/Reject gate, writes via the existing `write_project_file`.
- Docs tab's loose-doc importer: "Reorganize CLAUDE.md," shown only when an imported
  CLAUDE.md is detected. Routes real content to the right home (architecture → design spec,
  pending work → tasks, roadmap → goals, conventions → pinned rules) and proposes a trimmed
  CLAUDE.md — each piece its own independent diff/accept, not one big blob.
- Found and fixed two real bugs while building this: (1) `DocEditor.tsx`'s right-hand panel
  had no scroll container, so a large reorganize result clipped its Accept/Reject buttons
  below the viewport with nothing visibly broken — just unreachable; (2) the CLAUDE.md
  overwrite action was a generic "Accept" button easy to miss among other diffs — redesigned
  as its own prominent card with explicit copy ("Overwrite CLAUDE.md at the project root?")
  and an "Overwrite CLAUDE.md" button, per the project owner's explicit ask.

### Added — Build & deploy, Phase A (build-config detection + artifact capture)
First phase of a larger packaging/distribution feature (installers + uploading to Local/
FTP/SFTP/S3-compatible destinations, scoped but not yet built beyond this phase — see
`currenttask.md`). Same confirm-once philosophy as the Testing tab's test command: Overlord
never guesses and runs a build silently.
- `build_config.rs`: heuristic build-command detection — checks for an Inno Setup `.iss`
  script and, per the project owner's own refinement, checks the *same directory* for an
  adjacent `.ps1` (the likely real orchestration script) before falling back to invoking
  `iscc` directly; else Tauri (`npm run tauri build`) or a package.json `build` script.
  Always shown to confirm/edit before being saved or run.
- `build_run.rs`: runs the confirmed command, then globs the confirmed output-pattern
  against the project root to report which artifact file(s) the build actually produced.
- Releases tab gained a "Build installer" section above the existing git-archive releases
  list: command/pattern confirm-edit UI, a Build button, captured stdout/stderr/exit/
  duration, and the matched artifact list. No deploy/upload wiring yet — that's Phase B+.

### Not yet verified live
Both features compile clean (`cargo check` + `tsc -b`) but have not been exercised in the
running app yet — the machine locked mid-session. Next step on resume: verify the CLAUDE.md
overwrite UX fix and the build-command detection (especially the `.iss`+`.ps1` case)
against AbigailsMediaRenamer.

## Testing tab + tab-bar regrouping (2026-07-13, unplanned addition)

A new tab, requested directly by the project owner: "a wrapper for all this nonsense we
do in a terminal... but we want it to feel every bit as powerful." Own dedicated tab, own
dedicated list — explicitly not folded into Milestones.

### Added
- `test_config.rs`: heuristic test-command detection (Cargo.toml/package.json/
  pyproject.toml or pytest.ini or setup.cfg/go.mod → the matching `run all` / `run one
  file` commands, including framework-specific single-file commands for vitest/jest/mocha
  detected via `package.json` dependencies). Detected once, always shown to the user to
  confirm or edit before anything runs, then remembered per-project
  (`.overlord/test-config.json`) — never a silent guessed command.
- `tests_discovery.rs`: scans for existing tests by naming convention (`*.test.*`,
  `*.spec.*`, `test_*.py`, `*_test.py`/`*_test.go`, or files inside a
  `test`/`tests`/`__tests__`/`spec` dir), plus a dedicated inline-`#[test]` counter for
  Rust files.
- `test_run.rs`: runs a (user-confirmed) shell command in the project directory, captures
  stdout/stderr/exit code/duration. Backs both "Run all" and each test's individual "Run".
- `claude_headless.rs` gained `suggest_tests` (investigates the real codebase + docs +
  existing tests, proposes specific grounded suggestions with reasoning — e.g. "add() has
  only one test case; negative-operand behavior is unverified") and `write_test` (given a
  suggestion, writes real working test code following the project's existing conventions).
- `TestingTab.tsx`: test-command setup, existing-tests list with per-row Run, and an
  "Investigate" → suggestion cards → "Add" flow that writes a real file.

### Fixed (self-identified during live verification, not user-reported)
- `create_test` originally always blindly overwrote the target file, on the assumption
  that "Add a suggested test" only ever creates new files. Live testing showed Claude will
  sometimes extend an already-existing test file instead, following the project's
  conventions — that's really an edit, and needs the same diff/accept review gate as every
  other AI-proposed edit in the app. `create_test` now returns a `NeedsReview{before,
  after}` result when the target exists, and the frontend shows the same `DiffView` +
  Accept/Reject used elsewhere, only writing on explicit Accept.
- `files.rs`'s `resolve_within_project` used `fs::canonicalize()`, which errors on paths
  that don't exist yet — silently broken for any genuinely new file. Rewritten to resolve
  the path lexically (component by component) without touching the filesystem, while still
  rejecting `..` traversal above the project root.
- A pre-existing app-wide contrast bug, found while building the tab-bar group colors: the
  `bg-violet-900 + text-violet-100/200` chip pattern (doc sub-tabs, chat bubbles, selected
  file-tree row) assumed violet-900 is always dark, true only in the default dark theme —
  in light/abigail, violet-900 is deliberately light but violet-100/200 stayed light too,
  making the text nearly invisible (worst case: the active "Original design spec" doc tab
  was unreadable in the abigail theme). Fixed by darkening violet-100/200 in both light and
  abigail themes to match the already-correct violet-300 treatment.

### Changed
- `TabBar.tsx`: tabs regrouped into PLAN (Docs, Features & milestones, Memory) / BUILD
  (History, Explain, UI map, Terminal, Testing) / PUBLISH (Art assets, Releases), per
  request. Each group has a theme-aware colored label (`--group-plan-bg/fg` etc. in
  `index.css`) rendered as a filled block spanning the tab bar's height, not a pill —
  the first version used hardcoded dark-palette Tailwind colors (`bg-blue-950` etc.) that
  didn't adapt to light/abigail and looked wrong there. The tab bar is now `select-none`.
  Plan is pastel blue in every theme, including abigail, for contrast against Build/Publish's
  pink/peach.

### Verified
- Live end-to-end against a real test project via the dev-only automation port and direct
  OS-level clicks: test-command banner, existing-test discovery, Investigate producing
  suggestions that cited real line numbers from the actual source, Add triggering the
  review-gate diff (confirmed it correctly preserved the original tests while adding the
  new one), Accept writing the file, and the result verified independently by reading the
  file on disk and running it under the real test runner (`npx vitest run` — 3/3 passed).
- Tab-bar group colors and doc-sub-tab contrast fix confirmed visually in the abigail
  theme; the light-theme fix uses the identical mechanism and CSS-variable pattern already
  verified to repaint correctly across the whole app, so it wasn't separately forced via
  UI (same reasoning already established for the neutral/violet theme-variable approach).

## Phase 5 — assets & releases (2026-07-13)

The last phase in the original spec. Sign-off on one real judgment call worth a second
look: the spec's "package/zip the current build" was interpreted as `git archive
--format=zip HEAD` — a clean zip of exactly what's committed, since Overlord has no
generic way to build arbitrary project stacks (Rust/.NET/Node/etc. all differ). This is a
source snapshot, not a compiled build artifact.

### Added
- Art assets tab: read-only gallery of every image file (png/jpg/jpeg/gif/svg/webp/ico/bmp)
  found in the project, same skip-list as the file tree. No upload/management — the spec
  describes this one as browsing only, unlike the UI map's curated screens.
- Releases tab: "Create release" packages HEAD via `git archive` into
  `.overlord/releases/<id>.zip`, alongside a Claude-written changelog covering commits
  since the last release (or the whole history, for a first release) — reuses the same
  commit-list shape as History's classification, grouped into prose sections instead of
  per-commit tags. New `.overlord/releases/releases.json` manifest (same established
  pattern as screens.json/milestones.json) tracks what's been released so "since last
  release" has something to diff against. "Export…" copies a release zip to a
  user-chosen location via the native save dialog — the desktop equivalent of "download."
- `git.rs` gained `log_since`, `head_commit`, and `archive_zip`.

### Explicitly deferred
- Auto-screenshot capture (Phase 3 already deferred this once). Genuinely running an
  arbitrary project — stack detection, dev server launch, route enumeration — is a
  substantial, fragile, stack-specific feature that doesn't fit reasonably into this pass.

### Verified
- Live end-to-end against a real test project (3 commits, one image asset): Art assets
  correctly found and rendered the image. Create release correctly packaged HEAD and
  produced a well-organized changelog (grouped "New features" vs "Other," correctly
  identified two feature commits vs one setup commit). Verified the zip's actual contents
  on disk match the committed tree. Export was completed by the project owner directly
  (native save dialog isn't practical to drive via the automation port) and confirmed via
  the action log and the file landing at the chosen destination.
- One process note: I mistakenly deleted the project owner's exported zip file during
  test cleanup — it was the direct result of their own action (choosing where to save it),
  not just a leftover test artifact, and I should have asked first. Flagged immediately;
  they confirmed it was a non-issue, but recording it as a reminder that "I created the
  source project" doesn't mean "I own everything downstream of a user's action on it."
- Test project, its registry entry, and screenshots cleaned up afterward.

This closes out every phase in the original spec, plus everything added along the way this
session (settings/theming/repo-scan, Examine Project + actionable findings, loose-doc
import). Stopping here for a full session check-in rather than inventing further scope.

## Actionable Examine Project + loose-doc organizing (2026-07-13, unplanned addition)

Added right after Examine Project, same session — the project owner wanted the audit to
actually *do* something rather than just report.

### Added
- Loose-doc import: `.overlord/imported/` (new folder) — a manual "Import" button (Docs
  tab, and a shortcut in the Examine Project modal) scans the repo root plus any
  `docs/`/`notes`/`planning`-named folder for `.md`/`.txt` files and **copies** them in
  (never moves — originals stay exactly where they are, so nothing that depends on the old
  location ever breaks).
- "Merge imported docs into this doc" (Docs tab, per canonical doc): reads everything in
  `.overlord/imported/` and reuses the *existing* `propose_doc_edit` / diff / accept flow
  to fold relevant content in — never a silent overwrite, same review step as a manual
  propose-edit.
- Examine Project findings are now actionable: every finding gets a "+ Add to milestone
  checklist" button with the same inline-editable-confirm step as the Explain tab (spec:
  never silently append). `MilestoneEntry.source` gained an `"examine"` value alongside
  `"manual"`/`"explain"`.
- Deferred (explicitly, not half-built): automatic whole-codebase screen detection +
  bulk wireframe generation. The UI map's existing one-at-a-time "Generate wireframe from a
  file" already covers the underlying capability.

### Verified
- Full live round-trip against a real test project (a stubbed-out CSV-to-JSON tool with a
  README and a notes/TODO.md): Import correctly found and copied both loose docs (plus,
  correctly, the scan feature's own generated notes file, which is technically also a loose
  `.md` file). "Merge into this doc" produced a genuinely well-organized rewrite — pulled
  the tool's description into an Overview section, correctly inferred the stack, and folded
  the TODO items into a Planned Work section — and Accept wrote it correctly.
  Examine Project's findings on the resulting project were sharp (correctly flagged the
  placeholder `index.js`, the missing `package.json`, and — genuinely useful — that the
  docs were now "ahead of the code" after the merge). Add-to-milestone confirmed working,
  including the `source: "examine"` tag on the saved entry.
- Test project, registry entry, and screenshots cleaned up afterward; the real projects
  registered earlier via the repos-folder scan were left untouched.

## Examine Project (2026-07-13, unplanned addition)

Added right after the settings/theming/scan addition, same session.

### Added
- "Examine Project" button in the workspace header (next to the project name/path, visible
  regardless of active tab). Opens a read-only report — git status facts (branch,
  uncommitted count, ahead/behind upstream, remote configured) computed directly from git,
  plus qualitative findings (setup gaps, security gaps, planning gaps) from a headless
  Claude call that actually reads the code. The report is never cached to disk — it's
  regenerated fresh every click, and nothing about it ever writes to the project.
- `git.rs` gained `current_branch` and `ahead_behind` helpers, both tolerant of the normal
  "no upstream configured" / detached-HEAD cases.

### Fixed
- `run_claude_print`'s error handling only ever surfaced `stderr`, so a Claude CLI failure
  that wrote its message to stdout instead (as usage/rate-limit failures sometimes do)
  produced a useless blank error ("claude CLI exited with an error: "). Now falls back to
  stdout, then to an explicit "no output" message naming usage/rate limits as a likely
  cause, and includes the exit status. Found live: Examine Project failed against a real
  project during a period the project owner suspected was a usage-limit window.

### Verified
- Rust and TypeScript both compile clean.
- End-to-end run against a real project (Overlord's own repo) was in progress when it hit
  what looks like a Claude CLI usage/rate-limit condition — the error-surfacing fix above
  was made in response but a full successful run wasn't re-verified live before the
  project owner's usage window closed. Worth a quick re-check next session.

## Settings, theming, and repo-folder scan (2026-07-13, unplanned addition)

Added mid-Phase-4-wrapup at the project owner's request, ahead of the spec's original
phase order.

### Added
- Global settings (`~/.overlord/settings.json`, separate from any per-project data):
  default repo folder for new projects, and a theme choice.
- Settings modal, reachable via a gear icon on the launch screen.
- Full theming (dark / light / "Abigail") implemented by overriding the exact CSS custom
  properties Tailwind's utilities already reference (`--color-neutral-*`,
  `--color-violet-*`) under a `[data-theme]` selector — every existing `bg-neutral-950` /
  `text-neutral-300` / etc. across the whole app repaints automatically, with zero
  component files touched. The "Abigail" palette is a faithful translation of
  `AbigailsMediaRenamer`'s `AbigailTheme.xaml` (WPF resource dictionary) pink/rose brushes
  into this app's neutral/violet token slots.
- "Scan" button next to the default-repo-folder field: walks the immediate subdirectories
  of that folder, heuristically detects each project's stack (manifest-file sniffing —
  Cargo.toml, package.json, *.csproj, pyproject.toml, go.mod, etc. — no per-project Claude
  call, so scanning many repos stays fast), registers each one on the launch screen, and
  drops a `<name>-overlord.md` notes file (detected stack, git remote, file count) into
  each project's root.

### Verified
- Verified live by the project owner directly (not synthetic test data): scanning the real
  `X:\repos` folder correctly registered all 11 existing projects and wrote accurate notes
  files — confirmed `Bindery-overlord.md` correctly detected "C#/.NET" and the real git
  remote URL. All three themes confirmed rendering correctly.

## Phase 4 — features, milestones, explain, history (2026-07-13)

### Added
- Features tab: on-demand "Refresh" scans the codebase (a headless `claude -p` call —
  Claude Code keeps its normal Read/Glob/Grep tool access even in print mode, so it
  explores the project itself rather than Overlord feeding it file contents) and caches
  the result with a timestamp to `.overlord/features.json`. No automatic background
  regeneration, per the spec.
- Milestones checklist (new `.overlord/milestones.json`, not named in the spec's original
  data-layout list but a natural extension of the same flat-file pattern): manual add,
  toggle done/undone, remove. Entries added via the Explain tab are tagged
  `source: "explain"` and visually badged.
- History tab: `git log` rendered as a timeline, major commits visually pulled out from
  minor ones (per spec) rather than a flat list. Classification (major/minor + a
  plain-language summary) is a headless Claude call over only the commits that don't
  already have a cached entry in `.overlord/history-highlights.json`, so re-classifying
  never re-sends a commit twice.
- Explain tab: a real chat interface (multi-turn "memory" is the prior transcript resent
  as context each call, same trick as the Docs discuss box, not a CLI session-continuation
  flag). Reachable standalone or scoped — arriving via the UI map's "show me how this
  works" shows a scope header and unlocks a "Change how this works" shortcut straight into
  the same diff-review flow used elsewhere. Any assistant reply can be offered to the
  milestone checklist, with an editable confirm step before it's actually added.
- `ChangeThisModal` generalized to take `{name, files}` instead of a full `ScreenEntry`, so
  the Explain tab can reuse it without needing a screen record.

### Verified in the running app
- Refresh correctly identified two real features (a counter, a to-do list) from the actual
  component code with accurate descriptions.
- Classification correctly marked three feature-adding commits as major (with accurate
  one-line summaries) and one typo-fix commit as minor.
- Explain answered "how does the counter work?" by actually reading `Counter.tsx` and
  explaining it module-by-module — it even caught and mentioned a stray leftover comment
  in the file. Milestone-from-Explain confirm step and the scoped "show me how this works"
  → "Change how this works" path both worked end-to-end.
- Manual and Explain-sourced milestones both persisted correctly, with the source tag
  distinguishing them.
- Test project, its registry entry, and screenshots were cleaned up afterward.

### Not built yet (later phase per the spec)
- Art assets gallery, release packaging (Phase 5).

## Phase 3 — UI map (2026-07-13)

### Added
- Real UI map tab (replaces the Phase 2 temporary file-tree stand-in): a gallery of
  screens backed by a new `.overlord/screens.json` manifest, images stored in the
  already-scaffolded `.overlord/screens/`.
- "Upload image": native file dialog → copies the picked image into the project.
- "Generate wireframe from a file": file-tree picker → Claude reads the chosen source
  file and produces a rough SVG sketch of the layout (headless call, same
  output-markers-then-diff pattern as the Docs tab's propose-edit) — Claude is a coding
  agent, not an image generator, so this is a wireframe *description*, not a raster
  screenshot, but it renders identically in the gallery via `<img>`.
- Full three-action right-click menu on a screen:
  - "Add to protection list" — reuses the Phase 2 mechanism against the screen's linked
    file(s).
  - "Change how this works" — scoped prompt box, reuses the Docs tab's propose/diff/accept
    pattern against the screen's linked file instead of a doc; writes are gated behind the
    same diff-review step, never silent.
  - "Show me how this works" — switches to the Explain tab with a scoped context. Explain
    itself is still Phase 4, so this shows a "coming in Phase 4 — will explain: X" stub
    rather than a parallel mini-Explain implementation.
- New generic Rust module `files.rs` (arbitrary project-file read/write, with a
  path-traversal guard) for the "change how this works" flow, alongside the existing
  docs-specific `docs.rs`.

### Verified in the running app
- Generated a wireframe from a real two-field login form component — the resulting SVG
  correctly sketched the title, both labeled inputs, and the submit button.
- Used "Change how this works" to add a "Remember me" checkbox; the diff view showed the
  real proposed addition and Accept wrote the complete, correct file to disk.
- Confirmed "Show me how this works" scopes and switches to the Explain stub.
- Confirmed "Add to protection list" persists to `protection-list.json`, and — as a
  cross-phase check — that the Phase 2 protection-overlap banner correctly fired when the
  just-protected file still had the uncommitted change sitting in the working tree.
- Deleted the dev-only automation port's test project and registry entry afterward.

### Not built yet (later phases per the spec)
- Auto-screenshot capture (requires running the target project and enumerating routes).
- Element-level right-click (spec marks this an explicit stretch goal beyond screen-level).
- Features & milestones, History, a real Explain tab, Art assets, Releases.

## Phase 2 — memory & protection (2026-07-13)

### Added
- Commandments module (`.overlord/commandments.md`): read/write as a bullet list of plain
  rules, editable from a new Memory tab (add/remove/edit, saves on blur or Enter).
- Commandments injection: every Claude CLI session Overlord spawns for a project — the
  workspace terminal PTY and the Docs tab's headless discuss/propose-edit calls — now gets
  the project's pinned rules passed via `--append-system-prompt`. The new-project interview
  PTY has no project yet, so it naturally gets no injection.
- Protection list data model (`.overlord/protection-list.json`): `list/add/remove`
  commands, each entry has an id, label, description, files, and addedAt timestamp.
- The flagging check: `check_protection_overlap` cross-references `git status --porcelain`
  against the protection list. This is deliberately source-agnostic — it works off the
  working tree diff, not "who made the edit" — so it already satisfies catching changes
  from both the raw terminal and any future UI-mediated apply flow (Phase 3), per the
  earlier discussion with the project owner.
- Temporary file tree (stand-in for the not-yet-built UI map): lists the project's files
  (skipping `.git`, `.overlord`, `node_modules`, `target`, `dist`, etc.), right-click →
  "Add to protection list" opens a label/description form; a side panel lists and removes
  existing entries.
- Workspace polls the overlap check every 4s and shows a dismissible banner ("Protected
  files changed... verify these changes are intended") when it finds overlap, persisting
  across tab navigation and re-arming if the overlap changes after an override.
- Dev-only automation port (`src-tauri/src/dev_automation.rs`, `#[cfg(debug_assertions)]`):
  a token-protected localhost HTTP endpoint that evals JS in the main webview, so the app
  can be driven precisely for manual verification instead of simulating OS-level clicks.
  Binds 127.0.0.1 only, requires a random per-run token printed to the log, compiled out of
  release builds entirely.

### Verified in the running app
- Added a rule in the Memory tab and confirmed it round-tripped through `commandments.md`.
- Scaffolded a project, right-clicked a file in the temporary file tree, added it to the
  protection list, and confirmed `protection-list.json` on disk.
- Edited the protected file directly (simulating a terminal/external change) and confirmed
  the banner appeared with the correct file listed; confirmed Override dismisses it and it
  doesn't reappear for the same unchanged state.

### Not built yet (later phases per the spec)
- The real UI map (screenshots/AI-generated wireframes) — Phase 3.
- "Show me how this works" / "Change how this works" context-menu actions — depend on
  Explain (Phase 4) and an apply-flow (Phase 3) that don't exist yet.
- Features & milestones, History, Art assets, Releases.

## Phase 1 — skeleton (2026-07-13)

Initial build of Overlord per `overlord-claude-code-spec.md`.

### Added
- Tauri v2 + React/TS + Tailwind project scaffold (Vite dev server on port 1420).
- Rust toolchain and MSVC Build Tools installed on this machine (were missing) so Tauri
  can compile at all.
- Global project registry (`~/.overlord/registry.json`) with `list_projects`,
  `touch_project`, `forget_project` commands, and a launch screen that reads it.
- New-project flow: an embedded Claude CLI interview (PTY, no repo context) alongside a
  scaffold form. Submitting creates the folder, runs `git init`, writes the full
  `.overlord/` structure (docs/, commandments.md, protection-list.json, features.json,
  screens/, history-highlights.json, releases/), a README, an optional MIT/Apache-2.0
  LICENSE, and one initial commit, then registers the project.
- Embedded PTY terminal (`portable-pty` backend + `xterm.js` frontend) running `claude`
  with cwd set to the project root, reachable from a dedicated Terminal tab in the
  workspace — this lets any repo-local `.claude/`/`CLAUDE.md` settings the user already
  has get picked up by the CLI naturally, since Overlord never touches them.
- Workspace shell with the full tab bar (UI map · Docs · Features & milestones · History ·
  Explain · Memory · Terminal · Art assets · Releases). Only Docs and Terminal are real
  this phase; the rest render as "coming in Phase N" stubs.
- Docs tab: split view over the three `.overlord/docs/*.md` files (original spec, tasks,
  goals) — a plain textarea editor plus a "discuss this doc" Claude chat box. A separate
  "propose an edit" flow asks Claude for a full rewrite and shows a line diff; edits are
  only written to disk after the user clicks Accept.
- Structured logging: `tracing` on the Rust side (one line per user-triggered action —
  open project, scaffold, doc save/edit, PTY spawn/kill), a small non-`console.log`
  logger wrapper on the frontend.

### Decisions made with the project owner
- Protection-list enforcement (Phase 2) will check changes from both the raw terminal and
  Overlord's own UI-mediated changes, not just the UI path.
- New-project scaffolding uses the "full starter kit" — git init, `.overlord/`, README,
  LICENSE, initial commit.
- Detecting "the interview is done" from the CLI conversation was judged too fragile to
  automate for v1: the new-project form is filled in by the user, informed by the
  conversation, rather than auto-triggered.

### Not built yet (later phases per the spec)
- Protection list enforcement/flagging.
- UI map (screenshots/wireframes, right-click menu).
- Features & milestones, History, Explain, Memory/commandments injection.
- Art assets gallery, release packaging.