Haute Lumière · An operations brief for Claude Code

The Site

This document is the complete operating manual for hautelumiere.life — what it is made of, how to put it on the internet, how to make it findable, how to add to it, and what to do when any part of it misbehaves. It is written to be worked from rather than read once.

The site is twenty-odd hand-set HTML documents and a folder of photographs. There is no framework, no build step, no package manifest, no node_modules, and no server-side anything. That is not a limitation to be corrected — it is the architecture, and every instruction below assumes it and defends it.

Read Part One before touching anything. The rest can be used as reference.

Stack
Static HTML · no build · no dependencies
Documents
20 pages, 12 of them editions of the quarterly
Assets
~400 photographs across fourteen folders
Fonts
Cormorant Garamond & Manrope, from Google Fonts
Host
Any static host. Cloudflare Pages recommended.
Runtime cost
Effectively zero

Part I

The Anatomy

Before deploying anything, understand what you are deploying, because the shape of it determines every later decision and one wrong instinct here will cost a week.

One file, no build

Every page in this site is a single self-contained HTML document. The CSS is in a <style> block in its own head. The JavaScript is in a <script> block at the foot of its own body. There is no shared stylesheet, no shared script bundle, and no import of any kind beyond two Google Font links.

The instinct of any competent engineer looking at this will be to extract the shared CSS into a file, deduplicate the register palettes, and set up a build pipeline. Do not do this. The duplication is deliberate and it buys four things that matter more than the elegance it costs:

Every page works alone. Any single file can be emailed, copied to a USB stick, opened from a download folder, or archived, and it renders perfectly with no network. This is the property that lets the whole catalogue be distributed as loose files.

Nothing can half-load. There is no state in which the markup arrives and the styling does not. The reader never sees an unstyled flash.

There is no toolchain to rot. A build pipeline is a thing that breaks in eighteen months when a dependency is deprecated. This site will open in a browser in twenty years.

Editing is direct. Change a file, refresh, see it. No watch process, no compile step, no cache to bust.

The duplication is the feature. Resist every instinct to normalise it.

The file map

FileWhat it isRegister
index.htmlThe landing page. The front door everything hangs off.Vespers
Issues.htmlThe quarterly index. Links to all twelve editions.Vespers
Haute Lumiere No 01 – 08.htmlEditions one through eight of the quarterly.Various
The First Reading.htmlNº 09.Dusk
The Reel - Build Brief.htmlNº 10.Midnight
The Reel - Interface Spec.htmlNº 11.Midnight
The Island - …Retreats.htmlThe retreat and Circle page.Vespers
The Concierge Eleven…htmlOne-to-one coaching.Aurora
The Island - Application.htmlThe way in.Dusk
The Island - Security.htmlThe Protocol.Midnight
The Server - The Standard.htmlThe communications standard.Nocturne
prices.jsonSingle source of truth for every figure.
sitemap.xml · robots.txtCrawl infrastructure.
_headers · _redirectsHost configuration.
img/hl … hl14/Photography, one folder per issue.

The two chassis

There are two page architectures in the site and it matters which one you are editing.

The spread chassis — issues Nº 01 through Nº 08. Content is a series of <section class="page tall"> blocks, each one an A-series sheet with a fixed aspect ratio, stacked vertically on a coloured desk. This is the magazine format: it prints one sheet per page and it is what gives the issues their object quality.

The rail chassis — everything from Nº 09 onward, plus the four practice pages. A fixed left navigation rail that collapses, a flowing content column, and section anchors. This is the document format: better for long argument, worse for photography.

The landing page and Issues.html use neither — they are ordinary responsive pages carrying the same tokens.

The seven registers

The register system is the single most distinctive thing about this site and the thing most likely to be broken by a well-meaning edit.

Seven palettes — Aurora, Daylight, Solstice, Dusk, Vespers, Midnight, Nocturne — are declared as CSS custom property blocks keyed to html[data-register="…"]. Changing that one attribute on the root element re-skins the entire document. Every colour in every page must resolve through a token: --paper, --ink, --text, --muted, --gold, --gold-d, --rule, and --veil.

