Build the first application journey

Begin with one useful business journey#

Start a Matrix Consumer from an observable outcome: who needs to do what, against which service or records, and what proves success. Record domain, security and operations owners before selecting modules. The first slice should exercise an actual authorized read or write, not expose every table in an existing database.

A Product definition connects each requirement to its module or custom implementation, execution boundary, tests and evidence. It also records exclusions, package versions, secret references, environment owners and remaining release gates. Keep credentials and customer data outside this document.

Select a coherent development baseline#

Obtain the approved runtime package version, matching kit and source revision, package feed access, and supported development toolchain. A newer source example is not proof that its API exists in the selected package. Ordinary development keeps the chosen pin; upgrading is a deliberate operation with its own acceptance.

The inspected template guide records stable template 1.3.0 targeting runtime 0.1.0-alpha.47. Template stability does not declare the separately versioned alpha runtime stable. Newer Workflow-enabled templates and connectors have separate candidate records. Treat these as a documented snapshot, not a recommendation to ignore subsequent verified releases.

The documented Windows path uses Visual Studio 2026 with the required ASP.NET/Aspire tooling, a compatible .NET 10 SDK, PowerShell 7, Aspire CLI and Docker Linux containers. Use the exact requirements supplied with the approved distribution. Existing applications should retain their solution and adopt individual changes rather than regenerate it.

Generate and verify the Consumer#

The public template flow uses an approved local package or authenticated feed. This example uses the local-package form; replace the package placeholder with the reviewed distribution path.

dotnet new install <absolute-path-to-SK.Matrix.Consumer.Templates.nupkg>
dotnet new matrix-consumer -n Acme.Workspace -o ./Acme.Workspace
cd ./Acme.Workspace

Generation creates Api, Web, AppHost, ServiceDefaults and Contracts. It does not restore, publish or deploy automatically. Configure the generated NuGet source and source mappings for the approved runtime packages, then follow the generated README:

./eng/Verify.ps1
dotnet run --project AppHost/Acme.Workspace.AppHost.csproj -c Release --no-build --launch-profile https

With that disposable AppHost running, use another terminal for the authenticated verification:

./eng/Verify.ps1 -Authenticated

Open Web from the Aspire dashboard and use the development identity procedure delivered with the fixture. Local identity and synthetic data are development inputs. They are excluded from the intended production identity model.

Replace the demonstration with application behavior#

Choose the appropriate starting path:

Keep business validation and transactions in the authoritative application service. Generated EF CRUD must not bypass that service when the domain requires it. Add modules as real journeys require them.

Complete acceptance before deployment#

Verify allowed and denied direct requests, invalid input, dirty drafts, relevant concurrency and uncertain-outcome recovery, plus the actual authenticated browser journey. A successful build is not evidence of login, permissions or production readiness.

Record exact packages, kit, commands, environment and results in the Product definition. Deployment additionally requires reviewed identity, TLS/proxy settings, secrets, migrations, persistent state, telemetry and rollback. Local publication does not complete that work.

For independent adoption, track setup effort, configuration, verification, rework and maintainer assistance. One representative follow-up change tests whether the platform helps maintain the application as well as create it. Continue with security and audit boundaries and verification guidance.