Pipeline-Go Methodology¶
Pipeline-Go is the development methodology built into F3L1X. It's a framework for AI-assisted software development that emphasizes planning, testing, and context preservation.
Philosophy¶
"Imagine you took the best software studio and gave them the latest technology and said 'go' - this is what that would be."
Pipeline-Go treats AI development sessions like professional software engineering:
- Every session is documented
- Every feature follows a process
- Every issue is tracked
- Every handoff preserves context
Core Principles¶
1. Test-Driven Development (TDD)¶
Pipeline-Go encourages writing tests before code:
┌─────────────────────────────────────────┐
│ TDD Cycle │
│ │
│ ┌─────────┐ │
│ │ RED │ Write failing test │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ GREEN │ Write minimal code │
│ └────┬────┘ to pass │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │REFACTOR │ Clean up, optimize │
│ └────┬────┘ │
│ │ │
│ └──────► Commit │
│ │
└─────────────────────────────────────────┘
The TDD Flow:
1. Write a test that describes what you want
2. Run it - it fails (RED)
3. Write the simplest code to make it pass (GREEN)
4. Clean up the code (REFACTOR)
5. Commit your changes
2. Activity Logging¶
Every session should be documented:
## Session Summary
### What Happened
1. Implemented user authentication
2. Added login endpoint
3. Created logout functionality
4. Fixed security issue
### Files Modified
- Authentication views
- Token services
- Test suite
### Next Steps
- Add rate limiting
- Implement password reset
This ensures you never lose track of what was accomplished.
3. Blocker Tracking¶
Blockers are unfinished tasks that prevent progress:
| Priority | Blocker | Status |
|---|---|---|
| High | Need API credentials | Waiting |
| Medium | Documentation incomplete | In Progress |
| Low | Could add pagination | Backlog |
Blocker Rules:
- Unchecked items become blockers
- Blockers are tracked across sessions
- Blockers must be resolved or documented
4. Context Preservation¶
Sessions must preserve context for future work:
┌─────────────────────────────────────────┐
│ Session Lifecycle │
│ │
│ START │
│ │ │
│ ▼ │
│ "hello f3l1x" ─────► Check blockers │
│ │ Show last session │
│ │ Suggest next step │
│ ▼ │
│ WORK │
│ │ │
│ ▼ │
│ END │
│ │ │
│ ▼ │
│ /cya ────────────► Log activity │
│ Capture blockers │
│ Generate handoff │
│ │
└─────────────────────────────────────────┘
Using Pipeline-Go¶
Starting a Session¶
Always begin with the greeting:
hello f3l1x
This triggers:
1. Service status check
2. Blocker display
3. Last session summary
4. Next action suggestion
During Development¶
When implementing features, Pipeline-Go encourages:
- Plan - Create a specification first
- Test - Write failing tests
- Implement - Write minimal code to pass
- Refactor - Clean up the implementation
- Document - Update activity log
Ending a Session¶
Before closing:
/cya
This captures:
- Session summary
- Files modified
- Blockers encountered
- Next steps for future sessions
The Three-File System¶
Pipeline-Go uses three key files:
1. Configuration File¶
The project's "brain" - contains project context and guidelines:
# Project Name
## Overview
What this project does
## Development Guidelines
How to work in this project
## Key Commands
Important commands to remember
2. Specification File¶
Feature blueprint - created before implementing:
# Feature: User Authentication
## Requirements
- Users can login with email/password
- Tokens issued on successful auth
- Tokens valid for limited time
## Technical Approach
1. Create login endpoint
2. Implement token handling
3. Add validation
## Test Cases
- Valid login returns token
- Invalid password returns error
- Expired token rejected
3. Activity Log¶
Session history - updated at end of each session:
# Activity Log
## Session 3 - Authentication
[Details...]
## Session 2 - Database Setup
[Details...]
## Session 1 - Project Init
[Details...]
Pipeline-Go Commands¶
| Command | Purpose |
|---|---|
hello f3l1x |
Start session, check status |
/cya |
End session, capture context |
/tests |
Run test suite |
/sync |
Sync configuration files |
Best Practices¶
1. Don't Skip the Greeting¶
# Start every session properly
hello f3l1x
# See blockers and context, then work
2. Plan Before Coding¶
# Create a spec first
# Think through the approach
# Then implement
3. Test First¶
Write tests before implementation to clarify requirements.
4. Log Everything Important¶
Document technical decisions, not just what changed.
5. Never Leave Blockers Undocumented¶
If you can't finish something, document it as a blocker.
Common Patterns¶
Feature Implementation Pattern¶
1. hello f3l1x # Check status
2. Create spec # Plan feature
3. Write tests # TDD - RED
4. Implement # TDD - GREEN
5. Refactor # TDD - REFACTOR
6. Update log # Document
7. /cya # Handoff
Bug Fix Pattern¶
1. hello f3l1x # Check context
2. Write failing test # Reproduce bug
3. Fix code # Make test pass
4. Verify no regressions
5. Update log # Document fix
6. /cya # Handoff
Research Pattern¶
1. hello f3l1x # Check status
2. Document findings # In docs folder
3. Update config # Add new knowledge
4. Update log # Document research
5. /cya # Handoff
Benefits of Pipeline-Go¶
For Solo Developers¶
- Never lose context between sessions
- Always know what to work on next
- Track all unfinished work
For Teams¶
- Consistent development practices
- Clear handoff between team members
- Auditable development history
For AI-Assisted Development¶
- AI agents understand the methodology
- Context preservation across sessions
- Structured approach to complex tasks
Next Steps¶
- Understanding Realms - Learn about F3L1X components
- Herald Network - Inter-realm communication
- CLI Commands - Command reference