If you wanna to continuous deployment, the sequence of events would be like: new app build -> helm charts output from app build -> trigger Pulumi pipeline (possibly with a manual update to your stack config that says what version of the Helm chart to deploy). Does that answer your question?

I guess one more followup, how does this look for a project and stack organization tree?

aws
   ├── eks
        └── dev
        └── staging
        └── prod    
   └── rabbitmq
        └── dev
        └── staging
        └── prod

Presumably you're gonna want some rabbitmq stuff in your K8s resources, e.g. a configmap, so you might benefit from putting them all together. Basically, I recommend you avoid stack refs until you really need them. Stack refs are almost the analogue of going from a monolith to a distributed architecture - don't do it until you need it. Pulumi is designed to coordinate all that stuff together.

When it comes to this design decision of multiple programs w/stack references, try to think through what changes you might see in the future and play it out: When we make this change, does it feel more "ergonomic" in a monorepo with a single Pulumi program, or multiple programs?

Conway's Law is also huge here. When I talk about stack refs, the canonical example I use is for a fictional larger org where you have a network team (VPCs and Transit Gateway), a platform team (EKS clusters deployed to the VPC subnets), and app teams (K8s resources deployed to the EKS clusters).