EFFICIENT System

Stack

• Agent Skills
• ·Claude Code
• ·Python
• ·Django
• ·React

Category

Platform

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 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.

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.

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.

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.

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.

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.

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.