CareNest

A babysitter app for two phones. A parent sets up the family space and invites a babysitter by email; the babysitter sees the schedule and each child's care info and checks off tasks while the parent watches progress live.

The site itself is plain HTML, CSS, and JavaScript served as static files (Vercel, no build step). There is deliberately no package.json at the repo root; database tooling lives in tests/, and .vercelignore keeps supabase/ and tests/ off the deployed site.

Accounts and sign-in

Pages: signin.html (Google sign-in, the data notice), onboarding.html (create a family space; requires ticking the at-your-own-risk acknowledgement), people.html (parents: invite a sitter, revoke invites, remove sitters), invite.html#<token> (accept an invite), and privacy.html / terms.html. Every app page (index, parent, people, manage, schedule, care-log, children, profile, gallery, info, food-allergies) loads js/auth.js, which keeps the page hidden until it has checked the session: signed out goes to signin.html, no family space goes to onboarding.html, a parent's home is parent.html, a sitter's is index.html, and a page for the other role redirects to the right one. The Profile tab shows the signed-in account and signs out or deletes the account and its data. The children, the schedule, care info (Good to know, food and allergies, emergency steps) and contacts come from the family space in Supabase (js/family-data.js loads them into the shape js/data.js defines); parents edit them on manage.html ("Family info" in the parent nav). The Children tab (children.html, both roles) pins the current household (family name and next sit) to the top of the page while the list scrolls under it (SI-68), then shows the family card (primary contact, phone, and home address) and each child, with their age, stage, pinned note, and any severe allergies. A sitter in several families switches household from the pinned card or the family bar without leaving the tab: the pin shows the new household at once and the previous family's children are cleared until the new family's load. Each child's page keeps the family name pinned in its header. Tapping a child (children.html?child=<id>) shows that child's food and allergies, preferences, and instructions, the family's contacts, and links to where things are and emergency steps, which stay family-wide. A category with nothing in it says "No information provided". Parents add, edit, and delete children and each child's items there too, and set the home address and primary contact in Family info. Pages that list care info for the whole family (the food page, the care info pages) tag each per-child item with the child's first name once the family has more than one child. Children are shown by initials, never by photo. The top of the sitter's page (index.html) is an "Important today" section: the parent's notes for that day (day_notes: routine change, special instruction, schedule change, food or medication, other), each opening in place to its details and marked "Updated " after a parent edits it, or "No special updates for today." The day is today's local date (the browser's, re-checked at local midnight); while a shift that started on an earlier local date is still open (overnight, or never ended), the notes for that start date are shown too, under "Today" and the start date's own heading. Parents pick the date for each note in the "Important today" card on manage.html. The notes refresh live (Realtime), and if they fail to load only that section says so. Below it, the sitter's Home (SI-69) shows "What's next": the one next activity, with its name and time, which is the earliest task not yet checked off whose time is now or later (re-checked every minute, so a 3:00pm activity gives way to the next one at 3:01pm; tasks with no time are left out; js/next-activity.js). After the last one it says "No more activities scheduled for today.", and "Full schedule" opens the Schedule tab. Then the Checklist: the day's tasks with "x of y done", checked off the usual way (a photo, an optional tag and note, then the "Add details" prompt). The Schedule tab shows the same checklist under Current Shift for the sitter; both read the shift's task checks, so a task checked or unchecked on one page shows on the other. With no tasks it says "No checklist items for today." The side column has the emergency entry, the family's primary contact only (contacts.is_primary, with a call button; "All contacts" opens the first child's page on the Children tab, which lists every contact), or "No primary contact yet.", and the Good to Know tiles. Home no longer previews the care log. The Care Log tab (care-log.html, both roles; parents at care-log.html?as=parent, and js/auth.js sends each role to its side) is the current session's log: the family's latest shift, its entries oldest first, each with the child it is about (initials and first name), what happened, the time, and who wrote it; details logged under completed tasks are listed in the same order, labelled with the task. With no entries it says "No entries yet". The sitter's "New entry" (care-log.html#new, so the phone's back button closes it) picks the child (skipped when the family has one child) and takes a note of up to 1000 characters; the entry is saved to care_logs (in demo mode, to the tab's sessionStorage) and shows for everyone in the family live. If saving fails the form says "Your entry wasn't saved" with the reason and keeps what was typed, so Save can be tapped again. New entry is offered only while the shift's date is in the window (open or ended); before the sitter starts a shift the page says to start it on Home, and an older session is read-only. Parents read the log and do not add to it. Messages was removed (SI-66): there is no chat screen and no Messages item in the navigation. messages.html is now a tiny page that sends old links and bookmarks to care-log.html, keeping the query (?as=parent, ?demo=1; js/messages-redirect.js, with a meta refresh as the fallback), chosen over a vercel.json redirect because it also works with the local python3 -m http.server and needs no extra CSP rule. The messages table and its data stay: photo messages, task proofs, and moments are rows of it. Parents can no longer reply under a photo (no sitter screen showed replies once Messages was gone); replies written before stay under their photo in the parent's Today feed, read-only. The shift (start, end, reopen, history), task check-offs with photo proofs, moments, photo messages, and care logs are in Supabase (js/shift-data.js: Postgres, the private photos Storage bucket, and Realtime) for both roles; ?demo=1 keeps them in this browser (js/store.js). The parent's Today page (parent.html) shows today's shift status (not started / active / reopened / ended) with its history, "x of y done", the schedule (a parent can mark a task done without a photo, "Done by ", and end or reopen the shift), and a live feed of the shift's proofs and moments (Late, "Added after reopen", "Photo removed by ", earlier replies (read-only), "New" until seen via message_reads). New photos (proofs, moments, and the sitter's photo messages) and shift events raise an in-app banner and a polite live announcement (no push notifications); View scrolls to a new feed photo, or opens the Gallery when only photo messages are new (they stay out of the Today feed). Save photo uses the Web Share API with files on touch devices, otherwise a JPEG download, and adds it to the parent's Album (#album, photo_saves). Remove photo calls remove_photo and then deletes the object from Storage. The concept alert (concept_flags) and "Bring moment forward" (trigger_moment_now) are demo controls shown only on localhost; the concept alert is labelled "Concept — not real analysis". The Gallery (gallery.html, both roles; parents at gallery.html?as=parent) shows every photo of the family's shifts, oldest first with the newest at the bottom, under a heading per shift date, each labelled Task update, Photo message, or Moment, with a filter (native radios styled as chips); removed photos are skipped. The sitter's "+" (Add a photo) opens the phone's camera or library (<input type="file" accept="image/*">), then a dialog with the preview and an optional caption, and sends a photo message; it is disabled with the reason when the shift isn't open. A shift takes up to 20 photo messages; past that the sitter sees "Photo limit reached for this shift." Parents get "Remove photo" on each photo. On manage.html, "Remove from schedule" archives a task (archived_at, stamped by the database); past shifts keep it. Parents book and edit sessions on the Schedule tab (schedule.html) in Schedule Details. Times are picked with hour, minute (5-minute steps), and AM/PM selects, which phones show as scroll wheels; a new activity starts at the session's start time. An end time earlier than the start means the session ends the next day (SI-80): 7:00 PM to 1:00 AM is listed on the day it starts as "7:00pm – 1:00am (next day)", and the dialog shows its length under the pickers ("6 hours, ends 1:00am the next day"). An end equal to the start is refused, so a session is always under 24 hours. Sessions may not overlap, across midnight too (Friday's 7:00 PM – 1:00 AM clashes with Saturday's 12:30 AM); the app checks this (js/schedule-dates.js), the database does not. An overnight session's activities after midnight sort after its evening ones, and the Current Session/Shift card (and the Children tab's next-sit tag, "Now until 1:00 AM") keep showing it after midnight until it ends, updating each minute without a reload. While it is under way, today's list starts with "Continues from yesterday until 1:00am" (tap it to see that session) and offers no Request Schedule, and the Current Session pencil edits that session (its own date stays allowed). Saving a session longer than 12 hours asks first ("This session is 20 hours long, ending 5:00am the next day. Save it?"), to catch an AM/PM slip. There is no caregiver picker: a session is not assigned to a sitter yet. Parents pick which children a session is for (every child by default, and for sessions saved before children were recorded) and which of those children each activity is for; the sitter sees "For Jack" on an activity that is for only some of the session's children. Adding, editing, or deleting an activity shows in the list at once and is kept when the parent taps Save (closing without saving discards it); an activity still being typed when Save is tapped is added, and Enter in the activity's name adds it rather than saving the whole session. Delete Schedule removes the whole session, after a confirmation, for everyone in the family. Outside demo mode the bundled sample family is discarded before anything renders, so a signed-in person never sees sample content; an empty family shows "No information provided". A parent's edits (schedule, care info, contacts, children) reach every open page of the family within a second or two, without a reload (Realtime; refetched on return to the tab too).

