Church4Christ v1.6.0: twelve interface languages

Upgrading from 1.5.0: see Upgrading 1.5.0 to 1.6.0.

Added

• Language infrastructure (no operator action required for the language settings themselves). A registry of
  supported languages, installation-wide locale.enabled / locale.default settings editable
  under Settings → Languages, a requested → default → English fallback chain, language
  negotiation at / (cookie from the switcher, Accept-Language, default), a switcher that
  becomes a dropdown above three languages, a reusable per-language tabbed editor in admin
  forms, and --locales / --default-locale setup flags with a multi-select in onboarding.
  Upgraded installations keep exactly English and Chinese with English as the default; nothing
  changes until an administrator saves new language settings. Disabling a language hides it and
  never deletes content. Setup manifests are schemaVersion: 2 (version 1 still reads) and
  onboarding preferences are schemaVersion: 2 (version 1 still reads). --locale x alone keeps its
  earlier meaning (English and Chinese enabled, x the default); --locales narrows or widens the set. See docs/i18n.md.

• Language support for ten more languages: Spanish (es), Brazilian Portuguese (pt, BCP-47
  pt-BR), French, German, Japanese, Korean, Malay (ms), Indonesian (id), Vietnamese, and
  Hindi are registered and selectable in Settings and onboarding, each with its own lazily loaded
  dictionary file. All ten are fully translated (AI-assisted, glossary-guided, and checked by
  scripts/i18n/check.mjs for keys, placeholders, HTML tags, script, and untranslated copy;
  community review welcome). Upgraded installations still enable only English and Chinese. Japanese, Korean,
  and Devanagari get system font stacks and Japanese and Korean the CJK line height. A
  translation toolkit ships with it: scripts/i18n/export-keys.mjs, scripts/i18n/check.mjs, a
  church glossary in docs/i18n/glossary.md, and per-language capability and readiness copy in
  src/i18n/catalog/<code>.json. See docs/i18n.md.

• The README is available in all twelve languages (README.<code>.md, AI-assisted) with a
  language bar at the top; README.md stays English and authoritative. The short Chinese summary
  section in the English README is replaced by the full Chinese README. See
  README translations.

• Admin editors for ministries, teams, service types, custom pages, events, announcements,
  navigation links, and the site identity settings (name, tagline, service times) now read and
  write every enabled language, not only English and Chinese.

Changed

• The "Han text means Chinese" display heuristic for legacy sermons, bulletins, and plan
  subtitles now applies only to Latin-script languages. Japanese, Korean, and Hindi pages no
  longer hide rows because they contain Han characters. Prayer sheets and testimonies are matched
  by their explicit language along the fallback chain.

• Locale columns now reference a supported_locales lookup table instead of a hard-coded
  CHECK (locale IN ('en','zh')), so adding a language later is an INSERT, not a schema
  change. Operator impact: apply the new forward migrations before deploying. D1 gets
  0041-0049 (the lookup table, then rebuilds of the translation and related tables; back up
  first, rebuild time grows with table size), and Supabase/PostgreSQL gets 0041. No data
  changes and no behavior changes; an upgraded installation still offers English and Chinese until an
  administrator enables more languages. See Language lookup migrations.

• New Church4Christ logo: a teal church and cross sheltering an orange figure that forms a
  "4". The browser favicon, the onboarding page, the README header, and the 1280×640
  social preview use it, and the demo seed sets it as the demo church's logo
  (site.logo_image_key). Source files and colors are in docs/images/brand/. Existing
  installations keep their own uploaded logo; only the favicon changes for them.

Fixed

• In the ten newer languages the public header put every link under More; built-in links
  now sort into Welcome, Explore, Connect, and Get Involved in every supported language.
• A paid Registration checkout started from a page in one of the ten newer languages failed its
  stored-request check during Stripe recovery; any supported language now passes.
• The serving menu's "Serve" link highlights correctly in every supported language.

Upgrade runbook: https://github.com/leveo/church4christ/blob/v1.6.0/docs/upgrade.md#upgrading-150-to-160

v1.5.0: production Giving, Member Portal on D1, mobile check-in and scheduling, Service Planning

Upgrade notes: Upgrading 1.4.0 to 1.5.0:
Member Portal on D1,
Production Giving,
Service Planning.

Added

• Member Portal now runs on the default Cloudflare D1 database: households, groups and
  protected group files, calendar, opportunity discovery, and church, group, and private
  prayers. New D1 migration 0039_member_portal_d1.sql adds the group_files and
  prayer_items tables. Demo prayer items are part of the D1 demo seed.

