Skip to main content

Nothing Is Rebuilt Because Nothing Is Forgotten

Most custom software is quoted as though nothing like it had ever been built before, and the customer pays a second time for thinking that was finished years ago.

Three things carry from one build to the next, and none is made again for each customer: what a trade actually needs from its software, the way that software gets built, and the way the work is run. All three are kept current on purpose, refreshed in a maintenance pass in August 2026 rather than left to whoever happens to remember them.

A problem solved once is not solved twice. A sign-in failure that still blocks several large vendors’ own products was diagnosed here once, and every build since has inherited the fix instead of losing a week to it. Hours not spent re-laying foundations are hours that never reach the invoice.

The Picture That Draws Itself

Architecture drawings age the moment they are exported to an image. A picture drawn by hand is out of date the day after it is drawn, and nobody defends a system they cannot see.

The diagram in the portal is generated from what is actually deployed, so it cannot disagree with reality. Every box is a real running thing. Clicking one shows where it runs, which address serves it and which data it uses. The live copy and the candidate copy both appear, so the path from one to the other is visible rather than described in a document.

The customer gets this as their own portal, not a screenshot in a report. Six views cover what is deployed, whether it is healthy and what it cost. The heavy part of the picture only loads when someone opens it, so the page stays fast for everyone else.

What Has Not Been Checked Is Named, Not Left Blank

A passing test proves only what somebody thought to check for, and everything never checked stays invisible. That invisible remainder is the part worth knowing. A green light covering only what someone remembered to measure is worse than no light at all.

The quality view reads results from what the checks actually produced, not from a claim typed into a document, and shows a failure as a failure. It presents two lists: what has been verified, and what has not been covered. The second is built by comparing what was checked against everything that exists. Where nothing was measured, the view states that and gives the reason rather than showing a zero that looks the same as a pass.

A record states, for five data files, where every figure came from. A weekly automatic check raises one prioritised improvement, so the list stays short enough to read.

10 days
from first commit to a working, secured management system
2
copies compared automatically: what is on preview against what is live
6
views in the customer's own portal, from what runs to what it cost
1
prioritised improvement raised by the weekly check, every week

Governing the Agentic Estate

See the Whole Estate 3 steps
01

Compare the Skill, Not Its Top File

A hand-kept note of which repository carries which version of a convention skill goes stale faster than the skills it tracks, and a top-level file comparison happily reports a skill as identical while a reference leaf beneath it has already diverged. Every skill, agent and command is fingerprinted with a recursive content hash instead, so the comparison covers a skill and everything under it. Status is computed rather than declared, in four values: identical, ahead, behind, diverged.
02

A Repository Nobody Cloned Still Drifts

An inventory limited to the checkouts on one machine cannot see a repository that is not cloned there, so its drift stays invisible until an agent session runs against it. Registered scopes therefore cover the global user scope, local repositories, and repositories scanned straight from GitHub rather than only local disk. GitHub scanning arrived in June 2026 alongside the deployment pipeline. What gets compared is the estate that exists, not the part of it sitting on the current laptop.
03

Locate the Divergence at the File

A repository-level verdict says something is wrong without saying what to fix, which usually ends with somebody copying a whole skill folder across and hoping. Asset ancestry renders master skills, subskills and reference leaves as a depth-three hover tree with connector lines and a status chip on every node, plus a meta chip bar carrying type, status, reference count, linked assets and scope count. The file that diverged is named, so the fix is one leaf rather than a directory.
Reconcile Without Breaking It 3 steps
04

Sync One Asset, Not the Whole Repository

A sweeping repository-wide sync overwrites the copy somebody deliberately moved ahead, and then costs more than the drift it fixed. Three operations run per asset instead: push sends the current version outward, pull takes a newer version in, and adopt brings an unmanaged copy under the inventory. One diverged skill is resolved without touching anything around it, and a repository that is ahead on purpose stays ahead until someone decides otherwise.
05

Write the Backup Before the Overwrite

