# 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: ```sh 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`](../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: ```text 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: ```text 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: ```text 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.