[Infra] Implement Release Automation & Safety Enforcement

[arii]

We are standardizing our release workflow to prevent "bad" commits from reaching production and to automate version tagging. This task involves implementing a client-side verification model where every release is verified before tagging, and production deployments are gated by these tags.

This implementation covers three key areas:

1. Release Automation: Standardizing version bumps (patch/minor/major).
2. Local Safety: A git hook to prevent modifying source code without updating the verification proof.
3. Production Safety: A deployment check to ensure only tagged releases are deployed.

Assignee: @[Developer Name]
Priority: High
Related Issues: #470, #471

---

📋 Tasks

• Step 1: Update package.json
  • Add verify, commit:verified, and release:* scripts to standardize the workflow.
• Step 2: Create Pre-commit Hook
  • Create .git/hooks/pre-commit to block commits that touch source code but fail to update test-proof.json.
• Step 3: Secure deploy.sh
  • Add a safety check at the top of the deployment script to verify that the package.json version matches the latest Git tag.
• Step 4: Update Documentation
  • Update TESTING.md with the new verification workflow.
  • Update DEVELOPMENT.md with new action items and workflow notes.

---

💻 Implementation Details

1. package.json Updates

Add the following scripts to the scripts section:

"scripts": {
  // ... existing scripts
  "verify": "ts-node scripts/verify-and-publish.ts",
  "commit:verified": "npm run verify && git add test-proof.json && git commit",
  "release:patch": "npm run verify && npm version patch && git push --follow-tags",
  "release:minor": "npm run verify && npm version minor && git push --follow-tags",
  "release:major": "npm run verify && npm version major && git push --follow-tags"
}

2. Git Hook (.git/hooks/pre-commit)

Create this file and ensure it is executable (chmod +x .git/hooks/pre-commit).

#!/bin/bash
# .git/hooks/pre-commit

# 1. Check if we are modifying source code
STAGED_SRC=$(git diff --cached --name-only | grep -E "^(app|components|lib|hooks|services|tests|server.ts)/")

if [ -n "$STAGED_SRC" ]; then
    # 2. Check if test-proof.json is ALSO staged
    STAGED_PROOF=$(git diff --cached --name-only | grep "test-proof.json")
    
    if [ -z "$STAGED_PROOF" ]; then
        echo "⛔️  STOP! You are modifying source code but 'test-proof.json' is not updated."
        echo "    The CI Integrity Guard will reject this commit."
        echo ""
        echo "👉  Solution: Run 'npm run commit:verified' instead of 'git commit'."
        exit 1
    fi
fi

3. Deployment Safety (deploy.sh)

Insert this block at the top of deploy.sh (after set -e):

# --- SAFETY CHECK ---
git fetch --tags
LATEST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "none")
CURRENT_VER=$(node -p "require('./package.json').version")

if [[ "v$CURRENT_VER" != "$LATEST_TAG" ]]; then
    echo "⚠️  WARNING: Mismatch detected! Version: v$CURRENT_VER, Tag: $LATEST_TAG"
    echo "    You are deploying untagged code."
    read -p "    Are you sure you want to continue? (y/n) " -n 1 -r
    echo
    if [[ ! $REPLY =~ ^[Yy]$ ]]; then
        echo "❌ Deployment cancelled."
        exit 1
    fi
fi

4. Documentation

• TESTING.md: Add a "Release Verification" section explaining npm run commit:verified.
• DEVELOPMENT.md: Update "Current Workflow" to reflect that direct commits should be avoided in favor of verified commits.

---

✅ Acceptance Criteria

1. Running npm run release:patch successfully runs tests, bumps the version, and pushes tags.
2. Trying to git commit changes to server.ts without running the verifier is blocked by the hook.
3. Running deploy.sh on a version that hasn't been tagged triggers a warning prompt.

[google-labs-jules]

Jules is on it. When finished, you will see another comment and be able to review a PR.

[google-labs-jules]

Ready for a review! A PR has been created.

[arii]

Hi team, PR #476 'Automate CI Verification and Proof Submission' significantly automates a key aspect of our CI verification. Does this PR address a substantial part of the release automation and safety enforcement outlined in this epic, or are there further components that still need to be implemented for this issue?

[arii]

Hi team, PR #476 'Automate CI Verification and Proof Submission' significantly automates a key aspect of our CI verification. Does this PR address a substantial part of the release automation and safety enforcement outlined in this epic, or are there further components that still need to be implemented for this issue?

[arii]

Hi team, PR #476 'Automate CI Verification and Proof Submission' significantly automates a key aspect of our CI verification. Does this PR address a substantial part of the release automation and safety enforcement outlined in this epic, or are there further components that still need to be implemented for this issue?

[arii]

A series of recent PRs, including #476 (Automate CI Verification), #474/#471 (Implement Local Test Reporter), #478 (Improve verification script feedback), and #470 (Create infrastructure test suite), have made substantial progress towards improving our release automation and safety enforcement. Given these updates, do you feel the core objectives of this issue have been sufficiently addressed, or are there specific remaining areas of concern for release automation and safety?