Expand description
§Fase 118.b.2 — the flow-execution RESULT, in a module that reaches nothing.
THE THIRD INSTANCE OF THE SMELL, and the largest so far. AXON_VERSION
(§118.a.1) lived in the flow executor; IngestProvenance (§118.b.1) lived in
the OOXML reader; ServerExecutionResult and EnforcementSummaryWire lived
in axon_server.rs — 29,734 lines of axum router. Same shape every time: a
general concept parked in the specific module that first needed it, silently
chaining everything downstream to that module’s dependencies.
What it chained here was not a leaf. ServerExecutionResult is the input of
crate::wire_envelope::FlowEnvelope::from_execution_result (§39.b), and
EnforcementSummaryWire is threaded through flow_dispatcher,
flow_dispatcher::pure_shape and streaming_via_dispatcher — the core
execution path. So axon run, which opens no socket, could not compile
without the HTTP server, for two structs that contain no HTTP: eight counters,
a policy slug, and an aggregation of step names and token totals.
Neither type is server-specific. server_execute was simply the first caller
to need a place to put the answer. The name ServerExecutionResult is kept
verbatim — it is crate-public since §39.b and named by
tests/fase39b_wire_envelope_integration.rs and
tests/fase39c_epistemic_ownership_integration.rs — and axon_server
re-exports both, so every existing call site (including axon-enterprise,
which consumes axon::axon_server::ServerExecutionResult) keeps resolving.
This module must never acquire a dependency. Its whole value is that the execution path can name its own result type without linking a web framework.
Structs§
- Enforcement
Summary Wire - §Fase 33.x.d — Wire-serializable mirror of
crate::stream_effect_dispatcher::EnforcementSummarypublished onaxon.completeper the D2 contract. - Server
Execution Result - Server-side execution result.