The rule that governs every edit

Never write a literal colour into page content. If you write color:#333 anywhere, that element will become illegible in three of the seven registers and nobody will notice until a reader opens it at midnight.

--veil is an RGB triplet rather than a colour, so it can be used at arbitrary alpha: rgba(var(--veil),.055). It is the ink colour in light registers and the paper colour in dark ones, which is what lets the same glass bar work in all seven.

The registers map to hours. On first visit a page reads the local clock and picks accordingly — Nocturne before five, Aurora to seven, Daylight to eleven, Solstice to three, Dusk to six, Vespers to nine, Midnight after. Once a reader chooses a register it is written to localStorage under a per-page key and the clock stops overriding it.

The bar

Every page carries the same 46-pixel glass bar: the mark at the left, the site links, a clock, and the seven register swatches. It is position:fixed, uses backdrop-filter: blur(16px) saturate(1.2) over rgba(var(--veil),.055), and is hidden in print.

Two implementations exist. Most pages have it as literal markup with class .hlbar or .hl-regsw. Two pages — the Concierge Eleven and the First Reading — construct it in JavaScript, so if you are adding a link to the nav, grep for both the markup and the createElement version or one page will silently fall out of step.

Clicking the clock clears the stored register and hands the page back to the current hour. This is its only function; it is not a stepper.

Part II

Installing It

A static site with no build step is the easiest thing in the world to deploy and there are still four ways to get it wrong. All four are covered here.

The host decision

Cloudflare Pages is the recommendation, and the reasoning is specific rather than fashionable. It serves static files from a global edge at no cost at this volume; it honours the _headers and _redirects files already in the repository; it terminates SSL automatically; and — the part that matters given what the Protocol promises readers — it can be configured not to retain analytics or logs, which keeps the site's behaviour consistent with the claims made on it.

Netlify is equivalent and uses the same two configuration files. GitHub Pages works but ignores both, so you would need to move the header and redirect logic elsewhere. Any bucket behind a CDN is fine. What you must not do is put this behind a platform that injects its own script tags — a tracker on this site contradicts the Protocol in writing.

Deploying to Pages

The whole procedure, from nothing to live:

One

Put it in git

git init, commit everything including the image folders. The repository will be a few hundred megabytes because the photography is the product; that is acceptable and expected.

Two

Connect the repository

In the Cloudflare dashboard: Workers & Pages, create, connect to git, pick the repo.

Three

Set no build

Build command: empty. Output directory: /. Framework preset: none. This is the step people get wrong — there is nothing to build, and setting a preset will make it try.

Four

Deploy and check

First deploy takes under a minute. Open the .pages.dev URL and click every item in the nav before touching the domain.

The domain

Add hautelumiere.life as a custom domain in the Pages project, and add www as a second one redirecting to the apex. If the domain's nameservers are already at Cloudflare the DNS record is created automatically; if not, point them there first.

Then verify three things by hand, because all three fail silently: that http:// redirects to https://, that www redirects to the apex rather than serving a duplicate, and that the certificate covers both. A duplicate at www will split your search ranking between two identical sites.

Headers and redirects

Two files at the repository root are already written and already correct.

_headers sets the security posture — nosniff, frame options, a strict referrer policy, a permissions policy that disables geolocation, microphone, camera and cohort tracking, and HSTS with a two-year max-age. It also sets caching: photographs are immutable for a year, HTML must revalidate every time. That split is what makes the site fast without ever serving a stale page.

_redirects maps short, human URLs to the real filenames — /island, /coaching, /apply, /security, /server, /desire, /issues. Use these in anything spoken aloud or printed. Nobody can read a URL with twenty per-cent-twenties in it over the phone.

The filename problem

This deserves its own heading because it is the single most likely thing to break in production and it will not show up in local testing.

The filenames contain spaces. The Island - Application.html is a legal filename and a fragile URL. Every internal link in the site already writes them percent-encoded — The%20Island%20-%20Application.html — and this works correctly on every static host.

