GO — Healthy across all four use cases

• Last commit 2d ago
• 10 active contributors
• MIT licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 74% of recent commits
• ⚠ No test directory detected

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

Files is a modern Windows file manager built in C# and WinUI that replaces the default Windows Explorer with a productivity-focused alternative. It provides multitasking experiences, file tagging, deep OS integrations, and an intuitive blade-based navigation UI, all distributed via Microsoft Store or classic MSIX installer. Monorepo structure: src/Files.App.Controls contains reusable custom controls (AdaptiveGridView, BladeView for navigation), src/Files.App.BackgroundTasks handles scheduled/background operations, with the main application likely in src/Files.App (not fully listed). Controls are modular and follow a pattern of separating properties, events, and core logic into separate partial classes (e.g., BladeItem.cs, BladeItem.Properties.cs, BladeItem.Events.cs).

Windows power users and file management enthusiasts who want a faster, more feature-rich alternative to Windows Explorer; open-source contributors interested in WinUI/UWP desktop applications and file system operations.

Actively developed and production-ready. The project has established CI/CD pipelines (ci.yml, cd-store-stable.yml, cd-sideload-stable.yml), a mature community (Discord badge, Crowdin localization), and is distributed through the Microsoft Store. Regular releases and documented build processes indicate healthy maintenance.

Community-driven sustainability depends on active contributor base; the large C# codebase (~3.9MB) with WinUI/UWP dependencies introduces platform lock-in risk to Windows 10/11. No obvious single-maintainer risk visible, but validate open issue backlog and PR velocity before relying on it for critical features. WinUI is still evolving—API stability is generally good but watch for breaking changes across major OS updates.

Active development on CI/CD optimization (format-xaml.yml workflow for XAML style consistency), background task improvements (UpdateTask.cs), and component refinement. Multiple deployment channels (preview via cd-sideload-preview.yml and cd-store-preview.yml, stable variants) indicate ongoing feature iteration and staged rollouts.

Clone the repo: git clone https://github.com/files-community/Files.git && cd Files. Restore dependencies and build: nuget restore Files.slnx && msbuild Files.slnx. See https://files.community/docs/contributing/building-from-source for detailed build instructions for WinUI/UWP targeting.

Daily commands: After building with msbuild, run the packaged MSIX from the output directory or deploy to a Windows device. For development iteration, use Visual Studio's local deployment (F5 in VS after opening Files.slnx).

• Files.slnx — Solution file that defines the entire project structure and build configuration for the Files application.
• src/Files.App.Controls/Files.App.Controls.csproj — Core controls library that provides reusable UI components (AdaptiveGridView, BladeView, BreadcrumbBar, etc.) used throughout the application.
• Directory.Build.props — Central build properties file that sets common compilation settings, target frameworks, and package dependencies across all projects.
• Directory.Packages.props — Centralized NuGet package version management file that ensures consistent dependency versions across the solution.
• .github/workflows/ci.yml — Primary CI/CD workflow that runs automated builds, tests, and validation on every commit to ensure code quality.
• src/Files.App.Controls/AdaptiveGridView/AdaptiveGridView.cs — Core adaptive grid layout component that is foundational for responsive file display and list rendering throughout the application.
• src/Files.App.Controls/Sidebar/SidebarView.xaml.cs — Main sidebar navigation component providing primary user interaction for folder navigation and view management.

