Appointment Wallet Pass

Status

planning

Tier

Tier 3 — Cross-cutting bet

Owner

Ryan Colston

Started

2026-04-26

One-line description. Auto-generated Google Wallet pass per FUB appointment so reminders land on the lock screen.

Why

Lock-screen reminders are the strongest "don't forget" mechanic that exists.

Calendar invites get buried. A wallet pass doesn't.

It's also a frame-control move. Most agents send a calendar invite. A pass shows up on the buyer's phone the morning of the meeting and updates on its own if anything reschedules.

That's the kind of touch other agents won't replicate.

Current state

Design approved 2026-07-04. Spec + Phase 1 implementation plan committed on monorepo branch docs/ryr-34-wallet-pass-design (worktree .claude/worktrees/ryr-34-wallet-pass-spec); both attached to Linear RYR-34 (state: Todo). No implementation code yet.

Scope grew from the 4/26 idea: three triggers now (setter scheduler, FUB hourly sync, Ry's calendar booking link), both wallet platforms from day one, and both recipients (external per-appointment pass + one persistent agent pass updated by push).

• Spec: ~/rylobasic/.claude/worktrees/ryr-34-wallet-pass-spec/docs/superpowers/specs/2026-07-04-appointment-wallet-pass-design.md

• Plan: same worktree, docs/superpowers/plans/2026-07-04-appointment-wallet-pass-mvp.md (23 TDD tasks; Sonnet-drafted, main-session reviewed)

• Status: planned, awaiting execution kickoff

• Last update: 2026-07-04
• Blocked on: execution-approach choice (subagent-driven vs inline); human prerequisites can run in parallel.

Next 3 actions

• Ry: Apple Developer Program enrollment ($99/yr) + Pass Type ID cert
• Ry: Google Wallet issuer account
• Execute the Phase 1 plan (MVP: pos-wallet + scheduler trigger + external passes)

Decisions log

• Portfolio organization — vault README is the front door, every project gets a hub from the template

Locked at MVP (captured in idea-inbox doc, not yet promoted to a decision file):

• Google Wallet only. Apple is post-validation.
• New pos-wallet Cloud Run service. Don't fold it into pos-fub.
• Pattern A (one pass per appointment). Pattern B (persistent seller-journey pass) waits on dim_lead.
• Delivery via FUB email template. No new SMS dependency at MVP.

Open issues

• Decide: Google-only ($0/yr, 1-2 days build) vs Google + Apple ($99/yr, 3-4 days build)
• Confirm FUB Owner role still has the appointment-created webhook scope
• Scope the first pass type. In-home consult B is the obvious one. Closing day, inspection, walk-through, photoshoot, pre-list strategy follow.

References

• Idea-Inbox doc: ~/CCPJ/projects/Idea-Inbox/idea/2026-04-26-appointment-wallet-pass.md
• Related: Custom Dialer, External API Platforms
• Code home (when built): ~/CCPJ/projects/pos-wallet/ (new service)