KiCAD Prism v3.0.0-alpha

[krishna-swaroop]

KiCAD Prism v3.0.0-alpha — visual design review, component governance, and a production-shaped platform

KiCAD Prism v3.0.0-alpha is the largest update to Prism so far. Since
v2.0.0-alpha, the project has grown from a useful Git-backed KiCad workspace
into a much broader hardware collaboration platform: one place to import and
organize projects, explore complete designs in the browser, compare two
immutable revisions at the engineering-object level, discuss findings in
context, and manage a revisioned component library from intake through release.

This release represents 250 commits across 504 changed files, with roughly
148,000 lines added since v2.0.0-alpha. The amount of code is not the point,
but it gives useful scale: v3 is not a cosmetic iteration. It replaces major
parts of the viewer and storage architecture, introduces entirely new review
and library workflows, and adds the deployment and operational foundations
needed to run Prism as a persistent team service.

Important

This is still an alpha release. The product and its data contracts may
change before a stable release. v3.0.0-alpha intentionally does not promise an
in-place data migration from v2.0.0-alpha; read the upgrade note near the end
of this post before replacing an existing installation.

At a glance

The headline changes in v3.0.0-alpha are:

• A redesigned Design Comparison workspace that understands schematic,
  PCB, BOM, stackup, fabrication, constraint, and net changes—not merely file
  diffs.
• A new Library Manager with a revisioned component catalog, CAD assets,
  validation, import remediation, lifecycle states, approval, and KiCad-facing
  exports.
• A substantially rebuilt schematic, PCB, 3D, BOM, stackup, and assembly
  visualization experience, powered by the pinned Prism ECAD viewer runtime.
• A PostgreSQL-native service architecture with separate application and
  background-worker responsibilities, durable jobs, schema migrations, and
  operational recovery tools.
• Stronger Git project workflows, including branch-aware viewing, multi-
  project repository discovery, queued import and sync work, secure SSH host
  verification, and automatically rendered project thumbnails.
• In-context comments and review threads, including severity, class,
  mentions, resolution, ECAD markers, and comparison discussions pinned to the
  exact base and compare revisions.
• A broad UX pass: command palette, keyboard shortcuts, better permission
  explanations, safer destructive actions, virtualized large lists, app-native
  confirmations, and more resilient panel-level error handling.
• A proper release and deployment path with quality-gated images, digest-
  pinned release bundles, a guided deployment installer, backups, restore
  checks, health checks, and smoke tests.

---

A more useful workspace for real repositories

The workspace remains the front door to Prism, but project handling is much
more capable than it was in v2.

Repositories are no longer treated as if every Git repository contains exactly
one KiCad project at its root. Prism now discovers projects in the layouts that
real hardware repositories use, supports importing additional projects from a
repository that has already been added, and can import from a selected branch.
Project views are branch-aware, so a user can inspect another branch without
mutating the shared source checkout or losing the project identity already
stored in Prism.

Import and synchronization are now durable background operations rather than
long, opaque browser requests. The UI reports what it is doing, expensive work
is delegated to workers, and generated Prism artifacts are kept outside the Git
checkout. Synchronization no longer merges changes into a working tree behind
the user's back.

The import path also received a security and diagnostics pass:

• Clone URLs are validated and import claims are re-derived on the server.
• SSH host keys are pinned for synchronization as well as initial import.
• Missing SSH client capability and clone failures are reported in terms an
  operator can act on.
• Git access and trust configuration are visible and verifiable.
• Project source, generated artifacts, and component-library assets have clearer
  ownership boundaries.

Project cards can now use thumbnails rendered from the actual board rather than
trusting an arbitrary image committed to the repository. The workspace also has
gallery and list presentations, pagination, bulk selection, folders, project
properties, and safer move, rename, and delete interactions.

The same workspace flow is also usable for a second real project shape. The
USB-PD-Trigger-Board example below shows the searchable, thumbnail-backed
project card without requiring a reviewer to know the repository layout first.

The new visual review experience

The v3 visualizer has been rebuilt around the pinned Prism ECAD viewer bundle.
It is no longer a collection of disconnected previews. Schematic, PCB, 3D, BOM,
stackup, and assembly views share a common project context and a consistent set
of selection, navigation, and commenting behaviours.

Hierarchical schematic navigation

Large hierarchical schematics are first-class. Prism builds a page catalog,
shows the full sheet hierarchy, supports searching page names, and resolves
parent-sheet navigation to the correct instance. The page list is contained and
scrollable while its search field remains visible, including trackpad and wheel
scrolling on long designs.

