Skip to main content

Reality-First Development Protocol - Prevents AI hallucination and ensures spec-driven development

Project description

RFD Protocol

Reality-First Development - Prevents AI hallucination and ensures spec-driven development

CI Pipeline Release Pipeline PyPI version Python 3.8+ License: MIT

What is RFD?

RFD (Reality-First Development) is a protocol that eliminates AI hallucination in software development by enforcing concrete reality checkpoints. Instead of trusting AI claims about what was implemented, RFD validates that code actually runs, tests pass, and features work.

Core Benefits

  • ๐ŸŽฏ Prevents AI Hallucination: Drops error rate from 48% to ~0%
  • ๐Ÿ“‹ Spec-Driven Development: Features must be specified before implementation
  • โœ… Reality Checkpoints: Every change is validated against working code
  • ๐Ÿ”„ Session Persistence: Context maintained across Claude Code sessions
  • ๐ŸŒ Universal Drop-in: Works with any tech stack (25+ languages)

Quick Start

Installation

Option 1: Via pip (Recommended)

pip install rfd

Option 2: From source

git clone https://github.com/rfd-protocol/rfd.git
cd rfd
pip install -e .

Initialize in Your Project

For a new project:

mkdir my-project && cd my-project
rfd init

For an existing project:

cd your-existing-project/
rfd init

This creates:

  • PROJECT.md - Your project specification
  • CLAUDE.md - Claude Code integration config
  • PROGRESS.md - Build progress tracking
  • .rfd/ - RFD system directory

Basic Workflow

  1. Define specifications first:

    rfd spec create
    
  2. Start feature development:

    rfd session start user_auth
    
  3. Build and validate continuously:

    rfd build
    rfd validate
    
  4. Save working checkpoints:

    rfd checkpoint "User auth working"
    

Project Architecture

Our repository follows modern Python packaging standards with a clear separation of concerns:

rfd-protocol/
โ”œโ”€โ”€ README.md                  # This file
โ”œโ”€โ”€ PROJECT.md                 # Project specification
โ”œโ”€โ”€ pyproject.toml            # Modern Python packaging config
โ”œโ”€โ”€ requirements.txt          # Runtime dependencies
โ”‚
โ”œโ”€โ”€ src/rfd/                  # ๐ŸŽฏ MAIN PACKAGE (modern Python layout)
โ”‚   โ”œโ”€โ”€ __init__.py          # Package entry point, version info
โ”‚   โ”œโ”€โ”€ cli.py               # Command-line interface
โ”‚   โ”œโ”€โ”€ rfd.py              # Core RFD orchestration class
โ”‚   โ”œโ”€โ”€ validation.py       # AI hallucination detection engine
โ”‚   โ”œโ”€โ”€ session.py          # Session management & persistence
โ”‚   โ”œโ”€โ”€ build.py            # Build automation engine
โ”‚   โ”œโ”€โ”€ spec.py             # Specification management
โ”‚   โ””โ”€โ”€ templates/          # Project templates
โ”‚
โ”œโ”€โ”€ tests/                   # ๐Ÿงช COMPREHENSIVE TEST SUITE
โ”‚   โ”œโ”€โ”€ conftest.py         # Shared pytest fixtures
โ”‚   โ”œโ”€โ”€ unit/               # Fast, isolated tests
โ”‚   โ”œโ”€โ”€ integration/        # Component interaction tests
โ”‚   โ”œโ”€โ”€ system/             # End-to-end workflow tests
โ”‚   โ””โ”€โ”€ fixtures/           # Test data and sample projects
โ”‚
โ”œโ”€โ”€ .rfd/                   # ๐Ÿ›๏ธ LEGACY SYSTEM (for compatibility)
โ”‚   โ”œโ”€โ”€ rfd.py              # Legacy CLI entry point
โ”‚   โ”œโ”€โ”€ validation.py       # Legacy validation engine
โ”‚   โ”œโ”€โ”€ session.py          # Legacy session management
โ”‚   โ”œโ”€โ”€ build.py            # Legacy build engine
โ”‚   โ”œโ”€โ”€ spec.py             # Legacy spec management
โ”‚   โ”œโ”€โ”€ memory.db           # SQLite persistent state
โ”‚   โ””โ”€โ”€ context/            # Session context files
โ”‚
โ”œโ”€โ”€ docs/                   # ๐Ÿ“š DOCUMENTATION
โ”‚   โ”œโ”€โ”€ AGENTS.md           # Agent orchestration definitions
โ”‚   โ”œโ”€โ”€ CLAUDE.md           # Claude Code CLI configuration
โ”‚   โ”œโ”€โ”€ INSTALL.md          # Installation instructions
โ”‚   โ”œโ”€โ”€ RFD-PROTOCOL.md     # Core protocol specification
โ”‚   โ”œโ”€โ”€ @RFD-PROTOCOL.md    # Protocol summary
โ”‚   โ”œโ”€โ”€ RFD-PLAN.md         # Development roadmap
โ”‚   โ””โ”€โ”€ archive/            # Historical documents
โ”‚
โ”œโ”€โ”€ tools/                  # ๐Ÿ”ง DEVELOPMENT TOOLS
โ”‚   โ”œโ”€โ”€ comprehensive_audit.py    # Codebase audit tool
โ”‚   โ””โ”€โ”€ detailed_bug_analysis.py  # Bug analysis tool
โ”‚
โ”œโ”€โ”€ research/               # ๐Ÿ“– RESEARCH & BACKGROUND
โ”‚   โ”œโ”€โ”€ brain-dump.md       # Original problem statement
โ”‚   โ”œโ”€โ”€ CONSENSUS-FINAL.md  # Design decisions
โ”‚   โ””โ”€โ”€ round-*/            # Development phases
โ”‚
โ”œโ”€โ”€ scripts/                # ๐Ÿ“œ LEGACY SCRIPTS
โ”‚   โ””โ”€โ”€ [legacy tools]      # Historical development scripts
โ”‚
โ”œโ”€โ”€ nexus_rfd_protocol/     # ๐Ÿ”„ TRANSITION PACKAGE
โ”‚   โ””โ”€โ”€ [legacy modules]    # Old package structure (being phased out)
โ”‚
โ”œโ”€โ”€ .github/workflows/      # ๐Ÿš€ CI/CD PIPELINE
โ”‚   โ”œโ”€โ”€ ci.yml             # Continuous integration
โ”‚   โ””โ”€โ”€ release.yml        # Automated releases
โ”‚
โ””โ”€โ”€ rfd -> .rfd/rfd.py     # ๐Ÿ”— SYMLINK (legacy compatibility)

