/poc - Proof Lane

/poc owns bounded proof work between capture/design and proposal. It proves a specific claim, not a whole project. It can produce a disposable artifact, a production-path trace, or a decision matrix, then routes the result back into the Leviathan lifecycle.

Entity Reconciliation

After authorized material progress, reconcile touched and causally affected artifacts before routing, handoff, or final response. Track entity ref, island/provider locator (a path for file storage), basis/evidence, and the reason/action due. Update through the verified owning CLI/adapter; use a write-authorized skill fallback only when that operation is unavailable. Record updated, no_change(reason), or blocked(reason), preserving unresolved refs. Reading or mentioning a path alone creates no update obligation. Read-only work reports pending changes only. Reminders grant no write authority; task status stays with the bound tracker. Update only artifacts whose content or evidence changed; do not rewrite every referenced document.

Work Link

Lifecycle lane: Shape -> Plan Entity movement: hypothesis | captured | idea -> proven | partial | disproven | monitor | proposal_ready Workstream: resolve the active workstream before writing artifacts or dispatching work Upstream: /capture, /interview, /design, workshop intake, /prior-art Downstream: /propose, /capture, /exec, /close, archive Router: /work HUD: end with 🧬 {ws} ⚡{exec_count} 📥{capture_count} ⏸️{paused_count} ✅{done_count} | 🚦poc={verdict}/{score} | ⏭️ {next} | 🔁{loop_state}

Commands

/poc                         # choose the cheapest proof mode
/poc --spike                 # answer a bounded unknown with minimal evidence
/poc --prototype             # build or inspect a disposable working artifact
/poc --production-path       # prove the real integration path, not a mock demo
/poc --matrix                # compare landing zones or implementation routes
/poc --auto                  # run without asking unless a gate blocks proof

Prior Art Guard

Run /prior-art or an equivalent local evidence pass before recommending a matrix, implementation route, or verdict. Workshop intake treats spike and POC as implementation routes, not terminal dispositions. The terminal disposition must be one of adopt, extract, monitor, or reject when the proof is part of workshop intake.

Mode Selection

Use --spike when the unknown is conceptual, architectural, API, feasibility, or fit. Output can be read-only when code is not needed.

Use --prototype when the user needs a tangible artifact to inspect or try. The artifact can be throwaway, but it still needs usage notes and a verifier.

Use --production-path when the risk is integration, deployment, persistence, data flow, runtime ownership, or "will this work in the real system?" Evidence must touch the real commands, contracts, files, APIs, or gates.

Use --matrix when there are multiple landing zones, libraries, routes, or approaches. Score against the claim, not against general preference.

Prototype Branches

Select the artifact from the question, not the available tool. Derive the question from the user's prompt and surrounding code (ask when the user is reachable), and name the state model when the question is about logic. Put a visible, one-paragraph Question / State model / Prototype status introduction at the top of the artifact, not only in a comment, so a reviewer can re-check the intended question later or AFK. Logic/state questions use a portable interactive model; appearance/layout questions use UI variants. If the choice remains ambiguous and the user is unavailable, a backend module defaults to logic and a page or component defaults to UI; state that assumption at the top. Keep it near its owner, follow existing route conventions, and provide one-command or one-file usage. Use in-memory state or an explicitly authorized disposable persistence target, not production mutations. If the question explicitly involves a database, use a scratch DB or local file whose name visibly says PROTOTYPE — wipe me.

Logic: prefer one self-contained HTML file with a small pure reducer, state machine or function module separated from the DOM shell. Use a state-owning module with a clear method surface if pure transforms do not model the question honestly. The page may call the logic module, but the module must not call the page, DOM, or button handlers; keep that dependency one-way so the logic can be lifted later. Arrange the demo as a title and one-line explanation of the question, current state, free-play controls, then guided walkthroughs. Write it for a non-developer: use domain-language labels and explain in plain words what is happening. Render the full relevant state after every action and call out what just changed where that helps. Provide one always-available free-play button per action so anyone can try actions in any order. Each guided scenario tab starts from a known reset state, includes a short plain-language description of the situation and what to watch for, and supplies ordered real buttons; clicking a step performs its named action and advances to the next step. Include a normal path, a difficult edge and an illegal transition attempt. Hand over the actual file or preview; invite concrete counterexamples, and add requested actions or scenarios within scope when they sharpen the same question. Surprising behavior is evidence about the model, not automatic approval. Keep presentation restrained so state changes remain visible; the portable logic is the candidate decision, not the HTML shell. For a one-file or double-clickable handoff, inline every required script and style so the file runs directly under file://; external modules instead require an explicit local server and an actual preview URL. Open the delivered surface in a browser and exercise a state-changing action—syntax or module-unit checks do not prove that the page initialized. Render the primary state with domain labels for a non-developer; raw JSON may be secondary evidence, not the only state view.

UI: prefer variants inside the existing host page so actual context and density inform the choice. Preserve auth, data fetching, and existing route parameters; vary only the rendered subtree. Use an obviously disposable route only when no host fits. Start with three structurally different layouts (at most five unless explicitly requested), using the project's components. Select via a reload-stable URL parameter; provide a clearly prototype-only floating bottom-bar switcher with the current label and wrapping previous/next controls. ← and → keyboard arrows also cycle variants, but must not steal input, textarea, or contenteditable navigation. Gate prototype controls and exposure from production; mutations use stubs. On every variant switch, render the full relevant prototype state in a readable form, excluding secrets and unrelated personal data. Give each variant a distinct component identity and share the switcher rather than coupling the layouts. Return the actual preview URL and variant keys so the user can revisit a choice. Capture combinations the user prefers across variants, not only a forced single winner.

