If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/felixse/FluentTerminal shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 5mo ago

• Last commit 5mo ago
• 15 active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Concentrated ownership — top contributor handles 64% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live felixse/FluentTerminal repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/felixse/FluentTerminal.

What it runs against: a local clone of felixse/FluentTerminal — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in felixse/FluentTerminal | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 168 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of felixse/FluentTerminal. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/felixse/FluentTerminal.git
#   cd FluentTerminal
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of felixse/FluentTerminal and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "felixse/FluentTerminal(\\.git)?\\b" \\
  && ok "origin remote is felixse/FluentTerminal" \\
  || miss "origin remote is not felixse/FluentTerminal (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 168 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~138d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/felixse/FluentTerminal"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Fluent Terminal is a UWP (Universal Windows Platform) desktop terminal emulator that renders a terminal interface using web technologies (xterm.js via TypeScript/Webpack frontend) backed by C# services. It provides tabbed terminal sessions supporting PowerShell, CMD, WSL, SSH, and Mosh connections with theme customization, keybinding configuration, and shell profile management. Mixed-architecture monorepo: C# services layer (FluentTerminal.App.Services/, ~1M LOC) handles shell spawning, SSH/Mosh, settings persistence, and dialogs via WinPty/MoshExecutables; TypeScript/xterm.js frontend in src/ (webpack-bundled to dist/) communicates with C# backend over IPC; tests in FluentTerminal.App.Services.Test/ cover theme parsing and settings; CI/CD via .github/workflows/main.yml.

Windows power users and developers who want a modern, themeable terminal alternative to conhost.exe with support for multiple shells, SSH connections, and tabs—particularly those already in the Windows 10/11 UWP ecosystem or preferring Fluent Design aesthetics.

UNMAINTAINED AND ABANDONED. The project explicitly states it is no longer being maintained; the author recommends migrating to Microsoft's Windows Terminal instead. No active commits are visible, CI may be stale, and while it reached production quality (Microsoft Store availability), it receives no ongoing development or security updates.

CRITICAL RISK: This is an archived/unmaintained project. No recent commits, no active maintainer response expected, and security vulnerabilities will not be patched. Dependency versions in package.json (xterm ^4.18.0, webpack ^5.76.0) are outdated. Using this in production exposes you to unpatched UWP, terminal emulation, and SSH/Mosh protocol bugs. Single-author project with no active contributor community.

Nothing. Project is archived. Last meaningful activity was maintenance of CI configuration and test suites, but no new features or bugfixes are being merged. The GitHub workflows are likely stale.

Clone: git clone https://github.com/felixse/FluentTerminal.git. Install C# dependencies via Visual Studio 2019+ with UWP workload, then: cd FluentTerminal.App && npm install (installs xterm, webpack, TypeScript). Build frontend: npm run build (outputs to dist/). Open .sln in Visual Studio and build C# projects. Install from Microsoft Store or build AppX locally.

Daily commands: Build frontend: cd FluentTerminal.App && npm install && npm run build. Build C# (Visual Studio GUI): Open FluentTerminal.sln, set startup project to FluentTerminal.App, Build → Build Solution. Run locally: Debug via Visual Studio's F5 (deploys AppX to local machine).

• FluentTerminal.App/MainPage.xaml.cs: XAML codebehind: bridges UWP UI container with xterm.js frontend via WebView interop, handles input/output redirection
• src/index.ts: Main TypeScript entry point: initializes xterm.js, wires addon plugins (fit, search, web-links), sets up IPC communication with C# backend
• FluentTerminal.App.Services/ITerminalService.cs: Core interface defining shell spawning, terminal I/O, and SSH/Mosh session lifecycle; implementations manage WinPty processes
• FluentTerminal.App.Services/ISettingsService.cs: Persistence layer: theme, keybinding, and profile configuration loaded from ApplicationDataContainer (Windows Settings storage)
• package.json: Frontend dependency manifest: declares xterm.js version, Webpack build script, TypeScript tooling versions
• Dependencies/WinPty: Native pseudo-terminal binaries (x86/x64): required for shell spawning; WinPty is the core I/O multiplexer between terminal and PowerShell/CMD/WSL
• Dependencies/MoshExecutables: Pre-built Mosh client binaries: enable SSH-based mobile shell sessions with connection roaming
• FluentTerminal.App.Services.Test/: Unit test suite: covers theme parsing, settings serialization, keybinding resolution; validates dialog and data handling
• .github/workflows/main.yml: CI/CD pipeline: builds C# projects, runs tests, and generates AppX artifacts (likely stale since project is unmaintained)

