Rendered from docs/PROJECT_OPERATING_MANUAL.md
Project Operating Manual
This manual defines the long-term development workflow for Ron Lavis' current and future projects.
Mission
Maintain a private Developer Hub that serves as the permanent source of truth for project documentation, architecture, project status, release history, decisions, prompts, diagnostics, and future automation.
Roles
Ron
- Product Owner
- Tester
- Final approval authority
- Defines goals, acceptance criteria, and business priorities
- Confirms when a task is complete
ChatGPT
- Architect
- Planner
- Design reviewer
- Workflow advisor
- Converts goals into implementation plans and review checklists
- Helps keep decisions consistent with long-term product direction
Codex
- Implementation engineer
- Refactoring agent
- Testing agent
- Documentation updater
- Commits completed work
- Keeps repository documentation synchronized with implementation changes
Standard Development Workflow
- Ron defines the goal.
- ChatGPT designs the solution.
- Codex implements the change.
- Codex updates documentation.
- Ron tests the result.
- ChatGPT reviews the outcome.
- The repository becomes the source of truth.
Source-of-Truth Rule
Never rely on chat history as permanent memory. If information matters beyond the current conversation, document it in this repository.
Project Modes
Active Development
Use this mode when a project is evolving.
Allowed work:
- new features
- architecture changes
- roadmap updates
- maintenance updates
- documentation improvements
Maintenance Mode
Use this mode when a project is stable and should change carefully.
Allowed work:
- bug fixes
- documentation improvements
- performance improvements
- explicitly approved feature work only
Archived
Use this mode when a project is reference-only.
Allowed work:
- documentation corrections
- historical reference updates
- no active implementation work unless the project is reactivated
Current Project States
| Project | State | Notes |
|---|---|---|
| Goblin Farmer V2 | Maintenance Mode | Stable Diablo III automation application. Primary future purpose is goblin statistics tracking. Do not plan additional feature development unless explicitly requested. |
| Season Helper | Active Development | Primary development focus. |
Documentation Expectations
Codex should update documentation when a task changes:
- project status
- architecture
- roadmap
- release history
- decisions
- testing instructions
- diagnostics
- task templates
Commit Expectations
Each completed implementation task should end with:
- validated links or tests when practical
- updated documentation
- a clear git commit
- a clean working tree unless there is a documented reason