Living On Grace is in early access. The web app is live. Mobile and desktop are on the way.

App

Release Notes

Every change to Living On Grace, newest first. App updates, website releases, and what changed in each version.

v0.0.22026-05-16
Website

v0.0.2: Correct project domain on the landing page

Released: 2026-05-16 Type: Bug fix (PATCH)

What changed

The Download section on the landing page displayed app.livingongrace.com as the URL where the PWA "will live." That is the wrong TLD. The canonical project domain is livingongrace.app, with the PWA at app.livingongrace.app. The maintainer confirmed this, and the same value is already used elsewhere in log-documentation (see 05-platforms/website.md).

Why it qualified as a release

Per ADR-013, version bumps are decoupled from commits. A typo fix in already-shipped public content does qualify as a user-observable bug fix (PATCH). The wrong URL was visible to anyone viewing the rendered landing page, so leaving it on [Unreleased] was not appropriate.

Files touched

  • app/page.js: Download section copy.
  • README.md: "Domain (planned)" line.
  • CHANGELOG.md, docs/release-notes/README.md: paperwork.

Domain (canonical)

  • Marketing site: livingongrace.app
  • PWA: app.livingongrace.app

The livingongrace.app TLD is the source of truth. All store listings, OG metadata, privacy/terms pages, and email reply-to addresses must use it. Internal bundle identifiers (app.livingongrace.log, app.livingongrace.log.desktop) are already the reverse of log.livingongrace.app and therefore consistent with this domain.

Verification

npm run build clean, zero warnings. Landing page now shows app.livingongrace.app in the Download section.

v0.0.12026-05-16
Website

v0.0.1: Initial Next.js scaffold (static export)

Released: 2026-05-16 Type: Initial seed

What this is

The first commit-able shape of the LOG marketing website: a single calm landing page that introduces the project, names the four product surfaces, lists the three product principles, and points visitors to where each app will live. Built on Next.js 16 + plain JavaScript, exported as fully static HTML/CSS/JS so it can drop onto any static host.

What's in it

  • app/page.js: the landing page itself. Sections, in order:
    1. Header: sticky brand bar with the LOG mark and primary nav.
    2. Hero: "A quiet companion for spiritual health." plus tagline and two CTAs.
    3. Surfaces: Mobile / Web / Desktop cards.
    4. Principles: Offline-first / Quiet by design / Yours.
    5. Download: surface-by-surface status callouts. Pre-alpha, no real links yet.
    6. Footer: links to every sibling repo, MIT note.
  • app/layout.js: root layout, metadata (title, description, OG, Twitter card, keywords), and the Next.js 16 viewport export carrying theme-color for light + dark.
  • app/globals.css: LOG design tokens (palette, spacing scale, radii, motion easing, fonts), base reset, link styling, ::selection accent, prefers-reduced-motion honoured.
  • app/page.module.css: CSS Modules for the landing page; responsive at 640px.
  • next.config.mjs: output: 'export', trailing slashes, image optimisation off (incompatible with static export).
  • Repo conventions: MIT LICENSE, VERSIONING.md, CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, GitHub issue & PR templates, .gitignore (Next default).

How to run

npm install
npm run dev        # localhost:3000 with hot reload
npm run build      # static export -> out/
npx serve out      # sanity-check the static output locally

What's deliberately not here

  • Analytics. No tracker on day one. Add one only with an ADR, and only if it respects privacy.
  • Cookie banner. None required while there's nothing to consent to.
  • Blog / changelog page.
  • sitemap.xml, robots.txt, dynamic OG image. Each a small follow-up.
  • Real store links and signed-build downloads. Will land alongside the corresponding app releases.
  • A /privacy and /terms page. Will land before the first public mobile release.

Each of these is intentionally a separate, reviewable step. The seed earns the right to exist on its own first.

