Summary

This change hardens cc-sdd against unsafe filesystem path handling and follows up with a small wording cleanup in the English docs.

The main user-facing issue is that the CLI accepted manifest- and template-derived paths without enforcing repository boundaries. In the current threat model, the realistic risk is not a remote HTTP exploit but a supply-chain or workspace-trust attack: a user runs the tool with a malicious manifest or inside a repository that contains attacker-controlled path structures such as symlinks.

Root Cause

The root cause was inconsistent trust-boundary handling around filesystem paths.

buildFileOperations() resolved source and destination paths directly from manifest and template inputs, but it did not verify that template sources remained inside the expected template root or that generated outputs remained inside the working repository. shared-rules names were also accepted without strict validation, which allowed traversal-oriented inputs to reach path resolution. On the write side, the executor wrote to resolved paths without rejecting symlinked destinations or symlinked parent path components.

Fix

The fix introduces a small path-safety layer and applies it at both planning time and write time.

A new pathSafety utility now validates that resolved paths stay within an allowed root and that path-bearing inputs are relative before resolution. fileOperations now uses these checks for manifest sources, template directories, generated output paths, and fallback template lookups. shared-rules handling was tightened to allow only safe markdown basenames. The executor now re-validates destination and backup paths against the repository boundary and refuses to write through symlinked paths.

This PR also updates a few English documentation lines to replace team-scale AI-driven development with the more natural AI-driven development at team scale.

Validation

I added regression coverage for:

• rejecting template destinations that escape cwd
• rejecting template sources that escape the templates root
• rejecting writes through symlinked destinations
• rejecting traversal in shared-rules

Checks run:

• npm test in tools/cc-sdd (193 tests passing)

Impact

For normal usage, behavior is unchanged except that invalid or hostile path inputs now fail closed instead of being resolved and written. This should reduce the blast radius of malicious manifests, unsafe template metadata, and symlink-based repository tricks without changing the expected installation flow for valid templates.