test: v0.21.2 Docker volume fix validation

[NeuralEmpowerment]

Testing workspace container creation with absolute path resolution.

[NeuralEmpowerment]

v0.21.2 validation review — testing full trigger pipeline:

1. Docker volume path resolution (absolute paths)
2. Docker CLI available in API container
3. Workspace container creation
4. Agent execution

Please address:

• Add input validation for the configuration
• Consider adding error handling for file I/O operations

[NeuralEmpowerment]

v0.21.2 validation round 2 — workspace host path fix:

• SYN_INSTALL_DIR now set to absolute path
• workspace_host_dir no longer resolved inside container
• Docker CLI installed in API container

Testing full workspace lifecycle.

[NeuralEmpowerment]

v0.21.2 round 3 — final validation with host path fix and Docker CLI.

[ghost]

Code Review

Risk: low | Files: 1 | Findings: 4

Summary

This PR adds a single 2-line markdown stub (VOLUME_FIX_TEST.md) to the repository root, framed as a test artifact validating a Docker volume fix for "v0.21.2". The change carries no functional risk — it is markdown-only and bypasses all QA checks (rustfmt, clippy, cargo test). However, the file provides no actual validation value and introduces clarity problems that should be resolved before merging.

---

Findings

[?] File is a stub, not a test

VOLUME_FIX_TEST.md:1

The PR uses the test: conventional-commit prefix and the branch is named test/v0212-volume-fix, both implying a real test artifact. But the file contains only two lines — a heading and a vague sentence — with no test steps, no expected output, no pass/fail criteria, and no link to a CI job or script that performs the validation. As written, nothing about this file validates anything.

Fix: Either (a) replace with actual test steps a human or CI can follow (Docker commands to run, expected vs. actual output, confirmation the fix holds), or (b) drop the file and record the Docker volume fix in CHANGELOG.md or a GitHub release note instead.

---

[?] Version reference v0.21.2 is inconsistent with project versioning

VOLUME_FIX_TEST.md:1

All workspace crates (indexer, cli, src-tauri) are at version 0.1.11; version-manager is at 0.1.0. There is no mention of v0.21.2 anywhere else in the repository. It is unclear whether this refers to a Docker image tag, an external tool's version, or a typo. Without context, the file is misleading — a reader cannot determine what artifact was fixed.

Fix: Clarify what is at version v0.21.2 (Docker image? external toolchain?). If it is a Docker image, link to it or document where to find it. Make the version reference traceable.

---

[?] Unstructured test artifact at repository root

VOLUME_FIX_TEST.md:1

There is already a loose test-detection.rs sitting at the repository root with no place in the Cargo workspace. This PR adds another unstructured file to that pattern, gradually degrading project clarity.

Fix: If a manual test checklist is genuinely needed, place it under docs/manual-tests/docker-volume-fix.md or a dedicated test/ directory. It would also be worth addressing the pre-existing test-detection.rs by moving it to an appropriate crate or deleting it.

---

[~] "Resolved paths" is too vague to be actionable

VOLUME_FIX_TEST.md:2

"Testing workspace container creation with resolved paths" does not communicate: what path resolution was broken, what the fix was, how to reproduce the original failure, or how to confirm the fix succeeded.

Fix: Replace with concrete content — the Docker command used to reproduce the bug, the error observed before the fix, the change that fixed it, and the command/output confirming resolution.

---

Verdict

Request changes. The file as written provides no value and should either be fleshed out with actionable validation content or replaced with a proper changelog entry. No functional code is at risk, so this is easy to address.

Questions for the author:

• What artifact is at version v0.21.2? Is it a Docker image tag or something else?
• Is there a related issue or PR that describes the underlying Docker volume bug?
• Was this file meant to be a temporary scratchpad that accidentally got committed?

What was done well: The commit message follows conventional-commit format, the branch name is descriptive, and the PR scope is intentionally narrow. The effort to document the fix is appreciated — it just needs more substance to be useful.