Cloudflare Access Claim Boundary Review

Purpose

This review defines how Renata should treat Cloudflare Access before accounts, identity storage, role assignment, or live pull-up/push-up drafting exists.

Cloudflare Access may remain the outer route gate. The app must not return, display, persist, derive live roles from, or join community content to Access identity claims in this phase.

Current State

Product

Renata

The Sixth Sense at 6th Street

Account architecture

cloudflare-access-claims-only

outer-boundary-only

Claims exposed

false

not implemented

Claims stored

false

not implemented

Cloudflare Access may remain the outer protected-route gate, but the app must not return, display, persist, or derive live roles from Access identity claims in this phase.

Cloudflare Access Boundary

Outer access boundary

Cloudflare Access can protect the route family before the app implements accounts.

Allowed: route-level protection and conceptual boundary planning only

Not allowed: app-level login, role assignment, identity display, or storage

Risk: lowest

allowed-for-boundary-review

Identity values

Email, name, subject, user id, groups, token, and JWT values are identity-bearing and remain off-limits to app output and storage.

Allowed: none in app pages or endpoints during this phase

Not allowed: returning, logging, displaying, storing, mapping to roles, or joining to community content

Risk: high

do-not-expose-or-store

Access result booleans

If an Access diagnostic exists, it must expose only safe boolean status and never identity details.

Allowed: boolean-only route protection checks

Not allowed: email/name/group/token/JWT echo, user profile response, or role assignment response

Risk: low

safe-diagnostic-shape

Future pseudonymous actor ref

A later phase may design actor refs that do not contain or reveal real identity values.

Allowed: conceptual planning after privacy approval

Not allowed: live mapping, storage, user assignment, or submission ownership

Risk: medium

planning-only

Claims Never Exposed Or Stored

These values may exist at the Cloudflare Access boundary, but this app must not display, return, persist, log, or map them to roles in this phase.

emailnamegiven_namefamily_nameuser idsubjectgroupsidentity provider idCloudflare Access JWTCloudflare Access tokenidentity headerssession detailsIP addressdevice posture detailsresident profile datastaff profile data

Safe Diagnostic Shape

return booleans only
do not return email
do not return name
do not return group names
do not return JWT
do not return token
do not return Cloudflare identity headers
do not store claims
do not log identity values
do not assign roles from claims
do not create app accounts

Safe diagnostics may say whether protection appears present. They must not become identity inspection endpoints.

Future Pseudonymous Actor Direction

Principle	Rule
Opaque actor ref	Future actor refs should be opaque values that do not encode email, name, initials, group, role, or resident/staff status.
Separate policy before storage	No actor map can be stored until identity, privacy, retention, audit, deletion, and staff approval policies exist.
No live permissions	Actor refs must not grant role assignment, draft submission, staff review, or Morning Sheet placement until later gates approve live behavior.
No content linkage	This phase does not link actors to pull-ups, push-ups, staff decisions, resident history, attendance, participation, analytics, or scores.

Review Gates

Gate	Status	Requirement
Claim inventory	conceptual-only	Document claim categories without reading, returning, or storing live identity values.
Response boundary	required-before-any-endpoint	Any future endpoint must return booleans only unless separately approved.
Logging boundary	required-before-any-debugging	Identity-bearing headers, JWTs, tokens, emails, and names must not be logged.
Actor ref policy	future-planning	Design pseudonymous actor refs without real identity and without storage in this phase.
Role policy	blocked-before-live	Claims cannot become app role assignment without a later approved role-mapping phase.
Submission policy	blocked-before-live	Claims cannot enable pull-up/push-up collection or ownership until draft storage gates are resolved.

Blocked Capabilities

app-level login
account creation
password fields
email capture
identity claim exposure
identity claim storage
real user names
resident profiles
staff profiles
user admin CRUD
role assignment
live pull-up forms
live push-up forms
submission collection
staff approval/rejection
Morning Sheet live placement
database writes
write endpoints
active migrations
D1 account/user/submission tables
attendance tracking
participation tracking
participation analytics
scoring, ranking, discipline points, or compliance metrics
billing, lead capture, CRM, Stripe, or sales forms
AI for real submissions
sensitive community content storage

What Remains Blocked

No app-level login, account creation, identity capture, identity storage, user CRUD, role assignment, live submissions, staff decisions, write endpoints, D1 account/user/submission tables, active migrations, attendance tracking, participation tracking, participation analytics, or scoring exists.

No Cloudflare Access email, name, token, JWT, group, identity header, or identity detail is returned or stored by this page.

Recommended Next Phase

Phase 8.2 - Pseudonymous Actor Model Planning

After the Access claim boundary is documented, the next safe planning step is an actor-ref model that does not expose, store, or encode real identity.

Boundaries: no account creation; no app-level login; no identity claim exposure; no identity storage; no user admin CRUD; no role assignment; no submissions; no staff decisions; no database writes.

recommended-next