Skip to content

Repository files navigation

Part Pilot

Part Pilot is a self-hosted electronics inventory manager for makers, hobbyists, repair benches, and small technical labs.

It combines configurable component templates with practical stock workflows, reusable catalogues, recoverable deletion, audit history, and a responsive dark interface. The long-term differentiator is MCP integration so approved AI assistants can understand and act on inventory safely.

Project status: active V1 development. The core inventory workflow is usable, but the project is not yet a public-alpha release.

Current capabilities

Inventory

  • Create parts from built-in or custom part-type templates.
  • Store typed template values, part numbers, descriptions, pricing, purchase links, notes, packages, manufacturers, and locations.
  • Search active inventory across part metadata, catalogues, locations, aliases, tags and typed custom fields.
  • Use server-backed part-type, location and stock-status filters with accurate totals and pagination.
  • Sort Available and Out of stock sections independently across the complete filtered result set.
  • Filter by stock status and reusable location.
  • View responsive part details.
  • Edit existing part metadata and typed values.
  • Add, remove, consume, and correct quantities with safeguards.
  • Review recent stock movement history.
  • Move parts to Deleted items and restore them without losing metadata or history.
  • Permanently purge selected Deleted items with explicit confirmation; active Reservations, Draft/Reserved Projects, and reserved quantities block purge.

Reusable catalogues

  • Manufacturer catalogue with seeded electronics brands and inline creation.
  • Package/form-factor catalogue with seeded options and inline creation.
  • Location catalogue with create, rename, notes, usage counts, and safe in-use deletion protection.
  • Custom part types with ordered dynamic fields.
  • Safe custom-type editing and deletion safeguards, including separate active and Deleted-items dependency counts with direct filtered recycle-bin navigation.

Platform

  • First-run setup and authenticated sessions.
  • FastAPI, SQLAlchemy, SQLite, and Alembic backend.
  • React, TypeScript, and Vite frontend.
  • Responsive desktop and mobile application shell.
  • Docker Compose deployment with persistent /data storage.
  • Automated database, API, migration, frontend-build, and route smoke checks.
  • Structured audit records for implemented inventory operations.
  • Protected system-wide History with unified audit and stock-movement search, filters, pagination and responsive detail inspection.

Planned V1 work

Major remaining areas include:

  • Static Bearer authentication in the MCP runtime.
  • Direct-key Settings controls and browser approval.
  • Custom-header and trusted-network MCP authentication modes.
  • Safeguarded MCP write tools.
  • Accessibility, security and public-alpha hardening.

See docs/Implementation_Roadmap.md for the detailed build plan and docs/Checkpoint.md for durable project decisions and completed checkpoints.

Quick start with Docker Compose

1. Clone the repository

git clone https://github.com/devanshtangri/Part-Pilot.git
cd Part-Pilot

2. Create the environment file

Linux/macOS:

cp .env.example .env

Windows Command Prompt:

copy .env.example .env

The default host port is 7890. Change PARTPILOT_HOST_PORT in .env when needed.

3. Build and start Part Pilot

docker compose up -d --build

Open:

http://localhost:7890

Persistent application data is stored under:

./data

4. Check container status

docker compose ps
docker compose logs --tail=100 partpilot

5. Run the complete smoke suite

docker compose exec -T partpilot python -m app.db.smoke_test

6. Stop the application

docker compose down

Do not delete ./data unless the database and application state are no longer needed.

Local development

Backend

cd backend
python -m venv .venv

Activate the virtual environment, install dependencies, then run:

pip install -r requirements.txt
uvicorn app.main:app --reload

Frontend

cd frontend
npm install
npm run dev

The Vite development server defaults to:

http://localhost:5173

Repository structure

backend/ FastAPI application, models, services, routes, migrations
frontend/ React and TypeScript application
docs/ product specification, roadmap, checkpoints, and handoffs
data/ persistent local runtime data; created during deployment
fixes/ repository patch and diagnostic scripts used during development

Development discipline

Part Pilot is being developed in narrow, verifiable slices:

  1. Inspect exact targets.
  2. Preflight transformations before writes.
  3. Back up changed files.
  4. Build and deploy.
  5. Run the complete smoke suite.
  6. Browser-test UI work.
  7. Commit implementation and documentation checkpoints separately.

