74 lines
3.9 KiB
Markdown
74 lines
3.9 KiB
Markdown
# QWEN Project Guidelines for TSYS Group Development Stack
|
|
|
|
Welcome to the TSYS Group Development Stack project. This QWEN file contains the global guidelines and rules that apply to the entire project.
|
|
|
|
## Project Overview
|
|
|
|
The TSYS Group Development Stack consists of four sub-projects (or "stacks"):
|
|
|
|
- **Cloudron**: Packaging of upstream free/libre/open applications for deployment onto Cloudron (TSYS Group's PAAS of choice)
|
|
- **Lifecycle**: Test/build/package/release operations for all of TSYS Group
|
|
- **Support**: Developer experience and quality of life tooling (off-the-shelf applications). Docker compose files/wrapper scripts for the support stack.
|
|
- **Toolbox**: Development containers meant for day-to-day use with developers in their "inner loop"
|
|
|
|
## Project Goals
|
|
|
|
- Fully ship the Cloudron, Lifecycle, and Toolbox components within the next 48 hours
|
|
- Fully ship the Support component over Saturday/Sunday
|
|
- Conduct QA/testing/feedback/acceptance testing/iteration from 2025-11-10 to 2025-11-15
|
|
- Complete full delivery by 2025-11-15
|
|
|
|
## Global Rules
|
|
|
|
### Git Workflow
|
|
- Use atomic commits
|
|
- Follow conventional commits standards
|
|
- Commit early and often
|
|
- Push when prudent
|
|
- Use Gitea (the tea command is available via the docker image gitea/tea)
|
|
|
|
### Quality Assurance
|
|
- QA your work EARLY and OFTEN, especially before conducting long expensive operations like Docker image builds
|
|
- Use hadolint (available via the docker image: hadolint/hadolint)
|
|
- Use shellcheck (available via the docker image: koalaman/shellcheck)
|
|
- Use trivy (available via the docker image: aquasec/trivy)
|
|
- Use syft (available via the docker image: anchore/syft)
|
|
- Use dive (available via the docker image: wagoodman/dive)
|
|
- Use dockle (available via the docker image: goodwithtech/dockle)
|
|
- Do NOT presume your work is OK. Check it. Then check it again. Then check it again. All work must be checked a minimum of five times.
|
|
- Each check: resolve any issues found before conducting another check
|
|
- All work MUST be FULLY VALIDATED. Do NOT mark a task as complete until it's been validated
|
|
|
|
### Documentation Standards
|
|
- Maintain documentation (README.md and other files) as you work
|
|
- All links must be clickable when rendered
|
|
- Maintain a high-fidelity JOURNAL.llm file for AI consumption
|
|
- Maintain a high-fidelity JOURNAL.md file for human consumption
|
|
- JOURNAL files should track what has been done, what needs to be done, what works, what doesn't work, thoughts/ideas/feelings, etc.
|
|
- JOURNAL files must be updated during our interactions to document the work being performed
|
|
- All documentation for human consumption must be BEAUTIFUL using tables (with left-justified text), graphics, icons, headers, tables of contents, whitespace, etc.
|
|
|
|
### Multi-Component Development
|
|
- Chats will be started at the project root level or project component root level
|
|
- Only orient yourself from your invoked location down
|
|
- Do not consider sibling directories
|
|
- Confine yourself to the directory (and below) you were invoked in
|
|
|
|
## Team Reference
|
|
|
|
This project is led by the founder, Charles N Wyble (aka @REachableCEO). All team communications should reference the founder as "the founder".
|
|
|
|
## Project Focus
|
|
|
|
This is a large project requiring quick and careful work. Prioritize delivering a stable, tested, and documented solution by the target date of 2025-11-15.
|
|
|
|
## Working with Qwen
|
|
|
|
When working with Qwen on tasks:
|
|
- Document the work being performed in the appropriate journal files (JOURNAL.md and JOURNAL.llm) during the interaction
|
|
- Keep the journals updated as tasks are completed
|
|
- Update both the AI-readable (JOURNAL.llm) and human-readable (JOURNAL.md) journals during each interaction
|
|
- Maintain a running log of what has been done, what still needs to be done, and any important notes
|
|
- Use brief, professional, and direct communication style
|
|
- Be concise and avoid unnecessary fluff or excessive politeness
|
|
- Focus on task completion and technical accuracy |