Two rules follow. When you add a link by hand, encode the spaces. A raw space in an href works in most browsers and fails in some crawlers, some email clients, and every messaging app that tries to auto-link it. And if you ever rename files to hyphenated slugs — which is defensible — you must add a 301 for every old path to _redirects in the same commit, or every existing share link dies at once.

Part III

Being Found

The site is already comprehensively marked up for search. This part explains what is there so you do not duplicate it, and what remains to be done by a human with account credentials.

What is already done

Every page carries a complete metadata block, injected into the head immediately after the title:

A unique description of 140–190 characters, written as a sentence rather than a keyword list. A keyword set reflecting the actual subject matter. A canonical URL, absolute, so no query string or trailing-slash variant can create a duplicate. Robots directives including max-image-preview:large, which is what lets a search result carry a full-width photograph rather than a thumbnail — significant for a site whose photography is half the argument.

Open Graph tags in full: type, site name, locale, title, description, absolute image URL, and image alt. Twitter card tags set to summary_large_image. Article tags on every editorial page carrying author, publisher, section and a tag per subject.

JSON-LD structured data on every page — an Article for editorial pages and a CollectionPage for indexes, each with a full author object carrying the ORCID identifier, a publisher object, the article section, the keyword set, and a mainEntityOfPage pointer. The landing page carries a richer @graph with linked Organization, Person, Periodical and WebSite nodes.

Plus sitemap.xml listing all twenty pages with change frequencies and priorities, and robots.txt pointing at it while excluding the uploads and working directories.

Registering with search

Four things a person with credentials must do once, in order:

Google Search Console. Add the property as a domain property rather than a URL prefix, verify by DNS record, and submit sitemap.xml. Then request indexing on the landing page manually — it seeds the crawl days faster than waiting.

Bing Webmaster Tools. Import directly from Search Console; it takes one click and it also feeds several smaller engines and a number of AI answer systems.

Check the rendered output. Use the Rich Results Test on three or four pages. It will confirm the JSON-LD parses and show you what a result will look like.

Do not install analytics. Cloudflare's own aggregate traffic view is enough to know whether anything is working, and it does not require a script on the page. Adding a third-party tracker to a site that publishes the Protocol would be a direct contradiction of the thing it sells.

The image problem

The photography is the largest thing on the site and the only real performance risk.

Plates are full-resolution JPEGs, several megabytes each. On a fast connection this is fine; on a phone in a hotel it is not. Three fixes, in order of value:

Lazy-load everything below the fold. Add loading="lazy" to every <img> that is not the cover of the page being opened. The cover should stay eager and should carry fetchpriority="high", because it is the largest contentful paint and the number search ranking actually measures.

Give every image explicit dimensions. A width and height attribute lets the browser reserve the space before the file arrives, which eliminates layout shift — the second of the three vitals.

Serve modern formats. Generate a WebP or AVIF beside each JPEG and use a <picture> element. This typically halves the weight at identical quality. It is the largest single win available and it is mechanical work.

Do not compress the plates destructively to chase a score. The photography carrying visible artefacts would cost more than a slow first paint.

Core Web Vitals

Three numbers decide whether search treats the site as fast. The site is architecturally strong on two of them and needs attention on the third.

Interaction delay is excellent by construction — there is no framework, no hydration, and a few hundred lines of vanilla JavaScript per page. Nothing here blocks the main thread.

Layout shift is good and would be perfect with the explicit image dimensions above. The one remaining source is the font swap; adding <link rel="preload"> for the two font files removes it.

Largest contentful paint is the weak one, and it is always the cover photograph. Preload the cover image in the head of each page, mark it fetchpriority="high", and ship a WebP. Those three changes typically move a page from mediocre to good.

The long game

An honest note, because it shapes what is worth doing. This site will not rank on volume terms — economics, coaching, retreat — and should not try. It is a small site publishing long, unusual documents.

What it will rank for, and already should, is the specific vocabulary it invented or uses precisely: Luminous PESTLE Ecology, the development prerequisite, relational density, living systems economics, the six winds, shadow wind analysis. That is the entire search strategy: be the definitive source for a small number of phrases that matter to a small number of people who are worth reaching.

