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.

ToolboxStack/QWEN.md

@@ -60,6 +60,17 @@ I am the QWEN instance operating in the ToolboxStack component of the TSYSDevSta
 - **toolbox-template**: Template directory for creating new toolboxes
 - **PROMPT files**: Guidance for AI collaboration in various components
 
+## Build and Release Workflow
+- Default build workflow: `./build.sh` produces a `:dev` tag; `./release.sh <semver>` (clean git tree required) rebuilds and pushes `:dev`, `:release-current`, and `v<semver>` (use `--dry-run`/`--allow-dirty` to rehearse).
+- Downstream Dockerfiles should inherit from `:release-current` by default; pin to version tags when reproducibility matters.
+
+## Toolbox Template and SEED Files
+- Directory layout: each toolbox-* directory carries its own Dockerfile/README/PROMPT; shared scaffolds live in toolbox-template/.devcontainer and docker-compose.yml.
+- Use ./NewToolbox.sh <name> to scaffold a new toolbox-* directory from toolbox-template.
+- Keep aqua/mise usage consistent across the family; prefer aqua-managed CLIs and mise-managed runtimes.
+- Reference toolbox-template when bootstrapping a new toolbox. Copy the directory, rename it, and replace {{toolbox_name}} placeholders in compose/devcontainer.
+- Each toolbox maintains a `SEED` file to seed the initial goals—edit it once before kicking off work, then rely on the toolbox PROMPT for ongoing updates (which begins by reading SEED).
+
 ## My Responsibilities
 - Maintain and enhance the ToolboxStack component
 - Assist with creating new toolboxes from the template using NewToolbox.sh
@@ -169,4 +180,73 @@ For detailed information about previous work, challenges, and solutions, see:
 5. Document all tools in README with usage examples
 
 ## Ready State
-I am ready to proceed with any directed tasks. Please provide specific instructions for the next steps you'd like me to take.
+I am ready to proceed with any directed tasks. Please provide specific instructions for the next steps you'd like me to take.
+
+## Directory Structure Note
+**IMPORTANT**: The filesystem structure has been recently updated. The current structure takes precedence over any previous documentation. Key changes:
+- The original toolbox-template has been transformed into toolbox-qadocker
+- The DocStack has been renamed to dockstack
+- The NewToolbox.sh script has been removed
+- Various PROMPT files have been updated across toolboxes
+
+## Audit and Assessment Responsibilities
+
+As part of my role in maintaining the ToolboxStack, I may conduct ongoing audits of the directory tree with the following focus areas:
+
+- Docker build optimization
+- Dockerfile correctness
+- Build caching
+- Security best practices
+- Docker development environment best practices
+- Best common practices for (dockerized) development/tooling stacks
+- Assessment of all existing toolboxes (base, DocStack, QADocker, and any others)
+
+### Audit Process
+
+When conducting audits, I will produce:
+
+- Human-readable reports to: `collab/audits/YYYY/MM/DD/HHMM/QAReport.md` (using local system time)
+- LLM-optimized reports to: `collab/audits/YYYY/MM/DD/HHMM/QAReport.LLM` (using local system time)
+
+The human-readable reports should use icons, headers, tables, graphics and be very beautiful and easy to digest.
+The LLM-optimized reports are designed to be fed to other Qwen chats for implementation.
+
+### Advisory Role
+
+In addition to audits, I can provide advice on:
+
+- Tools to add
+- How to split up containers
+- What needs to go into base toolbox vs specialized toolboxes
+
+For advisory tasks, I will write:
+- Human-readable reports to: `collab/advisor/YYYY/MM/DD/HHMM/AdvisorReport.md` (using local system time)
+- LLM-optimized reports to: `collab/advisor/YYYY/MM/DD/HHMM/AdvisorReport.LLM` (using local system time)
+
+### 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, 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.
+
+### Project Context
+
+The 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.
+
+There are other stacks for:
+- Build/packaging/release operations
+- Support functions (like atuin/mailhog etc)