Intent and scope
The change begins with a bounded intent and a clear review focus, so the reviewer can see what is—and is not—in scope.
Free and open source · Apache-2.0 · Developer Preview
Proof: a governed change, end to end.
Inspect the current public receiver proof before the longer walkthrough.
A real Go e-commerce microservices repository first received SDF through an isolated evaluation baseline. An ordinary catalog-validation request then used the installed Front Door without restating SDF instructions.
v0.1.0 — released July 2026 · Python 3.11+
pipx install software-dark-factory
Core proof loop
A governed loop gives human review the context it needs.
See what reaches review when repository guidance, verification history, explicit limits, and evidence links travel with the change.
Repository-owned guidance
The repository’s own standards and playbooks shape the work at the point of change.
Verification history
Configured checks record passes, failures, blocked states, and reruns rather than hiding the path to the final result.
Evidence for review
The handoff carries applied guidance, risks, unknowns, limits, and durable evidence links alongside the change.
Human decision
SDF prepares a reviewable change. People still judge, approve, merge, and release it.
Current public proof
A public Go receiver, installed and then used.
This is the current inspectable proof of the stable v0.1.0 flow. The installation PR is merged; the follow-on catalog-validation PR remains an open draft.
1. Install SDF safely into an isolated evaluation baseline
Merged PR #21 installed SDF 0.1.0 into the unfamiliar Go receiver through the isolated `sdf-demo` baseline, leaving the default branch outside the evaluation route.
2. Run an ordinary catalog-validation change through the installed Front Door
Open draft PR #22 takes a normal catalog-validation request through the installed repository guidance without repeating SDF instructions.
What happens in the loop
The local loop is clear about what each command does.
SDF supports the acceptance decision. It does not approve, merge, deploy, or prove that a change is correct.
sdf init
Installs the repository Front Door.
sdf start
`sdf start --change-id <id>` optionally scaffolds evidence when early declaration is useful; it is not required for every change.
Work with repository guidance
The repository’s own standards and playbooks shape the work. Focused checks can support it, but are not closeout verification.
sdf close
`sdf close --change-id <id>` runs the repository’s full configured verification boundary and prepares the reviewer handoff.
sdf status
Optionally checks the installed Front Door and release identity; it is not a required lifecycle step. Approval and merge remain outside SDF.
Longer walkthrough
Recorded before the stable v0.1.0 documentation and installation flow.
The retained Loom follows an ordinary coding task in a Go e-commerce microservices repository as repository guidance, configured verification, and reviewer evidence become part of the delivery loop.
Video not loading? Watch the walkthrough on Loom.
Recording status: This recording predates the stable v0.1.0 documentation and installation flow. The core governed loop remains representative; use the current README and the public receiver proof for the current commands and installation surface.
Read the current README ↗What reaches review
The handoff preserves the reasoning around the diff.
The retained review visuals show the context that is otherwise easy to lose between an agent’s work and a human reviewer’s decision.
Intent and review focus
What was requested and what a reviewer should inspect closely.
Scope, limits, risks, and unknowns
The bounds of the change stay explicit instead of being reconstructed from a diff.
Applied guidance and verification history
Reviewers can see the repository expectations that shaped the work and every relevant result.
Evidence links
Durable links connect the concise handoff to the retained record when deeper detail is useful.
Why this matters
Make the delivery trail inspectable before review starts.
Less context to reconstruct
Intent, constraints, and the review focus arrive with the change.
Repository expectations travel with the work
Teams keep ownership of their standards rather than moving them into a generic workflow.
Verification remains inspectable
A pass is accompanied by the relevant history, including correction and rerun where they happened.
Human judgement remains central
The loop supports review; it does not make decisions on a team’s behalf.
Public project and current status
Inspect, install, and try the Developer Preview.
Software Dark Factory is free and open source under Apache-2.0, publicly available as v0.1.0, and supported on Python 3.11+.
GitHub repository ↗
Source, issues, and the current project surface.
README and getting started ↗
Current installation and command guidance.
ARCHITECTURE.md ↗
How the public verification and handoff model fits together.
SECURITY.md ↗
The project’s current security reporting and boundary guidance.
v0.1.0 release ↗
Public release notes for the Developer Preview.
PyPI distribution ↗
The published software-dark-factory package.
Deliberate limits
A governed loop supports judgement; it does not replace it.
SDF does not write or repair code, replace a coding agent, approve, merge, deploy, or release changes. It does not prove correctness, certify security, or establish production readiness. This demonstration shows one governed loop in a Go repository; it does not claim external adoption, measured savings, or universal repository coverage.