Capture the question, observed answer, limitations, variant choice/reason and artifact pointer in the existing workstream/design. Preserve the prototype as primary evidence; do not automatically create branches, commit or promote it. Those source defaults are superseded by explicit scope and Git authorization. On authorized implementation, carry the decision-rich logic or winning design forward with production-quality checks and remove prototype controls/losing variants from the shipping path while retaining the evidence pointer.

A prototype optimizes for learning quickly and needs the smallest relevant runnable check, not a production test suite by default. Source advice to skip all testing is superseded by Lev's claim-specific verifier requirement. A clickable demo can resolve a design question; it cannot by itself certify a production path or user acceptance.

Proof Protocol

steps:
  - id: bind_claim
    action: State the single claim being proved and the proof mode.
    validation: "Claim, scope boundary, expected evidence, and stop condition are visible."
    on_failure: "Ask one narrowing question or route to /interview."

  - id: load_prior_art
    action: Search existing chats, workstreams, workshop notes, repo docs, and relevant external sources.
    validation: "Prior-art result names what is new, repeated, stale, or already decided."
    on_failure: "Do not recommend a route or write a matrix."

  - id: choose_verifier
    action: "Pick the cheapest credible proof: command, trace, test, demo, doc evidence, or operator review."
    validation: "Verifier can falsify the claim or clearly explains why it cannot."
    on_failure: "Mark proof as partial instead of proven."

  - id: execute_or_design
    action: Run the proof, build the prototype, or produce the comparison matrix.
    validation: "Evidence is concrete: file, command, output, trace, screenshot, result JSON, or cited prior art."
    on_failure: "Record the failure and route to monitor, reject, or revised proof."

  - id: score_matrix
    action: Score evidence and route the result.
    validation: "Weighted score, hard blockers, verdict, and lifecycle route are visible."
    on_failure: "Do not promote to /propose."

  - id: capture_result
    action: Capture the result into the workstream, design, proposal seed, or archive note.
    validation: "The next lifecycle owner can continue without re-reading the whole chat."
    on_failure: "Emit a compact handoff block in the response."

Proof Matrix

Dimension	Weight	Pass signal
Evidence strength	0.25	Direct artifact, trace, result, command, or source-backed finding
Production-path fit	0.20	Real integration path is named and exercised or bounded
Verifier strength	0.15	The verifier can fail for the right reason
Architecture fit	0.15	Fits known lifecycle, ownership, data, and runtime constraints
Operator value	0.10	Proves a decision the user actually needs
Route clarity	0.10	Next owner and entity state are unambiguous
Cost and risk	0.05	Effort, fragility, and cleanup are acceptable

Verdicts:

• proven: score >= 0.85 and no hard blocker.
• partial: score >= 0.60 or useful evidence with unresolved blockers.
• disproven: evidence falsifies the claim or required path is blocked.
• monitor: not worth acting on now, but worth revisiting.
• reject: no current route, value, or credible proof path.

Output Contract

poc_result:
  claim: ""
  mode: spike|prototype|production_path|matrix
  prior_art:
    reused: []
    new: []
    stale: []
  evidence:
    artifacts: []
    commands: []
    citations: []
    gaps: []
  matrix:
    evidence_strength: 0.0
    production_path_fit: 0.0
    verifier_strength: 0.0
    architecture_fit: 0.0
    operator_value: 0.0
    route_clarity: 0.0
    cost_and_risk: 0.0
    weighted_score: 0.0
  verdict: proven|partial|disproven|monitor|reject
  route: propose|capture|exec|monitor|archive|reject|revise_poc
  next: ""

Next Routes

Route the result, not the existence of a prototype. Show only applicable next owners as a numbered skill://<name> table when there is a real choice; otherwise name one route. Proof completion does not authorize implementation.

Result	Next owner
Supported direction spans multiple outcomes	skill://lev-plan
Supported bounded coding slice	skill://propose
Supported non-coding action with sufficient plan, scope, and checks	skill://exec with the domain method; proposal optional
Claim or decision needs reframing	skill://interview
New insight or rejected hypothesis needs preservation	skill://capture
Monitor, defer, or stop	skill://handoff with the revisit condition; no automatic scheduling
Proof itself is the completed requested outcome	skill://close
Domain route unknown	skill://lev

Stopgap Loop Note

For handwritten skills, a temporary loop may use the operator-approved sleep tick pattern when a real FlowMind runner is not available. Do not copy that pattern into generated lev exec --flow skills. FlowMind-authored skills should get loop behavior from the flow/runtime contract.

Red Baseline

The proof is invalid when any of these statements are true:

• "POC is the disposition." POC is a route; disposition is adopt, extract, monitor, or reject when workshop intake owns the decision.
• "A demo exists, so the production path is proven." Demos prove only the demo unless the real path was exercised.
• "Prior art can be skipped." Repeated concepts must be identified before claiming novelty.
• "The verifier exists, so the claim is true." A verifier is useful only when it can falsify the relevant claim.

Related

• /capture records proof results and entity movement.
• /interview and /design clarify ambiguous proof claims.
• /propose turns proven or aligned results into execution-ready task DNA.
• Workshop intake owns adopt, extract, monitor, and reject dispositions.