Page identity is instance-aware rather than filename-only. That distinction is
important when a schematic file is instantiated more than once or when the two
revisions in a comparison do not contain exactly the same hierarchy.

Cross-probing and engineering-object selection

Selection is shared across schematic, PCB, and 3D contexts. Components, pins,
nets, pads, vias, zones, and tracks can be selected and inspected; the viewer
can frame the selected object, highlight related objects, and isolate a net.
Component focus and net isolation now survive the view transitions where that
state is still meaningful.

The side panel reports engineering data rather than only graphic primitives:
references, values, part metadata, pins, connectivity, layers, object identity,
and source context. A click on a hierarchical sheet symbol selects it without
accidentally opening the child page; navigation remains an explicit action.

Browser-native PCB and 3D exploration

The PCB pipeline now emits semantic, tiled glTF suitable for WebGPU rendering.
It supports board and component visibility, copper-layer controls, net-aware
objects, component selection, and staged loading for larger designs. Copper
geometry is generated and loaded as needed, and expensive PCB parsing is
deferred while a reviewer is working only in the schematic domain.

Pad orientation, rotated-footprint handling, back-side footprint presentation,
board visibility during staged jobs, and un-isolation behaviour have all been
corrected during the v3 cycle. The result is a viewer that is much closer to a
practical engineering inspection surface than the static 3D preview in earlier
builds.

BOM, stackup, and assembly views

The visualizer now includes an engineering BOM table with grouped rows, search,
additional project fields, DNP reporting, and cross-probing by reference. Board
stackup has its own graphic and tabular presentation. Assembly Assistant builds
on the same semantic selection model so an operator can move between a part,
its board position, and its project data without mentally joining separate
tools.

Importing a selected component into the Component database

Selecting a reference in the Cynthion BOM opens the selection inspector with the
component identity and library provenance in view. The Import into Library
action stages that project component for review in the Component database,
including its symbol, footprint, 3D model, and project metadata. This keeps the
visualizer useful as an intake surface without making it a KiCad-file authoring
surface: the source design remains in Git, while the catalog receives a
reviewable, provenance-pinned component record.

Design Comparison: review the design, not the Git syntax

Design Comparison is the centrepiece of v3.0.0-alpha. A reviewer chooses a base
and compare revision from History, then reviews parser-owned changes across the
design in a dedicated three-zone workspace.

The left rail is the review queue, grouped by domain and change type. The middle
is the visual evidence. The right rail explains the selected change and hosts
its context and discussion. Selecting R110, for example, can take the reviewer
directly to the affected component and show the value, description, part number,
footprint, and other before/after properties instead of asking them to infer the
change from a line-oriented schematic diff.

Comparison domains

The comparison API and UI can represent:

• Schematic: components, properties, connectivity, hierarchy, page
  instances, and visual evidence.
• PCB: components and board objects with revision-aware geometry.
• BOM: quantity and field changes, including added, removed, modified, and
  unchanged states.
• Stackup: layer construction and material/thickness changes.
• Fabrication: fabrication-output changes and cached evidence.
• Constraints and nets: parser-owned identity and evidence used by the
  review model, even when surfaced through another domain's presentation.

The implementation uses one semantic parser model rather than maintaining
different interpretations of the same KiCad object in the backend, UI, and
viewer. Stable object identities, digests, and side-specific evidence make the
review queue more deterministic and allow changes to deep-link reliably.

Composite, side-by-side, and Old/New presentations

Reviewers can choose the presentation that best explains a change:

• Composite overlays the two revisions where that produces meaningful
  evidence.
• Side by side keeps the base and compare canvases visible together and
  synchronizes their cameras.
• Old / New switches the presented revision without rebuilding the entire
  review session or losing the current selection.

The presentation policy is domain-aware, so the UI can preserve a usable panel
when a domain is unchanged or when evidence only exists on one side. Missing-
side documents use an explicit missing-document presentation rather than a
blank or crashed viewer.

Synchronized schematic page navigation

The comparison navigator builds the union of both revisions' schematic page
catalogs. Shared instances are matched using stable project and sheet identity,
while each side retains its exact revision-specific path. Entries that exist in
only one revision are labelled Base only or Compare only.

