Five-minute demo

This walkthrough demonstrates the behavior Fullstack Expert is designed to make visible: inspect first, preserve unknowns, plan a vertical slice, protect sensitive operations, and require fresh evidence before claiming completion.

The commands below use the repository's deterministic test fixtures, so the flow can be rehearsed without a live database, credentials, or external writes.

1. Validate the plugin itself

From the plugin checkout:

npm install
npm run verify

Expected result: lint passes and all tests pass. The exact test count may change as the project evolves; use the command output as the evidence.

2. Use a Supabase-shaped project as the inspection target

The fixture at fixtures/supabase-saas contains local Supabase evidence and a migration, but no credentials or linked project. This is deliberate: detection is safe, while linking and mutation are not implied.

In a running Harness profile with Fullstack Expert enabled, ask:

Inspect fixtures/supabase-saas and plan the smallest safe vertical slice for adding project labels. Include Supabase evidence, identify what is unknown, and do not log in, link, push, reset, pull, or deploy anything.

The agent should call fullstack_plan with includeSupabase: true. The result should contain a project model, tasks, assumptions, unresolved items, and advisory Supabase evidence.

3. Make the safety boundary explicit

Follow with:

What would need explicit approval before it could change a remote Supabase project? Do not execute any mutation.

The answer should distinguish local read-only inspection from sensitive operations such as login, linking, migration push, reset, pull, or deployment. Fullstack Expert does not claim that a local migration has been applied merely because the file exists.

4. Record and inspect evidence

Ask the agent to run the relevant native project checks, then:

Use fullstack_check for the checks you actually ran. Record pass, fail, or unknown evidence with the exact command and exit code. Do not self-attest verification.

fullstack_check can perform bounded read-only project inspection and record non-verification facts supplied after native Harness tools run. A verification result cannot be supplied by model assertion; it must come from a native Harness check.

What to show in a recording

A short screen recording should show:

1. The repository request.
2. fullstack_plan inspecting actual files.
3. Explicit assumptions and unknowns.
4. The Supabase evidence boundary.
5. A native test command and its exit code.
6. fullstack_check recording the result.
7. The final state refusing completion when verification is missing or failed.

Honest comparison

The plugin does not make the underlying model omniscient and does not add a second shell or browser. Its value is that it gives the model a stateful engineering discipline and makes unsupported success claims harder: inspection, safety classification, and verification evidence become visible seams rather than informal promises.