General Practices

Appearance

From the foundation template

This page is read live from D:\foundation\docs\VALUES.md, the one home of the values. Change it there.

Values ​

From the foundation template (D:\foundation). Change it THERE, then copy it into projects — never edit it only here.

How Daniel builds, and how every person, Claude session and agent working with him is expected to build. Drawn from every major project (Task4ce, Adtro, RookWorlds, Capsa Web Control, TaskPyramid, Coordie, the AARP annual report, BrandTactics). The examples are real; they stay as evidence.

Systems beat effort ​

Hard work, effort and a serious attitude are worth far less than a system. Work and effort matter, but without systems and infrastructure under them they are wasted. The reverse is how big businesses win: ordinary effort, run through excellent systems, succeeds again and again.

In the AI age this matters more, not less. AI makes execution cheap and fast, so the advantage goes to whoever has the better system for directing it: work smarter, not harder. Every time Daniel and Claude, Daniel and Dave, or Claude and a fleet of agents built well together, it was because the infrastructure and the process were sound. Every time either broke, it showed up in the product or in the pace.

Three values, and how they fit:

  1. Absurd standards is WHAT we are after.
  2. Infrastructure first is WHAT SUPPORTS it.
  3. Procedural approach is THE DOING.

Infrastructure and process work together: infrastructure is the tooling and structure the work relies on, process is the steps we follow to do the work. A high standard without both of them does not get met consistently.

1. Absurd standards ​

Why ​

Users judge the product by what they see and touch, not by the code behind it. Small details add up to the overall impression, so the bar is not "does it work" but "is this as good as the best version of this we can find".

Effort is no longer the main constraint. When building was expensive, shipping "good enough for now" was a sensible trade. With AI, the well-considered version costs little more to build than the rough one, so we ship the well-considered one first. In practice, rough versions rarely get revisited once they ship.

AI will build whatever it is asked to. Deciding what good looks like, and rejecting what falls short, stays with people.

The standard applies to honesty too: we say what is measured and what is assumed, we do not oversell, and we show nothing rather than show something false.

In Daniel's words ​

  • "the absurdly ideal user experience with disregard to effort by us" (Adtro)
  • "if it isn't perfect we need to fix it" (AARP)
  • "i just want it fixed and world class" (Task4ce)
  • "Do not make it look better than it is." (Capsa)
  • "Silence over hallucination." (RookWorlds)

What it looks like: things we have done ​

  • We measured the best before designing. The BrandTactics Library was rebuilt against Dropbox, measured first-hand: the tile size, the 12px strip labels, the loading skeleton. The AARP report went to Mobbin and Pentagram before a line was built.
  • We read the real thing rather than accept "unknown". BrandTactics reads a picture's true DPI from the file's own bytes. The AARP report traces every figure to a PDF page.
  • We handled the hard case automatically. Logos come in every shape; BrandTactics checks each one and fits it the way a designer would, so nobody crops anything by hand.
  • We said the true state. Adtro marks every number measured or assumed, never blended. Capsa's state-of-the-product page has a section called "Not proven yet".
  • We cut what was not excellent. BrandTactics' Share worked and was archived anyway. TaskPyramid's rule: "Zen is a feature. Default answer: don't add it." Excellent over more.

2. Infrastructure first ​

Why ​

Processes break. Every one we rely on has broken at least once: parallel sessions nearly editing the same files, a refused push that looked like a success, a half-killed gate leaving a lock behind, a shell eating command flags, an install that "succeeded" inside a sandbox and did nothing on the real machine.

The app breaks, often where nobody would think to test: a preview fine locally and blocked in production by a security header; one part of the app destroying a file another part was still using; one import breaking a whole server at boot.

The reliable fix is to make the failure impossible, not to rely on remembering to avoid it. A rule written in a document can be forgotten; a rule enforced by the database, the type system or the gate cannot. "ENFORCED, not remembered." (Task4ce)

Speed depends on it. Six changes from idea to production in one afternoon (BrandTactics, 25 Sep 2026) was only safe because the checks, the deploy path and the diagnostics already existed.

Problems have to be visible to be fixed. "how can I fix what I cannot see" (TaskPyramid). Whoever is building, person or AI, needs tools that show what the product is actually doing.