Demo for user testing

Open demo.html and pick Try as the babysitter (index.html?demo=1) or Try as a parent (parent.html?demo=1). No sign-in is needed. The demo families are in js/data.js:

• Babysitter (Bethany) sits for the Thomas family (Jack, age 3, and Kylie, age 6) and the Rivera family (Sofia, age 6), and switches between them with the "Family space" bar at the top of each page. Kylie has no food info, so her page shows "No information provided".
• Parent (Mary Ann Thomas) sees the Thomas family, the same one the babysitter sees.

Each family has a profile, care info (food and allergies, preferences, where things are, instructions, emergency steps, contacts), today's schedule, upcoming sessions, and today's care log already started (two tasks done, with care log details on them). Testers can check off tasks, add care log details and photos, add Care Log entries about each child on the Care Log tab, edit the sitter profile, and, as the parent, add, edit, and delete children and their care info, contacts, where things are, and emergency steps on the Children tab, and schedule sessions on the Schedule tab. Everything is kept in the tab's sessionStorage, so closing the tab resets the demo for the next tester. The parent's "Important today" notes are read-only in the demo. The demo tools panels (moment trigger, "Start a new shift", concept alerts) show only on localhost.

?demo=1 (remembered for the browser tab) shows the demo families from js/data.js with a "Demo mode" banner, as before accounts existed. It does not sign anyone in or out: signed out, the banner links to sign-in; signed in, it reads "Demo mode — signed in as · Exit demo" (Exit demo clears the flag). Sign-in, invite.html, and onboarding.html also clear it. Demo mode never reads the database (signed-out requests can read nothing anyway) and never reads an account's device data.