Changing the selected page updates the comparison session itself, which keeps
both panes on the corresponding instance in side-by-side mode. Switching
between Old and New keeps the selected logical page, and the viewer uses the
correct side-specific sheet path. This also fixes repeated filenames and
hierarchical instances that cannot be identified safely by filename alone.

Review state, reporting, and resilience

The comparison workspace includes search and filtering, grouped change queues,
selection re-application when a second pane joins, CSV/report generation,
comparison-scoped discussions, and panel-level error boundaries. Escape clears
selection before it closes the workspace, reducing accidental loss of review
context.

Large comparisons have received targeted performance work: revisions can be
built in separate processes, schematic form scanning and symbol-property
extraction are faster, semantic indexes are cached before repository
extraction, board nets use one shared table, domain assets are staged, and
unchanged domain viewers stay mounted instead of being recreated unnecessarily.

History stays concise

History is deliberately the place to choose revisions, not a second Design
Comparison interface. Release and commit rows show the Git history, exact commit
identity, author/date metadata, base/compare actions, and the files changed by an
expanded commit with Git-derived addition/deletion counts.

Component-level changes are not listed in the History feed. Once a base and
compare pair is selected, Design Comparison is the place to inspect and navigate
individual components such as R110 or C102. This keeps long histories
scannable while preserving deep engineering detail where it can be shown with
visual and property evidence.

Changed schematic and PCB files can also open the visualizer at the selected
commit. Release actions have been compacted, commit hashes can be copied, and
the commits-per-page control makes large repositories easier to browse.

Library Manager: a governed component catalog

v3 introduces a full Library Manager alongside the project workspace. It is a
revisioned, server-indexed component system rather than a browser over a loose
folder of symbols and footprints.

Catalog and revisions

The catalog tracks component identity, manufacturer and part-number metadata,
classification, package information, CAD readiness, validation state, workflow
state, revision number, author, and timestamps. Search, sorting, filters, and
pagination run on the server so a catalog with tens of thousands of components
does not have to be downloaded into the browser before it becomes useful.

Component revisions are immutable evidence. A component can carry its symbol,
footprint, 3D model, SPICE model, datasheet-related metadata, and preview assets,
with the relationships between catalog data and stored files maintained by the
backend. Symbol, footprint, and 3D previews make CAD readiness inspectable in the
browser.

Lifecycle and approval

The default lifecycle progresses from open work through in-progress and QA
review to done and released. Component Designer and Component QA responsibilities
are separate, and the release path supports a two-person approval model. The
release queue gives reviewers a focused list of components waiting for the final
decision.

Released is meaningful: the Remote Symbol Provider and KiCad database-library
exports expose place-ready, released component revisions rather than every
draft or partially imported row.

The release-review surface brings readiness evidence, the current lifecycle
stage, revision ownership, reviewer identity, evidence failures, structured
decisions, and publication records into one view. It makes an approval decision
auditable without asking a reviewer to reconstruct it from a generic activity
feed.

Import Center and bulk remediation

Library data rarely arrives cleanly. The Import Center discovers components from
library folders and KiCad projects, harvests relevant CAD assets, and turns
ambiguous imports into explicit remediation work. Conflicts are grouped by the
component they will become, resolved findings clear as the data is corrected,
and catalog metadata edits can be undone.

For larger jobs, the Bulk Edit workspace provides a spreadsheet-style,
virtualized grid and CSV-oriented workflow. It is intended for normalization,
classification, package correction, and other changes that are inefficient one
component at a time. Large-grid scrolling and viewport calculations were
hardened during the v3 cycle to avoid blank or jumping content.

The Cynthion import view shows the intended remediation loop: select a project,
review rows that need attention, group repeated references by MPN, link an
existing footprint where possible, and use CSV or bulk actions for the remaining
normalization work. Ready and blocked counts stay visible while the reviewer
works through the grid, so a large intake job has a measurable path to release.

Validation and KiCad integration

Catalog components can run KiCad Library Convention checks and retain validation
evidence. Prism can import symbol and footprint libraries, split larger symbol
libraries into managed assets, generate previews, and build datasource packages
for KiCad clients. The catalog also supports database-library exports and a
scoped remote-symbol service, closing the loop between governed browser workflows
and actual part placement in KiCad.

Comments and collaborative review

Comments now carry more review intent. Threads can include a class, severity,
mentions, replies, and resolution state. In visualizer modes, comment markers
can be placed in ECAD context and reopened from the design.

Comparison discussions are distinct from ordinary project comments: they are
pinned to the immutable base/compare pair and, where applicable, the selected
change. That prevents a discussion about one revision pair from silently
appearing to describe a later design.

