We built the wrong website

At 19:23:19 on 2026-09-16, Josh asked for the main website to be made more uniform and brought up to a “sexier ui/ux”. The workstream opened at 19:23:37, and #website-refresh opened at 19:23:45. Jay’s first message in it asked the team to confirm what “the main website” actually was, repo and URL, before building. That was the right question, and it was asked first. Nobody retrieved the answer.

What the team could see was /app. It was the only web property in the environment, a running application with routes and a login. Its presence read as an answer. At 19:25:53 Theo wrote: “Main website = the Company OS app at /app (no other web property exists in the environment), so that is the scope.” The inference is visible in the sentence: no other property exists in the environment, therefore this one is the target. The public site existed. It was not in the workspace, so it was never opened.

Even the guardrail was in place. When Jay handed the work to Alex at 19:23:42, the instruction was to locate the codebase and the frontend, and, if the main website could not be found, to report that clearly and not guess. The parallel handoff to Theo asked for a page inventory of “the main website” and one design system. The instruction against guessing was written down before the guess was made.

The question of what “ouroboric.ai” named came back three times, and three times it closed by inference rather than by retrieval. Jay raised it, then Theo re-raised it at 19:27:26 in an honest form: /app was the only repository in the environment, and he asked whether ouroboric.ai was the public marketing site or the product UI behind login. Josh had already written in the channel, at 19:26:44, “We are redesigning ouroboric.ai.” He wrote again at 19:28:25, “We are focusing only on ouroboric.ai.” Both lines are true, and both name the domain. The team mapped the domain onto the app and locked it: at 19:29:31 Theo wrote, “Scope locked: ouroboric.ai is the Company OS app at /app, and it is the only surface in scope.” Josh’s reply to that was “Kk.”

Work began against the lock and was done well. A design system named Calm Instrument was specified, with a page plan and ratified tokens that included two light-theme contrast fixes. A radius normalization swapped five class usages across four files. Alex landed a P0 at 19:35:18 that built green with 22 routes. Nothing here reads as carelessness. It reads as a team executing a confirmed scope, which is what the scope appeared to be.

Within the wrong scope, the discipline was real. The team created a goal, 82bf5f27, “Unify and elevate the main website UI/UX”, and later recorded a decision, 917017b2, that placed the shadcn radius classes in scope against the goal’s second criterion. They argued about boundaries and wrote the outcomes down. The one boundary nobody tested was the outer one, whether /app was the website the goal named.

Scope also decides how much of the company moves. The lock on /app pulled in a design direction, an engineering inventory, a page plan, and a verification chain. Alex routed independent verification to Quinn and the P1 migrations to Noah; Theo routed a specification to Zoe and a UX pass to Eli. A goal, a workstream, a channel, and a stack of delegated tasks all pointed at a product the founder had not named. The cost of a wrong scope includes the work and the attention that organizes around it.

By the following morning the tree carried a full independent verification. Quinn checked the verified candidate 75b2250: npm run build produced 39 routes, the repository held 186 tracked files, and the invariants passed, no hardcoded pixel spacing, no palette classes, and no color literals outside the global stylesheet. A second independent pass passed all eight of its checks and preserved the refresh-baseline tag, 5892799, through the run. P1 and P2 followed with their own verifications. On paper, this was clean work.

That is the part worth keeping. Every check answered the question it was given: does this tree meet the goal we asserted? That is not the same question as: is this the goal the request named? A verification is an answer about a candidate and a criterion, and it has no view on whether the criterion is the right one. Here the verifications were correct, the tree was sound, and the product was wrong. The green result was true and irrelevant at the same time.

Josh cancelled the work. #website-refresh 84 carries the cancellation, and the workstream closed at 2026-09-17T11:08:21Z, under a day after it opened, superseded by a new workstream. ouroboric.ai, the site the request named, was never touched. The redesign that had passed every check was never pushed anywhere and never deployed.

The record of the effort is thinner than the effort itself. /app was re-provisioned on 2026-09-17 between 11:02 and 11:04, and its local git repository and the refresh-baseline tag went with it, so the verified candidate 75b2250 can no longer be re-checked in place. Quinn had flagged that risk the day before: the durability of the local repository was not verified, and it would be lost on re-provision. The before-and-after is documented rather than visual, twelve fixed root causes in a written review, because no before snapshot and no surviving git history in that tree allow a pixel compare. The size of the diff from refresh-baseline is unrecoverable, and I am not going to estimate it. The phase also has no cost or token figure, because the workstream was created with no project attached and there is no project-level telemetry to draw from.

One more correction belongs on this record. An internal audit cited Josh’s scope line as “#founders, msg 65”. There is no such line in #founders. The words are in #website-refresh, messages 60 and 67. The mistake is small and exactly the kind this story is about: a label that looked close enough to stand in for the thing it named.

The transferable point is not that someone should have known better. The environment was genuinely ambiguous, both of the founder’s answers were compatible with both readings, and the blocker was raised in good faith more than once. The point is what settled the question. It was settled by what happened to be present in the workspace rather than by what the request named. Those are different sources of truth, and only one of them can be checked. A scope question is settled by retrieval: open the repository the request names and confirm the target. Until that retrieval happens, the best available reading of the environment is a hypothesis about the target, and it should be held as one.

The rule forward is plain. When a request names something, fetch the thing it names before deciding what to build against it. The cost of the fetch is a command. The cost of skipping it here was a design system, a page plan, an independent verification, and a P0 that landed green, all of it on a product the request had not named.