• Production Giving on Supabase and Stripe. Stripe now has an explicit live mode
  (STRIPE_MODE=live plus STRIPE_LIVE_CONFIRMED=1) alongside the default test mode.
  Checkout offers cards, wallets, and ACH bank debits (us_bank_account); Stripe emails
  per-payment receipts; donors change or cancel recurring gifts in Stripe's Billing Portal;
  yearly recurring gifts are supported. ACH gifts are recorded as pending and settle or fail
  from Stripe events.

• Giving ledger accuracy: each gift records live or test mode, the Stripe payment time
  (paid_at), refunded amounts (partial refunds are netted out), the charge id, and
  disputed status. Refunds and disputes are matched to gifts by the database, including
  refunds of recurring payments. invoice.payment_failed marks a recurring gift past due
  without any app email, and customer.subscription.updated syncs amount, interval, and fund.

• Annual giving statements: a printable page at /my/giving/statement/<year> and an admin
  page at /admin/giving/statements that queues a statement email for every donor, drained
  in small batches by the existing five-minute job (no new schedule).

• Giving admin: funds gain a description, a default flag, and a tax-deductible flag; manual
  gifts use the giving.currency setting; totals are per currency and net of refunds; CSV
  export of gifts; audit rows for manual gifts, fund edits, statement batches, and exports.

• PostgreSQL migration 0039_giving_production.sql (details under Operator impact).

• Service Planning (planning, 服事流程): a timed run sheet for each service or event
  (live start times, fixed starts, overrun and overlap warnings, leader-only cue notes, print
  view, copy from a previous event), rehearsal sessions with called people and call times,
  member availability windows, a "find a time" search that ranks slots by conflicts, a team
  availability calendar, rehearsals and run-sheet duties in the member calendar and calendar
  feed, and automatic email on schedule, change, cancel, and a reminder. It is a new module in
  Volunteering that works on D1 and Supabase. See
  docs/features/service-planning.md.

• The Supabase setup guide opens its Stripe section with a short, no-code overview for churches
  and nonprofits, linking Stripe's official pages for account activation, the nonprofit fee
  discount, receipts, the customer portal, ACH, keys, webhooks, and test cards.

Changed

• Children's check-in and volunteer scheduling now work at phone width (375px): Today
  check-ins are cards with a full-width Check out button, the scheduling matrix and the
  availability grid become per-date and per-member cards, kiosk inputs open the right phone
  keyboard, and buttons, inputs and the admin top bar meet touch-size targets with 16px
  inputs. The Kiosk tab shows a QR code of the kiosk link, drawn on the server with the new
  qrcode-generator dependency (MIT, no dependencies). Forms that carried a data-confirm
  message (deleting a team or service type) now actually ask before submitting. The Accept or
  Decline email shows a short button instead of the raw link. Installing the update needs
  npm ci only; there are no migrations or settings to change.
• portal no longer requires the Supabase backend; only Giving and Registration do. A
  portal-only selection now resolves to D1, and a selection that also includes Giving or
  Registration still resolves to Supabase.
• Registration-dependent portal parts (event-scope prayers, event administrators, My
  registrations) are hidden, and no Registration table is read, when the registration
  module is off. /my/serving returns 404 when Volunteer Scheduling is off.
• Stripe objects and events must now carry a livemode equal to the configured mode;
  the previous hard cs_test_ / livemode: false checks are gone. A mismatched event gets
  400 livemode_mismatch and is not stored (it was 400 live_mode_disabled). Every Stripe
  request pins Stripe-Version: 2025-03-31.basil. Registration shares this client, so its
  paid checkout also follows the configured mode.
• The online give form is hidden, with a clear message, when Stripe is not configured for
  the current mode. The Billing Portal return URL now comes from APP_ORIGIN.
• Year totals on My giving bucket by the Stripe payment date in the church time zone and
  are net of refunds; test-mode rows count only on test-mode installations.
• The thank-you page says Stripe emails the receipt (the app never sent one).
• people.stripe_customer_id is now a legacy test-mode read fallback; customers live in
  stripe_customers, one per person per mode.

Fixed

• The children's Kiosk tab QR label and hint, and the "My giving" link on the giving thank-you
  page, showed raw dictionary keys. A new test fails when any literal translation key used in
  source is missing from either dictionary.

Operator impact

• D1 installations: apply the new migration 0039_member_portal_d1.sql with the normal D1
  migration step before deploying. The migration keeps Member Portal off on an existing
  installation by recording module.portal = 0 unless a choice is already saved; an
  administrator turns it on in Settings → Modules.