Adding shell profiles: Modify FluentTerminal.App.Services/ApplicationDataContainers.cs and settings serialization. Theming: Update FluentTerminal.App.Services/Dialogs/ and theme parser in FluentTerminal.App.Services.Test/FluentTerminalThemeParserTests.cs. Frontend (terminal UI): Edit src/index.ts, src/style.css, rebuild with npm run build. Keybindings: FluentTerminal.App.Services/KeyboardCommandServiceTests.cs shows structure. SSH/Mosh: Native WinPty/Mosh code in Dependencies/ (binary blobs—requires separate build).

UWP Sandboxing: Terminal spawning is restricted by UWP's file/process access policies; WinPty bypasses some restrictions but not all (no direct stdin/stdout redirection outside sandbox boundaries). WinPty Version Lock: Binary blobs in Dependencies/ are hardcoded; updating requires recompiling WinPty separately—not automated. Xterm.js Event Routing: Frontend must marshal keypress/paste/resize events across WebView IPC boundary to C# with specific serialization; custom events not part of xterm.js API. ApplicationDataContainer: Settings persist in Windows registry under AppContainer path—debugging requires registry inspection, not file-based config. Missing Environment Setup: Building requires Visual Studio UWP workload AND Node.js (npm) installed in PATH; CI assumes both are available. Unmaintained Webpack Config: webpack.config.js is v5 but some loaders may have deprecated APIs; upgrading xterm.js to newer versions risks breaking loader compatibility.

