\n\nAnd I thought, why am I here manually marking this task overdue? Why am _I_\nmanually doing _anything_? Manual is for mans. So I'm building Notion Boyfriend\nto automate this kind of stuff for me. A handsome little set of Deno scripts in\na nice jacket to whom I can say, \"Baby can you email a list of my 3 highest\npriority tasks organized by [xyz] criteria\" while I kick back and sip an ice\ncold Diet Coke.\n\nThe best part about Notion Boyfriend is you can make your own, then make him\nyour own, the sky's the limit. Really there's no limit. _Unlimited boyfriend_,\nthat's the power of Deno and Val Town.\n\n## Utilities\n\nEach util lives in its own top-level file with a default export that wires up\nits trigger (cron, HTTP, or webhook). In Val Town, point the configured trigger\ntype at the file.\n\n### `label_overdue.ts`\n\nWalks every configured Tasks data source, finds pages whose `Due` date is before\ntoday (in `America/Chicago`) and whose `Status` is \"not started\" or \"in\nprogress\" flavored, and flips them to the `Overdue` status. Set conditional\nformatting on the `Overdue` value in Notion to make rows pop red.\n\n**Trigger:** cron (or HTTP for manual runs). Set around 2:30am\n`America/Chicago` — Val Town crons run UTC, so use `30 7 * * *` during CDT or\n`30 8 * * *` during CST.\n\n**Required env vars:**\n\n- `NOTION_TOKEN` — internal integration token from developers.notion.com\n- `NOTION_TASK_DATA_SOURCE_IDS` — comma-separated bare data source IDs (no\n quotes)\n\nSee [`docs/label_overdue.md`](docs/label_overdue.md) for status-variation\nextension points and internals.\n\n### `cascade_access.ts`\n\nNotion guests get database-wide access by default — there's no built-in way to\ngate visibility down a relation chain. This util fakes row-level inheritance by\ncascading a `Team` people-property from `Organization` → `Project` → `Task`.\nCombined with Notion's data-source-level access rules that key off the `Team`\nproperty, each client guest only sees their own Org and everything underneath\nit.\n\n**Trigger:** HTTP webhook from a Notion automation on the **Organization** data\nsource. Organization is the source of truth; the cascade only flows downward.\nManual additions to a Project's or Task's `Team` will be overwritten the next\ntime its parent Org fires the webhook.\n\n**Flow on each webhook:**\n\n1. Authenticate the request via the `X-Notion-Webhook-Secret` header (constant-\n time compare; rejection paths return a bare `404`).\n2. Read the triggering Org page; walk its `Projects` relation to find affected\n projects, and each project's `Tasks` relation to find affected tasks.\n3. For each affected project, set `Team` to the union of its parent Orgs'\n teams. Skip writes when already correct.\n4. For each affected task, set `Team` to the union of its parent Projects'\n teams (post-update). Same skip/warn behavior.\n\n**Required env vars:**\n\n- `NOTION_TOKEN`\n- `NOTION_WEBHOOK_SECRET` — shared secret sent by Notion as\n `X-Notion-Webhook-Secret`\n- `NOTION_ORGANIZATION_DATASOURCE_ID`\n- `NOTION_PROJECT_DATASOURCE_ID`\n- `NOTION_TASK_DATASOURCE_ID`\n\n**Required Notion setup:**\n\n- Every Org, Project, and Task data source has a property named `Team` of type\n `People`.\n- Org has a relation property named `Projects` pointing at the Project DS.\n- Project has a relation property named `Organization` pointing at the Org DS\n (the bi-directional reflection of `Projects`).\n- Project has a relation property named `Tasks` pointing at the Task DS.\n- Task has a relation property named `Project` pointing at the Project DS (the\n bi-directional reflection of `Tasks`).\n- The integration is shared into all three data sources.\n- A Notion automation on the Org DS triggers on `Team` changes (and any other\n field whose change should propagate) and sends a webhook to this util's URL\n with `X-Notion-Webhook-Secret` set to `NOTION_WEBHOOK_SECRET`.\n\nSee [`docs/cascade_access.md`](docs/cascade_access.md) for auth, dispatch, and\ncascade internals.\n\n## Project layout\n\n```text\nnotion-boyfriend/\n├── label_overdue.ts # overdue-labeling util (cron + http)\n├── cascade_access.ts # team-cascade util (webhook)\n├── shared/\n│ └── notion.ts # Notion client, env helpers, sleep, trigger wrapper\n├── docs/ # internal reference docs (see AGENTS.md index)\n├── deno.json\n├── README.md\n└── AGENTS.md\n```\n\n## Configuration\n\nAll configuration is via Val Town environment variables — never bake IDs or\ntokens into the source. Utils fail fast at startup if any required env var is\nmissing or empty.\n\n## For beginners\n\n(coming soon)\n",[],[213],"b4d7968c-50d5-11f1-94f3-ee650bb23af1","AGENTS.md","5a36d6c8-fb46-11f0-a3f7-42dde27851f2",65,["D",1778901421698],2,"You are an advanced assistant specialized in generating Val Town code.\n\n## Core Guidelines\n\n- Ask clarifying questions when requirements are ambiguous\n- Provide complete, functional solutions rather than skeleton implementations\n- Test your logic against edge cases before presenting the final solution\n- Ensure all code follows Val Town's specific platform requirements\n- If a section of code that you're working on is getting too complex, consider\n refactoring it into subcomponents\n\n## Code Standards\n\n- Generate code in TypeScript or TSX\n- Add appropriate TypeScript types and interfaces for all data structures\n- Prefer official SDKs or libraries than writing API calls directly\n- Ask the user to supply API or library documentation if you are at all unsure\n about it\n- **Never bake in secrets into the code** - always use environment variables\n- Include comments explaining complex logic (avoid commenting obvious\n operations)\n- Follow modern ES6+ conventions and functional programming practices if\n possible\n\n## Types of triggers\n\n### 1. HTTP Trigger\n\n- Create web APIs and endpoints\n- Handle HTTP requests and responses\n- Example structure:\n\n```ts\nexport default async function (req: Request) {\n return new Response(\"Hello World\");\n}\n```\n\nFiles that are HTTP triggers have http in their name like `foobar.http.tsx`\n\n### 2. Cron Triggers\n\n- Run on a schedule\n- Use cron expressions for timing\n- Example structure:\n\n```ts\nexport default async function () {\n // Scheduled task code\n}\n```\n\nFiles that are Cron triggers have cron in their name like `foobar.cron.tsx`\n\n### 3. Email Triggers\n\n- Process incoming emails\n- Handle email-based workflows\n- Example structure:\n\n```ts\nexport default async function (email: Email) {\n // Process email\n}\n```\n\nFiles that are Email triggers have email in their name like `foobar.email.tsx`\n\n## Val Town Standard Libraries\n\nVal Town provides several hosted services and utility functions.\n\n### Blob Storage\n\n```ts\nimport { blob } from \"https://esm.town/v/std/blob\";\nawait blob.setJSON(\"myKey\", { hello: \"world\" });\nlet blobDemo = await blob.getJSON(\"myKey\");\nlet appKeys = await blob.list(\"app_\");\nawait blob.delete(\"myKey\");\n```\n\n### SQLite\n\n```ts\nimport { sqlite } from \"https://esm.town/v/stevekrouse/sqlite\";\nconst TABLE_NAME = \"todo_app_users_2\";\n// Create table - do this before usage and change table name when modifying schema\nawait sqlite.execute(`CREATE TABLE IF NOT EXISTS ${TABLE_NAME} (\n id INTEGER PRIMARY KEY AUTOINCREMENT,\n name TEXT NOT NULL\n)`);\n// Query data\nconst result = await sqlite.execute(\n `SELECT * FROM ${TABLE_NAME} WHERE id = ?`,\n [1],\n);\n```\n\nNote: When changing a SQLite table's schema, change the table's name (e.g., add\n_2 or _3) to create a fresh table.\n\n### OpenAI\n\n```ts\nimport { OpenAI } from \"https://esm.town/v/std/openai\";\nconst openai = new OpenAI();\nconst completion = await openai.chat.completions.create({\n messages: [\n { role: \"user\", content: \"Say hello in a creative way\" },\n ],\n model: \"gpt-4o-mini\",\n max_tokens: 30,\n});\n```\n\n### Email\n\n```ts\nimport { email } from \"https://esm.town/v/std/email\";\n// By default emails the owner of the val\nawait email({\n subject: \"Hi\",\n text: \"Hi\",\n html: \"

