A good plan splits the work in two:
Why and what: why the work matters, who it's for, what the product does, and what people see. The product lead owns this.
How: the architecture, the data, and the code. Design and engineering own this.
A simple test
If two good engineers could build it in different ways, and the customer gets the same result either way, it's a how. Leave it out of the plan.
If the customer would notice the difference, it's a what. Put it in the plan.
For example:
"A customer can move a visit up to 24 hours before it starts." That's a what. The customer notices.
"Store reschedules in a new table." That's a how. The customer doesn't notice.
How Grove does this
Grove plans at the level of why and what. It writes outcomes and requirements in product language, not technical terms.
Grove reads your code, but doesn't plan it. It uses your code to know what already exists, and what would be a big change. It doesn't choose the architecture.
Builders plan the how. A builder's coding agent turns the requirements into a technical plan. See Turn requirements into a technical plan.
Why this split works
Product leads spend their time on decisions only they can make.
Builders get clear goals, and freedom in how to reach them.
Plans stay short, so people read them.