• Supabase installations are unaffected by the portal change: it has no PostgreSQL migration.
• Supabase installations with Giving: apply PostgreSQL migration
  0039_giving_production.sql with the normal Supabase migration step before deploying. It
  adds gift columns (livemode, paid_at, refunded_cents, stripe_charge_id), widens the
  gift method and status and recurring interval checks, and adds stripe_customers,
  giving_statement_outbox, giving_audit_events, and fund description / default /
  tax-deductible columns. Existing manual gifts become live; existing Stripe gifts stay test
  (they were test-only) and their paid_at is backfilled from created_at. Existing
  installations remain in test mode: no behavior changes until you opt into live.
• New variable STRIPE_LIVE_CONFIRMED (set to 1 together with STRIPE_MODE=live) is the
  explicit live opt-in; STRIPE_MODE now accepts test or live. Setup still provisions test
  mode and preserves a live opt-in when rerun. The webhook endpoint must be created at Stripe
  API version 2025-03-31.basil; the doctor warns on stored events from another version.
• Update the Stripe webhook endpoint to the twelve events in the go-live checklist
  (invoice.payment_failed, charge.failed, charge.dispute.created, and
  charge.dispute.closed are new).
• No new bindings, secrets, or cron triggers. Statement emails ride the existing
  */5 * * * * Supabase schedule.
• Service Planning: apply the new migration 0040_service_planning.sql with your normal
  migration step before deploying: npm run db:migrate:remote on D1 and
  npm run db:migrate:supabase on Supabase (numbered 0040 there as well, after Production Giving's
  0039). It adds seven
  planning_* / availability_windows tables with campus_id, four default notification
  rules, and registers the new person references with the identity merge inventory. On an
  existing installation it also records module.planning = 0, so the module stays off until
  an administrator turns it on in Settings → Modules; a fresh installation follows the
  setup choices, and no preset includes Service Planning.
• Service Planning adds the planning administrator area, grantable on a person's page.
  Reminder emails use the existing daily reminder cron (0 13 * * *).

Try it

• Live demo with fictional data: https://church4christ.yunfei-song.com
• Single-feature editions, now pinned to this release: church-checkin, church-volunteer-scheduling, church-small-groups, church-website-cms

v1.4.0: single-feature presets and editions

Upgrade notes: Upgrading 1.3.0 to 1.4.0.

Added

• Three focused setup presets: checkin (People & Households, Children Check-in),
  volunteer-scheduling (Volunteer Scheduling, Spiritual Gifts, People & Households), and
  small-groups (Groups, Fellowships, People & Households). They run on the default D1
  database and work with the installer's --preset flag.
• npm run onboard -- --preset <key> opens the browser form with that preset's features
  pre-checked; the form's reset button returns to the same preset.
• config/editions.json and node scripts/editions/render.mjs describe and render the
  single-feature edition repositories. Each edition is a README and agent guide that installs a
  pinned release of this repository with one preset; editions contain no application code.
  See docs/editions.md.

Operator impact

None for existing installations: no migrations, bindings, secrets, module defaults, or access
rules change. Existing presets keep their module lists. A preset's module list is recorded in
each installation's setup manifest, so the new presets' lists are fixed from this release on.

Single-feature editions

These small repositories each install this release with one preset:

• church-checkin: checkin
• church-volunteer-scheduling: volunteer-scheduling
• church-small-groups: small-groups
• church-website-cms: website

Church4Christ 1.3.0

Added

• npm run onboard opens a local browser form for church, nonprofit, or campus identity,
  primary and secondary colors, a PNG/JPEG/WebP logo, language, first administrator,
  initial content, and feature checkboxes. It recommends the D1-backed Website + Community
  selection; Supabase-only modules require an explicit advanced choice. Preferences and
  uploaded logos stay in Git-ignored .church/ files and can be reopened in later sessions.
• The existing installer accepts --preferences .church/preferences.json for both dry-run
  plans and setup. Initial setup applies identity and logo settings and stores brand colors
  locally for design-token generation. README, AGENTS.md, CLAUDE.md, and the setup guide
  describe the browser-first workflow and preference reuse by coding agents.
• Every deployment now serves a generated /robots.txt and /sitemap.xml. The sitemap
  lists public landing pages for enabled modules and published custom pages in English and
  Chinese with hreflang alternates; robots.txt names the sitemap and disallows admin,
  signed-in, token, kiosk, and API paths. Indexable public pages add Open Graph and Twitter
  card tags, and the home page adds a schema.org WebSite description.
