context-compiler 0.7.2__tar.gz → 0.7.4__tar.gz

{context_compiler-0.7.2 → context_compiler-0.7.4}/AGENTS.md

@@ -75,6 +75,7 @@ Prefer modern typing syntax:
 
 ## PR guidance
 - Never open or merge a PR targeting `main` from `main`; always use a feature branch.
+- Always use the repository PR template when creating or updating PR descriptions.
 - PR titles must use the same format as commits: `<type>: <summary>`.
 - PR descriptions should include:
   - what changed
@@ -82,6 +83,11 @@ Prefer modern typing syntax:
 - Do not include a dedicated "Validation" section in PR text.
 - Keep PR scope aligned to the requested task; if scope grows, ask for guidance before expanding.
 
+## Issue guidance
+- Always use the repository issue templates when creating or updating issues.
+- Use `bug_report` for defects and regressions.
+- Use `feature_request` for new capabilities or enhancements.
+
 ## CI
 Do not modify GitHub CI workflows unless explicitly asked.
 
@@ -105,6 +111,10 @@ Prefer plain, concrete wording when accurate. Examples:
 
 Avoid describing features only in architectural terms when a behavior-first explanation is possible.
 
+Prefer direct subjects and strong verbs.
+Avoid noun stacks and passive phrasing when a simpler active sentence is clearer.
+Use simpler wording unless technical precision requires formal terminology.
+
 Specification and contract documents are different:
 - preserve precise terminology
 - preserve unambiguous behavioral guarantees

