AmoleoFamily

Process & Registry

Mission Statements

Every family website's mission — the umbrella first, then every registered repo. A repo with no MissionStatement.md entry in the master registry yet says so plainly rather than being left out.

Amoleo·Family

Repo: Amoleo-Family (umbrella workspace)
File: MissionStatement.md

One-Liner

Keep Amoleo consistent — one brand, many separately deployed products, no silent drift.

Private Mission

We maintain the Amoleo family's visual and conceptual coherence across many independently deployed codebases. We do this by:

The failure we prevent is the quiet one: a wrong footer sitting in production for weeks because nobody noticed it until they opened two sites side by side. Every shared rule gets a written spec and an automated check. A rule that only exists in prose is one repo away from being untrue.

We are ruthlessly practical about the cost of this approach: shared presentational parts (wordmark, footer, header, auth-box, base theme) are copied into each repo, not linked at runtime — no site's first paint depends on another site being up. Revised 1 Sept 2026: shared services are the deliberate exception, and now the norm for anything service-shaped rather than a special case argued per repo — Registry, Accounts, Communications and Images are always called live, as long as doing so is secure, with every consumer failing gracefully if the call doesn't land. Extended 2 Sept 2026 to public-product-to-public-product calls too (client-side, browser-driven, same graceful-degradation bar) — the family is allowed to speak to each other, but it must always fail gracefully. See CLAUDE.md's "What this repo is for" for the full reasoning.

Public Mission

Amoleo is a family of products spanning pet care, K-Drama discovery, family history, personal tasks, a shared identity provider, a film/TV edition catalogue, curated watch/read/play lists, a personal item collection tracker, a shared canonical-identity service, a comments/email/push service, user reviews, and a central image service — with more added as real personal needs come up, not according to a fixed roadmap. We keep them looking and feeling like they came from the same place, even though they're built on different stacks and deployed separately. This repo holds the shared rules that make that possible.

Amoleo·Website

Repo: Amoleo-Website (AmoleoWebsite)
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

The front door to everything Amoleo.

Private Mission

The main website is not a product in itself; it's a discovery and direction service. Its mission is to help a visitor understand what Amoleo is, discover which of our products solves their problem, and get them there with minimal friction.

For a visitor landing on amoleo.com, the questions we answer are:

Secondary to that: building confidence in the brand and helping people understand that our products are built with care. But the primary mission is to be a clear, honest, fast entry point.

Decisions should prioritize clarity and simplicity over visual flourish. Every pixel should answer one of the four questions above. Don't build for depth (Pets, Connections, Rissbrook build depth); build for breadth and clarity.

Note: the front page only ever lists the family's public-facing products — see tools/product-order-surfaces.json. Registry, Communications, Images and Recommendations are behind-the-scenes and never appear here, by design, not by omission.

Public Mission

Amoleo is a family of tools for pet owners, drama fans, family historians, and anyone who benefits from organized, personal information. Visit us to discover which Amoleo products work for you.

Amoleo·Rissbrook

Repo: Amoleo-Rissbrook (RissbrookWebsite)
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Preserve the genealogy and history of the Rissbrook and Bickley families.

Private Mission

This site exists to preserve Robert Bickley's genealogical research on the Rissbrook and Bickley families — a finite, irreplaceable resource that would be lost without ongoing preservation. The mission is archival and memorial: keeping that research accessible, findable, and intact for future generations who may be researching their own family histories.

Unlike Pets (which serves active users logging weight) or Connections (which serves discovery), Rissbrook serves a different need: historical preservation. It is not a social feature, not a service with repeated use, but a reference and memorial. Decisions should prioritize preservation, accuracy, and permanence over engagement.

The site is free because Robert Bickley's research belongs to the families it documents, not to us. There is no Premium tier here — this is a public good, kept alive as long as the Amoleo family exists.

Public Mission

Amoleo Rissbrook preserves the genealogical research of Robert Bickley on the Rissbrook and Bickley families, providing a permanent, accessible archive for descendants and family historians.

