The Gap Between Code and Deployment: A User's Two-Line Reality Check

In the middle of an intense debugging and feature-building session for a horizontally scalable S3 architecture, a single user message landed with surgical precision:

Latency chart: Rename SLA to SLO, set at 350ms. Don't see layout fixes nor IO chart, not deployed?

Seven words of request, eleven words of observation. Together, they exposed a fundamental gap in the development pipeline that the assistant had been operating under for several messages. The message is remarkable not for its length—it is barely a sentence—but for the depth of what it reveals about the collaborative debugging process, the assumptions embedded in continuous development workflows, and the critical difference between writing code and shipping code.

Context: The State of Play

To understand this message, one must understand what preceded it. The assistant had been building a comprehensive cluster monitoring dashboard for a distributed S3 storage system composed of stateless S3 frontend proxies and Kuri storage nodes backed by YugabyteDB. The previous message (index 801) was a triumphant summary from the assistant, listing a litany of improvements:

• Backend changes: I/O throughput tracking with a new IOThroughputHistory type, byte tracking in RecordRead() and RecordWrite(), a new IOThroughput RPC method, and updates to the ClusterTopology endpoint to include live storage statistics.
• Frontend changes: A brand-new IOThroughputChart.js component showing bytes-per-second for reads, writes, and totals; an improved ClusterTopology.js visualization with distinct blue/green color coding for proxies versus storage nodes, gradient backgrounds, status indicator rings, and layer labels; a restructured Cluster.js layout with a two-column grid; and responsive CSS breakpoints.
• Verification: The assistant had run docker build, restarted containers, and used websocat to query RPC endpoints, confirming that both Kuri nodes were reporting metrics like storageUsed, groupsCount, requestsPerSecond, and I/O byte data. The summary painted a picture of completion. The assistant seemed satisfied that the cluster monitoring dashboard was "fully functional." But the user, looking at the actual deployed interface, saw something different: no layout fixes, no IO chart. The changes existed in source code but not in the running system.

The Core Problem: The Build Pipeline Blind Spot

The user's question—"not deployed?"—cut to the heart of the issue. The assistant had made a critical assumption: that rebuilding the Docker image with docker build -t fgw:local . would automatically pick up the React frontend changes. But the Docker build process for this project uses a multi-stage build that copies pre-compiled React assets from a build/ directory. The assistant had edited the React source files (.js and .css files in src/) but had never run npm run build to compile them into the static bundle that the Dockerfile actually copies.

This is a classic pipeline failure. The assistant's mental model of the build process was incomplete: it assumed that docker build would somehow trigger the React build, or that the source files were directly served. In reality, the React app must be compiled into optimized static assets (JavaScript bundles, CSS files) before being embedded in the Docker image. Without the explicit npm run build step, the Docker image contained the old frontend, and all the layout fixes, IO chart, and CSS improvements existed only as source files on disk—invisible to anyone accessing the web UI at localhost:9010.

The user's observation was not just about missing features. It was a systems-thinking check: "I see the code changes you described, but the deployed system doesn't reflect them. Something is broken in your deployment process."## The SLA-to-SLO Request: A Domain Terminology Correction

The first part of the user's message—"Rename SLA to SLO, set at 350ms"—is a domain-specific terminology correction that carries significant weight. In the context of distributed storage systems, SLA (Service Level Agreement) and SLO (Service Level Objective) are distinct concepts with different implications.

An SLA is a contractual commitment between a service provider and a customer, typically with financial or legal consequences for breach. An SLO is an internal target—a goal the system aims to meet, but without the binding contractual force. By requesting the rename from SLA to SLO, the user was making a deliberate architectural statement: the latency threshold in the monitoring dashboard should represent an internal operational target, not a customer-facing contractual promise. The 350ms threshold (down from whatever the previous value was) further refined this target.

This is the kind of distinction that matters deeply in production systems. Calling an internal metric an "SLA" creates confusion about what commitments have actually been made to customers. It also sets false expectations: if an operator sees "SLA: 500ms" on a dashboard, they might assume there is a contractual obligation at that threshold, which could lead to unnecessary panic or, worse, complacency if the actual SLA is different. The user was cleaning up this ambiguity before it became embedded in the codebase.