Directory Purposes

Core Directories

  • src/rfd/: Modern Python package following PEP standards. This is the main codebase.
  • tests/: Comprehensive test suite with 90+ test functions across unit/integration/system categories.
  • .rfd/: Legacy system directory for backward compatibility. Contains working database and CLI.

Documentation Directories

  • docs/: Essential documentation and specifications.
  • docs/archive/: Historical documents from development phases.
  • research/: Background research and design decisions.

Development Directories

  • tools/: Development and analysis tools.
  • scripts/: Legacy development scripts.
  • .github/workflows/: CI/CD automation.

Transition Directories

  • nexus_rfd_protocol/: Old package structure being phased out.
  • rfd (symlink): Legacy CLI compatibility.

Core Concepts

Reality-First Principles

  1. Code that runs > Perfect architecture
  2. Working features > Planned features
  3. Real data > Mocked responses
  4. Passing tests > Theoretical correctness

Validation Engine

RFD continuously validates:

  • โœ… Files actually exist (detects AI file creation lies)
  • โœ… Functions are implemented (not just claimed)
  • โœ… APIs respond correctly
  • โœ… Tests pass with real data
  • โœ… Build processes work

Session Management

  • Persistent Context: RFD maintains what you're working on across restarts
  • Memory: AI remembers what worked/failed in previous sessions
  • Progress Tracking: Visual progress through complex features
  • Auto-Recovery: Continue from last checkpoint if interrupted

Integration with Claude Code

RFD is designed to work seamlessly with Claude Code:

  1. Install RFD in your project: rfd init
  2. Claude Code reads CLAUDE.md automatically
  3. AI follows RFD workflow - validates every change
  4. Context persists in .rfd/context/memory.json

Example Claude Code Session

# AI automatically follows this workflow:
rfd check                    # Check current status
rfd build                    # Implement features  
rfd validate                 # Verify everything works
rfd checkpoint "Feature X"   # Save progress

Command Reference

Core Commands

rfd init                    # Initialize RFD in current directory
rfd check                   # Quick status check
rfd spec create            # Interactive spec creation
rfd spec review            # Review current specification

Development Workflow

rfd session start <feature>  # Start working on a feature  
rfd build [feature]          # Build/compile feature
rfd validate [--feature X]  # Run validation tests
rfd checkpoint "message"     # Save working state
rfd session end             # Mark feature complete

State Management

rfd revert                  # Revert to last checkpoint
rfd memory show            # Show AI memory
rfd memory reset           # Clear AI memory

Specification Format

RFD uses frontmatter-based PROJECT.md files:

---
version: "1.0"
name: "My API"
stack:
  language: python
  framework: fastapi
  database: sqlite
features:
  - id: user_auth
    description: "User signup and login"
    acceptance: "POST /signup returns 201, POST /login returns token"
    status: pending
rules:
  max_files: 20
  max_loc_per_file: 200
  must_pass_tests: true
---

# My API Project

This API handles user authentication and data management.

Getting Started Guide

For Brand New Projects

  1. Create project directory:

    mkdir my-awesome-project
    cd my-awesome-project
    
  2. Initialize RFD:

    rfd init
    

    This will walk you through:

    • Project name and description
    • Technology stack selection
    • Initial feature definitions
    • Acceptance criteria
  3. Review generated files:

    • PROJECT.md - Your specification
    • CLAUDE.md - AI instructions
    • PROGRESS.md - Progress tracking
  4. Start developing:

    rfd session start <first-feature>
    # Write code...
    rfd build
    rfd validate
    rfd checkpoint "First feature working"
    

