Implement with TDD

Work from the outside in and let each failure name the next move. Stop at shameless green; a later step refactors.

The discipline exists because you're fluent enough to write plausible code for almost anything, and plausible isn't correct. A failing test tells them apart.

What you were handed

The thing to build: $ARGUMENTS

If that's empty, ask. If it's a path, read it.

Take the acceptance criteria as the scope. Those are behavior, and behavior is what you can test. A suggested design, a test path, an ordering: that's a guess from a session that never ran the suite. Yours will run it, so your evidence is better. Where the repo contradicts the plan the repo is right — say so rather than diverge quietly.