ABKC Co-Owner Registration Walkthrough — Dane + James Joint Session (V1)

Audience: Dane Cooper (primary owner / operator) + James Cooper (co-owner) executing the dual-owner registration validation together — plus the standing deliverable panel (engineering, security, legal, QA, payments/PCI, privacy, accessibility/WCAG 2.2, SRE) reviewing the evidence.
Version: V1 · 2026-06-09 · the document HANDOFF-TO-JAMES.md told James to stand by for. Companion to the single-owner walkthrough (run and signed first) and the Office-Manager walkthrough (what the office sees on their side).
Canonical source: this Markdown; HTML (interactive) / PDF / DOCX derived — regenerate per §10.
Time: ~45 min joint session (both of you live at the same time) + 10 min setup each beforehand.

§0 — Scope: what this session proves

The single-owner walkthrough proved the solo path: form → uploads → signature → PayPal sandbox → paid row → packet email. This session proves the dual-owner path on top of it:

Dane submits a registration listing James as co-owner.
The system invites James by email; the application waits for his signature.
James signs on his own account (canvas signature, his own login).
With all co-owners signed, the application completes (payment + submitted), both of you get confirmations, and the office sees one finished application.

This is a sandbox validation — synthetic dog data, test-fixture uploads, PayPal sandbox money. No real registry rows that the office must later clean up beyond the agreed test markers.