Be unmissable for a hundred people rather than invisible among a million.

Which means the highest-value SEO work is not technical. It is publishing the next issue. Twelve substantial documents with real citation apparatus is already an unusual corpus; thirty is a body of work that search engines and answer systems treat as authoritative.

Part IV

Being Shared

The card

When any page is pasted into a message, a post, or a chat, the receiving platform reads the Open Graph tags and builds a card. Every page here produces a correct one: a full-width photograph, the title, and a real sentence of description.

Two things to verify after deploying, because both fail silently. Image URLs must be absolute — they are, but if you add a page by hand and write a relative path, the card will render with a blank rectangle. And platforms cache aggressively: if you change a title or image after a link has been shared, the old card persists for days unless you force a refresh through the platform's own debugging tool.

Where this actually spreads

Worth being concrete, because effort spent in the wrong place is the usual failure.

The material is long, dense, and beautifully set. That combination performs badly on any surface optimised for velocity and well on surfaces where people save things to read later. In practice that means it spreads through forwarding — one person sending a link to one other person with a sentence about why — far more than through broadcast.

Which suggests the useful priorities: make the card excellent, make the short URLs speakable, make each page trivially printable, and make sure the person who forwards it does not have to explain what it is. All four are already true. What is not yet built is a way for someone who reads an issue to be told when the next one lands, and that is the single largest gap in the site.

What never to do

The restraint is load-bearing and it should survive a change of hands.

No pop-up. Not on exit, not on scroll, not after thirty seconds. The design system forbids urgency surfaces and an interstitial is the purest form of one.

No cookie banner, because there are no cookies to consent to. If you find yourself needing one, something has been added that should not have been.

No reading time estimate. "Read it slowly" is the house instruction; a stopwatch contradicts it.

No share buttons. They are third-party scripts that track, they date the design instantly, and the people this is for know how to copy a URL.

No comment system. It is a third-party embed, a moderation liability, and a contradiction of the Protocol.

Part V

Adding an Issue

This is the operation that will be performed most often, so it is written as a procedure rather than a description. Follow it in order; several steps depend on earlier ones.

The eleven steps

One

Choose the register

One no recent issue has used. It sets the mood of the whole edition and it is the first decision.

Two

Copy the nearest chassis

Spread format for photography-led work, rail format for long argument. Copy the whole file — never start from scratch.

Three

Change five things in the head

Title, the data-register attribute, the localStorage key prefix, the canonical URL, and the whole SEO block.

Four

Vet the photography

New folder, img/hlNN/. Check every frame for deformed hands and cropped crowns before allocating.

Five

Dedupe against every issue

Compare file sizes against every existing plate folder. No photograph appears twice on this site, ever.

Six

Write the content

Replace the body. Keep the section structure — cover, contents, openers, plates, works cited, colophon.

Seven

Build the apparatus

Numbered footnote marks in the text, an ordered list of sources with matching ids at the end.

Eight

Wire the contents

Every table-of-contents row links to a section id. Audit for dead anchors before shipping.

Nine

Add it to the indexes

Both Issues.html and the landing page. The array in the script block, not the markup.

Ten

Add it to the sitemap

One <url> block with today's date. Forgetting this is the most common omission.

Eleven

Check the bar

Register switching, the clock, and every site link. Then print it to PDF and look at the sheets.

Photography rules

These are absolute and they come from the house rather than from taste.

Never reuse a photograph. Every image appears in exactly one issue, once. Each new issue gets its own folder. Before allocating, compare byte sizes against every existing folder — identical size is a reliable duplicate signal. If the clean supply runs short, ask for more; do not reuse.

Never repeat a model on a cover. A face that has carried one cover does not carry another.

Never cut the top of a head. Full-bleed images use object-position: 50% 0%. Uncut detail plates use object-fit: contain. If a crop is unavoidable, crop from the bottom.

Check hands and limbs. Every frame, before it is placed. Build a contact sheet and look at it. A deformed hand in a magazine that argues for rigour is worse than a missing image.

The citation apparatus

