[top-flight]

I've been in a similar situation. I think you're thinking about this in the wrong way. You want someone else to tell you what to do or how things should work, yet no one on your project knows (and they probably don't care either). You can use this to your advantage.

You should trace how major features or specific functionality actually works according to what the code does (trace all paths and weird edge cases and bug scenarios), then present that this is how 'x' actually works, and if the customer wants to do 'y' here is what we have to do to make it work. You have to take initiative to do deep dives without someone telling you what to do or hand holding.

Then when your PM or manager discusses adding new features you'll know what scenarios can break or need to be re-tested. Everyone else will have no clue and then they'll naturally start asking and looking to you for handling and leading maintenance and new features.

[TbobbyZ]

This is great advice, thank you! I’ve noticed my team act in the way you’ve described involving certain functionality that I’ve figured out and diagramed.