Mvp.Cli 2.1.0-preview.1

mvp

mvp is an open-source .NET command-line tool for scaffolding full-stack minimum viable products. It generates an opinionated, buildable starting point with a layered .NET backend, an Angular workspace, JWT authentication, and Playwright end-to-end test assets.

Get started | CLI reference | Documentation site | Documentation | Contributing | Support

Packages

Use the library directly when you want to drive generation from your own code; see its readme.

Why mvp?

Starting a product should mean working on its domain, not repeatedly assembling authentication, project boundaries, frontend libraries, and test infrastructure. mvp turns a small YAML manifest into a consistent application baseline that a team can own and extend.

The primary generator provides:

• A .NET 10 backend organized into Domain, Application, Infrastructure, and API projects.
• Registration and sign-in flows using JWT bearer authentication.
• An Angular 22 workspace with application, API, component, and domain boundaries.
• Entity, page, and reusable-component scaffolding driven by YAML.
• Playwright page objects and an authentication journey.
• In-memory persistence for local evaluation, with SQL Server support available through configuration.
• Focused commands for generating individual solution parts.

Get started

Prerequisites

To build and run the CLI, install the .NET 10 SDK. The repository's global.json selects the supported SDK feature band.

Node.js 24.15 or newer and npm are required only when you want to install or run a generated Angular 22 application. Playwright browser binaries are required only for generated end-to-end tests.

Run from source

git clone https://github.com/QuinntyneBrown/mvp.git
cd mvp
dotnet restore
dotnet build Mvp.sln --configuration Release
dotnet run --project src/Mvp.Cli -- --help

Generate the included sample:

dotnet run --project src/Mvp.Cli -- \
  new dotnet-angular-jwt-mvp \
  --config samples/sample-mvp.yaml \
  --output ./out

In PowerShell, the same command can be entered on one line:

dotnet run --project src/Mvp.Cli -- new dotnet-angular-jwt-mvp --config samples/sample-mvp.yaml --output ./out

The generated solution is written to ./out/Acme because the sample manifest names the solution Acme.

Install as a global tool

dotnet tool install --global Mvp.Cli
mvp --help

Every commit to main publishes a prerelease build, so the newest code is one flag away:

dotnet tool install --global Mvp.Cli --prerelease

Prereleases are versioned X.Y.Z-preview.N. They pass the same cross-platform test matrix and packaged-consumer smoke test as a stable release, but they are not release-reviewed and their behaviour can change between builds. Use a stable version unless you need something that has not shipped yet.

Update or remove an installed tool with dotnet tool update --global Mvp.Cli and dotnet tool uninstall --global Mvp.Cli.

Install from source

To run a local change as a tool, package and install it from a local source:

dotnet pack src/Mvp.Cli --configuration Release --output ./nupkgs
dotnet tool install --global --add-source ./nupkgs Mvp.Cli

To reinstall a locally packaged version, uninstall the existing tool first or use dotnet tool update with the same package source.

Create an authenticated full-stack MVP

For a minimal solution, provide a name and output directory:

mvp new dotnet-angular-jwt-mvp --name Contoso --output ./out

For a domain-aware solution, describe it in YAML:

name: Contoso

entities:
  - name: Project
    properties:
      - name: Title
        type: string
      - name: BudgetCents
        type: long

pages:
  - name: Projects
    route: projects
    requiresAuth: true

components:
  - name: ProjectCard
    library: domain

Then generate it:

mvp new dotnet-angular-jwt-mvp --config mvp.yaml --output ./out

--name overrides the name in the manifest when both are supplied. See the manifest reference and complete sample for supported fields and types.

After generation

Treat the generated tree as application source code, not a production-ready deployment:

1. Replace the placeholder Jwt:SigningKey in the generated API configuration with a secret of at least 32 random characters. Store real secrets outside source control.
2. Build the generated backend from its backend directory with dotnet build.
3. From frontend, run npm install and npm start to serve the Angular application.
4. If you need end-to-end tests, run npx playwright install once and then run npm run e2e.
5. Configure durable persistence, allowed origins, observability, deployment, and environment-specific security controls before any non-evaluation use.

The default in-memory store is intentionally disposable; data does not survive a process restart.

CLI reference

Run mvp new <command> --help for the authoritative options for a command.

All generation commands accept --force (-f) for explicit, transactional replacement. Component commands accept --name (-n) and --output (-o); the authenticated full-stack command also accepts --config (-c). --diagnostic is global and is the only mode that displays internal exception details.

Exit codes are stable: 0 success, 1 invalid syntax/manifest/input, 2 output conflict, 3 generator or external-tool failure, 70 unexpected internal failure, and 130 cancellation.

Generation validates the complete input before creating directories. New trees are rendered in a sibling staging directory and published only when complete. Existing targets are untouched unless --force is present; forced replacement uses a sibling backup and restores it if publication fails.

Repository layout

src/Mvp.Core/       Generation engine: manifests, feature slices, infrastructure, packaged templates
src/Mvp.Cli/        Command-line front end: bootstrap, commands, exit codes
tests/Mvp.Cli.Tests Unit, command integration, golden-tree, and cancellation tests
samples/            Example manifests
skills/             Reusable guidance and generation references
docs/specs/         Baselined L1 and L2 product requirements
docs/detailed-designs/
                    Feature and subsystem design documentation

Documentation

The documentation site — https://happy-mud-0689bad0f.7.azurestaticapps.net — explains every command, the manifest contract, the generated file inventory, and the tool's limitations for a general audience. Its source lives in website/ and deploys on every change to main. Start with the documentation index for the engineering material. Key resources include:

• High-level requirements
• Detailed requirements and delivery status
• Requirement-to-test traceability
• Detailed designs
• Manifest schema
• Generated solution inventory
• Maintainability audit

Project status

Capabilities are tracked as implemented, partial, or planned in the L2 requirements; partial and planned requirements remain outside the v2 delivery baseline. The released baseline is recorded in CHANGELOG.md, and the release procedure in RELEASE.md.

Contributing

Contributions to code, tests, documentation, templates, and design are welcome. Read CONTRIBUTING.md before opening a pull request. Participation in this project is governed by the Code of Conduct.

For usage questions and non-sensitive problems, see SUPPORT.md. Do not disclose a vulnerability in a public issue; follow SECURITY.md instead.

Governance

Maintainer responsibilities, project decision-making, and the path to maintainership are described in GOVERNANCE.md. Contributors are recognized in CONTRIBUTORS.md, and notable changes are recorded in CHANGELOG.md.

License

Copyright (c) 2026 Quinntyne Brown and contributors. Released under the MIT License. Third-party components and template provenance are documented in THIRD-PARTY-NOTICES.md.