This keeps the repository recoverable while larger V1 workflows are built.

Current development status

The current checkpoint includes authenticated dashboard stock alerts and a settings-driven Stored Parts workflow for separating zero-stock matches from available inventory.

CapabilityStatus
Inventory creation and metadata editingAvailable
Manufacturer, package, and location cataloguesAvailable
Stock quantity adjustments and movement historyAvailable
Soft deletion and restorationAvailable
Stored Parts universal search, filters, pagination, and sortingAvailable
Dashboard low-stock alertsAvailable
Unconfigured zero-stock detectionAvailable
Settings-driven out-of-stock groupingAvailable
Explicit In stock, Low, and Out filtersAvailable

When grouping is enabled, matching zero-stock parts appear in a dedicated section below normal Stored Parts results while the All filter is active. Disabling that preference hides the separate section without removing access to those parts through the explicit Out filter.

Focused Inventory workspace

The /inventory route now provides the live Stored Parts experience rather than a placeholder. It reuses the same implementation that remains available inside Part Manager, avoiding duplicate inventory logic.

The focused Inventory page supports:

  • adding and browsing parts;
  • search and location filters;
  • All, In stock, Low, and Out stock filters;
  • settings-driven separation of zero-stock matches;
  • part details and stock movement history;
  • quantity adjustments;
  • metadata editing;
  • recoverable deletion and restoration.

Part-type templates and custom-field management remain under /part-manager.

Universal inventory search

Part Pilot now includes a responsive Dashboard search experience backed by the inventory API.

Search coverage

  • part numbers and names;
  • descriptions, notes, and packages;
  • part types and manufacturers;
  • storage locations;
  • aliases and tags;
  • custom-field names and typed values.

Result experience

  • live results after a short pause while typing;
  • available parts shown before out-of-stock parts;
  • separate Available and Out of stock result cards;
  • result sections appear only when they contain matches;
  • selected-part quantities, location, notes, package, and custom fields;
  • keyboard launch with /;
  • responsive desktop and mobile layouts;
  • out-of-stock visibility controlled by Search settings.

Dashboard and Stored Parts search are complete and browser approved. Stored Parts now uses the backend universal-search contract with part-type, location and stock-status filters, accurate pagination, stale-response guards, and independent full-result sorting for Available and Out of stock sections.

Projects and reservations

Part Pilot separates planning from operational inventory commitments.

Users create a Draft Project for a build, repair, prototype or other planned work. A Project stores parts, quantities, notes and price snapshots without changing stock. Reserving the Project creates one linked active Reservation and atomically commits its planned quantities.

Draft Project
↓ Reserve
Reserved Project + Active Reservation
├─ Edit → synchronized Project + Reservation commitment
├─ Consume → Consumed Project + Consumed Reservation
└─ Cancel → Cancelled Project + Cancelled Reservation
CapabilityStatus
Project register, detail, creation and Draft/Reserved editingAvailable
Server-backed multi-result part search (up to 50 matches)Available
Price, currency and current-availability snapshotsAvailable
Atomic Project reservation with linked ReservationAvailable
Atomic Project consumption API and UIAvailable
Atomic Project cancellation/release API and UIAvailable
Two-way linked editing from Projects or ReservationsAvailable
Available/reserved/physical quantity accountingAvailable
Reserve/release/consume movements and paired auditsAvailable
Physical, Reserved and Available history snapshotsAvailable
Reservation activity and lifecycle actionsAvailable
Accessible in-app confirmations and stale-state handlingAvailable
Responsive desktop and mobile workflowsAvailable

Project consumption reuses the linked Reservation transaction: physical and reserved quantities decrease together, available quantity remains unchanged, both records become consumed, and paired movements and audits are written.

Project cancellation also reuses the linked Reservation transaction: reserved quantity returns to available stock without changing physical totals, both records become cancelled, and paired release movements and audits are written.

A Reserved commitment can be edited from either workspace. Projects preserves Project-specific description data, while shared names, notes, items, quantities, price/value snapshots and inventory deltas remain synchronized atomically. Quantity increases reserve only the additional units; decreases release only the removed units.

