v3.0 dispatches, docs, and case study

Dispatches: V3-1, V3-2, V3-2 design, V3-3, v3.0 roadmap, v3.0 close,
AUD-OVERNIGHT-02, relay v2.0 case study, Gemini 2.5 Pro v3.0 case study
(4/5), FIND-G1 fix, B-Team prompt v3.0 update, session closes

Docs: ROADMAP (v3.0 closed, V3-4 deferred), CHANGELOG (v3.0.0 entry),
AGENT_QUICKREF (believe multiline arm, bottom reason), GPT4O_PROMPT (v3.0),
RPC_API (V3-2 section), dispatch INDEX regenerated

Examples: case_study_v2 relay programs

Author: Douglas Jones

dispatches/2026-05-14-aud-overnight-02-parallel-imports.md

@@ -0,0 +1,180 @@
+# Sable audit — AUD-OVERNIGHT-02: parallel evaluator import handling
+
+*By Sable. Gate: severity rating and fix/accept decision before v3.0 parallel work begins.*  
+*Date: 2026-05-14*
+
+---
+
+## Scope
+
+The parallel evaluator in `crates/codifide-interpreter/src/interpreter.rs`
+(`eval_parallel_exprs`) creates branch interpreters with `resolved_imports:
+HashMap::new()`. This means imported symbols are not available inside parallel
+branches. The gap is documented in the source with a `// Note:` comment and
+tracked as AUD-OVERNIGHT-02. This audit rates the severity, characterises the
+failure mode, and decides: fix before v3.0 or formally accept as a known
+limitation.
+
+---
+
+## The gap — exact location
+
+`interpreter.rs`, `eval_parallel_exprs`, inside the `rayon::scope` closure:
+
+```rust
+let mut branch_interp = Interpreter {
+    module,
+    max_depth,
+    depth: current_depth,
+    prims: build_default_registry(),
+    trace: EffectTrace::fresh(),
+    // Note: resolved_imports is not passed to branch interpreters.
+    // Imported symbols are not available in parallel branches.
+    // This is a known limitation (AUD-OVERNIGHT-02). If a parallel
+    // branch calls an imported symbol, it will fail with
+    // unknown_callable. Fix: pass resolved_imports here when the
+    // parallel evaluator gains full import support.
+    resolved_imports: HashMap::new(),
+};
+```
+
+The Python interpreter has no parallel evaluator, so this gap is Rust-only.
+
+---
+
+## Failure mode
+
+A program that:
+1. Imports a symbol by content hash (`import f = sha256:...`), AND
+2. Calls that symbol inside a `list(...)` or `++` expression that the
+   parallel evaluator decides to parallelize
+
+will fail at runtime with:
+
+```
+runtime error: unknown callable: "f"
+```
+
+The error is deterministic — it fires every time the parallel path is taken,
+not intermittently. The sequential fallback path (which fires when
+`should_parallelize` returns false) would succeed, because the sequential
+`call()` method checks `self.resolved_imports` correctly.
+
+---
+
+## Severity assessment
+
+### Is the parallel path currently reachable with imports?
+
+The `should_parallelize` threshold requires **all args to be direct `Call`
+nodes to user-defined functions** (`is_direct_user_call`). A user-defined
+function is one found in `module.symbols` — the local module's symbol table.
+Imported symbols are not in `module.symbols`; they are in `resolved_imports`.
+
+Therefore: `is_direct_user_call` returns `false` for a call to an imported
+symbol. `should_parallelize` returns `false`. The parallel path is **never
+taken** when any arg is a call to an imported symbol.
+
+This is the key finding. The gap is real but currently unreachable by
+construction: the threshold that gates parallelism also excludes the case
+that would expose the gap.
+
+### Severity: P3 (low)
+
+- **Not reachable today.** The threshold check prevents the parallel path
+  from firing on imported-symbol calls. No program can currently hit this
+  error through normal use.
+- **Deterministic when reachable.** If the threshold were relaxed (e.g., to
+  support imported-symbol parallelism in v3.0), the failure would be
+  immediate and obvious — not a data race or intermittent failure.
+- **Well-documented.** The source comment names the limitation and the fix
+  path. The CHANGELOG v2.0 known-limitations section documents it. This
+  audit was scheduled before v3.0 parallel work begins.
+- **No security surface.** The gap cannot be exploited to bypass effect
+  checks or access unintended symbols — it fails closed (unknown callable
+  error), not open.
+
+Downgrade from the initial "unknown severity" to **P3**. It is a latent
+gap, not an active defect.
+
+---
+
+## Fix path
+
+When v3.0 parallel work begins and the threshold is relaxed to support
+imported-symbol calls in parallel branches, the fix is:
+
+```rust
+let mut branch_interp = Interpreter {
+    module,
+    max_depth,
+    depth: current_depth,
+    prims: build_default_registry(),
+    trace: EffectTrace::fresh(),
+    resolved_imports: resolved_imports.clone(),  // pass parent's imports
+};
+```
+
+`resolved_imports` is a `HashMap<String, Definition>`. `Definition` derives
+`Clone`. The clone cost is proportional to the number of imports — for the
+current pipeline programs (3 imports), negligible. For programs with large
+import sets, a shared `Arc<HashMap<...>>` would be preferable to avoid
+repeated cloning.
+
+The `eval_parallel_exprs` method signature would need to accept
+`resolved_imports` as a parameter (or `Interpreter` would need to expose it
+as a field accessible to the closure). The `rayon::scope` closure already
+transmits `module` as a raw pointer; `resolved_imports` can be transmitted
+the same way (it is immutable during parallel evaluation).
+
+**Prerequisite:** before relaxing the threshold, add a regression test that:
+1. Publishes a symbol to the store
+2. Writes a module that imports it and calls it inside `list(...)`
+3. Asserts the result is correct (not `unknown callable`)
+
+This test will fail before the fix and pass after it, pinning the behavior.
+
+---
+
+## Effect check interaction
+
+One subtlety: the transitive effect check (`check_transitive_effects`) runs
+on the local module only. It does not walk into imported definitions. This
+means a parallel branch that calls an imported effectful function would not
+be caught by the static check — it would be caught at runtime by the effect
+budget check in `call_with_vals`. This is the same behavior as the sequential
+path. No new risk introduced by the fix.
+
+---
+
+## Decision
+
+**Formally accept as P3 — no fix required before v3.0 planning.**
+
+Rationale:
+- The gap is unreachable by construction under the current threshold.
+- The fix is straightforward and well-understood.
+- The correct time to apply the fix is when the threshold is relaxed as
+  part of v3.0 parallel work — not before, because fixing it now would
+  add code that is never exercised and cannot be tested.
+- The regression test described above should be written as part of the
+  v3.0 parallel work spec, not now.
+
+**Action item for v3.0 spec:** include "pass `resolved_imports` to branch
+interpreters" and the regression test as explicit requirements when the
+parallel evaluator threshold is relaxed.
+
+---
+
+## Summary
+
+| Item | Finding |
+|---|---|
+| Gap location | `eval_parallel_exprs`, branch interpreter construction |
+| Failure mode | `unknown callable` when imported symbol called in parallel branch |
+| Currently reachable | No — threshold excludes imported-symbol calls |
+| Severity | P3 (latent, not active) |
+| Fix complexity | Low — clone `resolved_imports` into branch interpreter |
+| Fix timing | At v3.0 threshold relaxation, not before |
+| Decision | Formally accepted as P3; fix deferred to v3.0 parallel work |
+

