chore(pql): file T-1 — settings.local.json is tracked and should not be

First ticket in this repo's vault, so the changelog files are new. Committed
because the database is gitignored and the changelog is what makes a ticket
travel with a clone (workspace D-15); uncommitted, this ticket would exist only
on one machine.

The bug itself: .gitignore has listed .claude/settings.local.json since it was
added, and line 130 even carries the git rm --cached command, but gitignore does
not apply to paths git already tracks — so the rule has been inert the whole
time. This is the only repo in the workspace where that file is tracked.

No credentials were ever committed; both existing versions hold four permission
rules and no env keys, checked per commit rather than only at HEAD. The ticket
records that explicitly, because a previous survey misread this same file as
credentials across nine repos and the correction is worth keeping attached to it.

Not fixing it here. The four rules allow browser-automation MCP tools, and
untracking silently removes them from every clone — whether they are personal or
belong in the committed settings.json is a judgement about how people work in
this repo, not something to decide while filing.

Co-Authored-By: Claude <noreply@anthropic.com>

.pql/changelog/ticket_history/2026-08.sql

@@ -0,0 +1,23 @@
+INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FZ4HDS0AGMK8R3WS0RY7BMJW', 'description', NULL, '`.claude/settings.local.json` is committed to this repo. It is the per-clone local overrides file — the documented home for personal settings and for credentials — and it does not belong in version control at all.
+
+STATE, verified 2026-08-11 rather than assumed:
+  - the file is tracked, with 2 commits touching it (both 2025-12-31)
+  - `.gitignore` already lists it at line 137, and line 130 carries the exact `git rm --cached` command in a comment
+  - gitignore does not apply to files git already tracks, which is why the rule has been inert since it was added
+  - this is the ONLY repo in the workspace where the file is tracked; desklock, library-desk and tatlock all ignore it correctly
+
+NO CREDENTIALS WERE EVER COMMITTED. Both committed versions contain a `permissions` section and nothing else — zero env keys, checked at each commit rather than only at HEAD. This is a loaded trap, not a leak: the next person who adds an env key to this file commits a secret, and nothing will stop them because the ignore rule cannot fire on a tracked path.
+
+Worth recording because it has already cost time once: a survey agent previously reported credentials committed across nine repos. Traced to source, it was this one file holding a four-entry permission list and no secrets. The finding was wrong and the file is still tracked, so the same false alarm is available to the next person who greps for it.
+
+THE FOUR RULES IN IT ARE THE ONLY REASON TO PAUSE. They allow browser-automation MCP tools:
+  mcp__chrome-devtools__take_screenshot, take_snapshot, navigate_page
+  mcp__puppeteer__puppeteer_evaluate
+
+Untracking removes them from anyone who clones. Two ways to go, and this wants deciding rather than defaulting:
+  - they are genuinely personal (one person''s browser tooling) — untrack and let each clone re-grant
+  - they are useful to anyone working on this UI — move them into `.claude/settings.json`, which is committed by design and already carries 16 allow and 43 deny rules
+
+The second reading looks likelier for a front-end repo where visual verification is routine, but it is a judgement about how people work here, not something the file can answer.
+
+FIX: `git rm --cached .claude/settings.local.json` and commit. The file stays on disk, so nobody loses their local settings; it simply stops being shared. Decide the four rules first, or they vanish quietly.', NULL, '2026-08-11 19:21:23', '2026-08-11 19:21:23.594', '2026-08-11 19:21:23.594', NULL, '6ae54cdfcaa87232e3074a23b88d1b82', 2) ON CONFLICT(hash) DO NOTHING;

.pql/changelog/ticket_idmap/2026-08.sql

@@ -0,0 +1 @@
+INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FZ4HDS0AGMK8R3WS0RY7BMJW', 'T-1', '2026-08-11 19:21:23.466', '2026-08-11 19:21:23.466', NULL, '953ce74627a5dd3cc3f2c4e56e6fc6aa', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= ticket_idmap.updated_at;

.pql/changelog/tickets/2026-08.sql

@@ -0,0 +1,24 @@
+INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FZ4HDS0AGMK8R3WS0RY7BMJW', 'bug', NULL, '.claude/settings.local.json is tracked in git and should not be', NULL, 'backlog', 'high', NULL, NULL, NULL, '2026-08-11 19:21:23.458', '2026-08-11 19:21:23.458', NULL, 'b68f6240b59c932e1b81744ce2e9f054', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= tickets.updated_at;
+INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FZ4HDS0AGMK8R3WS0RY7BMJW', 'bug', NULL, '.claude/settings.local.json is tracked in git and should not be', '`.claude/settings.local.json` is committed to this repo. It is the per-clone local overrides file — the documented home for personal settings and for credentials — and it does not belong in version control at all.
+
+STATE, verified 2026-08-11 rather than assumed:
+  - the file is tracked, with 2 commits touching it (both 2025-12-31)
+  - `.gitignore` already lists it at line 137, and line 130 carries the exact `git rm --cached` command in a comment
+  - gitignore does not apply to files git already tracks, which is why the rule has been inert since it was added
+  - this is the ONLY repo in the workspace where the file is tracked; desklock, library-desk and tatlock all ignore it correctly
+
+NO CREDENTIALS WERE EVER COMMITTED. Both committed versions contain a `permissions` section and nothing else — zero env keys, checked at each commit rather than only at HEAD. This is a loaded trap, not a leak: the next person who adds an env key to this file commits a secret, and nothing will stop them because the ignore rule cannot fire on a tracked path.
+
+Worth recording because it has already cost time once: a survey agent previously reported credentials committed across nine repos. Traced to source, it was this one file holding a four-entry permission list and no secrets. The finding was wrong and the file is still tracked, so the same false alarm is available to the next person who greps for it.
+
+THE FOUR RULES IN IT ARE THE ONLY REASON TO PAUSE. They allow browser-automation MCP tools:
+  mcp__chrome-devtools__take_screenshot, take_snapshot, navigate_page
+  mcp__puppeteer__puppeteer_evaluate
+
+Untracking removes them from anyone who clones. Two ways to go, and this wants deciding rather than defaulting:
+  - they are genuinely personal (one person''s browser tooling) — untrack and let each clone re-grant
+  - they are useful to anyone working on this UI — move them into `.claude/settings.json`, which is committed by design and already carries 16 allow and 43 deny rules
+
+The second reading looks likelier for a front-end repo where visual verification is routine, but it is a judgement about how people work here, not something the file can answer.
+
+FIX: `git rm --cached .claude/settings.local.json` and commit. The file stays on disk, so nobody loses their local settings; it simply stops being shared. Decide the four rules first, or they vanish quietly.', 'backlog', 'high', NULL, NULL, NULL, '2026-08-11 19:21:23.458', '2026-08-11 19:21:23.593', NULL, 'dad1d9ab6415c597def74a213e0d914e', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= tickets.updated_at;