Marketplace: Install into an Existing Project
How to discover, analyze, and apply Feature Packs and Recipe updates to an already-running Alchemist project, including conflict detection, AI-assisted reconciliation, versioning, and compatibility.
If your project already exists and you want to add a Feature Pack or pull in a Recipe update, you use the post-creation install surface rather than recreating the project from scratch. This guide covers how to discover compatible add-ons, run the install analysis, apply changes, and understand how versioning and conflict reconciliation work.
Finding Add-Ons for Your Project
From the project Marketplace tab
Every Alchemist project has a Marketplace tab in the project sidebar. Opening it shows:
- Compatible packs — Feature Packs whose declared dependency graph is compatible with the packs already installed in your project. Incompatible packs are shown grayed out with a tooltip explaining the conflict.
- Available updates — newer versions of packs you already have installed, including whether an update requires an active Maintenance subscription.
- Related listings — packs commonly installed alongside your current stack.
From the standalone Marketplace
You can also browse the full Marketplace and filter by “compatible with my project” using the compatibility filter. The listing detail page shows a compatibility badge when you are viewing it with a project selected in context.
Compatibility checking is based on the pack dependency declarations in the catalog. The analysis step (below) provides a more precise conflict report against your actual project files before anything is written.
Running the Install Analysis
Before any files are written, you always run an analysis first. The analysis:
- Resolves the dependency graph — identifies all transitive packs that need to be installed alongside the one you selected.
- Inventories your project files — compares the pack’s source files against what already exists in your project.
- Identifies conflicts — files the pack wants to write that you have already modified from the original template are flagged as conflicts.
- Produces a change plan — a structured list of new files to add, files to overwrite (unmodified), and files requiring AI reconciliation (modified by you since original install).
- Checks entitlement — verifies you hold a valid license for the pack (or that it is free/granted) before surfacing the apply button.
The analysis is read-only and non-destructive. You can run it as many times as you like.
If the pack requires a Maintenance subscription for updates (e.g. you are pulling a newer version than your license originally covered), the analysis report will show this and the apply button will be disabled until the subscription is active.
Understanding the Change Plan
The change plan produced by the analysis groups file changes into three categories:
| Category | What it means |
|---|---|
| New | File does not exist in your project yet — safe to write directly |
| Overwrite (clean) | File exists but matches the original pack source exactly — safe to overwrite |
| Reconcile (modified) | File exists and you have made changes since installation — requires conflict resolution |
For Reconcile files, the platform dispatches AI-assisted reconciliation: the agent reads your modifications and the incoming pack version, then produces a merged file that preserves your customizations while adopting the pack’s changes. You review the proposed merge before it is applied.
Applying the Changes
After reviewing the change plan:
- Click Apply to start the installation.
- For each “Reconcile” file, the AI reconciler proposes a merged version. You see a diff view: your current file on the left, the proposed merge on the right. Accept, edit, or reject each file individually.
- When all reconciled files are approved, the platform writes all changes atomically and records the installation as provenance on the project.
- Any new database migrations included in the pack are staged for the next deploy.
If AI reconciliation is dispatched for a complex merge, the operation may take 30-60 seconds per conflict file. You can leave and return — the reconciliation runs in the background and you are notified when results are ready.
Versioning and Compatibility
How versions work
Each Marketplace Listing publishes a version number following semantic
versioning conventions (e.g. 1.2.0). Packs declare the range of versions of
their dependencies they are tested against. When you install a pack, the version
you receive is recorded as provenance on your project.
Compatibility declarations
A listing’s detail page shows:
- Current version and release date
- Changelog — a human-readable list of what changed in each version
- Compatible with — the pack versions and runtime requirements this listing has been tested against
- Breaking changes — versions that require reconciliation of existing code are marked as breaking and require explicit confirmation before apply
Forks and divergence
When you accept an AI-proposed merge, the resulting file is a fork: your project’s copy now diverges from the canonical pack source. This is expected and intentional — you own the source, and customization is a first-class use case.
Divergence is tracked per-file. If a future pack update modifies the same file again, the analysis will flag it as a reconciliation target and the AI reconciler will incorporate both your prior divergence and the new upstream changes into the proposed merge.
Staying up to date
If you have an active Maintenance subscription:
- The project Marketplace tab shows a badge when a newer compatible version is available.
- Changelogs are accessible from the listing detail and from the project’s Maintenance panel in project settings.
- You are notified (in-app and by email) when a security or compatibility notice is issued for an installed pack.
Without an active Maintenance subscription, you retain perpetual use of the installed version but do not receive update notifications or access to newer versions. See Maintenance Subscriptions for details on what Maintenance covers and how cancellation works.
Security, Review, and Support Expectations
Security posture of published packs
All packs submitted to the Marketplace go through a review process before being listed:
- Static analysis — automated checks for common vulnerabilities (SQL injection, path traversal, unsafe deserialization, hardcoded secrets).
- Dependency audit — third-party dependencies are checked against known vulnerability databases.
- Human review — Chipp reviews pack manifests, migration scripts, and agent-guidance notes for correctness and safety.
Marketplace review reduces risk but does not guarantee that a pack is free of all vulnerabilities. Treat installed pack source with the same care as any third-party code: read the files, run your own tests, and report issues to the seller and to Chipp’s security contact.
Seller support
Each listing’s detail page shows the seller’s support channel. For issues with a specific pack, contact the seller directly. For platform-level concerns (billing, entitlement, account), use Chipp’s support.
Sellers are not obligated to provide support beyond what is stated in their listing. Active Maintenance subscribers are entitled to the level of support the seller declares in the Maintenance terms on the listing.
Verified publisher badge
Listings from sellers who have completed Chipp’s identity and review process display a Verified Publisher badge. This means Chipp has confirmed the seller’s identity and reviewed at least one of their published listings. It does not constitute a warranty or guarantee.
Reporting security issues
If you discover a security vulnerability in a published pack:
- Contact the seller through the channel on their profile page.
- Also report to Chipp via the security contact in the platform footer.
- Do not publish the vulnerability publicly before the seller has had a reasonable opportunity to issue a patch (coordinated disclosure).
Chipp may delist or quarantine a listing while a reported vulnerability is being addressed.