Amoleo·Pets

Repo: Amoleo-Pets (PetWeightTracker)
File: MissionStatement.md

One-Liner

We value the health and wellbeing of all pets — and especially cats.

Private Mission

Helping owners keep their pets healthy is the primary focus of this app, and every feature and decision should serve that goal first, above all else.

Secondary to that: helping owners share their pet's moments (photos, public profiles, wrapped summaries) and explore their pet's genealogy (family tree, #52). These are real value in their own right, not just dressed-up health features — but they're secondary. When a health-serving decision and a sharing/genealogy-serving decision conflict, health wins. A feature doesn't need a health angle to be worth building, but it must never come at the health mission's expense (e.g. never let a sharing/genealogy flow add friction to logging a weight or a treatment).

Free by default: We intend to provide as much as we can for free, as long as it costs us nothing beyond the baseline (hosting, domain names, development tools). If something could serve the mission — health, sharing, or genealogy — but carries an additional cost to us, we won't ignore it — but it will always live in the Premium tier. The Premium tier will only ever contain features that cost us money to run; anything that doesn't cost us anything stays free, always.

Public Mission

Amoleo Pets helps pet owners keep their beloved animals healthy by making it easy to track weight, medications, and treatments. Share your pet's moments with others and explore their family tree.

Amoleo·Connections

Repo: Amoleo-Connections (K-Drama Connections)
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Explore the actors and connections that weave K-Dramas together.

Private Mission

We help K-Drama fans discover the hidden network of actors and relationships that span multiple shows. The primary mission is discovery: making visible the connections between shows that aren't obvious from the surface (an actor appears in two shows, a K-pop group is featured in a drama, etc.). This turns passive watching into active exploration.

Like Pets' genealogy feature (secondary but valuable), genealogy here is real value: helping fans trace an actor's career, understand K-pop group involvement in dramas, or explore a show's full cast web. But the core mission is discovery, not archiving.

We keep the core experience free and the data open. If we add features that cost us money to run (e.g. real-time syncing with external K-Drama databases, premium actor insights), they live in Premium. Everything else — the graph, the connections, the actor info — stays free.

Public Mission

Amoleo Connections helps K-Drama fans discover the actors and relationships that weave their favorite shows together. Explore which shows share cast members, trace an actor's career, and find new dramas through the connections you care about.

Amoleo·Accounts

Repo: Amoleo-Accounts
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

One login across all Amoleo products.

Private Mission

Accounts is an infrastructure service, not a product users engage with directly. Its mission is to remove friction: a user who wants to try Pets and Connections should need only one login, not two separate registrations. It enables users to build a unified identity across the Amoleo family.

Beyond friction removal, it enables future possibilities: preferences that follow a user across products, a unified dashboard, personalization that spans apps. But the immediate mission is simplicity and convenience.

Because Accounts is a service layer, decisions should prioritize reliability and simplicity over features. Security is non-negotiable (this is where user credentials live). Every feature should serve the core mission of reducing friction; anything that adds complexity to login or credential management loses.

Public Mission

Amoleo Accounts provides unified sign-on for all Amoleo products, giving you one login across Pets, Connections, and everything else we build.

Amoleo·Todo

Repo: Amoleo-Todo
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Organize your goals and tasks — one personal system for everything.

Private Mission

Todo is a personal productivity tool. Its mission is to help users organize, track, and complete the work that matters to them — both the big goals and the daily tasks. Unlike Pets (which serves health) or Connections (which serves discovery), Todo serves personal agency: keeping you on top of what you said you'd do.

We stay ruthlessly simple. Every feature we add should help you remember and complete work; anything that adds clutter or process overhead loses. We are a tool, not a workflow — get out of the way and let the user decide how to organize.

Early on, Todo is standalone. Later, it could integrate with Accounts to enable cross-Amoleo features (e.g. "remember to log weight" reminders, K-drama watch goals), but those are future possibilities, not the core mission. The core mission is being a reliable, uncluttered personal task manager.

We may add a Premium tier for features that cost us money to run (e.g. advanced analytics, integrations with external services, extra storage). Core task management stays accessible.

Public Mission

Amoleo Todo helps you organize your goals and tasks in one place. Keep track of projects, break them into actionable steps, and stay on top of what matters to you.

Amoleo·Editions

Repo: Amoleo-Editions
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Every edition of a film, concert or show — and how to sync them.

Private Mission

Editions is a collaborative catalogue. For any given title, there are often several editions — different regions, years, discs, streaming platforms, cuts — and their audio tracks are frequently offset from each other by a fixed, discoverable amount. Matching that up today means owning multiple copies and doing frame-by-frame comparison by hand. Editions' mission is to be the shared, structured record of what those editions are and how they line up, built by the people who already do that work for themselves.

Two things it deliberately is:

  1. A specification library — codec, resolution, HDR, audio tracks and special features for each edition, held as structured, lookup-backed fields wherever there's a fixed set of options, free text only where there has to be.
  2. A sync registry — frame-accurate reference points tied to a recognisable moment in the title, from which the delay between any two editions that share a point can be derived.

Data is never all-or-nothing. A record with just a title, region, year and format is worth having; every other field is fillable later, by anyone. Encourage completion, never require it.

Writing is gated to a Contributor role, above plain Viewer — sync data is only trustworthy if the people entering it can be held to it, and a wrong offset does more damage than a missing one. Anyone can read; not everyone can write.

Editions builds outward in a fixed order: Movies, then Concerts, then TV Shows — each stage widens the schema (TV adds season/episode structure) without disturbing what came before, and each is intended to actually ship rather than stay a permanent "someday."

Revised 1-2 Sept 2026: Editions' Title/Edition entities are now Amoleo Registry entries, not Editions' own private records — see Amoleo-Registry/docs/Architecture.md. Editions owns the rich comparison/scoring data layered on top, not the bare existence of an edition.

Public Mission

Amoleo Editions is a collaborative catalogue of film, concert and TV releases. Look up every edition of a title, see how its specs compare, and find the audio sync offset to line any edition up with any other.

Amoleo·Upnext

Repo: Amoleo-Upnext
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Curated orders for what to watch, read and play next — tick off your progress as you go.

Private Mission

Upnext is a curation product, not a personal-list builder — for its public, discoverable surface. Editors — currently just the family — decide what lists get published, found through search, and recommended; standard users subscribe to those and record their own progress against them, never create one of their own. That's a deliberate constraint, not a v1 shortcut: the product's discovery value is the quality of the curation, and its growth there is bottlenecked by editor time by design. We don't try to scale published content by opening up public-list creation to everyone.

Revised 1 Sept 2026: standard users can build their own private lists — share-link only, never searchable or recommended — including system-provisioned ones like a personal Watchlist or Backlog. This isn't a reversal of the constraint above; it's a distinction the original text didn't yet draw. The constraint was always about the curated, discovered surface, not about whether a person could keep their own private list of things to get to — the two don't compete for the same editor-scarce resource, and a private list never appears anywhere a public one would.

Users must be alerted when a list they follow changes — an editor reordering or adding to a list they're partway through is exactly the moment they need to know.

Upnext requires sign-in via Amoleo Accounts. Permissions (who's an editor) are stored in Upnext's own database against the Accounts reference ID, the same pattern every other family product uses — Accounts is identity only, not authorization.

Upnext has a genuine sibling: the "Up Next" feature in the separate, unbranded MagazineScraper desktop app, which drives a physical Kindle over USB. The two are not the same list mirrored for convenience — the desktop app is a full second editing surface with real two-way sync, not a read-only Kindle-export view. Reconciling concurrent edits between the two is treated the same way concurrent edits between two editors on the website would be, on the basis that the desktop app is always-online and has at most one editor actually using it in practice.

Public Mission

Amoleo Upnext gives you curated orders for what to watch, read and play next. Find a list, follow it, and tick things off as you get through them — you'll always know what's next, and you'll hear about it when the list changes. Or build your own private list — a Watchlist, a Backlog — just for you.

Amoleo·Collections

Repo: Amoleo-Collections
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Catalogue what you own, in a flow fast enough to actually finish.

Private Mission

Collections exists to solve one specific failure mode: cataloguing tools that are too slow to ever get past the first ten items. The add flow is the product — a full-screen, one-fact-at-a-time sequence (name, then photos with skip available on each angle, then price paid, then storage location) that moves straight to the next blank item rather than back to a dashboard. If a change makes adding an item slower, it needs a very good reason.

Unlike Upnext, any user can build and own their own collection — there's no editor gate here, because "what I own" is inherently personal, not curated content.

Every catalogued item marks itself digital or physical — a $60 Steam library entry and a $60 physical copy of the same game are not interchangeable facts, and the data model treats them as genuinely different records, not a single "owned" flag. Items synced automatically from a platform (Steam now; Xbox and PlayStation are open questions, PSN specifically has no official API and is treated as best-effort at most) start as thin, unverified records — a title and nothing else — and are never presented as equivalent to a fully catalogued item with photos and a price until a user fills the rest in.

Revised 1-2 Sept 2026: adding an item from Amoleo Editions ("Add to Collection") produces this exact same thin-record state — pre-filling a name doesn't touch what actually makes a record complete (real photos, price, storage), so both origins share one unified "needs completion" view. Collections also now exposes a public, Accounts-authenticated API so other products (starting with Editions' "In My Collection") can check ownership client-side.

Collections holds no canonical "what is this" data itself. Every item resolves to an entry in Amoleo Registry, tracked at the Edition level (not just the Title), a shared internal service also used by Upnext, Editions and Reviews — see docs/Architecture.md. This is what makes cross-product features like "which of my Upnext lists' entries do I already own" possible without fragile text matching. Registry never receives personal data: photos, price paid and storage location live in Collections alone.

Collections requires sign-in via Amoleo Accounts.

Public Mission

Amoleo Collections helps you catalogue what you own — snap a few photos, note what you paid and where it lives, and move straight on to the next item. See at a glance which of your Upnext lists you've already got covered, or add straight from an Editions page.

Amoleo·Communications

Repo: Amoleo-Communications
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

The family's single point for talking to people — comments, email, push, and whatever's next.

Private Mission

Communications exists to stop five apps building five slightly-different copies of the same problem: how do you let someone comment on something, send them an email, or push them a notification. It's infrastructure, not a destination — thin user-facing side, like Accounts and Registry, with the real work happening across two backend surfaces built for very different trust levels.

The public surface (comments) is reachable directly from a stranger's browser and has to defend itself — real rate-limiting, real moderation, Accounts authentication on every comment, no anonymous posting. The internal surface (email, push) is only ever reached from another family app's own server, the same shape Registry already uses.

Centralizing push here — rather than every app running its own, as originally sketched for Upnext modelled on Pets' existing system — was a direct consequence of the family's own runtime-coupling policy changing: once "always live, fail gracefully" became the default for service-shaped things, one shared implementation of subscriptions and VAPID key management beat five copies.

Public Mission

Amoleo Communications is what quietly sits behind the comment box you're typing into, and the email or notification you just got from an Amoleo product — one well-built system instead of five different ones.

Amoleo·Reviews

Repo: Amoleo-Reviews
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Real reviews of real items, tied to what they actually are.

Private Mission

Reviews exists because a review is only trustworthy when it's anchored to a real, canonical thing — not a freeform title someone typed. Every review attaches to an Amoleo Registry entry, the same identity layer Collections and Upnext use, so a review of a film means the same film no matter who wrote it or where it's read. Revised 1-2 Sept 2026: a review attaches to whichever Registry node is actually being reviewed — a Title, a Series, or a specific Edition — with edition-agnostic axes (Story) attaching higher and edition-specific axes (Video/Audio/Extras) attaching to the specific Edition.

Reviews is deliberately its own product with its own front end rather than a feature bolted onto Editions, even though Editions is where the idea originated (Amoleo-Editions #12). Editions owns editions — comparing releases, scoring specs, tracking extras. Reviews owns opinions about the underlying work. Editor-approved reviews flow into Editions for display, but Editions never builds or owns the review itself.

Reviews doesn't build a comment system either. Discussion under a review runs on Amoleo Communications' shared comment surface, the same one every other family product with comments uses — Reviews is a consumer of that, not a second implementation.

Public Mission

Amoleo Reviews is where you write and read real reviews of the things you've watched, read, or played — tied to the actual work, not a guess at what someone meant.

Amoleo·Images

Repo: Amoleo-Images
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

One place for every family photo to live, on a real CDN, whether it's private or shared.

Private Mission

Images exists to get every family product's photos off local Docker volumes and onto proper object storage with a real CDN in front of it, without pretending every image the family stores has the same shape. Investigating Pets and Connections directly (rather than assuming) showed two genuinely different needs already live in production: Pets' private, per-record, live-authenticated photos (owner/co-owner/sitter, revocable share links, moderation) and Connections' public, content-deduplicated, unowned pool. Images supports both rather than forcing one onto the other.

The ownership model stays deliberately narrow: Images only ever answers "who uploaded this, for delete authorization" — never "what is this a photo of." That question stays entirely inside the owning app's own database, the same way it works today, just pointing at an Images ID instead of a local file path.

Private content never touches the public CDN path unauthenticated — a CDN edge can't check a live share-token expiry or a sitter grant, so private and public images live in genuinely separate storage, with the owning app minting a short-lived signed token for any private image it discloses.

Public Mission

Amoleo Images is the quiet layer underneath every family product's photos — fast wherever it's shown, private wherever it needs to be.

Amoleo·Registry

Repo: Amoleo-Registry
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

One canonical record per thing, shared by every product that needs to know what something is.

Private Mission

Registry exists so "is this the same comic/movie/game as that one" is answered once, in one place, instead of being solved independently — and inconsistently — inside Collections, Upnext, Editions and Reviews. It holds only the shared, descriptive identity of a work: name, format, and similar fields. It never holds anything personal — no photos, no price paid, no storage location, no per-user data of any kind (with one narrow exception: createdBy, tracking who submitted an entry, needed for the verification model below). Those stay entirely inside whichever product collected them; Registry only ever holds a reference ID from the other side.

Registry has no end users and no public presence. It doesn't compete with the other products for attention and it isn't marketed — it gets the family's basic wordmark and default Amoleo Light/Dark themes purely so it looks at home if anyone with access ever opens it, not because it needs a brand identity. It must never appear in the footer lockup, the Website's front-page cards, or any product-listing surface — see Amoleo-Family/tools/tokens/base.tokens.json's --brand-registry $description.

Revised 1-2 Sept 2026: Registry now models three entity kinds (Title, Edition, Franchise) and four typed relationships between them (edition variance, alternate-version, structural hierarchy, franchise membership), plus a real verification/ownership model — entries start unverified, are locked from the moment of creation, and a bad merge is resolved non-destructively rather than by deleting anything. See docs/Architecture.md for the full model; it's substantial enough that it isn't restated here.

Registry is reached through a small internal-only API, not direct database access — this keeps schema changes safe across independently-deployed repos and matches the family's existing rule (docs/stack.md) against sharing a database across apps, even though a Mongo container can be shared. Access is restricted to the family's own internal network, authenticated by a service credential between family backends — separate from, and simpler than, Accounts' own end-user authentication.

Public Mission

Registry has no public mission. It has no visitors and nothing to show them. Its only "users" are the other Amoleo products' own codebases — this section exists because every Amoleo repo has one, not because there's marketing copy to write.

Amoleo·Recommendations

Repo: Amoleo-Recommendations
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback. More than the usual amount — very little about this product is actually decided yet.

One-Liner

Quiet, data-driven suggestions, built from what you already own and watch — not a place you go, a thing that shows up.

Private Mission

Recommendations exists to answer one question well — "given what's in my Collections and what I've tracked in Upnext, what would I actually like next" — without becoming a destination of its own or a feature bolted onto a product that isn't about this. It's computational and personal (about your data specifically), which is a genuinely different kind of thing from Reviews' social/editorial reviews, and different again from a public product like Editions or Upnext that anyone visits directly. The shape that fits is the one Registry, Communications and Images already use: a shared capability with no real front end of its own, consumed by whichever products want to show a "Recommended for you" panel.

Almost everything past that one framing decision is still open, deliberately — the actual recommendation approach, what infrastructure it needs, which products embed it first. This mission statement will need real revision once those land, not just a light edit.

Public Mission

Amoleo Recommendations quietly suggests what to watch, read, or play next, built from what you already own and track across the family — not a site you visit, just there when a product wants to show you something.

Amoleo·Worldbook

Repo: Amoleo-Worldbook
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback. Added here 7 Sept 2026 — this repo (added 2 Sept 2026) already had a real MissionStatement.md and was simply never added to this master file or to check-missions.mjs's repo list, the same "checker can only catch what it's told to look for" gap this document's own closing note warns about.

One-Liner

Every character, location, item, and cast member in the stories you follow — and, privately, the ones you're still writing.

Private Mission

Worldbook is the single reference for entities tied to the stories the Amoleo family catalogues: characters, locations, items, and — as of 2 Sept 2026 — real cast (actors, directors, crew). It holds two kinds of entity, distinguished by visibility rather than by separate products: public entries are editor-curated, about existing catalogued works, and searchable by anyone; private entries are a user's own original creative work, owned by them, never public unless they choose to share it. Both render through the same view — a Character record looks the same either way — the distinction is a permission/visibility concern, not an architectural one.

This design deliberately chose UX/UI over a second codebase to carry the public/private distinction, after briefly building it as two separate repos (Amoleo-Worldbook + Amoleo-Write) and deciding the identical view mattered more than the structural separation. The private side is expected to grow past simple entity records — relationship mapping between a user's own characters, notes, outlining — and that growth should never be constrained by Worldbook's public side needing to stay a narrow, stable reference; it's a UX boundary (distinct "Browse" vs. "My Writing" areas), not a scope boundary.

Worldbook is deliberately not Amoleo Registry itself — Registry stays the canonical store of works (Title/Edition/Franchise); Worldbook consumes it, the same relationship Editions, Upnext and Collections already have, for a narrower kind of fact (who/where/what/whom appears in a story, not what the story itself is). But Worldbook is meant to eventually play a Registry-like role of its own for other products: the long-term direction is for Amoleo Connections (and any future product needing Actor or Character info) to read from Worldbook rather than keeping its own freeform copy — not designed or scheduled yet, but the intended destination.

Public Mission

Amoleo Worldbook is where you look up who's who, where's where, and what's what in the stories you already follow — characters, locations, items, and cast from the films, shows, comics, and games catalogued across the Amoleo family. And privately, it's where you map out your own — the characters, locations, and items of the stories you're writing yourself, never shared unless you choose to.

Amoleo·Health

Repo: Amoleo-Health
File: MissionStatement.md
Status: ⚠️ REVIEW ME — Drafted by Claude, awaiting feedback

One-Liner

Ride your bike, watch it happen, and see what you actually did against what you planned.

Private Mission

Health exists to make riding a Bluetooth fitness bike feel like doing something, not filling in a log. The primary mechanism is the real-time sprite-on-a-circuit visualization — turning live cadence/power/speed telemetry into a ride that visibly goes somewhere, lap by lap — plus ride replay so a finished ride is still worth looking at afterwards, not just a row in a history table.

Routines, not raw logging, are the unit of commitment. A user sets a time-based, frequency-based, or effort-based routine before they ride; nudges keep it in front of them; and the product's real value-add over a plain fitness tracker is closing the loop honestly — "I planned 3 rides this week, did 2; here's how I actually rode them" — rather than only recording what happened with no reference to what was intended. This is why the Todo integration matters: a planned ride is a real commitment (a Todo task), and Health's job is to show the truth of what happened against it, not to replace Todo's own planning.

Resistance control is secondary, on purpose, not a placeholder for "real" features to come. The bulk of Decathlon/Domyos-class bikes expose resistance over an undocumented, proprietary protocol; reverse-engineering it is uncertain research, not routine integration work, and is tracked separately from the product's committed scope. Preset maps and elevation profiles are designed now because the same data model drives today's visual pacing and tomorrow's resistance control — but the product is meant to be genuinely worth using on the visualization and routine-tracking alone, before resistance control ever ships.

Named Health, not Fitness, to leave room for the product to grow past bikes and into other health-platform integrations later, without a rename implying a pivot it wasn't. That is a decision about headroom, not a present-day feature promise — today, this is a bike-tracking product, full stop.

Free by default, same principle as Pets: anything that doesn't cost money to run stays free; a feature that genuinely does is the kind of thing that would live in a Premium tier if one is ever built — not decided yet, recorded as the default posture.

Public Mission

Amoleo Health turns your Bluetooth fitness bike ride into something worth watching — a real-time sprite riding your circuit as you pedal, and a replay you can look back on afterwards. Set a routine, get nudged to keep it, and see honestly how you actually rode against what you planned.

How to Update

When you update a mission statement:

  1. Update the copy here first (in this file)
  2. Run node tools/check-missions.mjs to see which repos need updating
  3. Update the repo's MissionStatement.md to match this version
  4. Commit both changes together (master + repo update in the same session)

The checker will flag:

Both findings are based purely on file modification time, not content — see the note at the top of this document. A finding here is a prompt to go look, not proof of actual drift.

If a repo's mission has genuinely changed (not just formatting drift), update the master first, get alignment, then propagate to the repo.

2 Sept 2026: this file had gone stale enough (missing Registry, Upnext, Collections, Communications, Reviews, Images and Recommendations entirely; the Family entry still said "six products") that check-missions.mjs was silently only checking eight of fifteen repos — the missing ones simply weren't in its list to compare against, so their drift (if any) was invisible rather than flagged. Worth remembering: a checker can only catch what it's told to look for.

7 Sept 2026: the same gap recurred immediately after being named — Amoleo-Worldbook was added 2 Sept 2026, five days after the note above was written, with a real MissionStatement.md from day one, and still wasn't added here or to check-missions.mjs's list until now. Naming a failure mode in prose doesn't prevent its next occurrence; only the checklist in "How to Update" (specifically: add a new repo's mission to both this file and check-missions.mjs in the same session it gets a MissionStatement.md) does. Fixed alongside registering Amoleo Health.

The template

Mission Statement Template

Every Amoleo product and the Family repo itself should have a mission statement. Use this template as the structure.

One-Liner

A single sentence that captures the core purpose. This is the elevator pitch version.

Example: "We value the health and wellbeing of all pets, especially cats."

Private Mission

The internal guide for how this product makes decisions and prioritizes work. This should include:

This is not marketing copy. It's decision-making guidance for the team. Write it as if explaining to developers and product managers.

Example: "We value health and wellbeing as primary. Sharing and genealogy are real value but secondary — when health and sharing conflict, health wins. We keep features free by default unless they cost us money to run (Premium tier only)."

Public Mission

The version you'd show a visitor to the site or a user of the product. This should:

This is what appears in "About Us", FAQ, or marketing copy. Keep it concise (2-3 sentences).

Example: "Amoleo Pets helps pet owners keep their beloved animals healthy by making it easy to track weight, medications, and treatments. Share your pet's moments with others and explore their family tree."

Why This Structure

A product without these three things either drifts over time (private version fades) or confuses users (private and public don't match).

Generated from docs/mission-statements.md + docs/MissionStatementTemplate.md + tools/repos.json. Edit there and re-run npm run build in docs-site-src/ — never hand-edit a page.