ui-automation-control-plane

Get Started

Prooflane makes the most sense when you start from the WebUI you want to test, not from the installation checklist.

This page separates three different wins:

No Local Setup Yet?

If you want to understand the product before you install anything, start with the public-safe guided demo.

That demo is read-only and safe to share. Think of it like a museum walkthrough: it shows the main rooms, the public-safe sample, and the AI/MCP layers without opening the private runtime storeroom.

30-Second First Look

If your dependencies are already installed, this is the fastest visible path:

./scripts/dev-up.sh

This confirms the stress-lab surface boots locally. It does not yet prove a governed run.

What success looks like:

Prooflane studio preview showing the launch-first operator path: Stress Lab first, then Runs and Blocks, then Flow Studio, with Advanced Review as the deeper governed layer behind the first visible result.

This preview card is the current front-door orientation visual for the launch-first IA. It is useful for understanding the product map before you boot the stack, but the running app and the latest audit artifacts still remain the source of truth for current behavior and live GitHub state.

If this is your first run in a fresh checkout, bootstrap once first:

./scripts/setup.sh && ./scripts/dev-up.sh

Local first look and governed experiment proof are different checkpoints. Think of it like opening the lab door versus finishing a supervised test session: both matter, but they prove different things.

Pick Your First Win

Goal Best path Outcome
Understand the product without booting it Guided demo Walk through the target -> experiment -> result -> advanced-review path with public-safe assets only
See the stress lab in action Local stack path Open the Command Center and API locally
Produce a localhost-first governed experiment Orchestrator path Generate a run manifest, summary, and proof indexes for a localhost WebUI with a valid GEMINI_API_KEY
Connect from an MCP client MCP path Expose the same runtime to an agent or operator client

Prooflane result path diagram showing the local first-look path, the governed run path, and the MCP connection route.

Current Route B Boundary

The front door is now stress-lab-first, but the honest MVP is still localhost-first:

Run Lane Map

Prooflane uses several run surfaces on purpose.

Surface Think of it as What it writes
./scripts/dev-up.sh Turn on the dashboard Local UI/API runtime state only
POST /api/runs Start a saved workflow from the product Workflow ledger records under .runtime-cache/automation/universal/
POST /api/automation/run Queue a named command AutomationTask execution records
pnpm uiq run --profile ... --target ... --base-url ... Produce a governed experiment result Run bundle under .runtime-cache/artifacts/runs/<runId>/
pnpm mcp:start Expose the above through MCP Reuses API + governed bundle contracts

/api/runs, /api/automation/run, and pnpm uiq run are related, but they are not the same lane. If you care about release-grade proof, use the governed pnpm uiq run path.

How The Product Surfaces Fit Together

If you open the local app and feel like there are several “run” pages, use this simple map:

That means the fastest first look is not the same as the release-review path. You can start in the app, but you still need governed proof when you want repeatable release evidence.

Path 1: Launch The Stress Lab Locally

Use this path when you want to experience Prooflane as a stress lab, not just as a set of scripts.

This path is the honest “I can see the lab working locally” checkpoint. It does not consume a Gemini key and it does not write the governed run bundle.

Step 1. Set up the workspace

./scripts/setup.sh

Step 2. Start the local stack

./scripts/dev-up.sh

Step 3. Open the operator surfaces

Stop the stack

./scripts/dev-down.sh

Path 2: Produce A Localhost-First Governed Experiment

Use this path when you care about proof, repeatability, and gate-aligned run artifacts for a real local WebUI.

This path is stricter than the local UI path because it is the one that writes the governed run bundle.

GEMINI_API_KEY=<your-key> pnpm uiq run --profile deep-localhost --target web.any-localhost --base-url http://127.0.0.1:3000

Replace http://127.0.0.1:3000 with the local WebUI you actually want to test.

What this gives you:

Current note from local verification: governed profiles enforce a strict Gemini preflight. If GEMINI_API_KEY is missing, the run stops with reasonCode=ai.gemini.strict_policy_violation.

If you want to inspect a public-safe example before wiring a key, use the single sample linked from docs/proof-center.md or the public-safe guided demo.

If you want the deeper contract, read docs/architecture.md.

Path 3: Connect Through MCP

Use this path when you want Prooflane to show up as a controlled tool surface inside an MCP-capable client such as Codex, Claude Code, or another MCP host.

The truthful install path today is the repo-native command:

pnpm mcp:start

Package truth for this path:

By default the MCP server targets its managed backend lane at http://127.0.0.1:18080. If you want MCP to attach to the local ./scripts/dev-up.sh stack instead, export:

UIQ_MCP_API_BASE_URL=http://127.0.0.1:17380

If you want optional tool groups as well, add:

UIQ_MCP_TOOL_GROUPS=advanced,analysis,proof

Then continue with:

Remember that MCP is a connection layer over the same governed runtime. It is not a second truth surface that replaces workflow runs or governed proof.

This site is open source. Improve this page.