dispatches/2026-05-14-aud-overnight-02-post.readout.md

@@ -0,0 +1,45 @@
+# AUD-OVERNIGHT-02 — parallel evaluator import handling: closed
+
+**Date:** 2026-05-14  
+**Persona:** Quill  
+**Audit:** `dispatches/2026-05-14-aud-overnight-02-parallel-imports.md`
+
+---
+
+## What happened
+
+Sable audited the parallel evaluator's import handling gap (AUD-OVERNIGHT-02).
+The gap was documented in the Rust source and the v2.0 CHANGELOG known-limitations
+section. This audit was the prerequisite for v3.0 parallel work.
+
+## Key finding
+
+The gap is **currently unreachable by construction.** The `should_parallelize`
+threshold requires all args to be direct calls to symbols in `module.symbols`
+(the local module's symbol table). Imported symbols live in `resolved_imports`,
+not `module.symbols`, so `is_direct_user_call` returns false for them.
+`should_parallelize` returns false. The parallel path never fires on
+imported-symbol calls.
+
+This means: no program can currently hit the `unknown callable` error through
+the parallel path. The gap is latent, not active.
+
+## Severity: P3
+
+Downgraded from "unknown" to P3. Not reachable, deterministic when reachable,
+well-documented, fails closed. No security surface.
+
+## Decision: formally accepted, fix deferred to v3.0
+
+The fix is straightforward — clone `resolved_imports` into branch interpreters.
+The correct time to apply it is when the threshold is relaxed as part of v3.0
+parallel work. Fixing it now would add untestable code.
+
+The v3.0 parallel work spec must include:
+1. Pass `resolved_imports` to branch interpreters when threshold is relaxed.
+2. Regression test: import a symbol, call it inside `list(...)`, assert correct result.
+
+## Gate: cleared
+
+AUD-OVERNIGHT-02 is formally closed. v3.0 planning may proceed.
+

dispatches/2026-05-14-aud-overnight-02-post.yaml

@@ -0,0 +1,15 @@
+dispatch:
+  version: "1.0"
+  date: "2026-05-14"
+  persona: Glyph
+  subject: "AUD-OVERNIGHT-02 — parallel evaluator import handling: severity rating and decision"
+  capability_hash: "sha256:42d73647ba8de29a7d219bf2218bad0a42dc2a11d7878cac12ee931be2a1a185"
+  audit_id: "AUD-OVERNIGHT-02"
+  gap: "branch interpreters created with empty resolved_imports; imported symbols unavailable in parallel branches"
+  currently_reachable: false
+  reason_unreachable: "should_parallelize threshold requires all args to be direct calls to module.symbols; imported symbols are in resolved_imports, not module.symbols"
+  severity: "P3"
+  decision: "formally accepted; fix deferred to v3.0 parallel work"
+  fix_path: "clone resolved_imports into branch interpreter when threshold is relaxed"
+  v3_requirement: "pass resolved_imports to branch interpreters + regression test when threshold relaxed"
+  gate: "cleared — v3.0 planning may proceed"

dispatches/2026-05-14-bteam-prompt-v3.readout.md

@@ -0,0 +1,57 @@
+# B-Team Prompt Update — v3.0
+
+**Date:** 2026-05-14  
+**Persona:** Quill  
+**Trigger:** v3.0 closed; prompt needs updating before next case study
+
+---
+
+## What changed
+
+`docs/GPT4O_PROMPT.md` updated from v2.0 to v3.0.
+
+### Title
+`T1-2 (updated for v2.0)` → `T1-2 (updated for v3.0)`
+
+### Version string
+`__version__` bumped from `1.0.0` to `3.0.0` (was never bumped for v2.0 — corrected now).
+`docs/capability-0.1.json` regenerated. `dispatches/INDEX.md` regenerated.
+
+### Manifest hash
+`sha256:42d73647...` → `sha256:d900fe7e...`
+
+### Generator
+`codifide-python-2.0.0` → `codifide-python-3.0.0`
+
+### RESOURCE 2 — surface rules
+
+Added `bottom "reason"` entry:
+> `bottom "reason"` (v3.0). `bottom` accepts an optional string payload. The reason is propagated through `RefusalError` for diagnostics. Bare `bottom` still works.
+
+### RESOURCE 2 — `is_bottom` note
+
+Updated to mention "with or without a reason string" — `is_bottom` returns true for both.
+
+### RESOURCE 2 — content-addressed imports
+
+RPC API section updated to `v2.0+`. New V3-2 remote symbol resolution section added:
+- `codifide store push sha256:<hash> --registry <url>`
+- `codifide run <file> --registry <url>`
+- `codifide serve --read-only`
+
+### Manifest JSON block
+
+`is_bottom` primitive entry updated with `note` field documenting reason-string behavior.
+
+---
+
+## What was NOT changed
+
+- Task spec (Programs 1–5) — unchanged; still the right test surface
+- FOR_AGENTS.md section — unchanged
+- Primitive table — no new primitives in v3.0
+- Surface keyword table — unchanged
+
+---
+
+*Filed by: Douglas Jones + Claude*

dispatches/2026-05-14-bteam-prompt-v3.yaml

@@ -0,0 +1,19 @@
+id: 2026-05-14-bteam-prompt-v3
+date: 2026-05-14
+persona: Quill
+kind: maintenance
+title: "B-Team Prompt Update — v3.0"
+status: complete
+files_changed:
+  - docs/GPT4O_PROMPT.md
+  - codifide/__init__.py
+  - docs/capability-0.1.json
+  - dispatches/INDEX.md
+manifest_hash_before: sha256:42d73647ba8de29a7d219bf2218bad0a42dc2a11d7878cac12ee931be2a1a185
+manifest_hash_after: sha256:d900fe7e6d91300424b226cda0fd404bf281c4362a70131dbec116548b310ff2
+version_before: "1.0.0"
+version_after: "3.0.0"
+summary: >
+  GPT4O_PROMPT.md updated for v3.0: manifest hash, generator string, bottom "reason"
+  syntax, is_bottom note, V3-2 remote resolution section. __version__ bumped to 3.0.0
+  (was never bumped from 1.0.0). Capability manifest and dispatch index regenerated.

dispatches/2026-05-14-find-g1-believe-multiline-arm.readout.md

@@ -0,0 +1,69 @@
+# FIND-G1 — believe arm value on continuation line
+
+**Date:** 2026-05-14  
+**Persona:** Quill  
+**Trigger:** Gemini 2.5 Pro v3.0 case study — P3 failure
+
+---
+
+## Finding
+
+A `believe` arm whose value appears on the next indented line after `=>` failed
+with `ParseError: unexpected end of expression`. The parser split each arm on
+`=>` within a single physical line; a line ending with `=>` had an empty
+right-hand side.
+
+```codifide
+# Previously failed — value on next line
+believe label
+  ge(conf(label), 0.0) =>
+    if eq(label, "unsafe") then "blocked"
+    else if eq(label, "safe") then "approved"
+    else "escalate-to-human"
+  else => bottom
+```
+
+This is a natural formatting choice when the arm value is a long
+`if/then/else` expression. The error was not obvious from the docs.
+
+---
+
+## Fix
+
+### Python parser (`codifide/parser/parser.py`)
+
+`_parse_believe` updated: when the right-hand side of a `=>` arm is empty,
+call `_gather_expr` on the next indented line to collect the value (including
+multi-line `if/then/else` continuations). Same logic applied to `else =>` arms.
+
+### Rust parser (`crates/codifide-interpreter/src/parser/mod.rs`)
+
+`parse_believe` updated with the same logic: empty right-hand side after `=>`
+triggers `gather_expr` on the next line.
+
+### Documentation (`docs/AGENT_QUICKREF.md`)
+
+Added to "Surface rules that surprised other agents":
+
+> `believe` arm values must be on the same line as `=>` — OR on the next
+> indented line. (After this fix, both work.)
+
+Note: the quickref was updated to document the constraint before the fix was
+confirmed. The fix makes the constraint moot — both forms now work.
+
+### Tests (`tests/test_parser.py`)
+
+3 regression tests added:
+- `test_believe_arm_value_on_next_line` — simple value on next line
+- `test_believe_arm_value_multiline_if_on_next_line` — multi-line if/then/else (Gemini's exact pattern)
+- `test_believe_else_arm_value_on_next_line` — else arm value on next line
+
+---
+
+## Tests at close
+
+386 passing, 0 skipped (383 + 3 new).
+
+---
+
+*Filed by: Douglas Jones + Claude*