diff --git a/.github/CLAUDE.md b/.github/CLAUDE.md index 394da5bd..66ebc561 100644 --- a/.github/CLAUDE.md +++ b/.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. \ No newline at end of file +- If told to not do something, ensure this is also added to the "Dont Do that" section. \ No newline at end of file diff --git a/src/PluginRegistry/PluginHashGenerator.Generated.cs b/src/PluginRegistry/PluginHashGenerator.Generated.cs index 45a4bb63..17bef54c 100644 --- a/src/PluginRegistry/PluginHashGenerator.Generated.cs +++ b/src/PluginRegistry/PluginHashGenerator.Generated.cs @@ -10,7 +10,7 @@ public static partial class PluginValidator { /// /// 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 /// @@ -18,27 +18,27 @@ public static Dictionary GetBuiltInPluginHashes() { return new Dictionary(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", }; }