Checkpoint 1 · PLAN-174 / ADR-086

Bodhisattva Vows — the first content-study profile

A new study profile that treats a Dharma text like a language corpus — same FSRS engine, same carousel, same review pipeline, applied to a non-language content list for the first time. It doubles as a rehearsal for a future "upload a document, get a study profile" wizard.

105 cards live eng / eng profile Dealing on preview now Full review ritual run 7 ratification items
Checkpoints Latest →
What this is

A study profile for the vows, not a spreadsheet of them

The booklet's structure, ported into cards.

The FPMT booklet "The Bodhisattva Vow" lists things in numbered groups — advantages of bodhichitta, the eighteen root vows, forty-six branch vows split into seven perfection groups, and so on. Each group became a section container (never itself a card); each numbered item inside it became one graded card. Two long recitation prayers stayed as whole-text "read it as a passage" cards rather than being chopped up.

105 cards total: 13 section containers + 90 graded items (10 advantages, 4 guarding practices, 4 negative dharmas, 4 positive dharmas, 18 root vows, 4 conditions of transgression, 46 branch vows) + 2 recitation-passage cards.

Every root and branch card's back carries commentary mined from Geshe Sonam Rinchen's "The Bodhisattva Vow" (same Gelug lineage, verse-by-verse on the same root text): the canonical list title, a short original-prose gloss, "no fault if…" exceptions where the book states them, and a page citation. The Nyingma/Akashagarbha eighteen-vow list is a genuinely different enumeration and was deliberately kept separate — not merged in.

Pace

How the cards arrive

Same drip mechanism every profile uses — no special-casing.

Release cadence
Day 1
18 cards released (pool-floor rule tops up a new profile faster than the daily rate)
Day 2+
10 new cards/day — the profile's normal pace knob, same one every profile has
~Day 9
All 90 graded items released; the 2 prayer cards were live from day one
Example cards

Three cards, as Frank will actually see them

Copyright note: FPMT's booklet text is copyrighted. Cards keep at most ~25 words of verbatim booklet text per card, clearly marked as an excerpt — everything else (glosses, gists, hooks) is freshly written prose. No full vow text, no full prayers, and no Sonam Rinchen excerpt beyond one short attributed line, appear anywhere below or on any card.

1 · Root 7 — Harming the ordained

Front: "Root 7 · Harming the ordained"

Gist: Harming an ordained person — violence, robbing robes, causing loss of vows.

Memory hook: "Striking at the robe strikes the whole lineage."

Commentary: Sonam Rinchen, pp. 127–129, plus the exception the book gives: "No fault if expulsion is done out of compassion…"

Excerpt shown (≤25 words, marked): "Harming an ordained person, inflicting violence on them, stealing their robes…" (trimmed).

2 · Branch 19 — Refusing apologies

Note field: "Differs from root 3: no four conditions required."

Memory hook: "The lighter twin of root 3 — but this one breaks on contact."

3 · Condition 2 — Intending to repeat

Memory hook: "Condition two: the return ticket kept in your pocket."

Rigor

What the review process caught

The full ritual ran, and it earned its keep.

Brainstorm → ADR-086 → PLAN-174 → peer review (ENR + QA) + a new persona (DEVOTEE, "Tenzin D.," built specifically for this learner axis) → execute → code review → testing. The reviews falsified the plan's original "zero web-code changes" claim twice: QA found the grade pipeline hardcoded Indonesian, so grading any English card would 404 — fixed by plumbing the profile's own language through review/close/my-words. The persona review found the verbatim booklet text had no rendering path at all, and that the normal vocab-card layout would stack empty blocks (pronunciation, synonyms…) around sacred text — fixed with a dedicated FULL TEXT / MEMORY AID reveal block and an archetype-scoped filter that suppresses the vocab-only blocks. Drip-release math, an invalid UUID namespace, and a re-run "zombie intake" hole were also caught and fixed before anything ran against real data.

Same-day code review (8 finder+verify agents) went further: it found 6 more Indonesian hardcodes outside the grade path — the Learn deep-dive route, My Cards, the manual-add search, and the session-sweep job all assumed Indonesian and would have broken this profile the moment it left the carousel screen. All six were fixed and re-plumbed to the profile's own language. Two smaller items were judged lower-priority and deferred — they're flagged in BRIEF-2026-07-05-001 rather than silently dropped.

Known issue

One cosmetic bug, already scoped

The card front shows a dotted respelling/pronunciation line that duplicates the cue text. This is a pre-existing fallback in the shared card-prompt component when no phonetic respelling is supplied — not something this build introduced, and not unique to the vows profile. The real fix belongs to ADR-084's planned per-archetype "which prompt elements show" work, not a one-off patch here. Cosmetic only; doesn't block studying.

Decisions ledger

Ratification items — R1 through R7

Everything below already shipped, under your 2026-07-05 dispatch to execute end-to-end while you were out. This is the after-the-fact ratify/amend pass, not a pre-approval gate.

