Projects are Chats

tl;dr

Create a "new" project (fork from your brainspace) which creates a "chat". But think about each chat item with respect to time. Some chat items you want the latest one, like a "file" in a repo at HEAD. But each "file" is like its own repo. Some chat items you want to spawn an "issue" which is itself a metadata chat. Some "issues" you may want a tag, which you will make design decisions on. This "tag" on this "issue" on this "file" is a "chat".

The "Project Explorer" on the left is a view on this **chat**. The "breadcrumb" control in the header is a view on this chat. The "log" is a view on it. The contents of a single file is a view on it. Rebase your brain to understand each and every piece of each and every project is its own project, with its own timeline, and you want to CRUD those pieces - **but natively in time**.

Bass...

ackwards. That's how people do software right now. They write code and THEN tack on things like commit messages, issue tracking, discussions, code reviews, etc., having forgotten that there were words in the first place. To unify production, we must understand that WORDS come FIRST and code, apps, libs, docker images, cloud architectures come after-the-fact.

Projects are...

chats. This is the third time on this page that this is stated - and for good reason. It's vitally important to grasp this key fundamental. "Vibe coding" is words. Ibgib "projects" are how we manage vibe coding in real-world situations, beyond silly trivial demos.