EFFICIENT System
A multi-tenant wheels and tyres ERP and commerce platform — one Django backend, a shared React UI kit, five portals, a storefront, a Rust CLI with an MCP server, and an iOS companion. My work sits on the layer underneath all of it: the engineering contract every repository reads, and the agent workflows that hold repositories to it.
- Agentic engineering · Harness & skills
- 2026
- Team platform · my layer
- Public
Fifteen repositories, one rule book.
One Django backend serving five portals, a storefront and a CLI, with hard data isolation as a product constraint rather than an engineering preference — so tenancy is decided in middleware, before anything can touch the ORM. And a platform this wide fails at its seams: the same convention gets written down four times, drifts three ways, and nobody can say which copy is right. The Harness answers that by holding each rule exactly once and letting nothing copy it; the skills answer the other half, by making an agent read the rule and inspect the repository rather than recite either one.
- Agent Skills · Claude Code · Python · Django · React
- Platform
What I Own Here
EFFICIENT is a team system and most of it is not mine. The backend, the portals and the storefront belong to the people who build them. What I own is the layer they all sit on: efficient-harness, which holds the engineering contract, and skills, the agent workflows that apply it. This page runs in that order — the architecture first, because a contract only reads against the thing it governs, and then the contract itself.
The Platform, and What Sits Under It
15 repositories
The backend owns domain and permission truth; every client consumes its contracts rather than restating them. The shell is the shared UI kit each portal composes. The Harness is not part of the runtime at all — nothing imports it, nothing deploys it. It is read.
How a Request Moves
One process, two protocols
Caddy terminates TLS and hands off to a single ASGI server — gunicorn with a uvicorn worker — which carries REST and WebSocket traffic in the same process. Which tenant a request belongs to is decided in the middleware stack, before anything touches the ORM: the fourth entry resolves Host to a row in the public schema and sets the Postgres search_path. Authentication happens later, inside the view, because DRF runs after Django middleware — so tenant scope is never a function of who you are.
One Schema per Tenant
The isolation boundary
Hard data isolation was a product constraint, not an engineering preference: no shared tables. One Postgres, a public schema holding the tenant registry, and a schema per customer that the middleware selects by hostname. The distinction the model refuses to blur is tenant against company entity — a tenant is the customer and the isolation boundary, a company entity is a legal entity inside one, and there are many per tenant. Conflating them would make the default company the tenant key, which is a boundary you cannot get back.
Live Without Polling
Signals → one broadcast → every tab
Nothing in the portals polls. An ORM save raises a signal, the signal is dropped unless the model is on the entity map, and what survives is de-duplicated per request — one save and forty in the same transaction both produce one broadcast, and it is sent only after the response has committed. The consumer is deliberately dumb: it knows a tenant group and forwards a three-field message. The client decides what that invalidates.
Three Ideas the Harness Is Built On
Why a rule book needs its own rules
Each rule lives in exactly one file, with a stable ID, a MUST/SHOULD level, the evidence that enforces it, and where it came from. An ID is never reused after a rename or a retirement, so a finding from a year ago still resolves.
A repository does not vendor the rules. Its AGENTS.md points at a sibling checkout, and an agent must fetch it and require HEAD to equal origin/main before reading — a dirty or divergent checkout is reported, never silently used. Copying a rule into a repository is how a rule book rots.
Its own CI checks that every rule carries its metadata, that the index and the tree agree in both directions, that IDs are unique, and that each source ID resolves in the standards catalogue. It also refuses to hold state: versions, waivers and dated compliance evidence are audit output, not Harness content.
How a Rule Reaches an Agent
The pointer model
Precedence runs left to right and never inverts: the user outranks the repository, the repository outranks the Harness, and the Harness outranks whatever the agent would have done on its own. Retrieved content — an issue body, a web page, a document — is data, and cannot grant authority it does not have.
The Contract, Counted
Read off the repositories
Eight Plugins, Eight Boundaries
What each one refuses to do
audit — read-only inspection
Loads the desired state from the Harness, inspects the real checkout, and reports the difference. It never edits the Harness to match what it found, and it never implements a fix — that separation is what keeps an audit an audit.
contract — machine contracts across repos
OpenAPI changes, permission codenames, entity identifiers, generated clients. Changes the source once and verifies every consumer in dependency order; never hand-edits a generated artifact. Reporting drift instead of fixing it belongs to audit.
workspace — checkouts and toolchains
Local Git state and the tools a repository declares it needs. Explicitly not databases or running services — those are a different lifecycle with different failure modes, and mixing them is how one command grows into an unreviewable one.
dev, environment, release, ui, knowledge
Authoring-time gates; local data and tenants; promotion of already-built artifacts; UI normalisation against the shared kit; and redacted, source-cited learning capture that never publishes on its own. A plugin is a subject, not a bucket.
The Loop
Desired state, current state, and the gap
This is the whole method, and its value is in what it refuses to collapse. Reporting a difference and closing it are separate skills with separate outputs, because a workflow that can do both will eventually rewrite the standard to match whatever it found.
Writing a Skill So It Fires When It Should
A skill that fires on the wrong prompt is worse than one that never fires, because the reader cannot tell the difference between a workflow doing its job badly and a workflow that was never meant to be here. So each skill ships an eval file of prompts it MUST fire on and prompts it MUST NOT, both in English and in Chinese, each with the behaviour expected of it — and CI scores them. The non-triggers do the real work: ui:normalize must stay out of an audit-only request, contract:evolve must stay out of a refactor that changes no contract, workspace:doctor must stay out of anything that mutates. Those cases are the boundary made executable, which is the only form of a boundary that survives contact with a year of changes.
Want the full walkthrough?
Happy to talk through the architecture, the decisions, and the trade-offs behind this build.
More work