Demo data (js/store.js, ?demo=1 only: task photos, moments, messages, check-offs, care logs and Care Log entries) is in sessionStorage under carenest:demo:v1:<family>, with the demo family's edits under carenest:demo:data:<family>; all of it ends with the tab. Signed-in people's photos and messages are not kept on the device. Each account's device key is carenest:v1:<user id>, picked by the auth guard; signed-out visitors get no key. Signing out, or the guard finding no family space, removes that account's key; deleting the account removes every carenest:* key in that browser. The pre-accounts shared key carenest:v1 is discarded on load (it can't be attributed to one account). The sitter profile used to be kept only on the device under carenest:sitter-profile:<user id>; it now lives in the database, and the profile page moves that old copy there once and then deletes the key.

Security headers (CSP with Google Identity Services' documented sources, frame-ancestors 'none', nosniff, Referrer-Policy, Permissions-Policy) are set for every route in vercel.json. style-src includes 'unsafe-inline' because Google's sign-in script injects its own <style> element and style attributes (the button renders broken without it); script-src has no inline allowance. python3 -m http.server does not send these headers.

Config is in js/config.js and is public by design: the Supabase URL, the publishable key, and the Google OAuth client ID. On localhost/127.0.0.1 the app uses the local stack (http://127.0.0.1:55321, the CLI's built-in local publishable key) and shows a password "Local development sign-in" form; every other host uses the hosted project. Run it locally with python3 -m http.server 8000 from the repo root and open http://localhost:8000/signin.html.

Sign-in architecture

Google is the only sign-in method, through Supabase Auth with Google Identity Services (GIS):

• signin.html and invite.html load https://accounts.google.com/gsi/client and render Google's button on our own origin (js/signin-widget.js), popup or FedCM only: no One Tap and no auto-select. Google returns an ID token; supabase.auth.signInWithIdToken exchanges it for a session. No redirect, so no tokens ever appear in the URL (detectSessionInUrl: false).
• Nonce: each page load makes a random 256-bit raw nonce and its SHA-256 hex. Google gets the hash (it copies it into the ID token); Supabase gets the raw value, hashes it, and compares, so an ID token from another page load is rejected.
• supabase-js is the UMD build from jsDelivr pinned to an exact version (2.117.2, matching tests/package.json) with a Subresource Integrity hash, so a changed file is refused. Google's GIS script is evergreen and cannot be pinned or hashed.
• Invite links put the token in the URL fragment (invite.html#<token>), which browsers never send to a server, and invite.html sets <meta name="referrer" content="strict-origin"> so only the origin ever leaves in a Referer. After accepting, the page replaces itself, so the token leaves the tab's history.
• Hosted project setup: Supabase → Auth → Providers → Google enabled with this client ID listed; the Email provider OFF (see below). The Google OAuth client must list each site origin (the Vercel URL, and http://localhost:8000 for local Google testing) as an authorized JavaScript origin.

Local database

The Supabase schema is in supabase/migrations/. Everything below runs against a local Supabase stack in Docker; nothing here touches a hosted project.

cd tests
npm install          # pinned Supabase CLI + supabase-js
npm run db:start     # local stack; ports are 553xx so it never collides with Carekeeper's 543xx
npm run db:reset     # applies migrations, then supabase/seed.sql
npm run test:rls     # authorization tests (refuse to run against a non-local URL)
npm run test:unit    # care-log age parser, config port override, next activity, ... (no database needed)
npm run db:lint      # supabase db lint
npm run db:stop
npm run db:env       # which stack this checkout uses, and its ports

Local ports: API 55321, Postgres 55322, Studio 55323, Mailpit 55324.

Parallel worktrees

Every npm run db:* and test:rls goes through tests/stack.sh. In the main checkout it changes nothing. In a linked git worktree (git worktree add ../CareNest-x) it runs a separate stack: project carenest-<worktree folder>-<slot> with its own containers and volumes, and every port shifted by slot × 100, where the slot (1-40) is derived from the folder name, so one session's db reset cannot wipe another's data. npm run db:env prints the slot and ports. If two worktrees land on the same slot, db:start fails with "port is already allocated"; pick a free one with CARENEST_STACK_SLOT=<n> npm run db:start and use the same variable for that worktree's other commands (without it they find no running stack and fail). CARENEST_STACK_SLOT=0 means the main checkout's shared stack. A stack started before this script existed (or under a hand-picked project_id) is not stopped by db:stop; stop it once by name with npx supabase stop --project-id <old id> if it holds the ports. Stop stacks you are done with (npm run db:stop); each one holds a few GB of Docker memory. When Docker is short on memory and db:start times out on health checks, start only what the tests need: npm run db:start -- -x studio,logflare,vector,edge-runtime,imgproxy,postgres-meta.

To point the site at a worktree's stack, serve that checkout on its own port and open it once with ?supabasePort=<API port> (for example http://localhost:8001/?supabasePort=57521). The page remembers it for that origin; ?supabasePort= (empty) goes back to 55321. The override works only on localhost, only changes the port on 127.0.0.1, and only accepts stack API ports (55321 plus a multiple of 100, up to 59321).

Demo family (local only)

supabase/seed.sql loads the demo family from js/data.js (Jack Thomas and Kylie Thomas: the day's schedule, care info, food and allergies, emergency steps, contacts with Mary Ann as the primary contact, the home address, and the hospital) into a household with id 00000000-0000-4000-8000-00000000c0de that has no members. Users cannot be created from SQL, so sign up on the local stack, then attach yourself as its parent in Studio's SQL editor:

insert into public.household_members (household_id, user_id, role, email, display_name)
select '00000000-0000-4000-8000-00000000c0de', id, 'parent', lower(email), 'Mary'
from auth.users where email = '[email protected]';

Seeds run only on a local supabase db reset; never run seed.sql against a hosted project.

Data model

Table	Holds	Who can write
households	Family space name, optional home address, and the old single-child columns child_name and child_age_label (transitional: only tabs still open on the pre-SI-45 client write these)	Created by create_household, which also creates the first child; parents edit the name, the child columns, and the home address. Only current members read the address
children	One row per child: name, age label, stage label, pinned note, order	Members read; parents add, edit, and delete. Reads, adds, and edits use column grants (delete is table-level): a child's household, id, and creation time are fixed, so a child never moves to another family space
household_members	Parent and caretaker roles. An account is a parent of at most one family space (a partial unique index) and a sitter in any number, including while a parent elsewhere	Added only by RPCs; parents remove caretakers
invites	Email-bound invites (token hash, 7-day expiry)	Created by create_invite; parents revoke
care_items	Preferences, where things are, instructions, emergency steps, food/allergies (with severity). Food, preferences, and instructions belong to one child (child_id set, enforced by a check); where things are and emergency steps are family-wide (child_id is null, enforced by a check)	Parents. A composite foreign key means an item can only point at a child of its own family space. Deleting a child deletes that child's items
contacts	People and places to call (including the hospital, with address), shared by the family space; at most one primary contact per family space (is_primary, a deferrable exclusion constraint, so one update can move primary to another contact)	Parents
day_notes	"Important today": notes for one calendar date (category, title, detail); who wrote and last edited each, and when	Parents add, edit, delete; members read. Authorship and edit times are set by the database (a trigger), so "Updated" cannot be forged; a note never moves to another family space
plans, tasks	The child's day (one plan per family space): ordered tasks with time, detail, location, care note, usual hours

Data and risk boundaries

• Every table has Row Level Security enabled and denies by default. Signed-out (anon) requests can read nothing and call no function in public. The browser will only ever hold the public publishable key; there is no service-role or secret key in the app.
• Signed-in users get only the table and column privileges the app needs, and RLS narrows rows to their own household. Only parents change care info, contacts, plans, and tasks. Caretakers read everything in their household, start shifts, check and uncheck tasks, add care logs to checked tasks and Care Log entries about the family's children, and write the handoff note. Later migrations start closed too: new tables, sequences, and functions in public get no anon/authenticated privileges (schema-scoped default privileges revoked). Postgres also gives every new function EXECUTE to PUBLIC in every schema by default, which a schema-scoped revoke cannot remove, so the migration additionally revokes that globally for functions created by postgres: any function a later migration adds, in any schema, must be granted explicitly to be callable.
• Note for T3 and later migrations: every function created by postgres in a later migration is NOT executable by anon or authenticated until it is explicitly granted (grant execute on function ... to authenticated). This also covers helpers used in column defaults, CHECK constraints, RLS or storage policies, and functions from extensions created by postgres. The migration author must add the grant; a missing grant fails closed with 42501 (permission denied).
• Sitter profiles. Each sitter owns their sitter_profiles row; only they can read or change it, and the row's owner is set by the database (auth.uid()), never by the client. Parents see a sitter's profile only through household_sitter_profiles(household), which returns rows to a parent of that family space, only for its current caretakers, and returns about, phone, and availability as NULL unless the sitter chose to share them. That filtering is server-side, so hidden fields and the private reminders preference never reach a parent's browser. A profile saved on a device before this change is moved to the database once and the device copy is deleted.
• Children (SI-45). 20261102000000_carenest_children.sql gave every household exactly one children row (blank ones included) and moved its food, preferences, and instructions to that child. The client reads and writes children and per-child care_items directly (20261106000000_carenest_children_client.sql): creates the first child, and onboarding names it. A tab left open on the old client from before that deploy still writes , , and care items with no child id, so two transitional triggers stay for a grace period: a change to one of the household's child columns copies that column to the first child (lowest position), and a per-child care item saved with no child goes to the first child (creating one if every child was deleted). The copy runs one way only: a direct edit of a child does not change the household's columns. Until it reloads, an old tab also shows every child's food items in one list under the first child's name (it shows more restrictions, never fewer), and an allergy it saves goes to whichever child is first, so reordering children in Family info changes which one. The check (validated by ) makes a child required for food, preferences, and instructions. Once no old tab can be open, a later migration drops the two triggers, then , then the household child columns, in that order.

Deploying to a hosted Supabase project

The migration does not depend on dashboard toggles, but two settings must match it:

• Auth providers: Google only, with the Email provider OFF. Invites trust the account's verified email. With email sign-up enabled (especially with "Confirm email" off), anyone could create a self-confirmed account under an invitee's address and accept their invite.
• "Automatically expose new tables" OFF (Data API settings), matching the migration's revoked default privileges, so a table added later is not exposed until a migration grants it.

Schema changes reach the hosted project (carenest, ref ibwshlbhszznfhmeckda) only through supabase db push, which records each version in supabase_migrations.schema_migrations, so the project's history shows exactly which migrations it has. Never apply a migration by pasting SQL or with supabase db query: that skips the history, and the next db push would try to run it again. From tests/, with the pinned CLI installed (npm ci) and logged in (npx supabase login):

npm ci
npx supabase db push --workdir .. --project-ref ibwshlbhszznfhmeckda --dry-run
npx supabase db push --workdir .. --project-ref ibwshlbhszznfhmeckda

• Run the dry run first: it must list exactly the new migration files, in version order. If it lists a migration the project already has, stop and compare the hosted schema with that file before repairing the history (npx supabase migration repair --workdir .. --project-ref ibwshlbhszznfhmeckda --status applied <version>).
• Deploy migrations before merging the frontend change that needs them: once the PR is approved, rebase it on main, push, and merge right away. Vercel deploys main on merge, so the new pages must never reach a database without their tables and functions (and the live site must keep working against the migrated database until the merge lands).
• A pushed migration is frozen: never edit its file (the history only records the version, so db push would report up to date while production differs). Fix it with a new migration.
• Never use db push --include-all or migration repair --status reverted here. If the dry run says a remote version is missing locally, rebase on main; if a new migration's version is older than one already pushed, rename it to a newer timestamp so it runs in order.
• Migrations up to 20261017000000 were applied as SQL before the history existed and were marked applied with migration repair after their hosted schema was compared with the repo.

Photo cleanup (one-time per project)

The cleanup job reads two Vault secrets, which are not in any migration because one is a secret key. Its deletes are permanent: database backups do not restore Storage objects. So first, in the SQL editor (after db push), review what the first runs will delete, and move anything that must stay out of the photos bucket:

select o.name, o.created_at
  from public.photo_orphans() n (name)
  join storage.objects o on o.bucket_id = 'photos' and o.name = n.name;

Then create a dedicated secret key (Dashboard → Project Settings → API Keys → Secret keys → New, named photo-cleanup) so it can be revoked on its own, and run:

select vault.create_secret('https://ibwshlbhszznfhmeckda.supabase.co', 'carenest_project_url');
select vault.create_secret('<the sb_secret_... key>', 'carenest_photo_cleanup_key');

Check the URL and key right away, without waiting for an orphan. Run this on its own (pg_net sends the request only after the statement commits):

select net.http_get(
  (select decrypted_secret from vault.decrypted_secrets where name = 'carenest_project_url')
    || '/storage/v1/bucket/photos',
  headers := jsonb_build_object('apikey',
    (select decrypted_secret from vault.decrypted_secrets where name = 'carenest_photo_cleanup_key'))
) as request_id;

A few seconds later, with the returned id, this must show 200:

select status_code, left(content, 200), error_msg from net._http_response where id = <request_id>;

After a run (each hour at :17), the job's latest run should have succeeded and, when there was something to delete, Storage should have answered 200 (pg_net keeps responses for 6 hours). Storage answers after the sweep has committed, so a rejected delete (a wrong or revoked key) shows in the check job, carenest-photo-cleanup-check at :47: it fails with photo_cleanup_failed, and its return_message has the status and response. The refused paths are skipped with backoff (1 to 2 hours, doubling with each failure up to a day) so newer orphans still go; they are listed in public.photo_sweep_failures. To retry them at the next run, update public.photo_sweep_failures set retry_at = now();. A manual select public.sweep_orphan_photos() settles the earlier requests itself, so after one, look at last_status in public.photo_sweep_failures rather than at the check job. pg_net briefly stores the key in net.http_request_queue: never add the net schema to the Data API's exposed schemas.

select j.jobname, d.status, d.return_message, d.start_time
  from cron.job_run_details d join cron.job j using (jobid)
 where j.jobname in ('carenest-photo-cleanup', 'carenest-photo-cleanup-check')
 order by d.start_time desc limit 6;
select status_code, left(content, 200), error_msg, created from net._http_response
 order by created desc limit 3;

To rotate the key, select vault.update_secret(id, '<new key>') from vault.secrets where name = 'carenest_photo_cleanup_key';. To pause the cleanup, pause both jobs (the check alone would fail once pg_net drops the last response), select cron.unschedule('carenest-photo-cleanup'); select cron.unschedule('carenest-photo-cleanup-check');; to resume, select cron.schedule('carenest-photo-cleanup', '17 * * * *', 'select public.sweep_orphan_photos()'); select cron.schedule('carenest-photo-cleanup-check', '47 * * * *', 'select public.check_photo_sweep()');.