Verification

  • npm run build completes with no warnings.
  • Output in out/ is plain HTML/CSS/JS.
  • Page renders in light and dark, at desktop and mobile widths.
  • All in-page anchors (#surfaces, #principles, #download) resolve.
  • All external repo links open to GitHub.

Why static export

The website only ever serves content. No user accounts, no per-request rendering, no API. Static export gives us:

  • Instant page loads (no cold start).
  • Trivially cheap hosting on Cloudflare Pages, Netlify, GitHub Pages, S3, etc.
  • A single artefact (out/) we can preview and ship by uploading a folder.
  • Zero server attack surface because there is no server.

When/if we need server-rendered features (form submission, dynamic OG images), we'll switch off output: 'export' for the affected route, but only via an ADR.

v0.0.62026-05-16
Website

Release Notes: v0.0.6

Date: 2026-05-16 Type: Design-system migration (non-breaking, visual) Scope: log-website


Summary

Adopted the canonical LOG design-system token catalog (ADR-017). The primary visible change is the brand accent colour shift from legacy Grace Gold to the canonical Brand brown.


Token rename table

Old variable New variable Old hex New hex Notes
--log-grace-gold --log-brand-accent #C9A227 #926247 Resolves to var(--brand-60)
(implicit: bg) --color-bg-surface #FAF9F6 #FAFAF9 gray.5, 1-digit rounding diff
(implicit: ink) --color-text-primary #1F1B16 #1C1917 gray.90 canonical

Colour before / after

Token Before After Swatch (hex)
Brand accent Grace Gold Brand warm-brown #926247
Brand accent (dark) N/A --brand-50 #A27450
Brand gradient (apple-icon) #C9A227 → #A88317 #B1865E → #926247 → #5F3D34 brand.40 → .60 → .80

Files changed

File Change
app/globals.css Full rewrite, canonical primitives + semantic aliases + compat layer
app/page.module.css 8× --log-grace-gold → --log-brand-accent
app/(legal)/changelog/changelog.module.css 4× --log-grace-gold → --log-brand-accent
app/(legal)/legal.module.css 5× --log-grace-gold → --log-brand-accent
app/icon.js #C9A227 → #926247
app/apple-icon.js Gradient recomposed with brand.40/60/80
app/opengraph-image.js 4× #C9A227 → #926247
app/layout.js Font loading + themeColor update
package.json Version 0.0.5 → 0.0.6
CHANGELOG.md Added [0.0.6] section

Upgrade path for consumers

This is a CSS custom-property rename. Any downstream CSS that references --log-grace-gold must be updated to --log-brand-accent. Globally search for --log-grace-gold and #C9A227 across all stylesheets.


References

  • ADR-017 (canonical Figma design system token adoption)
  • log-documentation/04-design/tokens/tokens.json - source of truth
v0.0.52026-05-16
Website

log-website v0.0.5: 2026-05-16

Three small things, one release

Favicons

The site finally has its own brand favicon and Apple touch icon instead of Next.js's default N mark.

  • app/icon.js → 32×32 PNG, solid Grace Gold, white serif L. Used in browser tabs, bookmarks, history, and Google's SERP.
  • app/apple-icon.js → 180×180 PNG, Grace-Gold gradient with a larger serif L. Used by iOS Safari when a user adds the site to their Home Screen.

Both ride the same next/og ImageResponse pipeline as the OG image, so the renderer is consistent across every generated image. Both are marked dynamic = 'force-static' so they build to plain PNGs in out/.

/changelog route

https://livingongrace.app/changelog/ now exists. It reads CHANGELOG.md from the repo at build time and renders it as styled HTML inside the same shared layout as /privacy and /terms.

  • Added marked@^16 (small, zero-deps markdown parser).
  • Page lives at app/(legal)/changelog/page.js inside the existing route group, same sticky header, same footer.
  • The in-page nav and the home page footer both now link to /changelog/.
  • The shared footer wording in app/(legal)/layout.js was generalized so it covers all three docs (privacy, terms, changelog) rather than legal docs only.

Why now

The changelog page is useful for early testers because they can read what shipped without browsing GitHub. It is also useful at store review time because reviewers often look for an accessible release history.

Static export verification

next build emits 11 static routes:

○ /                 ○ /_not-found        ○ /apple-icon
○ /changelog        ○ /icon              ○ /opengraph-image
○ /privacy          ○ /terms             ○ /twitter-image

All pre-rendered as static content. No runtime function execution needed in production.

Why a PATCH bump

Three user-observable additions on a live marketing site (favicon visible in every tab, public /changelog/ route, share-image unchanged but works alongside). PATCH on the 0.0.x line per ADR-013.

v0.0.42026-05-16
Website

log-website v0.0.4: 2026-05-16

Social-share previews land

The marketing site now produces a proper 1200×630 PNG for Open Graph and Twitter card previews. When someone pastes livingongrace.app into iMessage, Slack, WhatsApp, Twitter, LinkedIn, Discord, or a preview-rendering bot, this is what they see:

  • A thin gold accent line across the top.
  • ● LOG · pre-alpha eyebrow in Grace Gold.
  • A serif headline, "A quiet companion for spiritual health."
  • A sans-serif subtagline, "Living On Grace, offline-first, no streaks, no noise. Built for the device you already carry."
  • Footer: livingongrace.app on the left, Mobile · Web · Desktop on the right.

Generated by Next.js's next/og ImageResponse from app/opengraph-image.js; app/twitter-image.js re-exports the same image. Both routes are marked dynamic = 'force-static' so they build to plain PNGs in out/ and need zero runtime support.

metadataBase

Set metadataBase = new URL('https://livingongrace.app') in app/layout.js. This makes every Open Graph and Twitter image URL absolute, required by every social platform's crawler.

How to regenerate

Edit app/opengraph-image.js and run npm run build. The PNG lives at out/opengraph-image (no extension; Next.js + Vercel serve it with the right content-type). Commit the source file, not the PNG.

Why a PATCH bump

ADR-013: rendered content that public users see qualifies for a bump. Social-share previews are arguably the most-seen surface of any marketing site. Every shared link renders this image, so PATCH is right on the 0.0.x line.

v0.0.32026-05-16
Website

log-website v0.0.3: 2026-05-16

/privacy and /terms ship

The website now serves the two pages that App Store, Play Store, and AppGallery require before any product surface can be submitted for review.

  • https://livingongrace.app/privacy/
  • https://livingongrace.app/terms/

Both are statically exported (out/privacy/index.html, out/terms/index.html) and render without any client-side JavaScript.

What's in them

The full canonical text from log-documentation/06-compliance/, privacy-policy.md and terms-of-service.md, rendered in JSX with the LOG design tokens (Ivory / Graphite / Grace Gold, serif headings, accessible tables). The website is not the source of truth: if the canonical markdown changes, the JSX must be updated to match.

Effective date for both: to be set at v1.0 launch. Until then the pages exist for discoverability (store review crawlers, due-diligence checks) and for early testers to read.

Plumbing

  • Route group app/(legal)/ with shared layout.js (header + footer + return link to home) and legal.module.css.
  • Footer of the landing page now links to /privacy/ and /terms/ via next/link (trailing-slash export-safe).
  • Per-page metadata (<title> + <meta name="description">) for SEO.

Why a PATCH bump

ADR-013 in log-documentation: a release bumps when user-observable shipped content changes. New public pages on a live marketing site qualify. They are not new "features" of the product (no behaviour change on /), so MINOR isn't warranted at this stage of the 0.0.x line. PATCH is correct.

Next

  • A real OG image for social-share previews.
  • A /changelog page so visitors can read the live changelog without leaving the site.
  • Linking the published privacy/terms URLs into the App Store Connect and Play Console listings once those apps are created.