witnora

External Pilot Protocol

This protocol is for an agent team evaluating Witnora from its own repository. It is designed to expose onboarding friction, not to manufacture a passing result. Use staging or deterministic fixtures only. Do not provide Witnora with production credentials or access to real payments, email, or customer data.

Ten-Minute Target

The first useful checkpoint is one locally validated evidence bundle visible in the hosted control plane.

1. Sign in at the Witnora workspace.
2. Create a project. Witnora opens the Setup Wizard and pre-fills a metadata-only plan.

3. Review the plan, then open a terminal in the Agent repository and run the displayed command.

   npx witnora@latest onboard --project <project-id>
   

4. Select Approve setup in the browser. The CLI stores a restricted credential, detects the repository, writes missing-only Gateway, probe, CI, policy, and review contracts, starts and health-checks the customer-owned Gateway in the background, and runs an isolated synthetic self-test. Failed attempts stop and remove only resources created by that attempt. No API key copy and paste or separate Gateway command is required.

5. Produce a real Witnora evidence bundle from an existing Tripwire, MCPBench, or runtime artifact, then upload it.

   npx witnora@latest run --tripwire .tripwire/latest/tripwire-result.json --push
   # or
   npx witnora@latest push --evidence .witnora/latest/agentcert-evidence.json
   

6. Confirm that the four assurance dashboards show the same run, runtime action, evidence digest, and review state. New capabilities remain pending and denied until confirmed.
7. Confirm that Runs and Evidence show the same run, verdict, schema version, and SHA-256 provenance as the local output.

CI runners should use WITNORA_BASE_URL, WITNORA_PROJECT_ID, and the secret WITNORA_API_KEY instead of persisting a user profile.

Pilot Paths

Generate the boundary-specific starter from an empty repository:

npx witnora@latest init --template <browser|coding|mcp|workflow|data> --subject <agent-name>

• Browser or computer-use agent: start with examples/minimal-browser-agent and replace the fixture command with the real agent command.
• Real browser agents: compare the browser-use and Stagehand adapters.
• MCP server or tool: run MCPBench and pass its results.json through witnora run --mcpbench <path>.
• Runtime action: use the Onegent local adapter and mock systems. Do not connect a live payment, email, or vendor system during the pilot.

Acceptance Evidence

Record facts rather than impressions:

• minutes from empty checkout to first local report;
• minutes from API key creation to first hosted evidence;
• commands that required undocumented repository knowledge;
• first failing step and its exact error category;
• whether the report identifies the first behavioral divergence;
• whether a reviewer can connect the verdict to screenshots, traces, and source artifacts;
• whether a retry creates duplicate evidence;
• whether revoking the project key blocks the next request.

Success means the integration is reproducible and the evidence is explainable. It does not require the agent to pass every test.

Report Friction

Use Report onboarding friction on the Hosted Overview page so the stage, category, outcome, and bounded diagnostic context stay attached to the project. Public pilots may also use the repository’s External pilot report issue form. Never paste API keys, database URLs, access tokens, customer data, or unredacted production traces. Include links to public or sanitized CI artifacts when possible.

This site is open source. Improve this page.