#### What's the relationship between Drupal CMS and the Starshot prototype?
The Starshot prototype was hacked together in two weeks to prove the concept at DrupalCon Portland. Modules were included based on @phenaproxima's personal preferences, not on any kind of process or methodology. There was no expectation that anything in the prototype would necessarily make it into the final Drupal CMS product, and there still isn't.
That said, the prototype did a number of things quite well: It established a reasonable repository layout, made workable infrastructural decisions, set up a testing pipeline, and added strong support for DDEV, which is Drupal's officially recommended local development platform. And what's more, the prototype chose several modules that are very likely to end up in Drupal CMS (Pathauto and Metatag being top examples).
When the Drupal CMS repository was created, it didn't seem wise to throw out all of that preexisting work and start from scratch. So the prototype code was renamed and copied into the Drupal CMS repository's `0.x` branch, with the intention that we would start with something that works, and iterate freely on that, rather than starting from scratch.
#### Does the Drupal CMS repository contain the definitive set of Drupal CMS recipes?
The recipes that exist in the Drupal CMS repository, and what they do, is completely up to the track leads. Recipes that came from the prototype are there only as examples, for track leads to examine, or change as they please, or even discard entirely. Be bold - slice and dice them to your heart's content!
With that in mind, Drupal CMS _will_ be built as a "monorepo/manyrepos" project. This means that each recipe in Drupal CMS will be available as its own Composer package, but they will all be _developed_ within the same repository. This avoids a huge pile of potential problems with dependencies, and other release management headaches. Symfony itself, for what it's worth, is developed in exactly the same way.
So the answer to this question is that yes, the Drupal CMS repository will contain all of the Drupal CMS recipes, but the number of Drupal CMS recipes, and how they fit together, will change over time. Recipes, by their very design, have a lot of freedom to change.
#### I see there's an install profile in Drupal CMS. How is this used? What does it do?
The Drupal CMS Installer is an install profile that exposes the ability to choose recipes during the site install process. It applies those recipes, then as a final step, it uninstalls itself, removing the site from any lock-in effect and leaving in the state that the chosen recipes put it into. The installer itself contains absolutely no configuration and installs nothing beyond the stuff that it needs to do its job.
The recipes that are part of Drupal CMS should, in theory, apply against _any_ install profile (although that won't necessarily always be the case - but ideally all Drupal CMS recipes would apply cleanly against Standard and Minimal, but we don't yet enforce or test this).
The installer should be considered part of the overall infrastructure of Drupal CMS, and track leads should generally ignore it.