The comments dialog keeps All, Open, and Resolved filters beside the schematic
context, so a reviewer can check the discussion state without leaving the
design. Prism is intentionally a browser review and design-governance layer:
KiCad files remain authored in KiCad and committed through Git, while Prism
presents their evidence, comparison context, and review history. An in-browser
schematic or PCB authoring surface is not part of the product plan.

Faster navigation and safer everyday actions

The global command palette makes the larger v3 surface area manageable. Press
Cmd+K on macOS or Ctrl+K elsewhere to find projects, catalog components,
Library Manager sections, workspace actions, and help without hunting through
the navigation.

Other quality-of-life improvements include:

• A keyboard-shortcuts reference and shortcuts for common viewer actions.
• Searchable projects and catalog components from one palette.
• App-native confirmations and feedback instead of browser-native dialogs.
• Hold-to-confirm controls for high-impact destructive actions.
• Permission hints that explain why a control is unavailable.
• A role-authority popover that makes the current access level easier to
  understand.
• Theme-token cleanup for more consistent dark and light presentation.
• Resizable panels, better overflow containment, and virtualized large lists.
• Error boundaries that contain a render failure to the affected panel where
  possible instead of taking down the whole workspace.
• Clearer empty, loading, missing-document, and failure states throughout the
  visualizer and comparison flow.

PostgreSQL-native architecture and durable background work

v3 moves Prism's server-side state to PostgreSQL and separates synchronous API
work from expensive background processing. The standard Compose deployment now
runs five primary services:

1. The frontend web application.
2. The backend API.
3. A general Prism worker for project and visualizer jobs.
4. A catalog worker for library-specific work.
5. PostgreSQL for workspace, comments, catalog, operations, authentication, and
   job state.

Jobs use leases and fencing so a stale worker cannot overwrite a newer result
after losing ownership. Capacity limits, recovery from dropped database
connections, artifact ownership, and worker health are explicit parts of the
design. First-run state, queued project jobs, catalog work, and generated assets
are now treated as operational data rather than process-local convenience.

Workspace and catalog schemas have independent migration ledgers. Within the v3
PostgreSQL line, startup migrations are additive and protected by advisory locks;
derived indexes and projections can be rebuilt from authoritative state.

Authentication and access control

OIDC login now uses Authorization Code with PKCE, state and nonce validation,
and audience checks. Sessions are stored server-side in PostgreSQL, can be
listed and revoked, and no longer depend on an unrevokable process-local view of
the user. Unsafe or incomplete production authentication configuration fails
closed and is reported as one operator-readable error.

Prism's role model covers workspace administration, project access, component
design, component QA, and service access. OAuth/service-client support is scoped
for KiCad-facing provider workflows. Proxy-aware origin handling, secure-cookie
configuration, and same-origin viewer framing have also been tightened.

This remains a single-workspace alpha with one effective role per user rather
than composable permissions. Operators should read the authentication and access
documentation before exposing Prism beyond a trusted evaluation environment.

Deployment, releases, backups, and recovery

The release path is now reproducible and quality-gated. A semantic-version tag
on a successfully tested main commit builds AMD64 backend and frontend images,
smoke-tests them together, and publishes a digest-pinned deployment bundle.
Prerelease tags such as v3.0.0-alpha publish only their exact version; they do
not move stable latest, major, or minor tags.

The guided deployment installer covers several practical network shapes:

• Plain HTTP for a trusted local evaluation network.
• An existing external reverse proxy.
• ACME HTTP-01.
• ACME DNS-01.
• An internal certificate authority.
• Tailscale, including hosts that are already members of a tailnet.

Preflight checks validate Docker and Compose, port use, DNS and certificate
assumptions, and the network path the selected deployment will actually use.
The deployment documentation includes source builds, stable release bundles,
health checks, backup/restore, rollback, and failure evidence collection.

prism_backup.py captures PostgreSQL plus the authoritative project, component,
SSH, and environment files as a coherent archive, records schema versions and
checksums, and verifies a backup before it is trusted for restore. Failed restore
handling is designed to leave the previous deployment recoverable.

Note

The published release images and bundle are currently AMD64/x86-64 only.
ARM64 is not part of the supported v3.0.0-alpha release contract.

Performance and reliability work that is easy to miss

Many important v3 changes are not visible in a screenshot:

