Pippa Go Quest

Tracks

1. 01📱The Pocket

   0/4 lessons

   What Pippa Go is, what it refuses to be, and where it came from

   Start with the shape. Pippa Go is a question-first mobile projection of a canonical brain — not a shrunken copy of a full chat app, and not a second Pippa. This track draws the outline: the one job the phone does, the three things it deliberately isn't, the lineage from Waystone's Crumb composer, and a first look at the four promises that make the rest of the quest.

   Lesson list (4)

   • 01
     What Pippa Go Is (and Is Not)~12 min · identity, overview, projection, mobile
   • 02
     Question-First, Not Miniature Chat~11 min · product-shape, constraint, design, focus
   • 03
     The Crumb Lineage~11 min · lineage, reuse, waystone, design-method
   • 04
     The Four Promises~10 min · roadmap, invariants, trust, overview

   ✓Quiz · 3 questions→

2. 02📥Capture First

   0/4 lessons

   The network is never on the save path

   The first and load-bearing promise. Before Pippa Go ever touches the network, your question and its images are already durable on the device — committed as one aggregate, in an IndexedDB outbox, safe from a dropped link or a killed app. This track proves why the network must never be the save, how the question and its images stay one unit, and why an interruption changes a status flag instead of erasing your work.

   Lesson list (4)

   • 01
     The Network Is Not the Save~12 min · local-first, critical-path, durability, anti-pattern
   • 02
     One Aggregate: Question + Images Together~12 min · aggregate, atomicity, consistency, intent
   • 03
     IndexedDB as the Durable Outbox~13 min · indexeddb, outbox, storage, blobs
   • 04
     Interruption Changes Status, Not Input~11 min · state-machine, immutability, resilience, status

   ✓Quiz · 3 questions→

3. 03🤐Honest Offline

   0/4 lessons

   Durable waiting, never a fabricated answer

   The promise that gives Pippa Go its conscience. Offline is a first-class state, not an error — but it produces honest, visible waiting, never an invented answer. This track draws the hard line: only a successful canonical call may materialize a real reply, the client never fabricates from cache or a local model, every state is shown plainly, and refusing to lie when you can't reach the truth is treated as a feature, not a limitation.

   Lesson list (4)

   • 01
     Durable Waiting, Not Fake Answers~12 min · offline, first-class-state, waiting, trust
   • 02
     Only a Canonical Call Materializes an Answer~12 min · authority, source-of-truth, materialize, boundary
   • 03
     Pending, Sending, Answered, Failed — All Visible~11 min · ux, state-visibility, honest-ui, feedback
   • 04
     Why Refusing to Lie Is a Feature~11 min · trust, philosophy, character, honesty

   ✓Quiz · 3 questions→

4. 04🔁Idempotent Retry

   0/4 lessons

   At-least-once delivery, exactly-once intent

   The promise that makes retry safe. On a flaky link you will send the same thing more than once — that's not a bug to avoid, it's a reality to survive. This track builds the machinery that turns unreliable at-least-once delivery into exactly-once intent: a device turn ID that dedupes, a check for completed/pending/unknown before any model call, and a clear-eyed look at what a careless double-send actually costs.

   Lesson list (4)

   • 01
     Delivery Is At-Least-Once; Intent Is Exactly-Once~12 min · distributed-systems, at-least-once, idempotency, reliability
   • 02
     The Device Turn ID~12 min · idempotency-key, identity, dedupe, client-generated
   • 03
     Check Completed / Pending / Unknown Before Any Model Call~12 min · retry-logic, state-check, guard, dedupe
   • 04
     The Cost of a Double-Send~11 min · consequences, cost, canonical-log, integrity

   ✓Quiz · 3 questions→

5. 05🪞Projection, Not a Brain

   0/5 lessons

   The phone owns capture; the backend owns the truth

   The promise that keeps Pippa one. Every Pippa Go conversation is canonical in the backend from birth, projected into a system folder, and promotable by branching — the phone owns durable capture and presentation, never Pippa's identity, memory, or judgment. This track draws the ownership line precisely: canonical-from-birth, the system-folder projection, branch-to-promote, continuity that lives in the backend, and the hard rule against growing a parallel soul.

   Lesson list (5)

   • 01
     Canonical From Birth~12 min · canonical, ownership, source-of-truth, no-drafts
   • 02
     The System-Folder Projection~11 min · projection, organization, origin-surface, system-folder
   • 03
     Branch to Promote~11 min · promotion, branching, continuity, reuse
   • 04
     Continuity Is Canonical, Presentation Is Bounded~12 min · context, continuity, presentation, replay
   • 05
     No Parallel Soul, Router, or Store~12 min · identity, one-brain, boundary, philosophy

   ✓Quiz · 3 questions→

6. 06👁️Actual Bytes

   0/4 lessons

   A filename is not proof Pippa can see the image

   The promise that makes multimodal honest. When you attach an image, Pippa must receive the real bytes and the real media type — not a filename, not a textual summary. This track builds the discipline: a shared staged-media resolver, two deliberate envelopes for the two flows, an all-or-error rule that forbids silent text-only downgrades, and why the media type has to travel with the bytes.

   Lesson list (4)

   • 01
     A Filename Is Not Proof~12 min · multimodal, vision, bytes, anti-pattern
   • 02
     One Resolver, Two Envelopes~12 min · shared-code, divergence, ownership-boundary, design
   • 03
     All-or-Error: Never Silent Text-Only~11 min · failure-handling, all-or-error, no-silent-downgrade, honesty
   • 04
     The Media Type Travels With the Bytes~10 min · media-type, mime, interpretation, pairing

   ✓Quiz · 3 questions→

7. 07🧩Macros as Projections

   0/4 lessons

   Reusable prompts that stay editable, cached, and out of the way

   Prompt macros make the composer reusable without ever becoming a second brain. This track shows how: instruction and input stay cleanly separate, macros are server-owned CRUD with an offline device cache, apply-free never means tool-free, and a macro never blocks a direct question. They're optional, editable projections over the same capture flow — convenience that never compromises the core.

   Lesson list (4)

   • 01
     Instruction and Input Stay Separate~11 min · macros, separation, template, legibility
   • 02
     Server-Owned CRUD With an Offline Cache~12 min · crud, cache, sync, ownership
   • 03
     Apply-Free Is Not Tool-Free~11 min · apply-free, tools, capability, terminology
   • 04
     Macros Never Block Direct Ask~10 min · optional, core-path, convenience, layering

   ✓Quiz · 3 questions→

8. 08🎒Own Your Pocket

   0/3 lessons

   Remote is config, the boundary is same-origin, the carrier is yours

   The closing discipline. A resilient client is also a client you own and control — no hardcoded topology, no secret baked into source, no browser-direct calls that bypass the engine's boundaries. This track ties the promises together: remote origin and auth are settings, the engine is a same-origin boundary that guards every request, and owning the thing that carries your questions is the point of building it yourself.

   Lesson list (3)

   • 01
     Remote Is Configuration, Not Topology~11 min · configuration, secrets, portability, security
   • 02
     The Same-Origin Engine Boundary~12 min · boundary, architecture, security, low-bandwidth
   • 03
     Own the Thing That Carries Your Questions~12 min · ownership, closing, craft, synthesis

   ✓Quiz · 3 questions→