• Optional GOOGLE_SITE_VERIFICATION and BING_SITE_VERIFICATION Worker variables render
  search-console ownership meta tags; malformed values are ignored.

Changed

• Canonical, hreflang, and Open Graph URLs now use the deployment's APP_ORIGIN (falling
  back to the request origin) instead of the build-time site in astro.config.mjs, so
  each church's pages point at its own domain.
• Refresh npm dependencies, including Astro 7.3.3, React 19.3.0, Tailwind CSS 4.3.3,
  Wrangler 4.135.0, and current compatible adapters, fonts, types, and utilities.
  Replace @cloudflare/vitest-pool-workers with its official successor,
  @cloudflare/vitest-plugin 1.1.13. Keep TypeScript 6.0.3 and Vitest 4.1.11 because
  the Astro checker and Cloudflare test plugin do not yet support their newer major
  versions. Pin the checker's language server to 2.16.16 to avoid false frontmatter
  parsing errors in 2.17.0; see the
  dependency compatibility notes.
• Recognize the updated workerd socket-close message in the existing narrowly scoped
  PostgreSQL end-to-end test cleanup filter. Other unhandled errors still fail the suite.

Upgrade notes

• From 1.2.0, no database migration is added: the latest forward migration remains
  0038_community_workflows.sql on both backends. Run npm ci and rebuild after pulling
  the dependency refresh. Node.js 22.22.1 remains the minimum runtime. No reseeding,
  bindings, secrets, or deployment procedure changes are needed; follow
  the upgrade runbook.
• Confirm vars.APP_ORIGIN is the domain visitors use: canonical links, /robots.txt, and
  /sitemap.xml now come from it. Then submit /sitemap.xml to search consoles if wanted.
• Onboarding only saves local preferences; it does not create resources or deploy a site.
  Existing installations need no migration, reseeding, new binding, or secret for this
  workflow. Use the existing upgrade/configuration process for subsequent site changes;
  saving new preferences does not overwrite the installed brand.
• Preserve .church/preferences.json, its uploaded logo, and .church/branding.json
  when moving an organization's build to another machine. Initial setup generates brand
  tokens; npm run tokens and production builds regenerate them from the local brand file.
  Organization type and time zone remain preference context for further customization;
  this form does not change the application's scheduling time zone.

Documentation

• README now leads with what the project is (open-source church management software,
  church CMS, and a self-hosted Planning Center alternative), adds project badges, a
  feature comparison with its current gaps, an FAQ, and a Chinese summary. package.json
  gains description, keywords, homepage, repository, and issue links; it stays private.
• Add llms.txt and CITATION.cff at the repository root, a 1280×640 social preview image
  at docs/images/social/social-preview.png, and a "Search engines" section in the
  deployment guide.

Fixed

• Community workspace entry buttons now persist the selected campus through the existing
  campus switch endpoint, so navigation to fellowships, groups, and workflows keeps its
  context. Workflow save redirects also retain the selected campus, including email links.

Church4Christ 1.2.0

Added

• Campus community workspaces can directly manage Groups and member follow-up. Optional
  Fellowships add independent membership, meeting details, a default coordinator, and child
  groups. Existing groups remain directly managed by their campus until explicitly assigned.
• Reusable campus and fellowship workflows provide manual and new-member enrollment,
  assigned steps, due dates, progress notes, completion, cancellation, and reminder controls.
  Members receive a private task workspace. All new interface and email copy is English.
• Cloudflare email reminders use the existing hourly cron and EMAIL binding, with atomic
  delivery claims, failed-send backoff, pause controls, and explicit recovery for uncertain
  delivery. Reminders are disabled unless WORKFLOW_EMAIL_ENABLED=1.

Upgrade notes

• From 1.1.0, apply all outstanding forward migrations 0027 through 0038 for the selected
  backend before deploying 1.2.0. These include the existing campus, identity, and Planning
  Center updates as well as 0038_community_workflows.sql on D1 and Supabase/PostgreSQL.
• Preserve existing database, R2, authentication secrets, and provider configuration; use
  the upgrade runbook. This release does not reseed church data.
• Review community workflows before enabling email.
  Confirm the sending domain, EMAIL_FROM, and APP_ORIGIN. No new cron trigger is required.
• Community administrators need the existing Groups grant. A fellowship coordinator label
  does not grant admin privileges. Identity merges with community references require review.

Security