Hi

\",\n});\n```\n\n## Val Town Utility Functions\n\nVal Town provides several utility functions to help with common project tasks.\n\n### Importing Utilities\n\nAlways import utilities with version pins to avoid breaking changes:\n\n```ts\nimport {\n parseProject,\n readFile,\n serveFile,\n} from \"https://esm.town/v/std/utils@85-main/index.ts\";\n```\n\n### Available Utilities\n\n#### **serveFile** - Serve project files with proper content types\n\nFor example, in Hono:\n\n```ts\n// serve all files in frontend/ and shared/\napp.get(\"/frontend/*\", (c) => serveFile(c.req.path, import.meta.url));\napp.get(\"/shared/*\", (c) => serveFile(c.req.path, import.meta.url));\n```\n\n#### **readFile** - Read files from within the project:\n\n```ts\n// Read a file from the project\nconst fileContent = await readFile(\"/frontend/index.html\", import.meta.url);\n```\n\n#### **listFiles** - List all files in the project\n\n```ts\nconst files = await listFiles(import.meta.url);\n```\n\n#### **parseProject** - Extract information about the current project from import.meta.url\n\nThis is useful for including info for linking back to a val, ie in \"view source\"\nurls:\n\n```ts\nconst projectVal = parseProject(import.meta.url);\nconsole.log(projectVal.username); // Owner of the project\nconsole.log(projectVal.name); // Project name\nconsole.log(projectVal.version); // Version number\nconsole.log(projectVal.branch); // Branch name\nconsole.log(projectVal.links.self.project); // URL to the project page\n```\n\nHowever, it's _extremely importing_ to note that `parseProject` and other\nStandard Library utilities ONLY RUN ON THE SERVER. If you need access to this\ndata on the client, run it in the server and pass it to the client by splicing\nit into the HTML page or by making an API request for it.\n\n## Val Town Platform Specifics\n\n- **Redirects:** Use\n `return new Response(null, { status: 302, headers: { Location: \"/place/to/redirect\" }})`\n instead of `Response.redirect` which is broken\n- **Images:** Avoid external images or base64 images. Use emojis, unicode\n symbols, or icon fonts/libraries instead\n- **AI Image:** To inline generate an AI image use:\n `

