appydave-tools 0.20.0 → 0.20.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fa0d28f2da43b19537700a122baaea2401ea5c7b545d687a1bff64150d1c7d88
-  data.tar.gz: 98b8575d8af3b09e0dbc025b076d9b221d0d5b28705ee714a2483f74022c73c6
+  metadata.gz: ad2e56b8d8b3c9a1cb3e97bf6a020dff3c912ae6d22be2188104276cf952a0cf
+  data.tar.gz: ba06bb06e615d282df69ccb5b52a1f5b5264f02dfd7af574e86a71721cec1633
 SHA512:
-  metadata.gz: 2f3c69c161ac3b1ca8642db8d1f6a15317510956ffe396635d6bf2f49e1be6bc6b22c4b5b9e9694b9b40ffbb9214da8487979078740a68a0b2dcec7c07a42ba1
-  data.tar.gz: de05f01bba2420b7c287cd28ac499ca56af5b7277c88522d867280e27be99d821baf2cb9d389beefe0c3e6573b6eee6095c0eafdd1a2806f1e49ec782f0de54f
+  metadata.gz: 53ba4ece9f3f7d7c8fe29107b9059018285a382acb02a1f26275d0b41a95745402dbe74d9609a6a089c73c0ec92ce320df58fa50b8bbd4b17578f0d84234bc1a
+  data.tar.gz: 927899c39261f330ceb73387a8598023a5c642cec24e5753ddde063af545a7aa373ac07969c6f0ee5c69ed2ee76b4f75d871c96cce2d015ef81d7fae6b532fab

data/CHANGELOG.md

