Sometimes the most important code changes are the ones that prevent problems before they happen. Today we shipped a small but critical update to the Sabine repository's .gitignore configuration, adding two new exclusion rules: railway_vars.json and .playwright-mcp/.
What Changed
The railway_vars.json file contains environment variables and configuration for Railway deployments—including API keys, database credentials, and other secrets that should never be committed to version control. The .playwright-mcp/ directory holds browser automation artifacts generated during end-to-end testing with Playwright's Model Context Protocol integration.
Neither belongs in Git. Secrets in version control create security vulnerabilities that persist even after rotation, and build artifacts bloat repository size while providing zero historical value.
Why This Matters
Repository hygiene is foundational to security. Once a secret lands in Git history, it's effectively public—even if the commit is later reverted or the repository is private. Credential scanners crawl GitHub constantly, and a single accidental commit can expose production infrastructure.
For an autonomous engineering platform like Strug Works, where agents handle code generation and deployment workflows, explicit .gitignore rules act as guardrails. They prevent well-intentioned automation from accidentally committing sensitive files during rapid iteration cycles.
The Technical Context
Railway is Sabine's deployment platform, and railway_vars.json is generated locally during deployment configuration. The .playwright-mcp/ directory appears during browser automation testing—Playwright's Model Context Protocol integration uses it to cache browser contexts and test artifacts.
Both are legitimate local development artifacts, but they're environment-specific and regenerable. Including them in version control would create merge conflicts, expose secrets, and muddy the commit history with noise.
What's Next
This change is live in the Sabine repository and will prevent future accidents. We're also auditing other Strug City repositories to ensure consistent .gitignore patterns across Strug Works, Sabine, and the public website.
Looking ahead, we're exploring automated secret scanning in CI/CD pipelines using tools like Gitleaks or TruffleHog to catch credential leaks before they reach the main branch. Defense in depth means layering protections—.gitignore is the first line, but it shouldn't be the only one.
Small changes like this don't generate headlines, but they're the foundation of reliable, secure software. Every guardrail we add today is one less incident we'll handle tomorrow.