The Reservations page is the operational queue for committed inventory. Manual Reservation creation is intentionally absent from the frontend so users have one clear entry path: plan work in Projects, then reserve it. The backend Reservation-create API remains temporarily available for compatibility while future API and MCP behavior is defined.

Planned administration control

A future Settings update will add an authenticated control to enable or disable the MCP server. Default, restart behavior, transport/tool gating and auditing will be defined during the MCP implementation phase; the control is not implemented yet.

System-wide History

Part Pilot provides a protected chronological register across operational inventory and audit events.

CapabilityStatus
Unified audit and stock-movement registerAvailable
Deterministic newest-first paginationAvailable
Literal text searchAvailable
Kind, entity, event, actor, user and movement filtersAvailable
From/to date filteringAvailable
Counted filter facetsAvailable
Part, Reservation and Project contextAvailable
Physical, Reserved and Available snapshotsAvailable
Structured Before, After and metadata evidenceAvailable
Desktop register/detail workspaceAvailable
Register-first mobile detail workflowAvailable
Stale-response protectionAvailable

History remains newest-first by design. General sortable columns are omitted because the available filters support investigation without breaking the operational timeline. An Oldest-first option can be added later if a concrete investigation workflow requires it.

Global appearance and Settings

Part Pilot provides authenticated installation-wide appearance preferences with Dark, Light and System modes.

CapabilityStatus
Persisted Dark, Light and System preferencesAvailable
Pre-paint theme applicationAvailable
Live operating-system theme followingAvailable
Server synchronization and audit evidenceAvailable
Responsive Appearance settingsAvailable
Inventory search preferenceAvailable
Reservation expiry defaultsAvailable
Accessible database-reset review dialogAvailable
Light-theme coverage across all current workspacesAvailable
Explicit active, destructive and disabled statesAvailable

The stored preference is applied before the React application renders, so direct route loads do not flash the opposite theme. System mode follows prefers-color-scheme changes without a reload.

Database reset remains intentionally guarded: Settings presents one review action, then requires the exact destructive phrase inside an accessible in-app dialog before the final erase action becomes available.

Completed Settings workspace

The Settings workspace now uses a compact, responsive composition:

SectionDesktopMobile
AppearanceFull widthFull width
Inventory searchFull-width compact rowFull width
Reservation defaultsLower two-column rowFull width
Database resetEqual-height lower cardFull width

The Inventory preference preserves its server-backed boolean behavior and explicit Out filter while displaying a concise On/Off/Saving switch. The Reservation and Database reset cards align on desktop without enlarging their controls, and return to natural independent heights below the desktop breakpoint.

Dark, Light and System modes remain installation-wide. The page-level runtime status and selected theme card identify the active appearance; duplicate resolved-theme text has been removed.

Backup and restore is the next independent product area. The existing database-reset action remains a separate guarded permanent operation.

Backup and restore

Part Pilot supports portable manual backups and guarded database restoration.

CapabilityStatus
Versioned .ppbackup artifactAvailable
SQLite online snapshotAvailable
Manifest, schema, hash and integrity evidenceAvailable
Protected manual downloadAvailable
No-store response headersAvailable
Strict archive and database validationAvailable
Review-before-restore workflowAvailable
Rollback snapshot and atomic replacementAvailable
Session invalidation after restoreAvailable
Responsive Settings controlsAvailable
Manual-backup status APIAvailable
Scheduled backupsNot implemented
Retained server-side backup copiesNot implemented

A .ppbackup contains exactly manifest.json and partpilot.db. Restore validation completes before live data is touched. A successful restore uses a same-filesystem staged replacement, verifies the result, records an audit and requires every user to sign in again.

Current backup behavior is manual download only. Part Pilot does not schedule backups and does not retain a server-side copy after the download operation. The compact manual-backup status display is implemented and available in Settings.

Model Context Protocol authentication and OAuth administration

Part Pilot exposes an authenticated, stateless JSON Streamable HTTP endpoint at /mcp.

