Behavior regression detection for critical systems

Vokt Workflow Examples

Real-world scenarios showing how Vokt catches behavior changes before they ship

See what your system did before vs after — at the behavioral level, not just syntax. These examples demonstrate behavior-level validation in action.

Not BDDNot spec-firstNot a testing framework— Vokt extracts behavior from existing code.

Table of Contents

  1. 1. Legacy Code: First Touch
  2. 2. The 80/20 Rule in Action
  3. 3. Catching Security Vulnerabilities
  4. 4. Living Documentation
  5. 5. Team Inheritance Scenario
  6. 6. Understanding Complex ModulesNEW
  7. 7. New Feature Development
  8. 8. Handling Drift Conflicts
  9. 9. End of Sprint CleanupNEW
  10. 10. Preparing for AuditNEW

Features Demonstrated

The scenarios below cover the complete Vokt feature set. Here's how each phase maps to CLI commands and MCP tools:

PhaseFeatureCLI CommandMCP Tool
1Project setupvokt init
2Cold start specsvokt generatevokt_modify_start
3Context analysisvokt generate-contextvokt_modify_start + use_context
4Module synthesisvokt synthesize-moduleCLI via Claude
5New file creationvokt generatevokt_create
6Modify with driftvokt drift checkvokt_modify_complete
7Test generationvokt generate-testsgenerate_tests
8Review queuevokt reviewvokt_review_queue
9Analyticsvokt reportCLI via Claude
10Doc exportvokt exportCLI via Claude
11LSP Servervokt lsp serveReal-time via VS Code extension

Feature Checklist

After working through the scenarios, verify you've exercised these core features:

Setup & Generation

  • Project initialization (vokt init)
  • IDE integration (.mcp.json)
  • Cold start spec generation
  • Context-aware analysis with dependencies
  • Module synthesis

Modification & Validation

  • New file creation (spec-first)
  • Modification with drift detection
  • Drift resolution
  • Test generation from specs
  • Review queue management

Reporting & Export

  • Analytics report (HTML/Markdown)
  • Documentation export
  • PR description generation

IDE Integration

  • LSP server for real-time feedback
  • VS Code extension commands

1. Legacy Code: First Touch

Scenario

You inherit a 50,000 line payment processing system. Zero tests. No documentation. Original developers gone. Boss says: "Add refund support by Friday." You have Claude Code to help, but how do you ensure it doesn't break existing payment flows?

❌ Without Vokt:

AI modifies code blindly, no context on constraints. Breaks fraud detection. Ships to production. 😱

✅ With Vokt:

Vokt documents constraints, AI preserves them, tests verify safety. Ships confidently. ✅

First-Time Setup

You: "I need to set up Vokt before I start"
$ vokt init
Select IDE integration:
1. Claude Code
2. Cursor
3. None (CLI only)
> 1
Created .vokt/config.yaml
Created .mcp.json (Claude Code MCP integration)
$ vokt mode auto
Workflow mode set to: auto
[Now when you ask Claude to modify files, Vokt tools activate automatically]
🔧Under the Hood
Claude called: vokt init
With: {
ide: "claude-code",
creates: ".mcp.json, .vokt/config.yaml",
}

Workflow (Auto Mode)

You: "Add refund support to src/legacy/payment-processor.js"
Claude Code: Reading src/legacy/payment-processor.js...
[Calling vokt_modify_start]
file_path: "src/legacy/payment-processor.js"
use_context: true
[File has no spec - cold-start kicks in]
Analyzing existing code...
Found payment processor with:
- Stripe integration (API v1)
- USD only
- Max transaction: $10,000
- Card validation before charge
- No refund support currently
Generated baseline spec: payment_processor_spec.json v1
Now adding refund functionality...
Added full refund support
Added partial refund logic
Added refund validation
[Calling vokt_modify_complete]
change_description: "Added refund support"
Updated spec to v2
Generated 15 tests covering:
- Full refund scenarios (5 tests)
- Partial refund scenarios (4 tests)
- Validation edge cases (3 tests)
- Error handling (3 tests)
Saved to: tests/generated/payment_processor.spec.js
You: "Ship it!"
[You shipped on time]
[payment-processor.js now has specs + 15 tests]
[Can safely modify it in the future]

