feat: improved demo videos and consistent CLI colors

[t1mmen]

User description

Summary

• Redesigned demo videos with clearer storytelling
• Implemented consistent color semantics across CLI output
• Added workflow demo showing WIP template flow

Demo Videos

Hero Demo (readme-demo.gif)

Shows the core workflow in ~25 seconds:

1. The problem: changing a function = new migration file
2. With SRTD: templates are the source of truth
3. Edit template → apply → build → done

Workflow Demo (readme-workflow-demo.gif)

Shows WIP templates (placed in README under WIP Templates section):

1. Create .wip.sql for experimentation
2. Apply works locally, build excludes it
3. Promote when ready → now it builds

Color Semantics

Consistent coloring across all CLI output:

Status	Color	Meaning
success/built	GREEN	Just acted on
unchanged	DIM	No action taken
skipped (WIP)	YELLOW	Needs attention
error	RED	Problem

Previously only icons were colored; now the entire row reflects the action status.

Test Plan

• All tests pass
• Typecheck passes
• Frame-by-frame verification of both demos

🤖 Generated with Claude Code

---

PR Type

Enhancement, Documentation

---

Description

• Implemented consistent color semantics across CLI output (green=success, dim=unchanged, yellow=WIP, red=error)

• Redesigned demo videos with clearer storytelling approach (Pain → Discovery → Delight narrative)

• Restructured shipped templates with pre-built migrations and cleaned up demo state

• Added WIP workflow demo showing template experimentation and promotion flow

---

Diagram Walkthrough

flowchart LR
  A["CLI Output"] -->|"Apply consistent coloring"| B["Color Semantics"]
  B -->|"Green = success"| C["Built/Applied"]
  B -->|"Dim = unchanged"| D["No Action"]
  B -->|"Yellow = WIP"| E["Needs Attention"]
  B -->|"Red = error"| F["Problem"]
  G["Demo Videos"] -->|"Hero demo"| H["Pain → Discovery → Delight"]
  G -->|"Workflow demo"| I["WIP Templates Flow"]
  J["Templates"] -->|"3 shipped templates"| K["Pre-built Migrations"]
  J -->|"Demo template"| L["get_user_email"]

Loading

File Walkthrough

	Relevant files
Enhancement	6 files watch.ts Add consistent color semantics to stacked events                  +10/-2    resultsTable.ts Apply consistent coloring to all result rows                          +28/-11  srtd_demo_get_user_email.sql Add utility function template for workflow demo                    +12/-0    20251230191156_srtd-srtd_demo_audit.sql Add pre-built audit trigger migration                                        +28/-0    20251230191157_srtd-srtd_demo_greet.sql Add pre-built greeting function migration                                +24/-0    20251230191158_srtd-srtd_demo_rls.sql Add pre-built RLS policy migration                                              +37/-0
Configuration changes	2 files record_demo.sh Clean up demo recording setup and state                                    +14/-14  .srtd.buildlog.json Update buildlog with 3 shipped templates                                  +15/-5
Documentation	4 files consistent-colors.md Document color semantics patch release                                      +5/-0      README.md Add workflow demo and update demo references                          +3/-1      readme-demo.tape Redesign hero demo with storytelling narrative                      +51/-113 readme-workflow-demo.tape Create new WIP templates workflow demo                                      +106/-0
Miscellaneous	2 files test.sql Remove old test template file                                                        +0/-6      20241230164858_tmpl-test.sql Remove old test migration file                                                      +0/-14
Additional files	3 files srtd_demo_audit.sql [link]    srtd_demo_greet.sql [link]    srtd_demo_rls.sql [link]

---

[changeset-bot]

🦋 Changeset detected

Latest commit: 608f4ea

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@t1mmen/srtd	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codecov]

Codecov Report

❌ Patch coverage is 81.81818% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.00%. Comparing base (79f8254) to head (608f4ea).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/commands/watch.ts	60.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #64      +/-   ##
==========================================
+ Coverage   79.85%   80.00%   +0.15%     
==========================================
  Files          46       46              
  Lines        2219     2221       +2     
  Branches      546      546              
