Easy-to-manage touch screens
Free, open-source touch screens. Guided USB setup, a drag-and-drop editor and local control. Made for Home Assistant.
翻訳待ち
No updates detected yet. GitHub releases will appear here.
Loading the full README. The saved excerpt is shown below.
A living city guide you operate, not just read.
AI engines produce good city research in minutes, but the output is a wall
of text you re-scroll all week while the real trip mutates around it:
plans reorder, options die ("full tonight"), backups get promoted, and
half the value is discovered on the ground. Nomadding owns the layer between
AI research and the actual week: a guide with a working memory.Read the full README ↗A living city guide you operate, not just read.
AI engines produce good city research in minutes, but the output is a wall of text you re-scroll all week while the real trip mutates around it: plans reorder, options die ("full tonight"), backups get promoted, and half the value is discovered on the ground. Nomadding owns the layer between AI research and the actual week: a guide with a working memory.
Live app: app.nomadding.com · Example guide: example.html · Deep dive: docs/ARCHITECTURE.md
This public repo ships the app plus one bundled example city. The real city guides it was built around (and field-tested on) are personal travel data and live out-of-repo by design, in a private deployment of the same code.
| Planner | Review-verified intel |
|---|---|
plan, backup, done, or
archived, with one-tap moves and undos. Days are chronological slots;
drag a day's content elsewhere and the dates stay put while the plan
reorders. Rename items, collapse sections, collapse whole days once they
are done; everything persists.must / good / skip verdicts on
specific dishes and specifics-of-the-thing (which route, which seats,
which add-on), plus tips and a source line. A real pass on a lived-in
guide produced 25 items with 73 verdicts, built from per-dish review
data, and corrected the guide's own prose in four places.template.html to <city>.html (e.g. lisbon.html).PROMPT.md with the city, dates,
accommodation, and traveler profile, then paste the whole prompt into
Claude, ChatGPT, or any capable AI engine. It returns a single JSON
code block.<script type="application/json" id="city-data">
block in <city>.html, orcities/<city>.json and run
node tools/embed.js cities/<city>.json <city>.html.Or skip the file entirely: open the app, tap the city name, + Add city, and either paste generated JSON or start a blank city from a name and dates. Build my prompt assembles step 2 for you, with your saved interest profile included.
Each place has a lifecycle: plan (the current pick), backup (the
alternative when plan A falls through), done (visited; recedes but
stays visible as the trip record), and archived (out of the way,
recoverable). One-tap controls move items between states; every move is
undoable, and controls only render where the action is valid.
Days render as chronological slot cards, including empty days, so anything can be dragged or moved onto any date of the stay. Share flips to a clean read-only view (prints as a one-pager). Export downloads schema-valid JSON with your live changes baked in; the round trip back through paste is lossless by test. Update data and Enrich accept pasted JSON on the go: Update data replaces a city's research wholesale, Enrich merges a delta (new interest matches, or an intel pass) without touching anything you've done.
Somewhere recommended over dinner goes in by hand from the + on any section header, and the card that appears carries an Ask Claude control that looks the place up and ranks it against the rest of that section: "ranks 2nd of your 11 dinner picks". The header carries a single row of highlights above the city's facts: today's sunset, computed on the device from the city's coordinates with no network call, and up to four pinned items, so the tap-water rule sits in the header instead of eleven screens down the Info tab.
Run tools/verify.sh before opening a PR; paste its last line in the PR
body. It runs the unit suite, the build, the drift guard and the headless
browser checks, prints one line per stage, and exits non-zero on any failure.
Only the headless stage needs a network: VERIFY_SKIP_HEADLESS=1 skips it with
a visible SKIP line.
This is the beginning of the README. Read the rest at the original. Read the full README ↗