Learning-path smoke matrix

This matrix is a test plan, not eight passing badges. Use the linked page for commands and prerequisites. Record the source commit, CLI version, exact package or Plugin version, target, command result, and browser result for each run. A local source candidate cannot become a released tutorial by passing a Site link check.

P1. First runnable App

Smoke: Run app dev; submit Ada in a real browser and see Hello, Ada! from POST /greetings.

Boundary: Use a source-built CLI and matching dependency cohort. Stop if a pinned dependency is unavailable.

P2. Same task for an agent and a human

Smoke: Give the page's agent request the same CLI revision, template, and browser assertion as P1. Compare actual output and errors.

Boundary: This is not a second template or another Agent product. Independent agent completion still needs a recorded run.

P3. Adopt a Plugin

Smoke: Find an exact signed version in the directory, check distribution, target, trust, and permissions, then adopt, configure, build, and invoke it.

Boundary: A candidate page is not installable. A signed listing alone does not prove a compatible .crate, complete permission evidence, or a successful App build.

P4. Write a Plugin

Smoke: Implement behavior, make a real plugin dev call, run plugin check and plugin pack, then add the artifact to a compatible App and call it there.

Boundary: Packaging is local preparation, not catalog publication. App adoption requires a matching Host and target.

P5. Web and React

Smoke: Generate and typecheck the client, create and read a note in the browser, then inspect a denied cross-user request and an API error.

Boundary: This candidate needs an exact client tarball, Auth/Jobs/Secrets inputs, credentials, and disposable PostgreSQL.

P6. Configuration and dynamic sources

Smoke: In a local App, change one typed Instance patch, reject an invalid value, and inspect the result with app show and app check. Keep secret values outside the Plugin Root. For a concrete revision-fenced remote source, follow the single-resource Agent configuration service: publish a reviewed proposal, reject a stale revision, then verify that a service outage fails closed.

Boundary: The Agent service is one named resource, not a general App configuration provider or deployed multi-environment control plane. The source-built default App has local, versioned file-snapshot activation tests; this Site path does not establish a published provider.

P7. Build and run a distribution

Smoke: Use the Exact package inputs for external providers section of lenso-examples/fixtures/vnext-knowledge-base-app/README.md from a matching candidate checkout. In a network-disabled, resource-limited container, run verify.py --package-only with one signed --linked-snapshot, independent --trust, exact --auth-crate, --jobs-crate, and --secrets-crate inputs, and --trust-linked-build-from-crates. The verifier adopts those archives, builds the Host, runs app check and app show, deletes the disposable App source, and repeats real HTTP and PostgreSQL checks after a controlled restart.

Boundary: Package-only describes the three external providers, not the App's own Rust and TypeScript source. Supply a matching source-built CLI and offline dependency closure. The local candidate test does not prove these packages or the CLI are published on crates.io, nor that the final candidate SHA has passed the same run. The simpler app start --from in the Web App quickstart does not replace this check.

P8. Upgrade, disable, and uninstall

Smoke: In a source App with a selected Plugin, add its default.disabled marker and run app build, app check, and app show on a new distribution. Remove the marker to enable it again. For an exactly signed linked Cargo or Portable adoption, use the matching app unadopt path, then build and inspect the next distribution. Verify business data separately before switching Hosts.

Boundary: app unadopt applies only to the exact signed source it previously adopted; it does not remove a local Plugin or reverse a migration. An upgrade is a separately reviewed version adoption and application migration, not an automatic or reversible CLI operation. This is a local candidate path, not proof of a published package cohort.

Run the checks in layers

1. pnpm build in the Site checkout generates the public pages. Then pnpm check:learning-paths checks that all eight entries, English/Chinese routes, and linked tutorials are present in the published output. Before a Site build, node scripts/check-learning-paths.mjs --source-only checks source links and path boundaries without claiming a rendered-page pass. Neither check runs an App or issues a browser request.
2. Run the command and browser check in each linked tutorial only after its stated inputs exist. A failed dependency, missing signed release, or missing external service is a named boundary, not a pass.
3. For the separate framework-extension path, use Build a local Engine extension and its temporary-fixture smoke script. It checks a real local CLI but does not qualify a Driver or Adapter.

For P3, retain the exact signed document/version URL used for the adoption decision. For P5, retain the generated client revision and browser network response. For P6, retain non-secret revision and diagnostic evidence. For P7, record how the source checkouts were made unavailable. For P8, keep a data backup and explicitly name any irreversible migration before changing the active Host.