No, I'm pretty sure that everything I'm looking at is strictly rails. A friend pointed me at: https://gist.github.com/iangreenleaf/b206d09c587e8fc6399e which is a really good start.
All of the conversions of CamelCase to snake_case, or plural to singular are all strictly rails. AFAIK, the only thing Ruby cares about is capitalizing classes, maybe.
The rails guides are not references. They're tutorials.
An example of the thing I'm having trouble with:
I'm having things like "it says it's missing foo_bar_bazes" but "foo_bar_bazes" never occurs in my code, why does it think that it SHOULD?" The answer in this particular case was that there was a FooBarBaz or something, and that Rails decided that there obviously should be a foo_bar_bazes sql table, which I never created. Rails was RIGHT, there needed to be a sql table, but it took me like 4 hours to figure out what it was complaining about, and where it thought "foo_bar_bazes" needed to live, and why it should be foo_bar_bazes and not FooBarBaz, or FooBarBazes or foo_bar_baz, or any other of a number of possible things... It took another 4 person hours to figure out how to get migrate to correctly do the things I needed, because it converted Camel to snake in ways that I didn't expect.
In that case, I suspect that you really ought to follow a single tutorial all the way through, even if you do know how to program. I really recommend the (free to use online) https://railstutorial.org by Michael Hartl. We use this at Penn for all new programmers, regardless of their existing experience with programming or Ruby or Rails. The last time I did it, it took me about two days to go from end to end (I take it over each time there's a new version, so I can advise the people I'm on-boarding). I've been using Rails professionally for over ten years, and I still learn things from it.
Following that exercise all the way through will give you an excellent tour of the many ways that Rails extends the Ruby language to make your day-to-day experience easier and faster (once you know the tricks).
You really won't get very far in Rails (with all your hair in place) if you don't follow the conventions it expects you to. There are ways around everything (self.table_name = 'BadLegacyTableName', for example, or self.primary_key = 'somethingRailsWontGuess'), but you can come to those after you learn what it expects by default. Being able to back a table with a form using an empty class of the proper name doesn't come for free (you have to follow the conventions to get it). If you're used to doing everything from scratch, you may not expect that to work, or know where to look when it doesn't.