What we build ​

  • The method. Handoff, changelog, memory and runbooks, so the project carries its own memory and nothing learned is lost between sessions. (THE METHOD.)
  • One authority per fact. One store, one component, one set of verbs, one home per table. When a fact lives in two places, one of them is wrong within a month. The most repeated law across every project.
  • The four layers, and the folders are the system. Interfaces → Features → Domain → Infrastructure, dependencies pointing down: docs/ARCHITECTURE.md. Each shared job lives once, in the lowest layer that can hold it; a feature never keeps its own copy and never imports another feature. Without it every feature builds its own picker, its own menu, its own maths, and they drift apart — a September 2026 review of BrandTactics found about twenty jobs done twice or more. Existing duplication is debt: listed, ranked by harm, folded into one home, and the count only goes down.
  • Data in the database. Not in code, not in repo files, not typed by hand where it can be computed.
  • Laws enforced by mechanism. Database triggers that refuse the wrong write; hooks that refuse edits in the wrong place; checks the gate runs. A mistake is refused rather than recorded.
  • Loud failure. A fallback that silently hides a problem makes it look fixed when it is not. Failures are visible, named and counted.
  • No workarounds. A workaround is a failure kept alive: a type forced, an error swallowed, a copy made instead of reused, a retired part designed around. They are "a wretched disease" (Daniel, 26 Sep 2026) because each one makes the next easier. So they are found by code, not by looking — a catalogue of every kind this project has shown, each with real examples it must catch — made loud, and counted down; a new one fails the gate. The work is done up front, on purpose: the more the tool costs to build, the less anyone wants to be the author of what it finds.
  • Parts we no longer use never shape the current design. When something retired is in the way of a true name or a clean path, the retired thing is removed (its data kept first), never designed around.
  • Call it what it is. A name that outlives its meaning is a small lie in every file that says it. Rename it, all of it, when the meaning changes.
  • No exceptions list. A list of rules "kept by judgement", or of files a check skips, is a trap list under another name: the count goes down and nothing got safer. Every finding is fixed, deleted with the evidence that it can no longer happen, or left counted. A second reader (skill escape-hunt) checks that a drop in the count is a real fix.
  • The system governs the code, not the people. What a person keeps in their own files and accounts is theirs; never guard, filter or refuse it to hold a rule of the code.
  • Diagnostics. Maps of what exists, previews of the branch being built, measurements on production with real data. If something cannot be seen or measured, we build the way to see it before we trust it.
  • The gate. Tests, typechecks and checks every change must pass. Passing them is the minimum, not proof that the change is right.
  • Structure for the future we have chosen. Flexible structure for directions we have decided on, not features built on a guess.
  • Features ship with their runbook. Every feature comes with written instructions for operating it.

3. Procedural approach ​

Why ​

Everything can be broken down into steps. If a step is too hard to do, it is not yet broken down far enough: split it again. That is how Daniel solves most problems, and it is how systems get built, because a system is only a set of steps that has been made repeatable.

Process is also how knowledge carries over. Every Claude session starts with no memory of the last one; anything learned is only available if it was written where the next session will look. And AI reports "done" with the same confidence whether or not the thing works, so process includes checking the result rather than trusting the report.

What happened when we did not follow it ​

  • Five branches in one evening cost more in gates and merges than the work itself, because one idea had been split into pieces instead of being done whole.
  • A tidy report described a feature in which not one file could be opened. Only using the software caught it.
  • A relayed instruction ("Daniel said not to self-merge") was not what Daniel said.
  • Finished work sat in an ended session with no copy anywhere else.
  • A fact written in two places disagreed with itself, every time.
  • A rushed stretch produced work that had to be redone: "whole ass one thing", and "its better to work a little slower". (Adtro)
  • Checks that only ran after the work was done caught nothing that mattered.
  • A weakened test looked exactly like a passing one, and hid at the end of a big commit.
  • The foundation itself lived in one chat and one project, so nothing carried to the next.

How we follow it ​

  1. Start: read the handoff. Where we are, what is next, what bites. Follow one pointer, not all of them.
  2. Break it down: into steps small enough to do well. One whole idea per task, finished; a subtask is a part of it, never a stopping point.
  3. Before building: talk about the shape. Measure the best version. Find what already exists and use it. Name the layer the change lives in.
  4. During: when something worth keeping is learned, write it to its one home right away, not at the end.
  5. Prove it: done means seen working on real things, by a person or a measurement. "Verify from artifacts, not from a green checkmark." (Task4ce) Say what was not done.
  6. Close: update the handoff, the changelog and the runbook the work touched; record what was learned.

How we make it stronger ​

  • Every failure becomes a rule with a mechanism. A trap is written onto the thing it concerns, and where possible made impossible.
  • Checks move to the front. A check after the work only records; a check before the work changes it.
  • Checks that do not help are removed. Process steps have to justify their cost, the same as features.
  • Better context today wins. "no choices made yesterday matter. we have better context today." (Task4ce)
  • What works goes back into the template. A project that finds a better way improves D:\foundation, so the next project starts with it.

Keeping the values alive ​

Values slip gradually: a shortcut, a duplicated fact, a check nobody reads. So we maintain them with systems, not just intentions. Every tool, check and habit in a project should serve at least one of the three values. If one serves none, we remove it. If a value has no tool supporting it, building one is a priority.

Linked from