dsh-e2e-dev-sdd

Between a one-line product request and shippable code lie four gates: prototyping, architecture design, spec definition, and test acceptance. In practice, most teams either lock these into a rigid pipeline or let the artifacts scatter across chat threads where they are hard to trace and reuse. dsh-e2e-dev-sdd treats the five stages as independent entry points, so a team picks only the upstream deliverables a given requirement actually needs instead of replaying the full chain every time. Teams without an enterprise adapter can hand-enter requirements and run the entire loop out of the box; teams with one unify business facts into a Source Envelope via Source Providers or Connector adapters, sharing a single schema across plugin-level and project-level with project config overriding the plugin layer on name collisions.

The plugin revolves around one .sdd/ project space. A project board aggregates requirement bundles, standalone defects, and five-stage status, complete with burndown charts, delivery coverage, and a filterable delivery matrix. Each deliverable is a multi-file package-body text, diagrams, prototype, and attachments-whose file manifest and SHA-256 hash are frozen at acceptance. Later revisions open dedicated change sessions while older versions stay read-only. Linked code repositories automatically feed the first four stages as read-only reference; in the dev-test stage the plugin creates an isolated Worktree or Clone for every confirmed target repo, branches a dedicated SDD feature branch from the chosen baseline, lets the AI execute tests, records real exit codes and code fingerprints, and blocks local commits when evidence is stale or failing. All outer SDD repository Git operations-Fetch, fast-forward sync, scoped commits, and explicit Push-require human confirmation; on divergence or text conflict the plugin halts and defers to the operator.

If you build with the DSH Agent on DeepSeek Harness and want the requirement-to-code trace to be explicit, auditable, and reusable, this workbench slots naturally into daily practice. A simple need can skip straight from source to dev-test, while a complex project stages acceptance and freezes deliverables incrementally-the flexibility level is yours to set.