It is a large part of what makes these documents credible and it is entirely manual.

In the body, a source is marked with a superscript link: <sup class="fn"><a href="#c12">12</a></sup>. At the end of the document, a Works Cited section holds an ordered list where each entry carries the matching id: <li id="c12">. Numbering runs in the order the argument needs them, not alphabetically.

Two disciplines. Every number in the prose gets a source — if a figure cannot be attributed it should be cut rather than left bare. And audit before shipping: collect every href="#c…" and every id="c…" and confirm they match. A footnote pointing nowhere is the single most damaging small error available in a document like this.

Choosing a register

Not decorative. The register is an editorial decision about what the material is.

RegisterReads asSuits
AuroraFirst light, cool, cleanBeginnings, one-to-one work, clarity
DaylightNeutral, working, plainFrameworks, systems, reference
SolsticeHigh summer, warm, generousAbundance, physiology, celebration
DuskEvening, intimate, warmPartnership, desire, the personal
VespersCandlelit, after dinnerEconomics, the long argument, the house
MidnightDeep night, cool, preciseSpecification, security, the technical
NocturneLights out, green-blackField reports, the standard, the private

Part VI

The Blog

Why there isn't one yet

The site publishes issues rather than posts, and the distinction is deliberate. An issue is finished, cited, photographed and set. A post is a smaller, faster thing, and the risk of adding one is that the quarterly's standard quietly drops to meet it.

So the recommendation is: if you add a blog, make its floor high. A thousand words minimum, at least one plate, at least three sources. Anything shorter belongs in a letter to members rather than on the site.

If you build it

The architecture that fits what already exists:

A folder notes/, one self-contained HTML file per entry, built from the rail chassis. An index at Notes.html matching the pattern of Issues.html — the entries as an array in the script block rather than hand-written markup, so adding one is a single line.

Every entry carries the same head block as an issue, with og:type set to article and two extra properties: article:published_time and article:modified_time, both ISO 8601. The JSON-LD gains datePublished and dateModified, which is what produces a date in a search result.

Do not build a tag archive page per tag. At this volume it produces dozens of thin pages, which is actively harmful in search. Filter client-side on the index instead — the array is already in the page.

Tags and categories

The taxonomy is already implicit in the metadata and should be formalised rather than invented.

Categories — one per document, matching article:section: Economics · Partnership · Physiology · Strategy · Contemplative · Design · Software · Security · Field Report · The Practice.

Tags — several per document, matching the article:tag entries: living systems, commons, complexity, regenerative, developmental psychology, spiritual bypass, embodiment, nervous system, appreciative inquiry, sovereignty, privacy, local AI, design system, typography.

Two rules. A tag exists only if two or more documents carry it — a tag of one is a label, not a taxonomy. And a document has one category and no more; if two apply, the second one is a tag.

The feed

An RSS feed is the highest-value thing you could add and it takes an hour.

Write feed.xml at the root with the twelve issues as items — title, absolute link, description, publication date, and the cover image as an enclosure. Link it from the head of every page with <link rel="alternate" type="application/rss+xml">.

The reason it matters here specifically: this material is read by the kind of person who still runs a reader, it is the only subscription mechanism that requires no email address and no database and contradicts nothing in the Protocol, and it is how a great deal of long-form writing still travels between people who take reading seriously.

Part VII

Commerce

The site currently takes no money and that is the largest functional gap in it. Everything below is unbuilt; this is the specification.

The price file

prices.json at the root is the single source of truth for every figure on the site, and it exists because prices had already drifted across six files before it was written.

Its governing key is policy.display, set to enquiry. That means no figure appears on any public surface — everything reads Arranged in conversation. There is exactly one exception, declared in the file itself: coaching.group, the group programme, which names its figure once in its own place.

The rule for any future work: no page hard-codes a number. Read from the file, honour the display policy, and if a figure needs to change, change it in one place.

Taking money

The lightest thing that preserves the architecture is a Stripe payment link per product — created in the dashboard, pasted into the page as an ordinary anchor. No JavaScript SDK, no server, no build step, and it works today.

