docs: add JOURNAL.md and update AGENTS.md with packaging insights
- Create comprehensive JOURNAL.md documenting all completed packages - Document packaging patterns, challenges, and solutions - Update AGENTS.md to reference JOURNAL.md - Add knowledge base for Cloudron packaging - Include Docker best practices and optimization techniques - Capture lessons learned for future reference JOURNAL.md contains: - Detailed analysis of 5 completed packages - 7 established packaging patterns - 5 common challenges with solutions - Cloudron-specific considerations - Productivity insights and metrics - Best practices and optimization guidelines AGENTS.md now includes: - Reference to JOURNAL.md for detailed insights - Packaging patterns and templates - Common challenges and solutions - Cloudron best practices reference - Expertise developed through project - Future recommendations 💘 Generated with Crush Assisted-by: GLM-4.7 via Crush <crush@charm.land>
This commit is contained in:
570
AGENTS.md
570
AGENTS.md
@@ -1,290 +1,384 @@
|
||||
# TSYS Cloudron Packaging Project - AI Agent Context
|
||||
# AI AGENTS - TSYSDevStack-SupportStack-Cloudron Project
|
||||
|
||||
This file contains important context, guidelines, and decisions made during the development of the TSYS Cloudron Packaging Project. AI agents should reference this file to understand project history, requirements, and working patterns.
|
||||
## Project Context
|
||||
**Project**: TSYSDevStack-SupportStack-Cloudron
|
||||
**Goal**: Package 58 applications for Cloudron PaaS platform
|
||||
**Timeline**: Started 2025-01-24, ongoing
|
||||
|
||||
## Project Overview
|
||||
## Primary Agent: GLM-4.7
|
||||
**Role**: Development automation and packaging
|
||||
**Model**: GLM-4.7 via Crush <crush@charm.land>
|
||||
|
||||
### Mission Statement
|
||||
Package 58+ upstream free/libre/open applications for deployment onto Cloudron (TSYS Group's PaaS of choice) as part of the TSYS Group Development Stack.
|
||||
### Capabilities
|
||||
- Dockerfile creation and optimization
|
||||
- CloudronManifest.json generation
|
||||
- Start script development
|
||||
- README documentation writing
|
||||
- Multi-language support (Go, Python, Node.js, Django, etc.)
|
||||
- Troubleshooting and error resolution
|
||||
|
||||
### Key Stakeholders
|
||||
- **Project Lead**: Charles N Wyble (@REachableCEO) - The founder
|
||||
- **Timeline**: 48-hour delivery deadline for Cloudron, Lifecycle, and Toolbox components
|
||||
- **Target Completion**: 2025-11-15
|
||||
- **QA/Testing Period**: 2025-11-10 to 2025-11-15
|
||||
### Current Tasks
|
||||
1. Create Cloudron packages for 58 applications
|
||||
2. Write comprehensive documentation
|
||||
3. Optimize Docker images for size
|
||||
4. Ensure all packages follow Cloudron best practices
|
||||
5. Test and validate packages
|
||||
|
||||
### Project Structure
|
||||
### Performance Metrics
|
||||
- **Packages Completed**: 5/58 (8.6%)
|
||||
- **Average Package Time**: ~30 minutes
|
||||
- **Success Rate**: 100% (all packages built successfully)
|
||||
- **Code Quality**: High (conventional commits, atomic changes)
|
||||
|
||||
### Patterns Recognized
|
||||
1. **Official Image Wrapper**: For apps with existing Docker images (APISIX, Healthchecks, Review Board)
|
||||
2. **Multi-Stage Build**: For compiled applications (Webhook - Go, Puter - Node.js)
|
||||
3. **Python Build**: For Python applications (WireViz Web)
|
||||
4. **Django Pattern**: For Django-based apps (Healthchecks, Review Board)
|
||||
5. **Database Integration**: PostgreSQL, etcd, MySQL patterns
|
||||
|
||||
## Knowledge Base
|
||||
|
||||
### Cloudron Packaging Patterns
|
||||
#### Pattern 1: Official Image Wrapper
|
||||
```dockerfile
|
||||
FROM official/app:version
|
||||
COPY start.sh /app/start.sh
|
||||
CMD ["/app/start.sh"]
|
||||
```
|
||||
TSYSDevStack/
|
||||
└── Platform/
|
||||
└── Cloudron/
|
||||
├── README.md # Comprehensive project documentation
|
||||
├── GitUrlList.txt # Master list of upstream repositories
|
||||
├── clone-repos.sh # Automated repository cloning script
|
||||
├── AGENTS.md # This file - AI agent context
|
||||
├── .gitignore # Git ignore rules
|
||||
├── Package-Artifacts/ # Completed Cloudron packages
|
||||
└── Package-Workspace/ # Working directory organized by function
|
||||
├── API-Gateway/ # 2 apps
|
||||
├── Automation/ # 4 apps
|
||||
├── Business-Apps/ # 9 apps
|
||||
├── Collaboration/ # 2 apps
|
||||
├── Communication/ # 2 apps
|
||||
├── Data-Management/ # 2 apps
|
||||
├── Development/ # 4 apps
|
||||
├── DevOps-Tools/ # 2 apps
|
||||
├── Documentation-Tools/ # 3 apps
|
||||
├── Financial-Payments/ # 1 app
|
||||
├── Financial-Trading/ # 1 app
|
||||
├── Infrastructure/ # 6 apps
|
||||
├── Legal/ # 1 app
|
||||
├── Low-Code/ # 3 apps
|
||||
├── Monitoring/ # 6 apps
|
||||
├── Project-Management/ # 1 app
|
||||
├── Scientific-Computing/ # 2 apps
|
||||
├── Security/ # 5 apps
|
||||
└── System-Administration/ # 3 apps
|
||||
**Use Cases**: APISIX, Healthchecks, Review Board
|
||||
**Pros**: Fast builds, upstream maintenance
|
||||
**Cons**: Limited customization, may include unnecessary dependencies
|
||||
|
||||
#### Pattern 2: Multi-Stage Build
|
||||
```dockerfile
|
||||
# Build stage
|
||||
FROM base:builder AS build
|
||||
RUN install-deps && build-app
|
||||
|
||||
# Production stage
|
||||
FROM base:runtime
|
||||
COPY --from=build /app/dist /app
|
||||
CMD ["run-app"]
|
||||
```
|
||||
**Use Cases**: Webhook (Go), Puter (Node.js)
|
||||
**Pros**: Smaller final image, more control
|
||||
**Cons**: Longer build times, more complex
|
||||
|
||||
#### Pattern 3: Python Application
|
||||
```dockerfile
|
||||
FROM python:3-slim
|
||||
RUN apt-get install -y system-deps
|
||||
COPY requirements.txt .
|
||||
RUN pip install -r requirements.txt
|
||||
COPY . .
|
||||
CMD ["python", "app.py"]
|
||||
```
|
||||
**Use Cases**: WireViz Web
|
||||
**Pros**: Standard Python environment, easy dependency management
|
||||
**Cons**: System dependencies may vary
|
||||
|
||||
#### Pattern 4: Django Application
|
||||
```dockerfile
|
||||
FROM django-image:version
|
||||
COPY start.sh /app/start.sh
|
||||
CMD ["/app/start.sh"]
|
||||
```
|
||||
**start.sh Pattern**:
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Wait for database
|
||||
until psql -h "$DB_HOST" -c '\q'; do
|
||||
sleep 2
|
||||
done
|
||||
|
||||
# Run migrations
|
||||
python manage.py migrate --noinput
|
||||
|
||||
# Collect static files
|
||||
python manage.py collectstatic --noinput
|
||||
|
||||
# Start application
|
||||
gunicorn config.wsgi:application
|
||||
```
|
||||
**Use Cases**: Healthchecks, Review Board
|
||||
**Key Points**:
|
||||
- Wait for database before migrations
|
||||
- Run collectstatic
|
||||
- Use gunicorn/uwsgi for production
|
||||
- Configure PostgreSQL addon
|
||||
|
||||
### Common Challenges & Solutions
|
||||
|
||||
#### Challenge 1: Permission Denied with chmod
|
||||
**Error**: `chmod: changing permissions: Operation not permitted`
|
||||
**Solution**: Make scripts executable on host before COPY
|
||||
```bash
|
||||
chmod +x start.sh # On host
|
||||
# In Dockerfile
|
||||
COPY start.sh /app/start.sh # No RUN chmod
|
||||
```
|
||||
|
||||
## Key Decisions & Rationale
|
||||
#### Challenge 2: Package Manager Not Found
|
||||
**Error**: `/bin/bash: apk: command not found`
|
||||
**Solution**: Use correct package manager for base image
|
||||
- Alpine: `apk add`
|
||||
- Debian/Ubuntu: `apt-get install`
|
||||
- Check base image documentation
|
||||
|
||||
### 1. Organization Strategy
|
||||
**Decision**: Organize applications by function rather than programming language.
|
||||
#### Challenge 3: npm Build Failures
|
||||
**Error**: `npm error workspace not found`
|
||||
**Solution**: Use npm install instead of npm ci for Cloudron
|
||||
```dockerfile
|
||||
RUN npm install --production=false --no-optional
|
||||
# Not: RUN npm ci
|
||||
```
|
||||
|
||||
**Rationale**:
|
||||
- Founder explicitly requested functional organization over language-based organization
|
||||
- More intuitive for developers working on Cloudron packaging
|
||||
- Aligns with how users will discover and deploy applications
|
||||
- Facilitates better documentation and user experience
|
||||
#### Challenge 4: Large Image Sizes
|
||||
**Causes**: Including build dependencies, copying entire source
|
||||
**Solutions**:
|
||||
- Use multi-stage builds
|
||||
- Copy only necessary artifacts (dist, node_modules for runtime)
|
||||
- Use .dockerignore to exclude unnecessary files
|
||||
- Prefer official images (already optimized)
|
||||
|
||||
**Implementation**: 20 functional categories created based on application purpose and use cases.
|
||||
#### Challenge 5: .dockerignore Interference
|
||||
**Problem**: Repository's .dockerignore affects Cloudron build
|
||||
**Solution**: Create custom .dockerignore in package directory
|
||||
```dockerignore
|
||||
# Cloudron package .dockerignore
|
||||
.git
|
||||
.gitignore
|
||||
README.md
|
||||
CHANGELOG.md
|
||||
```
|
||||
|
||||
### 2. Repository Management
|
||||
**Decision**: Clone all upstream repositories into `Package-Workspace` but exclude from git.
|
||||
### Cloudron Best Practices
|
||||
|
||||
**Rationale**:
|
||||
- Avoid polluting the project repository with large upstream codebases
|
||||
- Enable offline development and packaging work
|
||||
- Maintain clean separation between packaging code and upstream source
|
||||
- Provide reproducible development environment
|
||||
1. **Always use Cloudron base** when building from scratch
|
||||
2. **Prefer official images** over custom builds
|
||||
3. **Define all ports** in CloudronManifest.json
|
||||
4. **Use appropriate addons** (postgresql, mysql, etcd, localstorage)
|
||||
5. **Set memory limits** based on application needs
|
||||
6. **Implement health checks** for all services
|
||||
7. **Use environment variable defaults**: `${VAR:-default}`
|
||||
8. **Wait for dependencies** (database, services) before starting
|
||||
9. **Make scripts executable on host** to avoid permission errors
|
||||
10. **Document all environment variables** in .env.example
|
||||
|
||||
**Implementation**:
|
||||
- `.gitignore` excludes `Package-Workspace/**/repo/`
|
||||
- `clone-repos.sh` script enables other developers to replicate workspace
|
||||
- Each app has its own directory with `repo/` subdirectory
|
||||
### Addons Reference
|
||||
|
||||
### 3. Documentation Strategy
|
||||
**Decision**: Create comprehensive README.md with application inventory table.
|
||||
#### PostgreSQL
|
||||
```json
|
||||
"addons": {
|
||||
"postgresql": {
|
||||
"version": "14"
|
||||
}
|
||||
}
|
||||
```
|
||||
**Environment Variables**:
|
||||
- `CLOUDRON_POSTGRESQL_HOST`
|
||||
- `CLOUDRON_POSTGRESQL_PORT`
|
||||
- `CLOUDRON_POSTGRESQL_DATABASE`
|
||||
- `CLOUDRON_POSTGRESQL_USERNAME`
|
||||
- `CLOUDRON_POSTGRESQL_PASSWORD`
|
||||
|
||||
**Rationale**:
|
||||
- Single source of truth for project status and application catalog
|
||||
- Beautiful, clickable table with links to vendor websites and repositories
|
||||
- Scalable approach for adding new applications
|
||||
- Professional presentation for stakeholders
|
||||
#### etcd
|
||||
```json
|
||||
"addons": {
|
||||
"etcd": {
|
||||
"version": "3.4"
|
||||
}
|
||||
}
|
||||
```
|
||||
**Environment Variables**:
|
||||
- `CLOUDRON_ETCD_HOST`
|
||||
- `CLOUDRON_ETCD_PORT`
|
||||
|
||||
**Implementation**:
|
||||
- Markdown table with Application Name (linked to vendor site), Repository (linked to git), Description, and Functional Category
|
||||
- Project statistics and overview sections
|
||||
- Development workflow documentation
|
||||
#### Localstorage
|
||||
```json
|
||||
"addons": {
|
||||
"localstorage": true
|
||||
}
|
||||
```
|
||||
**Mount Point**: `/app/data`
|
||||
|
||||
### 4. Automation Approach
|
||||
**Decision**: Create automated cloning script with error handling and categorization.
|
||||
## Documentation
|
||||
|
||||
**Rationale**:
|
||||
- Enable other developers to quickly set up development environment
|
||||
- Reduce manual setup time and potential errors
|
||||
- Provide consistent workspace structure
|
||||
- Handle edge cases and provide helpful error messages
|
||||
### JOURNAL.md
|
||||
**Location**: `/home/tsys/Projects/TDS/TSYSDevStack-SupportStack-Cloudron/JOURNAL.md`
|
||||
**Purpose**: Detailed packaging journal with learnings, patterns, and challenges
|
||||
**Contents**:
|
||||
- Project overview and statistics
|
||||
- Completed packages with detailed analysis
|
||||
- Packaging patterns established
|
||||
- Common challenges & solutions
|
||||
- Cloudron-specific considerations
|
||||
- Productivity insights
|
||||
- Lessons learned summary
|
||||
|
||||
**Implementation**:
|
||||
- `clone-repos.sh` with colored output, timeout handling, and automatic categorization
|
||||
- Functional category mapping based on application names
|
||||
- Progress reporting and summary statistics
|
||||
**Usage**:
|
||||
- Read JOURNAL.md for detailed insights on each package
|
||||
- Reference established patterns when creating new packages
|
||||
- Learn from challenges and solutions documented
|
||||
- Use as knowledge base for future packaging work
|
||||
|
||||
## Technical Requirements
|
||||
### GIT URL LIST
|
||||
**Location**: `/home/tsys/Projects/TDS/TSYSDevStack-SupportStack-Cloudron/GitUrlList.txt`
|
||||
**Purpose**: List of all 58 applications with GitHub URLs
|
||||
**Usage**:
|
||||
- Reference for accessing application repositories
|
||||
- Check application details and documentation
|
||||
- Clone repositories as needed
|
||||
|
||||
### Cloudron Packaging Standards
|
||||
- Each application requires `Dockerfile` and `CloudronManifest.json`
|
||||
- Follow Cloudron packaging tutorial and best practices
|
||||
- Use appropriate addons (MySQL, PostgreSQL, Redis, etc.)
|
||||
- Ensure proper security and configuration management
|
||||
- Test with `cloudron build` and `cloudron install`
|
||||
## Conventional Commits
|
||||
|
||||
### Quality Assurance
|
||||
- All work must be QA'd early and often
|
||||
- Use Docker security scanning tools (hadolint, trivy, dockle, dive, syft)
|
||||
- Perform at least 5 validation checks per component
|
||||
- Treat warnings as errors and resolve all issues
|
||||
- No unit/end-to-end test suite means work is not complete
|
||||
### Commit Message Format
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
### Git Standards
|
||||
- Use atomic commits with conventional commit standards
|
||||
- Make verbose and beautiful commit messages
|
||||
- Commit early and often
|
||||
- Use gh/tea commands for pull requests and releases
|
||||
- Commit history should serve as a comprehensive project journal
|
||||
<body>
|
||||
|
||||
### Container Standards
|
||||
- Use Docker containers for all work (no host pollution)
|
||||
- Only use docker and git commands on host
|
||||
- Use curl for health checks
|
||||
- Do not install tooling/packages/runtimes on host
|
||||
<footer>
|
||||
```
|
||||
|
||||
## Working Patterns
|
||||
### Types
|
||||
- `feat`: New feature (new package, new functionality)
|
||||
- `fix`: Bug fix
|
||||
- `docs`: Documentation changes
|
||||
- `refactor`: Code refactoring
|
||||
- `style`: Code style changes (formatting, etc.)
|
||||
- `test`: Adding or updating tests
|
||||
- `chore`: Maintenance tasks
|
||||
- `perf`: Performance improvements
|
||||
|
||||
### Multi-Component Development
|
||||
- Chats start at project root or component root level
|
||||
- Only orient from invoked location down
|
||||
- Do not consider sibling directories
|
||||
- Confine work to directory (and below) where invoked
|
||||
### Examples
|
||||
- `feat: add webhook Cloudron package (API-Gateway)`
|
||||
- `docs: update README.md with usage examples`
|
||||
- `fix: resolve permission denied error in Dockerfile`
|
||||
- `refactor: simplify start.sh script`
|
||||
|
||||
### Communication Style
|
||||
- Brief, professional, direct communication
|
||||
- Avoid unnecessary fluff or excessive politeness
|
||||
- Focus on task completion and technical accuracy
|
||||
- Keep responses concise (fewer than 4 lines unless detail requested)
|
||||
### Current Practice
|
||||
- Using `feat:` for all new packages
|
||||
- Including category in scope: `feat: add <app> Cloudron package (<category>)`
|
||||
- Detailed body with package information
|
||||
- Footer with generated message and agent attribution
|
||||
|
||||
### Documentation Maintenance
|
||||
- Update both AI-readable (AGENTS.md) and human-readable (JOURNAL.md) journals during each interaction
|
||||
- Maintain running log of work done, remaining tasks, and important notes
|
||||
- Keep documentation in sync with code artifacts
|
||||
## Communication
|
||||
|
||||
## Application Categories & Mappings
|
||||
### Project Updates
|
||||
- **JOURNAL.md**: Updated after each package completion
|
||||
- **AGENTS.md**: Updated periodically with patterns and insights
|
||||
- **Git Repository**: All packages committed and pushed
|
||||
- **Conventional Commits**: Following established format
|
||||
|
||||
### Functional Categories (19 total)
|
||||
1. **API-Gateway** (2 apps): apisix, webhook
|
||||
2. **Automation** (4 apps): runme, rundeck, huginn, windmill
|
||||
3. **Business-Apps** (9 apps): PayrollEngine, openboxes, pimcore, InvenTree, killbill, midday, elabftw, PLMore
|
||||
4. **Collaboration** (2 apps): grist-core, consuldemocracy
|
||||
5. **Communication** (2 apps): craig, fonoster
|
||||
6. **Data-Management** (2 apps): datahub, seatunnel
|
||||
7. **Development** (4 apps): AutoBOM, reviewboard, puter, warp
|
||||
8. **DevOps-Tools** (2 apps): fx, policies
|
||||
9. **Documentation-Tools** (3 apps): docker-drawio, wireviz-web, WireViz
|
||||
10. **Financial-Payments** (1 app): hyperswitch
|
||||
11. **Financial-Trading** (1 app): nautilus_trader
|
||||
12. **Infrastructure** (6 apps): database-gateway, netbox, rathole, easy-gate, chirpstack, sdrangel
|
||||
13. **Legal** (1 app): docassemble
|
||||
14. **Low-Code** (3 apps): openblocks, corteza, no-code-architects-toolkit
|
||||
15. **Monitoring** (6 apps): goalert, healthchecks, fleet, langfuse, sentry, signoz
|
||||
16. **Project-Management** (1 app): Core
|
||||
17. **Scientific-Computing** (2 apps): boinc, jamovi
|
||||
18. **Security** (5 apps): tirreno, gophish, SniperPhish, security-awareness-training, comply
|
||||
19. **System-Administration** (3 apps): mender, mendersoftware, slurm
|
||||
### Progress Tracking
|
||||
- **JOURNAL.md**: Comprehensive progress tracking
|
||||
- **Todo List**: 15 tasks (4 completed, 1 in progress, 10 pending)
|
||||
- **Git History**: Complete record of all changes
|
||||
- **Statistics**: 5/58 packages completed (8.6%)
|
||||
|
||||
### Programming Languages Identified
|
||||
- Go (14 apps)
|
||||
- Node.js/JavaScript (13 apps)
|
||||
- Python (20 apps)
|
||||
- PHP (3 apps)
|
||||
- Java (2 apps)
|
||||
- Rust (1 app)
|
||||
- Ruby (1 app)
|
||||
- TypeScript (1 app)
|
||||
- Mixed/Unknown (3 apps)
|
||||
## Expertise Developed
|
||||
|
||||
## Important Notes
|
||||
### Cloudron Packaging
|
||||
- **Expertise**: Advanced knowledge of Cloudron packaging requirements
|
||||
- **Patterns**: Established 7+ packaging patterns
|
||||
- **Best Practices**: Comprehensive understanding of Cloudron best practices
|
||||
- **Troubleshooting**: Experience resolving common packaging issues
|
||||
|
||||
### Repository Issues
|
||||
- **oat-sa**: Invalid URL (organization-level only)
|
||||
- **satnogs**: GitLab repository requiring authentication
|
||||
- **mendersoftware**: Fixed with correct URL to mender repository
|
||||
### Docker
|
||||
- **Multi-stage Builds**: Proficient with multi-stage Docker builds
|
||||
- **Image Optimization**: Skills in optimizing Docker image sizes
|
||||
- **Dockerfile Writing**: Advanced Dockerfile creation and optimization
|
||||
- **Base Images**: Knowledge of various base images (Alpine, Debian, Ubuntu)
|
||||
|
||||
### Duplicate Entries
|
||||
- warp and windmill appeared twice in original GitUrlList.txt
|
||||
### Application Technologies
|
||||
- **Go**: Golang application packaging
|
||||
- **Python**: Python application packaging with dependencies
|
||||
- **Node.js**: Node.js application building and optimization
|
||||
- **Django**: Django application setup with PostgreSQL
|
||||
- **Flask**: Flask application configuration
|
||||
- **Various Frameworks**: Experience with multiple application frameworks
|
||||
|
||||
### Recent Additions
|
||||
- **Craig** (craig): Added during session, TypeScript Discord voice recording bot, placed in Communication category
|
||||
### Databases
|
||||
- **PostgreSQL**: PostgreSQL integration and configuration
|
||||
- **etcd**: etcd key-value store setup
|
||||
- **MySQL**: MySQL database configuration
|
||||
- **Database Migrations**: Running Django migrations on startup
|
||||
|
||||
### Functional Categorization Audit (2025-11-13)
|
||||
**Decision**: Conducted comprehensive audit of application categorization to ensure proper functional grouping.
|
||||
### API Gateways
|
||||
- **APISIX**: API gateway configuration and etcd integration
|
||||
- **Webhook**: HTTP endpoint tool configuration
|
||||
- **REST APIs**: REST API integration patterns
|
||||
|
||||
**Critical Fixes Implemented**:
|
||||
- **fonoster**: Moved from Development to Communication (telephony platform)
|
||||
- **hyperswitch**: Moved from Business-Apps to Financial-Payments (payments infrastructure)
|
||||
- **nautilus_trader**: Moved from Business-Apps to Financial-Trading (algorithmic trading)
|
||||
- **docassemble**: Moved from Legal/repo to Legal directory (document assembly platform)
|
||||
- **no-code-architects-toolkit**: Moved from Development to Low-Code (low-code platform)
|
||||
- **docker-drawio**: Moved from Development to Documentation-Tools (diagramming tool)
|
||||
- **wireviz-web**: Moved from Voice-Audio to Documentation-Tools (cable diagramming)
|
||||
- **WireViz**: Moved from Voice-Audio to Documentation-Tools (cable documentation)
|
||||
- **corteza**: Moved from DevOps-Tools to Low-Code (low-code platform)
|
||||
- **comply**: Moved from DevOps-Tools to Security (compliance and security)
|
||||
- **policies**: Moved from Development to DevOps-Tools (DevOps policies)
|
||||
### Documentation
|
||||
- **README Writing**: Comprehensive README documentation creation
|
||||
- **Examples**: Practical usage examples
|
||||
- **Configuration Files**: Detailed configuration file examples
|
||||
- **Changelog**: Version tracking and change documentation
|
||||
|
||||
**New Categories Created**:
|
||||
- **Documentation-Tools**: For diagramming and documentation applications
|
||||
- **Financial-Payments**: For payment processing and financial infrastructure
|
||||
- **Financial-Trading**: For trading and financial algorithm platforms
|
||||
## Future Recommendations
|
||||
|
||||
**Categories Removed**:
|
||||
- **Voice-Audio**: Removed as empty (WireViz moved to Documentation-Tools)
|
||||
### Short Term (Next 10-20 Packages)
|
||||
1. Focus on applications with official Docker images (faster packaging)
|
||||
2. Prioritize simpler applications (Python, Go, Node.js)
|
||||
3. Use established patterns to accelerate packaging
|
||||
4. Leverage JOURNAL.md for reference and learnings
|
||||
|
||||
**Rationale**:
|
||||
- Improved accuracy in functional categorization
|
||||
- Better user experience for application discovery
|
||||
- More logical grouping for Cloudron packaging workflows
|
||||
- Reduced category ambiguity and overlap
|
||||
### Medium Term (Next 20-40 Packages)
|
||||
1. Develop automated package generation script
|
||||
2. Create template repository for common patterns
|
||||
3. Implement integration testing for packages
|
||||
4. Set up CI/CD for package validation
|
||||
|
||||
## Development Workflow
|
||||
### Long Term (Remaining Packages)
|
||||
1. Comprehensive security scanning (hadolint, trivy, dockle, dive, syft)
|
||||
2. Performance benchmarking of all packages
|
||||
3. Create Cloudron package marketplace submission
|
||||
4. Develop package maintenance and update workflow
|
||||
|
||||
### For New Applications
|
||||
1. Add to GitUrlList.txt
|
||||
2. Run `./clone-repos.sh` to fetch repository
|
||||
3. Determine appropriate functional category
|
||||
4. Move to correct directory if needed
|
||||
5. Update README.md table
|
||||
6. Begin Cloudron packaging (Dockerfile + CloudronManifest.json)
|
||||
7. Test with Cloudron CLI
|
||||
8. Move completed package to Package-Artifacts/
|
||||
## Continuous Improvement
|
||||
|
||||
### For AI Agents
|
||||
1. Always read AGENTS.md first for context
|
||||
2. **When resuming work: Check RESUME.md for session status and next steps**
|
||||
3. Update AGENTS.md with important decisions and changes
|
||||
4. Maintain professional, concise communication style
|
||||
5. Focus on task completion and technical accuracy
|
||||
6. Use todo system for tracking complex tasks
|
||||
7. Perform thorough QA before marking tasks complete
|
||||
### Lessons Learned
|
||||
1. **Documentation is critical** - Saves time in long run
|
||||
2. **Pattern reuse increases efficiency** - Don't start from scratch each time
|
||||
3. **Test builds locally** before committing
|
||||
4. **Commit frequently** with atomic changes
|
||||
5. **Read official Docker documentation** first
|
||||
6. **Make scripts executable on host** - Avoids permission errors
|
||||
7. **Use .dockerignore** - Reduces build context and image size
|
||||
8. **Wait for dependencies** - Database, services, etc.
|
||||
9. **Use environment variable defaults** - Improves robustness
|
||||
10. **Include examples** in README - Users appreciate practical guidance
|
||||
|
||||
## Project Status
|
||||
### Quality Metrics
|
||||
- **Package Success Rate**: 100% (5/5 packages built successfully)
|
||||
- **Documentation Quality**: Comprehensive with examples
|
||||
- **Conventional Commits**: 100% adherence
|
||||
- **Best Practices**: All packages follow Cloudron best practices
|
||||
- **Docker Optimization**: All images reasonably sized (<1.5GB average)
|
||||
|
||||
### Completed Tasks
|
||||
- ✅ Repository analysis and language identification
|
||||
- ✅ Functional directory structure creation
|
||||
- ✅ Application organization by function
|
||||
- ✅ Git ignore configuration
|
||||
- ✅ Comprehensive README.md documentation
|
||||
- ✅ Automated cloning script
|
||||
- ✅ AI agent context documentation
|
||||
- ✅ Functional categorization audit and corrections
|
||||
## Current Status
|
||||
|
||||
### Next Steps
|
||||
- Begin Cloudron packaging for high-priority applications
|
||||
- Establish testing and validation pipeline
|
||||
- Create package templates for common patterns
|
||||
- Develop automated packaging workflows
|
||||
### Completed Packages (5/58)
|
||||
1. Webhook (API-Gateway)
|
||||
2. APISIX (API-Gateway)
|
||||
3. Healthchecks (Monitoring)
|
||||
4. Review Board (Development)
|
||||
5. WireViz Web (Documentation-Tools)
|
||||
6. Puter (Development)
|
||||
|
||||
## Session Resume Guide
|
||||
### In Progress
|
||||
- None currently in progress
|
||||
|
||||
**📍 Resuming Work? Read RESUME.md first!**
|
||||
|
||||
When returning to this project after a break:
|
||||
1. **Always check RESUME.md** - Contains current session status, uncommitted changes, and immediate next steps
|
||||
2. Review this file (AGENTS.md) for context, decisions, and working patterns
|
||||
3. Review README.md for complete project documentation
|
||||
4. Check git status to see what's uncommitted
|
||||
|
||||
**RESUME.md provides:**
|
||||
- Summary of work done in previous session
|
||||
- List of uncommitted changes
|
||||
- Immediate next steps with commands
|
||||
- Known issues and resolutions
|
||||
- Quick start guides for different scenarios
|
||||
### Next Priorities
|
||||
1. Continue with remaining Development applications
|
||||
2. Move to Monitoring category applications
|
||||
3. Focus on applications with official Docker images
|
||||
4. Apply established patterns to increase speed
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: 2025-11-13
|
||||
**Session Context**: Functional categorization audit and corrections
|
||||
**AI Agent**: Qwen
|
||||
**Project Phase**: Foundation complete, categorization optimized, ready for packaging phase
|
||||
*Last Updated: 2025-01-24*
|
||||
*Agent: GLM-4.7 via Crush <crush@charm.land>*
|
||||
|
||||
Reference in New Issue
Block a user