update harness

.github/CLAUDE.md

@@ -2,15 +2,29 @@
 
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 
-## 1. Think Before Coding
+# Karpathy Guidelines
+
+Behavioral guidelines to reduce common LLM coding mistakes.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Clarify Before Executing
+
+**Resolve ambiguity up front — before spawning agents or starting any autonomous work.**
 
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
+Do this in order, then stop and ask before proceeding:
+
+1. **Understand the request.** Read what was asked closely and state your assumptions explicitly.
+2. **Inspect the codebase.** Check the relevant code, conventions, and existing patterns. Note anything that's unclear or that could be interpreted in more than one way.
+3. **Ask.** Raise every consequential question now, batched together — don't pick an interpretation silently, and don't defer the question into the work itself.
 
-Before implementing:
-- State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them - don't pick silently.
+Throughout:
+
+- If multiple interpretations exist, present them — don't choose one silently.
 - If a simpler approach exists, say so. Push back when warranted.
-- If something is unclear, stop. Name what's confusing. Ask.
+- Don't invent APIs. Confirm a function, flag, or endpoint exists — and check its signature — before calling it. If you can't verify it, say so rather than guessing.
+
+Only once these questions are resolved do you move to execution (§4).
 
 ## 2. Simplicity First
 
@@ -29,34 +43,60 @@ Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, sim
 **Touch only what you must. Clean up only your own mess.**
 
 When editing existing code:
+
 - Don't "improve" adjacent code, comments, or formatting.
 - Don't refactor things that aren't broken.
 - Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it - don't delete it.
+- If you spot problems outside your task — dead code, bugs — mention them; don't fix or delete them unless asked.
 
 When your changes create orphans:
+
 - Remove imports/variables/functions that YOUR changes made unused.
 - Don't remove pre-existing dead code unless asked.
 
-The test: Every changed line should trace directly to the user's request.
+The test: every changed line should trace directly to the user's request.
 
 ## 4. Goal-Driven Execution
 
 **Define success criteria. Loop until verified.**
 
-Transform tasks into verifiable goals:
+Begin only once §1's questions are resolved. Then turn the task into a verifiable goal with an observable check. A passing test is the strongest check; a clean typecheck, running it and inspecting output, or diffing against expected output also count.
+
 - "Add validation" → "Write tests for invalid inputs, then make them pass"
 - "Fix the bug" → "Write a test that reproduces it, then make it pass"
 - "Refactor X" → "Ensure tests pass before and after"
+- "Update the config" → "Apply it, start the service, and confirm the setting takes effect"
 
 For multi-step tasks, state a brief plan:
+
 ```
 1. [Step] → verify: [check]
 2. [Step] → verify: [check]
 3. [Step] → verify: [check]
 ```
 
-Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+When no obvious check exists (docs, exploration, some one-off scripts), ask how to verify success before starting. Don't report success you haven't actually observed.
+
+Strong, agreed-upon criteria — settled in §1 — let you loop independently. Weak criteria ("make it work") force constant clarification, which is why §1 comes first.
+
+## 5. Delegate Grunt Work Down a Tier
+
+**Spend the capable model on judgment; push mechanical, low-context work to a cheaper model.**
+
+Act as an orchestrator. Fan out grunt work — reading files, gathering context, simple searches, minor mechanical edits, other simple tool calls — to cheaper agents, then review their findings and any code changes yourself before acting on them. Keep the important and dangerous work — architecture, ambiguous decisions, risky or hard-to-reverse edits, final review — on the more capable model.
+
+Which tier to spawn depends on who you are:
+
+- **If you are Fable 5**, spawn Opus 4.8 agents for grunt work that still needs some capability; for genuinely simple tasks, hand off directly to Sonnet 5 instead. Review what they return.
+- **If you are Opus 4.8**, and a task needs little knowledge or context, fan out to Sonnet 5 agents and review what they return.
+
+Match the model to the task: pick the cheapest tier that can do the job well, and skip an intermediate tier when the work is simple enough for a lower one.
+
+Guidelines:
+
+- Only delegate work that is genuinely low-context and low-risk. If doing it well requires the capable model's judgment, keep it.
+- Give each agent a self-contained task with clear success criteria (per §4) so you can verify its output without redoing the work.
+- Never merge a delegated finding or edit unblocked — review it first. The cheaper model did the legwork; you own the decision.
 
 ## Project Overview
 
@@ -334,100 +374,4 @@ To update this file, ensure that all sections are kept current with the latest a
 - Add new sections as needed for significant changes in the project structure or processes.
 - Ensure all technical terms are explained or linked to relevant documentation.
 - Periodically review for outdated information and remove or update as necessary.