• Pseudo-terminal (PTY) — Fluent Terminal delegates shell I/O multiplexing to WinPty—understanding PTY master/slave communication, signal handling (SIGWINCH for resize), and buffering is critical to diagnosing hangs or garbled output
• UWP (Universal Windows Platform) AppContainer Sandboxing — The app runs in a restricted UWP sandbox with limited file/registry/process access; WinPty and careful capability declarations in Package.appxmanifest allow shell spawning, but understanding AppContainer boundaries prevents security/functionality regressions
• WebView IPC (Inter-Process Communication) — Fluent Terminal bridges C# backend and TypeScript/xterm.js frontend via UWP WebView message passing; custom event marshaling and async serialization are non-obvious and fragile
• Terminal Emulation (VT100/ANSI escape codes) — Xterm.js decodes ANSI/VT100 escape sequences from shell stdout to render colors, cursor position, bold/underline; Fluent Terminal's theme engine must generate compatible color palettes
• Mosh (Mobile Shell) Protocol — Fluent Terminal bundles pre-built Mosh executables to enable roaming SSH; Mosh uses UDP state synchronization and predictive typing—understanding this helps debug connection instability or lag
• Webpack Module Bundling and Code Splitting — The frontend TypeScript and xterm.js dependencies are bundled into dist/ via webpack.config.js; the custom build script copies CSS/HTML manually—modifying bundle outputs or adding code-splitting requires webpack config changes
• Application Data Containers (Windows Settings Storage) — Fluent Terminal persists themes, keybindings, and profiles in ApplicationDataContainer (UWP's abstraction over Windows registry)—unlike file-based config, this requires programmatic access and is not human-editable, affecting testability and user troubleshooting

• microsoft/terminal — Direct successor: Windows Terminal is the recommended modern replacement for Fluent Terminal with richer theming, plugin support, and active maintenance
• xtermjs/xterm.js — Core dependency: Fluent Terminal's terminal rendering engine; understanding xterm.js event model and addon architecture is essential for frontend work
• mohanson/moha — Mosh documentation/reference: Fluent Terminal bundles Mosh executables for SSH roaming; familiarity with Mosh protocol helps debug connection issues
• rprichard/winpty — Pseudo-terminal backend: Fluent Terminal's shell I/O layer via WinPty DLLs; rebuilding or updating WinPty requires understanding its spawn/resize APIs
• microsoft/terminal-vscode-extension — Companion ecosystem: Fluent Terminal had a VS Code extension; reviewing this extension's architecture shows WebView-to-extension IPC patterns applicable to terminal emulator integrations

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for IThemeParser implementations and theme parsing edge cases

The repo has FluentTerminalThemeParserTests.cs and ITermThemeParserTests.cs in FluentTerminal.App.Services.Test, but given the complexity of parsing multiple theme formats (evidenced by TestData/AdventureTime.itermcolors and IThemeParserFactory), there are likely edge cases and error conditions not covered. The IThemeParser interface and ParseThemeException suggest theme parsing is critical but undertested.

• [ ] Review existing tests in FluentTerminal.App.Services.Test/FluentTerminalThemeParserTests.cs and ITermThemeParserTests.cs
• [ ] Add test cases for malformed theme files, missing required fields, and unsupported format versions
• [ ] Add integration tests for ThemeParserFactory.cs to verify correct parser selection across different theme formats
• [ ] Test ParseThemeException scenarios to ensure proper error handling and user feedback

Implement GitHub Actions workflow to validate Dependencies binaries and catch supply chain vulnerabilities

The repo commits pre-built binaries (mosh-client.exe, winpty.dll, etc.) to the Dependencies folder without a visible verification mechanism in .github/workflows/main.yml. This is a supply chain risk. A new workflow should validate checksums, verify digital signatures, and document the provenance of these binaries.

• [ ] Examine .github/workflows/main.yml to understand current CI pipeline
• [ ] Create a new workflow file (e.g., validate-dependencies.yml) that verifies SHA256 checksums of all binaries in Dependencies/MoshExecutables and Dependencies/WinPty
• [ ] Add a documented process (DEPENDENCIES.md) listing official sources, versions, and checksums for mosh and winpty
• [ ] Integrate the validation workflow to run on pull requests that modify Dependencies folder

Add comprehensive tests for SettingsService and IApplicationDataContainer persistence layer

SettingsServiceTests.cs exists but the ApplicationDataContainers.cs and ApplicationDataContainerAdapter.cs are critical infrastructure for persisting user preferences. Given the ISettingsService interface is central to the app, the persistence layer deserves thorough testing of serialization, migration, and edge cases like corrupted storage or permission errors.

• [ ] Review FluentTerminal.App.Services.Test/SettingsServiceTests.cs for current coverage
• [ ] Add unit tests for ApplicationDataContainerAdapter.cs covering read/write operations, null values, and type conversions
• [ ] Add tests for ISettingsService implementations to verify settings persistence across app restarts (using mock IApplicationDataContainer)
• [ ] Test backward compatibility: add tests ensuring old settings format can be migrated to new format without data loss

• Add unit tests for ITerminalService: The FluentTerminal.App.Services.Test/ folder has good coverage of settings and themes, but ITerminalService interface lacks mock-based tests for shell spawning and SSH session lifecycle. Writing xUnit tests with Moq for terminal creation/deletion would strengthen the foundation.
• Document the IPC protocol between frontend and C#: No TypeScript or C# documentation exists for the WebView message passing contract. Add XML doc comments to IPC marshaling code in MainPage.xaml.cs and src/index.ts explaining message format, error codes, and event sequencing.
• Migrate build system to .NET CLI from MSBuild GUI: The project currently requires Visual Studio IDE to build (F5 debug). Extract the AppX packaging logic into a .csproj target or PowerShell script so dotnet build + npm run build works headless in CI—unblocks container builds and GitHub Actions modernization.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.