Handbook

Wizard — operator trust boundaries

A concise map of who may observe or mutate Wizard session data versus your git working tree, LLM vendors, and Forge Fleet. Implementation touch points live under lenses/blueprints_wizard/ in the forge-lenses repository.

Updated

What it is

A concise map of who may observe or mutate Wizard session data versus your git working tree, LLM vendors, and Forge Fleet. Implementation touch points live under lenses/blueprints_wizard/ in the forge-lenses repository.

Boundaries (expanded)

Surface Ships today Operator responsibility
Browser (Studio) Renders steps; holds transient UI state Hard-refresh can drop unsaved UI — rely on server persistence for the session envelope
Lenses HTTP API GET/POST families under /api/blueprints/wizard/* (builder API) Restrict network path to trusted clients on your LAN/VPN
.lenses-local/ Session JSON, telemetry, optional export scratch Classify as sensitive working data — backup/retention per Security and local-first
Product repos Wizard does not auto-commit Blueprints submodule or product branches Review diffs yourself; exports are suggestions
LLM Optional Refine / Interpret / similar POST routes Redact regulated content; route via approved gateways
Forge Fleet Optional async jobs when wired Bearer tokens are production secrets

Sequence view

Same story as the overview diagram — trust flows across Studio, Lenses, and optional outbound services:

Sequence view

  Actor / trigger
      |
      v
  System step
      |
      v
  Outcome / handoff
Session envelope persists server-side; outbound calls are explicit POSTs

Verify

Your runbook names where session files live on disk (.lenses-local/…) and states that no Wizard route implies an automatic git push.

What to do next