Keep in mind that this is subjective, but here's my advice moving forward:
- Point 0: Reframe your expectations
As a PhD student, you want to do independent research, with some guidance from your supervisor. At the start, it makes sense for them to steer you a bit in terms of the big picture; later, you'll just want them to support your line of inquires. To get there, you want to build trust with them. Assuming good faith on all sides, the best way to achieve this is successfully completing tasks, and some niceness.
- Point 1: Find a big-picture idea/problem you both like
It sounds like your supervisor is already sending you suggestions (papers) and the like. Find something that you want to work on, and that they seem supportive of. This is a threefold objective. Scientifically, you should have some big-picture direction (even if it's not ideal, you'll learn a lot). Logistically, you want your supervisor's blessing to work on X (you can expand your degrees of freedom from there). Socially, you've been struggling to agree with them. Thank them for their contribution to finding X idea, and celebrate this win. Try to err on the side of being collaborative and agreeable.
- Point 1b: Take their ideas on board
Your supervisor might have more detailed ideas about how to do project X. Don't dismiss them out of hand; write them all down, thank them for their input. Once you've built more trust, you can argue again: for now, assume that they know what they're talking about and are trying to help you.
- Point 2: Debug, do science
Go through their ideas and your ideas, and come up with a reasonable plan of action to work on project X. If you're unsure about the implementation of some details, talk to a postdoc or some more experienced lab-mate. You might need to put some token effort into your supervisor's ideas to show that the approaches are unwise. The key point here is that you agreed to work on project X, and this is your positive attitude moving forward. Changing the implementation details along the way as the need arises is within your wheelhouse, so do it. Document what you're working on, what you tried, what worked so far (or didn't).
- Point 3: Update supervisor
Keep up a regular meeting schedule: let them know how project X is going. If you needed to fundamentally adjust their suggestions, frame it positively, e.g. "I did some reading and [Y paper] suggested that [Z method] is more efficient, so I implemented that..." or "I tried [dumb idea], but [obvious problems] happened, so I asked [trusted postdoc] and followed [N approach] instead.". As long as you have reasonable results and used a reputable scientific approach, they should come around in time.
- Point 4: Be nice, build your reputation
Keep working on project X, but don't forget the long game - you want your supervisor to trust you, and help you grow into a mature collaborator. Don't gloat if your approach works (over your supervisor's), give them credit, try to stay positive when problems arise and avoid the blame game. Right now you're "argumentative": at the end of the project, you're aiming for something like "well mhdadk sure is opinionated, but they get things done". It's probably also a good idea to try to build positive relationships with postdocs and other senior scientists around you.
- Point 5: Feed into the positive pattern
Once you're completed project X, propose your own ideas for the next big-picture and see how your supervisor reacts. Ideally, they'll give you more freedom once you've shown that you work well with it. Always try to find some common ground, but as you get more experienced, treat their recommendations as suggestions.
A positive anecdote: I had a similar, but far less extreme problem with my masters supervisor. They were a big-picture person, trying to give me specific advice (since I was starting out) but this was not their forte. A kind PhD student explained to me that when Prof A. said "do X to get Y", they meant that Y is a cool topic that they're interested in, and I should aim for a simpler, attainable rephrasing of Y with whatever method seemed most appropriate (often somewhat related to X). This was a bit confusing at first, but worked out well in the end.