Think it through. Then let it build.

Reconstructed from Gravity’s PRD and portfolio story, not a verbatim transcript. Build activity and context checkpoints illustrate the method; they are not a historical tool log or live execution.

1. Brainstorm / Daniel

   I wrote a piece with a cello at the center and musicians moving around it. What if you could move inside the music?

2. Brainstorm / AI collaborator

   Let’s explore that. Is the listener conducting the piece, or discovering how it sounds from different places?

3. Brainstorm / Daniel

   Discovering. You could listen from the audience, the cello, or an orbiting performer. Each musician must keep an independent timeline.

4. Brainstorm / AI collaborator

   A browser experience could test that: introduce performers, hear them move, and change where you listen. How much belongs in the first version?

5. Brainstorm / Daniel

   One complete composition. Cello, independent performers, spatial audio, and two visual interpretations: Atomic and Celestial.

6. Draft PRD / Daniel

   Now create a PRD for me to review. Include the whole listener journey, MVP scope, what must stay true, and acceptance criteria.

7. Draft PRD / AI collaborator

   Here’s the draft: begin with cello, introduce performers, explore different listening positions, then return to cello alone. The requirements support that whole experience.

8. Review / Daniel

   Make musical independence explicit: no shared tempo, quantization, or synchronized entrances. The sound must also match each performer’s visible position.

9. Review / AI collaborator

   Updated: those behaviors must stay true through later changes. Keep docs/PRD.md current, and use the repo’s agent instructions to say when to read it—before planning, when scope changes, and before calling the work done.

10. Build MVP / Daniel

    I’m happy with the PRD. Go ahead and build the first MVP from it. Run the checks and bring back something I can try.

11. Build MVP / AI builder

    First I read docs/PRD.md and the relevant design and architecture notes. The intent is discovery inside the music; independent timelines and matching sound and motion must survive every implementation choice.

12. Build MVP / AI builder

    Building the performer, audio, and listener controls. As I connect them, I’m returning to the listener journey in the PRD. A control can work on its own while the overall experience is still wrong.

13. Build MVP / AI builder

    Now checking the whole journey against the current PRD: cello → performers → changing perspective → cello alone. Also checking independent timelines and matching sound and motion.

14. Build MVP / AI builder

    The first usable version is ready to try. You can introduce performers, switch perspectives, and hear the field change around you.

15. Try it / Daniel

    Now I have something to experience. I can listen from the center and the edge, watch the performers, and compare it with what I intended.

16. Try it / AI collaborator

    Try it with headphones. Does changing perspective change the mix? Do the performers stay independent? What feels different from the original idea?

17. Refine / Daniel

    The MVP works. Now bring the visual atmosphere closer to the concept: richer depth, clearer trails, and a more dimensional cello. Keep the musical behavior intact.

18. Refine / AI builder

    Even in a new session, I start by reading the current PRD and design references. I’ll refine the visuals, preserve musical independence, and check the whole journey again. We’ll record the agreed changes and why for the next session.

19. Refine / AI collaborator

    Back to trying it. The cycle continues with a real product in front of you: experience it, decide what matters, refine, and test again.