Spring Lens is a runtime control plane for Spring Boot applications. It gives coding agents a structured way to inspect live behavior, ask high-value runtime questions, and turn findings into reviewable remediation workflows.
Most coding agents can read source code well. They are much weaker at answering the harder questions that only show up at runtime:
- What actually happened in this request?
- Which SQL call was slow?
- What state was present when the exception was thrown?
- Is this service carrying concurrency or retention risks that are not obvious in a code diff?
Spring Lens addresses that gap by exposing runtime truth as:
- execution graphs instead of log archaeology
- task-oriented tools instead of raw bean dumps
- governed remediation flows instead of ad hoc instrumentation
flowchart LR
Agent["Coding agent<br/>Codex / Cursor / CloudCode"] --> MCP["Spring Lens server<br/>MCP tools + control plane"]
MCP --> Runtime["Spring Boot app<br/>spring-lens-starter"]
Runtime --> Graph["ExecutionGraph<br/>runtime truth"]
Runtime --> Safety["Runtime safety inspector"]
Safety --> MCP
MCP --> Overlay["Overlay + patch drafts"]
Overlay --> Agent
-
Build and test the workspace.
mvn test -
Start the control plane.
mvn -f spring-lens-server/pom.xml spring-boot:run
-
Start the demo application and register it with the control plane.
mvn -pl spring-lens-demo-app -am clean install -DskipTests "-Dspring-boot.repackage.skip=true" mvn -f spring-lens-demo-app/pom.xml spring-boot:run "-Dspring-boot.run.arguments=--server.port=8081 --spring.lens.registration-enabled=true --spring.lens.server-url=http://localhost:8090 --spring.lens.runtime-base-url=http://localhost:8081"
The clearest end-to-end flow in the current repository is:
-
Trigger a request against the demo app.
GET http://localhost:8081/orders/fail -
Inspect runtime safety in the live application.
inspect_runtime_safety -
Draft remediation from those findings.
draft_runtime_safety_remediation -
Promote the reviewed remediation into the control plane.
promote_runtime_safety_remediation
That flow is what makes Spring Lens different from a debugging helper. It connects live runtime evidence to a governed remediation path.
- Inspect real request behavior through execution graphs.
- Pull slow SQL and exception context without adding one-off debug endpoints.
- Expose project-specific runtime tools through SPI and
@LensTool. - Detect runtime safety issues before proposing concurrency-related fixes.
- Turn findings into reviewable overlay and patch drafts.
spring-lens-modelShared runtime graph model and transport DTOs.spring-lens-spiSPI contracts for collectors, capabilities, tools, and playbooks.spring-lens-runtimeExecution graph assembly and built-in runtime collectors.spring-lens-starterDefault application-side starter for runtime truth and AI-facing tools.spring-lens-agent-contractShared contracts for overlays, patch drafts, and instrumentation governance.spring-lens-agent-starterHigher-trust extension for overlay sync and future instrumentation control.spring-lens-serverExternal control plane, tool router, MCP surface, and governance flows.spring-lens-demo-appRunnable H2-backed demo application used by tests and demos.
Runtime and diagnosis:
list_registered_appsget_slow_sqlget_exception_contextget_execution_graphdiagnose_execution_graphget_diagnostic_playbooklist_runtime_toolsinvoke_runtime_toolquery_probe_valuesinspect_runtime_safetyplan_runtime_safety_remediation
Control plane:
get_policy_snapshotlist_active_overlayslist_patch_draftsapply_overlay_instrumentationapprove_overlay_instrumentationdisable_overlay_instrumentationlist_audit_eventsdraft_runtime_safety_remediationpromote_runtime_safety_remediation
Spring Lens includes repository-local onboarding material for editor and agent workflows:
- Codex integration guide
- CloudCode integration guide
- Skills overview
- Codex runtime safety skill
- CloudCode runtime safety guidance