Key Outcomes

  • Shipped on time - No stopping work to add tests
  • Built quality - Specs + tests generated automatically
  • Documented behavior - Spec shows "Stripe v1, USD only, $10k max"
  • Safe for next time - Future changes check against spec
  • 1 of 500 files - Covered the one you touched (0.2% → 100% on that file)

This is the Vokt approach: Build quality where you work.

2. The 80/20 Rule in Action

Scenario

Legacy 50,000 line codebase. Team of 3 developers. 6 months of feature work.

Reality: 20% of code changes 80% of the time.

Vokt Strategy: Build specs + tests for the 20% you actually touch.

Month-by-Month Progression

Month 1: Payment Features

Team touches:

  • payment-processor.js (add refunds)
  • stripe-gateway.js (update API version)

Vokt auto-generates:

  • 2 specs documenting existing + new behavior
  • 27 tests covering edge cases

Coverage: 2/500 files (0.4%)

But these are the files you modify monthly!

Month 2: Authentication Updates

Team touches:

  • auth-middleware.js (add 2FA)
  • jwt-validator.js (add refresh tokens)
  • session-manager.js (extend timeout)

Vokt auto-generates:

  • 3 specs documenting existing + new behavior
  • 34 tests covering edge cases

Coverage: 5/500 files (1%)

These files change every sprint.

Month 3: User Management

Team touches:

  • user-service.js (add soft delete)
  • permissions.js (add role inheritance)

Vokt auto-generates:

  • 2 specs documenting existing + new behavior
  • 18 tests covering edge cases

Coverage: 7/500 files (1.4%)

Month 6: The Result

Total files touched: 15/500 (3%)

Files with full specs + tests: 15 (100% of touched files)

Total tests: 143 auto-generated