• AdaptiveGridView (C#, XAML, Windows.UI.Xaml) — Renders virtualized grid of files/folders with responsive column layout; handles selection, drag-drop, and keyboard navigation
  • Failure mode: Crashes on invalid file paths; hangs on slow disk I/O or large folder enumeration; column calculations fail with extreme window sizes
• SidebarView (C#, XAML, ISidebarItemModel) — Manages hierarchical folder navigation, favorites, shortcuts; coordinates between breadcrumb, grid, and main view state
  • Failure mode: Item selection races with folder navigation; drag-drop operations corrupt state if interrupted; path

Add a new custom control

1. Create a new folder under src/Files.App.Controls/ with your control name (src/Files.App.Controls/YourControl/)
2. Implement the main control class (e.g., YourControl.cs) following the pattern of AdaptiveGridView.cs with Properties and Events partial classes (src/Files.App.Controls/YourControl/YourControl.cs)
3. Create XAML markup file (YourControl.xaml) if your control has visual structure (src/Files.App.Controls/YourControl/YourControl.xaml)
4. Add the control to the Files.App.Controls.csproj project file by referencing its .xaml and .cs files (src/Files.App.Controls/Files.App.Controls.csproj)

Add a new sidebar navigation item

1. Create a new class implementing ISidebarItemModel interface in the Sidebar directory (src/Files.App.Controls/Sidebar/ISidebarItemModel.cs)
2. Implement the item properties including icon, label, path, and metadata following existing patterns (src/Files.App.Controls/Sidebar/SidebarItem.Properties.cs)
3. Register the new item type in the SidebarView code-behind to handle its initialization and events (src/Files.App.Controls/Sidebar/SidebarView.xaml.cs)
4. Add styling rules in SidebarStyles.xaml to define the visual appearance of the new item type (src/Files.App.Controls/Sidebar/SidebarStyles.xaml)

Add a new CI workflow

1. Create a new .yml file in .github/workflows/ following naming convention (e.g., cd-store-preview.yml) (.github/workflows/your-workflow.yml)
2. Define GitHub Actions workflow triggers, jobs, and build steps referencing existing PowerShell scripts (.github/workflows/your-workflow.yml)
3. Use existing build scripts like Configure-AppxManifest.ps1 and Create-MsixBundle.ps1 in your workflow steps (.github/scripts/Configure-AppxManifest.ps1)

• C# with .NET (via csproj files) — Windows-native development for a modern UWP/WinUI file manager with access to system APIs and native performance
• XAML for UI markup — Declarative UI framework for WinUI controls with data binding, styling, and layout capabilities standard for Windows applications
• GitHub Actions workflows — Native CI/CD for rapid iteration, automated testing, and release automation directly integrated with the repository
• PowerShell scripts for packaging — Windows-native scripting for MSIX/AppX manifest configuration and bundle creation without cross-platform overhead
• Centralized package management (Directory.Packages.props) — Ensures consistent NuGet dependency versions across all projects, reducing compatibility issues and build drift

• Windows-only development (C#/.NET/XAML/MSIX)

  • Why: Maximizes native OS integration, performance, and access to Windows-specific file system APIs
  • Consequence: No cross-platform support; limits audience to Windows users and increases developer friction for non-Windows contributors

• Monolithic control library (Files.App.Controls) rather than separate packages

  • Why: Simplifies versioning and ensures all controls evolve together with consistent APIs
  • Consequence: Changes to one control affect the entire library; harder for external consumers to cherry-pick components

• Multiple deployment workflows (Store, Sideload, Preview)

  • Why: Supports diverse user preferences and testing channels
  • Consequence: Increased CI/CD complexity and maintenance burden; more release testing required

• Cross-platform support (explicitly Windows-only via XAML/MSIX packaging)
• Web-based file manager interface (native desktop application)
• Network file system management (local Windows file system focus)
• Real-time collaboration features (single-user focused)

WinUI/UWP development requires Windows 10/11 build environment (not easily cross-platform); SDK versions in global.json are strict—missing or mismatched Windows SDK versions cause silent build failures. MSIX packaging requires signing certificates (see Generate-SelfCertPfx.ps1); preview/stable channels share code but differ in deployment manifests (check .github/scripts/Configure-AppxManifest.ps1 for manifest manipulation). Crowdin integration (crowdin.yml) requires API tokens for localization sync—not needed for local development but breaks if you modify string resources without the proper workflow.

• MVVM (Model-View-ViewModel) Pattern — Files uses MVVM to decouple UI logic from business logic; understanding this pattern is essential for modifying or extending file browser features without breaking the navigation model
• Blade Navigation (Onion/Master-Detail Pattern) — The BladeView control implements a stacked-pane navigation model unique to Files; mastering this is critical for understanding how file hierarchy exploration works in the UI
• WinRT (Windows Runtime) — Files uses WinRT APIs for OS-level file system access, permissions handling, and deep Windows integration; understanding WinRT projection is necessary for implementing new OS integration features
• MSIX Package Format — Files is distributed as an MSIX bundle via Microsoft Store; understanding MSIX signing, manifest configuration, and deployment is essential for release engineering and testing packaged app scenarios
• Responsive UI / Adaptive Layout — The AdaptiveGridView control dynamically adjusts column counts based on window size; understanding adaptive patterns is core to Files' multi-window and responsive design philosophy
• Background Tasks / Scheduled Agents — The UpdateTask in src/Files.App.BackgroundTasks shows how Files handles async file monitoring and maintenance without freezing the UI; essential for understanding scalability to large file trees
• Partial Classes (C# Feature) — Files uses partial classes extensively (BladeItem.cs, BladeItem.Properties.cs, BladeItem.Events.cs) to organize code by concern; this pattern is non-obvious to newcomers but critical for maintainability in WinUI codebases

• microsoft/WinUI-Gallery — Official Microsoft WinUI component showcase and best practices—essential reference for modern Windows app patterns used in Files
• niels9001/Files-Preview — Early prototype and design exploration for Files, showing the iterative design process and feature roadmap decisions
• microsoft/TerminalApp — Sibling modern Windows app using WinUI 3 and MSIX packaging; shares deployment and CI/CD patterns with Files
• sbaeumlisberger/RaytracerChallenge — Alternative file managers in the Windows ecosystem; provides context for feature differentiation and UX patterns

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 AdaptiveGridView control

The AdaptiveGridView is a core UI component used throughout Files for displaying file listings, but there are no visible unit tests for its properties, layout calculations, or height conversion logic. Adding tests for AdaptiveGridView.cs, AdaptiveGridView.Properties.cs, and AdaptiveHeightValueConverter.cs would improve reliability and catch regressions in this critical component.

• [ ] Create a new test project or add to existing test suite targeting src/Files.App.Controls
• [ ] Add unit tests for AdaptiveHeightValueConverter.cs to verify Convert() and ConvertBack() logic
• [ ] Add property binding tests for AdaptiveGridView.Properties.cs (ItemHeight, DesiredWidth, etc.)
• [ ] Add layout and dimension calculation tests for AdaptiveGridView.cs
• [ ] Integrate tests into ci.yml workflow to run on PR validation

Add comprehensive tests for BreadcrumbBar navigation component

The BreadcrumbBar is essential for navigation UX, with multiple interacting parts (BreadcrumbBar.cs, BreadcrumbBarItem.cs, BreadcrumbBarLayout.cs, EventArgs.cs). Currently no visible test coverage exists for navigation events, item rendering, layout behavior, or accessibility (BreadcrumbBarItemAutomationPeer.cs).

• [ ] Create test class for BreadcrumbBar.cs covering ItemsSource binding and navigation
• [ ] Add event tests for BreadcrumbBarItem.Events.cs (ItemClicked, ItemPointerEntered, etc.)
• [ ] Test BreadcrumbBarLayout.cs custom layout logic with various item counts and widths
• [ ] Add automation peer tests for BreadcrumbBarItemAutomationPeer.cs to verify accessibility
• [ ] Add tests for EventArgs.cs custom event argument classes
• [ ] Include tests in ci.yml workflow

Add integration tests for Background Tasks (UpdateTask)

The Files.App.BackgroundTasks project contains UpdateTask.cs which handles background updates, but there's no visible test coverage. Background tasks are critical for app reliability and should have integration tests verifying task triggering, completion, and error handling.

• [ ] Create integration test project targeting src/Files.App.BackgroundTasks/UpdateTask.cs
• [ ] Add tests for UpdateTask initialization and background registration
• [ ] Test UpdateTask.Run() method with mocked system conditions (battery level, network, etc.)
• [ ] Add tests for error handling and retry logic in update scenarios
• [ ] Test integration with Files.App.BackgroundTasks.csproj dependencies
• [ ] Add workflow step to ci.yml to run background task tests separately (they may require special execution context)

• Add unit tests for AdaptiveGridView.Properties.cs—the file exists but no test coverage is visible in the file list; adding tests for responsive column calculation would improve reliability and serve as a learning opportunity for WinUI testing patterns.
• Document the BladeView navigation model in a CONTRIBUTING guide with diagrams—the .github/CONTRIBUTING.md is mentioned but the specific blade interaction model (push/pop semantics) is not explained, making it hard for contributors to extend it correctly.
• Implement localization string review automation in the CI pipeline—crowdin.yml exists but there's no validation step shown; adding a workflow step to detect untranslated UI strings in the app would prevent regressions.

The Files application shows a generally reasonable security posture for a desktop file manager with proper project structure and GitHub-based security practices (FUNDING, CODE_OF_CONDUCT). However, several areas require attention: (1) File system operations must be thoroughly validated to prevent path traversal attacks, which is critical for a file manager; (2) Dependency management needs automated vulnerability scanning; (3) XAML-based UI controls should enforce strict input validation; (4) Background tasks should avoid insecure deserialization patterns. The application uses modern C# and WinUI framework which provide some inherent security features. Conduct thorough code review of core file handling logic, implement automated security testing in CI/CD, and maintain up-to-date dependencies.

• Medium · Potential Insecure Deserialization Risk in UpdateTask — src/Files.App.BackgroundTasks/UpdateTask.cs. The UpdateTask.cs file in background tasks may handle serialized data without proper validation. Background tasks often process data from untrusted sources (scheduled jobs, notifications). Without explicit code review, there's a risk of insecure deserialization if the application deserializes user-controlled data. Fix: Review UpdateTask.cs to ensure all deserialization operations use safe patterns. Validate all data before deserialization, use TypeNameHandling = TypeNameHandling.None in JSON.NET, and implement input validation.
• Medium · Missing Dependency Manifest Review — Directory.Packages.props, nuget.config, *.csproj files. The Directory.Packages.props and nuget.config files are present but content was not provided for analysis. These files control NuGet dependencies. Without visibility into them, potential vulnerable package versions or insecure package sources cannot be verified. Fix: Conduct a thorough audit of all NuGet dependencies using 'dotnet list package --vulnerable' and verify all package sources are legitimate HTTPS endpoints. Implement automated dependency scanning in CI/CD pipeline.
• Medium · Potential Unsafe File System Operations — src/Files.App (core implementation not fully visible). A file manager application handles file operations extensively. Without reviewing the actual implementation files, there's risk of Path Traversal vulnerabilities if user input (file paths, navigation) isn't properly sanitized before being passed to file system APIs. Fix: Implement strict input validation on all file paths. Use Path.GetFullPath() and verify the resolved path is within expected directories. Never concatenate user input directly with file paths. Implement whitelist-based path validation.
• Low · GitHub Workflow Secrets Management — .github/workflows/cd-*.yml, .github/workflows/ci.yml. Multiple CD/CI workflow files are present (.github/workflows/*.yml). Potential risk of secrets exposure in logs if workflows are not properly configured to mask sensitive data in outputs. Fix: Review all workflow files to ensure secrets are marked with 'secrets.VARIABLE_NAME' syntax. Ensure no secrets are logged in build output. Use GitHub's secret masking features and audit workflow permissions.
• Low · Missing XAML Input Validation Context — src/Files.App.Controls/**/*.xaml, Converter files. Multiple XAML-based UI controls exist (BreadcrumbBar, Omnibar, BladeView). XAML binding without proper ValueConverter validation could lead to UI-based injection or unintended type coercion issues. Fix: Review all XAML bindings and ValueConverters to ensure proper input validation. Implement try-catch in converters and validate converted types. Use explicit Type declarations in bindings.
• Low · Potential Information Disclosure in Error Handling — Application-wide error handling. No comprehensive error handling review visible. File manager applications may expose sensitive path information or system details in error messages if not properly sanitized. Fix: Implement centralized error handling that logs detailed errors securely while displaying user-friendly messages. Never include file paths, system information, or stack traces in user-facing error dialogs.

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

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

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/files-community/Files 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.

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

What it runs against: a local clone of files-community/Files — 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 files-community/Files | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of files-community/Files. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/files-community/Files.git
#   cd Files
#
# 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 files-community/Files and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "Files.slnx" \\
  && ok "Files.slnx" \\
  || miss "missing critical file: Files.slnx"
test -f "src/Files.App.Controls/Files.App.Controls.csproj" \\
  && ok "src/Files.App.Controls/Files.App.Controls.csproj" \\
  || miss "missing critical file: src/Files.App.Controls/Files.App.Controls.csproj"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
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/files-community/Files"
  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).

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