For Existing Projects

  1. Add RFD to existing project:

    cd existing-project/
    rfd init
    
  2. RFD will analyze your project:

    • Detect programming language
    • Identify build system
    • Suggest initial feature breakdown
  3. Define what you want to build:

    • Edit generated PROJECT.md
    • Add acceptance criteria for features
    • Set validation rules
  4. Start RFD workflow:

    rfd check                # See current state
    rfd session start <feature>
    # Continue development with RFD validation
    

What You Need to Provide

Minimum Required:

  • Project goal: What are you building?
  • Technology stack: Language, framework, database
  • First feature: What's the first thing you want working?

Recommended:

  • Acceptance criteria: How do you know a feature is done?
  • Validation rules: Max files, complexity limits
  • Test requirements: What tests must pass?

Technology Stack Support

RFD works with any stack by detecting your configuration:

  • Python: FastAPI, Flask, Django, any framework
  • JavaScript/TypeScript: Express, NestJS, Next.js, React, Vue
  • Go: Gin, Echo, standard library
  • Rust: Actix, Rocket, Axum
  • Java/Kotlin: Spring Boot, Quarkus
  • C/C++: Any build system
  • And 20+ more languages...

Development

Running Tests

# All tests
pytest

# By category
pytest -m unit           # Fast unit tests
pytest -m integration    # Integration tests  
pytest -m system         # End-to-end tests

# With coverage
pytest --cov=src/rfd --cov-report=html

Code Quality

# Linting
ruff check src tests

# Formatting
ruff format src tests

# Type checking (optional)
mypy src --ignore-missing-imports

Troubleshooting

Common Issues

"No feature specified"

rfd session start <feature_id>  # Start a session first

"Validation failed"

rfd validate                    # See what's failing
rfd build                       # Fix build issues first

"Lost context"

rfd check                       # See current state
cat .rfd/context/current.md     # Check session file

Debug Mode

export RFD_DEBUG=1
rfd validate                    # Verbose output

Legacy vs Modern CLI

We provide two CLI options:

  • Modern: rfd (via pip install) - Uses src/rfd/ package
  • Legacy: ./rfd or python .rfd/rfd.py - Uses .rfd/ directory

Both provide the same functionality for backward compatibility.

Architecture Decisions

Why Both docs/RFD-PROTOCOL.md and docs/@RFD-PROTOCOL.md?

  • docs/RFD-PROTOCOL.md: Complete protocol specification with all details
  • docs/@RFD-PROTOCOL.md: Summary version for quick reference with @ prefix for Claude Code CLI

Why Keep Legacy .rfd/ Directory?

  • Backward Compatibility: Existing projects using RFD continue working
  • Migration Path: Gradual transition to modern package structure
  • Working Database: Contains SQLite state and session data
  • Symlink Compatibility: Legacy ./rfd command still works

Why Both nexus_rfd_protocol/ and src/rfd/?

  • Transition Period: Moving from old package name to new clean structure
  • Testing: Ensuring both old and new imports work during transition
  • Release Safety: No breaking changes for existing users

Contributing

RFD Protocol is open source. Contributions welcome!

  1. Fork the repository
  2. Create a feature branch
  3. Use RFD to develop your feature ๐Ÿ˜‰
  4. Ensure tests pass: pytest
  5. Submit a pull request

Development Setup

git clone https://github.com/rfd-protocol/rfd.git
cd rfd
pip install -e ".[dev]"
pytest  # Run tests

License

MIT License - see LICENSE file.

Support


Built with RFD Protocol - This project was developed using its own reality-first methodology.

Version History

  • v1.0.0: Production release with modern Python packaging, comprehensive test suite, CI/CD pipeline, and full documentation.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

rfd_protocol-2.0.1.tar.gz (49.1 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

rfd_protocol-2.0.1-py3-none-any.whl (32.5 kB view details)

Uploaded Python 3

File details

Details for the file rfd_protocol-2.0.1.tar.gz.

File metadata

  • Download URL: rfd_protocol-2.0.1.tar.gz
  • Upload date:
  • Size: 49.1 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.11.13

File hashes

Hashes for rfd_protocol-2.0.1.tar.gz
Algorithm Hash digest
SHA256 b009f220426495dfdef67ee1a8df6d7c2484e7f395fd84acb390026907be9791
MD5 34cf54f66184f4cf8e84b079a0442731
BLAKE2b-256 37efa4b772288296125998d65707d186e6c8ffe9cffc8ec45d57e463e1e6c523

See more details on using hashes here.

File details

Details for the file rfd_protocol-2.0.1-py3-none-any.whl.

File metadata

  • Download URL: rfd_protocol-2.0.1-py3-none-any.whl
  • Upload date:
  • Size: 32.5 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.11.13

File hashes

Hashes for rfd_protocol-2.0.1-py3-none-any.whl
Algorithm Hash digest
SHA256 10b63abb6fdc19f9632d26d4708225951e1de7e1688e28c6e2fe283753079a70
MD5 6a63172161d02e571fad81f5ebff5371
BLAKE2b-256 0a6580df2b65ea7ad1a9270e706afb12501812b7e53684d5ba4e5745093fa4dc

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page