{context_compiler-0.7.2 → context_compiler-0.7.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: context-compiler
-Version: 0.7.2
+Version: 0.7.4
 Summary: Deterministic conversational state engine for LLM applications.
 Project-URL: Homepage, https://github.com/rlippmann/context-compiler
 Project-URL: Repository, https://github.com/rlippmann/context-compiler
@@ -40,11 +40,11 @@ Description-Content-Type: text/markdown
 [![Python versions](https://img.shields.io/pypi/pyversions/context-compiler)](https://pypi.org/project/context-compiler/)
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
-Some behaviors require explicit host-side state machinery.
+Some behaviors require explicit host-side state handling.
 
 Context Compiler is a deterministic host-side state layer for LLM applications.
-It handles explicit state transitions for premise and policies so that mutation
-rules are fixed and repeatable.
+It applies explicit premise and policy updates so state changes stay fixed and
+repeatable.
 
 ## What prompting and reinjection can do
 
@@ -59,17 +59,17 @@ pending confirmations from checkpoints.
 ## What prompting cannot do by itself
 
 Prompt text (including reinjected state text) helps, but it does not give your
-app controlled rules for when state can change. By itself, it does not provide:
+app clear rules for when state can change. By itself, it does not provide:
 
 - rules your app controls for state changes
 - replacement precondition checks (`use X instead of Y` when `Y` may be absent)
 - confirmation flows that must complete before anything else changes
-- clear decisions about when a change is blocked
+- clear rules for when to block a change
 - reliable checkpoint restore for both saved state and pending confirmation flow
 
 ## What Context Compiler provides
 
-Context Compiler provides fixed host-side state machinery:
+Context Compiler provides fixed host-side state handling:
 
 - deterministic directive handling for explicit user state changes
 - clarification instead of silent overwrite for blocked/ambiguous changes
@@ -139,22 +139,55 @@ Bare REPL input behavior remains unchanged.
 
 Or in code:
 ```python
-from context_compiler import DECISION_CLARIFY, DECISION_UPDATE, create_engine
+from context_compiler import (
+    create_engine,
+    get_clarify_prompt,
+    is_clarify,
+    is_update,
+)
 
 engine = create_engine()
 
 user_input = "prohibit peanuts"
 decision = engine.step(user_input)
 
-if decision["kind"] == DECISION_CLARIFY:
-    show_to_user(decision["prompt_to_user"])
-elif decision["kind"] == DECISION_UPDATE:
+if is_clarify(decision):
+    show_to_user(get_clarify_prompt(decision))
+elif is_update(decision):
     messages = build_messages(engine.state, user_input)
     render(call_llm(messages))
 else:
     render(call_llm(user_input))
 ```
 
+Controller quick example:
+
+```python
+from context_compiler import (
+    get_decision_state,
+    is_update,
+    create_engine,
+    preview,
+    state_diff,
+    step,
+)
+
+engine = create_engine()
+
+before = engine.state
+dry_run = preview(engine, "prohibit peanuts")
+print(dry_run["would_mutate"])  # True
+planned_change = state_diff(before, dry_run["state_after"])
+print(planned_change["changed"])  # True
+
+after_preview = engine.state
+print(state_diff(before, after_preview)["changed"])  # False (preview does not mutate state)
+
+applied = step(engine, "prohibit peanuts")
+print(is_update(applied["decision"]))  # True
+print(get_decision_state(applied["decision"]) is not None)  # True
+```
+
 ## Installation
 
 Requirements:
@@ -297,6 +330,10 @@ Meaning:
 | update      | authoritative state mutated; host may call LLM with updated state |
 | clarify     | show `prompt_to_user` and do not call the LLM |
 
+For normal app code, prefer exported decision helpers (`is_clarify`,
+`is_update`, `is_passthrough`, `get_clarify_prompt`, `get_decision_state`)
+instead of direct key traversal.
+
 ---
 
 ### API Reference
@@ -334,6 +371,17 @@ Decision-kind constants are also exported for host branching readability:
 - `DECISION_UPDATE`
 - `DECISION_CLARIFY`
 
+Decision helpers are also exported for common host-side checks:
+- `is_update(decision)`
+- `is_clarify(decision)`
+- `is_passthrough(decision)`
+- `get_clarify_prompt(decision)`
+- `get_decision_state(decision)`
+
+Policy value constants are exported for explicit policy comparisons:
+- `POLICY_USE`
+- `POLICY_PROHIBIT`
+
 ---
 
 ## State Model
@@ -348,6 +396,8 @@ The compiler keeps a current state snapshot that your app can trust.
 Identical input sequences always produce identical state.
 
 The internal structure of the state is intentionally opaque to host applications.
+For normal reads, prefer `get_premise_value(state)` and
+`get_policy_items(state, ...)` over direct key traversal.
 
 ---
 
@@ -384,6 +434,9 @@ Checkpoint object shape:
 }
 ```
 
+The checkpoint shape above is an explicit serialization contract. At this
+boundary, direct key access is expected.
+
 Notes:
 
 - `pending` is `null` when no continuation is waiting for confirmation.

{context_compiler-0.7.2 → context_compiler-0.7.4}/README.md

@@ -4,11 +4,11 @@
 [![Python versions](https://img.shields.io/pypi/pyversions/context-compiler)](https://pypi.org/project/context-compiler/)
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
-Some behaviors require explicit host-side state machinery.
+Some behaviors require explicit host-side state handling.
 
 Context Compiler is a deterministic host-side state layer for LLM applications.
-It handles explicit state transitions for premise and policies so that mutation
-rules are fixed and repeatable.
+It applies explicit premise and policy updates so state changes stay fixed and
+repeatable.
 
 ## What prompting and reinjection can do
 
@@ -23,17 +23,17 @@ pending confirmations from checkpoints.
 ## What prompting cannot do by itself
 
 Prompt text (including reinjected state text) helps, but it does not give your
-app controlled rules for when state can change. By itself, it does not provide:
+app clear rules for when state can change. By itself, it does not provide:
 
 - rules your app controls for state changes
 - replacement precondition checks (`use X instead of Y` when `Y` may be absent)
 - confirmation flows that must complete before anything else changes
-- clear decisions about when a change is blocked
+- clear rules for when to block a change
 - reliable checkpoint restore for both saved state and pending confirmation flow
 
 ## What Context Compiler provides
 
-Context Compiler provides fixed host-side state machinery:
+Context Compiler provides fixed host-side state handling:
 
 - deterministic directive handling for explicit user state changes
 - clarification instead of silent overwrite for blocked/ambiguous changes
@@ -103,22 +103,55 @@ Bare REPL input behavior remains unchanged.
 
 Or in code:
 ```python
-from context_compiler import DECISION_CLARIFY, DECISION_UPDATE, create_engine
+from context_compiler import (
+    create_engine,
+    get_clarify_prompt,
+    is_clarify,
+    is_update,
+)
 
 engine = create_engine()
 
 user_input = "prohibit peanuts"
 decision = engine.step(user_input)
 
-if decision["kind"] == DECISION_CLARIFY:
-    show_to_user(decision["prompt_to_user"])
-elif decision["kind"] == DECISION_UPDATE:
+if is_clarify(decision):
+    show_to_user(get_clarify_prompt(decision))
+elif is_update(decision):
     messages = build_messages(engine.state, user_input)
     render(call_llm(messages))
 else:
     render(call_llm(user_input))
 ```
 
+Controller quick example:
+
+```python
+from context_compiler import (
+    get_decision_state,
+    is_update,
+    create_engine,
+    preview,
+    state_diff,
+    step,
+)
+
+engine = create_engine()
+
+before = engine.state
+dry_run = preview(engine, "prohibit peanuts")
+print(dry_run["would_mutate"])  # True
+planned_change = state_diff(before, dry_run["state_after"])
+print(planned_change["changed"])  # True
+
+after_preview = engine.state
+print(state_diff(before, after_preview)["changed"])  # False (preview does not mutate state)
+
+applied = step(engine, "prohibit peanuts")
+print(is_update(applied["decision"]))  # True
+print(get_decision_state(applied["decision"]) is not None)  # True
+```
+
 ## Installation
 
 Requirements:
@@ -261,6 +294,10 @@ Meaning:
 | update      | authoritative state mutated; host may call LLM with updated state |
 | clarify     | show `prompt_to_user` and do not call the LLM |
 
+For normal app code, prefer exported decision helpers (`is_clarify`,
+`is_update`, `is_passthrough`, `get_clarify_prompt`, `get_decision_state`)
+instead of direct key traversal.
+
 ---
 
 ### API Reference
@@ -298,6 +335,17 @@ Decision-kind constants are also exported for host branching readability:
 - `DECISION_UPDATE`
 - `DECISION_CLARIFY`
 
+Decision helpers are also exported for common host-side checks:
+- `is_update(decision)`
+- `is_clarify(decision)`
+- `is_passthrough(decision)`
+- `get_clarify_prompt(decision)`
+- `get_decision_state(decision)`
+
+Policy value constants are exported for explicit policy comparisons:
+- `POLICY_USE`
+- `POLICY_PROHIBIT`
+
 ---
 
 ## State Model
@@ -312,6 +360,8 @@ The compiler keeps a current state snapshot that your app can trust.
 Identical input sequences always produce identical state.
 
 The internal structure of the state is intentionally opaque to host applications.
+For normal reads, prefer `get_premise_value(state)` and
+`get_policy_items(state, ...)` over direct key traversal.
 
 ---
 
@@ -348,6 +398,9 @@ Checkpoint object shape:
 }
 ```
 
+The checkpoint shape above is an explicit serialization contract. At this
+boundary, direct key access is expected.
+
 Notes:
 
 - `pending` is `null` when no continuation is waiting for confirmation.

{context_compiler-0.7.2 → context_compiler-0.7.4}/docs/DescriptionAndMilestones.md

@@ -10,9 +10,9 @@ conversations, and state can conflict over time.
 This project adds a deterministic state layer that is independent of the model.
 The model handles interpretation and generation; the engine handles premise and
 policies. Only explicit user directives can change state.
-By separating reasoning from state ownership, the system improves reliability
-without requiring model retraining. The system never derives authoritative state
-from model responses.
+When the model reasons and the engine owns state, behavior stays reliable
+without retraining the model. The system never derives authoritative state from
+model responses.
 The goal is not to make the model smarter, but to make interactions
 predictable: once a statement is corrected or scoped, future responses
 must respect that change.
@@ -64,7 +64,7 @@ After correcting or constraining the assistant once, the behavior remains consis
 ### M3 — Cross-Session Recall (implemented, engine-level / host-enabled)
 
 **Goal**
-Extend app-level workflows around persisted exported state safely and intentionally.
+Help apps safely reuse saved exported state.
 
 **Core capability:**
 
@@ -77,8 +77,8 @@ Extend app-level workflows around persisted exported state safely and intentiona
 
 **Deliverables:**
 
-- App-side storage/recovery patterns built on the existing import/export API
-- App-side storage/recovery patterns for checkpoint object/checkpoint JSON continuation restore
+- App-side storage and recovery patterns built on the existing import/export API
+- App-side storage and recovery patterns for checkpoint object and checkpoint JSON restore
 
 **User-visible outcome:**
 

{context_compiler-0.7.2 → context_compiler-0.7.4}/docs/DesignPhilosophy.md

@@ -2,7 +2,7 @@
 
 ## The Problem with Implicit State
 
-Modern LLM applications typically manage conversational state implicitly — the model reads the transcript, infers what constraints are active, and generates a response accordingly. This works well for short conversations and simple tasks.
+Modern LLM applications often manage conversational state implicitly: the model reads the transcript, infers active constraints, and generates a response. This works well for short conversations and simple tasks.
 
 It breaks down reliably in longer conversations, correction flows, and multi-turn constraint management. Constraints drift. Corrections get partially applied or treated as additive rather than authoritative replacements. Contradictions accumulate instead of resolving. The model interprets intent rather than enforcing it.
 
@@ -16,7 +16,7 @@ Explicit state management is not a new idea. Earlier AI systems maintained struc
 
 The core insight is simple: maintain an explicit active set of rules rather than inferring the relevant context from history each time. What is in the active set is known with certainty. What is not in it is not active.
 
-These approaches succeeded in narrow, well-defined domains precisely because explicit state gives you guarantees that implicit inference cannot. The limitation was not the state management approach — it was that handling natural language and ambiguity was extraordinarily difficult. Those problems consumed most of the design effort.
+These approaches succeeded in narrow, well-defined domains because explicit state gives guarantees that implicit inference cannot. The limitation was not state management itself. Handling natural language and ambiguity was the hard part, and that work consumed most of the design effort.
 
 Modern LLMs handle natural language interpretation and generation far more effectively than earlier systems. This changes the calculus: the language interface problem is largely addressed. As end-to-end neural approaches became dominant, many systems shifted toward transcript-driven implicit state management, assuming a capable model could handle state implicitly.
 
@@ -26,8 +26,8 @@ That assumption is incorrect in practice, for the structural reason described ab
 
 Context Compiler applies explicit state management to the modern LLM context, with a clear division of responsibilities:
 
-- The LLM handles what it is genuinely good at — language understanding, reasoning, generation, handling ambiguity in user intent
-- The deterministic engine handles what probabilistic systems handle poorly — maintaining explicit state across turns, enforcing constraints, guaranteeing that corrections replace rather than compete with prior state
+- The LLM handles what it does well: language understanding, reasoning, generation, and ambiguity in user intent
+- The deterministic engine handles what probabilistic systems handle poorly: keep explicit state across turns, enforce constraints, and make corrections replace prior state instead of competing with it
 
 The preprocessor layer bridges the two: it uses the LLM's language understanding to translate natural language directive intent into canonical form, which the deterministic engine can then process reliably. Fuzzy where it needs to be fuzzy, deterministic where determinism matters.
 

{context_compiler-0.7.2 → context_compiler-0.7.4}/docs/llm-preprocessor.md

@@ -15,8 +15,7 @@ layer. Do not rely on repo-relative preprocessor paths.
 
 ## Architectural framing
 
-The preprocessor is a helper layer in your app, not the source of truth for
-state changes.
+The preprocessor helps your app, but it does not own state changes.
 
 Model/tool-description translation can help with simple direct cases, but
 integrations should not rely on model intent translation alone to decide when
@@ -25,10 +24,10 @@ state changes.
 In simpler hosts without an embedded model, this preprocessor provides a
 conservative translation path.
 
-In model-assisted hosts, the app still checks outputs before applying them.
+In model-assisted hosts, the app still validates outputs before applying them.
 
 Both paths send canonical directives to the same deterministic engine. The
-engine still controls state updates.
+engine controls state updates.
 
 In MCP/tool-calling environments, over-eager tool calling on conversational or
 ambiguous input is a known failure mode. Conservative preprocessing and
@@ -36,7 +35,7 @@ validation help reduce unintended mutation.
 
 ## Required flow
 
-Recommended conceptual flow:
+Recommended flow:
 
 1. heuristic preprocessing
 2. validate candidate output

{context_compiler-0.7.2 → context_compiler-0.7.4}/docs/multi-engine.md

@@ -73,7 +73,7 @@ Introduce multiple engines only when you need **independent lifecycle or isolati
 ## Combining Policies from Multiple Sources
 
 If you need to combine constraints from separate sources, do it explicitly in
-host code by replaying directives through `step(...)` into a target engine.
+host code: replay directives through `step(...)` into a target engine.
 
 Pattern:
 
@@ -81,5 +81,5 @@ Pattern:
 2. Replay each directive via `engine.step(...)`
 3. Handle any returned `clarify` decisions explicitly
 
-This keeps conflict handling in normal engine semantics and avoids adding merge
-semantics to core state APIs.
+This keeps conflict handling in normal engine behavior and avoids adding merge
+rules to core state APIs.

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/01_persistent_guardrails.py

@@ -2,11 +2,11 @@
 
 from _util import print_decision_summary, print_state_summary
 
-from context_compiler import State, create_engine, get_policy_items
+from context_compiler import POLICY_PROHIBIT, State, create_engine, get_policy_items
 
 
 def build_prompt(state: State, user_input: str) -> str:
-    prohibit = get_policy_items(state, "prohibit")
+    prohibit = get_policy_items(state, POLICY_PROHIBIT)
     prohibit_text = ", ".join(prohibit) if prohibit else "(none)"
     return (
         "System: Follow authoritative conversation state.\n"

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/03_ambiguity_with_clarification.py

@@ -2,7 +2,7 @@
 
 from _util import print_decision_summary, print_state_summary
 
-from context_compiler import create_engine
+from context_compiler import create_engine, get_clarify_prompt, is_clarify
 
 
 def fake_llm(user_input: str) -> str:
@@ -23,9 +23,9 @@ def main() -> None:
     print_decision_summary(decision2)
     print()
 
-    if decision2["kind"] == "clarify":
+    if is_clarify(decision2):
         print("Host behavior: clarification pending, do NOT call LLM.")
-        print(f"Clarify prompt: {decision2['prompt_to_user']}")
+        print(f"Clarify prompt: {get_clarify_prompt(decision2)}")
     else:
         fake_llm("use peanuts")
     print()

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/04_tool_governance_denylist.py

@@ -4,7 +4,7 @@ from dataclasses import dataclass
 
 from _util import print_decision_summary, print_state_summary
 
-from context_compiler import create_engine, get_policy_items
+from context_compiler import POLICY_PROHIBIT, create_engine, get_policy_items
 
 
 @dataclass
@@ -32,7 +32,7 @@ def main() -> None:
     print()
 
     print("Host-side tool denylist behavior:")
-    prohibit = get_policy_items(state, "prohibit")
+    prohibit = get_policy_items(state, POLICY_PROHIBIT)
     tools = [Tool("docker"), Tool("kubectl")]
     for tool in tools:
         if tool.name in prohibit:

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/05_llm_integration_pattern.py

@@ -3,12 +3,14 @@
 from _util import print_decision_summary, print_state_summary
 
 from context_compiler import (
-    DECISION_CLARIFY,
-    DECISION_PASSTHROUGH,
-    DECISION_UPDATE,
     Engine,
     State,
     create_engine,
+    get_clarify_prompt,
+    get_decision_state,
+    is_clarify,
+    is_passthrough,
+    is_update,
 )
 
 
@@ -27,15 +29,15 @@ def handle_turn(engine_input: str, engine: Engine) -> None:
     print(f"User: {engine_input}")
     print_decision_summary(decision)
 
-    if decision["kind"] == DECISION_PASSTHROUGH:
+    if is_passthrough(decision):
         print("Host action: passthrough -> call fake_llm() without state")
         fake_llm(None, engine_input)
-    elif decision["kind"] == DECISION_UPDATE:
+    elif is_update(decision):
         print("Host action: update -> call fake_llm() with compiled state")
-        fake_llm(decision["state"], engine_input)
-    elif decision["kind"] == DECISION_CLARIFY:
+        fake_llm(get_decision_state(decision), engine_input)
+    elif is_clarify(decision):
         print("Host action: clarify -> show prompt, DO NOT call LLM")
-        print("clarify prompt:", decision["prompt_to_user"])
+        print("clarify prompt:", get_clarify_prompt(decision))
     print()
 
 

context_compiler-0.7.4/examples/08_controller_preview_diff.py

@@ -0,0 +1,30 @@
+"""Example 8: controller preview + state diff + apply flow."""
+
+from _util import print_decision_summary, print_state_summary
+
+from context_compiler import create_engine, preview, state_diff, step
+
+
+def main() -> None:
+    engine = create_engine()
+
+    state_before = engine.state
+    print_state_summary(state_before, "state before preview")
+
+    print("\nPreview: prohibit peanuts")
+    preview_result = preview(engine, "prohibit peanuts")
+    print("would_mutate:", preview_result["would_mutate"])
+    print_decision_summary(preview_result["decision"])
+
+    state_after_preview = engine.state
+    diff_after_preview = state_diff(state_before, state_after_preview)
+    print("state changed after preview:", diff_after_preview["changed"])
+
+    print("\nApply: prohibit peanuts")
+    step_result = step(engine, "prohibit peanuts")
+    print_decision_summary(step_result["decision"])
+    print_state_summary(step_result["state"], "state after step")
+
+
+if __name__ == "__main__":
+    main()

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/README.md

@@ -40,3 +40,9 @@ Shows `compile_transcript(messages)` from a fresh engine and `engine.apply_trans
 
 Demonstrates explicit single-policy correction without `reset policies`.  
 Shows `prohibit peanuts` -> `remove policy peanuts` -> `use peanuts`.
+
+## 08_controller_preview_diff.py
+
+Shows controller-layer dry-run behavior with `preview(engine, user_input)`.  
+Shows structural state inspection with `state_diff(state_before, state_after)`.  
+Shows `step(engine, user_input)` after preview to apply the same input.

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/_util.py

@@ -2,10 +2,14 @@ import json
 from typing import Any, Literal
 
 from context_compiler import (
-    DECISION_CLARIFY,
-    DECISION_UPDATE,
+    POLICY_PROHIBIT,
+    POLICY_USE,
+    get_clarify_prompt,
+    get_decision_state,
     get_policy_items,
     get_premise_value,
+    is_clarify,
+    is_update,
 )
 
 
@@ -28,22 +32,21 @@ def print_state_summary(state: Any, label: str = "state") -> None:
 
     print(f"{label}:")
     print(f"- premise: {premise_text}")
-    print(f"- use policies: {_format_policy_values(state, 'use')}")
-    print(f"- prohibit policies: {_format_policy_values(state, 'prohibit')}")
+    print(f"- use policies: {_format_policy_values(state, POLICY_USE)}")
+    print(f"- prohibit policies: {_format_policy_values(state, POLICY_PROHIBIT)}")
 
 
 def print_decision_summary(decision: Any) -> None:
-    kind = decision.get("kind")
-    if kind == DECISION_UPDATE:
+    if is_update(decision):
         print("result: updated")
-        state = decision.get("state")
+        state = get_decision_state(decision)
         assert isinstance(state, dict)
         print_state_summary(state, "compiled state")
         return
 
-    if kind == DECISION_CLARIFY:
+    if is_clarify(decision):
         print("result: clarify")
-        prompt = decision.get("prompt_to_user")
+        prompt = get_clarify_prompt(decision)
         if isinstance(prompt, str) and prompt:
             print("clarify prompt:")
             for line in prompt.splitlines():

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/integrations/README.md

@@ -17,7 +17,7 @@ export OPENAI_API_KEY=...
 export PROVIDER=openai
 ```
 
-Checkpoint continuation in these integration examples requires `context-compiler>=0.6.14`.
+Checkpoint continuation in these integration examples requires `context-compiler>=0.7.0`.
 
 ### Run
 
@@ -29,7 +29,7 @@ See the LiteLLM examples README for setup and usage:
 - Context Compiler runs before each LLM call.
 - If result is `clarify`, show the question and do not call the LLM.
 - If result is `passthrough`, send normal user input.
-- If result is `update`, use updated state and call the model with saved state added to the prompt.
+- If result is `update`, use updated state and call the model with saved state in the prompt.
 
 ## LiteLLM Proxy
 

{context_compiler-0.7.2 → context_compiler-0.7.4}/examples/integrations/litellm/README.md

@@ -105,7 +105,7 @@ Use `llama` only for LLM-only preprocessing with Llama-family models.
 
 ## Usage pattern
 
-These files are importable integration references for host applications.
+You can import these files as integration references in host applications.
 
 - Import `handle_turn(...)` from either `basic.py` or `with_preprocessor.py`.
 - Create and retain an engine instance in host/session state.