Pharos På svenska
Pages

The factory

Two parts: a factory, and the thing it builds

Pharos is two separate things. One is the solution: the platform with my agents, the one I talk to, call, and hand my everyday work to. The other is the factory that builds it.

The factory is lights out: it runs without me, and nobody has to sit at it. It works day and night with one purpose: to keep the solution current and free of bugs. It reads what is new in the models and the code it depends on, finds what is broken, fixes it, checks the fix on the live system and writes down what it learned. I describe, I say yes, and I read the reports.

It is a personal project, not a product and not for sale. But it is deeply technical, and this page is where I let that show.

the factory builds, checks, repairs
me: describe, say yes
the solution

One afternoon

A page broke, and nobody opened an editor

One afternoon a page I rely on broke. I wrote one line about it, in plain words, and went back to what I was doing.

The factory traced the cause through the layers. There were two faults, not one: an approval that never reached me, and a backend that only accepted one shape of content. Each layer was fixed on its own, with its own tests.

Every change was read by an independent reviewer, who had to approve exactly the version that would ship, not a description of it. The approved version went into the queue and through the gates. It was deployed automatically and proven against the live system; had that proof turned red, the deploy would have reverted the whole merged group and paused the queue.

I did not read a line of the fix. I read that it was done, and that it had been checked. That is the whole afternoon.

How it works

For the reader who wants to dig. These are the ideas; the code is the factory’s own business.

  1. A head of production who never writes code

    One role directs the work: reads what is broken, decides what matters, writes a brief for each change and reads the report back. It never edits a line itself, so the direction and the work stay separate.

  2. Builders who build from a written brief

    A change is made by a builder that gets a written brief and nothing else. It does not invent scope. Every change comes with its own tests, and a change without a passing run is not done.

  3. Independent reviewers, on the exact version

    A second, separate mind reads every change and must approve the exact version that will ship. A new version means a new review. The builder never grades its own work.

  4. Deterministic gates instead of reminders

    A rule that was repeated too often becomes a gate that blocks: scans for tenant names and identifiers in platform code, for files growing past a size limit, for timestamps kept as text, for anything that wakes the system outside the one agreed path. A gate blocks a new hit; the old ones it found when it landed are listed, each with a ceiling it may not grow past. A gate that blocks is right until I say otherwise.

  5. A queue to the main line, one deploy per merged group

    Changes reach the main line through a queue, in groups. Each merged group is followed by exactly one deploy. A deploy that turns red reverts the whole group and pauses the queue until someone has looked.

  6. Live probes after every deploy

    Unit tests have been green while the live chain was broken, twice. So after a deploy the factory probes the live system the way the agents actually use it. A red deploy reverts the merged group. A few live health probes can pause the queue until someone has looked; the other probes report what they found and never pause anything.

  7. Pacing against the budget

    The factory runs on subscriptions with limits. It paces its own work against them: when a cap is reached it pauses, when the cap clears it resumes, so it runs day and night within what I pay for.

  8. Lessons are written down

    After every correction from me, a lesson is written in the factory’s own files. A lesson that repeats becomes a gate. That is how the mistake rate goes down without me repeating myself.

  9. Every action has a name on it

    Nothing is meant to happen anonymously. Every change, every deploy and every approval is attributed to a person or to a named part of the factory, so I can answer who did what and why.

What it is not

It is not a product and it is not for sale. It earns nothing. It is the part of my hobby that I find hardest to explain and most worth explaining.