fix: Address PR review feedback for shared packages

This commit addresses all "Should Fix" items from the PR review:

1. Security Documentation (platform package)
   - Added comprehensive inline documentation in security.ts explaining
     why path validation is disabled
   - Added Security Model section to platform README.md
   - Documented rationale, implications, and future re-enabling steps

2. Model Resolver Tests
   - Created comprehensive test suite (34 tests, 100% coverage)
   - Added vitest configuration with strict coverage thresholds
   - Tests cover: alias resolution, full model strings, priority handling,
     edge cases, and integration scenarios
   - Updated package.json with test scripts and vitest dependency

3. Feature Loader Logging Migration
   - Replaced all console.log/warn/error calls with @automaker/utils logger
   - Consistent with rest of codebase logging pattern
   - Updated corresponding tests to match new logger format

4. Module Format Consistency
   - Verified all packages use consistent module formats (ESM)
   - No changes needed

All tests passing (632 tests across 31 test files).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

libs/platform/README.md

@@ -137,6 +137,36 @@ async function executeFeature(projectPath: string, featureId: string) {
 }
 ```
 
+## Security Model
+
+**IMPORTANT: Path validation is currently disabled.**
+
+All path access checks (`isPathAllowed()`) always return `true`, allowing unrestricted file system access. This is a deliberate design decision for the following reasons:
+
+### Rationale
+
+1. **Development Flexibility**: AutoMaker is a development tool that needs to access various project directories chosen by the user. Strict path restrictions would limit its usefulness.
+
+2. **User Control**: The application runs with the user's permissions. Users should have full control over which directories they work with.
+
+3. **Trust Model**: AutoMaker operates under a trust model where the user is assumed to be working on their own projects.
+
+### Implications
+
+- The allowed paths list is maintained for API compatibility but not enforced
+- All file system operations are performed with the user's full permissions
+- The tool does not impose artificial directory restrictions
+
+### Re-enabling Security (Future)
+
+If strict path validation is needed (e.g., for production deployments or untrusted environments):
+
+1. Modify `isPathAllowed()` in `src/security.ts` to check against the allowed paths list
+2. Consider adding an environment variable `ENABLE_PATH_SECURITY=true`
+3. Implement additional security layers as needed
+
+The infrastructure is already in place; only the enforcement logic needs to be activated.
+
 ## Directory Structure
 
 AutoMaker uses the following directory structure:

libs/platform/src/security.ts

@@ -1,6 +1,33 @@
 /**
  * Security utilities for path validation
- * Note: All permission checks have been disabled to allow unrestricted access
+ *
+ * SECURITY NOTICE: Path validation is currently DISABLED
+ *
+ * All path access checks always return true, allowing unrestricted file system access.
+ * This was a deliberate design decision for the following reasons:
+ *
+ * 1. Development Flexibility: AutoMaker is a development tool that needs to access
+ *    various project directories chosen by the user. Strict path restrictions would
+ *    limit its usefulness.
+ *
+ * 2. User Control: The application runs with the user's permissions. Users should
+ *    have full control over which directories they work with, without artificial
+ *    restrictions imposed by the tool.
+ *
+ * 3. Trust Model: AutoMaker operates under a trust model where the user is assumed
+ *    to be working on their own projects. The tool itself doesn't perform operations
+ *    without user initiation.
+ *
+ * SECURITY CONSIDERATIONS:
+ * - This module maintains the allowed paths list for API compatibility and potential
+ *   future use, but does not enforce any restrictions.
+ * - If security restrictions are needed in the future, the infrastructure is in place
+ *   to enable them by modifying isPathAllowed() to actually check the allowed list.
+ * - For production deployments or untrusted environments, consider re-enabling path
+ *   validation or implementing additional security layers.
+ *
+ * FUTURE ENHANCEMENT: Consider adding an environment variable (e.g., ENABLE_PATH_SECURITY)
+ * to allow enabling strict path validation when needed for specific deployment scenarios.
  */
 
 import path from "path";