@@ -1,3 +1,11 @@
+# [0.20.0](https://github.com/appydave/appydave-tools/compare/v0.19.0...v0.20.0) (2025-11-10)
+
+
+### Features
+
+* Phase 2: add unified status and git repo commands (status, repo-status, repo-sync, repo-push) ([c9ff7de](https://github.com/appydave/appydave-tools/commit/c9ff7dee9bd2d60954205df08c23dd673960a524))
+* Phase 2: add unified status and git repo commands (status, repo-status, repo-sync, repo-push) ([b74f343](https://github.com/appydave/appydave-tools/commit/b74f3436e188cfa7dbdff386d35cb96d75f80860))
+
 # [0.19.0](https://github.com/appydave/appydave-tools/compare/v0.18.5...v0.19.0) (2025-11-10)
 
 

data/bin/dam

@@ -414,6 +414,14 @@ class VatCLI
         help [command]              Show help information
         list [brand] [pattern]      List brands/projects
 
+        Status & Monitoring:
+        status [brand] [project]         Show unified status (local/S3/SSD/git)
+
+        Git Repository Commands:
+        repo-status <brand> [--all]      Check git status for brand repos
+        repo-sync <brand> [--all]        Pull updates for brand repos
+        repo-push <brand> [project]      Push changes for brand repo
+
         S3 Sync Commands:
         s3-up <brand> <project>          Upload to S3 staging
         s3-down <brand> <project>        Download from S3 staging
@@ -438,6 +446,10 @@ class VatCLI
 
       Examples:
         dam list
+        dam status appydave
+        dam status appydave b65
+        dam repo-status appydave
+        dam repo-sync appydave
         dam s3-up appydave b65
         dam s3-down voz boy-baker --dry-run
         dam s3-status appydave b65

data/docs/dam/dam-testing-plan.md

@@ -1,6 +1,6 @@
 # DAM (Digital Asset Management) - Integration Testing Plan
 
-**Date**: 2025-11-08
+**Date**: 2025-11-10
 **Purpose**: Validate DAM integration into appydave-tools gem
 **Tester**: David Cruwys
 **Status**: Ready for User Acceptance Testing
@@ -37,25 +37,17 @@
 - ✅ `dam archive` - Archive to SSD with dry-run and force options
 - ✅ `dam sync-ssd` - Restore light files from SSD (dry-run supported)
 
-**Git Repository Management Scripts - Intentionally Not Migrated**:
+**Commands - Phase 4 Complete** (Status & Git Integration):
+- ✅ `dam status` - Unified status view (local/S3/SSD/git)
+- ✅ `dam repo-status` - Git status for brand repositories (supports `--all`)
+- ✅ `dam repo-sync` - Pull updates for brand repositories (supports `--all`)
+- ✅ `dam repo-push` - Push changes for brand repository (optional project validation)
 
-These are **shell scripts** for managing the multi-repo video-projects git structure, NOT video asset management commands:
-
-- ❌ `status-all.sh` - Runs `git status` on all v-* brand repos (git workflow, not asset management)
-- ❌ `sync-all.sh` - Runs `git pull` on all v-* brand repos (git workflow, not asset management)
-- ❌ `clone-all.sh` - Clones all v-* brand repos if missing (git workflow, not asset management)
-
-**Why not migrated:**
-1. These manage **git repositories**, not **video assets**
-2. They loop through brand folders running git commands
-3. They're workflow automation for the video-projects repo structure
-4. They belong in `/video-projects/v-shared/`, not in the appydave-tools gem
-5. Different use case: repo management vs. video file management
-
-**If you want these migrated:** We could add `dam repo-status`, `dam repo-sync`, `dam repo-clone` commands, but they would:
-- Need Ruby implementations of multi-repo git operations
-- Duplicate functionality that shell scripts handle well
-- Mix concerns (video assets vs. git repos)
+**New Manifest Fields (Phase 4)**:
+- ✅ `git_remote` - Self-healing git remote URL detection in brands.json
+- ✅ `s3: { exists: true/false }` - S3 staging folder tracking in manifest
+- ✅ `type: 'flivideo' | 'storyline-app'` - Project type detection
+- ✅ `hasStorylineJson: true/false` - Storyline project identification
 
 ---
 
@@ -150,10 +142,19 @@ These commands only read data and don't modify files:
 | Command | Type | What It Does |
 |---------|------|--------------|
 | **list** | Read-only | List brands/projects |
+| **status** | Read-only | Show unified status (local/S3/SSD/git) |
+| **repo-status** | Read-only | Check git status for brand repos |
 | **manifest** | Generates JSON | Generate `projects.json` manifest |
 | **s3-status** | Read-only | Check sync status |
 | **help** | Read-only | Show help information |
 
+### Git Commands (Special Behavior)
+
+| Command | Type | What It Does | Safety Features |
+|---------|------|--------------|-----------------|
+| **repo-sync** | Modifies (git pull) | Pull updates for brand repos | Skips if uncommitted changes |
+| **repo-push** | Modifies (git push) | Push changes for brand repo | Warns if uncommitted changes, optional project validation |
+
 ### Force Flag Behavior
 
 Commands requiring `--force` provide extra protection for destructive operations:
@@ -418,6 +419,115 @@ bin/s3_sync_cleanup.rb --dry-run
 
 ---
 
+#### Test 2.15: Status - Brand Overview ⭐ PHASE 4
+```bash
+# Test: Show unified status for entire brand
+bin/dam status appydave
+```
+**Expected**: Shows brand git status, manifest summary (total projects, local, S3, SSD counts)
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.16: Status - Specific Project ⭐ PHASE 4
+```bash
+# Test: Show detailed status for specific project
+bin/dam status appydave b65
+```
+**Expected**: Shows storage locations (local, S3 staging, SSD backup) and git status for project
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.17: Status - Auto-Detect ⭐ PHASE 4
+```bash
+# Test: Auto-detect brand and project from PWD
+cd ~/dev/video-projects/v-appydave/b65-*
+bin/dam status
+```
+**Expected**: Auto-detects and shows project status
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.18: Repo Status - Single Brand ⭐ PHASE 4
+```bash
+# Test: Show git status for single brand
+bin/dam repo-status appydave
+```
+**Expected**: Shows branch, remote, working directory status, sync status
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.19: Repo Status - All Brands ⭐ PHASE 4
+```bash
+# Test: Show git status for all brands
+bin/dam repo-status --all
+```
+**Expected**: Shows git status for all configured brands (appydave, voz, aitldr, etc.)
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.20: Repo Sync - Single Brand ⭐ PHASE 4
+```bash
+# Test: Pull updates for single brand
+bin/dam repo-sync appydave
+```
+**Expected**: Pulls updates if available, skips if uncommitted changes, shows status
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.21: Repo Sync - All Brands ⭐ PHASE 4
+```bash
+# Test: Pull updates for all brands
+bin/dam repo-sync --all
+```
+**Expected**: Syncs all brands, shows summary, skips brands with uncommitted changes
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.22: Repo Push - Basic ⭐ PHASE 4
+```bash
+# Test: Push changes for brand (no project validation)
+bin/dam repo-push appydave
+```
+**Expected**: Pushes commits, shows push summary
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
+#### Test 2.23: Repo Push - With Project Validation ⭐ PHASE 4
+```bash
+# Test: Push with project validation
+bin/dam repo-push appydave b65
+```
+**Expected**: Validates project exists in manifest before pushing, shows validation message
+
+**Status**: [ ] Pass [ ] Fail
+**Notes**: ___________________________________________
+
+---
+
 ### Phase 3: Gem Installation Tests (Manual - Installed Gem)
 
 **Prerequisites**: `gem install pkg/appydave-tools-*.gem`
@@ -670,31 +780,18 @@ All video asset management commands have been successfully migrated and are full
 - ✅ `dam archive` - Archive to SSD (dry-run + optional force)
 - ✅ `dam sync-ssd` - Restore light files from SSD (dry-run)
 
+### Phase 4: Status & Git Integration
+- ✅ `dam status` - Unified status view (local/S3/SSD/git)
+- ✅ `dam repo-status` - Git status for brand repositories (`--all` support)
+- ✅ `dam repo-sync` - Pull updates for brand repositories (`--all` support)
+- ✅ `dam repo-push` - Push changes with optional project validation
+
 ### All Commands Support:
 - **CLI args**: `dam <command> <brand> <project>`
 - **Auto-detect**: Works from project directory (where applicable)
 - **Dry-run**: All destructive operations support `--dry-run`
 - **Force flags**: Extra safety for deletions
-
----
-
-## Git Repository Scripts - Separate Concern
-
-The following shell scripts are **intentionally not migrated** as they manage git repositories, not video assets:
-
-### `/video-projects/v-shared/*.sh`
-
-- `status-all.sh` - Runs `git status` on all v-* brand repos
-- `sync-all.sh` - Runs `git pull` on all v-* brand repos
-- `clone-all.sh` - Clones missing v-* brand repos
-
-**Why separate:**
-1. Different domain: Git repository management vs. video asset management
-2. Different tools: Shell + git commands vs. Ruby + AWS/file operations
-3. Different location: Belongs in video-projects workspace, not in distributed gem
-4. Shell scripts work perfectly for this use case
-
-**If migration is desired:** Could add `dam repo-status/sync/clone` but would duplicate working shell functionality and mix concerns.
+- **Git integration**: Unified status + repo management commands
 
 ---
 
@@ -707,8 +804,8 @@ The following shell scripts are **intentionally not migrated** as they manage gi
 - **TOTAL**: **64 / 64 ✅**
 
 ### Phase 2: Integration Tests (Manual - Development)
-- Passed: _____ / 13
-- Failed: _____ / 13
+- Passed: _____ / 23
+- Failed: _____ / 23
 
 ### Phase 3: Gem Installation Tests (Manual - Installed)
 - Passed: _____ / 6
@@ -728,8 +825,8 @@ The following shell scripts are **intentionally not migrated** as they manage gi
 
 ### **GRAND TOTAL**
 - **Unit Tests**: 64 / 64 ✅
-- **Manual Tests**: _____ / 29
-- **Overall**: _____ / 93
+- **Manual Tests**: _____ / 39
+- **Overall**: _____ / 103
 
 ---
 
@@ -832,8 +929,8 @@ The following shell scripts are **intentionally not migrated** as they manage gi
 
 **Then manual development tests** (safest first):
 2. Phase 2.1-2.5: Help and list commands
-3. Phase 2.6-2.7: S3 upload with dry-run
-4. Phase 2.8-2.13: Phase 2 commands (download, status, cleanup) with dry-run
+3. Phase 2.6-2.14: S3 commands (upload, download, status, cleanup) with dry-run
+4. Phase 2.15-2.23: Phase 4 commands (status, repo-status, repo-sync, repo-push) ⭐ NEW
 5. Phase 4: Edge cases and error handling
 
 **Then gem installation tests**:

data/docs/development/CODEX-recommendations.md

@@ -1,6 +1,6 @@
 # CODEX Recommendations - Review & Status
 
-> Last updated: 2025-11-10 08:12:59 UTC
+> Last updated: 2025-11-10 11:01:36 UTC
 > Original recommendations provided by Codex (GPT-5) on 2025-11-09
 
 This document captures Codex's architectural recommendations with implementation status and verdicts after engineering review.
@@ -148,16 +148,20 @@ end
 
 ### 🔍 DAM Manifest & Sync Addendum (2025-11-10)
 
-New DAM code mirrors the VAT manifest/sync flow but reintroduces several bugs plus new inconsistencies:
+Phase 1 added S3/git metadata, but several inconsistencies remain between the manifest generator and the SSD sync tooling:
 
-- **Archived projects still missing:** `collect_project_ids` explicitly skips the `archived` directory (`lib/appydave/tools/dam/manifest_generator.rb:70-99`), so the later logic that probes `brand_path/archived/<range>/<project>` never runs; manifests omit the majority of historical work. This also means `SyncFromSsd.should_sync_project?` (`lib/appydave/tools/dam/sync_from_ssd.rb:77-96`) will think everything is already local because manifests never flag archived presence.  
-- **Range math diverges between components:** Manifest uses `project_id =~ /^[a-z](\d+)/` to build ranges (`lib/appydave/tools/dam/manifest_generator.rb:214-224`), but the SSD sync hard-codes `/^b(\d+)/` (`lib/appydave/tools/dam/sync_from_ssd.rb:123-138`). Projects outside the `b` prefix (aitldr, voz, etc.) will all collapse into the fallback `000-099`, creating collisions.  
-- **SSD paths lose grouping info:** Manifests record `path: project_id` for SSD entries (`lib/appydave/tools/dam/manifest_generator.rb:119-126`), ignoring the range folders that exist on disk. The sync tool then assumes `ssd/<project_id>` (line 98) and will fail whenever the SSD organizes projects under range subdirectories.  
-- **Disk usage ignores archived location:** Even when a project only exists under `archived/<range>`, `calculate_disk_usage` points at `File.join(brand_path, project[:id])` (`lib/appydave/tools/dam/manifest_generator.rb:131-146`), so archived-only projects report 0 bytes. Need to reuse the resolved `local_path` (flat vs archived) instead of rebuilding the path blindly.  
-- **Heavy file detection still shallow:** `heavy_files?` only inspects direct children (`lib/appydave/tools/dam/manifest_generator.rb:233-239`), while `light_files?` walks `**/*`. Any team that keeps footage under nested folders (e.g., `/final/video.mp4`) gets `has_heavy_files: false`, which downstream sync logic relies on.  
-- **Sync exclusion filter misidentifies generated folders:** `EXCLUDE_PATTERNS` contain glob syntax (`**/node_modules/**`, `**/.DS_Store`), but `excluded_file?` strips `**/` and compares raw path segments (`lib/appydave/tools/dam/sync_from_ssd.rb:160-182`), so patterns like `.DS_Store` or `.turbo` may still slip through or block unrelated files. Consider using `File.fnmatch` with the original glob rather than manual string surgery.
+- **Range directories are inconsistent:** `ManifestGenerator#determine_range` groups projects in 50-count buckets per letter (`lib/appydave/tools/dam/manifest_generator.rb:271-285`), but `SyncFromSsd#determine_range` still assumes only `b`-series projects and uses 10-count buckets (`lib/appydave/tools/dam/sync_from_ssd.rb:186-196`). Any non-`b` brand (AITLDR, VOZ) or the new 50-count scheme will pick the wrong destination folder.  
+- **SSD paths are lossy:** Manifests store `storage[:ssd][:path] = project_id` even when the data actually lives under `ssd/<range>/<project>` (`lib/appydave/tools/dam/manifest_generator.rb:178-185`). `SyncFromSsd#sync_project` then only checks `ssd/<project>` (`lib/appydave/tools/dam/sync_from_ssd.rb:162-170`), so range-based backups always report “SSD path not found” despite `ssd_exists: true` in the manifest. Persist the relative range folder so both tools agree on the same layout.  
+- **Heavy file detection still stops at the top level:** `heavy_files?` only scans `dir/*.{mp4,...}` (`lib/appydave/tools/dam/manifest_generator.rb:314-318`), so nested footage (e.g., `final/video.mp4`) reports `has_heavy_files: false`, skewing SSD/cleanup metrics. Mirror the recursive approach used in `light_files?`.  
+- **Exclude patterns are fragile:** `SyncFromSsd#excluded_file?` strips `**/` from patterns and only compares path segments (`lib/appydave/tools/dam/sync_from_ssd.rb:198-223`), which means globs like `**/.DS_Store` or `**/*.lock` do not behave like actual glob patterns. Replace the manual parsing with `File.fnmatch?(pattern, relative_path, File::FNM_PATHNAME | File::FNM_DOTMATCH)` so `.git`, `.turbo`, etc., are consistently ignored.
 
-Action: Fold these findings into the existing VAT manifest backlog or spin up DAM‑specific tickets so both manifest implementations converge on a single, tested service.
+Action: Align the manifest and sync code on the same range conventions and relative paths before we rely on Phase 2 git workflows; otherwise `dam sync-ssd` will never restore the projects that manifests say exist.
+
+### ⚠️ DAM Git Workflow (Phase 2)
+
+- **Project resolver instantiated incorrectly:** Both `Status#resolve_project_path` and `RepoPush#validate_project` call `ProjectResolver.new.resolve` (`lib/appydave/tools/dam/status.rb:36-40`, `lib/appydave/tools/dam/repo_push.rb:45-63`), but `ProjectResolver` only exposes class methods inside `class << self`. These code paths raise `NoMethodError` the moment you ask for project status or run `dam repo-push … <project>`. Switch to `ProjectResolver.resolve(...)` (or add an instance API) before shipping.  
+- **Auto-detected brands pollute configuration:** When you run `dam status` from inside `v-appydave`, the auto-detect logic passes the literal `v-appydave` string (`bin/dam:269-290`) into `Status`, which in turn calls `Config.git_remote`. That method persists the inferred remote under whatever key it was given (`lib/appydave/tools/dam/config.rb:43-71`), so a new `v-appydave` entry gets written to `brands.json`, duplicating the real `appydave` record. Normalize auto-detected names back to the canonical brand key before calling configuration APIs.  
+- **Naming drift in the CLI:** `bin/dam` still defines `class VatCLI` (line 11), so stack traces and help output reference the old VAT class name. Rename the class (and any references) to avoid confusion when both `vat` and `dam` binaries coexist.
 
 ---
 

data/lib/appydave/tools/configuration/models/config_base.rb

@@ -20,11 +20,10 @@ module Appydave
           end
 
           def save
-            # Create backup if file exists
+            # Create backup if file exists (silent for self-healing operations)
             if File.exist?(config_path)
               backup_path = "#{config_path}.backup.#{Time.now.strftime('%Y%m%d-%H%M%S')}"
               FileUtils.cp(config_path, backup_path)
-              log.info "Backup created: #{backup_path}" if respond_to?(:log)
             end
 
             File.write(config_path, JSON.pretty_generate(data))

data/lib/appydave/tools/version.rb

@@ -2,6 +2,6 @@
 
 module Appydave
   module Tools
-    VERSION = '0.20.0'
+    VERSION = '0.20.1'
   end
 end

data/package.json

@@ -1,6 +1,6 @@
 {
   "name": "appydave-tools",
-  "version": "0.20.0",
+  "version": "0.20.1",
   "description": "AppyDave YouTube Automation Tools",
   "scripts": {
     "release": "semantic-release"

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: appydave-tools
 version: !ruby/object:Gem::Version
-  version: 0.20.0
+  version: 0.20.1
 platform: ruby
 authors:
 - David Cruwys