docs: replace empty "boundary" labels with the concrete role

"is the XDR/K-execution boundary" named no fact the reader could use.
State what each component actually does instead: TransactionEncoder
decodes Stellar's binary XDR (the wire format K cannot read);
NodeInterpreter runs request envelopes through the K semantics. Applied
across the architecture/interpreter/transaction docs and the matching
class docstrings.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: RaoulSchaffranek

docs/architecture.md

@@ -45,15 +45,15 @@ The server implements six RPC methods — `getHealth`, `getNetwork`, `getLatestL
 
 ### `transaction.py` — `TransactionEncoder`
 
-`TransactionEncoder` is the XDR boundary. It decodes a `stellar_sdk` transaction envelope into a JSON request envelope containing the RPC method, the transaction hash, the envelope XDR, and the decoded operations as JSON "steps". For the one case K cannot consume as JSON — a wasm upload, whose `ModuleDecl` has no JSON form — it produces the kasmer steps in K-AST form for direct injection into the `<program>` cell.
+`TransactionEncoder` decodes Stellar's binary XDR, the wire format K cannot read. It turns a `stellar_sdk` transaction envelope into a JSON request envelope containing the RPC method, the transaction hash, the envelope XDR, and the decoded operations as JSON "steps". For the one case K cannot consume as JSON — a wasm upload, whose `ModuleDecl` has no JSON form — it produces the kasmer steps in K-AST form for direct injection into the `<program>` cell.
 
 → **[Detailed documentation](transaction.md)**
 
 ---
 
 ### `interpreter.py` — `NodeInterpreter`
 
-`NodeInterpreter` is the K-execution boundary. It builds the initial configuration, runs a request envelope through the LLVM interpreter against `state.kore`, and persists the resulting state. It knows nothing about Stellar. It performs **no** whole-configuration `kast`↔`kore` conversions — the initial config is built directly in KORE and request steps are spliced into the `<program>` cell at the KORE level.
+`NodeInterpreter` runs request envelopes through the K semantics. It builds the initial configuration, feeds a request envelope to the LLVM interpreter against `state.kore`, and persists the resulting state. It knows nothing about Stellar. It performs **no** whole-configuration `kast`↔`kore` conversions — the initial config is built directly in KORE and request steps are spliced into the `<program>` cell at the KORE level.
 
 → **[Detailed documentation](interpreter.md)**
 

docs/interpreter.md

@@ -1,6 +1,6 @@
 # `interpreter.py` — `NodeInterpreter`
 
-`NodeInterpreter` is the K-execution boundary of komet-node. It builds the initial configuration, runs RPC request envelopes through the compiled K semantics with the LLVM backend, and persists the resulting world state. It knows nothing about Stellar — XDR decoding lives in [`TransactionEncoder`](transaction.md), and RPC dispatch / bookkeeping / response formatting live in [`node.md`](node-semantics.md).
+`NodeInterpreter` runs komet-node's RPC requests through the compiled K semantics (LLVM backend). It builds the initial configuration, feeds each request envelope to the interpreter against `state.kore`, and persists the resulting world state. It knows nothing about Stellar — XDR decoding lives in [`TransactionEncoder`](transaction.md), and RPC dispatch / bookkeeping / response formatting live in [`node.md`](node-semantics.md).
 
 ---
 

docs/transaction.md

@@ -1,6 +1,6 @@
 # `transaction.py` — `TransactionEncoder`
 
-`TransactionEncoder` is the XDR boundary of komet-node — the part the K semantics cannot cross. It decodes a Stellar transaction envelope into the JSON *request envelope* consumed by [`node.md`](node-semantics.md), computes the transaction hash and contract ids, and (for wasm uploads only) parses the bytecode into a `ModuleDecl`.
+`TransactionEncoder` decodes Stellar's binary XDR, the wire format the K semantics cannot read. It turns a transaction envelope into the JSON *request envelope* consumed by [`node.md`](node-semantics.md), computes the transaction hash and contract ids, and (for wasm uploads only) parses the bytecode into a `ModuleDecl`.
 
 ---
 

src/komet_node/interpreter.py

@@ -82,7 +82,7 @@ class NodeInterpreter:
     """
     Runs the K node semantics against a saved KORE world-state configuration.
 
-    This is purely the K-execution boundary: it builds the initial configuration, runs RPC
+    Its sole responsibility is K execution: it builds the initial configuration, runs RPC
     request envelopes through the LLVM interpreter, and persists the resulting state. It
     knows nothing about Stellar — XDR decoding lives in :class:`TransactionEncoder`, and RPC
     dispatch / bookkeeping / response formatting live in ``node.md``.

src/komet_node/transaction.py

@@ -40,7 +40,7 @@ class TransactionEncoder:
     """
     Decodes Stellar XDR transactions into the request envelope consumed by ``node.md``.
 
-    This is the boundary K cannot cross: parsing the XDR envelope, computing the
+    It performs the work K cannot do itself: parsing the XDR envelope, computing the
     transaction hash and contract ids, and (for wasm uploads) parsing the bytecode into a
     ``ModuleDecl`` via ``wasm2kast``. It produces a JSON request envelope and, only for the
     wasm-upload case, the kasmer steps to inject into the ``<program>`` cell.