What it is
I've been running my search through this framework and built a small macOS desktop app on top of it for my own use. Before polishing it into a PR, I'd like to know whether something like this fits upstream at all, or whether it belongs in a fork. I've read CONTRIBUTING, including the part about orchestration layers and wrappers (#44, #49, #66) and your reply in #332, so I'd rather ask first than send you a 4k-line PR.

The app gives a visual view of the pipeline:

Lists: scraped jobs grouped by fit, applications grouped by tracker status, and a side panel showing /rank's strengths and gaps.
Documents: PDF preview of the compiled CV and cover letter.
Runs: the commands appear as a live activity feed.
(Screenshots use made-up demo data.)

How it stays out of the specs' way
The design goal was to add zero workflow logic:

Commands run unchanged. Every action is the existing slash command, e.g. /scrape, /rank, /apply , /outcome, /interview, /upskill, /html-report, /setup --section. They run through the Claude Agent SDK in the repo root with settingSources: ["project"] and Claude Code's own preset system prompt. So CLAUDE.md, the skills, the commands and .claude/settings.json load exactly as in the CLI, and a methodology change upstream reaches the app with no app change.
The app writes no state files. It only reads seen_jobs.json, job_search_tracker.csv, documents/applications/* and the compiled PDFs. Every write still happens inside the commands, so /outcome stays the single writer of the tracker, which was the concern you raised in #332.
Stop points stay with the user. The commands' stop points (e.g. /apply's "proceed to drafting?") end the turn. The app shows a reply box and resumes the same session; AskUserQuestion is rendered as a form.
Tool permissions are layered on top. Read-only tools and the same commands settings.json already allows (portal CLIs, tools/*.py, LaTeX compiles, rm -f of build artifacts in cv/ and cover_letters/) run without asking. Anything else shows an approval prompt. Writing outside the repo, git push, sudo and rm -r are refused. settings.json itself isn't touched, so security_guards stays green.
Footprint outside ui/: a few .gitignore lines (build output and run transcripts) and a short README pointer. No new commands, no changes to skills or tools.
Locked down by default: no network port (renderer ↔ main over IPC only), contextIsolation and sandbox on, a strict CSP, PDFs served only from allowlisted folders. The Claude token is stored encrypted via the macOS keychain (safeStorage).
Tests: 50 bun test cases in ui/tests/. They cover tracker CSV parsing (including legacy 13-column rows and space-spelled statuses), the seen_jobs.json wrapper/bare forms and legacy verdicts, outcome.md parsing, the permission classifier, path-traversal rejection, theme contrast, and i18n key parity.
It also ships Turkish and English UI strings. Claude's chat replies follow the app language, while document language still follows the repo's rules. Adding a language means adding one dictionary file, which felt in the spirit of fork-and-adapt.

The honest costs
It is a resident process. That's exactly what you described as a real cost in a run-and-done template. It also pulls in Electron and the Agent SDK, so it's heavy for something optional.
Packaging is macOS-only. It's Apple Silicon, ad-hoc signed, with bun run install-app. The code itself isn't macOS-specific, but I haven't built or tested it elsewhere.
CI and maintenance. It's another surface to keep working, and I don't have a way for CI to exercise the live agent path.
The question
Which of these would you prefer?

Upstream as an optional ui/ folder. I'd split it the way you like (#73): the core app first, then design, then i18n, each as its own PR, with CI only typechecking and unit-testing it.
Keep it out of upstream. I'd publish it as a standalone repo that points at a user's checkout of this template, and list it under Community forks & adaptations (#78).
Either answer is fine with me. I'd rather it lives wherever it costs you the least.