• Base and compare revisions can be parsed in separate processes.
• Semantic indexes are checked before repeating repository extraction.
• Schematic form scanning and symbol-property lookup are substantially cheaper.
• PCB nets resolve against a shared table instead of repeated structures.
• Heavy visualizer assets are staged by domain and loaded when needed.
• Comparison viewers remain mounted when switching BOM or stackup tabs.
• Old/New presentation is a visibility change rather than a full reload.
• Camera synchronization waits for both sides to be ready rather than relying
  on a timing guess.
• Large catalog and remediation grids use virtualized viewports.
• Database pools detect and recover from dead network connections.
• Job ownership uses leases, fencing, and capacity controls.
• Viewer and comparison failures have explicit fallbacks and panel-level error
  containment.

Together these changes reduce repeated work, make large projects more usable,
and turn failures that previously looked like a frozen panel into diagnosable
states.

Breaking change from v2.0.0-alpha

v2.0.0-alpha stored its catalog, workspace, comment, and related application
state in SQLite files. v3.0.0-alpha is PostgreSQL-native and does not include an
automatic v2 SQLite-to-v3 PostgreSQL migration.

Because both releases are alpha, backwards-compatible migration is not part of
this release contract. Treat v3.0.0-alpha as a fresh deployment:

1. Preserve the complete v2 data directory before changing anything.
2. Export or otherwise record any v2 data you may need later.
3. Deploy v3 separately or from a clean v3 data location.
4. Re-import Git projects and component-library sources into v3.
5. Keep the archived v2 installation available until you have validated the v3
   result.

The v3 prism_backup.py workflow protects an existing PostgreSQL-based v3
installation; it is not a conversion tool for a v2 SQLite deployment.

Current alpha boundaries

v3.0.0-alpha is intentionally broad, but it is not a finished enterprise PLM or
EDA collaboration product. Important current boundaries include:

• One Prism workspace and one effective role per user.
• Fixed component and review workflows rather than a configurable workflow
  engine.
• Prism does not edit KiCad source files in the browser. Schematic and PCB
  authoring remains in KiCad, with Git as the source of truth.
• No automatic GitHub/GitLab pull-request checks, status updates, or webhook-
  driven review synchronization yet.
• Mentions are stored as review context but do not yet form a complete
  notification system.
• Project-level approved/changes-requested state is not yet a complete gated
  release mechanism.
• Release images are AMD64 only.
• Alpha data and API contracts may change again before stable v3.

These are product boundaries, not hidden promises. The goal of this alpha is to
put the new architecture and workflows in the hands of real reviewers and
library teams early enough that their feedback can still shape the stable
release.

Validation performed for this release candidate

The reviewed dev tip for this post is a7adf3bf5256beccb1193973872f3ecffb0c1424.
At review time:

• The GitHub dev quality gate passed on that exact commit.
• All 334 frontend unit/component tests passed.
• Frontend lint completed with no errors.
• The production frontend TypeScript/Vite build completed successfully.
• The semantic glTF conversion suite passed.
• The ECAD viewer suite passed.
• Both reviewed viewer bundles built successfully.
• The release-bundle, guided-deployment, and backup suites passed (102 tests
  in total).
• The application was exercised in the local Docker deployment used to capture
  the screenshots in this post, including workspace, catalog, schematic
  navigation, and a real two-revision schematic comparison.

This evidence is appropriate for an alpha release candidate, but it is not a
substitute for backups or evaluation with your own repository layouts, KiCad
versions, authentication provider, and network environment.

Getting started

For a source checkout, follow Getting Started. For a
tagged deployment, follow Deployment and the release bundle
instructions in Releases. Operators should also read
Authentication and Access,
Operations, and Upgrades and Backups.

If you are evaluating v3, the most valuable feedback is concrete workflow
evidence. The areas below are especially useful:

• Project discovery and Git: repositories with nested projects, multiple
  checkouts, unusual branch layouts, submodules, large histories, private SSH
  hosts, or generated files that Prism classifies incorrectly. Please include
  the branch and commit that reproduce the problem, plus whether the failure
  happened during import, sync, branch viewing, or thumbnail generation.
• Schematic navigation: deep hierarchy, repeated sheet instances, unusual
  filenames, missing parent sheets, pages that exist on only one side of a
  comparison, or page lists that become difficult to search. Note whether the
  issue appears in the standalone visualizer, Composite, Side by side, or Old /
  New presentation.
