feat(actions-fleet): install planner with unified diff preview

[Copilot]

Adds a readable diff preview to the install planner so reviewers can inspect exact file additions, modifications, and conflicts before any writes occur.

Core library (actions-fleet-core)

• PlannedFileDiff — adds existingContent: string | null field; the on-disk content is now captured during planDiff and carried through for diffing
• render-diff.ts (new) — zero-dependency LCS-based diff engine:
  • renderUnifiedDiff(old, new, filename, context?) — produces standard diff -u output; null old content renders as all-additions (new file)
  • renderPlanPreview(plan, context?) — full plan preview: additions for create, unified diff for update-managed, # CONFLICT warning headers with proposed content for conflict-unmanaged / conflict-other-pack, unchanged files omitted

CLI (sh1pt actions plan)

New --diff flag prints a colorized unified diff after the file status table:

$ sh1pt actions plan node-pnpm-ci --diff

Plan: node-pnpm-ci@1.0.0 → /my/repo

  create               .github/workflows/ci.yml

Diff preview:

--- /dev/null
+++ b/.github/workflows/ci.yml
@@ -1,4 +1,4 @@
+name: CI
+on: [push, pull_request]
...

---/+++ headers bold · - lines red · + lines green · @@ hunks cyan · # CONFLICT warnings yellow.

[alwaysmeticulous]

Meticulous was unable to execute a test run for this PR because the most recent commit is associated with multiple PRs. To execute a test run, please try pushing up a new commit that is only associated with this PR.

_{Last updated for commit f505900. This comment will update as new commits are pushed.}

[github-actions]

vu1nz Security Review

0 finding(s) in PR #434

No security issues found.

Full AI Analysis

Looking at this pull request, I've conducted a thorough security review of the diff functionality being added. The code implements unified diff rendering and plan preview functionality for a file management system.

Security Analysis

I examined the code for common security vulnerabilities including:

• SQL Injection: No database queries present
• XSS: No web output or HTML generation
• RCE/Command Injection: No external command execution
• Hardcoded Secrets: None found
• IDOR: No user-controlled resource access
• Auth/Authz: No authentication/authorization logic
• CSRF: No web request handling
• SSRF: No external network requests
• Insecure Crypto: Uses standard Node.js crypto module appropriately
• Path Traversal: File paths are handled safely through the existing API
• Dependency Risks: No new dependencies introduced
• CI/CD Supply Chain: No CI/CD modifications

Key Security Observations

1. Safe Array Access: The code uses non-null assertions (!) but only after proper bounds checking in the LCS algorithm implementation.

2. Input Handling: All string inputs are processed safely without shell execution or unsafe deserialization.

3. File Operations: File content is handled through existing abstractions (readExisting callback) rather than direct filesystem access.

4. Memory Safety: The LCS algorithm has O(m*n) complexity which could consume significant memory for very large files, but this is a performance consideration rather than a security vulnerability.

5. Output Sanitization: The unified diff output is plain text without any executable content or special formatting that could be exploited.

Findings

NO SECURITY ISSUES FOUND

The code follows secure development practices:

• Uses safe string manipulation
• Implements proper bounds checking
• Avoids direct filesystem operations
• Contains no executable code generation
• Handles edge cases appropriately (null content, empty files)

This appears to be a well-implemented, security-conscious addition to the codebase.