CapabilityStatus
OAuth protected-resource discoveryAvailable
OAuth authorization code with PKCEAvailable
Access/refresh token rotation and revocationAvailable
Standalone OAuth consent and error experienceAvailable
Claude and ChatGPT OAuth read-only flowsVerified end to end
Connected/manageable OAuth client administrationAvailable
Manual OAuth client registration in SettingsAvailable
Public clients with PKCE and no client secretAvailable
Confidential clients with secret POST or BasicAvailable
One-time confidential secret display with digest-only storageAvailable
Explicit public-origin and Host/Origin validationAvailable
Global MCP and read/write authorization settingsAvailable
Six read-only inventory, Project and Reservation toolsAvailable
Official Python MCP SDK compatibilityVerified
Public Nginx TLS Streamable HTTP pathVerified
Static Bearer key authenticationAvailable
Dedicated custom-header key authenticationAvailable
Trusted-network authentication with IPv4/IPv6 CIDRsAvailable
Named direct MCP clients (Bearer/custom-header/trusted-network)Available
Direct-client master and typed-confirmed no-auth fallbackAvailable
Individual-tool and per-client MCP permissionsAvailable
Safeguarded MCP write toolsNot yet implemented

The live installation keeps MCP and read tools enabled while write authorization, named direct clients, and no-auth fallback remain disabled. Named direct clients can be enabled independently of OAuth; the no-auth fallback is read-only and requires exact typed confirmation. OAuth registration supports explicit current-user ownership for manually created clients, safe manageable-client status, exact revocation, and one-time confidential secret display. Revoked clients remain available to backend audit/history semantics but are hidden from the normal active Settings list.

Claude and ChatGPT OAuth connection flows have been verified end to end. During Chat 20, a manually registered Claude client also connected successfully using Claude's fixed callback and client_secret_post. Gemini/Google reached Part Pilot consent and authorization-code issuance during testing, but the Google callback did not complete a token exchange; Part Pilot's issued code was not redeemed.

Current-user account and session administration

CapabilityStatus
Protected profile read/update APIAvailable
Username normalization and uniquenessAvailable
Display-name updateAvailable
Built-in avatar persistence/catalogueAvailable
Database-backed custom avatar upload/crop/removalAvailable
Current-user avatar state in /auth/meAvailable
Password change requiring current passwordAvailable
Current-session-safe password rotationAvailable
Active-session list and targeted/revoke-all-other controlsAvailable
New-session User-Agent/client-IP captureAvailable
Account/Security Settings UIAvailable

Built-in avatar IDs are initials, chip, circuit, terminal, storage, and rocket. Uploaded avatars are normalized server-side and stored in SQLite so backup/restore preserves them. Sessions created before client-metadata capture remain honestly reported as Unknown rather than being backfilled or guessed.

MCP permission browser-test batch

Chat 22 established the live 0016_mcp_tool_permissions schema and pending administration/UI source for global individual-tool permissions plus OAuth and named-direct client deny overrides.

The browser-test configuration currently has search_parts globally disabled. The other five read tools remain enabled and client deny lists are empty. Call-time authorization already enforces the effective policy.

The remaining refinement in Chat 23 is to filter ineffective tools from the authenticated MCP tools/list catalogue, grey client overrides under global blocks, show the current absence of real write tools honestly, and align the Add-direct-client form styling. The complete permission batch remains uncommitted application source until browser approval.

Regional display preferences

Part Pilot provides workspace-level Currency and Display timezone preferences under Settings → Preferences → Regional display.

  • Currency uses a persisted uppercase three-letter ISO code for display formatting only. Changing it does not perform foreign-exchange conversion or rewrite historical Project/Reservation currency snapshots.
  • Display timezone uses an IANA timezone and changes passive timestamp presentation across the workspace. Stored timestamps are not rewritten, and datetime-local entry semantics are unchanged.
  • Both preferences save independently and use the same themed Settings controls as the rest of Part Pilot.

Chat 23 public milestone

Chat 23 completes MCP permission finalization and Settings modernization. Part Pilot now has principal-aware individual MCP tool permissions, a clearer Direct MCP access hierarchy, reversible Preferences autosave with independent targeted resets, and workspace-level Currency + Display timezone controls. Currency is display formatting only; timezone changes passive presentation only. Historical currency snapshots and stored timestamps remain authoritative.

The next implementation milestone is authenticated server-driven invalidation/targeted refetch, followed by public-alpha API documentation hardening and whole-inventory metrics.

Authenticated live updates