• Comparison evidence: changes that are grouped under the wrong component,
  page, net, constraint, BOM row, stackup layer, or fabrication artifact;
  selections that do not survive a presentation switch; camera synchronization
  that drifts; or a missing-side document that is not explained clearly.
• Visualizer fidelity: symbols, footprints, pads, vias, tracks, zones,
  board layers, 3D models, DNP parts, stackup materials, assembly positions,
  or BOM fields that look wrong compared with KiCad. A reference design,
  screenshot, and the relevant source commit are more useful than a general
  report that “the viewer is off.”
• Comments and review: comment markers that land on the wrong sheet or
  object, confusing severity or class choices, mention suggestions, reply and
  resolve behaviour, filters that lose context, or comparison discussions that
  appear under the wrong base/compare pair. Please say whether the problem is
  visual placement, persistence, permissions, or notification expectations.
• Component intake and remediation: missing metadata, footprint links that
  cannot be reused, false conflicts, incorrect MPN grouping, CSV round-trips,
  undo/redo surprises, previews that do not generate, or rows that remain
  blocked after a correction. Include whether the source was a KiCad library
  folder or a project BOM and which fields should be authoritative.
• Lifecycle and approval: states that feel ambiguous, evidence that is hard
  to audit, two-person approval hand-offs that are unclear, release-queue
  ordering, publication records that do not explain what was released, or a
  mismatch between catalog status and KiCad-facing exports. Feedback on which
  evidence a reviewer needs before approving a component is particularly
  valuable.
• Search, layout, and input: slow filters, pagination gaps, virtualized rows
  that jump or go blank, keyboard focus traps, touchpad scrolling, browser zoom,
  narrow windows, high-DPI displays, or panels that obscure the primary evidence.
  Please mention browser, operating system, display scale, and whether a mouse
  wheel, trackpad, or keyboard produced the problem.
• Performance and recovery: import or comparison jobs that stall, worker
  retries that repeat work, stale progress, memory growth, database reconnects,
  backup/restore surprises, or a panel that remains stuck after a failed job.
  Timings, approximate project size, worker logs, and whether a retry changed
  the outcome help us separate data-shape problems from infrastructure limits.
• Deployment and access: OIDC providers, reverse proxies, TLS termination,
  Tailscale, Docker/Compose versions, ARM or AMD64 hosts, SSH trust prompts,
  cookie or origin issues, and permission explanations that do not match the
  role you expected. Redacted configuration and the exact deployment mode are
  enough; never include secrets or private keys.
• Accessibility and team workflow: keyboard-only navigation, screen-reader
  labels, focus order, contrast, reduced-motion preferences, role boundaries,
  review hand-offs, or places where a new team member cannot tell what is safe
  to do next. These reports are welcome even when the workflow technically
  completes.

For any report, include the shortest reproducible sequence, the project or
revision involved (redacted if necessary), the browser and OS, and a screenshot
or copied error text when available. If the issue is intermittent, record how
often it occurs and whether a refresh, retry, or fresh comparison session
changes the result. This level of detail lets the alpha feedback improve the
actual review and governance workflows rather than only the demo path.

Thank you

v3.0.0-alpha is a foundation for a different kind of KiCad workflow: Git remains
the authoritative source, while Prism supplies the browser-native visibility,
review context, component governance, and operational history that a hardware
team needs around it.

Thank you to everyone testing the alpha, reporting real project failures, and
pushing the review experience beyond “show me which files changed.” That feedback
is directly reflected in the new Design Comparison model, the concise History
view, the instance-aware schematic navigator, and the many reliability fixes in
this release.

Full source comparison:

v2.0.0-alpha...v3.0.0-alpha

---

This discussion was created from the release KiCAD Prism v3.0.0-alpha.

[DavidMeYourGuru]

Hey, I just wanted to say amazing work. I'm really blown away by the scope and quality.
I just stumbled upon this project today because I was looking for solutions to compare kicad layouts and schematics.
I was thinking about coding something myself But honestly, you have every feature that I thought about, and it really looks amazing.
This repo deserves a lot of more stars. I will spread the word about it.

Edit:
One feature that would be nice would be a measurement tool in the layout viewer. One where you can select where it will snap to like to edges , to centers, etc or nothing of course

[krishna-swaroop]

Thank you for the kind words!
This did start off as an attempt to close the gap with other commercial ECAD tools as we transitioned to KiCad at my workplace.

I agree about the measurement tool. It is something that is in the pipeline. I want to finish the Prism Release Studio before I get to that!