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/skills/test-fix-loop/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: test-fix-loop
+description: Build or use a tight automated test-fix loop that repairs one failing test at a time with minimal patches and narrow context. Use whenever the user wants a repair harness, constrained bug-fixing loop, failing-test repair workflow, or a prompt that turns the model into a surgical fix engine instead of a general coding assistant.
+---
+
+# Test-Fix Loop
+
+## Goal
+
+Drive a tight repair loop:
+
+1. run tests
+2. find the failing test
+3. collect traceback or stderr
+4. collect only relevant files
+5. ask the model for the smallest valid patch
+6. apply the patch
+7. rerun tests
+8. repeat until pass or stop limit
+
+This skill is for narrow repair work, not broad refactoring or feature design.
+
+## Core stance
+
+Treat the model as a constrained repair engine.
+
+- Keep context small.
+- Fix the reported failure only.
+- Prefer surgical diffs over rewrites.
+- Preserve existing style and structure.
+- Stop when the failure is ambiguous.
+
+## When to use
+
+Use this skill when the user wants any of the following:
+
+- an automated test-fix harness
+- a minimal-patch bug fixing loop
+- a failing-test repair workflow
+- a prompt that returns only a patch
+- strict guardrails against unrelated refactors
+
+Do not use this skill for greenfield design, large refactors, or vague requests like "improve this codebase."
+
+## Required loop shape
+
+Keep the loop conceptually this small:
+
+```text
+run tests
+-> find failing test
+-> collect traceback / stderr
+-> collect only relevant files
+-> ask model for minimal patch
+-> apply patch
+-> rerun tests
+-> repeat until pass or stop limit
+```
+
+Do not expand this into a broader autonomous workflow unless the user explicitly asks for that.
+
+## Prompt contract
+
+When drafting the repair prompt, preserve these rules:
+
+- fix only the failing issue
+- return a minimal diff
+- avoid unrelated refactors
+- preserve existing style
+- stop if the failure is ambiguous
+
+Use a system-style prompt close to this:
+
+```text
+You are a repair agent working in an automated test-fix loop.
+
+Goal:
+Make the smallest valid code change that fixes the reported failure.
+
+Rules:
+- Return only a unified diff patch.
+- Do not rewrite entire files unless absolutely necessary.
+- Do not refactor unrelated code.
+- Preserve current code style and structure.
+- Prefer surgical edits.
+- If the error cannot be fixed confidently from the provided context, return:
+  CANNOT_FIX_CONFIDENTLY
+
+You will receive:
+1. failing test name
+2. error output
+3. relevant file contents
+4. optional project rules
+```
+
+If the user explicitly wants a short explanation with the patch, keep it brief and machine-friendly. Otherwise prefer patch-only output.
+
+## Iteration payload
+
+Each repair attempt should include only:
+
+- failing test name
+- error output
+- relevant files
+- project rules
+
+Send only the smallest useful code context. Usually 2 to 5 files max.
+
+Good file sources:
+
+- file from traceback
+- failed test file
+- directly implicated source module
+- config file only if clearly involved
+
+Bad pattern:
+
+- dumping large parts of the repo "just in case"
+
+## Patch shape
+
+Prefer unified diff output like this:
+
+```diff
+--- a/auth/token.ts
++++ b/auth/token.ts
+@@
+- if (token.isValid()) {
++ if (token.isValid() && !token.isExpired()) {
+    return true
+  }
+```
+
+Do not return essays, rewritten full files, or unrelated cleanup.
+
+## Guardrails
+
+Use hard stops to control cost and drift:
+
+- max repair attempts per failure
+- stop after repeated no-op patches
+- stop if the same error repeats unchanged
+- stop if failures increase sharply
+- stop if the patch touches unrelated files
+
+Before applying a patch automatically, validate:
+
+- patch parses correctly
+- changed files are allowed
+- forbidden files are untouched
+- diff size is under threshold
+- tests are still runnable
+
+Reject patches that fail these checks.
+
+## Review pass
+
+If the user wants a safer loop, recommend a two-step flow:
+
+1. repair model proposes patch
+2. review model checks likely fix and collateral risk
+
+Keep the review narrow. It should judge the candidate patch, not redesign the solution.
+
+## Output expectations
+
+When helping the user build this workflow:
+
+- keep recommendations concrete
+- preserve the tight loop shape
+- avoid turning the pattern into a generic coding agent
+- name any disagreement with the user's design explicitly before changing 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,6 @@ 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.
+- Test-fix harnesses: invoke test-fix-loop when the user wants a constrained failing-test repair loop, minimal-patch harness, or automated test-fix workflow.
 - 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;
-}