House Desk is an independent Cloudflare Pages product for the private, auto-updating I-House Programs calendar, the public Bulletin, resident subscription management, and staff operations. It owns its own data, review workflows, delivery, roles, and permissions.
Start here
| Goal | Documentation |
|---|---|
| Subscribe to or manage Programs | Resident guide |
| Understand request and publication flow | Architecture |
| Choose the correct hostname | Origin boundary |
| Review and publish Programs | Event review and publication |
| Operate the staff console | Operations reference |
| Manage staff access and roles | Identity and access |
| Deploy, verify, or recover the service | Operations guide |
Human, admin, and email-action origin: desk.ihnyc.affectivetech.com
Private feed and compatibility origin: calendar.ihnyc-rc.org
Repository: dghauri0/ihnyc-rc-cal-landing
Product surfaces
| Surface | Purpose | Access |
|---|---|---|
/ | Resident entry to Programs, Manage, Bulletin, and staff sign-in | Public |
/subscribe-programs | Request a verified Programs subscription | Public with anti-abuse controls |
/manage | Request a short-lived link to inspect, renew, or revoke a private feed | Passwordless email action |
/contribute | Request and configure a private Programs forwarding address | Public guidance; operator enrollment |
/updates | Search reviewed Bulletin knowledge and read published notices | Public |
/admin/ | Capability-projected Operations console | Cloudflare Access plus a local grant |
/cal/programs.ics | Fetch the Programs calendar | Private calendar token |
Publication and knowledge flow
flowchart LR SOURCES["Happenings, WhatsApp, PDFs, and operators"] --> REVIEW["House Desk review queues"] REVIEW -->|"publish Programs"| EVENTS[("D1 program events")] REVIEW -->|"publish Bulletin"| KNOWLEDGE[("D1 reviewed knowledge")] EVENTS --> SCHEDULER["Programs scheduler"] SCHEDULER --> FEED["Private ICS feed"] KNOWLEDGE --> BULLETIN["Public Bulletin search and notices"]
Nothing publishes directly from an intake. Operators review content, resolve duplicates or source discrepancies, and make an explicit publication transition. The Bulletin is the current public name for tables and routes that may still retain house_updates in source for compatibility.
Runtime and storage
- Eleventy builds resident and Operations pages from
src/intodist/. - Cloudflare Pages Functions handle subscription, management, feed, intake, webhook, and admin requests.
- D1 (
SUBS_DB) stores subscribers and token hashes, Programs and Bulletin content, resident projections, operator grants and roles, templates, source receipts, and audit records. - R2 stores the generated
programs.ics, immutable event flyers, private resident archive material, and commissioned WhatsApp media in separately bounded bindings. - A standalone Worker rebuilds the Programs feed from published D1 rows every 15 minutes.
- Resend delivers product email; Turnstile protects high-abuse public actions.
Staff access has independent gates
Every admin request passes three checks:
- Cloudflare Access admits the identity and signs a product-specific assertion.
- House Desk verifies that JWT in application code and resolves the normalized email through immutable recovery configuration or an exact D1 grant.
- The method and path must map to one of the 41 canonical permissions in
functions/_lib/route-actions.ts.
Routine access is managed in /admin/access/. Administrators can create or edit reusable roles, assign an exact snapshot to a person, fine-tune a person into a Custom grant, and review append-only access history. Recovery administrators remain outside D1 and cannot be changed through the UI. Unknown routes, malformed grants, unavailable authorization storage, and unassigned identities fail closed.
Authentik will become the shared upstream staff identity provider through Cloudflare Access. House Desk’s local grants, role templates, application audience, and route checks remain authoritative. See Identity and access.
Operations console
| Area | What it controls |
|---|---|
| Today | Capability-aware service summary and recent activity |
| Messages | Private WhatsApp ledger, attachment review, and connected-group capture selection |
| Programs | Event intake, source batches, reconciliation, duplicates, history, flyers, note previews, and publication |
| Bulletin | Notice and knowledge review, official PDF sources, deterministic search, Ask preview, and publication |
| People | Subscribers, resident snapshots/history, import, token lifecycle, and email actions |
| Reliability | System state, observability, replay, funnel, cohort, and latency views |
| Tools | Email templates, Calendar Note Studio, bulk operations, and test delivery |
| Access | People, reusable roles, exact permission snapshots, view-as, contact configuration, and audit |
The interface hides controls outside the returned capability projection, but the server independently enforces every request. Operator view-as is read-only, audited, bounded to reviewed human identities, and never unions the actor’s permissions with the target’s.
Detailed documentation
| Page | What it covers |
|---|---|
| Resident guide | Subscribing, managing a subscription, and fixing refresh problems |
| Architecture | Layers, request routing, credential boundaries, and fail-closed behavior |
| Origin boundary | Why human pages and stable private feeds use different hostnames |
| Happenings intake | How a forwarded newsletter becomes reviewable content |
| Event review | Source triage, duplicates, flyers, publication, and Pub sharing |
| Bulletin | Reviewed notices and public knowledge behavior |
| Programs ICS generation | Deterministic rendering from D1 into R2 |
| Scheduler Worker | Lease protocol and bounded rebuild capability |
| Subscription lifecycle | Verification, handoff, renewal, win-back, and revocation |
| Integrations | Email, anti-abuse, intakes, projections, and retired dependencies |
| API reference | Public, resident, machine, and permission-protected routes |
| Data model | D1 migrations, role and audit storage, knowledge stores, and R2 objects |
| Operations reference | Current console destinations and their capability boundaries |
| Operations guide | Local checks, migration isolation, deployment, and troubleshooting |