The way Claude helped me setup my system is interesting and may be useful for this project. I realized early on that the .md files are useful, but that Claude actually performed its best work not from reading through the Haiku Book, or 2nd hand sources, but rather from examining the code directly. So, I created a local Haiku checkout and gave Claude permission to pull any source it was interested in into the local Haiku repo using sparse checkout. This also has the added benefit of local files being faster to access and with less token usage, and it also removes the burden of reading the same files over and over again from the Haiku servers and putting a burden on them. My Media-OS repo only contains the source files I actually carry/changed. When it is time to build, it builds from my Media-OS repo first, but also pulls any stock source files that are needed for the build directly from the local Haiku repo.
Of course, if we are building the entire OS, we can check out the entire repo, rather than using sparse checkout, but the hybrid approach of having a local Haiku repo that is true to stock and our project repo, and compiling from a mix of the two depending on if we carry that file or not, seems like a solid approach. I am not sure if automating a build based on Haiku's nightlies is a good idea though, if it's even attainable at all. The issue is, I think it takes human judgement to determine how difficult merges go. Using my current reconciliation between Media-OS and the recent post Beta 6 changes as an example, a Haiku dev recently rewrote the Isochronous functions for XHCI. I finished my implementation a week or so prior. So now I built them each independently and will do some A/B testing to see how each performs. This could never be determined from an automated process.
