What WootBuild reads from docade

Generated from client.yaml — do not hand-edit. npm run check fails if this page and the declaration disagree, so it is always what the code does.

WootBuild reads the paths below from your repo, read-only, always, and nothing else. Keep them where they are and the rest takes care of itself; move one and art intake says so rather than silently reading nothing.

What we read

assets/asset-list.csv — The work itself. You regenerate it with npm run assets:csv from assets/manifest.json. WootBuild consumes it and never invents a row — a piece that is not in it does not exist.

assets/ART-BRIEF.md — Your prose about intent, per category. A person reads it; nothing derives from it automatically. Where it disagrees with the CSV's Rarity column, your brief text wins — someone wrote that sentence.

assets/identity/ — Your approved brand package. WootBuild holds a copy so the console can render your mark beside your work; this read is how we find out that copy has gone stale.

assets/REQUESTS.md — Where a docade session drops a need it discovered while working on something else. Free text — you are not expected to know a spec, a lane or a size. Appending here is the whole protocol; WootBuild costs it and comes back. Declared before it exists on purpose: the path has to be agreed before the first request, or the first request goes somewhere nobody looks.

What happens when one changes

art intake hashes each path, reports what moved, and re-reads the work-list without overwriting the snapshot it is comparing against. It then says whether new pieces fall in a lane that already exists or need a new one.

It proposes; it never acts. No lane is created, nothing is written into your repo, and a new lane still starts at a human gate. You do not need to tell us when something changes — but telling us is faster than us noticing.

How to ask for something

You do not need to know anything about how WootBuild works. Append to assets/REQUESTS.md and stop. No spec, no size, no lane, no model — working out what it costs and how to make it is the whole job on this side.

## <date> · <one line: what you need>
status: open
category: <a manifest category, if it belongs to one — otherwise omit>
key: <the filename key, if you already know it — otherwise omit>
what: >
  What it is, and where it will be seen. Say the smallest size it has to
  survive at — that decides more than anything else here.
why: >
  What it is for. This is the part that stops us making the wrong thing.

This is not the catalogue. A request is for the moment before that — when you know you need something and do not yet know whether it is a catalogue piece at all. Filing one does not settle that, and it should not: inventing a key to quiet a script is worse than the disagreement it hides. (docade wrote that framing on their first day using this, and it is better than what was here.)

Half of that is optional and a sloppy entry is still a filed request. An entry nobody can parse is shown to a person rather than dropped.

Keep going without waiting. Your filenames are foreign keys, so the key can exist before the art does: declare it, write your code and your documents against the path, and the file arrives underneath it later. That is already how your manifest works — this just extends it to things you had not planned.

Set status: done or delete the entry once it lands. WootBuild never edits this file — it is yours, and we only read it.

Copies WootBuild holds

So the console can render your work beside your brand without reaching into your repo at page-load. These are copies, never sources — regenerate yours and art intake reports ours as stale, then we re-copy.

• assets/identity/ → held at clients/docade/identity

What you get back

Delivered assets land at the paths your own manifest declares — WootBuild never invents a filename, because your filenames are database foreign keys.

An index of everything delivered goes to assets/WOOTBUILD-DELIVERED.md: the manifest key each asset satisfies, where it landed, its spec, and the verdict that released it. Declared, not yet written — WootBuild ATL-40.

For your CLAUDE.md

This belongs in CLAUDE.md, not in anyone's memory. Memory is per-person and per-machine; this has to hold for every session and everyone who works here.

And it is a draft, not a paste. Write it in your own words. A client who writes it has adopted it; a client who pastes ours has filed it. Most of what is below came from RecHero, who wrote their own version before being asked and improved on what was here.

Visual assets — WootBuild produces the catalogue art

Division of labour. We own the requirements. WootBuild owns the execution. A deliverable that misses because our brief was vague is our failure — which makes writing a spec precise enough to be missed the actual work on our side, and earns us the right to hold them to the other half without argument.

When you need catalogue art that does not exist:

1. Append a request to assets/REQUESTS.md — free text. You are not expected to know a size, a style, a lane or a model. Say what it is, where it will be seen, and the smallest size it must survive at.
2. If it belongs in the catalogue, add its key to the manifest.
3. Keep going. Filenames are foreign keys, so the key can exist before the art does. Write your code, your migrations and your documents against the path now; the file arrives underneath it later.

Ways this gets circumvented. Each feels efficient alone; the sum is a studio that never gets exercised and a product whose visuals drift back to whatever was fastest. Named individually, because as a slogan the rule does not survive contact with a deadline:

• Generating or hand-rolling an asset inline because it is "just a quick one"
• Lowering a visual requirement because a delivery is pending
• Letting an untracked placeholder become permanent
• Deciding the studio "probably can't do this" without ever asking

Placeholders are allowed — the UI has to be built against something. It must be visibly a placeholder, it must be logged as a request, and it is never shipped to a user. An unlogged placeholder is circumvention with extra steps.

Not everything is catalogue art. A diagram, a chart, an internal mock, a throwaway — make it here. Authored SVG usually beats a diffusion model for anything carrying real text, and routing a two-minute job through a studio is worse than doing it locally. What must not happen is shipping product art made by handing a screenshot to an image model.

What we owe them in return: a spec precise enough that a miss is unambiguous, rejections with specifics rather than a vibe, something harder to do once the easier thing is proven, problems we do not know how to solve, and intake friction fed back as a finding rather than worked around.

You do not need to notify anyone. WootBuild reads this repo and picks up the change. Telling them is faster, not required.

What we never do

• Write into your repo without a human verdict.
• Invent a filename, or deliver to a path your manifest does not declare.
• Read anything outside the paths above.
• Change your files. Every read is read-only, including during an intake.