Draft. Review. Approve.
Your local agent turns intent into explicit scenarios. You review the expected behavior before implementation starts.
A specification you accepted SPECIFICATION → VERIFICATION
Build with intent.
Ship with evidence.
Describe a change. Review the spec. Let your coding agent create the tests and implementation. Playwright checks the result; SDDFW shows the evidence.
Open source · Local workflow · No SDDFW account
01 / THE ACCEPTANCE REPORT+
CHANGE / RESERVATIONS
Cancellation window
Allow cancellations at least 24 hours before a reservation.
2 / 4 criteria passed
Needs attentionCR-003 / SAMPLE EVIDENCELOCAL
cancellation.test.js:42
Expected
rejectedReceived acceptedA reservation 12 hours away can still be cancelled.
Every result has a reason. Every gap stays visible.
A framework for the way
you already build.
Your specs+</> Your agent+ Your checks
First integration: Playwright UI + API tests.
Codex CLI, Claude Code, or your own tool.
TRY A REAL CHECK
Your first
evidence.
Start with a complete local example: a frontend, a real Node.js API, and Playwright checks. No AI account needed to verify it.
Install from GitHubRequires Node.js 22+. v0.1 is an early source preview; the npm package has not been published.
AFTER INSTALLING THE CLIRUNNABLE DEMO
mkdir sddfw-demo
cd sddfw-demo
sddfw init --demo --install
# Read the spec before approving it
sddfw approve favorites
sddfw verify favorites
sddfw report favorites--install installs the demo dependencies and Chromium. Verification starts the application and writes real HTML, Markdown, and JSON evidence.
THE WORKFLOW
Make intent
traceable.
Keep the behavior you want connected to the work you review. One focused change at a time.
Create checks. Make the change.
The agent prepares tagged Playwright tests. SDDFW checks them first, then freezes them while the agent implements the behavior.
Reviewable code and testsRun. Inspect. Share deliberately.
Playwright executes the checks. Read each result, its evidence, and the recorded environment before accepting the change.
Local acceptance reportsTHE PRINCIPLE
A checkmark should
tell a story.
The first version is built around a simple idea: make the evidence as easy to review as the change itself.
A result for every criterion.
Missing and skipped checks stay unverified. A pass after retries stays flaky. Gaps never disappear behind a green summary.
A source for every result.
Follow the connection from the expected behavior to the check and its recorded output.
Context for every change.
See the checked sources, environment, and declared mocks. Changed code or specs require fresh evidence.
ONE APP. BOTH SIDES OF THE CHANGE.
Frontend meets
backend.
The favorites example uses real local HTTP calls.
Each scenario answers a different question.
Did the behavior reach the user?
Save an item through the accessible interface. Reload the page and check that the saved favorite still appears.
Given
A user is viewing an item.
When
They save it and reload.
Then
Read the executable UI tests It remains in their favorites.
Did the API preserve the rule?
Save the same item twice and check there is one stored favorite. Query as a second user and check their list stays separate.
Given
Two simulated users.
When
One repeats a save request.
Then
Run the fullstack example No duplicate; no cross-user favorite.
This demo uses simulated identity and local storage. It demonstrates UI/API verification; it is not a production authentication template.
SMALL STEPS. A CLEAR DIRECTION.
The first chapter.
A focused first integration.
Future additions follow community use.
v0.1 SOURCE PREVIEW
Acceptance,
made visible.
A local loop from reviewed behavior to agent-authored tests, implementation, and evidence.
- Native spec + explicit approval
- Playwright test creation and adaptation
- HTML, Markdown, and JSON reports
THE INITIAL SCOPE
NextEXPLORING
Context that
carries forward.
Keep the link between intent and evidence useful as the project evolves.
- OpenSpec and Spec Kit imports
- More local agent adapters
- Learning from real project adoption
GUIDED BY THE FIRST USERS
LaterON THE HORIZON
A framework
that grows with you.
Expand the same clear acceptance loop to more tools, stacks, and teams.
- More test runners and adapters
- Shared review workflows
- Reusable behavior scenarios
ONE USEFUL ADDITION AT A TIME
A LITTLE MORE CONTEXT
Good questions.
Can I install SDDFW yet?
Yes, the v0.1 preview can be installed from the GitHub repository's main branch. Follow the linked getting-started guide. There is no npm registry release yet. The interactive reservation report above is an illustrative sample; the CLI favorites demo executes real local tests.
Will I need to change my coding agent?
Use your installed Codex CLI or Claude Code, with its existing account and permissions. Manual mode writes instructions for your preferred tool, then you run verification separately. SDDFW supplies the specification and acceptance loop; agent usage follows your provider’s usual charges.
What does a passed check actually mean?
The mapped checks executed and passed for the recorded sources and environment. Review the scenarios and assertions: a passing test can check the wrong interpretation. Missing checks stay unverified, retries stay visible, and declared mocks limit the result. Local evidence does not certify production.
Can the agent change a test to make it pass?
Tests can be adapted during preparation when the accepted behavior requires it. Implementation runs against frozen tests; modifying them stops the workflow. You still review the prepared assertions: SDDFW cannot prove they represent the correct interpretation of the requirement.
Does SDDFW upload my evidence?
Reports and traces are stored locally. SDDFW does not automatically publish them. Your coding agent communicates with its provider under its own settings, and detailed traces can contain application data. Inspect artifacts before choosing to share them.
BUILD THE NEXT CHANGE WITH CLARITY.
Intent in.
Evidence out.
Try one small change.
Help make the next one easier for everyone.