When that becomes insufficient — a cart, a subscription, an entitlement — the next step is a single serverless function on the same host handling checkout session creation and the webhook. Not a platform migration. One file.

Whatever is built, three things must hold: no card data ever touches this site, no third-party script is added to a page that publishes the Protocol, and the buyer's file is delivered without an account being required.

Delivering a file

The store's promise is specific — a file, not a licence — and delivery must honour it.

On payment, issue a signed, expiring URL to the actual EPUB, PDF or M4B. No login. No reader application. No expiry on the file itself once downloaded. If the buyer loses it, they email a person and receive a new link.

Do not build a customer account system to solve re-download. It is a database of names attached to purchases of books about desire, which is precisely the record the rest of this architecture exists to avoid creating.

Part VIII

Eventualities

Twenty things that break

A page renders unstyled. The <style> block was closed early — usually an unescaped </style> inside a string. Check the last edit.

Text is invisible in one register. A literal colour was written somewhere instead of a token. Grep the page for # followed by hex outside the palette blocks.

The register does not persist. Two pages are sharing a localStorage key. Every page needs its own prefix.

The bar overlaps the content. The padding-top that clears it was overridden by a later padding shorthand. This has happened before.

A nav link 404s. A space was left unencoded, or a file was renamed without a redirect.

The clock does nothing. The script ran before the bar existed — on the two pages that build it in JavaScript, order matters.

Contents links go nowhere. Section ids were regenerated and the anchors were not. Audit both lists.

A footnote points nowhere. The source list was renumbered without updating the marks.

The share card is blank. A relative image path in og:image. It must be absolute.

The share card is stale. Platform cache. Force a refresh in that platform's debugging tool.

The page prints wrong. Something was added outside the print stylesheet's expectations. Check that the bar and rail are hidden and margins are zero.

A print page is blank. A fixed-aspect spread overflowed. Reduce the content or let it split.

Fonts flash then change. Add rel="preload" for the two font files.

The page is slow on mobile. The cover image. Preload it, mark it high priority, ship a WebP.

Search shows the wrong description. Google chose its own because yours was too short or too generic. Rewrite it as a real sentence.

Two URLs rank as duplicates. The www variant is not redirecting.

The sitemap reports errors. A URL was renamed. Regenerate it.

An image is missing in production. Case sensitivity — local filesystems forgive it, servers do not.

The deploy fails. A framework preset was set. There is no build; clear it.

Everything looks broken after an edit. An unclosed tag. Run the file through a validator before assuming anything worse.

The pre-flight check

Twelve items, before any deploy.

  1. Does every page open with the network disabled?
  2. Does every register render every element legibly, including the dark three?
  3. Does the clock set the register on a fresh browser with no storage?
  4. Does every link in the bar resolve, on every page?
  5. Does every contents row reach its section?
  6. Does every footnote reach its source, and every source have a mark?
  7. Does every page print with the chrome hidden and no clipped sheets?
  8. Is every photograph unique across the whole site?
  9. Does every page carry a unique title, description, canonical and image?
  10. Is every new page in the sitemap?
  11. Does the share card render correctly in a debugger?
  12. Is there any figure on a public page that contradicts prices.json?

What never to change

The five things that would cost the site its character rather than merely its polish.

The no-build architecture. Every argument for a framework here is an argument for a site that stops working in two years.

The seven registers. Not a dark mode toggle. Seven palettes keyed to the hours, and the clock that follows them.

The absence of urgency. No pop-ups, no counters, no scarcity language, no reading times, no streaks. This is the design system's non-negotiable and it is why the site feels the way it does.

The photography discipline. One image, one issue, once. Faces whole, hands checked.

The refusal to track. The site publishes a document promising readers that nothing reports home. Adding an analytics script would make that a lie in writing.

The restraint is not decoration. It is the argument, made in the medium.

Colophon

Written to be worked from. The Server The Reader The Landing Read Begin The Desk sets out the communications standard; The Protocol sets out vetting and the record. This document covers the public site only.

No build step. Seven registers. One photograph, one issue, once.