==========================================
+ Hits         1772     1777       +5     
+ Misses        447      444       -3     

Flag	Coverage Δ
e2e	80.00% <81.81%> (+0.15%)	⬆️
unittests	80.00% <81.81%> (+0.15%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[qodo-free-for-open-source-projects]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🔴	Sensitive information exposure Description: The get_user_email() function uses SECURITY DEFINER to query the auth.users table, which contains sensitive user information. This allows any user who can execute this function to retrieve email addresses for any user ID, bypassing normal access controls on the auth schema. srtd_demo_get_user_email.sql [4-10] Referred Code CREATE OR REPLACE FUNCTION public.get_user_email(user_id uuid) RETURNS text LANGUAGE sql SECURITY DEFINER AS $$ SELECT email FROM auth.users WHERE id = user_id; $$;
⚪	Unnecessary SECURITY DEFINER Description: The set_timestamps() function uses SECURITY DEFINER which executes with the privileges of the function owner, potentially allowing privilege escalation if the function owner has elevated permissions. This is unnecessary for a simple timestamp trigger function that only modifies the NEW record. srtd_demo_audit.sql [9-21] Referred Code BEGIN IF TG_OP = 'INSERT' THEN NEW.created_at := COALESCE(NEW.created_at, now()); END IF; NEW.updated_at := now(); RETURN NEW; END; $$; COMMENT ON FUNCTION public.set_timestamps IS 'Trigger function to auto-update timestamp columns';
	Unnecessary SECURITY DEFINER Description: The greet() function uses SECURITY DEFINER which executes with the privileges of the function owner. This is unnecessary for a simple greeting function that performs no privileged operations, and could be exploited if the function owner has elevated database permissions. srtd_demo_greet.sql [9-17] Referred Code BEGIN RETURN 'Hello, ' || name || '!'; END; $$; COMMENT ON FUNCTION public.greet IS 'Returns a friendly greeting message';
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-free-for-open-source-projects]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Security	Remove unnecessary elevated function privileges In the greet function, change SECURITY DEFINER to SECURITY INVOKER to adhere to the principle of least privilege, as the function does not require elevated permissions. supabase/migrations/20251230191157_srtd-srtd_demo_greet.sql [9-17] CREATE OR REPLACE FUNCTION public.greet(name text DEFAULT 'World') RETURNS text LANGUAGE plpgsql -SECURITY DEFINER +SECURITY INVOKER AS $$ BEGIN RETURN 'Hello, ' || name || '!'; END; $$; Apply / Chat Suggestion importance[1-10]: 7 __ Why: This is a valid security hardening suggestion that correctly points out the unnecessary use of SECURITY DEFINER, promoting the principle of least privilege in the new SQL function.	Medium
Possible issue	Improve script portability across operating systems To ensure the demo script runs on both macOS and Linux, replace the non-portable sed -i '' command with a compatible alternative that creates and then removes a backup file. readme-demo.tape [52-53] # Make a tiny, visible change -Type "sed -i '' 's/Hello/Howdy/' supabase/migrations-templates/srtd_demo_greet.sql" +Type "sed -i.bak 's/Hello/Howdy/' supabase/migrations-templates/srtd_demo_greet.sql && rm supabase/migrations-templates/srtd_demo_greet.sql.bak" Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies a portability issue with sed -i '' that would cause the demo script to fail on Linux, and the proposed fix is a valid cross-platform solution.	Low
General	Refactor status check into helper For improved maintainability, refactor the success status check (status === 'success' || status === 'built') into a dedicated isSuccessStatus helper function. src/ui/resultsTable.ts [198-199] +const isSuccessStatus = (status: TemplateResult['status']) => + status === 'success' || status === 'built'; + // Count both 'success' (applied) and 'built' as successful actions -const successCount = results.filter(r => r.status === 'success' || r.status === 'built').length; +const successCount = results.filter(r => isSuccessStatus(r.status)).length; Apply / Chat Suggestion importance[1-10]: 3 __ Why: The suggestion offers a minor refactoring for maintainability by creating a helper function, but it adds complexity for a simple condition that is only used once in the file.	Low
More