Auto-sync .kiro/ from master (post-checkout hook)

.kiro/steering/workflow.md

@@ -25,55 +25,3 @@ Each spec folder typically contains:
 - Adding to an existing feature — check the spec to understand design constraints
 - Investigating unexpected behavior — the spec documents what "correct" looks like
 - Refactoring — the spec documents which properties must be preserved
-
----
-
-## Bug Fix Documentation
-
-When fixing something that is or could be considered a bug, document it with a bug report.
-
-### Process
-
-1. Fix the bug and commit to `master`
-2. Push to both `origin` and `backup` remotes
-3. Stash any uncommitted work: `git stash`
-4. Switch to the `ops/records` branch: `git checkout ops/records`
-5. Add a bug report under `docs/bug-reports/` with the naming convention `<area>-<short-description>-<YYYY-MM-DD>.md`
-6. Commit and push on `ops/records` to both `origin` and `backup`
-7. Switch back to `master`: `git checkout master`
-8. Restore specs (gitignored on master, wiped by branch switch): `git checkout ops/records -- .kiro/specs/` then `git reset HEAD .kiro/specs/`
-9. Pop stash: `git stash pop`
-
-### Bug Report Format
-
-Each bug report follows the **Symptom, Cause, Fix** pattern per bug:
-
-```markdown
-# <Title> — <Date>
-
-## Summary
-One paragraph describing the scope and root cause category.
-
-**Commit:** `<hash>` on `master`
-
----
-
-## Bug N: <Short Title>
-
-**Symptom:** What the user sees or experiences.
-
-**Cause:** The underlying technical reason.
-
-**Fix:** What was changed and why it resolves the issue.
-
-**Files changed:**
-- `path/to/file.js`
-```
-
-### What Qualifies as a Bug
-
-- Incorrect data display (wrong values, wrong format)
-- UI crashes or blank pages (unhandled exceptions)
-- Features that stopped working after a migration or refactor
-- Missing scope/filter application that was designed but not wired up
-- Regressions from dependency or platform changes (e.g., SQLite to PostgreSQL)