1
R1 — Partition: new t070_card_eng, eng/eng profile
A brand-new database partition for English-as-content, mirroring how Indonesian already gets its own partition. This becomes the template for every future content-study profile — a profile where the language you're learning IN and the language of the content are the same (eng/eng here). No new schema mechanism needed for that pattern going forward.
Decided by Frank
2
R2 — New "concept" card type; enumerated items vs. whole-text passages
A new card archetype was added to the registry: a section container (never graded, never shown as a card) plus a numbered item (the actual graded card). The call on the two prayers was to keep them as whole-text "passage" cards rather than break them into pieces, since they're recited, not enumerated. Typed recall of specific phrases (recitation-cloze) is documented as a deliberate future stage-two, not built now — recognition first, as you asked.
Decided by Frank
3
R3 — Custom content lives on the main card table, not a side table
Confirmed: custom/user-authored content gets a field on the same table every card lives in, not a separate table. The old side-table (t075, 0 rows, never used) is now formally legacy and flagged for a cleanup deletion — that deletion still needs your explicit four-questions sign-off before anyone touches it; nothing has been dropped yet.
Decided by Frank
4
R4 — LAUNCH GATE: custom content is world-readable until launch-gate work lands
Important to flag even though it's low-risk today: the database change that makes custom-authored rows private to their owner is deliberately deferred to the same pre-launch gate as another known schema fix. Right now nobody else can log in, so nothing leaks in practice — but this must land before any second real user exists. It's tracked in the audit log and in a column comment in the database itself, not just in this checkpoint.
Inferred from what you said
5
R5 — Card copy layout + continuous branch numbering
Front = a short number-and-cue ("Root 7 · Harming the ordained"). Back = one-line essence, plain-language gist, a trimmed excerpt of the actual booklet text, a memory hook, and commentary with citation. Branch vows use one continuous count 1 through 46 straight through all seven perfection groups, rather than restarting the number at each group — a mistake the persona review specifically caught and fixed before it shipped.
Decided by Frank
6
R6 — Ratify ADR-086 (currently marked "proposed," executed ahead of ratification)
The decision record for this whole build is written and everything in it is already live — it was executed under your explicit dispatch before you could review it in the normal order. This checkpoint is that review. A click here flips its status from "proposed" to "accepted" (or routes it back for changes).
Decided by Frank
7
R7 — New persona: DEVOTEE "Tenzin D." — keep it or fold it in?
A sixth user-archetype persona (PERSONA-007) was created specifically to review this build from a devout-practitioner learner's point of view — a genuinely different lens than the existing personas (it caught the empty-block and full-text-rendering problems above). It's documented as a deliberate cap-exception case. Question for you: keep it as a standing persona for future content-study work, or was it a one-off tool that should get folded back into an existing persona once this pass is done?
Inferred from what you said
Future feature — §2

Outline: document → card-profile ingestion wizard

This build IS the wizard's target output, done once by hand. Nothing here is built — it's a spec sketch for later.

1
Upload. PDF/doc/text now, book chapter or YouTube transcript later. Text gets extracted server-side; the raw uploaded content is stored privately and never becomes shared corpus — same copyright boundary this build used.
2
Structure detection. Headings become section containers, numbered/bulleted lists become graded items, block quotes or verse become whole-text passage cards — exactly the split done by hand here. LLM-assisted, but checked by deterministic rules: item counts, continuous numbering, no orphaned items — the same checks the vows data file itself uses.
3
Card proposal. Per item: a short cue, a one-line gloss, a plain-language gist, an optional memory hook — full text stays on the back. Generated instead of hand-written, following the same copy contract this build used.
4
User confirms. A swipeable review of the proposed structure and sample cards; the user can edit titles and pacing, and pick how many new items arrive per day.
5
Profile creation. The exact pipeline this build used, run automatically: new profile, new cards, intake queue, daily drip release, dealing in the carousel.

What this build already hands the wizard for free: the card type (concept) already exists in the registry; the authoring script's shape — structure data → save → intake → drip — is basically the wizard's backend already; and the copyright boundary (verbatim text only ever in owner-private rows) is the default posture, not a bolt-on.

Open questions for whoever plans the wizard properly: what generates glosses/hooks automatically (the cheap-model-first escalation ladder is the leading candidate); how to pull in more than one source per item (this build's Sonam Rinchen commentary pass is the hand-made prototype of that); and the fact that the privacy/launch-gate work above is a hard prerequisite before any second person could ever upload their own content.

📱
Worth doing tonight: open the preview app on your phone, switch to the "Bodhisattva Vows" profile, and run a real carousel session. It's not a demo — it's your actual first day of cards, already scheduling under FSRS.
🧩
If R7's persona question lands as "keep," it's worth deciding now whether DEVOTEE-style personas get spun up per content domain going forward, or whether one general "content-study learner" persona covers all future document-upload profiles.