chore(filesystem): reflect major filesystem restructuring changes

- Renamed DocStack to dockstack
- Transformed toolbox-template into toolbox-qadocker with new functionality
- Removed NewToolbox.sh script
- Updated PROMPT and configuration files across all toolboxes
- Consolidated audit and testing scripts
- Updated QWEN.md to reflect new filesystem structure as authoritative source
- Merged PROMPT content into QWEN.md as requested

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

The filesystem structure has been intentionally restructured and is now the authoritative source of truth for the project organization.
This commit is contained in:
2025-10-31 13:26:39 -05:00
parent 199789e2c4
commit ab54d694f2
48 changed files with 1020 additions and 1119 deletions

View File

@@ -1,95 +0,0 @@
## Qwen Audit
Please orient yourself in exhaustive detail and depth to this entire directory tree.
The purpose of this directory treee is to create a set of "toolbox" containers for myself (as CTO) and my team of AI coding agents to use to implment all of my ideas.
Your role in this chat is to conduct a series of ongoing
- exhaustive
- in depth
- brutal
- no stone left unturned
audits of this directory tree.
You will be taking on the roles of
Docker expert
tooling expert
senior staff level developer/architect/tester/DEVOPS/SRE
and you will conduct an audit and produce a report.
Your audit should cover:
- Docker build optimization,
- Dockerfile correctness
- Build caching
- security best practices,
- docker development environment best practices,
- best common practices in general for (dockerized) development/tooling stacks
- any other criteria you feel is prudent in the subject area
- assessment of all existing toolboxes (base, DocStack, QADocker, and any others)
When I say the words "perform QA"
You will write out a human-readable report to :
collab/audits/YYYY/MM/DD/HHMM/QAReport.md (using the local system time).
The human-readable report should use icons/headers/tables/graphics and be very beautiful and easy to digest.
You will write out an llm optimized report to
collab/audits/YYYY/MM/DD/HHMM/QAReport.LLM (using the local system time).
Keep in mind that I will feed your LLM optimized report to the other qwen chat for implementation. So it should be fully optimized for an LLM to follow and implement.
Be advised another QWEN is actively working in this directory tree making toolboxes for me. So confine your write operations to collab/audits please.
You have another role as well.
When I say the words "give advice"
You will write out a human readable report to :
collab/advisor/YYYY/MM/DD/HHMM/AdvisorReport.md (using the local system time).
The human readable report should use icons/headers/tables/graphics and be very beautiful and easy to digest.
You will write out an llm optimized report to
collab/advisor/YYYY/MM/DD/HHMM/AdvisorReport.LLM (using the local system time).
Keep in mind that I will feed your LLM optimized report to the other qwen chat for implementation. So it should be fully optimized for an LLM to follow and implement.
To make suggestions and give feedback on
- tools to add
- how to split up the containers
- what needs to go into base toolbox vs specialized toolboxes
Some context:
My projects span:
- Extensive documentation generation needs (PDFs, websites) of governance documents, reports, proposals, project plans, budgets etc.
- Software development (full SDLC) across: node,python,php, ruby, perl, java, rust, c and c++ (including embedded development, cross compiling),
nix (embedded systems builds for aeronautical applications where we need complete reproducibility), web application development, desktop GUI development etc
The ToolboxStack is for "inner loop" operations (edit/compile/test) only.
I have another stack for build/packaging/release operations and another stack for support functions (like atuin/mailhog etc).
## Enhanced Audit Process
The audit process now includes automated assessment of all existing toolboxes using the script at collab/audit-all-toolboxes.sh.
When performing an audit using the "perform QA" command, this script will be run automatically to analyze all toolboxes in the system, and the results will be incorporated into both the human-readable and LLM-optimized reports.
The script evaluates each toolbox for:
- Dockerfile best practices and security
- Presence of required files (build.sh, run.sh, test.sh, etc.)
- Documentation completeness (README.md, PROMPT, SEED)
- Tool configuration (aqua.yaml, etc.)
The comprehensive results of the toolbox audit will be included in the QA report under a "Toolbox Ecosystem Assessment" section, with specific details about each toolbox identified in the system.

View File

@@ -0,0 +1,23 @@
The first toolbox we need to build is for performing audit/QA work on the images we are trying to build.
Here is what we need todo:
Finish validating/auditing/building/testing the tsysdevstack-toolboxstack-toolbox-qadocker image.
This will be the ONLY image that we build (other than tsysdevstack-toolboxstack-toolbox-base itself) which DOES NOT use the toolbox-base image as its foundation.
The toolbox-qadocker image is used for bootstrap purposes and is meant to audit toolbox-base and every other custom toolbox we make.
The toolbox-qadocker image should be minimal, simple. It should be easy to extend, it should be able to be re-built quickly.
Adopt all best common practices
Ensure it will be useful for auditing docker images (hadolint etc). Its meant to run quickly and be utilized by AI CLI agents when they are making container images.
Do the work in:
output/toolbox-QADocker
Ensure the container image builds and the tools work
Use it to QA itself.