Callum 260312 WIP

.agents/skills/cognitive-load/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: cognitive-load
+description: Reduce cognitive load when implementing or refactoring code for readability.
+---
+
 From [Cognitive Load prompt](https://github.com/zakirullin/cognitive-load/blob/main/README.prompt.md).
 
 You are an engineer who writes code for **human brains, not machines**. You favour code that is simple to undertand and maintain. Remember at all times that the code you will be processed by human brain. The brain has a very limited capacity. People can only hold ~4 chunks in their working memory at once. If there are more than four things to think about, it feels mentally taxing for us.

.agents/skills/conventional-commits/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: conventional-commits
-description: Write commit messages using Conventional Commits 1.0.0. Use when creating, reviewing, or fixing commit messages so they follow <type>[optional scope]: <description> with optional body/footer and proper BREAKING CHANGE handling.
+description: Use Conventional Commits when creating reviewing or fixing commit messages.
 ---
 
 # Conventional Commits

.agents/skills/patch-first-debugging/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: patch-first-debugging
+description: Debug and repair code using minimal, reviewable patches instead of full-file rewrites. Use this whenever the user is fixing a bug, iterating on failing tests, asks for a surgical code change, wants a minimal diff, or is in a tight debug loop where output size and token cost matter. Prefer this even if the user does not explicitly say "patch."
+---
+
+# Patch-First Debugging
+
+## Goal
+
+Fix the problem with the smallest correct change, keep outputs reviewable, reduce token usage in iterative debug loops, and avoid regenerating entire files unless a full rewrite is clearly justified.
+
+## Why this skill exists
+
+- Smaller patches usually cost fewer tokens than full-file rewrites.
+- Minimal diffs are easier to review and less likely to introduce unrelated churn.
+- Tight debug loops work better when each iteration changes only the code justified by the latest failure.
+
+## When to use
+
+- Bug fixes
+- Failing test or regression loops
+- Small refactors with no intended behavior change
+- Requests for minimal diffs or surgical edits
+- Cases where only one or two files appear relevant
+
+## Workflow
+
+1. Reproduce or identify the failure.
+2. Narrow scope to the smallest relevant file, function, or branch.
+3. Inspect existing code before proposing changes.
+4. Make the minimal patch that addresses the root cause.
+5. Run the smallest verification that proves the fix.
+6. Expand scope only if the minimal patch fails or the evidence points elsewhere.
+
+## Output rules
+
+- Prefer patch-oriented edits over full-file rewrites.
+- Prefer unified diffs, `apply_patch`, or small in-place edits.
+- Modify existing code instead of regenerating it.
+- Keep outputs small when the task is local; this reduces token usage and makes repeated repair loops cheaper.
+- Include only the changed context needed to understand the patch.
+- Do not rewrite unrelated code, comments, or formatting.
+- Rewrite a whole file only when the structure is fundamentally changing or patching would be less clear than replacement.
+
+## Context rules
+
+- Ask for or inspect only the relevant file, function, error, and test output first.
+- Avoid pulling in whole directories or broad repo context unless the first pass is insufficient.
+- If the problem spans multiple files, add them one at a time based on evidence.
+
+## Verification rules
+
+- Prefer targeted tests, builds, or lint checks over full-suite runs.
+- State what was verified.
+- If verification was not possible, say so plainly.
+- If the first patch does not hold, iterate with another minimal patch instead of broadening the rewrite immediately.
+
+## Escalation rules
+
+- If the bug report is vague, first identify the failure mode before editing.
+- If the requested change would trigger broad churn, say that a larger refactor is needed and explain why patch-first is no longer the right shape.
+- If a rewrite is necessary, say why the patch boundary broke down.
+
+## Examples
+
+**Example 1**
+Input: "This test started failing after a refactor. Fix it with the smallest possible change."
+Output: Reproduce the failure, patch the relevant file only, rerun the affected test file, and report the result.
+
+**Example 2**
+Input: "Here is a stack trace and `auth.ts`. Find the bug and output only a unified diff."
+Output: Limit analysis to `auth.ts` and the stack trace, then return a small diff instead of a full file.
+
+**Example 3**
+Input: "Login regressed. Please avoid touching unrelated files."
+Output: Inspect the failing path, make the smallest safe patch, and verify only the login-related tests or checks.

.agents/skills/patch-first-debugging/evals/evals.json

@@ -0,0 +1,38 @@
+{
+  "skill_name": "patch-first-debugging",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "A Vitest file started failing after a small refactor. Fix the bug with the smallest possible change, avoid touching unrelated files, and verify only the most relevant test target first.",
+      "expected_output": "The response narrows scope quickly, favors a minimal patch over a rewrite, and runs or recommends a targeted verification step.",
+      "files": [],
+      "expectations": [
+        "The workflow focuses on the smallest relevant file or function first",
+        "The solution prefers a patch or surgical edit instead of rewriting whole files",
+        "The verification step is targeted rather than defaulting to the full test suite"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Here is a stack trace and one file, auth.ts. Find the bug and output only a unified diff. Do not return the full file.",
+      "expected_output": "The response honors the patch-only format and limits analysis to the supplied file and error context.",
+      "files": [],
+      "expectations": [
+        "The output format is a diff or patch rather than a full-file rewrite",
+        "The response stays scoped to auth.ts and the provided failure context",
+        "The edit changes only the code needed to address the bug"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Login regressed, but the root cause is unclear. Investigate carefully, start with the smallest likely surface area, and only broaden scope if the first patch does not hold.",
+      "expected_output": "The response follows a patch-first debugging loop, explains when to widen scope, and avoids broad churn before evidence requires it.",
+      "files": [],
+      "expectations": [
+        "The response identifies or reproduces the failure before making broad changes",
+        "The initial repair attempt is a minimal patch",
+        "The response explains that wider refactoring or additional files should be pulled in only if evidence requires it"
+      ]
+    }
+  ]
+}

AGENTS.md

@@ -20,7 +20,8 @@ DataConnect is the protocol client: it runs connectors, orchestrates grants, and
 
 - Prefer retrieval‑led reasoning for project‑specific knowledge.
 - Don’t overwrite comments; don’t change styles/classes unless asked.
-- When I report a bug, don't start by trying to fix it. Instead, start by writing a test that reproduces the bug. Then, have subagents try to fix the bug and prove it with a passing test.
+- Prefer minimal patches over full-file rewrites when feasible; this keeps outputs smaller, reduces token usage in debug loops, and makes changes easier to review. Keep context scoped to the relevant file, function, and failure, and avoid regenerating entire files unless a full rewrite is clearly justified.
+- When I report a bug, do not start with a fix. First reproduce the bug and add the smallest failing test for the reported behavior when feasible. Then have subagents propose fixes, and accept a fix only when that reproducing test passes.
 - Commit only when asked; never push; stage explicit paths only (no `git add .`, `-A`, `-u`, `git commit -a`); run relevant tests before commit.
 - For all commit actions, follow `.agents/skills/commit-discipline/SKILL.md` exactly.
 - For links/actions that open URLs or local file/folder paths, use shared helpers in `src/lib/open-resource.ts` and `src/lib/tauri-paths.ts`; avoid inline runtime/OS branching in page components.
@@ -52,4 +53,5 @@ Use skills only when the task matches; explore the code first.
 - Text usage edits: when changing usage of `src/components/typography/text.tsx`, read ui-component-audit first (soft default; use judgment).
 - Testing: invoke react-testing when writing/running tests or before commit.
 - Linear: invoke linear skill when asked to create/update tickets or statuses.
+- Commit messages: invoke conventional-commits when creating, reviewing, or fixing commit messages.
 - Committing: invoke committing skill only when user explicitly asks to commit.

src/components/typography/text.tsx

@@ -129,6 +129,10 @@ export const textVariants = cva(
           "list-disc",
         ],
       },
+      textBox: {
+        // Perfectly trims the text box to the actual glyph bounds
+        true: "[text-box-trim:trim-both_cap_alphabetic]",
+      },
     },
     compoundVariants: [
       // mono displays
@@ -199,6 +203,7 @@ export const Text = <T extends ElementType = "div">({
   optical,
   truncate,
   bullet,
+  textBox,
   pre,
   link,
   dim,
@@ -255,6 +260,7 @@ export const Text = <T extends ElementType = "div">({
           truncate,
           pre: preProp,
           bullet: bulletProp,
+          textBox,
           link: linkProp,
           withIcon,
           dim,

src/styles/index.css

@@ -328,11 +328,4 @@
   }
 }
 
-/* Draggable title bar area for macOS */
-.titlebar-drag-region {
-  -webkit-app-region: drag;
-}
 
-.titlebar-no-drag {
-  -webkit-app-region: no-drag;
-}