Part Pilot now has a browser-approved authenticated live-update foundation for Stored Parts/Part Manager and History. Successful inventory mutations emit server-side invalidations over an authenticated event stream; open tabs refetch the affected data without rewriting each tab's local search/filter/sort/page or selection state. Same-browser tabs also relay deduplicated invalidations for prompt multi-tab updates, while reconnect/replay and degraded polling provide recovery if the stream is interrupted.

This is an incremental public-alpha hardening feature. Other workspaces are being migrated to the same invalidation model deliberately rather than relying on broad full-page refreshes.

Projects and Reservations live updates

Projects and Reservations now participate in the authenticated live-update system. Linked Project/Reservation edits and lifecycle changes invalidate the affected workspaces after successful commits, and open tabs refetch their current lists/details/activity without replacing local filters, search, pagination or selection.

Dashboard live inventory updates

The Dashboard now follows authenticated inventory invalidations too. Low-stock alerts and an already-open universal search refresh automatically after inventory changes, while each tab keeps its own query and current selected search result whenever that part still matches.

Live Settings and account updates

Part Pilot now propagates workspace preferences, account identity/session changes and manual-backup status across authenticated open tabs. Theme, currency, timezone and inventory display preferences update their existing consumers automatically, while unfinished local Account or Reservation edits are protected from cross-tab refresh.

Chat 24 live-sync boundary

Authenticated live sync is browser-approved for Inventory/History, Projects/Reservations, Dashboard and non-credential Settings. The remaining REST API-key/MCP integration slice moves to Chat 25 after a diagnostic found legacy OAuth smoke tests coupled to mutable historical client IDs.

Live API-key and MCP integration updates

REST API-key and MCP administration now participate in Part Pilot's authenticated live-update system. Open tabs refresh integration state after successful mutations without transporting plaintext credentials, while local unfinished MCP drafts and credential dialogs remain protected. Together with the earlier inventory, project, reservation, Dashboard and Settings slices, this completes the current public-alpha live-sync migration.

Stable MCP autosave

Reversible MCP access and global read-tool permissions now save automatically. The no-auth fallback still requires explicit confirmation before enabling, and credential/client lifecycle actions remain explicit. Already-loaded MCP state stays visible while authenticated live-sync refreshes happen in the background, so normal cross-tab updates no longer replace the section with a loading flash.

Stable live background refresh

Already-loaded live-sync surfaces now stay mounted while matching authenticated background refetches run. Blocking loading states are reserved for first loads or genuine query/page/selection changes; cross-tab updates replace cached data in place. This behavior covers Projects, Reservations, History, Dashboard, Settings/account/data, REST API keys and selected Stored Parts details/history.

Public API documentation and restore safety

Swagger and ReDoc now describe Part Pilot's Bearer authentication model, exact REST API-key scopes, session-only administration and MCP OAuth protocol boundary. The same hardening sweep aligned restore schemas to Alembic 0016 and made restore logical hashing safe for SQLite BLOB data such as custom avatars.

Whole-inventory Stored Parts metrics

Stored Parts now presents six live whole-inventory metrics for active records, physical/reserved/available units, Stock alerts and inventory value. The cards are independent of the current table filters/page, exclude deleted parts, keep pricing coverage visible, and use workspace currency for display only. Their responsive grid follows the available Stored Parts width symmetrically, while GET /api/parts/metrics is available to authenticated sessions and inventory:read REST API keys.

Dashboard operational home

The Dashboard now uses Stock alerts as the single gateway to a live-synced alert dialog and provides compact Quick actions for common inventory/project workflows. Redundant backend-status and inline low-stock panels are removed. Routine Refresh buttons are also gone from the live-synced Dashboard, Stored Parts, Projects, Reservations and History views; request-failure Retry actions remain available.

User roles and authorization

Part Pilot now has an enforceable Owner / Administrator / Operator / Viewer authorization foundation. Existing installations migrate their current accounts to Owner without recreating the SQLite users table. Operational REST requests, REST API keys, workspace/MCP administration, backups and restore/reset actions are checked against role ceilings, and session-only user administration protects the last active Owner. The backend APIs support user lifecycle management; a future Settings UI can present those controls without changing the security boundary.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages