Ministry Studies Tool — Acceptance Spec

STATUS: DRAFT. This spec exists because the proposal to Almost Home Ministries (2026-09-28, no charge, first Founding Ministries slot) promised a specific product — see the verbatim quotes below — and per Rule #17 (no features without expected-output specs), no code should be built until this spec exists and is founder-confirmed. Per the AI Bridge Principle, this tool's defining constraint is the opposite of Living Word's: Living Word is AI-graded gameplay; this tool must be AI-drafted, human-approved content, delivered to a human who reads it — the AI never reads, grades, or comments on what a participant writes.

§0 — What was promised (verbatim, from the signed proposal)

"You send me two or three of the studies you already use. I write the rest of the set in the same voice and format, and you approve every question before a woman sees it. Or you type your own in. Either works." "Each woman gets a simple sign-in on a phone or tablet. She works through the study at her own pace. Her answers are saved." "Her leader sees her answers, and only her leader. No score, no grade, no percentage. A reflection on Psalm 51 isn't a test, and no computer is going to mark it." "Every study also prints. For the ministries you know that work inside prisons, where there is no internet, the paper version is the real product."

It "comes with the website" (the cwa_website plan). Target users beyond Almost Home: prison ministries (paper-first, no internet, no personal devices, a chaplain may transcribe spoken answers), jail chaplains, addiction recovery groups, Celebrate Recovery-style groups, women's shelters, youth groups, small-group Bible studies, new-believer discipleship.

§1 — Purpose

A church or ministry runs a real Bible study with real people who are often unreached by the rest of ChurchWiseAI's product line — a woman in a recovery home, a man in a county jail, a teenager in a youth group with no email address of her own. The tool's job is narrow: hold a study (passage, reflection, questions), let a participant answer at her own pace without being watched by peers or scored by a machine, let her leader read what she wrote and follow up as a human, and print the whole thing when there is no device at all. It is not a quiz engine, not a content-marketing tool, and not a pastoral-care AI — see AI Bridge Principle: the tool connects a woman to her leader, it never becomes the counsellor.

§2 — Personas

Persona	Who	Device / access	What they need
Dana	Resident/participant, recovery home	Shared house tablet, no email, may not read fluently under stress	Find her name, enter her study, answer at her pace, leave and come back, never see a score
Stephanie	Leader (house manager, group facilitator, small-group leader)	Her own phone, logged into the church's dashboard	See who's where, read answers, send a private note, mark "walked through together," print for someone without a device
Ministry admin	Program director / church staff who set up the study library	Desktop, dashboard admin	Paste in their own studies, kick off AI drafting from samples, approve every question, manage groups and leader assignments
Prison chaplain	Volunteer or staff chaplain, jail/prison ministry	Paper only — no internet or personal devices permitted for residents	Print blank studies and a chaplain packet of N copies; optionally transcribe a resident's spoken answers into the system afterward, from their own device
Founder	John	Any	Show the shape of the product on a call; confirm it matches what was promised

§3 — Entities and data model (proposed)

Multi-tenant on premium_churches.id, following the existing convention (church_voice_agents, church_team_members, etc. — see knowledge/architecture/database-schema.md). Verify every column against information_schema.columns before any migration — do not assume a table below is final; this is a proposal for the founder + a build agent to confirm, per Rule #18.

study_sets

A "book" — a themed collection of studies (e.g. "Beauty for Ashes: An 8-Week Study for Women in Recovery").

Column	Type	Notes
id	uuid PK
premium_church_id	uuid FK → premium_churches.id	tenancy
title	text
description	text
target_audience	text	free text, e.g. "Women in recovery", "Youth group"
source	enum: admin_authored, ai_generated, imported	how the set originated
status	enum: draft, active, archived
created_by	uuid FK → church_team_members.id
created_at, updated_at	timestamptz

studies

One lesson within a set.

Column	Type	Notes
id	uuid PK
study_set_id	uuid FK
sequence_number	int	order within the set
title	text
passage_ref	text	e.g. "Isaiah 61:1-4"
passage_translation	text	e.g. "ESV" — must be recorded, never assumed
passage_text	text	full passage, stored so the study renders offline/print without a live Bible API call
reflection_text	text	the ~150-word framing
prayer_text	text	closing prayer
leader_note	text	what to listen for; when to involve a counsellor/pastor (Bridge Principle)
review_status	enum: draft, pending_approval, approved, archived	every AI- or admin-drafted study starts draft; nothing reaches a participant below approved
approved_by	uuid FK → church_team_members.id, nullable
approved_at	timestamptz, nullable
created_at, updated_at	timestamptz

questions

Column	Type	Notes
id	uuid PK
study_id	uuid FK
sequence_number	int
prompt_text	text
question_kind	enum: observation, meaning, application, commitment	mirrors the observation → meaning → "where are you in this" → one small step arc
review_status	enum: draft, approved	question-level gate — an admin can approve 6 of 8 questions in a study and hold 2 back

ministry_groups

A cohort (a house, a cabin, a Tuesday-night group) — the unit leaders are assigned to.

Column	Type	Notes
id	uuid PK
premium_church_id	uuid FK
name	text	e.g. "Almost Home — Main House"
created_at	timestamptz

participants

No email, ever. Identity is a display name plus a PIN or leader-issued code.

Column	Type	Notes
id	uuid PK
premium_church_id	uuid FK
ministry_group_id	uuid FK, nullable
display_name	text	first name, or first name + last initial if a group has duplicates
access_code_hash	text	hashed 4-6 digit PIN or leader-issued code — never stored plaintext, never an email/password pair
created_by	uuid FK → church_team_members.id	the leader/admin who enrolled her
archived_at	timestamptz, nullable	soft-delete on program exit; see §7 retention
created_at	timestamptz

leader_assignments

Column	Type	Notes
id	uuid PK
ministry_group_id	uuid FK, nullable	assign a leader to a whole group
participant_id	uuid FK, nullable	OR assign a leader to one participant directly (one of the two is set)
leader_church_team_member_id	uuid FK → church_team_members.id
assigned_at	timestamptz

responses

Column	Type	Notes
id	uuid PK
participant_id	uuid FK
study_id	uuid FK
question_id	uuid FK
answer_text	text
status	enum: draft, submitted	autosave writes draft; participant does not "submit" a whole study, each answer stands alone the moment she moves on — no false sense of a graded submission
walked_through_together	boolean, default false	leader marks this per study, not per question
leader_note_back	text, nullable	private note, leader-only, never shown to the participant unless the leader explicitly shares it (v1: never shown — see §8 out of scope)
leader_note_by, leader_note_at
created_at, updated_at	timestamptz
entered_by	uuid FK → church_team_members.id, nullable	set when a leader/chaplain transcribes a spoken or paper answer on the participant's behalf (prison/no-device flow); null means the participant typed it herself

RBAC

New role capability ministry_studies:* on the existing church_team_members role system (see churchwiseai-web/CLAUDE.md Data Access Rules table). A leader sees only participants via leader_assignments; there is no "see all participants" view below admin/office_admin. Reflection answers are treated as pastoral-tier data — same visibility class as confidential prayer text, never as loose as "any staff member."

§4 — Privacy (non-negotiable, confirm at the Wednesday call)

• Participant identity requires no email address. A first name + PIN, or a leader-issued code, is sufficient — this is the whole point for a resident who has neither an email account nor privacy to receive one.
• A response is visible only to: (a) the participant herself, and (b) leader(s) assigned to her via leader_assignments. Never to other participants. Never to leaders outside her assignment. Never surfaced in any cross-tenant or cross-ministry view.
• Responses are never sent to any LLM, embedding pipeline, or unified_rag_content ingestion, and never used for AI training — not by ChurchWiseAI, not by any model provider. This is a hard architectural rule, not a policy statement: no code path may pass responses.answer_text to an AI call of any kind. (Contrast with study_sets/studies/questions content, which is legitimately AI-assisted at authoring time, before any participant ever sees it.)
• A participant or her leader/ministry admin can request export (PDF of her own answers) or deletion. Deletion is a hard delete of her responses rows and archives her participants row; it does not cascade-delete other participants' data.
• Shared-device reality: the sign-in screen must not leave a previous participant's session open. Auto-sign-out on inactivity (proposed: 3 minutes) and an explicit "I'm done" button that returns to the sign-in list.

§5 — Participant flow (screen by screen)

Phone-first, large type (18px+ body), no timers, no scores, no streaks, no gamification, no leaderboard of any kind — this is not Living Word. Every screen must render on a 5-year-old Android in Chrome (see §10 accessibility).

Screen 1 — Sign in. A grid of first names for her group/house (or a single "Enter your code" field if the church prefers PIN-only, per group setting — see open question §9.3). Given X: the tablet shows the house roster. Given Y: Dana taps her name and enters her 4-digit PIN. Success → Screen 2. No password-reset flow, no "forgot email" — a wrong PIN just says "try again"; a leader resets a forgotten PIN from the roster screen.

Screen 2 — Your studies. A list of study sets assigned to her group, each showing a plain state: Not started / In progress / Completed — never a percentage, never "3/8 done" framed as a score. Tapping an in-progress study resumes at the exact question she left.

Screen 3 — Study intro. Title, full passage text (so it works without any external Bible API call), the ~150-word reflection. One "Begin" button (or "Continue" if resuming).

Screen 4 — One question at a time. Large question text, a large text area, "Next" / "Back." Autosave fires on blur and on Next (writes a responses row with status: draft) — losing the tablet mid-sentence must not lose her answer. Progress shown as a plain position indicator ("Question 4 of 7") — a navigational aid, not a score, and never phrased as a fraction of "correct."

Screen 5 — Done. "Thank you — [Leader name] will see what you wrote." No grade, no summary of her own answers shown back to her (keeps the screen simple and avoids re-reading pressure — confirm this default at the Wednesday call), one "Back to your studies" button. The crisis-resource line (see §7) is present here too, not just mid-study.

Every study screen carries the church's own crisis instruction + 988, persistently visible (see §7), and a visible "I'm done for now" control that returns to Screen 1 (privacy on shared devices).

§6 — Leader flow

1. Roster — list of assigned participants (via leader_assignments), each showing group, and per-active-study status (Not started / In progress / Completed) — no scores.
2. Participant detail — every response she's given, grouped by study, in question order, with the study's own text alongside so the leader isn't reading answers with no context. A "walked through together" toggle per study (useful even when the leader met her in person and never opened a device).
3. Leader note back — a private note field per study, leader-only (v1; never shown to the participant — see §8).
4. Print blank study — one PDF, the study with answer lines, for a participant with no device.
5. Print a participant's answers — one PDF of what she wrote, for the leader's own reference/casework, watermarked with her name and a "confidential — pastoral use" footer.
6. Enter an answer on her behalf — for the prison/no-device flow: the leader/chaplain types what a resident said or wrote on paper into the same responses table, with entered_by set. The UI must make this transcription mode visually distinct from a self-entered answer (so nobody later mistakes a chaplain's paraphrase for the resident's own words).

§7 — Safety (AI Bridge Principle applied)

A response that reads like a self-harm or abuse disclosure is NOT auto-detected or auto-escalated by AI. This is a deliberate choice, not a gap:

• Running any automated scanner over responses.answer_text would itself be an AI use of participant data — directly in tension with the privacy commitment in §4 ("never used for AI training," never sent to a model). A scanner that reads every answer to look for danger signals is, functionally, an AI reading every answer.
• A missed detection (false negative) in a life-safety context is worse than no detection at all, because it creates false confidence that "the system is watching" when it is not. The Bridge Principle's answer to "who watches for danger" is always a human, never a heuristic.
• Instead: every study screen shows the ministry's own crisis instruction (customizable per church, defaulting to 988 + the ministry's own on-site contact) persistently, exactly as the chatbot and voice agent do today (AI_BRIDGE_FRAME / === AI BRIDGE PRINCIPLE ===). And the leader dashboard surfaces new responses promptly — a "new since your last visit" indicator, plus an optional notification (email/SMS, reusing the existing founder_action_items/sendAlertSMS pattern scoped to the leader) when a participant submits an answer in a study flagged by the admin as touching a sensitive theme (confession, grief, trauma). No SLA is promised or implied by the AI; the promise is that a human reads it, not that a machine caught it first.

§8 — Admin flow

1. Study set library — create a set, choose admin_authored (paste/type), imported (upload a doc — v1: paste plain text; parsing a formatted Word/PDF is a fast-follow, see open question §9.1), or ai_generated.
2. "Write the rest in this voice" — the admin pastes 2-3 of their own studies as samples. Generation runs via claude -p (CLAUDE.md Rule #5 — CLI, never a direct Anthropic/OpenAI API call; environment must strip CLAUDE_CODE_ENTRYPOINT/CLAUDECODE/ANTHROPIC_API_KEY per the house rule) with the samples as style/format reference. Every generated study and every generated question lands with review_status: draft. Nothing generated is ever auto-published.
3. Approval queue — the admin reviews study-by-study, question-by-question: edit inline, approve, reject, or send back. A study cannot move to approved while any of its questions are still draft. This is the gate the proposal promised ("you approve every question before a woman sees it") — it is enforced in the data model (review_status), not just as a UI convention.
4. Groups and leaders — create ministry_groups, assign leaders, enroll participants (generates the display-name + PIN pair; the admin can print the PIN card for a resident who can't be handed a password on a screen).
5. Print defaults — Letter vs A4, large-print toggle, the church's crisis-instruction text.

§9 — Print mode (the prison-ministry product)

Per the proposal, this is not a nice-to-have export — for a ministry with no internet access for residents, the printed study is the entire product.

• Blank study, single copy — Letter or A4 (church setting), passage in full, reflection, each question with generous answer lines, closing prayer, a name/date line at the top, ministry name slot in the header. Spec default (confirmed against print-sample.html, 2026-09-28): 5 ruled lines per open question, 9mm spacing (~0.35in); large-print mode widens this to 11mm per line. A question and its ruled lines must never split across a page break (page-break-inside: avoid on the question block) — a woman should never have to hunt across two pages to finish writing one answer. Large-print option roughly doubles body font size and line height, reflowing to more pages. A single 8-9 question study at these defaults runs ~5-6 printed pages (Letter) — confirmed against the rendered sample.
• Chaplain packet — the same blank study repeated N times (admin enters a count) into one PDF, so a chaplain can print and hand out a whole group's worth without repeating the export.
• Leader "answers" print — a participant's own responses laid out study-by-study, question-with-answer, for the leader's casework or for handing back to a chaplain who transcribed the paper originals.
• No internet is required to READ the print output, obviously, but generating it today requires the ministry (or ChurchWiseAI on their behalf) to have used the dashboard at least once. Open question for Wednesday: does Almost Home or a prison-ministry partner need ChurchWiseAI to generate and physically mail/print packets on their behalf, since the print step itself may need a device the ministry doesn't have on-site? (§10.8)

§10 — Accessibility

• WCAG AA contrast and tap-target sizing throughout the participant flow (the flow most likely used by someone in crisis, in recovery, or reading under stress).
• Dyslexia-friendly option (larger line-height + letter-spacing toggle at minimum; a genuine dyslexia-friendly typeface is a nice-to-have, not required for v1 — confirm cost/benefit before adding a font dependency).
• Must render correctly on a 5-year-old Android device in Chrome — no heavy client bundle, no video, minimal JS on the participant path; test against Chrome's low-end device emulation, not just desktop DevTools mobile viewport.
• Large-type mode is a genuine accessibility feature, not merely a print option — should also be selectable on the participant's live screen, not just in print.

§11 — Tier gating

Included in cwa_website and cwa_complete (both include Pro Website — the proposal explicitly says the tool "comes with the website"). Not included in cwa_phone-only (Phone does not include a Pro Website). Gate on the existing entitlement pattern used by tier-config.ts (Rule #23 — gate on the normalized entitlement/channel, never persist a normalized value back to premium_churches.plan). Grandfathered legacy customers: any legacy plan that includes Pro Website (cwa_pro_website) gets it; a legacy voice-only or chat-only-without-website plan does not.

Almost Home receives it free, per the Founding Ministries program (project_founding_ministries_program memory) — provisioned the same way any Founding Ministries slot is provisioned, not as a special-cased code path.

§12 — Out of scope for v1

• Peer visibility of any kind (no shared answers, no group chat, no "see what others wrote").
• Sharing a leader's private note back to the participant (may become an opt-in fast-follow; v1 keeps it leader-only to avoid an accidental disclosure while the feature is new).
• AI reading, summarizing, scoring, or commenting on participant answers, in any form, at any time — not a v1 limitation, a permanent architectural rule (§4, §7).
• Automated crisis-signal detection over responses (§7) — permanent, not deferred.
• Age-banded variants of a study (one plan per study for v1, matching the Living Word LP4 precedent — a study written for adult women in recovery is not auto-adapted for youth).
• Parsing uploaded Word/PDF studies (v1 accepts pasted plain text only; a chaplain or admin retypes/pastes).
• Multilingual studies (per project_multilingual_content_needs_fluent_reviewer memory — translation needs a fluent reviewer per language; defer until a specific ministry asks).
• SMS/email reminders to participants (most have no email; a leader-facing "nudge" notification could be a fast-follow, not v1).
• Voice-agent delivery of a study over the phone.
• API/webhook export of study data to a ministry's own systems.
• Consent/e-signature workflow for enrolling a participant — v1 relies on the leader's existing enrollment relationship with the resident, same trust boundary as any other in-person ministry intake.

§13 — Expected outputs (representative touchpoints)

Given	Screen shows
Dana taps her name and enters the wrong PIN	"That code didn't match. Try again." — no lockout messaging that implies a security breach, no "contact support" (she has no email to be contacted at)
Dana is mid-question and the tablet is closed/loses power	Reopening and signing back in resumes at the exact question, prior answer preserved (autosave on blur/Next)
Stephanie opens a participant with zero responses yet	"No answers yet" — not a blank page that looks broken, not a 0%
Stephanie opens a participant who has submitted answers to a sensitive-themed study	A "new" badge on the study, per §7's leader notification behavior
Admin generates a set from 2 pasted samples	Every resulting study lands in the approval queue with review_status: draft; nothing is visible to any participant until approved study-by-study
Admin tries to approve a study with 2 of 8 questions still in draft	Approve is disabled/blocked with an explicit reason ("2 questions still need review")
Chaplain requests a packet of 15 copies	One PDF, the blank study repeated 15 times, each with its own name/date line
A church on cwa_phone (no website) opens the dashboard	No "Ministry Studies" tab appears at all — same pattern as any other Pro-Website-gated feature

§14 — QA checklist (run before declaring any phase done)

• Participant flow click-through on the deployed URL, emulated low-end Android + reduced motion (house QA convention: behavior, not DOM presence).
• Leader-visibility boundary test: Leader A, assigned only to Group 1, cannot read a Group 2 participant's responses via any route (API-level test, not just UI-hidden).
• RBAC test: a non-leader church_team_member role cannot reach the roster/read endpoints.
• Grep-level assertion: no code path passes responses.answer_text to any AI/LLM call, embedding call, or unified_rag_content ingestion.
• Tier-gating test: a cwa_phone-only account cannot reach the module (dashboard tab absent AND API 403s).
• Print PDF renders correctly at Letter and A4, large-print toggle reflows without clipping, chaplain packet page count matches the requested copy count.
• Autosave verified with an actual network interruption / tab-close mid-answer, not just a happy-path save.
• product_knowledge updated (Rule #8) once the feature ships, and validated (Rule #19).
• FEATURE_REGISTRY row added in the same PR (Rule #14) — proposed row in the accompanying report, not added by this draft.

§15 — Open questions for the Wednesday 2026-09-30 call with Almost Home

1. What format are their existing studies in today (typed document, printed handout, handwritten outline)? Determines whether "paste your studies in" is realistic as typed text or needs a scan/retype step.
2. Group study (everyone answers together, discussed live in the room) vs. individual take-home reflection — or does Almost Home want both, on different studies?
3. How are leaders assigned — one house leader per resident, or one leader per whole house/cohort? Affects whether leader_assignments needs to support many-to-many from day one.
4. Do residents share one device (a house tablet) or does each have her own phone/tablet? Determines how hard the auto-sign-out / shared-device privacy requirement (§5) actually bites.
5. Does Almost Home want printing prioritized first, given many recovery-home programs deliberately restrict resident phone/internet access as part of the program structure — closer to the prison case than assumed?
6. What sign-in convention works for their house — first name alone, or first name + last initial (residents with the same first name)?
7. Any topics Almost Home considers off-limits, or that should carry extra leader-notification weight beyond the standard crisis-resource line (e.g., anything trauma- or addiction-specific to their program)?
8. Who prints — does the house have its own printer/access, or does ChurchWiseAI need to generate and ship printed packets on their behalf for the paper-first cases (§9)?
9. What's their resident turnover/graduation cadence — should participant records auto-archive on a schedule, or does a leader manually mark "graduated" and trigger retention per §4?

§16 — v1 as built (2026-09-29, churchwiseai-web PR #1774)

Built on the lead's 30-day cut. Migration migrations/2026-09-29-ministry-studies.sql was APPLIED in prod on 2026-09-29. Team-member foreign keys target public.tenant_team_members(id) — church_team_members is a VIEW over it and cannot be an FK target (the first apply attempt failed with 42809 and rolled back); code keeps reading through the view. Validated on Postgres 17 (PGlite, mirroring the table + view): 33 checks incl. the gate, tenant FKs, idempotent upsert, RLS/grants, rollback. The dashboard tab hides itself if the tables are ever missing (the access check probes and fails closed). Full admin → participant → leader → print loop verified by Playwright on the preview (churchwiseai-web #1774), with every QA row removed afterwards.

What v1 contains

Area	v1 behaviour	Code
Data	10 tables, all ministry_study_* / ministry_studies; RLS on, no policies, no anon/authenticated grants; composite FKs force every child row onto its parent's tenant	migration above
Approval gate (§8.3)	Enforced by DB triggers: a study cannot be approved with 0 questions or any draft question; a draft question can never be added to / reopened in an approved study. UI disables Approve with the reason ("2 questions still need review."). Editing an approved study requires "Move back to draft" (participants stop seeing it until re-approved); editing a question's words sends it back to draft	src/lib/studies/gate.ts, admin.server.ts
Admin (§8)	Dashboard Studies tab (church rail destination "Studies"): study sets; paste-a-study (deterministic splitter, not AI — §8.1 v1) or type it in; question-level approve/edit/reorder/delete; approve study; archive; groups with join codes; enroll participant (display name + leader-issued 4-digit PIN shown once); reset PIN; archive; delete her answers (§4); remove a mistaken enrollment; delete an EMPTY group or set (otherwise archive); leader + study-set assignments; crisis line	src/app/(cwa)/admin/[token]/components/studies/
Participant (§5)	/s/[slug]/studies on the tenant host: group code → name grid → PIN → her approved, assigned studies (Not started / In progress / Completed) → passage + reflection → one question per screen, autosave (blur, typing pause, Next; idempotent upsert), resume at the exact question → Done ("{leader} will see what you wrote") + closing prayer. Crisis line + 988 + 911 on every screen (default when the church has written nothing: "Need to talk to someone? Call {ministry phone}. Call 988 or 911 in an emergency." — only the PHONE is taken from a ministry's public crisis bar; its visitor-facing sentence is never shown to a resident); "I'm done for now"; 3-minute idle sign-out; larger-text toggle; no scores/timers/progress bars	src/app/s/[slug]/studies/
Leader (§6)	Roster (plain states, "New" since last visit, walked-through tick); participant detail with the study text + leader's note alongside each answer set; "No answers yet"; walked-through-together toggle; private note (never shown to her); transcription mode, visibly labelled "Transcribed by … — not her own typing" everywhere incl. print	leader.server.ts, ParticipantDetail.tsx
Print (§9)	Blank study (Letter, 5 ruled lines at 9mm / 11mm large print, question blocks never split, name/date line, church name) with ?copies=N (1-50) chaplain packet; a participant's answers ("Confidential — pastoral use"). Browser Print → Save as PDF	src/components/studies/StudyPrintDocument.tsx, /admin/[token]/studies/print/*
Tier (§11)	studiesEntitled() = planIncludesProWebsite(row) (Website / Complete (+annual) / legacy cwa_pro_website; Founding Ministries rows via has_website_subscription), minus service_business prospect rows, real-estate tenants and non-live rows. Phone-only: no tab, API 403, participant route 404. Read-only use of the plan; never persisted (Rule #23)	src/lib/studies/entitlement.ts
AI Bridge (§4/§7/§12)	No code path sends an answer to any AI/LLM/embedding/unified_rag_content; enforced by no-ai-over-answers.test.ts (allowlisted answer-touching files, none may import anything AI-shaped)	src/lib/studies/__tests__/

Deviations from §3 (all intentional; confirm with the founder)

1. Table names prefixed. questions and study_groups already exist in public (legacy B2C); participants/responses are too generic for a shared DB.
2. Per-study state in ministry_study_progress (resume point, completed, walked-through, leader note, leader-viewed) instead of on every responses row — §3 itself says these are per study.
3. ministry_study_assignments (new): which study SET a group or one participant sees.
4. Group join code gates the name grid. Without it, anyone could open {slug}.john316.church/studies and read a recovery home's first names. The leader enters the code once on the house tablet (or shares …/studies?code=XXXX, prefill only). The device cookie carries a tag of the code (never the code itself): issuing a new code, or archiving the group, revokes every device unlocked with the old one on its next request; anyone already signed in lapses within the 10-minute sliding session.
5. Roles without a new RBAC capability. Studies admin = inbox:prayer:read:confidential holders (admin, office_admin, pastor — "pastoral tier", §3 RBAC). Leader = any team member with leader assignments; she reaches only those participants (anyone else → 404). A dedicated ministry_studies:* capability is a fast-follow if churches want finer control.
6. PIN lockout (escalating): 5 wrong in a row → 10-minute cool-down ("Let's pause for a few minutes. Your leader can reset your code."); every further wrong try re-locks for double the time (10 → 20 → 40 … minutes, capped at 24 hours). The counter resets only on a correct PIN or a leader's PIN reset. Plus per-IP limits on code and PIN entry.

Deferred (not in v1)

• claude -p "write the rest in this voice" generation (§8.2) — the source column and draft-by-default gate are ready for it.
• Chaplain packets with per-copy numbering beyond "N copies", A4 toggle in the UI (CSS supports Letter only in v1).
• Dyslexia-friendly typeface (v1 has the larger-text toggle only).
• Multi-leader views beyond assignment (e.g. a leader dashboard across several churches).
• Sensitive-theme flag + leader email/SMS notification (§7) — v1 has the in-dashboard "New" badge only.
• Participant self-service export (§4) — v1: the leader prints her answers; deletion is admin-driven.
• product_knowledge rows (Rule #8) — add when the feature is announced to customers.

Open questions added by the build (for the 2026-09-30 call)

10. Is a group join code on the house tablet acceptable, or does Almost Home want PIN-only sign-in with no visible name list?
11. 3-minute idle sign-out — right for their house, or too short for a slow reader?
12. May a resident re-open a completed study and change an answer? (v1: yes — she lands on her last question.)
13. Should printing her answers clear the leader's "New" badge? (v1: no — only opening her answers on screen does.)