The assistant's response to this request (visible in subsequent messages) was straightforward: read the LatencyDistributionChart.js file, find the relevant string, and replace it. But the user's request also implicitly asked why this hadn't been caught earlier—the latency chart was already deployed, and it was displaying the wrong terminology.

The Assumptions Embedded in the Assistant's Work

The subject message reveals several assumptions the assistant was operating under:

1. The build pipeline assumption: The assistant assumed that docker build would automatically incorporate frontend changes. This was incorrect because the React build step (npm run build) was not integrated into the Docker build process—it was a manual prerequisite that the assistant had skipped.
2. The verification assumption: The assistant had verified backend changes via websocat RPC calls and concluded the system was working. But backend RPC verification does not validate frontend rendering. The I/O throughput data was flowing to the RPC endpoint, but the React component that displays it was never compiled into the deployed image.
3. The "done" assumption: The assistant's summary message (index 801) declared the work complete with a list of changes. But completeness in source code is not the same as completeness in the deployed system. The user's message forced a re-evaluation of what "done" actually means.
4. The terminology assumption: The assistant had chosen "SLA" as the label for the latency threshold without considering whether it was the correct domain term. The user's correction to "SLO" reflects deeper domain knowledge about how service level targets are classified in production storage systems.

Input Knowledge Required

To fully understand this message, a reader needs:

• Knowledge of the project architecture: The horizontally scalable S3 system has three layers—S3 frontend proxies (stateless), Kuri storage nodes (stateful), and YugabyteDB (shared database). The monitoring dashboard displays metrics from all layers.
• Understanding of the build pipeline: The project uses a multi-stage Docker build that copies pre-built React assets. The React app is built separately with npm run build before the Docker image is created.
• Domain knowledge of SLO vs SLA: Understanding that SLOs are internal targets while SLAs are contractual commitments, and why the distinction matters in operational monitoring.
• Context of the previous work: The assistant had just implemented I/O throughput tracking, layout improvements, and topology visualization changes across multiple files.

Output Knowledge Created

This message created several important outputs:

1. A corrected latency chart: The "SLA" label was renamed to "SLO" with a 350ms threshold, making the monitoring dashboard more accurate from an operational standpoint.
2. A rebuilt React frontend: The assistant ran npm run build (message 803), which compiled the updated React source files into the static bundle that the Docker image actually uses.
3. A corrected mental model: The assistant learned that frontend changes require an explicit build step before Docker deployment—a lesson that would apply to all future work in this session.
4. A verification pattern: The user established that "I don't see it" is a valid and important form of verification. The assistant learned to check the deployed UI, not just the RPC responses.

The Thinking Process Revealed

The user's message is brief, but its structure reveals a clear thinking process:

1. Observation: The user looked at the deployed latency chart and saw "SLA" where "SLO" should be. This is a visual inspection of the running system.
2. Correction: The user provided the correct term and threshold in a single imperative sentence—concise, unambiguous, actionable.
3. Cross-checking: The user then looked for the other changes the assistant had described (layout fixes, IO chart) and found they were missing.
4. Hypothesis formation: The user connected the missing features to a deployment problem, asking "not deployed?" rather than "not implemented?"—a subtle but important distinction that shows systems-level thinking.
5. Confirmation request: The question mark at the end invites the assistant to confirm or explain, keeping the conversation collaborative rather than accusatory. This is the thinking of someone who understands both the code and the deployment process. The user didn't ask "did you implement the IO chart?"—they asked "is it deployed?" They knew the difference mattered.

Broader Implications

The subject message is a microcosm of a common pattern in software development: the gap between "it compiles" and "it works," or between "it's in source control" and "it's in production." The assistant had written code, verified backend APIs, and declared victory—but the user, looking at the actual running system, saw the gap immediately.

This message also illustrates the value of a user who tests the system as a whole rather than trusting developer summaries. The assistant's summary at message 801 was detailed and confident, but it was wrong about the deployment state. The user's two-line message corrected both the terminology and the deployment process in a single interaction.

The lesson is universal: source code is not the product. The deployed, running system is the product. And until changes are visible in the deployed system, they are not done.