Not in scope (V1): litter registrations with two co-owners (sire + dam — the UI for sequential dual co-owners is unproven; see §16), live-mode payment, and the office-side approval (that's the Office-Manager walkthrough, module M3).

One honest unknown, by design

The exact payment ordering (does Dane pay at form submission before James signs, or does payment complete after all_signed?) is the one thing the code mapping left ambiguous — HANDOFF-TO-JAMES.md flagged "payment authority" as unresolved on 2026-05-28 and it still is. Step 2.6 has you record what the system actually does. That observation is a deliverable of this session, not a gap in it.

§1 — Pattern + Triple Verification Protocol

Tutorial Template v2 (17 sections · exactly 4 diagrams · interactive HTML · honest reservations · dual sign-off). Verification state, 2026-06-09:

Level	Verification	Receipt
L1 Empirical (code)	The five co-owner routes exist in production code: `request` / `sign` / `resend` / `status` / `reject`; the signing page is the member account's Pending signatures screen with a canvas signature pad; invitations expire after 14 days; a brand-new co-owner gets an account-invitation branch	Same-day code-level mapping of `katterskillsawmill/ABKC-website`
L1 Empirical (single-owner)	The underlying payment rail was validated end-to-end on 2026-05-28 (HTTP 400-not-500 probe; $62.00 sandbox flow)	Single-owner walkthrough V1 §1 + its production probe
L2 / L3	PayPal sandbox + Supabase + Resend vendor behavior	PayPal sandbox accounts · Supabase Storage docs · Resend docs

What has NOT been verified yet: this exact dual-owner UX as a human click-through. That's why you're both here.

🧭 Interactive HTML: checkboxes persist per-browser (Dane and James each track their own copy); 📝 notes panel auto-saves — Dane's copy is the canonical observation record for §16/V2 feedback.

§2 — Prerequisites (split by person)

Dane (primary owner)

[ ] Chrome/Edge, signed in to your ABKC member account at https://abkc-website.vercel.app/login
[ ] test-fixtures/ from this folder on disk (the 4 upload stand-ins: 2 dog photos + 2 pedigree PDFs)
[ ] PayPal sandbox buyer credentials at hand (password manager / .env.test.local — never in this doc)
[ ] Single-owner walkthrough already executed + signed (its §17) — if not, stop and do that first
[ ] Phone able to receive SMS (if the form's verification step fires)

James (co-owner)

[ ] Chrome/Edge on his own machine (or at minimum a separate browser profile — never the same session as Dane)
[ ] Access to his email inbox live during the session (the invitation lands there)
[ ] An ABKC login of his own — it's fine if he doesn't have one yet: the invitation email branch creates it (Gate 3 handles both cases)
[ ] Phone for SMS
[ ] 45 uninterrupted minutes; HANDOFF-TO-JAMES.md read (10 min)

Both

[ ] A call/screen-share channel open between you for the whole session
[ ] Agreed test markers: dog name prefixed TEST-COOWNER- so the office can spot-and-clear sandbox rows later

§3 — Diagram 1/4: the dual-owner architecture

graph TB subgraph DANE["Dane (primary owner)"] F["register/dog form
co-owner fields = James"] AD["account dashboard
application + signature status"] end subgraph SYS["ABKC system"] REQ["signature request row
status: invited - 14-day expiry"] MAIL["invitation email (Resend)
new-user branch creates account invite"] APP["application row
waits on signatures"] PAYR["payment rail
PayPal sandbox / Stripe test"] DONE["all_signed → completion
confirmations to BOTH"] end subgraph JAMES["James (co-owner)"] INBOX["email inbox"] PEND["account → Pending signatures"] PAD["canvas signature pad"] end F --> APP F -->|"co-owner listed"| REQ REQ --> MAIL --> INBOX INBOX --> PEND --> PAD PAD -->|"submit signature"| DONE APP --> PAYR PAYR --> DONE DONE --> AD DONE --> INBOX

§4 — Diagram 2/4: the joint-session sequence

sequenceDiagram participant D as Dane participant S as ABKC system participant E as Email (Resend) participant J as James D->>S: fill register/dog with James as co-owner + uploads + signature S-->>D: application created - status: awaiting co-owner signature S->>E: invitation (existing-user or create-account branch) E-->>J: signing invitation lands J->>S: sign in (or create account from invite) J->>S: Pending signatures -> open request J->>S: draw signature on canvas -> Submit S-->>J: status signed + confirmation email S-->>D: confirmation email (all co-owners signed) D->>S: payment step ($62.00 sandbox) - ORDER OBSERVED at 2.6 S-->>D: application submitted - office queue Note over D,J: Record at 2.6/4.1 whether payment came BEFORE or AFTER the signature - V2 pins it.

§5 — Diagram 3/4: co-owner troubleshooting decision tree

flowchart TD A[Something stalls] --> B{Where?} B -- "James: no invitation email" --> C[Check spam + exact address Dane typed
then Dane: account → application → Resend invite] B -- "James: link opens but cannot proceed" --> D{Does James have an ABKC login?} D -- no --> D1[Use the create-account invitation branch
sign up first, then Pending signatures] D -- yes --> D2[Sign IN first, then open
account → Pending signatures directly] B -- "Pending signatures list is empty" --> E[Identity mismatch: the invite went to a
different email than James's login -
Dane resends to the LOGIN email] B -- "Canvas will not draw / submit disabled" --> F[Draw with mouse or touch inside the box
refresh once if blank - re-open from the list] B -- "Request shows expired" --> G[14-day expiry - Dane resends from the application] B -- "Payment step errors" --> H[Same triage as single-owner walkthrough Gate 3
create-order/capture-order in DevTools] C --> Z[Continue at the step you left] D1 --> Z D2 --> Z E --> Z F --> Z G --> Z H --> Z

§6 — Diagram 4/4: the 45-minute joint session

gantt title Joint session time budget (both live) dateFormat HH:mm axisFormat %H:%M section Gate 1 Setup checks both sides :g1, 00:00, 8m section Gate 2 Dane form + co-owner + submit :g2, after g1, 12m section Gate 3 James invite -> sign :g3, after g2, 12m section Gate 4 Completion + evidence + sign-off :g4, after g3, 13m

§7 — Gate 1: setup, both seats (~8 min)

[ ] 1.1 (Dane) Sign in; open https://abkc-website.vercel.app/register/dog in one tab and your account dashboard in another. DevTools → Network → Preserve log ON (same habit as single-owner Gate 1).
[ ] 1.2 (James) Sign in to email; keep the inbox tab visible.
[ ] 1.3 (James) Try https://abkc-website.vercel.app/login: if you have an account, sign in now; if not, do nothing yet — Gate 3 uses the invitation's create-account branch (that branch is part of what we're validating).
[ ] 1.4 (Both) Confirm the call/screen-share is up and you can hear each other.
[ ] 1.5 (Dane) Have the sandbox buyer login ready (you'll use it whenever the payment step appears).

Dane setup: form + account tabs
(capture during execution)

§8 — Gate 2 (Dane): submit with a co-owner (~12 min)

[ ] 2.1 Fill the registration form with the agreed synthetic data — dog name prefixed TEST-COOWNER- — and fill the co-owner section with James's name + the exact email he's checking (the address you type is where the invitation goes; a typo here is the #1 stall).
[ ] 2.2 Upload the four test-fixtures/ files (pedigree front, complete pedigree, photo front, photo side).
[ ] 2.3 Draw your signature; tick the attestation boxes; verify the $62.00 total renders.
[ ] 2.4 Validate / proceed exactly as in the single-owner flow.
[ ] 2.5 If the PayPal step appears now — complete it with the sandbox buyer (single-owner Gate 3 muscle memory: yellow button → popup → sandbox login → approve).
[ ] 2.6 📝 RECORD THE ORDERING (notes panel): did the system ask for payment (a) at submission, before James signed, or (b) does it hold payment until all signatures land? One sentence + a screenshot. This is the §0 unknown being resolved.
[ ] 2.7 Open your account dashboard → the new application should show a waiting-on-co-owner state with James listed. If a "Request Co-Owner Signature" button is present (rather than auto-sent), click it, choose role primary, confirm his email, send.
[ ] 2.8 (James, watching his inbox) The invitation should land within ~2 minutes. Not there? → §5 tree, top branch (spam → resend).

Co-owner fields filled with James
(capture during execution)

Application waiting on co-owner signature
(capture during execution)

§9 — Gate 3 (James): sign (~12 min) · Gate 4 (both): completion + evidence (~13 min)

Gate 3 — James signs

[ ] 3.1 Open the invitation email. Read which branch you got: existing-user ("sign in to review and sign") or new-user ("create your ABKC account"). Tell Dane which — 📝 he records it.
[ ] 3.2 Follow it: create the account if invited to (use the SAME email the invite came to), or just sign in.
[ ] 3.3 Go to your account's Pending signatures page — https://abkc-website.vercel.app/account/pending-signatures. The TEST-COOWNER- request is listed with the dog's details and Dane as primary owner. Empty list? → §5 tree, identity-mismatch branch.
[ ] 3.4 Click Sign Now → the canvas pad expands. Draw your signature with mouse/finger; your member number auto-fills if your profile has one.
[ ] 3.5 Submit signature → expect an on-screen confirmation (status signed) and a confirmation email to you.
[ ] 3.6 (Dane, same moment) Watch your inbox: the all-co-owners-signed confirmation should arrive; the application's status on your dashboard advances.

Pending signatures list with the request
(capture during execution)

Canvas signature drawn before submit
(capture during execution)

Gate 4 — completion + evidence

[ ] 4.1 (Dane) If payment was held until signatures (case (b) at 2.6), the pay step is now live — complete the $62.00 sandbox payment and note create-order / capture-order both 200 in DevTools (single-owner Gate 3 pattern).
[ ] 4.2 (Dane) Dashboard shows the application submitted (the office's queue now owns it — exactly what the Office-Manager walkthrough trains them to pick up).
[ ] 4.3 (Both) Email evidence: Dane has the signed-confirmation (+ payment receipt); James has his signing confirmation. Screenshot both inboxes.
[ ] 4.4 (Dane) Evidence pack — capture the manifest below; scrub per the package's privacy rules (real emails blurred; sandbox IDs are low-risk).
[ ] 4.5 (Both) Fill §17 (dual sign-off) while it's fresh — including the 2.6 ordering observation and any §5 branches you hit.

Screenshot manifest (14 screens — extends the package capture guide)

#	File	What it proves
1	`coowner-gate-1/01-dane-setup.png`	Clean start, DevTools preserving
2	`coowner-gate-2/01-coowner-fields.png`	James listed as co-owner pre-submit
3	`coowner-gate-2/02-awaiting-signature.png`	Application in waiting-on-co-owner state
4	`coowner-gate-2/03-payment-ordering.png`	The 2.6 observation (whichever case occurred)
5	`coowner-gate-3/01-invitation-email.png`	Invitation received (branch visible)
6	`coowner-gate-3/02-pending-list.png`	Request visible on James's account
7	`coowner-gate-3/03-canvas-signed.png`	Signature drawn pre-submit
8	`coowner-gate-3/04-signed-confirmation.png`	James's on-screen confirmation
9	`coowner-gate-3/05-james-email.png`	James's confirmation email
10	`coowner-gate-4/01-dane-allsigned-email.png`	Dane's all-signed email
11	`coowner-gate-4/02-capture-order-200.png`	Payment captured (whichever gate it fired in)
12	`coowner-gate-4/03-submitted-status.png`	Application submitted on dashboard
13	`coowner-gate-4/04-office-queue-row.png`	(optional, office role) the row in `/admin/registrations`
14	`coowner-gate-4/05-devtools-summary.png`	Network rows: request/sign/payment endpoints

§10 — Reference card

Registration form ......... https://abkc-website.vercel.app/register/dog
Dane's dashboard .......... https://abkc-website.vercel.app/account
James signs at ............ https://abkc-website.vercel.app/account/pending-signatures
Login / signup ............ https://abkc-website.vercel.app/login   /signup
Amount (sandbox) .......... $62.00 = $55 base + $7 processing
Invitation expiry ......... 14 days (resend from Dane's application page)
Roles in the system ....... co-owner role "primary" (this session) - "sire_co_owner" exists, unproven UI
Test marker ............... dog name prefix TEST-COOWNER-
Evidence dirs ............. screenshots/coowner-gate-{1..4}/
PayPal sandbox dashboard .. https://developer.paypal.com/dashboard/accounts

Regenerate formats (from this folder):

$env:PYTHONUTF8=1
C:\Users\dcoop\.venv\Scripts\python.exe C:\Users\dcoop\scripts\generate-tutorial-html.py ABKC-PAYMENT-WALKTHROUGH-CO-OWNER-V1-2026-06-09.md ABKC-PAYMENT-WALKTHROUGH-CO-OWNER-V1-2026-06-09 --title "ABKC Co-Owner Registration Walkthrough (V1)" --slug abkc-coowner-v1

§11 — UI anatomy: the two screens that are new vs single-owner

The co-owner block on the form (Gate 2): name + email + role fields inside the registration form. The email field is load-bearing — it's both the invitation address and the identity the signature gets matched against.

Pending signatures (Gate 3, James's account): a list of open requests — each row shows the dog, the primary owner, requested date, and a Sign Now action that expands into the canvas pad with a Submit button below. States you might see on a row: invited (fresh), signed (done), declined, expired (14-day lapse → ask Dane to resend).

Everything else (form fields, uploads, PayPal popup, success banner) is identical to the single-owner walkthrough — don't re-learn it, reference it.

§12 — Verification: what "this session passed" means

Check	Evidence	Pass
Invitation delivered	Screen 5 (+ branch noted: existing vs new user)	☐
Signature recorded	Screens 7–8 + James's email (screen 9)	☐
All-signed propagation	Dane's email (screen 10) + dashboard state	☐
Payment captured	Screen 11 — `capture-order` 200, $62.00 sandbox	☐
Application completed	Screen 12 — `submitted` on the dashboard	☐
Ordering question resolved	2.6 note + screen 4	☐
Office handoff visible	Screen 13 or the office confirms the queue row	☐
No real PII leaked	Manifest scrubbed per package privacy rules	☐

Fail-stop rule: any red box that the §5 tree can't clear in ~5 minutes ends the session honestly — note the exact step + screenshot, file it for dev (that outcome is still a successful validation session, per the integrity policy: finding the break IS the point).

§13 — What's next

If this passes: ABKC-12's remaining work is the automated Playwright spec mirroring what you two just did by hand (two browser contexts, DB token lookup, canvas events) — your 2.6 ordering observation directly shapes its assertions. The office trains M5 (co-owner status/resend) against real behavior. V2 of this doc pins the payment ordering as fact.
If it fails: the failing step + screenshot becomes the dev issue; the quarantine-style discipline applies (fix, then re-run this walkthrough for the green receipt).
Either way: send the signed §17 + evidence pack to the package folder; INDEX V2 records the session.

§14 — Anchors (verified 2026-06-09)

The flow's own screens: register/dog · account dashboard · pending signatures · login · signup

Payments + sandbox: PayPal sandbox accounts · PayPal Checkout docs · PayPal sandbox tooling · PayPal REST API v2 orders · Stripe testing · PCI SSC standards

Platform: Supabase Storage · Supabase Auth · Supabase database tables · Supabase RLS · Supabase status · Resend docs

Signature canvas + evidence: MDN Canvas API · MDN CanvasRenderingContext2D · MDN PointerEvent · WCAG 2.2 (canvas signature accessibility context) · ShareX · Mermaid

Tracking + follow-on automation: Jira ABKC-12 (the automated E2E follow-on) · Jira ABKC-14 (single-owner sign-off gate) · ABKC-website repo · Playwright browser contexts (the two-actor test pattern ABKC-12 automates)

Estate cross-references: single-owner walkthrough V2 · owners presentation V1 · screenshot capture guide V1 · HANDOFF-TO-JAMES · package INDEX V2 · Office-Manager walkthrough V1 (modules M3 + M5 are the office's side of this exact flow) · Wave-MT6 protocol · Tutorial Template v2 spec

(27 external + 8 estate file anchors = 35 — machine-counted)

§15 — Glossary (45 terms)

Term	Meaning here
Primary owner	Dane — submits the registration and owns the application
Co-owner	James — listed on the form; must sign before completion
Co-owner role	`primary` (this session); `sire_co_owner` exists for litter scenarios (unproven UI)
Signature request	The row the system creates when a co-owner is listed
Invitation email	The Resend message telling the co-owner to sign
Existing-user branch	Invitation for a co-owner who already has an ABKC login
New-user branch	Invitation that first creates the co-owner's account
Identity match	The sign step checks the signer's login/email against the request
Pending signatures	The member-account page listing open requests
Sign Now	The action that expands the signature canvas
Canvas / signature pad	The draw-with-mouse/finger box; stored as an image
Member number	Auto-filled on the signing screen when the profile has one
invited / signed / declined / expired	The four request states
14-day expiry	Invitation lifetime; resend restarts it
Resend invite	Dane's button on the application for a fresh invitation
all_signed	The condition (every listed co-owner signed) that unblocks completion
Awaiting-co-owner state	The application status while signatures are outstanding
Payment ordering	The §0 unknown: pay-at-submit vs pay-after-signatures (2.6 records it)
create-order / capture-order	The two payment endpoints; both must return 200
$62.00	The single-dog sandbox total ($55 base + $7 processing)
Sandbox buyer	The PayPal test account that "pays" with fake money
Sandbox vs live	Test rail vs real money — this session is entirely sandbox
Smart Buttons	PayPal's rendered payment buttons on the form
Popup flow	PayPal's login window during payment
DevTools / Network tab	Browser panel proving the endpoint responses
Preserve log	DevTools setting keeping rows across navigation
test-fixtures	The four stand-in upload files shipped with the package
TEST-COOWNER- prefix	The agreed marker making sandbox rows identifiable
Synthetic data	Made-up dog/owner details — no real PII
Privacy scrub	Blurring real emails etc. in evidence screenshots
Evidence pack	The 14-screen manifest + notes export
submitted	Application status entering the office queue
Office queue	`/admin/registrations` — where the office picks this up
Packet email	Certificate + pedigree + receipt PDFs sent on office approval
Confirmation email	The signing/all-signed notices both parties receive
Spam check	First move when an expected email is missing
Resend (vendor)	The email delivery service
Supabase	The database + storage backing the application rows
Storage bucket	Where signature images and uploads live
RLS	Row Level Security guarding member data
Dual sign-off	§17 — both participants attest
Fail-stop	Ending the session honestly at an unclearable red box
Wave-MT6	The manual-testing protocol this session descends from
ABKC-12	The Jira story for the automated E2E version
Joint session	Both participants live simultaneously — never solo

§16 — Honest reservations

The dual-owner UX has never been human-executed before this session — the routes and pages are code-verified, the click-through is not; surprises are in-scope findings, not failures of the doc.
Payment ordering is deliberately recorded, not asserted (§0, 2.6) — the V1 of this document refuses to guess; V2 states it as fact with your receipt.
The invitation's exact link target wasn't pinned in code — Gate 3 navigates via the stable path (sign in → Pending signatures) so a link-pattern change can't strand James.
Sire + dam dual-co-owner (two signers) is out of scope — single co-owner only; the two-signer UI is unproven and excluded until validated.
Email deliverability ramp — early sends may land in spam (young domain reputation); the §5 tree's first branch exists for exactly this.
Screenshots are capture-during-execution — the manifest is authored, the images aren't, until you run it.
Mermaid renders as code text in DOCX (known generator limitation) — train and execute from HTML/PDF.
Sandbox passing ≈ high confidence, not live proof — live mode still needs its own KYC'd validation pass (same caveat as the single-owner doc).

§17 — Dual sign-off (complete together, at the end)

Attestation: we executed this walkthrough live and the §12 checks reflect what we actually observed, including the 2.6 payment-ordering observation recorded below.

2.6 observation (payment ordering): ☐ paid at submission, before signature · ☐ payment held until all-signed · notes: ________

Participant	Name	Date	Signature
Primary owner	Dane Cooper	____	________
Co-owner	James Cooper	____	________

Gates passed: G1 ☐ · G2 ☐ · G3 ☐ · G4 ☐ — §12 checks all green: ☐

§A — Amendments Log (append-only)

2026-06-09 — V1 authored by Claude Fable 5 (plan ~/.claude/plans/autonomous-loop-check-sparkling-tome.md). The co-owner walkthrough that single-owner V1 §0 and HANDOFF-TO-JAMES.md deferred. Grounded in same-day code-level mapping (five signature routes; Pending-signatures page + canvas pad; 14-day expiry; new-user invitation branch) + the validated single-owner payment rail. Payment-ordering left as a recorded observation by design (integrity policy: no asserted guesses). Per ~/.claude/rules/archive-policy.md: append-only.