context-compiler 0.8.3__tar.gz → 0.9.0.dev0__tar.gz

{context_compiler-0.8.3 → context_compiler-0.9.0.dev0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: context-compiler
-Version: 0.8.3
+Version: 0.9.0.dev0
 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
@@ -35,27 +35,30 @@ Description-Content-Type: text/markdown
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
 Context Compiler is a deterministic conversational state authority for LLM applications.
-It handles explicit state changes, clarification and confirmation flows,
-checkpoint restore, and structured authoritative state for the host.
+It handles canonical directive execution, semantic validation, deterministic
+clarify decisions, runtime semantic continuation boundaries, and structured authoritative state for
+the host.
 
 ## What Context Compiler provides
 
 Context Compiler gives hosts fixed state rules:
 
-- handle explicit user state changes with deterministic rules
+- handle canonical explicit state changes with deterministic rules
 - clarification instead of silent overwrite for blocked/ambiguous changes
-- pending confirmation flows that must resolve before anything else changes
-- export and import checkpoints to restore saved state and pending confirmation flow
+- preserve supported pending continuation when explicit confirmation is required
+- export and import authoritative state for host-managed persistence
 - produce structured authoritative state for downstream host decisions
 
 The model generates responses. The compiler owns state.
+Human-facing normalization, malformed-input recovery, and intent drafting belong
+outside core.
 
 ## How the compiler metaphor works
 
-Like a compiler, it parses input, validates it, applies fixed rules, and
+Like a compiler, it parses canonical directives, validates them, applies fixed rules, and
 produces a stable result the host can use. It treats important instructions as
 structured state instead of temporary prompt text. It is not source-code
-compilation and not a reasoning model.
+compilation, not a reasoning model, and not a natural-language repair layer.
 
 ## 10-Second Example
 
@@ -83,33 +86,52 @@ instead of relying on memory of earlier conversation text.
 
 Context Compiler makes state-change rules explicit so behavior stays repeatable.
 
-**Explicit directive**
+The architecture has three layers:
+
+- syntax classification decides whether input is a canonical directive, invalid
+  directive-shaped syntax, or ordinary passthrough
+- semantic evaluation decides whether a canonical directive updates state,
+  clarifies, or no-ops
+- semantic continuation optionally preserves a deterministic blocked transition
+  that needs explicit `yes` / `no`
+
+### Explicit directive
+
 ```text
 set premise concise replies
 ```
+
 - Base model: silently accepts / rewrites
 - Context Compiler: applies a repeatable state update
 
-**Single-directive grammar**
+### Single-directive grammar
+
 ```text
 use docker and prohibit peanuts
 ```
+
 - Without an authority layer: host/model behavior varies
-- Context Compiler: returns `clarify`, keeps authoritative state unchanged, and asks for separate directives
+- Context Compiler: treats this as invalid directive-shaped syntax, keeps authoritative state unchanged, and does not create pending continuation
+
+### State-dependent operation
 
-**State-dependent operation**
 ```text
 clear state
 use podman instead of docker
 ```
+
 - Without explicit state transition rules: behavior depends on host/model handling
-- Context Compiler: returns `clarify` before changing state
+- Context Compiler: applies the deterministic resulting transition when
+  `docker` is absent and `use podman` is otherwise valid; other semantic
+  conflicts may still clarify
+
+### Lifecycle enforcement
 
-**Lifecycle enforcement**
 ```text
 clear state
 change premise to formal tone
 ```
+
 - Without explicit transition checks: behavior depends on host/model handling
 - Context Compiler: asks for clarification and keeps saved state unchanged
 
@@ -171,7 +193,7 @@ For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 That companion repository shows enforcement points built on compiler state,
 including retrieval filtering, schema selection, tool gating, execution
-authorization, gateway middleware, checkpoint continuation, and prompt
+authorization, gateway middleware, runtime continuation handling, and prompt
 construction.
 
 ## Does it Work?
@@ -197,13 +219,13 @@ pip install context-compiler
 context-compiler
 ```
 
-Preload options keep saved rules separate from confirmation state in progress:
+Preload options load authoritative state:
+
 - `--initial-state-json` / `--initial-state-file` load saved state
   (via exported state JSON).
-- `--initial-checkpoint-json` / `--initial-checkpoint-file` restore full
-  continuation checkpoint (saved state + pending confirmation state).
 
 REPL commands (controller layer, not engine directives):
+
 - `state` shows current saved state.
 - `preview <input>` runs deterministic dry-run without mutating live state.
 - `step <input>` is an explicit alias of normal bare-input step behavior.
@@ -219,23 +241,25 @@ for non-interactive usage.
 context-compiler --json < input.txt
 ```
 
-Preload options keep saved rules separate from confirmation state in progress:
+Preload options load authoritative state:
+
 - `--initial-state-json` / `--initial-state-file` load saved state
   (via exported state JSON).
-- `--initial-checkpoint-json` / `--initial-checkpoint-file` restore full
-  continuation checkpoint (saved state + pending confirmation state).
 
 ## Installation
 
 Requirements:
+
 - Python 3.11+
 
 Install:
+
 ```bash
 pip install context-compiler
 ```
 
 Packaging notes:
+
 - Base install includes the core authority-layer engine and CLI.
 - Example and demo source files are available in the repository and source distribution.
 - To run the demos from this repository, clone the repo and install `context-compiler[demos]`.
@@ -261,11 +285,11 @@ class Decision(TypedDict):
 
 Meaning:
 
-| kind        | host behavior                                 |
-|:-----------:|-----------------------------------------------|
-| passthrough | forward user input to LLM                     |
-| update      | authoritative state mutated; host may call LLM with updated state |
-| clarify     | show `prompt_to_user` and do not call the LLM |
+| kind | host behavior |
+| --- | --- |
+| passthrough | forward user input to LLM |
+| 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 the exported decision helpers (`is_clarify`,
 `is_update`, `is_passthrough`, `get_clarify_prompt`, `get_decision_state`)
@@ -277,12 +301,11 @@ reference.
 Common API entry points:
 
 - engine lifecycle: `create_engine(...)`, `engine.step(...)`, `engine.state`,
-  `engine.has_pending_clarification()`
+  `engine.premise`, `engine.policies`, `engine.export_json(...)`,
+  `engine.import_json(...)`
 - decision helpers: `is_clarify(...)`, `is_update(...)`, `is_passthrough(...)`,
   `get_clarify_prompt(...)`, `get_decision_state(...)`
-- state helpers: `get_premise_value(...)`, `get_policy_items(...)`
-- state and checkpoint transport: `export_json(...)`, `import_json(...)`,
-  `export_checkpoint(...)`, `import_checkpoint(...)`
+- state transport: `engine.export_json(...)`, `engine.import_json(...)`
 - controller APIs: `preview(...)`, `step(...)`, `state_diff(...)`
 
 ### Controller API (Reusable Outside REPL)
@@ -312,12 +335,15 @@ authoritative in future turns.
 - Policies are per-item (`use` or `prohibit`)
 - State changes only through explicit directives
 - No inference or semantic reasoning
+- Non-canonical input normalization is outside the core state contract
 
 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.
+For live engine-owned reads, use `engine.premise` and `engine.policies`.
+`engine.policies` returns a caller-owned copy.
+
+`engine.state` remains the public snapshot/serialization boundary when host code
+needs the full authoritative state object.
 
 ---
 
@@ -359,23 +385,21 @@ Hosts define what policy items and premise mean in context. Common patterns incl
 Context Compiler enforces explicit directive and state rules. Domain reasoning
 still belongs to the host and model workflow.
 
----
-
-## Checkpoint Contract
+If a user says something non-canonical such as a near miss, alternate phrasing,
+or a failed replacement request that would need reinterpretation, that
+normalization is outside core and must happen before canonical directives reach
+the compiler.
 
-`export_json()` / `import_json()` and the checkpoint APIs serve different boundaries:
+---
 
-- `export_json()` / `import_json()` transport **authoritative state only**
-- checkpoint APIs transport **serialized continuation**:
-  - authoritative state
-  - pending confirmation flow state
+## Persistence Contract
 
-Use state JSON when you only need authoritative state. Use checkpoint APIs when
-you also need resumable continuation state across process or request
-boundaries.
+`export_json()` / `import_json()` are the current persistence boundary.
 
-For the checkpoint object shape, API-level usage notes, and serialization
-details, see [docs/api-reference.md](docs/api-reference.md#checkpoint-apis).
+- They transport **authoritative state only**
+- Hosts own any broader interaction or session workflow around that state
+- Pending continuation, if supported by the active engine contract, remains a
+  runtime semantic concept rather than a documented persisted artifact
 
 ---
 
@@ -401,6 +425,11 @@ Replacement:
 User: use podman instead of docker
 ```
 
+If `docker` is absent from saved state, that does not make the directive
+pending. The user's intended resulting state is still unambiguous, so the
+replacement follows the deterministic `use podman` transition when otherwise
+semantically valid.
+
 Removal and reset:
 
 ```text
@@ -410,9 +439,15 @@ User: clear state
 ```
 
 Grammar invariant: one input may contain at most one canonical directive.
-If another canonical directive start appears later in the same input, the
-input is invalid and Context Compiler returns `clarify` without mutating
-authoritative state or creating pending confirmation state.
+Directive-shaped invalid input is outside the canonical language, and
+`clarify` is reserved for canonical directives that later fail semantic
+evaluation against authoritative state.
+
+Pending continuation is a separate runtime layer. It may exist only after a
+canonical directive reaches a supported semantic `clarify` case. It never
+repairs malformed syntax or reinterprets non-canonical input as a directive.
+An absent source item in a canonical replacement directive is not, by itself,
+such a `clarify` case.
 
 Examples:
 
@@ -442,9 +477,8 @@ set premise "use docker and prohibit peanuts"
 Quotes do not create protected literal regions inside a recognized directive
 payload.
 
-Conflicting directives also trigger clarification instead of changing state.
-
-For full directive grammar and edge-case behavior, see [DirectiveGrammarSpec.md](docs/DirectiveGrammarSpec.md).
+For the normative grammar, classification rules, and syntax-versus-semantics
+boundary, see [DirectiveGrammarSpec.md](docs/DirectiveGrammarSpec.md).
 
 ---
 
@@ -465,6 +499,11 @@ allowed, when clarification is required, and how continuation state is
 restored. For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 
+Human-facing interpretation is a separate concern. If you want to recognize
+non-canonical phrasing, recover from malformed input, narrow user intent, or
+turn a failed replacement request into a different canonical directive, do that
+before calling core.
+
 **Why not just use a plain dict?**
 A plain dict can hold state for prompt construction, schema selection, tool
 gating, and other host behavior.
@@ -492,6 +531,7 @@ overwriting state.
 - Identical input sequences produce identical compiler state.
 - Model responses never modify compiler state.
 - Ambiguous directives trigger clarification instead of changing state.
+- Syntax errors never create pending continuation.
 
 Behavioral tests and Hypothesis-based property tests verify these invariants.
 
@@ -519,6 +559,10 @@ These docs cover the design and milestone details:
 [`tests/fixtures/`](tests/fixtures/) defines the cross-language conformance tests.
 These fixtures serve as the behavioral contract for compiler semantics across implementations.
 
+## Development Process
+
+Most of this project and related projects were implemented with Codex across many development sessions, including substantial implementation, refactoring, and cross-language porting work. ChatGPT was used separately for design discussion, review, and planning. Conformance harnesses and tests were used to verify behavioral consistency rather than treating model output as the correctness check.
+
 ---
 
 ## License

{context_compiler-0.8.3 → context_compiler-0.9.0.dev0}/README.md

@@ -5,27 +5,30 @@
 [![License](https://img.shields.io/pypi/l/context-compiler)](https://pypi.org/project/context-compiler/)
 
 Context Compiler is a deterministic conversational state authority for LLM applications.
-It handles explicit state changes, clarification and confirmation flows,
-checkpoint restore, and structured authoritative state for the host.
+It handles canonical directive execution, semantic validation, deterministic
+clarify decisions, runtime semantic continuation boundaries, and structured authoritative state for
+the host.
 
 ## What Context Compiler provides
 
 Context Compiler gives hosts fixed state rules:
 
-- handle explicit user state changes with deterministic rules
+- handle canonical explicit state changes with deterministic rules
 - clarification instead of silent overwrite for blocked/ambiguous changes
-- pending confirmation flows that must resolve before anything else changes
-- export and import checkpoints to restore saved state and pending confirmation flow
+- preserve supported pending continuation when explicit confirmation is required
+- export and import authoritative state for host-managed persistence
 - produce structured authoritative state for downstream host decisions
 
 The model generates responses. The compiler owns state.
+Human-facing normalization, malformed-input recovery, and intent drafting belong
+outside core.
 
 ## How the compiler metaphor works
 
-Like a compiler, it parses input, validates it, applies fixed rules, and
+Like a compiler, it parses canonical directives, validates them, applies fixed rules, and
 produces a stable result the host can use. It treats important instructions as
 structured state instead of temporary prompt text. It is not source-code
-compilation and not a reasoning model.
+compilation, not a reasoning model, and not a natural-language repair layer.
 
 ## 10-Second Example
 
@@ -53,33 +56,52 @@ instead of relying on memory of earlier conversation text.
 
 Context Compiler makes state-change rules explicit so behavior stays repeatable.
 
-**Explicit directive**
+The architecture has three layers:
+
+- syntax classification decides whether input is a canonical directive, invalid
+  directive-shaped syntax, or ordinary passthrough
+- semantic evaluation decides whether a canonical directive updates state,
+  clarifies, or no-ops
+- semantic continuation optionally preserves a deterministic blocked transition
+  that needs explicit `yes` / `no`
+
+### Explicit directive
+
 ```text
 set premise concise replies
 ```
+
 - Base model: silently accepts / rewrites
 - Context Compiler: applies a repeatable state update
 
-**Single-directive grammar**
+### Single-directive grammar
+
 ```text
 use docker and prohibit peanuts
 ```
+
 - Without an authority layer: host/model behavior varies
-- Context Compiler: returns `clarify`, keeps authoritative state unchanged, and asks for separate directives
+- Context Compiler: treats this as invalid directive-shaped syntax, keeps authoritative state unchanged, and does not create pending continuation
+
+### State-dependent operation
 
-**State-dependent operation**
 ```text
 clear state
 use podman instead of docker
 ```
+
 - Without explicit state transition rules: behavior depends on host/model handling
-- Context Compiler: returns `clarify` before changing state
+- Context Compiler: applies the deterministic resulting transition when
+  `docker` is absent and `use podman` is otherwise valid; other semantic
+  conflicts may still clarify
+
+### Lifecycle enforcement
 
-**Lifecycle enforcement**
 ```text
 clear state
 change premise to formal tone
 ```
+
 - Without explicit transition checks: behavior depends on host/model handling
 - Context Compiler: asks for clarification and keeps saved state unchanged
 
@@ -141,7 +163,7 @@ For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 That companion repository shows enforcement points built on compiler state,
 including retrieval filtering, schema selection, tool gating, execution
-authorization, gateway middleware, checkpoint continuation, and prompt
+authorization, gateway middleware, runtime continuation handling, and prompt
 construction.
 
 ## Does it Work?
@@ -167,13 +189,13 @@ pip install context-compiler
 context-compiler
 ```
 
-Preload options keep saved rules separate from confirmation state in progress:
+Preload options load authoritative state:
+
 - `--initial-state-json` / `--initial-state-file` load saved state
   (via exported state JSON).
-- `--initial-checkpoint-json` / `--initial-checkpoint-file` restore full
-  continuation checkpoint (saved state + pending confirmation state).
 
 REPL commands (controller layer, not engine directives):
+
 - `state` shows current saved state.
 - `preview <input>` runs deterministic dry-run without mutating live state.
 - `step <input>` is an explicit alias of normal bare-input step behavior.
@@ -189,23 +211,25 @@ for non-interactive usage.
 context-compiler --json < input.txt
 ```
 
-Preload options keep saved rules separate from confirmation state in progress:
+Preload options load authoritative state:
+
 - `--initial-state-json` / `--initial-state-file` load saved state
   (via exported state JSON).
-- `--initial-checkpoint-json` / `--initial-checkpoint-file` restore full
-  continuation checkpoint (saved state + pending confirmation state).
 
 ## Installation
 
 Requirements:
+
 - Python 3.11+
 
 Install:
+
 ```bash
 pip install context-compiler
 ```
 
 Packaging notes:
+
 - Base install includes the core authority-layer engine and CLI.
 - Example and demo source files are available in the repository and source distribution.
 - To run the demos from this repository, clone the repo and install `context-compiler[demos]`.
@@ -231,11 +255,11 @@ class Decision(TypedDict):
 
 Meaning:
 
-| kind        | host behavior                                 |
-|:-----------:|-----------------------------------------------|
-| passthrough | forward user input to LLM                     |
-| update      | authoritative state mutated; host may call LLM with updated state |
-| clarify     | show `prompt_to_user` and do not call the LLM |
+| kind | host behavior |
+| --- | --- |
+| passthrough | forward user input to LLM |
+| 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 the exported decision helpers (`is_clarify`,
 `is_update`, `is_passthrough`, `get_clarify_prompt`, `get_decision_state`)
@@ -247,12 +271,11 @@ reference.
 Common API entry points:
 
 - engine lifecycle: `create_engine(...)`, `engine.step(...)`, `engine.state`,
-  `engine.has_pending_clarification()`
+  `engine.premise`, `engine.policies`, `engine.export_json(...)`,
+  `engine.import_json(...)`
 - decision helpers: `is_clarify(...)`, `is_update(...)`, `is_passthrough(...)`,
   `get_clarify_prompt(...)`, `get_decision_state(...)`
-- state helpers: `get_premise_value(...)`, `get_policy_items(...)`
-- state and checkpoint transport: `export_json(...)`, `import_json(...)`,
-  `export_checkpoint(...)`, `import_checkpoint(...)`
+- state transport: `engine.export_json(...)`, `engine.import_json(...)`
 - controller APIs: `preview(...)`, `step(...)`, `state_diff(...)`
 
 ### Controller API (Reusable Outside REPL)
@@ -282,12 +305,15 @@ authoritative in future turns.
 - Policies are per-item (`use` or `prohibit`)
 - State changes only through explicit directives
 - No inference or semantic reasoning
+- Non-canonical input normalization is outside the core state contract
 
 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.
+For live engine-owned reads, use `engine.premise` and `engine.policies`.
+`engine.policies` returns a caller-owned copy.
+
+`engine.state` remains the public snapshot/serialization boundary when host code
+needs the full authoritative state object.
 
 ---
 
@@ -329,23 +355,21 @@ Hosts define what policy items and premise mean in context. Common patterns incl
 Context Compiler enforces explicit directive and state rules. Domain reasoning
 still belongs to the host and model workflow.
 
----
-
-## Checkpoint Contract
+If a user says something non-canonical such as a near miss, alternate phrasing,
+or a failed replacement request that would need reinterpretation, that
+normalization is outside core and must happen before canonical directives reach
+the compiler.
 
-`export_json()` / `import_json()` and the checkpoint APIs serve different boundaries:
+---
 
-- `export_json()` / `import_json()` transport **authoritative state only**
-- checkpoint APIs transport **serialized continuation**:
-  - authoritative state
-  - pending confirmation flow state
+## Persistence Contract
 
-Use state JSON when you only need authoritative state. Use checkpoint APIs when
-you also need resumable continuation state across process or request
-boundaries.
+`export_json()` / `import_json()` are the current persistence boundary.
 
-For the checkpoint object shape, API-level usage notes, and serialization
-details, see [docs/api-reference.md](docs/api-reference.md#checkpoint-apis).
+- They transport **authoritative state only**
+- Hosts own any broader interaction or session workflow around that state
+- Pending continuation, if supported by the active engine contract, remains a
+  runtime semantic concept rather than a documented persisted artifact
 
 ---
 
@@ -371,6 +395,11 @@ Replacement:
 User: use podman instead of docker
 ```
 
+If `docker` is absent from saved state, that does not make the directive
+pending. The user's intended resulting state is still unambiguous, so the
+replacement follows the deterministic `use podman` transition when otherwise
+semantically valid.
+
 Removal and reset:
 
 ```text
@@ -380,9 +409,15 @@ User: clear state
 ```
 
 Grammar invariant: one input may contain at most one canonical directive.
-If another canonical directive start appears later in the same input, the
-input is invalid and Context Compiler returns `clarify` without mutating
-authoritative state or creating pending confirmation state.
+Directive-shaped invalid input is outside the canonical language, and
+`clarify` is reserved for canonical directives that later fail semantic
+evaluation against authoritative state.
+
+Pending continuation is a separate runtime layer. It may exist only after a
+canonical directive reaches a supported semantic `clarify` case. It never
+repairs malformed syntax or reinterprets non-canonical input as a directive.
+An absent source item in a canonical replacement directive is not, by itself,
+such a `clarify` case.
 
 Examples:
 
@@ -412,9 +447,8 @@ set premise "use docker and prohibit peanuts"
 Quotes do not create protected literal regions inside a recognized directive
 payload.
 
-Conflicting directives also trigger clarification instead of changing state.
-
-For full directive grammar and edge-case behavior, see [DirectiveGrammarSpec.md](docs/DirectiveGrammarSpec.md).
+For the normative grammar, classification rules, and syntax-versus-semantics
+boundary, see [DirectiveGrammarSpec.md](docs/DirectiveGrammarSpec.md).
 
 ---
 
@@ -435,6 +469,11 @@ allowed, when clarification is required, and how continuation state is
 restored. For runnable application-layer examples, see
 [`context-compiler-example-integrations`](https://github.com/rlippmann/context-compiler-example-integrations).
 
+Human-facing interpretation is a separate concern. If you want to recognize
+non-canonical phrasing, recover from malformed input, narrow user intent, or
+turn a failed replacement request into a different canonical directive, do that
+before calling core.
+
 **Why not just use a plain dict?**
 A plain dict can hold state for prompt construction, schema selection, tool
 gating, and other host behavior.
@@ -462,6 +501,7 @@ overwriting state.
 - Identical input sequences produce identical compiler state.
 - Model responses never modify compiler state.
 - Ambiguous directives trigger clarification instead of changing state.
+- Syntax errors never create pending continuation.
 
 Behavioral tests and Hypothesis-based property tests verify these invariants.
 
@@ -489,6 +529,10 @@ These docs cover the design and milestone details:
 [`tests/fixtures/`](tests/fixtures/) defines the cross-language conformance tests.
 These fixtures serve as the behavioral contract for compiler semantics across implementations.
 
+## Development Process
+
+Most of this project and related projects were implemented with Codex across many development sessions, including substantial implementation, refactoring, and cross-language porting work. ChatGPT was used separately for design discussion, review, and planning. Conformance harnesses and tests were used to verify behavioral consistency rather than treating model output as the correctness check.
+
 ---
 
 ## License

{context_compiler-0.8.3 → context_compiler-0.9.0.dev0}/demos/05_llm_prompt_drift_vs_state.py

@@ -4,7 +4,7 @@ import argparse
 import re
 
 import demos.llm_client as llm_client
-from context_compiler import create_engine, get_premise_value
+from context_compiler import create_engine
 from demos.common import (
     build_baseline_messages,
     build_mediated_messages_from_transcript,
@@ -257,7 +257,7 @@ def _run_demo(turns: int = _DEFAULT_TURNS) -> None:
         compact_output = f"[no call] clarification required: {compacted_prompt}"
         print_model_output("Compiler-mediated + compact", compact_output)
     else:
-        premise_value = get_premise_value(compacted_state)
+        premise_value = compacted_state["premise"]
         if (
             premise_value is not None
             and _ORIGINAL_DIRECTIVE not in compacted_turns

{context_compiler-0.8.3 → context_compiler-0.9.0.dev0}/demos/06_llm_context_compaction.py

@@ -1,6 +1,6 @@
 """Demo 6: host-side prompt replacement from authoritative step-derived state."""
 
-from context_compiler import create_engine, get_premise_value
+from context_compiler import create_engine
 from demos.common import compact_user_turns, is_verbose, print_info_report
 
 DEMO_NAME = "06_context_compaction — superseded directives eliminated"
@@ -44,7 +44,7 @@ def _compile_premise(turns: list[str]) -> str:
     for turn in turns:
         decision = engine.step(turn)
         assert decision["kind"] == "update"
-    compiled_premise = get_premise_value(engine.state)
+    compiled_premise = engine.premise
     assert compiled_premise is not None
     return compiled_premise
 
@@ -149,7 +149,7 @@ def main() -> None:
     compiled_context = f"- premise: {compiled_premise}"
     compacted_turns, compacted_state, compacted_prompt = compact_user_turns(transcript_turns)
     assert compacted_prompt is None
-    assert get_premise_value(compacted_state) == FINAL_PREMISE
+    assert compacted_state["premise"] == FINAL_PREMISE
     compacted_context = "\n".join(f"User: {turn}" for turn in compacted_turns)
     baseline_prompt = _build_baseline_prompt(transcript_turns)
     compiled_prompt = _build_compiled_prompt(compiled_premise)