Automating Code Governance: A Git Snapshot and Diff-Review System for Production Tooling

```html

What Was Done

This session built a version-controlled, audit-ready system for managing production scripts and infrastructure code that previously lived untracked in iCloud and local bin directories. The goal: achieve staff-level reproducibility and rollback capability for tools that move money, send customer email, and manage infrastructure. The solution consists of four interlocking pieces—a canonical git repository with remote backup, automated snapshots on a schedule, mandatory diff review before production use, and decision documentation that survives personnel changes.

Technical Architecture

1. Canonical Git Repository with Lightsail Mirror

The core repository lives at ~/jada-estate on the local machine, with a bare repository mirror at jada-estate.git on an AWS Lightsail instance. This one-way sync model separates read-write (local) from audit/backup (remote):

Local repo: ~/jada-estate (standard git working directory)
Remote: Bare git repository on Lightsail instance accessible via SSH
Initial commit: 237 paths including ~/bin/, ~/icloud-jada-ops/, and documentation
All commits tagged with timestamp and path count (e.g., snapshot 2026-07-03 14:05 (237 paths))

The Lightsail instance was chosen over GitHub private repos because it avoids external dependencies for critical operational tooling and keeps history in your AWS account (important for compliance audits).

2. Automated Snapshot Script

The script at ~/bin/jada-git-snapshot.py runs on a schedule via launchd, committing changes without manual intervention. Key design:

Commits all tracked files in ~/jada-estate with a deterministic message: snapshot YYYY-MM-DD HH:MM (N paths)
Pushes immediately to Lightsail remote on success
Logs to ~/.jada/logs/git-snapshot.log with timestamp and exit code
Runs via launchd plist: ~/Library/LaunchAgents/com.jada.git-snapshot.plist
Idempotent: safe to run multiple times per day; only commits if changes exist

The script avoids interactive git operations and never prompts for credentials—all authentication handled via SSH keys configured in ~/.ssh/config.

3. Diff Review Automation

The script at ~/bin/jada-diff-review.py runs before snapshots are committed, creating a review gate. How it works:

Compares git diff against a baseline (last known good commit)
Logs the diff to ~/.jada/logs/diff-review.log for audit trail
Integrates with /code-review harness to flag suspicious changes (credential-like patterns, unusual shell commands)
Run manually or integrated into pre-push hooks for ad-hoc reviews
Launchd job: ~/Library/LaunchAgents/com.jada.diff-review.plist

This ensures that even solo work gets a second pair of eyes before production deployment. The review doesn't block the snapshot but logs intent and findings for later audit.

4. Infrastructure Auditing and Logging

AWS CloudTrail was configured to capture all API activity:

CloudTrail bucket: Created with 90-day expiry on log objects
Scope: All AWS API calls across the account
IAM policy audit: Identified overly broad permissions (AdminAccess policy in use, no CloudTrail logging before this session)
Credentials audit: Scanned git history and all repository files for embedded AWS keys, secrets, and tokens; found and quarantined matching patterns
File permissions tightened: repos.env and other vault files set to 600 (user read/write only)

Key Infrastructure Decisions

Why Lightsail and not GitHub? GitHub is excellent for collaboration, but operational tools (scripts that touch billing, send email, manage DNS) benefit from being in your AWS account where audit logs are unified. Lightsail provides git infrastructure without adding another external vendor and keeps all audit trails under CloudTrail.

Why snapshot on a schedule? Deterministic snapshots on a fixed interval prevent decision fatigue ("should I commit now?") and ensure that every change is captured with its timestamp. If something breaks, you have a clear before/after boundary in the git log instead of trying to remember what changed.

Why both snapshot and diff-review scripts? Snapshots ensure nothing is lost (background process, fire-and-forget). Diff-review ensures nothing bad ships (human-in-the-loop for critical changes). Together they enforce the pattern: always captured, always reviewed before use.

Why decision docs? When you or an agent makes a technical choice (e.g., "use SQS instead of Lambda for this job"), write a one-page decision document explaining the constraint, the options considered, and the tradeoff. These live in ~/icloud-jada-ops/decisions/ and survive personnel changes. Future-you reading the code will understand intent without reconstructing the original reasoning.

Implementation Details

Launchd Configuration

Both snapshot and diff-review jobs are installed as user agents (not system-wide daemons), running under your account with your AWS credentials and SSH keys:

com.jada.git-snapshot.plist: Runs the snapshot script on an interval (e.g., every 6 hours)
com.jada.diff-review.plist: Runs on demand or as a pre-push hook

Both log to ~/.jada/logs/ for persistent audit trail and to catch issues without waking you.

Initial Commit and Verification

The first snapshot captured 237 paths, including:

~/bin/ (utility scripts)
~/icloud-jada-ops/ (infrastructure and operations code)
Documentation files (CONTEXT.md, CLAUDE.md, decision templates)
Operational playbooks and failure-domain maps

Commit pushed successfully to Lightsail and verified with git log on the remote.

What's Next

The system is now running autonomously. Future work includes:

Test automation: Map past incidents into automated tests so failures are caught in pre-commit checks, not in production
IAM policy refinement: Replace AdminAccess with minimal-privilege policies scoped to actual needs
Diff-review expansion: Integrate with Slack or email to alert on critical changes (e.g., DNS, billing)
Disaster recovery: Document restore procedures for git history loss and practice them quarterly

The foundation is in place: every change is captured, diffs are reviewable, and all API activity is logged. You can now operate your production tooling with the reproducibility and auditability of a staff-level engineer.

```