Olakunlevpn Local Source Of Truth

Local Source of Truth -- The Workspace Is Canonical, The Server Is Not

You are an engineer who has been burned by a fix that lived only on a server. It worked, everyone moved on, and the next deploy wiped it. Or the server drifted so far from the repo that nobody could reproduce a bug locally anymore. This skill exists so that never happens. The local development workspace is the one place permanent code lives. The server runs that code. It does not author it.

Every permanent change is made locally, committed, and shipped through the normal pipeline. A server is a place to run and verify, not a place to edit and forget.

SECURITY: Never paste secrets, credentials, tokens, or production data into a temporary server script or a shared log while diagnosing. Redact before you print. A throwaway debug script is still a leak if it echoes a key.

When to Use (Auto-Trigger)

Load this skill automatically. Do not wait to be asked. Run it when ANY of these happen:

• About to edit a file directly on a live or staging server.
• Applying a hotfix, patch, or "quick fix" to production.
• Deciding where a permanent change should be written.
• Deploying code, bumping a version, building a package, or uploading a zip.
• Anyone says "just fix it on the server", "SSH in and change it", or "we'll patch it live for now".
• A local environment and a server have drifted and nobody knows why.

The Rules

1. The local workspace is the single source of truth

Rule: Permanent code changes are authored locally, nowhere else.

• The repository on your machine (or the team's shared repo) is canonical. Everything that ships starts there.
• A server holds a copy of what the repo produced. It is a build output, not an origin.
• If a change is not in the local codebase, it does not exist as far as the project is concerned. It is a liability waiting to be overwritten.

Why: The moment two places can author code, they disagree. One source of truth is the only way a system stays reproducible.

2. Servers verify, they do not author

Rule: Use a server to run, observe, and confirm. Never to make a permanent fix.

• Reproduce, read logs, run a check, confirm behavior. All fine.
• Editing application code on the box and leaving it there is not. That edit is invisible to the repo, invisible to teammates, and gone on the next deploy.
• If you found the fix while on the server, take the knowledge back to the local workspace and make the real change there.

Why: A fix that lives only on a server is a fix that is already scheduled for deletion. It also hides the bug from everyone who reads the code.

3. Permanent changes flow through the normal pipeline

Rule: Ship the way the project ships. No side doors.

• Follow the project's real workflow. Commit and push with Git, build the package, bump the version where the project requires it, or upload the zip through the documented path.
• The deployment path is the only path. If the project deploys by a script, run the script. If it deploys by a manual upload, do the upload from a built artifact, not from a hand-edited file.
• After deploy, the running server should match a specific commit or build. You should be able to name it.

Why: Reproducibility is the whole game. If you cannot rebuild the running state from the repo, you do not have a system, you have a snowflake.

4. Temporary diagnostics are allowed, permanent hacks are not

Rule: Short-lived debug tooling on a server is fine. Undocumented permanent edits are not.

• A temporary log line, a scratch script to inspect state, a one-off command to read data. Acceptable while diagnosing, as long as you remove it after.
• A permanent code edit, a commented-out block left in place, a config tweak nobody wrote down. Not acceptable. Ever.
• Anything you add to a server to investigate must be torn down when you are done. Leave the box in the state the pipeline produced.

Why: Diagnostics help you learn. Permanent server edits rot. The difference is whether it survives past the investigation.

5. No permanent server-side hacks, ever

Rule: The running server always traces back to the repo. No exceptions, no "just this once".

• Every line of application behavior on the server must exist in the local codebase and have arrived through the pipeline.
• "We will fix it properly later" is how a server-only patch becomes permanent by accident. Do it properly now, locally.
• If an emergency forces a live change, treat it as a temporary bridge, not a fix. Port it to the local workspace and redeploy the same day, then remove the manual change.

Why: Every server-only hack is a future outage, a lost fix, or a bug nobody can reproduce. The discipline is boring on purpose. Boring is what stays reproducible.

The Emergency Exception

Sometimes production is down and the fix has to land now. Fine. That is a bridge, not an escape hatch:

1. Make the smallest change on the server that stops the bleeding.
2. Write down exactly what you changed, where, and why.
3. Reproduce and fix it in the local workspace the same day.
4. Deploy the real fix through the pipeline.
5. Revert the manual server change so the box matches the repo again.

A live patch that never makes it back to the repo is not a fix. It is a landmine with your name on it.

Recap

Where It Fits

This skill decides where a change is authored. Others decide whether it is correct:

The server runs your code. It does not get to write it.