灵珑·涅槃

[knight6236]

Welcome to LingFrame V0.3.0.

This release is not about adding another batch of isolated features. It is about converging governance capabilities that were previously scattered across multiple invocation paths into a reusable, explainable, evolvable runtime kernel.

The core theme of 0.3.0 can be summarized in four words:

• Unify: unify the governance execution spine
• Converge: converge runtime state ownership
• Reuse: reuse the same kernel across Web, Bean, and Dashboard paths
• Stabilize: bring unload, cleanup, and leak diagnostics into long-running runtime responsibilities

Key Highlights

1. The unified governance pipeline is now formally in place

InvocationPipelineEngine and FilterRegistry now form the formal governance execution spine of LingFrame. Calls pass through fixed phases in order:

• TrafficMetricsFilter
• MacroStateGuardFilter
• CanaryRoutingFilter
• ResilienceGovernanceFilter
• ContextIsolationFilter
• GovernanceDecisionFilter
• PermissionGovernanceFilter
• ThreadIsolationGovernanceFilter
• TerminalInvokerFilter

This means routing, resilience governance, context isolation, permission decisions, thread isolation, and terminal invocation are no longer scattered across multiple logic paths. They are now organized into a formal chain with validated order, explainable behavior, and reuse across multiple entry points.

2. The dual-state runtime model is now a formal structure

0.3.0 formally converges runtime state into two layers:

• Instance layer: InstanceStatus describes the lifecycle of a single LingInstance from CREATED to DEAD, written exclusively by InstanceCoordinator
• Runtime layer: RuntimeStatus describes the macro availability of one ling from the LingCore perspective, aggregated by RuntimeCoordinator after subscribing to instance facts

This change makes it much clearer who may write state, how state changes are linked, and when macro runtime conclusions are produced.

3. Lifecycle orchestration has become an explicit capability

DefaultLingLifecycleEngine is no longer just a helper around “hot swap.” It is now the real top-level lifecycle orchestrator:

• runtime registration happens before the first instance facts appear
• deploy drives an instance through LOADING -> STARTING -> READY
• reload uses a side-by-side replacement path: deploy the new instance, cut over traffic, then unload the old one
• unload first marks the instance as STOPPING, waits for in-flight requests to drain, and only then proceeds with cleanup

This gives 0.3.0 a much clearer operational boundary for long-running systems than earlier “hot swap exists” messaging.

4. The same kernel now serves more governance entry points

The governance kernel is no longer limited to standard ling-to-ling invocation:

• Spring Boot 2 / 3 LingWebGovernanceFilter borrows the same pipeline through GOVERN_ONLY
• LingCoreBeanGovernanceInterceptor lets LingCore bean invocation reuse the same governance capabilities
• Dashboard SimulateService runs the real governance chain through SIMULATION instead of maintaining a shadow ruleset

This means the explanations seen by the control surface remain aligned with real runtime governance results.

5. The dashboard is now built on real runtime facts

The governance control surface in 0.3.0 is now increasingly built on real kernel events:

• simulated calls retain EngineTrace
• the event bus publishes trace, audit, circuit-breaker, lifecycle, and leak-detection events
• LogStreamService continuously pushes these events to the control surface through SSE

Canary routing, simulation, lifecycle visibility, and event streaming are now increasingly built around the same runtime facts.

6. Long-running stability is now formally part of runtime responsibility

LingFrame now treats unload and cleanup as part of the runtime contract itself:

• governance resources and method caches held by the pipeline can be evicted during unload
• DefaultLeakDetector emits diagnostics through different strategies in dev mode and prod mode
• leak-detection results also enter the monitoring event stream

7. The Shared API bootstrap boundary is now written into the architecture

SharedApiManager makes startup order itself part of the architectural boundary:

• preload Shared API JARs or classes directories
• register shared package prefixes
• freeze the Shared API boundary
• only then load lings against that frozen contract view

This means a brand-new shared contract may still be introduced before freeze, but an already loaded shared contract still cannot be hot-updated or hot-unloaded in the same process; contract changes require a process restart.

Scope Delivered In 0.3.0

The current public delivery scope includes:

• unified governance pipeline
• dual-state runtime model
• explicit lifecycle orchestration
• dashboard simulation and event streaming
• web / bean governance entry points
• Shared API boundary freezing
• unload cleanup and leak diagnostics

---

This discussion was created from the release 灵珑·涅槃.