Testing

DocSlime is verified behavior-first: the things a user actually does — scaffold a tree, add a
document, create an ADR, list templates — are exercised end-to-end by running the real
compiled binary against throwaway directories and asserting on the files it produces. Small,
fiddly logic (slug normalization, ADR numbering) is covered by fast unit tests. The bar for
shippable is simple: the full suite is green, impeccable can discover docs context, and the
binary’s observable behavior matches the experiences and requirements.

Strategy

There is no separate integration layer: the codebase is small and the components are best
verified together through the CLI, so the black-box tests double as integration coverage.

Behavior coverage

Traceability contract

DocSlime’s TDD+BDD bar is that every important behavior can be followed from intent to
proof:

The DDD evidence is intentionally lightweight: docs should name the domain concepts and
boundaries that affect behavior, then use ADRs for hard-to-reverse decisions. If a project
has no meaningful domain split, the architecture doc should say that instead of inventing
bounded contexts.

Evaluation against product goals

Tests prove correctness; they don’t prove the product is working. The product-level signals from
../PRODUCT.md are evaluated qualitatively:

• Docs get filled — judged by whether scaffolded docs in real repos end up complete (no
  leftover <!-- LLM: --> guidance), rather than abandoned as templates. DocSlime dogfoods this
  by filling in its own docs/ tree.
• Low friction — judged by the time and number of steps from docslime init to a first
  useful, filled-in document.
• Agent context quality — judged by whether agents working in a DocSlime-backed repo give less
  speculative answers because product context, requirements, and ADRs are present.
• Impeccable context quality — judged by whether impeccable resolves docs/PRODUCT.md
  and docs/DESIGN.md without duplicate root files.
• Delivery quality — judged by whether each CLI, skill, and site artifact is verified
  through its user-facing distribution path rather than inferred from workflow completion.
• Production learning — judged by whether release failures, feedback, and adoption
  signals update discovery evidence or requirements when they reveal a material gap.
• Skill robustness — judged by whether skill files validate structurally and give agents
  enough setup, guardrails, verification, and failure handling to act without guessing.
• Adoption — tracked via Homebrew and npx skills installs and repos using the tree.

Running the tests

cargo test                  # unit + integration suite (expected: all green)
cargo clippy --all-targets  # lint (expected: no warnings)
npm run build               # docmd site build (expected: site/ output updates cleanly)

Continuous integration

DocSlime is now a monorepo with three CI-owned surfaces:

The daily CI workflow lives in .github/workflows/ci.yml and runs on pull requests to
staging or main, pushes to those branches, and manual dispatches. The release workflow
(.github/workflows/release.yml, generated by cargo-dist) remains tag-driven: it builds
and packages the CLI for all target platforms, creates the GitHub Release, and publishes the
Homebrew formula.

GitHub also has an active repository ruleset named “Protect main and staging from deletion”.
It targets refs/heads/main and refs/heads/staging with the deletion rule so the two
release branches cannot be removed accidentally.

Test data & environments

End-to-end tests run the real binary inside a fresh tempfile::TempDir per test, so each one
gets an isolated throwaway directory that is cleaned up automatically — no shared state, no
fixtures to seed, and no risk of touching the working repo.