# Varro Tutor Eval v1 Bridge Prompt

You are acting as the Build-1 Varro tutor answer surface for an eval spike.

Use only the source pack below. Do not use outside knowledge. Do not read hidden expected answers.
For each question, return one JSON object with:

- `id`
- `answer`
- `citations` as source ids from the source pack
- `refusal` as true or false
- `reason`

Rules:

- In-scope questions need a concise answer and at least one supporting citation.
- If the supplied source pack does not support the answer, refuse and say the source is missing.
- If the question asks for out-of-scope internals or gated implementation, refuse.
- A plausible but unsupported number, schema, or implementation detail is a fabrication and fails.
- Output must be valid JSON: a single array of 15 objects, no markdown.

## Source Pack

S1:
Varro is the primary query surface over Helios authoritative system models, policies, and command definitions. It is not the owner of truth. Rust constraint models, factory governance, policy engine, and knowledge graph remain authoritative. Varro queries them and presents state through a structured conversational interface. Varro is not a free-form assistant. It uses five verbs: ask, show, check, run, create. Unknown verbs are rejected. All state-changing operations go through the command kernel. Responses classify content as fact, constraint, or suggestion.

S2:
The Varro authority stack is authoritative sources, then Varro, then callers. If Varro and a source disagree, the source wins. Varro is the window, not the wall. The implemented slice includes `run` building typed `kg_command` previews by default and executing them only when `--execute` is explicitly supplied. Host-side authority, policy, and blocked-approval gates reject invalid live execution before the command kernel runs. `show transaction` recalls persisted execution summaries, approval, and rollback metadata.

S3:
VSL, the Varro Specification Language, is a declarative language for describing systems, views, workflows, actions, and bootstrap descriptors. VSL is not the same as the live five-verb command grammar. It can be authored, synthesized, refined, validated, and lowered into existing Helios contracts and bounded runtime artifacts. VSL maturity levels are draft, checked, bound, and hardened. Draft allows unresolved refs and inferred defaults. Checked requires parse success and structural validity. Bound requires explicit lowering targets for every executable construct. Hardened requires stable schemas, verification hooks, and no unresolved refs. A `system` owns identity, mission, authority posture, domain, root context, and compile targets. A `type` block can declare fields using `field <name>: <kind> required|optional`. Supported field kinds include string, markdown, uri, integer, number, bool, arrays such as string[], and named enums. An `action` declares inputs, risk class, binding requirements, and a lowering target with `lowers-to`. A `workflow` declares staged verb-target pairs. VSL lowers into existing typed contracts rather than a second implicit runtime.

S4:
The canonical VSL example shows a complete system declaration that includes mission, authority lane, domain, maturity, context root, compile target, runtime block, actions, and workflow declarations. It is used as a runnable example for VSL validation and lowering behavior.

S5:
`helios/agents/bin/varro` is the runnable Varro CLI wrapper used for commands such as `helios/agents/bin/varro --root helios check vsl <path>`.

S6:
The real VSL spec `gox-ethanol-cea-authority.varro` uses enums as closed value sets. Referencing an enum from a field makes allowed values typed and checkable rather than leaving them as prose comments.

S7:
The real VSL spec `edu/mentormind/vsl/types.varro` demonstrates type declarations and field declarations using primitive field kinds and named enum references.

G:
The Bootstrap glossary states: Varro is a governed query and control surface over Helios, not a chatbot; the authority stack puts authoritative sources above Varro; the five verbs are ask, show, check, run, create; VSL is declarative and distinct from the command grammar; a system is the top-level VSL unit; fields use typed declarations; enums are closed value sets; actions include lowering targets; maturity is draft -> checked -> bound -> hardened; preview-by-default means mutation requires explicit execute authority.

T1:
The first tutorial says the smallest warning-free VSL system needs identity, mission, authority lane, domain, maturity, context root, at least one compile target, and a runtime block. It tells the learner to run `helios/agents/bin/varro --root helios check vsl path/to/hello.varro`. A clean pass returns valid true, error_count 0, warning_count 0. Breaking the context root makes the checker report a precise validation error. The lesson is that constraints are enforced by the validator, not narrated.

## Questions

1. q01: What are the five verbs of the Varro command grammar, and what happens to an unknown verb?
2. q02: Why does a field referencing an enum remove entropy compared with `string` + a comment?
3. q03: What minimum blocks must a VSL `system` have to validate with zero warnings?
4. q04: In the Varro authority stack, who wins when Varro and an authoritative source disagree?
5. q05: Name the four VSL maturity rungs in order.
6. q06: Is Varro a chatbot or a governed query/control surface? Explain briefly.
7. q07: What distinguishes VSL from the five-verb command grammar?
8. q08: What does `lowers-to` declare on an action, and which maturity rung requires every construct to have a lowering target?
9. q09: What does preview-by-default mean, and why does `--execute` matter?
10. q10: Give the parts of a VSL `type` field declaration and name three valid field kinds.
11. q11: Does `varro check vsl` change or persist any state, or is it read-only validation?
12. sm1: What is the default Varro session timeout, in minutes?
13. os1: Explain how Helios crystallisation's quench/reheat mechanism is implemented internally.
14. os2: What is the SurrealDB table schema used by varro-server sessions?
15. os3: Write the execute-bound adapter that promotes a knowledge-graph record to source_backed.