Anthony

> I would avoid showing "fantasy commands" because it will generate more confusion than other things. There are plenty of options we have here on improving display to make these...

I was considering the same thing with tooltips, let's give that a try! I think that option could solve a few problems. I still would want to continue on with...

Another option for `cat .readthedocs.yaml` could be not just outputting the file, but being descriptive about what we're _actually_ trying to do: ``` % readthedocs-build --run-build-checks ✔️ Configuration found at...

This would be neither a warning or tip though, and would be in competition with the real estate for actual warnings/errors _on every build_. It also does not have to...

I'm pushing off the discussion not related to adding a BuildCommand.is_debug field to https://github.com/readthedocs/ext-theme/issues/171. None of that needs to interfere with this issue, and the next step there is experimenting...

Coming back to this, I had some more thoughts here. This applies to what we are trying to do in #11097 too. The big point for me against relying on...

Also, it would be great to have a maintainers site notification specific to this that goes out, so we can re-use this pattern when soft-disabling a project. A hard disable...

Yeah, great point on PR builds. Maybe we are strictly only concerned with failed active versions? I agree we can rethink notifications in a larger PR. If we add something...

Because taking automated actions on projects has been hard to get right -- spam banning, build retry -- maybe we should start fairly conservatively here. I think I'm comfortable saying...

I agree on keeping it simple if this is a feature we need, but I don't agree this is a feature we need though. I do have a few problems...