An unattended sync is only worth having if a bad one can be undone, and most tooling writes the file first and apologises afterwards. A timestamped backup is written before any file is overwritten, and a diff view shows what will change before it changes. That ordering is what makes the operation something an agent can be trusted to run without a person watching, because the previous version is already on disk when the write lands.
06

Let the Sessions Manage Their Own Tooling

Governance that exists only in a human interface cannot be acted on by the sessions actually causing and suffering the drift. The same inventory and sync operations are served as three MCP tools, harness_inventory, harness_asset and harness_sync, over an HTTP endpoint at /mcp under the same Microsoft Entra ID protected access as the interface. A Claude Code session asks which repositories lack the latest angular-conventions skill and fixes them through harness_sync without opening the dashboard.
Watch What Is Running 2 steps
07

Show Whether the Slot Answers, Not Whether It Deployed

A card reporting the last successful deploy reads as up while the slot is down, and asking the operator is otherwise the only way anyone finds out. Live per-application runtime health shipped on 2026-07-31, backed by /health and /about endpoints on every slot carrying deployment info, so a card reflects an actual response. Six deep-linkable routed views cover the estate, so a specific slot goes to a colleague as a link rather than as the dashboard, then click twice.
08

Preview Against Production, as a Drift Report

Nobody compares two environments by hand, so the difference gets found by an outage. Every setting is compared per application component across both slots, and each difference is classified as intended design or as drift, which keeps the list holding real disagreements instead of filling with deliberate ones and being ignored. Secrets appear as names and locations, never as values. The same list carries a stale manifest, or a DNS record pointing at a box no longer owned.
Turn the Chore Into a Skill 2 steps
09

An Unattended Audit That Cannot Flood the Tracker

Repository hygiene and on-page decay belong to everyone, which means they belong to nobody, and a report nobody opens does not change that. A weekly agentic workflow, compiled by gh-aw into a locked workflow file, collects Core Web Vitals and on-page SEO signals for the production pages through Google PageSpeed Insights and files one prioritized improvement issue. It runs under read-only repository permissions, an explicit network allowlist and a capped safe output.
10

Package the Chore With Its Hard Rules

The documentation a newcomer reads is the first thing to rot once a chore belongs to nobody in particular. A named skill regenerates a repository README from the repository itself: what it is, its deployment diagram, its addresses per environment or slot, its databases and its authentication. Two hard rules keep it honest, discover and never invent, with unknown values written as TBD, and never emit a secret, naming the git-ignored file instead of the value.

Frequently Asked Questions

How does the tool know a skill has drifted?
By fingerprinting it with a recursive content hash, so the comparison covers the skill and every reference leaf beneath it, not just a top-level file. Each registered scope then reads identical, ahead, behind or diverged, computed on the spot rather than declared in a list somebody has to maintain. Scopes cover the global user scope, local repositories, and repositories scanned straight from GitHub.
What stops a sync from making things worse?
Three things. Operations run per asset, so a single diverged skill is resolved without touching what sits around it. A diff view shows what will change before it changes. And a timestamped backup is written before any file is overwritten, so a bad sync is reversible rather than final. Push, pull and adopt cover sending a version outward, taking a newer one in, and bringing an unmanaged copy under the inventory.
Can an agent do this without a person opening a dashboard?
Yes, and that is the point, because the agent sessions are the ones causing and suffering the drift. Three MCP tools, harness_inventory, harness_asset and harness_sync, are served over an HTTP endpoint at /mcp under the same Microsoft Entra ID protected access as the interface. A Claude Code session asks which repositories lack the latest conventions skill and syncs them in the same conversation.
What does the operations side of the estate show?
Six deep-linkable routed views. Live per-application health backed by /health and /about endpoints on every slot, so a card reflects an actual response rather than a past deploy. A clickable deployment diagram built from the deployment manifests. Preview against production as a drift report, with each difference classified as intended design or drift and secrets shown as names and locations. And a quality view that names the untested surfaces as gaps.