The operating manual for traveller.org — kept current with every publish that changes a process. Sits with the CMS portal behind the admin door.
http://www.traveller.org property: it’s a museum of the old site; let it
decay. The only place a manual index request helps is a current page you want in
(URL Inspection → Request Indexing, rationed ~10/day). The full reading of a coverage
report is on the pipeline page;
calendar reminders for the check-back dates (21 Sept, 15 Oct, 16 Nov) are on your Google
Calendar.Until the /admin CMS ships, updates happen one of two ways: tell
Claude what you want in a session (it edits the data files and publishes), or edit
the JSON files directly on GitHub. Every path below ends the same way — a commit to
the repo, which triggers the automatic build and deploy. The CMS will be a friendlier
skin over exactly these same records.
The admin login lives at the foot of the left-hand menu (as a card near the top on a phone) — and since 3 September 2026 it asks for one thing: the passphrase, the same one as the upload page. The worker address is machinery and waits behind a small Change the worker address button; it reappears on its own when the worker cannot be reached, which is the one time it needs looking at. Sign in once on any admin page and it holds across all of them: each tool page connects itself the moment you arrive, and the prompt only reappears when the passphrase is absent or wrong. While the check runs, a band at the very top of the page says CONNECTING… in ink with a light sweeping along it — the phone uploader’s own language — and turns into the gold CONNECTED band the moment the session holds, so the page underneath stays readable instead of hiding behind the form. With Remember on this device ticked it survives closing the browser (and switches on the Rotate / Remove controls on photo pages); unticked, it lasts until the tab closes. Sign out in the same spot clears it from the device — photo pages drop their admin controls at the same time. Hiding the fields is convenience, not the security: the Worker re-checks the passphrase on every call regardless.
A browser cannot share a login between two addresses, so being connected on the staging
admin used to leave www.traveller.org a stranger to you: the friends door
bounced you off your own unlisted albums, and the photo-page controls stayed hidden. Now
the connected bar on every admin page carries Unlock the live site. One tap opens a
new tab in which production recognises you completely:
The button is the purple one on the bar — the same purple as
everything the friends layer touches. If the live site ever looks signed OUT when you
know you unlocked it, check the address bar first: the bare traveller.org
used to serve the site as a second host with none of your keys; since 30 August it
forwards to www, where your unlock lives.
Under the hood the button hands your held passphrase to the live site, which checks it against the upload Worker — the passphrase’s one home; no second copy exists anywhere — and only then lets that browser in. Once per browser is enough; it lasts about a year, like a friend’s sign-in. A wrong or rotated passphrase unlocks nothing.
The admin menu is grouped by the job, in the order the work flows: Add (the photo uploader, the phone uploader, the iPhone Shortcut recipe — each with its own icon), Content Mgmt (Gallery cleanup, Journal, Banknote pages, Cards & strips), Publish (the Publish button, zip records, the launch runbook) and Manual (these pages). Nothing inside any tool changed — only how you reach them.
production branch — the live
traveller.org is still the old InMotion site. From cutover day onward it is the real
switch.src/data/journal.json: title, city, date, country, body text, optional images and pull quote.2009-saigon suggests vietnam/2009/saigon) — edit it there if the replacement should live somewhere else. The old gallery stays visible as a deprecated reference until launch.country/year/name, e.g. vietnam/2009/halong-bay, plus an optional display name.Cat Ba/, Rangoon/) — one level below the gallery path, e.g. vietnam/2009/halong-bay/Cat Ba/ — and the photos arrive pre-tagged, so the gallery page groups itself into city sections. (The Cloudflare dashboard's own uploader caps at 100 files and flattens folders — use it only for tiny batches with no place folders.)…workers.dev/?fresh always gets the current one.rclone straight to the bucket beats any number of browser
tabs — then start the import from this page as usual.southkorea/2008 when that already holds albums like
southkorea/2008/busan, the photos land next to the albums rather than
in one — a valid path with no gallery of its own, so they publish nowhere and the import
for the album you meant reports "no images found". The page now catches this: it names the
album folders already there and offers a corrected path before uploading. If the photos
have already gone astray, nothing is lost — they can be moved into an album from Actions
(mode import with from_slug set to the parent path), which is a storage-side
move, not a re-upload.india/2007 does not make four albums; it makes one album
holding all four, named by whichever batch you sent last. The gallery name is a label on
the destination, not a divider between batches. To get separate albums give each batch its
own path — india/2007/agra, india/2007/kerala — or drop the
folders together and pick Separate galleries. The page now warns before uploading
when the destination already exists under a different name, and offers the sub-path.agra… files into one album, all the kerala… files into another)
and each is published under its own name. Nothing goes back up from your machine, so it
costs minutes rather than hours — but it only works when the filenames say which batch
they came from..THM thumbnail beside every .MRW; other cameras add
.XMP, and the Finder adds .DS_Store. None are photographs, and
none are uploaded — only .jpg, .jpeg, .jpe,
.png and RAW files (.mrw .nef .cr2 .arw .dng .orf) go up, in any
mix of upper and lower case. (.jpe is an ordinary JPEG — the third spelling
the standard allows, which some scanners still write.) The page says what it skipped and how
many it is sending, so a drop of 400 files uploading 200 is never a mystery. If sidecars
reach storage some other way (rclone, the Cloudflare dashboard), the import ignores them
and names them in its log.india/1993 and get 14 galleries, each titled from
its folder name, imported in one click of Start N imports) — or Places inside
one gallery — folder names become place tags, the way Burma’s
Rangoon/ and Bagan/ sections are made. Dragging one wrapper
folder still works as always (its name is stripped; folders inside it prompt the same
question). Switch on Ignore subfolder names to skip the question and file everything
flat.-1
suffix rather than overwriting.Canceling since a higher priority waiting request exists on
a perfectly good run.Setting this up for the first time, or rotating a key? See Publishing & image pipeline → Credentials & where to update them for direct links to the GitHub secrets page and the Cloudflare Worker editor.
jordan/2026/petra and adds
"Creates the country Jordan", and you never type a path. (If you prefer typing one,
"Edit the path directly" still works, and a path whose country the site does not recognise
is challenged before the upload with the same two questions — it also offers the near-miss,
so north-korea is caught when the site's slug is northkorea.)
The import creates the country record — page, stats, chips, listings and the locator
map are all live on that same import: maps draw from world-map data stored in the
repository, framed to show the country among its neighbours. (If map generation ever fails,
the import email says so, the country page simply renders without the map, and re-running
is one workflow click.) A country the site already knows — even one with no photo albums
yet, like a journal-only country — is never challenged: its first batch uploads like any
other.Start at www.traveller.org/admin/ — that page lists every tool with a line on what each is for. Cloudflare asks for your email and a one-time code first; after that the whole admin door is open for the session.
The tools that talk to the worker — Publish, Gallery cleanup, Journal photos, the Journal editor, Cards & strips, Banknote pages, Batch zip records — need the login at the foot of the left column. The manual pages need nothing.
They do the same thing. Every admin page on either host talks to the same upload
Worker, which starts the same workflow in the same repository and writes to the same photo
storage. Approving a gallery, hiding one, reordering photos, deleting a note — done from
brarob100.github.io/traveller.org/admin/ or from
www.traveller.org/admin/, the effect is identical. There is one set of data and
one pipeline; there is no second copy to keep in step.
What differs is the age of the tools, not the data.
| Staging admin (github.io) | Live admin (www) | |
|---|---|---|
| The pages | Every commit, within a minute. Newest controls. | Only what was there at the last Publish, so it can be missing controls that already work on staging. |
| The album list | The same list on both: the Worker reads it from staging, so a gallery imported ten minutes ago is offered on the live admin too, before it is published. That is deliberate and fixed — see which site the phone reads. | |
| The door | The passphrase only — the pages themselves are public (unlinked and noindex, but no login: GitHub Pages cannot take one). | Cloudflare Access since 19 August 2026 — email and a one-time code — then the passphrase. |
| Signing in | Separately on each: the passphrase and the Worker address are remembered per website address, so signing in on one does nothing for the other. | |
| Cross-site calls | An extension or privacy setting can block them (see the box above). | Same-origin through /api — nothing to block. |
Use whichever suits the moment, and treat staging as the master. It has the newest tools, and it is the site the album list comes from. The live admin is the same machinery one Publish behind — useful when a browser is blocking the cross-site call, and the only one protected by the Access door.
From the phone, the choice is made for you. The uploader’s Publish to the live site card and the tool links beside it (added 27 August 2026) all open the staging admin — the master set, and the one that does not stop a phone at an email-and-code login. See the rest of the admin, one tap away.
The uploader as a Home Screen app (31 August 2026). Open
www.traveller.org/api/m in Safari, tap Share → Add to Home Screen,
and the icon opens the phone uploader full-screen, no browser chrome. If you added the
icon before this date, delete it and add it again: the old app manifest pointed its
launch address at / — the uploader itself on the old
workers.dev host, but the site’s home page once the Worker moved
to /api, which is why the icon opened the wrong thing. It now names the
uploader on whichever address it was added from.
Picked the wrong photos on the phone? Tap Clear (4 September 2026). While photographs are selected, the Photos card shows Clear beside Change — one tap empties the selection without reopening the photo library, and the upload button goes quiet again. The same Clear appears on the Currency screen’s card. (Change re-opens the library; on an iPhone, cancelling there keeps the old selection, which is why Clear exists.)
The phone uploader tells you it is unlocked, at the top (1 September
2026). While a remembered passphrase is being checked the same bar runs first in
ink reading UNLOCKING… — it used to be a greyed label inside the
bottom button, the least visible corner of the screen — with a light sweeping along
the band so a slow network reads as working, not stuck (3 September 2026; the sweep
stays still for anyone whose phone asks for reduced motion), then turns gold the moment
the check succeeds. A gold UNLOCKED bar runs across the very top of every screen of
/m, saying whether the passphrase is remembered on this phone or good
for this session only — the two behave differently next time you open the page,
and only one survives closing it. It replaces a small green word in the top corner that was
easy to miss. The bar is absent on the unlock screen, which is by definition the locked one.
The same screen now leads with the site’s own app icon — the Buddha that is on
the browser tab and on the Home Screen icon — instead of a drawn symbol, so the
page you unlock looks like the thing you tapped.
An album named 2026/madrid instead of Madrid, with its year showing
the same thing, means an import was re-run without a name or a year filled in and the
album took its path as both. Nothing is lost — the photographs, the order and
the unlisted flag are all untouched, it is two fields on the record.
The repair is one save: open the album on Gallery cleanup, put the real name and year into Album details, and save. It will not happen again — from 27 August the import reads the album’s own record before falling back to anything, so a re-run that leaves those boxes empty keeps the name you gave it. See what a re-import keeps.
country/year or
country/year/name — both are accepted everywhere photographs are sent.
Forty-one albums on the site are two-part (botswana/1992,
unitedstates/2012), which is how the early ones were made.country/year/gallery-name; without a name it writes nothing. To send to a
two-part address, press Edit the path directly and type it.unitedstates,
hongkong, southafrica. Type united-states and it is
folded onto the site’s spelling automatically, at both ends of the upload.Removing photographs deletes them from storage and then starts a short run that rebuilds the album’s record. Two cases broke that second half and reached you as a red “Run failed” email for something that had already happened:
Neither was a lost photograph — both deletions did what was asked. What was wrong was being told a failure had occurred by email, minutes later, with no way to tell which half had failed.
An album is two screens: the photo view you land on, and the grid of every photograph in it. The bar at the top of the photo view now offers both ways up — “▦ All 388 photos” for this album’s grid, and “‹ Burma — country page” for everything from that country.
Before this the bar had the country page only, and the way back to the album was a button
below the filmstrip — off the bottom of a phone screen, and not where anybody
looks for “back”. It matters most for a link to a single photograph (an address
ending #p2), which is how one picture gets shared: whoever opens it has no idea
what album it belongs to, and now there is one tap to find out. The button below the filmstrip
still works and does the same thing.
Open Gallery cleanup on your iPhone and it is the page you designed on the boards: albums first — a searchable list with the ⊘ unlisted and ◌ not-imported markers — then the album itself with three ways of holding it:
The ⋯ button holds the rest: Album details (name, year, path, the Unlisted switch — or Import, for an album still waiting), Films, and Delete, which still shows the album’s path and makes you type it back, exactly as demanding as at a desk.
Everything here is the same machinery as the desktop page — the same checks, the same refusals, the same pipeline runs; only the room is arranged differently. The desktop page is unchanged, and a window wider than 700px always gets it.
The same treatment: on your iPhone, Cards & strips opens on three doors — Hero carousel, Letters home, and Country cards & strips — each a screen of its own, with the photo and entry pickers sliding up as sheets.
As with Gallery cleanup: same machinery, same save, same refusals — only the room is different, and a desktop window gets the page you already know.
On Gallery cleanup the same album shows a number twice, and during a working session they disagree. Both are right; they are answers to different questions.
Remove sixty photographs and the grid drops to 685 at once while the droplist sits at 749 until the site catches up. Nothing has gone missing. When they differ the line now says so — “685 photos · 0 selected · the site still lists 749 — it catches up a minute or two after each change” — so the gap reads as a delay rather than as lost work.
If the two are still apart long after everything has finished, that is worth a look: it means the record and storage genuinely disagree, and a sync run rebuilds the record from what is actually there. Ask a session, or run sync from the import workflow with the album’s country and path.
An import email may now tell you that a photograph you have just uploaded is already on the site in another album, and name it:
IMG_4471.JPG
is already published as
mexico/2019/vallarta/IMG_0031.JPG
Nothing was removed, and nothing needs doing. This is a notice, not a fault. The site now recognises a picture it already holds wherever it holds it, and the same photograph in two albums is often deliberate — a picture that belongs to a city album and to a later retrospective both. Only you can tell that apart from the same batch being uploaded twice, so the pipeline tells you and stops there.
If it is a mistake: open the album you do not want it in on Gallery cleanup, tick that photograph and Remove. The other copy is untouched either way.
Inside one album the rule is different and always has been: the same picture twice in the same album is a mistake by definition, so the import removes the second copy and lists it. That has not changed.
The other new line in an import email. A photograph that is 90% or more the same picture as one already in that same album is not added to the site:
IMG_4472.JPG
96% the same photograph as IMG_4471.JPG —
held back, not published
It is not deleted. The file is kept in storage, out of the album, and the email says so. Nothing else in the batch is affected.
If it should have been published — and this will happen, because two shots
taken seconds apart can read as the same photograph — ask a session, or run the
import for that album again with direction set to keep-near. That
brings back every photograph held for that album and publishes them all.
Why 90%: it is the number you set. It catches the copy whose file is genuinely different — a re-export, a screenshot, a photograph that came back through a message — which the exact match cannot see. The price of catching those is that it occasionally stops a real frame, so it stops it reversibly.
On the phone itself this moved (24 August 2026): the phone’s own
upload page at /m has a + New album row inside its album list — same
markers, same rules, same Unlisted switch — so on a phone you no longer open this panel.
The panel below is still how it works from a desktop, and everything it says about markers
and years holds for both.
The iPhone share sheet lists albums; it cannot make one. So when a trip needs three or four new albums, make them first, on the upload page — which works perfectly well in Safari on the phone, so this is not a trip to a desktop.
france/2019/champagne.france/2019), which 41 of the site’s albums are.spain/2026/basilica-de-la-sagrada-familia-barcelona, not
bas-lica-…. Renaming later in Gallery cleanup → Album details
still works and still wins — including against the next batch: an import used
to quietly re-derive the name from the address and undo a rename you had just made (it
happened with this very album, twice in one afternoon); now a later upload keeps whatever
name the album holds. If you already have a mangled album from before this:
while it holds no photographs, the simplest repair is to delete it in Gallery cleanup and
create it again — clean address, name kept. If photographs are already in it, open
Album details, fix the Name, and — only if you want the address clean too
— edit the Path, which moves every photograph with it.What actually gets written is an empty marker file, not a photograph — so there is nothing to delete afterwards, the album counts as 0 photographs until a real batch lands, and no gallery page can show it. A country the site has never had is refused here, because a new country needs a region and a display name that only the importer can be told: its first batch still goes through the uploader above.
The Year box fills itself, and the rule is different in the one case where getting it wrong is easiest:
netherlands/2018/amsterdam and spain/2018/madrid — the year
shown plainly in the preview, and easy to read straight past. They have been moved to 2026.
If it happens again: Gallery cleanup → Album details corrects the year, but the
year is also in the address, so correcting it properly means moving the album —
ask a session and it does both in one go.Creating a country needs two answers nothing can guess: its display name (“Egypt”) and its region, which decides where it files on the site. The upload page asks for both — the country list’s last entry is “+ a country the site doesn’t have yet…”.
The iPhone Shortcut and the share sheet cannot. They have nowhere to ask, so sending to a country the site has never had is refused on the spot, on the phone, with a line saying a country’s first batch has to go through the upload page. Nothing is uploaded, so nothing is stranded. (Before 21 August the upload was accepted and the import failed three minutes later by email, which is how a batch of Iran photographs went missing for a day.)
The refusal can only work when the phone can read the site’s country list. In the rare case it cannot, the upload is allowed through rather than blocked, and the import then fails with “No country ‘X’ on the site” by email — recoverable, since the photographs are in storage: import them again with the right country and the batch relocates itself.
The login is www.traveller.org/api everywhere (30 August 2026).
That address has been the offer since the route landed — but a
workers.dev address remembered from the early days beat the offer
forever on the test site, and on a network that black-holes that hostname it read as
being locked out of the admin. Every admin page now clears exactly that stale remembered
value, on either site, and offers /api; an address you typed yourself is a
choice and stays, and the login still falls back to the Worker’s own address by
itself if the /api route ever goes missing.
Checking the address in a browser (30 August 2026): www.traveller.org/api now lands on the upload page rather than a 404 — the
Worker’s mount needs the trailing slash, and the bare spelling used to miss it,
which read as “wrong address” at exactly the wrong moment. Either spelling
is fine in the Worker box; the login only ever calls addresses beneath it.
It should read https://www.traveller.org/api, and you should not have
to type it: the box offers that address by itself, on the live site and on staging alike.
It is the same Worker as traveller-upload.brarob.workers.dev, reached by the
site's own name — which is what stops browsers, networks and blockers interfering with
it, and they have.
upload.traveller.org (14 September 2026). Same Worker, same passphrase,
same pages — upload.traveller.org for the desktop form and
upload.traveller.org/m for the phone one, though a phone opening the plain
address is sent to /m by itself. It exists because the other two are awkward
to say out loud: this is the one to put on a phone’s home screen or read to somebody
helping with a batch.https://www.traveller.org/api — that one is same-origin with the admin
pages, which is what keeps browsers and networks out of the way — and the iPhone
Shortcut still carries the workers.dev address and needs no change. Three
addresses, one Worker, all live.You should not have to clear anything. The one address every browser was holding
— the worker's own traveller-upload.brarob.workers.dev, left behind by the
builds that filled the box with it automatically — is dropped on this domain the first
time a page loads, since /api replaces it. An address you typed is a
choice and stays.
What to expect when something is wrong. Every call the login makes gives up after fifteen seconds and says so. If you see “The worker did not answer within 15 seconds”, the address in the box is not reachable from that network — sign out and let it re-offer, or try another connection. What you should never see again is an admin page that simply sits there showing nothing, which is what a hostname being silently dropped used to look like.
https://www.traveller.org/api/galleries in a tab of the same browser. If it
prints wrong passphrase, the network is fine and something in the browser is refusing
the call the page makes.github.io, so its
admin pages must call the worker on another domain — a cross-site request, which
an extension or a privacy setting can refuse wholesale. No address fixes that; there is no
same-origin route to offer, and there cannot be one on GitHub Pages. Two ways through:
use the admin pages on www.traveller.org, where the call is same-origin
and nothing is cross-site (you will meet the Cloudflare Access code first), or open staging
in an incognito window, where extensions are off.Two kinds of row are in storage but off the site's public lists, and until 20 August they shared one word. They are now told apart, because they need opposite things done to them:
The difference is read from thumbnails, which only the import makes. Before this, flicking the Unlisted switch on a never-imported folder started a pipeline run that could only fail — “No album at brazil/2004” — because there was no record to change (owner, 20 August 2026).
Both sit in alphabetical order with everything else (22 August 2026). They are found by comparing storage against the site’s public list, and for a while that showed: they were added after the site’s own albums and arrived as a clump at the foot of every droplist, so reaching the folder you had just uploaded to meant scrolling past every published album on a phone. Where an album sits in a picker is its name, not where it was found.
Because they are no longer grouped, each carries its own mark, and on the upload page the mark also leads the row — since on a phone the label wraps to three lines and a note at the end of it is off the bottom of the row. The words are still there; nothing depends on recognising a symbol.
The destination droplist
The same two marks lead the lines of the iPhone Shortcut’s album list — see Photos from the phone.
So, with a · not imported folder: import it from Gallery cleanup (optionally ticking Import it unlisted on the way in, which you can change afterwards), or ask in a session to prune it if the files are strays. Pruning deletes only the files sitting directly in that folder — never an album nested inside it.
If the strays are inside a published album’s folder — one odd file among the album’s own photographs — ask for prune-files instead, which names files rather than sweeping a folder. It refuses to touch anything the site publishes, and when sweeping it keeps any file that is the only copy of that photograph and tells you which. See the pipeline page.
A photograph that arrives with no file extension is now sorted out for you.
The iPhone share sheet sometimes hands a photograph to the Shortcut without its filename
attached, and it then lands in storage as IMG_5064 rather than
IMG_5064.jpeg. Those used to be counted as stray files and quietly left out of
the album, while the run still reported success. The upload now takes the extension from the
photograph itself as it stores it, and the import repairs anything already sitting in storage
without one — the review email lists each rename. Nothing to do at your end, and
nothing in the Shortcut to change. See
the pipeline page.
Storage folder names are case-sensitive, and the site's country slugs
have no separators in them (unitedstates, hongkong). The upload now
folds a typed country onto the roster before storing anything — Mexico,
united-states and Hong Kong all land in the country that exists
— and the import folds the same way, so the two ends of one upload cannot disagree
about where the photographs are. A country the site has never been to is left exactly as
typed, and the import then asks for its region and display name. Folders that pre-date this
are tidied with a prune, or imported with the right country from Gallery cleanup.
Every note headline leads with its currency's symbol — ₹100,
€10, ₤1000 — and so does every heading that
names a currency: the library page heads The Euro — €, and the banknote
band on a country page reads The Peseta · ₧ — banknotes
(2026-08-20). The symbol is a modern label, not a claim
about what is printed on a 1975 note, and it is typed once per currency in the site's data.
A country new to the library arrives without one, because nothing in a filename says
“₱”: the build log names any currency still missing its symbol, and the
test suite fails until it is added. Ask in a session and it takes a minute.
The euro is a currency, not a country. It has its own page in the Banknote Library and its own note pages, but no country page, no card on The Countries, and no share of any “N countries” the site quotes — the library's own line reads “from 51 countries and the euro”. Instead, every country that uses it shows the euro band on its own page, above that country's older notes: Spain leads with the euro and the peseta sits beneath it. Germany and Luxembourg, which have no notes of their own here, show the euro band alone.
Uploading euro scans works exactly like any other — name the files
euro-50-f.jpg and the import takes them without asking for a region, because the
euro has no country to file. If another shared currency is ever collected, ask in a session:
it takes one line, plus the list of countries that use it.
The form at Contact is live on www.traveller.org — and, since 20 August 2026, on the staging site as well. A message sent from either one is a real email that arrives in your inbox, and hitting Reply answers the person who wrote it.
How to tell a live form from a dormant one at a glance: a dormant one carries a grey line under the button reading “Test build: the form is display-only” and shows a drawn checkbox that does not respond to a click. That is a build that was made without the two public keys — not a broken CAPTCHA. A live one has neither: it shows Cloudflare's own I'm not a robot widget, which ticks itself for most visitors.
The words now sit beside the form rather than above it, below the photograph, as the design had them originally.
The Publish button is one way; saying so in a
session is the other. Tell Claude “publish it” (or “publish to
prod”, “push it live”) and the live site is updated from the reviewed
staging trunk, exactly as the button does it — Claude names what is going out first,
runs it, and checks the result on www.traveller.org.
Without that phrase nothing reaches the live site. Every change — a fix, an import, a whole feature — lands on staging and waits there. That is the point: staging is where you look at it, and the live site changes when you say so and not before. Claude may offer to publish; it does not decide to.
One phrase, one publish: saying it today does not authorise tomorrow's work. And if anything is failing, Claude says so and asks first — “publish it” approves the deploy, not skipping the checks.
Under the Publish button, Publish now lists Previously published — every press of that button, newest first, with the date and the changes it carried. The newest one is open; the rest fold. It sits below what is waiting to go out, because what is about to happen is the decision on that page and what already happened is reference.
The list is worked out rather than kept: each press of Publish is one run of the publish job, so consecutive runs bracket exactly what went out between them. Nothing to maintain, and nothing that can drift out of step with the branch. The oldest entry says “earliest publish on record” and lists nothing — it has no earlier run to be compared against, and an empty list there would read as a publish that carried nothing.
On Banknote pages, open a note and use Delete this note, set apart at the foot of the editor. It asks first, naming the note.
An unlisted album is built and served exactly like any other, and appears nowhere
on the site: not on the home page, not on its country page, not in
Photographs, not in any of the counts the site quotes, not in
the sitemap, and not in llms.txt. Search engines are told not to index it. The
only way to it is its address.
To everyone who opens it: a single purple bar under the breadcrumb reading UNLISTED. One word, no explanation. Somebody you sent the link to should be able to see that the page is not part of the public site — that is orientation, and it costs nothing. And it is the same bar you use to check you are on the right album.
On both views (22 August 2026). An album page is two screens — the photo view
you land on and the gallery grid behind View gallery — and the bar sits at the top
of each. This matters because of how a single photograph gets shared: an address ending
#p2 opens the photo view with the grid hidden, so a bar on the grid alone would
disappear at exactly the moment one photograph is being passed around on its own.
The explanation is here and nowhere else. Until 22 August 2026 that bar was a paragraph, served to every visitor, which read:
Unlisted album — this page is linked from nowhere on the site, appears in no listing or count, and is not indexed by search engines. It is not private: anyone who has this address, or is sent it, can open it. Hide or unhide it on Gallery cleanup.
Every word of that is true, and it is the difference between a label and a briefing. The label tells a visitor where they are. The briefing told them the album is meant to be unfindable, that nothing guards it, and where the control that governs it lives — three facts that are yours, not theirs. It is recorded here so the explanation is not lost, and it is not on the album any more.
The bar is written into the page when the site is built, so it is there for everyone with no passphrase and no waiting. It is also the only thing on the page that mentions the word: a published album’s page never says it at all. The test suite counts the occurrences on both and fails if a paragraph creeps back in.
www.traveller.org, opening an unlisted album’s page asks for the
friend password first — see Friends: the door and the
password below. Two limits are worth holding in mind. The test site has no door
at all: it is plain files on GitHub Pages, so there the link alone still opens the album,
exactly as before. And the photograph files themselves still sit at ordinary public
addresses on images.traveller.org — the door is on the pages, not the
pixels; putting a gate in front of every image was offered and declined when unlisted
albums were built (2026-08-19), and that call stands. So the old advice still applies to
the photographs: fine for family, not for anything that would matter if it travelled.Two ways to set it, and they do the same thing:
You can see them on the country page (22 August 2026). Open a country’s page in a browser that holds the admin passphrase — the same one the admin menu remembers — and any unlisted album for that country appears in the country’s own list of albums, in its year’s place, as a purple-edged card marked ⊘ Unlisted. A note under the list says why you are seeing them.
What the card looks like (24 August 2026): a solid purple band across the top of it reading ⊘ UNLISTED — visible to you, not on the public site, with the album’s year, name and Gallery → link in the same purple beneath. It replaces the small outlined pill that used to sit under the photograph count: on a phone the card stacks into four short grey lines and the pill read as one more of them. It is the same purple, word and glyph as the bar on the album’s own page, so the two places an album says unlisted say it the same way.
In the timeline, not underneath it (24 August 2026). Until then the unlisted albums were collected in a block below the list, which answered what is hidden? — a question you can already ask on Gallery cleanup. The question a country page is for is what is there from 2019?, so that is where the album now sits: between 2024 and 2015 on Mexico’s page, in the same order as everything else, with the marker doing the work of saying it is not public. Legacy 800px albums stay at the bottom as they always have.
Two things about that are deliberate. The counts do not move: the galleries and photographs totals at the top of the page are the public ones, and an unlisted album is documented as absent from every listing and total — changing them for you would mean the number you see is not the number the site publishes. And the album is not in the page: the built HTML that anyone can download names it nowhere, whatever they do with CSS or View Source. Your browser fetches the list from the upload Worker, which asks for the passphrase before it answers. A folder that was uploaded and never imported is not shown here, because it has no gallery page yet — a card for it would be a link to nothing. Import it from Gallery cleanup first.
Finding one again is the part that needs saying, because an unlisted album is linked from nowhere: pick it in that same droplist on Gallery cleanup, where unlisted albums are marked · unlisted, and the page prints the album’s address for you to copy. That droplist is the only list of them anywhere — the site’s public gallery feed deliberately leaves them out, since it is a file anyone can read.
Uploading more photographs into one is the same as any other album: choose it as the destination and upload. It stays unlisted — a second upload cannot quietly put it back on the site.
If an album you created unlisted ever shows up public (it happened once, 30 August 2026 — the choice was lost when the album folder already existed at creation): flick the Unlisted switch on under Album details and it is repaired in a minute. Both ends now carry the choice independently — the builder re-marks an existing folder, and the import reads the mark itself — so the same loss cannot recur. Details on the pipeline page.
Since 27 August 2026 the live site has a friends door: one shared password that opens every unlisted album. It is made for the people you’d hand a printed album to — they sign in once and the device stays signed in for about a year.
Either of these, whichever suits the person:
www.traveller.org/friends/ and tell them the password. They type it once and
land back on the home page with a slim purple banner across the very top —
“Signed in as a friend — hidden albums and photographs are visible to
you, but not publicly available” — on every page, for as long as they stay signed in.www.traveller.org/friends/login?key=the-password — tapping it
signs them in and opens the home page, nothing to type. The password rides inside that
link, so send it the same way you’d send the password itself.A friend who follows a link to one unlisted album before signing in is not lost: the page asks for the password and then carries them on to the album they were opening.
Where a friend finds the hidden things (28 August 2026). There is deliberately no friends page to browse — a signed-in friend meets hidden content where it lives. On a country page, that country’s unlisted albums appear in the timeline in their year’s place, each carded ⊘ Unlisted · visible to friends — the same cards you see as admin. Inside a public album, the friends-only photographs are woven into their true positions, and each one carries a small purple flag — Friends Only — Not in Public View — across the top of its tile and above it in the photo view, so a friend always knows which photographs the public page does not show.
And one place lists them all (30 August 2026): the Photographs page
(/galleries/ — where the nav’s Photographs goes) shows
every unlisted album, whatever its country, in a block of cards under the public
listing, each named with its country — Spain — Ibiza. This works
signed in as a friend or holding the admin passphrase, and it exists because before it,
a country’s own page was the only page that could show its unlisted albums
— publish an album as unlisted, look anywhere else, and the site showed no trace
of it, which reads exactly like the album being lost.
If an unlisted album looks missing on the live site (30 August 2026). It is
almost always the browser you are looking with, not the album — so check in this
order. 1. Are you on www.traveller.org? 2. Is the purple
Signed in as a friend banner across the top? No banner means this browser is not
signed in, whatever it did earlier: sign in again at
www.traveller.org/friends/. 3. With the banner showing, the album is
in three places — its own page, its country’s page, and the
Photographs page, which lists every unlisted album whatever its country.
4. Signed in in a private / incognito tab? That sign-in does not carry to
your normal tabs — each has its own cookies — so sign in again in a normal
one. Different browsers are separate too: signing in on DuckDuckGo does nothing for
Chrome. 5. Missing from the uploader’s album picker or a Gallery cleanup
droplist rather than from the site? That is a different list, built by the Worker walking
storage — and note it names an unlisted album by its folder, so it reads
ibiza, not Ibiza. 6. Still nothing? Hard-refresh once. The whole journey — sign in, open the
album, find it on both listings — is checked on every push by
tests/friend-sees-album.test.mjs, over the real albums by name, so a genuine
site fault would fail a test before it reached you.
Open the album on the live site (for an unlisted album you’ll be signed in as a friend to see it at all) and press Share with a friend in the purple bar at the top. Since 4 September 2026 the same bar appears on a public album that carries friends-only photographs — signed in as a friend, you’ll see Friends-only photographs — visible to you above the album with the same button, since the mixed view is exactly the thing worth sharing. A stranger’s copy of the page has no bar at all — it only appears once the friends door has answered for you. On a phone that opens the share sheet straight into Messages; on a computer it copies the link. Either way the link is the one-tap kind: it carries the friend password, signs the person in for a year on that device, and lands them on the album you shared — nothing for them to type.
Treat the link like the password, because it contains it — fine to text a friend, not for anywhere public. The button appears only when you are signed in as a friend yourself, and the password inside the link is filled in by the server at that moment: it lives in no page. Rotating the password kills every link ever shared this way, along with every signed-in device.
The password is the FRIEND_KEY setting on the Cloudflare Pages project
— never in the site’s code and never on any page. In the
Cloudflare dashboard: Workers & Pages
→ the site’s Pages project → Settings → Variables and secrets, add or
edit FRIEND_KEY for Production, then redeploy (the next
Publish does it). Changing it signs every friend out
at once — that is the whole reset if the password ever travels too far. Until you
set it the first time, the door stays shut: unlisted pages answer “switched
off” rather than opening.
www.traveller.org,
and the friends-only photographs inside public albums.images.traveller.org, which remain public addresses.Separately from whole unlisted albums, any photograph in a public album can be marked friends-only: it comes off the public page and out of every count, and a signed-in friend sees the album complete, each hidden photograph back in its true place. Nothing moves in storage — this is a visibility switch, not a file operation.
To mark or unmark: open the album on Gallery cleanup, select the photographs, and press ⊘ Friends-only (or Public again). Or do it where you spot it (3 September 2026): on any high-resolution album’s photo view, the admin bar above the photo has the same ⊘ Friends-only button for the photograph on screen — and on a friends-only photograph (signed in as a friend, so it is woven into the album) the button reads Public again and reverses it. It refuses the last public photograph, the same guardrail as everywhere else. On the phone the action bar has one Friends button that reads the selection: photographs already marked go public again, anything else gets marked. Marked photographs wear a purple ⊘ friends badge in the grid — the same purple as the Unlisted mark, one colour for “the public does not see this”. The change lands in a minute or two, like a rotation.
A wrong guess costs a delay and the door never says whether it was close. The sign-in page is deliberately unlinked from the public site — a hidden address, which costs a stranger one more thing to know without costing a friend anything.
A film can now be unlisted the way an album can: off the public site entirely — the films pages, the home-page strip, every count and every machine feed — while a signed-in friend sees it on the films pages in its country’s own group, marked by a small purple ⊘ Unlisted chip on the poster — the duration chip’s own shape, in the colour that means “the public does not see this” — and plays it there like any other film. A note under the list explains the chips once, the way the album pages do.
Two ways to set it:
The one honest limit, chosen deliberately: unlisted means undiscoverable, not unwatchable. The film’s .mp4 file keeps its public storage address — the same standing rule as every photograph on the site — so someone holding the direct file link can still play it. Nothing on the site, in Google or in the AI feeds will hand that link out.
Both choose themselves already: a country’s home-page card shows a photograph from its first gallery, and each gallery’s strip on the country page shows four spread evenly through the album. Cards & strips is for pinning a particular picture instead.
brazil/2005/rio held
159 files and published 18. Pinning one of the other 141 would have shown nothing, and the
run refused it one at a time (owner, 20 August 2026). If a photograph you expect is missing
from the picker, that album needs a sync or a re-import — ask in a session.vietnam/2009), an optional Location (e.g. Halong Bay), the Title, and a sentence or two of Description — the title and description are shown on the site exactly as typed./countries/vietnam/films/), and the site-wide films page.src/data/films.json. (The CMS will make this a form field at launch.)Two ways, both permanent — the photo comes off the gallery and is deleted from storage to save space. No copy is kept, so download anything you want to keep first (the batch zips are the archive of record).
india/1998/delhi vs india/2005/new-delhi).gallery-index.json), so the Photos, Covers and Journal pages and the upload
page all changed together.-r1, -r2, …): the old one is cached "immutable" for a year, so
turning it in place would leave stale sideways copies in browsers and on the CDN. Its
position in the gallery, place tag, and any home-page cover reference all carry over —
and the grid on this page now shows it in that position straight away. (It used to show a
just-rotated photo at the end until the site redeployed, which read as the photo having
moved; it never had.)-m1 suffix. Moving every photo out
of an album is refused — that is a delete or a rename, done deliberately instead.china/2025/great-wall for a 2005 trip): the same card shows the
Album path field for high-resolution albums. Type the corrected
country/year/name and hit Save & move album — every photo is
relocated inside storage (no re-upload) and reprocessed at the new address, done in a few
minutes. Two things to know: links to the old address stop working, so correct a
path early rather than after it has been shared; and the field refuses to move an album
onto a path that already exists — that would merge two albums, which is what the photo
Move tool is for, done deliberately. Legacy albums have no path field: their images
live on the old server, untouched.burma/2001/rangoon beside TYPE THE
ALBUM PATH TO CONFIRM, type that. A high-res album is purged from storage and comes
off the site: permanent, with the batch zips as the only archive. A legacy album
just comes off the site (record + repo thumbnails); the old scans stay untouched on the
legacy server — use this to retire a deprecated album early once its replacement is
uploaded, instead of waiting for the launch prune. A confirmation email arrives either
way.After a removal the pipeline syncs the gallery record and the site redeploys itself — allow a few minutes for the public pages to catch up. The photo view updates instantly for you. Legacy 800px galleries have no removal controls; they're deprecated wholesale and pruned at launch.
Opening a single photograph on a phone used to spend the screen on everything but the photograph — masthead, crumb, album title and, for you, the five admin buttons, with the picture squeezed to about a tenth of the glass. You chose Option A of the photo-view design boards and it is built:
Swiping left and right still turns the pages, and Previous / Next are still under the caption. If the photograph looks small in a way these changes should have fixed, check you are not in an old tab — a page open from before a publish keeps its old layout until it reloads.
src/data/places.json.The upload page now works fully from a phone: tap the big box and it opens your photo library — multi-select as many as you like — and a new gallery needs no path typing at all: pick the country, confirm the year (it pre-fills from the photos' own dates), type just the name. HEIC uploads as-is, photos publish upright, and big photos shrink on the phone before uploading so a batch costs about a quarter of the data. There is also a one-time Shortcuts setup that puts "Upload to traveller.org" in the Photos app's share sheet. Setup steps for both — home-screen app and share sheet — are on the iPhone uploads page.
For photographs that live in iCloud Photos on a machine that is not the one in front of you. Nothing downloads to your computer or your phone: you hand the site the link Photos makes, and the originals are copied from Apple straight into the album on the site’s side, then imported onto staging exactly like a dragged-in batch (Publish sends it live) — same 2048px size, same thumbnails, same duplicate check, same confirmation email.
https://share.icloud.com/photos/0abc….
An emailed link from Photos is the same thing — copy the address out of the email.Then it is the usual few minutes: the run copies the originals, imports them and deploys staging; the confirmation email lists what arrived. Things worth knowing:
IMG_2427-2.JPG) — nothing is ever written over. And the import’s own
duplicate detection — pixel fingerprints, checked across the whole site — then
catches the same picture under two names, exactly as it does for a dragged-in batch.IMG_2428-2.JPG — nothing is
overwritten.Renamed from “Notes” and the naming is now optional (25 August 2026): on the phone, the Currency screen takes plain photographs with no filename at all — Claude identifies each note in the pipeline and files it (see the phone page). The naming below is the desktop path, and still the only way to say a name explicitly or upload PSDs.
High-detail note images come in through the Notes tab on the upload page (beside Photos and Film). PSD source scans, JPEG, PNG, TIFF and iPhone HEIC all work — front and back are separate files.
<country>-<denomination>-f
for a front, -b for a back, with a variant between denomination and side when
there is one. india-10-brown-f.psd, australia-20-b.jpg,
newzealand-5-f.heic. The country may be several words joined by hyphens
(cayman-islands-1-f.jpg) — what separates it from the denomination is
that the denomination is the first part beginning with a digit. Existing countries
keep the slug the site already uses (newzealand, srilanka,
hongkong) — or the country's name, which is often easier to
remember: turkiye-10-f.jpg and turkey-10-f.jpg both land on
Türkiye, and czech-republic-20-f.jpg works as well as
czech-20-f.jpg. Accents and spacing are ignored, so the name can be written
however is convenient. The plan shows which country each file resolved to before anything
uploads.brazil-1-a071-f.jpg for the note the site
calls brazil-1), files it as a new note beside the old one, and the
collection lists the same banknote twice. To replace a note, name the file with its
existing id exactly; add a variant only for a note the site does not have yet. The run also
warns when it creates a note whose denomination already exists un-re-shot — tell
Claude in a session and the superseded record is removed.currency-in/.After a batch, the run’s report lists every photograph it could not place and why — not sure enough, the reader timed out, or two photographs of the same face arrived together and only the first could take the name. Those wait in the bucket; nothing is lost, and nothing happens to them on its own.
You usually know exactly what each one is. To tell the site, run the pipeline in currency mode and put this in files:
{"name": {"1789320813201-59.jpeg": "france-10-richelieu-f.jpg"}} One line per photograph: the file as the report named it, then what it is —
country-denomination-f.jpg for a front, -b.jpg for a back, adding
the series after the denomination when the country has more than one note of that value
(france-10-richelieu-f.jpg). Your answer is taken as final; the reader is still
used to cut the note out of the photograph and stand it upright. A name typed wrongly is
refused before anything is written, and a name already in use is refused rather than
written over.
The Banknote pages page lists every note in the library with the picture it shows — the way Journal photos lists every letter. Narrow it by country, search it by denomination or currency, or use the four state chips: All, Written by Claude, not yet read, No write-up yet, and Still on the old picture. Every row says which of those it is, so nothing is hidden behind a queue.
The write-ups are already live — they go onto the note page as soon as they are written, because a described note beats an undescribed one and waiting for approval left every page showing filler. This is the editor, not a gate.
The backlog is gone (25 August 2026). You asked for the 214 write-ups sitting in Written by Claude, not yet read to be marked approved, and they were. Nothing on the site changed — those write-ups were already published; what went was the queue, which is now empty. Each of those notes still says “written by Claude 2026-08-19, cleared unread” on its own card when you open it, so you can always tell whose words they are; reading one and saving it makes it yours in the usual way. New notes scanned from here on still arrive in the not yet read chip, so the queue works exactly as before — it just starts from empty.
Label: value lines —
with a link to the live page beside the title.Under the list, a button offers to write up every note in the list in front of you that has none — so filtering to one country and pressing it drafts that country. A note still on its 100 px picture can be written by hand but not drafted: nobody can read a note off an image that size. Re-scan one through the Notes tab and it becomes draftable. A Collected row never comes from a draft: the site derives where and when from your own galleries and letters.
If the page says drafting is not configured, the two GitHub settings it needs are in
the pipeline page’s credentials table
(ANTHROPIC_API_KEY secret, ANTHROPIC_MODEL variable).
src/data/currency.json (on
GitHub, or ask a session) and add any of: series, years,
mm, art.front, art.back, circulation,
and facts (label→value pairs — a label matching an automatic row, like
Issuer or Collected, replaces it in place; a new one, like Watermark,
adds a row). The India ₹100 is the fully written working example; the India ₹1 shows a
single-fact override (its issuer is the Government of India, not the Reserve Bank).Two things you reported on the Edinburgh letter, both fixed for every entry and for every entry written from now on:
The Journal editor opens any of the letters on the page itself — the prose you edit is in the site's own typography, so what you see is what publishes. Pick the entry, then:
pub-…r2.dev address, and anything the build produces goes onto the staging site.
An unpublished letter should be neither. If you want drafts to follow you between devices,
tell Claude — it needs a private second bucket, which is a five-minute change./journal/a-night-in-mandalay/), so a title already in use is refused before
anything is sent; give it a different one. Title and date are required, and the excerpt the
index shows is taken from the opening of the prose rather than typed.The quickest way in is from the letter itself. Reading any letter on the site while this browser holds the passphrase, an ✎ Edit this letter control sits above the prose and opens the editor on that entry — no hunting through a droplist of 161. A visitor never sees it; it is the same passphrase-in-this-browser test the photo view uses for Rotate and Remove.
The confirmation appears in the toolbar beside Save, not under the prose — on a long letter the foot of the page is two screens away from the button that was pressed. Beside it, when you arrived by pressing ✎ Edit this letter on the letter itself, is ‹ Back to the letter (13 September 2026) — the way back to the page you were reading, there before and after the save. It appears only when the visit began at that letter and that letter is still the one open: pick a different one from the droplist and it goes, because there is no longer anywhere to go back to. Give staging its couple of minutes before expecting the change to show on the page you return to.
Save entry (or Publish new letter) sends it down the same path as every other tool — the pipeline sanitizes the markup to the journal's own vocabulary (a photograph that no longer exists is refused by name), commits, and staging updates in a couple of minutes. Photographs are stored by bucket key, never by URL, so the same entry is right on staging today and on www.traveller.org after cutover.
The picture belongs to the letter first (your rule, 13 September 2026). In order: the photograph you pinned on Journal photos; failing that, the letter’s own first picture — one you placed in the Journal editor, or one that came with the letter from the old site; failing that, a photograph of that country and that year; failing that, the country’s locator map (and for the two entries with no country, nothing). This is what the journal index and the country pages both show.
Two things changed that day. Six letters that carry a picture of their own were showing a stranger’s photograph from the same country — they now show their own. And the automatic choice is the same year only: it used to fall back to any gallery of that country, so a 1992 letter could be illustrated by a 2016 photograph. Where there is no photograph of that year the map is shown instead, which is the honest answer. Nothing needs doing for any of it — it follows your imports by itself, and an entry gains a real photograph the moment its country and year do.
A pick shows everywhere that entry appears as a card — the journal index and the “From the journal” panels on its country page. (Until 2026-08-19 the country pages ignored the picks and showed the locator map or an old GIF instead; they no longer do.)
Only high-resolution albums are offered, deliberately: the legacy 800 px albums are being retired, and an entry pinned to one would lose its picture at the launch prune. If a pinned photograph is later deleted or rotated, the entry quietly falls back to the automatic choice rather than showing a gap.
The rotating photographs that open the home page are managed at the top of Cards & strips — no country needs to be selected, the carousel belongs to the whole site. Connect and the current slides appear in order, each with its photograph, caption and photo key.
If every slide ends up removed or unloadable, the home page does not go blank: it opens on the largest high-resolution galleries’ first frames until you pin slides again.
The journal entries the home page shows under Letters home are chosen on the same page, in the section under the carousel. Until 21 August 2026 there was no control for this anywhere — the list lived in a data file, and the only way to change it was to ask in a session. It is now yours.
If a row says “Entry 412 — no longer on the site”, that entry has been deleted since it was featured. Remove the row. The save is refused while it is there, for the carousel’s reason: the run checks every entry and refuses the whole save if one is unknown. Before this section existed the home page simply showed one panel fewer, which looked like a design choice rather than a missing entry.
Every day, Google, Microsoft and others send a report to
dmarc@traveller.org listing everything that sent mail claiming to be this
domain. You do not have to read them. The traveller-dmarc Worker reads
each one and writes to you only if something needs acting on — a clean report
produces no email at all, and clean is what they have been.
If one does arrive, it names what happened in plain words and what it means: a service of yours whose settings need fixing, or somebody using the domain’s name. It also arrives if a report could not be read, because silence has to mean “checked” rather than “broken”. Forward it here and it can be dealt with.
Both switches were thrown on 10 September 2026 — the routing rule points at the Worker and its key is set, so this is running now. The two steps are kept below because they are what to redo if the rule is ever lost, and because the second explains where the reports went.
dmarc@traveller.org is not a
new address — you created it at cutover (step 15) forwarding to
brarob@gmail.com, which is how these reports have been reaching you. So this is
an edit, not an add: open
Email Routing
→ routing rules (that link opens the right page inside the
traveller.org zone — Email Routing lives per-domain, not at the account
level, which is what makes it hard to find by clicking), find the dmarc row,
and change its action from sending to your Gmail to Send to a Worker →
traveller-dmarc. It is the same change theboys@ already uses.RESEND_API_KEY (encrypted), from a fresh key at
resend.com → API Keys.A report forwarded to you with no note explaining it means the Worker read it and could not write to you — almost always the Resend key. The reason is in the Worker’s own log (traveller-dmarc), and the report itself is safe in your inbox meanwhile.
You will stop seeing the daily reports, which is the point — a routing rule has one action, so the Worker receives them instead of your inbox. Nothing is lost when it matters: if the Worker finds something wrong it forwards you the original report along with its explanation, so the evidence arrives with the alarm. The pipeline page has the detail of what it does and does not alert on.
contact@traveller.org, subject “traveller.org — message from
<name>”. There is no queue, no dashboard, and nothing to log in to.burma/2001/bagan were re-developed in August 2026,
compared side by side, and the re-developed album was deleted. Nothing needs doing; it is
noted here so the offer is not made to you a second time.Several apps will hang off this domain, and each needs an end-user guide — steps to follow while doing something, a reference to look things up in. They all live on one shelf: www.traveller.org/guides/, one card per app, each card listing that app’s pages in order. This site’s own guide is the first on the shelf (getting around, signing in as a friend, sending photographs from a phone); the other apps are listed and join the shelf the moment they have a page.
The shelf is open — no login, for now. You chose on 5 September 2026 to
put it live without a door: the pages are unlinked from the public site, marked
noindex, kept out of the sitemap and disallowed in robots.txt,
but anyone who has the address can read them. So write every guide as if it were
public — no passwords, no addresses that should stay private. The door that is
planned is a second Cloudflare Access application on
www.traveller.org/guides* with its own allow-list (you first, then an
app’s users as each app joins), kept separate from the admin’s so admitting a
reader never admits them to the admin; it is an open item on the
runbook for when you want it. A guide page
carries no admin nav, no login widget — and, since 2026-09-06, no site nav
either: the shelf is its own standalone area, free not to match the site’s design
(your call). Its wayfinding is the back link and each app’s own sidebar; the App guides entry under
Manual in the admin nav is just a link across.
docs/guides/ — one file per page, images beside them in any
sub-folder (docs/guides/img/…, referenced with a relative path). Each file
starts with a short header:
--- title: Sending photographs from your phone order: 3 summary: One line for the app's contents page. ---Only
title matters; without it the sync writes one from the first heading
(or the file name). order sorts the pages; summary is the line
under each title on the app’s landing.src/data/guides.json in this repository:
its slug (becomes the address, /guides/<slug>/), display name,
repository and the folder above. The eight repositories being tracked are already
listed, so for those this step is done.- run: gh api repos/brarob100/traveller.org/dispatches -f event_type=guides-updated
env:
GH_TOKEN: ${{ secrets.CENTRAL_DOCS_DISPATCH }}
where the secret is a token allowed to dispatch on this repository — its own row
(CENTRAL_DOCS_DISPATCH) in the credentials table on the
pipeline page says how to mint one and where
it goes.The same steps, written for the moment they have been forgotten, are the shelf’s own first guide — Centralized Documentation → Adding a new app to the shelf — which ends in a prompt to paste into a Claude Code session on the new app’s repository, so none of it needs a terminal.
The sync needs one credential, CENTRAL_DOCS_GIT_TOKEN — a
fine-grained GitHub token that may read the app repositories and nothing else.
Until it exists the nightly run ends green having done nothing, and says so; the
credentials table on the pipeline page says
where to create it. This site’s own guide needs no token: it is written straight
into src/content/guides/traveller/ in this repository, and editing it is
editing those markdown files.
Starting a session to write these guides? The prompt that starts one
lives in the repository at docs/guides-workstream-prompt.md — open a new
chat on the traveller.org repository and paste it. It carries everything a
fresh session needs (the shelf, the convention, the eight apps, the standing rules), so the
guides work does not have to share a session with the photographs and the journal.
Deleting a page upstream deletes it here on the next sync; deleting an
app’s whole docs/guides folder takes it off the shelf. Nothing on the
shelf is indexed: every page is noindex, none is in the sitemap, and the
live robots.txt disallows /guides/ beside /admin/.
src/styles/global.css (tokens at the top: paper, ink, accent, the five region colors) and the layouts in src/layouts/ and src/pages/.design/site-daylight.html — change the reference first, then the site, so they never drift.