Files never touched: 485 (97% - still no tests, and that's FINE)

The critical 3% now has:

  • ✅ Full specification documentation
  • ✅ Comprehensive test coverage
  • ✅ Version history explaining changes
  • ✅ Drift protection enabled

The Reality Check

❌ Old approach: "We need to add tests to 50,000 lines!"

  • • Time: 6 months
  • • Cost: 3 developers full-time
  • • Result: Never happens

✅ Vokt approach: "We'll add tests to code we touch"

  • • Time: 0 extra (built while shipping)
  • • Cost: Free
  • • Result: Critical 3% has enterprise-grade quality

The 97% with no tests? Hasn't been touched in years. Doesn't need tests.

3. Catching Security Vulnerabilities

Scenario

Claude Code is refactoring your authentication middleware. It accidentally removes the rate limiting check. Vokt catches it before you even commit.

❌ Without Vokt:

Security regression ships to production. Hackers find it in hours. You spend the weekend firefighting.

✅ With Vokt:

Vokt detects spec violation immediately. Claude fixes it. You never even notice.

The silent failure mode:

Tests passed. CI was green. But rate limiting was removed. This is a semantic regression — the kind that ships to production undetected.

Workflow Example

You: "Refactor auth middleware to use async/await"
Claude Code: Reading src/middleware/auth.js...
[Calling vokt_modify_start]
file_path: "src/middleware/auth.js"
use_context: true
Found existing spec: auth_middleware_spec.json v3
Constraints to preserve:
- Rate limiting (100 req/min per IP)
- JWT validation
- Session check
- CORS headers
Converting callbacks to async/await...
Converted token validation
Converted session lookup
Simplified error handling
[Calling vokt_modify_complete]
change_description: "Refactored to async/await"
Running spec validation...
⚠️ SPEC VIOLATION DETECTED
File: src/middleware/auth.js
Spec: auth_middleware_spec.json v3
Violation:
REMOVED: Rate limiting (max 100 req/min per IP)
This is a CRITICAL security requirement
Original spec (v3) required:
✓ JWT validation
✓ Session check
✗ Rate limiting (MISSING)
✓ CORS headers
Claude Code: Oops! Let me fix that...
Re-adding rate limiting...
Rate limiter restored (async version)
Re-validating against spec...
All spec requirements met
Updated spec to v4:
Changed: Async/await pattern (was callbacks)
Preserved: Rate limiting (100 req/min)
Preserved: JWT + session validation
You: "*sleep soundly*"
[Security vulnerability prevented]

Key Outcomes

  • Security guardrail - Spec caught critical requirement removal
  • Self-healing AI - Claude fixed its own mistake automatically
  • Zero human intervention - You never saw the security bug
  • Documented constraints - Rate limiting now explicit in spec
  • Safe refactoring - Implementation changed, behavior preserved

Vokt is your safety net when AI refactors critical code.

4. Living Documentation

Scenario

New developer joins your team. Asks: "How does the payment processor work?" You point them to the spec file. It's always accurate because it's enforced by Vokt.

❌ Traditional docs:

README says "Supports Stripe v1". Code uses Stripe v3. Doc is 2 years stale. New dev gets confused.

✅ Vokt docs:

Spec file is generated from code and enforced on every change. Always accurate. Always up to date.

Workflow Example

New Dev: "Where's the documentation for payment processing?"
You: "Check .vokt/specs/payment_processor_spec.json"
New Dev: *opens spec file*
# Payment Processor Specification v2
# Auto-generated by Vokt on 2024-03-15
# Last updated: 2024-03-20 (refund support added)
integration:
provider: Stripe
api_version: v1
mode: live (production), test (development)
supported_operations:
- charge (single payment)
- refund_full (100% refund)
- refund_partial (custom amount)
constraints:
currency: USD only
max_transaction: $10,000
min_transaction: $0.50
refund_window: 180 days
validation_rules:
- Card validation before charge
- Amount must be positive integer (cents)
- Refund cannot exceed original charge
error_handling:
- Invalid card → PaymentError with card decline reason
- Network failure → Retry 3 times with exponential backoff
- Duplicate charge → Return existing transaction ID
New Dev: "Nice! This is super clear. When was this written?"
You: "It wasn't written. Vokt generated it from the code."
New Dev: "How do I know it's accurate?"
You: "Vokt enforces it. If code drifts from spec, build fails."
New Dev: "So this is like executable documentation?"
You: "Exactly. It can't go stale. Try changing the code without updating the spec."
New Dev: *makes test change*
Vokt: ⚠️ Spec violation detected. Run 'vokt update' to sync.
New Dev: "Okay, I'm sold."

Why This Matters

  • Always accurate - Spec enforced on every code change
  • Zero maintenance - Auto-generated, auto-updated
  • Onboarding is instant - New devs read specs, understand system
  • Human-readable - YAML format, not cryptic code comments
  • AI-friendly - Claude reads specs before making changes

Documentation that can't lie to you.

5. Team Inheritance Scenario

Scenario

Sarah wrote the email service 3 years ago. She left the company. Now you need to add SMS support. Vokt has the complete behavioral contract she left behind.

❌ Without Vokt:

Spend 2 days reading code, guessing what's safe to change. Break retry logic accidentally. Users complain.

✅ With Vokt:

Read spec in 5 minutes. Understand all requirements. Add SMS without breaking email. Ship confidently.

Workflow Example

You: "Add SMS support to notification service"
Claude Code: Reading src/services/notifications.js...
Found existing spec: notification_service_spec.json v5
Current Behavior (from spec v5):
Email Provider: SendGrid
Retry Logic: 3 attempts, exponential backoff (1s, 2s, 4s)
Failure Handling: Log to Sentry, don't throw
Rate Limiting: 100 emails/min
Template Engine: Handlebars
Required Fields: to, subject, body
Note from spec:
"Retry logic is CRITICAL. Don't remove it."
"Template engine switched from EJS to Handlebars in v3"
"Rate limiting added in v4 after SendGrid ban incident"
Claude Code: Now adding SMS support...
Added Twilio SMS provider
Applied same retry logic (3 attempts)
Added SMS rate limiting (50/min per Twilio limits)
Preserved email behavior (no changes)
Updated spec to v6:
ADDED:
SMS Provider: Twilio
SMS Rate Limit: 50/min
SMS Required Fields: to (phone), body
PRESERVED:
Email retry logic (unchanged)
Email rate limiting (unchanged)
Template engine (still Handlebars)
Generated 12 new SMS tests
All 24 existing email tests still pass
You: "Perfect! Did we break anything?"
Claude Code:
All email tests passing (24/24)
All SMS tests passing (12/12)
Spec validation passed
No regressions detected
[Sarah's email code is untouched and working]
[SMS support added safely]
[Future developers will inherit both specs]

Key Outcomes

  • Understood legacy behavior - Spec showed retry logic, rate limits, critical notes
  • No regression - Email code preserved, all tests still pass
  • Consistent patterns - SMS inherited same retry/rate-limiting approach
  • Knowledge transfer - Sarah's decisions documented in spec forever
  • Future-proof - Next dev will inherit v6 spec with both email + SMS

Specs are the institutional memory of your codebase.

6. Understanding Complex Modules

Scenario

You're assigned to optimize the authentication system. It spans 8 files across 3 directories. You need to understand how it all fits together before making changes.

❌ Without Vokt:

Open 8 files in tabs. Manually trace function calls. Miss a dependency. Break something unexpected.

✅ With Vokt:

Vokt resolves dependencies, shows relationships, synthesizes module-level view. Understand in minutes.

Context-Aware Analysis

You: "Help me understand the auth module architecture"
Claude Code: Analyzing lib/auth/middleware.js with full context...
[Calling vokt_modify_start]
file_path: "lib/auth/middleware.js"
format: "yaml"
use_context: true
Resolving dependencies (depth: 2)...
Loading contracts from:
- lib/auth/jwt.js
- lib/auth/session.js
- lib/auth/permissions.js
- lib/users/service.js (caller)
- lib/api/routes.js (caller)
Dependency Graph:
  routes.js ──┐
              ├──▶ middleware.js ──┬──▶ jwt.js
  users.js ───┘                    ├──▶ session.js
                                   └──▶ permissions.js
Cross-Module Contracts:
jwt.js exports: validateToken(token) → User | null
session.js exports: getSession(id) → Session
permissions.js exports: checkPermission(user, action) → boolean
You: "Can you give me a module-level view?"
Claude Code: Synthesizing module spec...
$ vokt synthesize-module auth --verbose
Discovering files in auth module...
Found 8 files
Aggregating function-level specs...
Creating module contracts...
Generated .vokt/specs/modules/auth.yaml
Module: Authentication
─────────────────────
Responsibilities:
- JWT token validation and refresh
- Session management (Redis-backed)
- Permission checking (RBAC)
Public Interface:
- authenticate(req) → User | Error
- authorize(user, permission) → boolean
- refreshToken(token) → newToken
External Dependencies:
- Redis (session store)
- users module (user lookup)
Invariants:
- All routes require authentication except /login, /register
- Token expiry: 15 minutes, refresh: 7 days
- Rate limit: 5 failed attempts → 15 min lockout
🔧Under the Hood
Claude called: vokt_modify_start
With: {
file_path: "lib/auth/middleware.js",
use_context: true,
}
💻CLI Alternative

If using Vokt without Claude Code:

# Generate spec with dependency context
$ vokt generate-context lib/auth/middleware.js --verbose --depth 2
# View the generated spec
$ vokt view .vokt/specs/middleware.yaml --format markdown
# Synthesize module-level spec
$ vokt synthesize-module auth --verbose

Key Outcomes

  • Dependency resolution - Automatically traced all 8 files and their relationships
  • Module contracts - Understood public interface without reading implementation
  • Cross-file awareness - Saw how middleware connects to jwt, session, permissions
  • Invariants documented - Critical rules like rate limiting and token expiry captured
  • Safe to modify - Now know exactly what can change vs. what must be preserved

Understand complex systems in minutes, not days.

7. New Feature Development

Scenario

You're building a brand new API endpoint. Vokt guides you through creating specs first, then implementing with AI, then generating tests. True spec-driven development.

❌ Traditional flow:

Write code, realize you forgot edge cases, add them, tests break, fix tests. Messy iteration.

✅ Vokt guided:

Define behavior spec, Claude implements it, tests auto-generated, all edge cases covered upfront.

Guided Spec Creation

You: "Create new endpoint: POST /api/subscriptions"
Vokt: Let's define the behavior first!
Starting guided spec creation...
What should this endpoint do?
You: "Create monthly subscriptions with Stripe integration"
Vokt: Great! Let me ask some questions...
1. What data is required?
You: "email, plan_id, payment_method_id"
2. What plans are supported?
You: "basic ($10/mo), pro ($30/mo), enterprise ($100/mo)"
3. What should happen if payment fails?
You: "Return 402 with error details, don't create subscription"
4. What about duplicate subscriptions?
You: "Check if email already has active subscription. Return 409 if yes."
[Calling vokt_create]
file_path: "lib/api/subscriptions.js"
description: "POST /api/subscriptions - Create monthly subscription with Stripe"
module: "billing"
Vokt: Generated spec draft:
endpoint:
POST /api/subscriptions
auth:
Required (JWT)
input:
email: string (required, valid email format)
plan_id: enum [basic, pro, enterprise]
payment_method_id: string (Stripe PM ID)
behavior:
1. Validate email format
2. Check for existing active subscription → 409 if exists
3. Charge via Stripe ($10/$30/$100 based on plan)
4. If payment fails → 402 with error, no subscription
5. If payment succeeds → Create subscription, return 201
success_response:
201 + {id, email, plan, status, next_billing_date}
error_responses:
400: Invalid input
401: Missing/invalid JWT
402: Payment failed
409: Duplicate subscription
Vokt: Does this look correct?
You: "Yes, implement it!"
Claude Code: Implementing from spec...
Created route handler
Added input validation
Added duplicate check
Integrated Stripe payment
Added error handling
[Calling vokt_create_complete]
file_path: "lib/api/subscriptions.js"
module: "billing"
Linked spec to implementation
Updated links.json
[Calling generate_tests]
framework: "jest"
Generated 18 tests covering:
- Happy path (3 plans × success) = 3 tests
- Validation errors = 5 tests
- Payment failures = 4 tests
- Duplicate subscription = 2 tests
- Auth failures = 2 tests
- Edge cases = 2 tests
All 18 tests passing
Spec saved: subscriptions_api_spec.json v1
[Feature complete with full test coverage]
🔧Under the Hood
Claude called: vokt_create → vokt_create_complete → generate_tests
With: {
workflow: "spec-first development",
output: "spec + implementation + tests",
}

Key Outcomes

  • Spec-driven development - Defined behavior before writing code
  • All edge cases upfront - Duplicate check, payment failures covered in spec
  • Complete test coverage - 18 tests generated from spec automatically
  • Clear API contract - Spec documents all inputs, outputs, error codes
  • Future-proof - Next dev reads spec, understands complete behavior

Think about behavior first. Let AI handle the implementation.

8. Handling Drift Conflicts

Scenario

Your teammate merged a hotfix directly to production, bypassing CI/CD. Now the code and spec are out of sync. Vokt detects it and helps you resolve the conflict intelligently.

❌ Without Vokt:

Silent drift. Production code differs from repo. Tests pass locally, fail in prod. Mystery bugs.

✅ With Vokt:

Drift detected immediately. Vokt shows exact differences. You choose: update spec or revert code.

Workflow Example

You: "Deploy latest changes"
Vokt: Running pre-deploy validation...
⚠️ DRIFT DETECTED
File: src/api/orders.js
Spec: orders_api_spec.json v3
Production code has changes not in spec:
What changed:
+ Added field: "priority" (enum: normal, urgent)
+ Urgent orders skip fraud check for speed
- Removed: Fraud check for all orders
Last modified: 2024-03-20 11pm by alex@company.com
Git commit: HOTFIX: urgent order support (merged to prod)
⚠️ This is a SECURITY change (fraud check removed)
Vokt: What should I do?
1. Update spec to match new code (accept hotfix)
2. Revert code to match spec (reject hotfix)
3. Show me the full diff first
You: "Show me the diff"
Vokt:
Spec v3 (last known good):
1. Validate order data
2. Run fraud check (ALWAYS)
3. Process payment
4. Create order record
Production code (current):
1. Validate order data
2. Check if priority === 'urgent'
3. Skip fraud check if urgent
4. Run fraud check only for normal orders
5. Process payment
6. Create order record
You: "That's a security issue. Revert the code."
Vokt: Reverting to spec v3...
Restored fraud check for ALL orders
Removed priority field
Code now matches spec v3
Created revert commit: "Revert unsafe hotfix, restore fraud check"
You: "Thanks. Now let's add urgent support the RIGHT way."
You: "Add priority field, but keep fraud check for all orders."
Claude Code:
Added priority field (normal, urgent)
Urgent orders get priority queue processing
Fraud check STILL runs for all orders
Updated spec to v4:
ADDED: priority field (doesn't skip security)
PRESERVED: Fraud check (ALWAYS runs)
[Security preserved, feature added safely]

What this looks like in a PR

SF
voktbot
1 behavior change
CriticalFraud Check Removed
-Run fraud check (ALWAYS)
+Skip fraud check if priority === 'urgent'

This is what appears in every PR when Vokt detects behavior changes.

💻CLI Alternative

If using Vokt without Claude Code:

# Check for drift after editing
$ vokt drift check .vokt/specs/orders.yaml "Added priority field"
# Resolve drift interactively
$ vokt drift resolve .vokt/specs/orders.yaml
# Or accept as intentional change
$ vokt drift accept .vokt/specs/orders.yaml --reason "Approved by security team"

Key Outcomes

  • Drift detected immediately - Production hotfix caught before it spread
  • Security preserved - Unsafe fraud check removal caught and reverted
  • Clear diff analysis - Exactly what changed shown side-by-side
  • Safe re-implementation - Feature added properly with security intact
  • Spec as source of truth - When conflict arose, spec won

Vokt prevents spec drift from becoming production disasters.

9. End of Sprint Cleanup

Scenario

It's Friday. Your team shipped 12 PRs this week. Before you leave, you want to review what Vokt caught and ensure everything is clean.

❌ Without Vokt:

Hope nothing broke. Check Slack on Saturday for angry messages. Start the weekend anxious.

✅ With Vokt:

Review queue shows exactly what changed. Approve/reject items. Generate report. Leave confident.

Review Queue Management

You: "What needs my attention before the weekend?"
[Calling vokt_review_queue]
severity: "all"
limit: 20
Review Queue (7 items)
──────────────────────
🔴 Critical (1)
└─ orders.js: Fraud check behavior changed (needs approval)
🟡 Minor (4)
├─ auth.js: Added async/await (auto-approved)
├─ users.js: New field added (auto-approved)
├─ payments.js: Error message changed (auto-approved)
└─ api.js: Endpoint renamed (auto-approved)
🟢 Info (2)
├─ utils.js: New helper function (spec generated)
└─ config.js: New env variable (spec updated)
You: "Approve the orders.js change - we discussed it in standup"
Claude Code:
$ vokt review approve orders-fraud-check-001 \
--reason "Approved in standup - business requirement"
Approved. Spec updated to v4.
You: "Generate a report for the team"
$ vokt report --format markdown --timeframe 7d
📊 Weekly Vokt Report
════════════════════════
Files Modified: 12
Specs Generated: 3 new, 9 updated
Drift Events: 7 (6 auto-resolved, 1 manual)
Test Coverage: +34 tests generated
Top Churn Files:
1. orders.js (4 changes)
2. auth.js (3 changes)
3. payments.js (2 changes)
Risk Assessment:
🟢 Low risk: 10 files
🟡 Medium risk: 2 files (orders.js, auth.js)
🔴 High risk: 0 files
Saved to: .vokt/reports/weekly-2024-03-22.md
You: "Share it in Slack"
Claude Code: Posted to #engineering:
📊 This week: 12 files modified, 34 tests auto-generated,
7 drift events (all resolved). Top churn: orders.js.
Full report: .vokt/reports/weekly-2024-03-22.md
[Enjoy your weekend!]
💻CLI Alternative

If using Vokt without Claude Code:

# View review queue
$ vokt review
# Approve an item
$ vokt review approve <item-id> --reason "Business requirement"
# Reject an item
$ vokt review reject <item-id> --reason "Not applicable"
# Generate weekly report
$ vokt report --format markdown --timeframe 7d
# Generate HTML dashboard
$ vokt report --format html --timeframe 30d

Key Outcomes

  • Complete visibility - Saw all 7 spec changes from the week at a glance
  • Prioritized review - Critical items surfaced first, minor auto-approved
  • Audit trail - Approval reasons documented for compliance
  • Team communication - Weekly report shared with engineering team
  • Risk awareness - High-churn files identified for extra attention

Leave for the weekend knowing exactly what changed and why.

10. Preparing for Audit

Scenario

Your company is undergoing SOC2 audit. Auditors want documentation of your payment processing system's behavior. You have 2 hours.

❌ Without Vokt:

Scramble to write docs. Copy-paste from code comments. Hope it's accurate. Auditor finds inconsistencies.

✅ With Vokt:

Export specs as documentation. Generate compliance report. Everything matches code. Auditor impressed.

Documentation Export

You: "Export all payment-related specs as documentation"
Claude Code:
$ vokt export --verbose
Exporting specs to docs/specs/...
docs/specs/README.md (index)
docs/specs/payments/processor.md
docs/specs/payments/refunds.md
docs/specs/payments/stripe-gateway.md
docs/specs/billing/subscriptions.md
Skipped (unchanged - SHA256 match):
- docs/specs/auth/middleware.md
- docs/specs/auth/jwt.md
5 files written, 2 skipped
You: "Perfect. Also generate an HTML report showing our quality metrics"
$ vokt report --format html --timeframe 90d
Generated .vokt/reports/q1-2024.html
Opening in browser...
Dashboard Contents:
📈 Drift Timeline Graph
Shows all behavior changes over 90 days
📊 File Stability Scores
payments/processor.js: 94% stable
auth/middleware.js: 87% stable
🏥 Module Health Overview
payments: 🟢 Healthy (12 specs, 89 tests)
auth: 🟢 Healthy (8 specs, 67 tests)
billing: 🟡 Moderate (5 specs, 34 tests)
⚠️ Risk Predictions
No high-risk files detected
Auditor: "This is exactly what we needed. When was this documentation written?"
You: "It wasn't written. It's generated from the code and enforced on every change."
Auditor: "So this documentation can't be out of sync with the code?"
You: "Correct. If code changes, spec must update or CI fails."
Auditor: "That's... actually impressive. Most companies can't show this."
[Audit passed. Documentation always accurate.]
💻CLI Alternative

If using Vokt without Claude Code:

# Export specs as markdown documentation
$ vokt export --verbose
# Force re-export all files (ignore SHA256 cache)
$ vokt export --force --verbose
# Generate HTML report for last 90 days
$ vokt report --format html --timeframe 90d
# Generate JSON report for CI/CD integration
$ vokt report --format json --output reports/vokt.json

What Gets Exported

docs/specs/
├── README.md # Index of all specs
├── payments/
├── processor.md # Payment processor spec
├── refunds.md
└── stripe-gateway.md
├── auth/
├── middleware.md
└── jwt.md
└── billing/
└── subscriptions.md

Each markdown file contains the full spec: functions, constraints, invariants, and version history.

Key Outcomes

  • Instant documentation - Exported 5 spec files in seconds, not hours
  • Always accurate - Generated from code, enforced on every change
  • Incremental updates - SHA256 comparison skips unchanged files
  • Audit-ready - HTML dashboard shows quality metrics and history
  • Compliance proof - Auditor verified docs can't drift from code

Documentation that proves itself accurate.

Summary: The Vokt Philosophy

What We've Learned

Vokt transforms how you work with legacy code and AI assistants. Instead of choosing between shipping fast and building quality, you get both.

Why existing tools miss semantic regressions

ToolValidatesMisses
TestsKnown scenariosUnknown behavior changes
Code reviewImplementationSystem-level effects
QAUser pathsHidden business logic
VoktSystem behavior

For Legacy Code

  • Build quality incrementally as you ship
  • Focus on the 20% of code you actually touch
  • Never write tests for dormant files
  • Specs auto-generate on first touch

For AI Safety

  • Catch AI mistakes before commit
  • Detect security regressions automatically
  • Self-healing when spec violations occur
  • Specs guide Claude's code generation

For Documentation

  • Living docs that can't go stale
  • Zero-maintenance specification
  • Instant onboarding for new developers
  • Institutional memory preserved forever

For Teams

  • Inherit knowledge from departed developers
  • Prevent drift from hotfixes
  • Consistent patterns across codebase
  • Spec-driven development for new features

The Core Principle

Don't boil the ocean. Build quality where you work.

Vokt meets you where you are: shipping features on legacy code with AI assistance. It doesn't force you to stop and write tests. It builds them automatically as you work, making your codebase better with every change.

Next Steps

Ready to try Vokt?

1

Install Vokt

Follow the Quick Start Guide to set up Vokt in your project

2

Pick one file to start

Don't try to spec your entire codebase. Start with one file you're actively working on

3

Enable Auto Mode

Let Vokt generate specs automatically as Claude Code makes changes

4

Ship with confidence

Watch as specs and tests build up organically, file by file, as you ship features