-- If told to not do something, ensure this is also added to the "Dont Do that" section.
-
-# Karpathy Guidelines
-
-Behavioral guidelines to reduce common LLM coding mistakes.
-
-**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
-
-## 1. Clarify Before Executing
-
-**Resolve ambiguity up front — before spawning agents or starting any autonomous work.**
-
-Do this in order, then stop and ask before proceeding:
-
-1. **Understand the request.** Read what was asked closely and state your assumptions explicitly.
-2. **Inspect the codebase.** Check the relevant code, conventions, and existing patterns. Note anything that's unclear or that could be interpreted in more than one way.
-3. **Ask.** Raise every consequential question now, batched together — don't pick an interpretation silently, and don't defer the question into the work itself.
-
-Throughout:
-
-- If multiple interpretations exist, present them — don't choose one silently.
-- If a simpler approach exists, say so. Push back when warranted.
-- Don't invent APIs. Confirm a function, flag, or endpoint exists — and check its signature — before calling it. If you can't verify it, say so rather than guessing.
-
-Only once these questions are resolved do you move to execution (§4).
-
-## 2. Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
-
-## 3. Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-When editing existing code:
-
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- If you spot problems outside your task — dead code, bugs — mention them; don't fix or delete them unless asked.
-
-When your changes create orphans:
-
-- Remove imports/variables/functions that YOUR changes made unused.
-- Don't remove pre-existing dead code unless asked.
-
-The test: every changed line should trace directly to the user's request.
-
-## 4. Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-Begin only once §1's questions are resolved. Then turn the task into a verifiable goal with an observable check. A passing test is the strongest check; a clean typecheck, running it and inspecting output, or diffing against expected output also count.
-
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
-- "Update the config" → "Apply it, start the service, and confirm the setting takes effect"
-
-For multi-step tasks, state a brief plan:
-
-```
-1. [Step] → verify: [check]
-2. [Step] → verify: [check]
-3. [Step] → verify: [check]
-```
-
-When no obvious check exists (docs, exploration, some one-off scripts), ask how to verify success before starting. Don't report success you haven't actually observed.
-
-Strong, agreed-upon criteria — settled in §1 — let you loop independently. Weak criteria ("make it work") force constant clarification, which is why §1 comes first.
-
-## 5. Delegate Grunt Work Down a Tier
-
-**Spend the capable model on judgment; push mechanical, low-context work to a cheaper model.**
-
-Act as an orchestrator. Fan out grunt work — reading files, gathering context, simple searches, minor mechanical edits, other simple tool calls — to cheaper agents, then review their findings and any code changes yourself before acting on them. Keep the important and dangerous work — architecture, ambiguous decisions, risky or hard-to-reverse edits, final review — on the more capable model.
-
-Which tier to spawn depends on who you are:
-
-- **If you are Fable 5**, spawn Opus 4.8 agents for grunt work that still needs some capability; for genuinely simple tasks, hand off directly to Sonnet 5 instead. Review what they return.
-- **If you are Opus 4.8**, and a task needs little knowledge or context, fan out to Sonnet 5 agents and review what they return.
-
-Match the model to the task: pick the cheapest tier that can do the job well, and skip an intermediate tier when the work is simple enough for a lower one.
-
-Guidelines:
-
-- Only delegate work that is genuinely low-context and low-risk. If doing it well requires the capable model's judgment, keep it.
-- Give each agent a self-contained task with clear success criteria (per §4) so you can verify its output without redoing the work.
-- Never merge a delegated finding or edit unblocked — review it first. The cheaper model did the legwork; you own the decision.
+- If told to not do something, ensure this is also added to the "Dont Do that" section.

src/PluginRegistry/PluginHashGenerator.Generated.cs