`\n- **Storage:** DO NOT use the Deno KV module for storage\n- **Browser APIs:** DO NOT use the `alert()`, `prompt()`, or `confirm()` methods\n- **Weather Data:** Use open-meteo for weather data (doesn't require API keys)\n unless otherwise specified\n- **View Source:** Add a view source link by importing & using\n `import.meta.url.replace(\"ems.sh\", \"val.town)\"` (or passing this data to the\n client) and include `target=\"_top\"` attribute\n- **Error Debugging:** Add\n `` to HTML to capture\n client-side errors\n- **Error Handling:** Only use try...catch when there's a clear local\n resolution; Avoid catches that merely log or return 500s. Let errors bubble up\n with full context\n- **Environment Variables:** Use `Deno.env.get('keyname')` when you need to, but\n generally prefer APIs that don't require keys\n- **Imports:** Use `https://esm.sh` for npm and Deno dependencies to ensure\n compatibility on server and browser\n- **Storage Strategy:** Only use backend storage if explicitly required; prefer\n simple static client-side sites\n- **React Configuration:** When using React libraries, pin versions with\n `?deps=react@18.2.0,react-dom@18.2.0` and start the file with\n `/** @jsxImportSource https://esm.sh/react@18.2.0 */`\n- Ensure all React dependencies and sub-dependencies are pinned to the same\n version\n- **Styling:** Default to using TailwindCSS via\n `` unless otherwise\n specified\n\n## Project Structure and Design Patterns\n\n### Recommended Directory Structure\n\n```\n├── backend/\n│ ├── database/\n│ │ ├── migrations.ts # Schema definitions\n│ │ ├── queries.ts # DB query functions\n│ │ └── README.md\n│ └── routes/ # Route modules\n│ ├── [route].ts\n│ └── static.ts # Static file serving\n│ ├── index.ts # Main entry point\n│ └── README.md\n├── frontend/\n│ ├── components/\n│ │ ├── App.tsx\n│ │ └── [Component].tsx\n│ ├── favicon.svg\n│ ├── index.html # Main HTML template\n│ ├── index.tsx # Frontend JS entry point\n│ ├── README.md\n│ └── style.css\n├── README.md\n└── shared/\n ├── README.md\n └── utils.ts # Shared types and functions\n```\n\n### Backend (Hono) Best Practices\n\n- Hono is the recommended API framework\n- Main entry point should be `backend/index.ts`\n- **Static asset serving:** Use the utility functions to read and serve project\n files:\n ```ts\n import {\n readFile,\n serveFile,\n } from \"https://esm.town/v/std/utils@85-main/index.ts\";\n\n // serve all files in frontend/ and shared/\n app.get(\"/frontend/*\", (c) => serveFile(c.req.path, import.meta.url));\n app.get(\"/shared/*\", (c) => serveFile(c.req.path, import.meta.url));\n\n // For index.html, often you'll want to bootstrap with initial data\n app.get(\"/\", async (c) => {\n let html = await readFile(\"/frontend/index.html\", import.meta.url);\n\n // Inject data to avoid extra round-trips\n const initialData = await fetchInitialData();\n const dataScript = ``;\n\n html = html.replace(\"\", `${dataScript}`);\n return c.html(html);\n });\n ```\n- Create RESTful API routes for CRUD operations\n- Always include this snippet at the top-level Hono app to re-throwing errors to\n see full stack traces:\n ```ts\n // Unwrap Hono errors to see original error details\n app.onError((err, c) => {\n throw err;\n });\n ```\n\n### Database Patterns\n\n- Run migrations on startup or comment out for performance\n- Change table names when modifying schemas rather than altering\n- Export clear query functions with proper TypeScript typing\n\n## Common Gotchas and Solutions\n\n1. **Environment Limitations:**\n - Val Town runs on Deno in a serverless context, not Node.js\n - Code in `shared/` must work in both frontend and backend environments\n - Cannot use `Deno` keyword in shared code\n - Use `https://esm.sh` for imports that work in both environments\n\n2. **SQLite Peculiarities:**\n - Limited support for ALTER TABLE operations\n - Create new tables with updated schemas and copy data when needed\n - Always run table creation before querying\n\n3. **React Configuration:**\n - All React dependencies must be pinned to 18.2.0\n - Always include `@jsxImportSource https://esm.sh/react@18.2.0` at the top of\n React files\n - Rendering issues often come from mismatched React versions\n\n4. **File Handling:**\n - Val Town only supports text files, not binary\n - Use the provided utilities to read files across branches and forks\n - For files in the project, use `readFile` helpers\n\n5. **API Design:**\n - `fetch` handler is the entry point for HTTP vals\n - Run the Hono app with\n `export default app.fetch // This is the entry point for HTTP vals`\n\n## Project reference docs\n\nLoad on demand — these are not auto-imported.\n\ndocs/project-conventions.md\ndocs/cascade_access.md\ndocs/label_overdue.md\ndocs/shared-helpers.md\n",[],[221],["D",1778821754180],[],[18,64],["D",1778821754032],[177],[18],"b4bf3d9e-50d5-11f1-8cff-ee650bb23af1","shared-helpers.md","b4bf3eb6-50d5-11f1-8cff-ee650bb23af1","b4b0780e-50d5-11f1-ac77-ee650bb23af1",62,["D",1778901421581],"# `shared/notion.ts` helpers\n\nTiny module of cross-util utilities. Keep it small — promote a helper here only\nwhen a second util needs it.\n\n## Exports\n\n| Symbol | Purpose |\n| --- | --- |\n| `NOTION_API_VERSION` | Version string for the pinned `@notionhq/client` (`5.21.0`). Update alongside the `npm:` specifiers in util files. |\n| `requireEnv(name)` | Reads a non-empty env var, trims whitespace, throws on missing/empty. Fail-fast at boot. |\n| `requireEnvList(name)` | `requireEnv` + split on `,` + trim + drop empties. Throws if the resulting list is empty. Used for `NOTION_TASK_DATA_SOURCE_IDS`. |\n| `makeNotionClient()` | Returns a `Client` authed with `NOTION_TOKEN`. One per module, called at module load. |\n| `SLEEP_MS` | `400` — sized to stay safely under Notion's published ~3 req/s write limit. |\n| `sleep(ms?)` | `setTimeout` promise; defaults to `SLEEP_MS`. Call after every Notion write. |\n| `asTrigger(run)` | Wraps an async function so the same default export serves cron (`Request === undefined`) and HTTP. Logs JSON on cron, returns JSON `Response` on HTTP. **Not used by `cascade_access.ts`** — that file has a custom handler for webhook auth. |\n\n## When NOT to use `asTrigger`\n\n`asTrigger` assumes the trigger is unauthenticated and the only output shape is\n`{ ok, durationMs, result }`. For webhooks needing header auth, pre-screening,\nor opaque rejection responses, write a custom `handler` directly (see\n`cascade_access.ts`).\n\n## Conventions\n\n- Notion SDK version pinned via the `npm:@notionhq/client@5.21.0` specifier at\n each util import site — keep in sync with `NOTION_API_VERSION` here.\n- All env-var reads go through `requireEnv` / `requireEnvList` so missing\n config produces a uniform, actionable error.\n- Polite pacing (`sleep()`) is the writer's responsibility, not the client's —\n call it after every page update or DS iteration.\n",[],[244,236],"docs","b4ce2548-50d5-11f1-812b-ee650bb23af1","project-conventions.md","b4ce2624-50d5-11f1-812b-ee650bb23af1",64,["D",1778901421632],"# Project conventions\n\nPatterns that span the whole repo. Follow these when adding a new util.\n\n## One util per top-level file\n\nEach util is a single TS file at the project root with a default export wired\nto its Val Town trigger. No backend/frontend split — this is a serverless val,\nnot an app. Shared code lives in `shared/`.\n\n## Default export = trigger entry point\n\n- **Cron or HTTP** → wrap a plain async function with `asTrigger` from\n `shared/notion.ts`.\n- **Webhook with auth** → write a custom `handler(req: Request): Promise`\n directly. Don't use `asTrigger` — it has no place to do header validation or\n return opaque rejections.\n\n## Config via env vars, fail-fast\n\nAll configuration goes through `requireEnv` / `requireEnvList`. Never bake\ntokens, secrets, or IDs into source — Vals are world-readable, even though env\nvars are private. Missing or empty config throws at module load.\n\n## Notion SDK pinned per file\n\nEvery util imports from `npm:@notionhq/client@5.21.0`. When bumping, update all\nutil files and `NOTION_API_VERSION` in `shared/notion.ts` together.\n\n## Rate-limit politeness\n\nNotion publishes ~3 writes/second. Call `sleep()` (default `SLEEP_MS = 400`)\nafter every page update or DS-level iteration. Reads don't need pacing for our\nvolumes.\n\n## Logging\n\n`console.log` for normal progress, `console.warn` for recoverable surprises\n(unknown status name, missing relation), `console.error` for failures. Val Town\ncaptures all three.\n\n## Errors\n\nLet errors bubble. `asTrigger` and the webhook handler both convert thrown\nerrors to `500` JSON at the top level. Don't catch-and-log mid-flow unless\nthere's a real local recovery — per-DS loops in `label_overdue.ts` are the\nexception: they log DS context and re-throw, which is the right shape for a\nbatch operation.\n\n## Notion API quirks to remember\n\n- **DS IDs come in two forms.** Hyphenated (`213545fb-e522-4754-b5ee-32fc6ab7ef18`)\n and bare. Strip dashes before comparing — see `normalizeDsId` in\n `cascade_access.ts`.\n- **Property values cap at 25 entries** for `people` and `relation`. The page\n response sets `has_more: true` when truncated. Both utils throw on `has_more`\n rather than silently miss data; extend to paginated property reads if a real\n case hits the cap.\n- **`isFullPage` before treating a query result as a page.** Notion can return\n partial objects (e.g. data sources, blocks) in query results; the guard\n narrows the type.\n",[],[244,246],"b4e9e832-50d5-11f1-a37b-ee650bb23af1","label_overdue.md","b4e9e90e-50d5-11f1-a37b-ee650bb23af1",["D",1778901421844],"# `label_overdue.ts` internals\n\nMarks tasks whose `Due` date is in the past and whose `Status` is still in a\n\"not started\" or \"in progress\" flavor as `Overdue`. Runs over every DS in\n`NOTION_TASK_DATA_SOURCE_IDS`.\n\n## Trigger model\n\nDefault export is wrapped in `asTrigger`, so the same file works as either:\n\n- **Cron** — Val Town calls it with no `Request`; result is logged as JSON.\n- **HTTP** — Val Town passes a `Request`; result is returned as a JSON `Response`.\n\nNo authentication. Intended for cron; HTTP entrypoint exists for manual runs.\n\n## Status categorization\n\n`Status` option names vary across data sources, so the util classifies each\noption name (lowercased) against three variation arrays:\n\n- `NOT_STARTED_VARIATIONS` — `not started`, `todo`, `backlog`, `on hold`, etc.\n- `IN_PROGRESS_VARIATIONS` — `in progress`, `doing`, `active`, etc.\n- `DONE_VARIATIONS` — `done`, `complete`, `cancelled`, `archived`, etc.\n\nThe literal `Overdue` value is treated as `done` (so re-running is idempotent).\nAny option not matching a known variation is logged as a warning and skipped —\nadd it to the appropriate array to onboard a new DS dialect.\n\nThe filter sent to Notion includes only the options that classify as\n`notStarted` or `inProgress`, so the query stays scoped.\n\n## Date filter\n\nToday's date is computed in `America/Chicago` via `Intl.DateTimeFormat` with\n`en-CA` locale (yields `YYYY-MM-DD`). The Notion filter uses `date.before`\nagainst this string. A second client-side date check (`pageDate >= todayLocal`)\nguards against edge-of-day timezone slippage on the Notion side.\n\n## Per-DS error handling\n\nEach DS is processed in sequence with a `sleep()` between DSes. If one DS\nthrows (auth error, missing `Status` property, all-unknown options), the error\nis logged with DS ID context and re-thrown — the whole run fails fast rather\nthan silently skipping a DS.\n\n## Required Notion setup\n\n- Every Tasks DS in `NOTION_TASK_DATA_SOURCE_IDS` has a `Status` status\n property with at least one option matching a `notStarted` or `inProgress`\n variation, plus an `Overdue` option.\n- A `Due` date property exists on each DS.\n- The integration is shared into every Tasks DS.\n",[],[244,254],"b4dc59a6-50d5-11f1-a71a-ee650bb23af1","cascade_access.md","b4dc5a6e-50d5-11f1-a71a-ee650bb23af1",66,["D",1778901421613],"# `cascade_access.ts` internals\n\nWebhook-driven downward cascade of the `Team` people-property from Organization\n→ Project → Task. Organization is the source of truth.\n\n## Trigger model\n\nA Notion automation on the **Organization** data source POSTs JSON to this val\nwhen an Org changes. The util dispatches on `data.parent.data_source_id` — the\nDS the changed page lives in — so the same handler would also work if\nautomations were later added to Project or Task DSes, but in current setup only\nOrg fires.\n\nThe webhook payload's `data.id` is the changed page; `data.parent.data_source_id`\nidentifies which level (Org / Project / Task) triggered.\n\n## Authentication\n\nThree-layer pre-screen before any work:\n\n1. **Method gate** — non-`POST` requests return bare `404` (no body).\n2. **Content-type gate** — non-`application/json` returns bare `404`.\n3. **Secret check** — `X-Notion-Webhook-Secret` header compared to\n `NOTION_WEBHOOK_SECRET` env var via `safeEqual` (constant-time XOR). Missing\n or mismatched header returns bare `404`.\n\nBare `404` on every rejection path means scanners, stray GETs, and brute-force\nattempts see no signal that an endpoint exists or what header name to target.\nThe val URL is public (Vals are world-readable), so the secret is the only\nboundary.\n\n## Dispatch by level\n\nOrg/Project/Task DS IDs are compared with dashes stripped (`normalizeDsId`)\nsince Notion mixes hyphenated and bare forms.\n\n| Trigger level | Affected projects | Affected tasks |\n| --- | --- | --- |\n| Organization | Org's `Projects` relation | Each project's `Tasks` relation |\n| Project | The project itself | Project's `Tasks` relation |\n| Task | — | The task itself |\n\nA trigger from an unknown DS throws — the handler returns `500` with the error\nmessage, surfacing misconfiguration loudly.\n\n## Relation names (hardcoded)\n\n| Source DS | Relation property | Target DS |\n| --- | --- | --- |\n| Organization | `Projects` | Project |\n| Project | `Organization` | Organization |\n| Project | `Tasks` | Task |\n| Task | `Project` | Project |\n\nThe two pairs are bi-directional reflections in Notion. If property names ever\nchange, update the constants at the top of `cascade_access.ts`.\n\n## Team computation\n\n`updateTeamFromParents` is the same shape at both levels:\n\n1. Read the page's parent-relation property (`Organization` for projects,\n `Project` for tasks).\n2. Fetch each parent (via per-request cache); union their `Team` people IDs.\n3. Compare to the page's current `Team` (set equality). Write only if\n different.\n4. Sleep `SLEEP_MS` after each write for Notion rate-limit politeness.\n\nA page with no parent relation logs a warning and clears its `Team` — there's\nnothing to inherit from. That state is reported as `orphaned` in the result.\n\n## Per-request page cache\n\n`makePageCache` memoizes `notion.pages.retrieve` for the duration of a single\nwebhook. When many tasks share the same project parent, the project is fetched\nonce instead of N times. The cache is per-request (not module-level), so each\nwebhook starts fresh — no stale-page hazard across invocations.\n\n## Limitations\n\n- **25-entry property cap.** People and relation properties with `has_more=true`\n throw rather than silently truncate. If a team or relation grows past 25,\n extend the readers to paginate property values.\n- **Self-triggering loops.** If automations are ever added on Project or Task\n DSes too, a write at one level will fire the next level's webhook. The second\n pass finds Team already correct (set-equal) and skips, but still walks\n children — bounded, idempotent, just extra work. Today only Org fires, so no\n loop concern.\n- **Full backfill.** The previous full-sweep `cascadeTeamAccess` is gone. To\n retroactively recompute the whole tree, iterate Org IDs and POST to the\n webhook URL once per Org (or restore a scoped iterator).\n",[],[244,261],"b4b07732-50d5-11f1-ac77-ee650bb23af1",61,["D",1778901421483],[172,173,174,175],[244],["D",1768612648758],["D",1789527031073],{"_11":12,"_124":70},{"_11":12,"_119":120,"_69":70,"_31":68,"_121":122,"_123":30},{"_39":110,"_13":16,"_33":36,"_111":74,"_112":-5,"_113":-5,"_114":-5,"_115":-5,"_116":-5,"_117":14,"_118":12},"ctx",{"_52":-5,"_143":311,"_312":313,"_314":315,"_316":30,"_317":30,"_318":30,"_319":24,"_320":-5,"_321":-7,"_322":-7,"_323":26,"_324":30,"_325":30,"_326":-5,"_327":30,"_328":30,"_329":30,"_330":-5},"ENV",{"_282":283,"_284":285,"_286":16,"_287":288,"_289":290,"_291":292,"_293":294,"_295":296,"_297":298,"_299":300,"_301":302,"_303":304,"_305":306,"_307":308,"_309":310},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]

History · shared