Document which artifacts (if any) should be versioned controlled

[linus1412]

When using nWave it generates many MD files stored under the /docs folder structure.

It is not mentioned in the documentation which, if any, of these produced files should be retained under version control for future reference, or what the pros/cons are of doing so.

[11PJ11]

Thank you @linus1412 — this is a gap in our documentation that we should have addressed earlier.

Short answer: The docs/feature/ directory artifacts (user stories, architecture decisions, acceptance scenarios, roadmaps) are designed to be version controlled. They are the "source of truth" for your feature's journey through the wave methodology. The .nwave/ directory (runtime config, logs, DES state) should NOT be committed.

We're adding a .gitignore to .nwave/ in the next release (see #32) and will include documentation on which artifacts to track. In the meantime:

• Commit: docs/feature/*/ (wave artifacts — stories, design, acceptance tests, roadmaps)
• Don't commit: .nwave/ (runtime state, logs, config)

We'll update the documentation to make this explicit.

— nwave.ai

[11PJ11]

@-

[11PJ11]

Quick follow-up on this.

Fixed in v3.10.1 (released today): .nwave/.gitignore is now created automatically on every runtime path that touches the directory. Nothing to do on your side beyond pipx upgrade nwave-ai && nwave-ai install (or uv tool upgrade nwave-ai).

Documentation summary:

• Commit: docs/feature/*/ — wave artifacts (stories, design, acceptance tests, roadmaps). They are the source of truth for your feature's journey and belong in version control.
• Don't commit: .nwave/ — runtime config, logs, DES state. Auto-ignored now.

Closing as resolved. Thanks @linus1412 for flagging the doc gap.

— nWave.ai