• Upgrade Astro, its Cloudflare/React adapters, Wrangler, the Workers test pool,
  and affected transitive dependencies to clear the 13 npm audit findings.
  Keep Vitest on its compatible 4.x release line. Pin native install-script
  approvals for npm 12. Operator impact: run npm ci, rebuild, and follow the
  normal deployment process to use the patched packages. No database migration,
  reseeding, secret, or application configuration change is required.

Changed

• Renewed all 21 core modules with Sanctuary typography, forest-green navigation,
  purpose-specific public/member/admin workspaces, responsive layouts, keyboard
  editor controls, and nine bundled decorative images. English interface and demo
  presentation stay English; Chinese pages retain bilingual support. Existing
  personal names, messages, editor inputs, and authorization boundaries remain.
  README now includes 29 refreshed application screenshots and a repeatable capture
  inventory. No image service or API key is required for the packaged design.
• First setup now describes both starting-content choices explicitly and accepts
  --no-demo-data alongside --demo-data. Both keep the bundled design; no-demo setup
  retains schema, operational defaults, modules, church settings, and the first admin
  without sample business records. Noninteractive setup still defaults to no demo data.
  New managed initialization records site.demo_content without overwriting an existing
  choice. Operator impact: no migration or reseeding is required; neither flag clears an
  existing installation, and existing content remains protected during reruns and feature
  selection changes. Legacy initialized databases retain their absent content marker.
• Setup preserves Wrangler's structured stdout error messages when stderr is empty,
  extracting only the bounded, redacted diagnostic field. This keeps fresh-database
  detection working with JSON command errors without dumping query results or secret
  fields. No dependency change or operator action is required.
• Fresh administrator setup now creates its trusted verified contact and audit
  records atomically, so both demo choices can sign in after member-identity
  migrations. Reruns do not reverify existing or revoked ownership. PostgreSQL
  query compatibility fixes cover child attendance, scoped team scheduling, and
  security contact labels; PostgreSQL identity sessions require UTC as documented.

Church4Christ 1.1.0

Church4Christ 1.1.0 is a reviewed source checkpoint focused on Learning and explainable member activity insights.

Highlights:

• optional bilingual Learning module for Sunday school, discipleship, and similar ministries on D1 and PostgreSQL
• privacy-bounded learner pages for provider-authoritative courses, activities, files, links, due dates, and submission status
• official Google Classroom OAuth/API, Pub/Sub notification, bounded synchronization, and durable disconnect workflows
• Church4Christ Learning — Canvas Edition integration through scoped Canvas OAuth/REST and signed Live Events
• optional Activity Score dimensions for group attendance, confirmed serving, registration engagement, and default-disabled Learning engagement
• fictional Genesis 1 demo, bilingual screenshots, and a GPT Image 2-generated Learning workflow diagram

Security and privacy:

• provider credentials use a versioned AES-256-GCM server-side envelope
• provider origins, URLs, callbacks, response sizes, pages, items, elapsed time, D1 queries, and subrequests fail closed at bounded limits
• Church4Christ stores normalized learning metadata, not grades, answers, comments, assignment bodies, uploaded files, raw provider responses, or provider credentials

Upgrade guidance:

• back up and rehearse the matched Worker, database, R2, and provider configuration in staging
• apply forward migrations 0017_learning.sql through 0026_activity_score_learning.sql in numeric order before deploying 1.1.0
• configure LEARNING_CREDENTIAL_KEYS before authorizing Google Classroom or Canvas
• read the operator steps and provider-specific obligations in the upgrade guide

This is a source release; the package remains private and is not published to npm. No production deployment or database migration is performed by publishing this release.

Upgrade guidance: https://github.com/leveo/church4christ/blob/v1.1.0/docs/upgrade.md
Changelog: https://github.com/leveo/church4christ/blob/v1.1.0/CHANGELOG.md

Church4Christ 1.0.0

Church4Christ 1.0.0 is the initial open-source release.\n\nHighlights:\n- bilingual public website and modular church administration\n- People/Households portable export and source CSV mapping\n- aggregate Service Attendance with identity-free reporting\n- bilingual Newcomer intake and scoped follow-up workflow\n- shared launch-readiness checklist and doctor v2\n- D1 and Supabase/PostgreSQL forward migrations through 0015\n- refreshed README with real feature screenshots\n\nThis is a source release; the package remains private and is not published to npm. No production deployment is performed.\n\nUpgrade guidance: https://github.com/leveo/church4christ/blob/v1.0.0/docs/upgrade.md\nChangelog: https://github.com/leveo/church4christ/blob/v1.0.0/CHANGELOG.md