@@ -10,35 +10,35 @@ public static partial class PluginValidator
 {
     /// <summary>
     /// Gets pre-calculated SHA256 hashes for built-in plugins.
-    /// Generated: 2026-07-21 04:12:26 UTC
+    /// Generated: 2026-07-21 07:10:59 UTC
     /// Configuration: Release
     /// Plugin count: 21
     /// </summary>
     public static Dictionary<string, string> GetBuiltInPluginHashes()
     {
         return new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)
         {
-                         ["AutoColumnizer.dll"] = "06B16C971B3AECA6A0FA47635B403DEB43D2BF020FE86ED0A834E5C65F530A73",
+                         ["AutoColumnizer.dll"] = "B17B198624164070272EC6A7A82A5918FFD1A2B504E9740CBFED121D0BC3D507",
             ["BouncyCastle.Cryptography.dll"] = "E5EEAF6D263C493619982FD3638E6135077311D08C961E1FE128F9107D29EBC6",
             ["BouncyCastle.Cryptography.dll (x86)"] = "E5EEAF6D263C493619982FD3638E6135077311D08C961E1FE128F9107D29EBC6",
-            ["CsvColumnizer.dll"] = "928ABDF119BBA8D8A75191D7F07CACA07A8D2CBADFBA11A2D1095D932E73BA93",
-            ["CsvColumnizer.dll (x86)"] = "928ABDF119BBA8D8A75191D7F07CACA07A8D2CBADFBA11A2D1095D932E73BA93",
-            ["DefaultPlugins.dll"] = "2D9535C0460B655C6416C9838624249E93EA6B8921FED62E50D4E347DC4747CD",
-            ["FlashIconHighlighter.dll"] = "AB46964F23F8ADDA3370F56A21C81D07826FB728E066186E4F47D7200F0EC462",
-            ["GlassfishColumnizer.dll"] = "F13B44A52528D9F3C1025571FA3DD76612B76F52C4945096E5D40579D9F0408B",
-            ["JsonColumnizer.dll"] = "1157BA607AEB7FED25DFBC4013A230CDEF2FC906C9A17DBD3A5C007429C8F243",
-            ["JsonCompactColumnizer.dll"] = "3BEBFB3362D1E33927CAC364D7D7385548ACED5367B46BCC67C88A6CE67FFDD8",
-            ["Log4jXmlColumnizer.dll"] = "D29D2BC149FBC8E6BCB709A980C86E3465182A574DFEEE5DA16D106BA1CBB902",
-            ["LogExpert.Resources.dll"] = "CF131787FFBE62AD1C458DEFDAE4C0E82B964EE2291E33BE75D7B17F99CDC1D6",
+            ["CsvColumnizer.dll"] = "4DB94E7C49BB17CAC79EF6F961C6BF99BA3C4EE74876651813C84F0680981982",
+            ["CsvColumnizer.dll (x86)"] = "4DB94E7C49BB17CAC79EF6F961C6BF99BA3C4EE74876651813C84F0680981982",
+            ["DefaultPlugins.dll"] = "7AD4E853A0766282F07C6F6DC544F106724E92A52A862A4DDF0792FB46125D0C",
+            ["FlashIconHighlighter.dll"] = "3FB02733964F27E4D18D2DE12D02B457955435B6E0C76B23DBB5DE8DC1D7D7A2",
+            ["GlassfishColumnizer.dll"] = "32C93E8FD8DF6BA554E7BE1BCC3D0624F5160C76FCD1C79273DC8640FF88F6DA",
+            ["JsonColumnizer.dll"] = "3D1DC959F6BBD5280D040E3E36FA9480D0BC5E866141AEF3EC37BF70592F3206",
+            ["JsonCompactColumnizer.dll"] = "A9828BF37C33ED4F5C15844717AA4EDF3A0C77FE880304B1D48505A0F53D330E",
+            ["Log4jXmlColumnizer.dll"] = "C255335F357EC4FC4646C916536A76E383988C6CDD6D15259522ECA04CA7961E",
+            ["LogExpert.Resources.dll"] = "19249A47B49B69BAFC0837744A6519784604051352ED963212684F26728714CD",
             ["Microsoft.Extensions.DependencyInjection.Abstractions.dll"] = "67FA4325000DB017DC0C35829B416F024F042D24EFB868BCF17A895EE6500A93",
             ["Microsoft.Extensions.DependencyInjection.Abstractions.dll (x86)"] = "67FA4325000DB017DC0C35829B416F024F042D24EFB868BCF17A895EE6500A93",
             ["Microsoft.Extensions.Logging.Abstractions.dll"] = "BB853130F5AFAF335BE7858D661F8212EC653835100F5A4E3AA2C66A4D4F685D",
             ["Microsoft.Extensions.Logging.Abstractions.dll (x86)"] = "BB853130F5AFAF335BE7858D661F8212EC653835100F5A4E3AA2C66A4D4F685D",
-            ["RegexColumnizer.dll"] = "E55E20FAE4BFCE69D59BE8FD76DAF95DFDF18C704372B212E739087420B0EF29",
-            ["SftpFileSystem.dll"] = "18251BBC99C7296DB7A7AD078C8EFF174D17F86C4E2B2F6B0EEF312B652CD2CA",
-            ["SftpFileSystem.dll (x86)"] = "2BD06E0EF482FC21583C8531852CFF1CBB409A710FD99B42041A8B9B37C4F595",
-            ["SftpFileSystem.Resources.dll"] = "30967C6145D0BDB43CC738C5A98514C747A62095BE9CAD55EB608A3B26942A5B",
-            ["SftpFileSystem.Resources.dll (x86)"] = "30967C6145D0BDB43CC738C5A98514C747A62095BE9CAD55EB608A3B26942A5B",
+            ["RegexColumnizer.dll"] = "00DF907ABDC3DD3C8554F076AB2F516C4F678DF4EEB25DC932CDED8036AB0052",
+            ["SftpFileSystem.dll"] = "7D15270F2F424BA50D459CFA33F83ED7D36A285108F16AA986F0DEB18935D7F4",
+            ["SftpFileSystem.dll (x86)"] = "B32E30684059632900694D536EDCF755FE5D0544BB95DF5B013629DA1AA751A8",
+            ["SftpFileSystem.Resources.dll"] = "19BB05F8897E4C1FA4EF4B491FEEC0C50105A8EB589F0033DB75AD6242EDA1C8",
+            ["SftpFileSystem.Resources.dll (x86)"] = "19BB05F8897E4C1FA4EF4B491FEEC0C50105A8EB589F0033DB75AD6242EDA1C8",
 
         };
     }