Thank you! Completely agree with you.

Milestone size is basically tuned around one question: "can the user verify this in a short time without ambiguity?" If it is smaller than that, it becomes noise and hurts progress. If it is larger, people get stuck in a blob of work and lose the sense of forward motion. So the target is usually one meaningful capability change with one clear check - not a pile of subtasks and not a full feature.

On progress, I think completed milestones should stay as the primary unit because that keeps the system honest. But retries and failed attempts still matter as signal and we don't track them. I would not count them as progress in the same sense, but I would track them as learning/debugging history, like where people got stuck, how many tries something took and whether a milestone needs to be split or clarified. That is useful both for the user and for improving the recipe indeed. Great point!

And yes, I think mixing learning-path mode and spec mode inside the same project is important. A lot of real work starts milestone-first when you are learning the domain, then becomes spec-first once you know what you are building. So the model I like is one project with two views. Right now, Primer supports learner and builder tracks for the whole project/recipe. I would like to incorporate your feedback and allow switches between tracks.

[dead]

Agree. Right now, AI models are kind of at a plateau, so harnesses are really important.

Yes. They are trying to make AI-assisted development more structured. I am focusing with Primer more on learning-path oriented side. It means breaking things into small, verifiable milestones that one completes step by step, rather than defining a full spec upfront.