# pull_requests

title: Add Per-Pattern Model Mapping via Environment Variables
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1714
merged_at: 2025-08-17 23:49:46+00:00
created_at: 2025-09-11 18:18:34
body:
  # Add Per-Pattern Model Mapping via Environment Variables

  ## Summary

  This PR adds per-pattern model mapping support to the Fabric CLI tool, allowing users to configure specific AI models for individual patterns using environment variables. This enhancement provides more granular control over model selection without requiring command-line flags for each pattern usage.

  ## Related Issues

  Closes #691

  ## Files Changed

  - **README.md**: Added documentation for the new per-pattern model mapping feature
  - **internal/cli/chat.go**: Implemented the core functionality for environment variable-based model mapping

  ## Code Changes

  ### internal/cli/chat.go

  The main implementation adds environment variable lookup logic in the `handleChatProcessing` function:

  ```go
  // Check for pattern-specific model via environment variable
  if currentFlags.Pattern != "" && currentFlags.Model == "" {
      envVar := "FABRIC_MODEL_" + strings.ToUpper(strings.ReplaceAll(currentFlags.Pattern, "-", "_"))
      if modelSpec := os.Getenv(envVar); modelSpec != "" {
          parts := strings.SplitN(modelSpec, "|", 2)
          if len(parts) == 2 {
              currentFlags.Vendor = parts[0]
              currentFlags.Model = parts[1]
          } else {
              currentFlags.Model = modelSpec
          }
      }
  }
  ```

  ### README.md

  Added a new section documenting the feature with usage examples and benefits for shell startup file configuration.

  ## Reason for Changes

  This feature addresses the need for pattern-specific model configuration without requiring users to specify model flags repeatedly. It enables:

  1. **Persistent Configuration**: Users can set pattern-specific models in their shell startup files
  2. **Flexible Model Selection**: Different patterns can use different models optimized for their specific tasks
  3. **Backward Compatibility**: Only applies when no explicit model is specified via command-line flags

  ## Impact of Changes

  ### Positive Impacts
  - **Enhanced User Experience**: Reduces repetitive command-line flag usage
  - **Improved Workflow**: Allows for optimized model selection per pattern type
  - **Configuration Flexibility**: Environment variables can be managed in shell profiles

  ### Potential Issues
  - **Environment Variable Pollution**: Multiple patterns could create many environment variables
  - **Case Sensitivity**: Pattern name transformation logic could cause confusion if patterns have complex naming
  - **Silent Failures**: Invalid vendor|model format might not provide clear error messages
  - **Debugging Complexity**: Model selection logic now has multiple sources (CLI flags, env vars, defaults)

  ## Test Plan

  The changes should be tested by:

  1. **Basic Functionality**: Verify environment variables override default model selection
  2. **Format Validation**: Test both `vendor|model` and `model-only` formats
  3. **Pattern Name Transformation**: Test patterns with hyphens and special characters
  4. **Precedence Testing**: Ensure CLI flags still override environment variables
  5. **Error Handling**: Verify behavior with invalid model specifications

  ## Additional Notes

  - The implementation transforms pattern names by converting to uppercase and replacing hyphens with underscores
  - The feature only activates when a pattern is specified and no explicit model is provided via CLI flags
  - The vendor|model format is optional; users can specify just the model name
  - This change maintains full backward compatibility with existing usage patterns

commits:
  [{"SHA":"e5ec9acfac7ada2035cd5483d9a301c9252e4ff9","Message":"feat: add per-pattern model mapping support via environment variables\n\n• Add per-pattern model mapping documentation section\n• Implement environment variable lookup for pattern-specific models\n• Support vendor|model format in environment variable specification\n• Check pattern-specific model when no model explicitly set\n• Transform pattern names to uppercase environment variable format\n• Add table of contents entry for new feature\n• Enable shell startup file configuration for patterns","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-17T22:39:32Z","Parents":null}]


title: Add speech-to-text via OpenAI with transcription flags and completions
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1715
merged_at: 2025-08-18 15:02:37+00:00
created_at: 2025-09-11 18:18:34
body:
  # Add speech-to-text via OpenAI with transcription flags and completions

  ## Summary
  - Add first-class speech-to-text (STT) support to the CLI via OpenAI’s transcription APIs (Whisper-1, GPT-4o Transcribe, GPT-4o Mini Transcribe).
  - Introduce three new flags:
    - --transcribe-file: transcribe an audio/video file and prepend the text to the prompt input.
    - --transcribe-model: select a transcription model (separate from the chat model).
    - --split-media-file: automatically split files >25MB into smaller chunks using ffmpeg.
  - Add --list-transcription-models to enumerate supported STT models (with shell completion support).
  - Wire transcription into the CLI execution flow before HTML readability processing.
  - Update shell completions (zsh, bash, fish).
  - Minor README improvements and spelling dictionary update.

  ## Related Issues

  Closes #1711 

  ## Files Changed
  - .vscode/settings.json
    - Add "mpga" to the dictionary to avoid spellcheck warnings for MPEG audio extension.

  - README.md
    - Add v1.4.290 release note for STT feature and flags.
    - Fix example link path and repo case.

  - cmd/generate_changelog/incoming/1715.txt (added)
    - Entry documenting the new STT feature.

  - completions/_fabric (zsh)
    - Add completion function for transcription models and flags:
      - --transcribe-file
      - --transcribe-model
      - --split-media-file

  - completions/fabric.bash
    - Add flags to opts list and dynamic completion for --transcribe-model.
    - Add --transcribe-file to path completions.

  - completions/fabric.fish
    - Add function to list transcription models and completions for:
      - --transcribe-file
      - --transcribe-model
      - --split-media-file

  - internal/cli/cli.go
    - Invoke transcription if --transcribe-file is provided, and append the resulting text to the user message before readability processing.

  - internal/cli/flags.go
    - Add new flags:
      - TranscribeFile (string)
      - TranscribeModel (string)
      - SplitMediaFile (bool)
      - ListTranscriptionModels (bool)

  - internal/cli/listing.go
    - Add --list-transcription-models handling and printer, using openai-go’s AudioModel constants.
    - Support --shell-complete-list for clean shell completion output.

  - internal/cli/transcribe.go (added)
    - Introduce transcriber interface and handleTranscription function to:
      - Select vendor (defaults to OpenAI).
      - Validate vendor supports transcription.
      - Require and pass model.
      - Return transcription text for injection into the CLI message.

  - internal/plugins/ai/openai/openai_audio.go (added)
    - Implement Client.TranscribeFile for OpenAI vendor:
      - Validate model and input file extension.
      - Enforce 25MB size limit; optionally split with ffmpeg when --split-media-file is set.
      - Sequentially transcribe chunks and join results.

  ## Code Changes
  - Wire transcription into CLI flow (before readability):
    ```go
    // internal/cli/cli.go
    if currentFlags.TranscribeFile != "" {
      var transcriptionMessage string
      if transcriptionMessage, err = handleTranscription(currentFlags, registry); err != nil {
        return
      }
      currentFlags.Message = AppendMessage(currentFlags.Message, transcriptionMessage)
    }
    ```

  - Transcription handling and vendor dispatch:
    ```go
    // internal/cli/transcribe.go
    type transcriber interface {
      TranscribeFile(ctx context.Context, filePath, model string, split bool) (string, error)
    }

    func handleTranscription(flags *Flags, registry *core.PluginRegistry) (string, error) {
      vendorName := flags.Vendor
      if vendorName == "" {
        vendorName = "OpenAI"
      }
      vendor, ok := registry.VendorManager.VendorsByName[vendorName]
      if !ok {
        return "", fmt.Errorf("vendor %s not configured", vendorName)
      }
      tr, ok := vendor.(transcriber)
      if !ok {
        return "", fmt.Errorf("vendor %s does not support audio transcription", vendorName)
      }
      if flags.TranscribeModel == "" {
        return "", fmt.Errorf("transcription model is required (use --transcribe-model)")
      }
      return tr.TranscribeFile(context.Background(), flags.TranscribeFile, flags.TranscribeModel, flags.SplitMediaFile)
    }
    ```

  - OpenAI transcription with optional chunking:
    ```go
    // internal/plugins/ai/openai/openai_audio.go
    const MaxAudioFileSize int64 = 25 * 1024 * 1024

    var AllowedTranscriptionModels = []string{
      string(openai.AudioModelWhisper1),
      string(openai.AudioModelGPT4oMiniTranscribe),
      string(openai.AudioModelGPT4oTranscribe),
    }

    func (o *Client) TranscribeFile(ctx context.Context, filePath, model string, split bool) (string, error) {
      // validate model and extension, enforce size, optionally split via ffmpeg
      // transcribe chunks sequentially:
      params := openai.AudioTranscriptionNewParams{File: chunk, Model: openai.AudioModel(model)}
      resp, err := o.ApiClient.Audio.Transcriptions.New(ctx, params)
      // concatenate resp.Text across chunks
    }
    ```

  - List models for shell completion and user visibility:
    ```go
    // internal/cli/listing.go
    if currentFlags.ListTranscriptionModels {
      listTranscriptionModels(currentFlags.ShellCompleteOutput)
      return true, nil
    }
    ```

  ## Reason for Changes
  - Introduce robust STT so users can feed audio/video content directly into Fabric workflows (e.g., notes, podcasts, meetings, lectures), improving usability and enabling new patterns without leaving the CLI.
  - Keep transcription model selection independent from chat model selection for clarity and control.
  - Provide an ergonomic solution for large media files (>25MB) via optional ffmpeg-based chunking.
  - Enhance developer ergonomics with completions and model listing.

  ## Impact of Changes
  - New functionality:
    - Transcribe audio/video files and inject text into the prompt pipeline.
    - Model enumeration with shell completion.
  - CLI usage changes:
    - Users must specify --transcribe-model when using --transcribe-file; this is intentional to make the choice explicit.
  - Dependencies:
    - ffmpeg is required only when using --split-media-file with inputs >25MB.
  - Performance:
    - Large files are split and processed sequentially; this is safe and predictable, though not parallelized.
  - Documentation:
    - README updated with a release note and a fixed link.

  ## Test Plan
  - Basic transcription (small file):
    - Run: fabric --transcribe-file sample.m4a --transcribe-model whisper-1 -p your_pattern
    - Expect: Transcribed text is prepended to the message and processed normally.
  - Model variants:
    - Verify with whisper-1, gpt-4o-mini-transcribe, and gpt-4o-transcribe.
    - Use --list-transcription-models to confirm availability and shell completion.
  - Large media file (>25MB) without split:
    - Run: fabric --transcribe-file large.mp3 --transcribe-model whisper-1
    - Expect: Error indicating size limit and suggesting --split-media-file.
  - Large media file with split:
    - Ensure ffmpeg is installed.
    - Run: fabric --transcribe-file large.mp3 --split-media-file --transcribe-model whisper-1
    - Expect: File is split into chunks; each chunk is transcribed; results are concatenated.
  - Unsupported extension:
    - Run with an unsupported file extension.
    - Expect: Clear error listing supported formats (.mp3, .mp4, .mpeg, .mpga, .m4a, .wav, .webm).
  - Missing model:
    - Run with --transcribe-file but without --transcribe-model.
    - Expect: Error instructing to provide --transcribe-model.
  - Shell completions:
    - zsh/bash/fish: Verify completions for --transcribe-file, --transcribe-model, and --split-media-file.
  - Pipeline ordering:
    - Combine with --readability and confirm transcription occurs first, then readability.

  ## Additional Notes
  - Potential edge cases and follow-ups:
    - ffmpeg segmentation:
      - We use -f segment -segment_time with -c copy; for some containers/codecs (e.g., certain MP4 variants), this may fail or produce larger-than-expected segments. In future we might add -reset_timestamps 1 or re-encode when necessary.
    - Model lists:
      - AllowedTranscriptionModels in the OpenAI client and the listTranscriptionModels in CLI both leverage openai-go constants, but are defined in separate places. If OpenAI adds/removes models, we should centralize this list to avoid drift.
    - Concurrency:
      - Chunk transcription is sequential to preserve order; we can consider optional parallelism with ordered merge if latency becomes a concern.
    - Go version:
      - The code uses slices.Contains (Go 1.21+); ensure our minimum Go version aligns with this requirement.

commits:
  [{"SHA":"a2481406db7ba0c06823787d3eb45534d06959c7","Message":"feat: add speech-to-text via OpenAI with transcription flags and completions\n\nCHANGES\n- Add --transcribe-file flag to transcribe audio or video\n- Add --transcribe-model flag with model listing and completion\n- Add --split-media-file flag to chunk files over 25MB\n- Implement OpenAI transcription using Whisper and GPT-4o Transcribe\n- Integrate transcription pipeline into CLI before readability processing\n- Provide zsh, bash, fish completions for new transcription flags\n- Validate media extensions and enforce 25MB upload limits\n- Update README with release and corrected pattern link path","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-18T14:36:23Z","Parents":null}]


title: Highlight default vendor/model in model listing
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1717
merged_at: 2025-08-19 00:52:57+00:00
created_at: 2025-09-11 18:18:34
body:
  # Highlight default vendor/model in model listing

  ## Summary

  Highlight default AI vendor/model in the interactive models listing and wire the CLI to pass configured defaults into the listing. Introduces a subtle formatting change to the non-shell-completion output and adds a unit test to verify default model highlighting.

  ## Related Issues

  Closes #446 

  ## Files Changed

  - internal/cli/listing.go
    - Passes configured default vendor and model to the models listing for interactive display.
  - internal/plugins/ai/models.go
    - Changes the signature of PrintWithVendor to accept default vendor/model and visually marks the default in interactive listings.
    - Adds case-insensitive matching for defaults.
  - internal/plugins/ai/models_test.go
    - Adds a unit test to ensure the default vendor/model is marked in the listing output.

  ## Code Changes

  - Signature change to include defaults and documentation update:
  ```go
  // Default vendor and model are highlighted with an asterisk.
  func (o *VendorsModels) PrintWithVendor(shellCompleteList bool, defaultVendor, defaultModel string)
  ```

  - Interactive listing now marks the configured default with an asterisk (prefix column):
  ```go
  mark := "       "
  if strings.EqualFold(groupItems.Group, defaultVendor) && strings.EqualFold(item, defaultModel) {
      mark = "      *"
  }
  fmt.Printf("%s\t[%d]\t%s|%s\n", mark, currentItemIndex, groupItems.Group, item)
  ```

  - CLI now supplies defaults from registry for non-shell-completion outputs:
  ```go
  if currentFlags.ShellCompleteOutput {
      models.Print(true)
  } else {
      models.PrintWithVendor(false, registry.Defaults.Vendor.Value, registry.Defaults.Model.Value)
  }
  ```

  - Unit test captures stdout and checks that the default is marked:
  ```go
  vendors.PrintWithVendor(false, "vendor2", "model2")
  ...
  if !strings.Contains(string(out), "vendor2|model2 *") {
      t.Fatalf("default model not marked: %s", out)
  }
  ```

  ## Reason for Changes

  - Improve UX: Users can quickly identify the configured default AI model in the interactive listing.
  - Make defaults visible in the CLI without affecting shell-completion output.
  - Ensure behavior is test-covered.

  ## Impact of Changes

  - Behavioral/formatting change in interactive (non-shell completion) output only:
    - An asterisk is rendered to indicate the default entry. The star currently appears in a leading “mark” column, before the index.
  - Shell completion remains unchanged (no markers, same format).
  - API change: PrintWithVendor now requires defaultVendor and defaultModel parameters.
    - Any other call sites must be updated accordingly to avoid compile errors.
  - Case-insensitive matching for defaults improves robustness with varying config inputs.

  ## Test Plan

  - Unit:
    - internal/plugins/ai/models_test.go: TestPrintWithVendorMarksDefault
  - Manual:
    - Run the CLI command that lists models without shell completion (e.g., fabric list models) and confirm:
      - One entry has an asterisk indicating the default vendor/model.
      - Non-default entries are unmarked.
    - Run the same with shell completion mode enabled; ensure no asterisks are shown and the output remains “vendor|model”.
    - Verify behavior when defaults are unset or do not match any listed entries: no asterisk should appear.

  ## Additional Notes

  - Potential test mismatch: The test currently searches for the substring "vendor2|model2 *", which implies the asterisk appears after the model. The implementation places the asterisk in a prefix column before the index (e.g., "      *\t[2]\tvendor2|model2"). As written, the test will fail against the current implementation. We should either:
    - Update the test to look for the prefix asterisk (e.g., check for "*\t[", along with "vendor2|model2"), or
    - Move the asterisk to a suffix position (after "vendor|model") to match the test’s expectation. This may be more intuitive and less disruptive to existing consumers parsing the listing.

  - Ensure the "strings" package is imported in models.go (required for strings.EqualFold). If it is not already imported in the file, compilation will fail.

  - This is a breaking change to the PrintWithVendor signature; please verify and update any other usages outside of listing.go.

commits:
  [{"SHA":"ce599995031be895a257699c2286c7f43cc7eebf","Message":"feat: highlight default vendor/model in listings, pass registry defaults\n\nCHANGES\n- Update PrintWithVendor signature to accept default vendor and model\n- Mark default vendor/model with asterisk in non-shell output\n- Compare vendor and model case-insensitively when marking\n- Pass registry defaults to PrintWithVendor from CLI\n- Add test ensuring default selection appears with asterisk\n- Keep shell completion output unchanged without default markers","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-18T22:59:35Z","Parents":null}]


title: Implement Configurable Debug Logging Levels
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1718
merged_at: 2025-08-19 11:27:08+00:00
created_at: 2025-09-11 18:18:34
body:
  # Implement Configurable Debug Logging Levels

  ## Summary

  Introduce configurable, leveled debug logging across the CLI and key subsystems, replace ad-hoc/debug globals with a unified internal logging package, and expand Speech-To-Text (STT) documentation. Adds a `--debug` flag with four levels (off, basic, detailed, trace), integrates logging into transcription workflows (including ffmpeg chunking), updates shell completions, and removes the `FABRIC_STT_DEBUG` environment variable.

  ## Related Issues

  Closes #1220 

  ## Files Changed

  - README.md
    - Documented `--debug` flag and the available debug levels.
  - cmd/generate_changelog/incoming/1718.txt
    - Changelog entry for this PR.
  - completions/_fabric
    - zsh completion for `--debug` with supported values.
  - completions/fabric.bash
    - bash completion: added `--debug` flag to options and value suggestions.
  - completions/fabric.fish
    - fish completion for `--debug` with supported values.
  - docs/Using-Speech-To-Text.md
    - New comprehensive STT documentation (usage, models, splitting workflow, error handling, and implementation details).
  - internal/cli/flags.go
    - Added `--debug` flag to `Flags`.
    - Early parse of `--debug` from raw args to set logging level prior to full flag parsing.
    - Replaced local `Debugf`/globals with centralized `internal/log` usage.
  - internal/log/log.go
    - New unified logging package with leveled debug output and thread-safe configuration.
  - internal/plugins/ai/openai/openai_audio.go
    - Integrated leveled logging into STT flow (file size checks, chunking, and per-chunk transcription).
    - Removed `FABRIC_STT_DEBUG` env var and simplified `splitAudioFile` signature.
  - internal/plugins/ai/vendors.go
    - Minor cleanup (removed redundant return).
  - internal/plugins/template/extension_registry.go
    - Replaced package-level Debug usage with centralized logging.
  - internal/plugins/template/template.go
    - Removed `Debug` global; switched internal debug function to use trace-level logging.

  ## Code Changes

  - Add `--debug` flag and early initialization:
  ```go
  // internal/cli/flags.go
  type Flags struct {
      ...
      Debug int `long:"debug" description:"Set debug level (0=off, 1=basic, 2=detailed, 3=trace)" default:"0"`
  }

  func Init() (ret *Flags, err error) {
      debuglog.SetLevel(debuglog.LevelFromInt(parseDebugLevel(os.Args[1:])))
      ...
      if args, err = parser.Parse(); err != nil {
          return
      }
      debuglog.SetLevel(debuglog.LevelFromInt(ret.Debug))
      ...
  }
  ```

  - Early `--debug` parsing helper:
  ```go
  // internal/cli/flags.go
  func parseDebugLevel(args []string) int {
      for i := 0; i < len(args); i++ {
          arg := args[i]
          if arg == "--debug" && i+1 < len(args) {
              if lvl, err := strconv.Atoi(args[i+1]); err == nil {
                  return lvl
              }
          } else if strings.HasPrefix(arg, "--debug=") {
              if lvl, err := strconv.Atoi(strings.TrimPrefix(arg, "--debug=")); err == nil {
                  return lvl
              }
          }
      }
      return 0
  }
  ```

  - Unified logging package:
  ```go
  // internal/log/log.go
  type Level int

  const (
      Off Level = iota
      Basic
      Detailed
      Trace
  )

  func Debug(l Level, format string, a ...interface{}) {
      mu.RLock(); current := level; w := output; mu.RUnlock()
      if current >= l {
          fmt.Fprintf(w, "DEBUG: "+format, a...)
      }
  }
  ```

  - STT integration and removal of env-based debug:
  ```go
  // internal/plugins/ai/openai/openai_audio.go
  if info.Size() > MaxAudioFileSize {
      if !split {
          return "", fmt.Errorf("file %s exceeds 25MB limit; use --split-media-file ...", filePath)
      }
      debuglog.Debug(debuglog.Basic, "File %s is larger than the size limit... breaking it up into chunks...\n", filePath)
      if files, cleanup, err = splitAudioFile(filePath, ext, MaxAudioFileSize); err != nil {
          return "", err
      }
  }

  for i, f := range files {
      debuglog.Debug(debuglog.Basic, "Using model %s to transcribe part %d (file name: %s)...\n", model, i+1, f)
      ...
  }
  ```

  - ffmpeg splitting logs:
  ```go
  // internal/plugins/ai/openai/openai_audio.go
  debuglog.Debug(debuglog.Basic, "Running ffmpeg to split audio into %d-second chunks...\n", segmentTime)
  ```

  - Template/extension logging normalization:
  ```go
  // internal/plugins/template/template.go
  func debugf(format string, a ...interface{}) {
      debuglog.Debug(debuglog.Trace, format, a...)
  }

  // internal/plugins/template/extension_registry.go
  debuglog.Debug(debuglog.Basic, "Warning: could not load extension registry: %v\n", err)
  ```

  - README debug flag documentation:
  ```md
  --debug=                     Set debug level (0: off, 1: basic, 2: detailed, 3: trace)

  ### Debug Levels
  - 0: off (default)
  - 1: basic debug info
  - 2: detailed debugging
  - 3: trace level
  ```

  ## Reason for Changes

  - Provide a consistent, configurable logging experience across the CLI and internal modules.
  - Replace scattered, ad-hoc debug handling (including global variables and env-specific toggles) with a centralized, thread-safe logging API.
  - Improve transparency and diagnostics for STT flows (especially chunking behavior for large files).
  - Offer better user documentation for STT usage and debugging.
  - Keep default behavior unchanged while enabling optional verbosity for troubleshooting.

  ## Impact of Changes

  - Default behavior remains unchanged (debug level 0/off).
  - Users can now enable richer diagnostics with `--debug {0..3}`.
  - STT workflows output actionable logs when debug is enabled (file size checks, ffmpeg chunking progress, per-chunk transcription).
  - Shell completion updates ensure discoverability and ease-of-use for the `--debug` flag.
  - Removal of `FABRIC_STT_DEBUG` consolidates configuration into the CLI flag.
  - Internal codebase gains a unified logging approach that is thread-safe and extensible.

  ## Test Plan

  - CLI parsing and precedence:
    - Run with no `--debug`: confirm no debug output.
    - Run with `--debug 1`, `--debug=2`, `--debug 3`: confirm appropriate verbosity.
    - Confirm early logs (e.g., YAML mapping messages) are emitted when `--debug` is provided before parsing.
  - STT flows:
    - Transcribe a <25MB file; confirm expected output and no chunking logs unless debug enabled.
    - Transcribe a >25MB file without `--split-media-file`; confirm error message suggests enabling splitting.
    - Transcribe a >25MB file with `--split-media-file`; confirm ffmpeg logs and per-chunk logs at basic level.
  - Shell completions:
    - Verify `--debug` values are suggested (zsh, bash, fish).
  - Template/extensions:
    - Trigger scenarios that load extension registry; confirm warning logged only when debug level permits.
  - Regression:
    - Run common patterns and chat sessions across vendors to confirm no behavior changes when debug=0.

  ## Additional Notes

  - Breaking change: `FABRIC_STT_DEBUG` is removed. Use `--debug` instead.
  - Current scope: `--debug` is a CLI-only setting. There is no YAML tag for `debug` in the Flags struct; if we want config-file support, we can add `yaml:"debug"` in a follow-up.
  - Follow-ups to consider:
    - Input validation for `--debug` range within flag parsing.
    - Timestamped logging and/or log levels in output prefix.
    - Pluggable log output formatters (JSON/structured logs) if needed.

commits:
  [{"SHA":"ff1ef380a74bb95ff2532c06cd3d2439bdd57ee6","Message":"feat: add --debug flag with levels and centralized logging\n\nCHANGES\n- Add --debug flag controlling runtime logging verbosity levels\n- Introduce internal/log package with Off, Basic, Detailed, Trace\n- Replace ad-hoc Debugf and globals with centralized debug logger\n- Wire debug level during early CLI argument parsing\n- Add bash, zsh, fish completions for --debug levels\n- Document debug levels in README with usage examples\n- Add comprehensive STT guide covering models, flags, workflows\n- Simplify splitAudioFile signature and log ffmpeg chunking operations\n- Remove FABRIC_STT_DEBUG environment variable and related code\n- Clean minor code paths in vendors and template modules","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-19T06:53:10Z","Parents":null}]


title: docs: update README with Venice AI provider and Windows install script
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1723
merged_at: 2025-08-20 16:35:18+00:00
created_at: 2025-09-11 18:18:34
body:
  ## Summary

  Add native support for the Venice AI provider (OpenAI-compatible) and update documentation:
  - Introduce Venice AI to the OpenAI-compatible provider map with its API base URL.
  - Update README with a new “Recent Major Feature” entry for Venice AI support.
  - Add a Windows PowerShell one-liner for installing Fabric.
  - Add “Debug Levels” to the README table of contents.
  - Include a changelog stub for PR #1723.

  ## Related Issues

  Closes #610 
  Closes #1187 

  ## Files Changed

  - internal/plugins/ai/openai_compatible/providers_config.go
    - Added Venice AI provider configuration.
  - README.md
    - Added v1.4.294 feature note for Venice AI.
    - Added PowerShell install snippet for Windows.
    - Added “Debug Levels” entry to the Usage section of the Table of Contents.
  - cmd/generate_changelog/incoming/1723.txt
    - New changelog entry describing the above updates.

  ## Code Changes

  - internal/plugins/ai/openai_compatible/providers_config.go
    - Add Venice AI to the provider map:
      ```go
      "Venice AI": {
          Name:                "Venice AI",
          BaseURL:             "https://api.venice.ai/api/v1",
          ImplementsResponses: false,
      },
      ```
    - Rationale:
      - BaseURL points to Venice’s OpenAI-compatible v1 API root.
      - ImplementsResponses=false indicates we’ll use the Chat Completions flow rather than OpenAI’s Responses API for this provider.

  - README.md
    - Recent Major Features:
      ```md
      - [v1.4.294](https://github.com/danielmiessler/fabric/releases/tag/v1.4.294) (Aug 20, 2025) — **Venice AI Support**: Added the Venice AI provider. Venice is a Privacy-First, Open-Source AI provider. See their ["About Venice"](https://docs.venice.ai/overview/about-venice) page for details.
      ```
    - Table of Contents:
      ```md
      - [Usage](#usage)
        - [Debug Levels](#debug-levels)
      ```
    - Windows install snippet:
      ```powershell
      $ErrorActionPreference = "Stop"
      $LATEST="https://github.com/danielmiessler/fabric/releases/latest/download/fabric-windows-amd64.exe"
      $DIR="${HOME}\.local\bin"
      New-Item -Path $DIR -ItemType Directory -Force
      Invoke-Webrequest -URI  "${LATEST}" -outfile "${DIR}\fabric.exe"
      & "${DIR}\fabric.exe" /version
      ```

  - cmd/generate_changelog/incoming/1723.txt
    - Adds the changelog notes for this PR, including the Venice AI provider, Windows install script, debug levels ToC update, and the v1.4.294 release note.

  ## Reason for Changes

  - Feature addition: Enable users to select Venice AI as a provider via our OpenAI-compatible integration.
  - Documentation improvements: Make it easier for Windows users to install Fabric and surface debugging information in the README’s ToC.
  - Transparency: Update Recent Major Features and include a structured changelog entry for release automation.

  ## Impact of Changes

  - New functionality: Users can now target Venice AI using the OpenAI-compatible path with the configured base URL.
  - No breaking changes: Existing providers and defaults are unchanged.
  - Documentation: Easier onboarding for Windows and better discoverability for debugging guidance.
  - Release communication: The README’s feature list and the changelog entry align with the upcoming v1.4.294 release.

  ## Test Plan

  - Provider config:
    - Build and run Fabric.
    - Verify that “Venice AI” appears in any provider listing (if available) and can be selected.
    - Used the `--listmodels` subcommand and verified that Venice models show up.
    - Executed a simple prompt using the Venice AI provider and a valid API key.

commits:
  [{"SHA":"97beaecbeb39fd30327bd3df419afea31218ac24","Message":"docs: update README with Venice AI provider and Windows install script\n\n- Add Venice AI provider configuration with API endpoint\n- Document Venice AI as privacy-first open-source provider\n- Include PowerShell installation script for Windows users\n- Add debug levels section to table of contents\n- Update recent major features with v1.4.294 release notes\n- Configure Venice AI base URL and response settings","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-20T16:23:31Z","Parents":null}]


title: Standardize Anthropic Beta Failure Logging
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1727
merged_at: 2025-08-24 20:20:20+00:00
created_at: 2025-09-11 18:18:34
body:
  # Standardize Anthropic Beta Failure Logging

  ## Summary

  This PR replaces direct stderr output with structured debug logging for Anthropic API beta feature failures, improving the consistency of error handling and debug output across the codebase.

  ## Related Issues

  Closes #1724 

  You can still see the warning when using the `--debug` flag

  ```text
  fabric -m $MODEL_CLAUDE --debug 1 test
  DEBUG: Anthropic beta feature context-1m-2025-08-07 failed: POST "https://api.anthropic.com/v1/messages": 400 Bad Request (Request-ID: req_011CST94aNKdnaLbUmGY7Mjf) {"type":"error","error":{"type":"invalid_request_error","message":"The long context beta is not yet available for this subscription."},"request_id":"req_011CST94aNKdnaLbUmGY7Mjf"}
  I understand you want me to execute instructions using your input "test" and respond only in en-US English.
  ```

  ## Files Changed

  - **internal/plugins/ai/anthropic/anthropic.go**: Modified error reporting mechanism from using `fmt.Fprintf(os.Stderr, ...)` to using the internal debug logging system `debuglog.Debug()`.

  ## Code Changes

  ### internal/plugins/ai/anthropic/anthropic.go

  **Import changes:**
  ```go
  - "os"
  + debuglog "github.com/danielmiessler/fabric/internal/log"
  ```

  **SendStream method (line ~198):**
  ```go
  - fmt.Fprintf(os.Stderr, "Anthropic beta feature %s failed: %v\n", strings.Join(betas, ","), stream.Err())
  + debuglog.Debug(debuglog.Basic, "Anthropic beta feature %s failed: %v\n", strings.Join(betas, ","), stream.Err())
  ```

  **Send method (line ~292):**
  ```go
  - fmt.Fprintf(os.Stderr, "Anthropic beta feature %s failed: %v\n", strings.Join(betas, ","), err)
  + debuglog.Debug(debuglog.Basic, "Anthropic beta feature %s failed: %v\n", strings.Join(betas, ","), err)
  ```

  ## Reason for Changes

  The changes standardize error reporting throughout the application by utilizing the internal debug logging system instead of writing directly to stderr. This provides:
  - Centralized control over debug output visibility
  - Consistent logging format across the application
  - Better control over log levels and filtering

  ## Impact of Changes

  - **Logging Consistency**: Debug messages for Anthropic beta feature failures now follow the same logging patterns as the rest of the application
  - **No Functional Changes**: The error handling logic remains unchanged - beta features that fail still fall back to standard API calls
  - **Debug Control**: These messages can now be controlled via the application's debug logging configuration rather than always appearing in stderr

  ## Test Plan

  1. Test with Anthropic API calls that use beta features
  2. Verify that when beta features fail, the debug messages appear when debug logging is enabled
  3. Confirm fallback to standard API calls still works correctly
  4. Ensure no debug output appears in stderr when debug logging is disabled

  ## Additional Notes

  - The `debuglog.Basic` level was chosen for these messages as they represent non-critical fallback scenarios
  - The message format and content remain identical to preserve any existing log parsing or monitoring
  - No changes to the actual error handling flow - this is purely a logging improvement

commits:
  [{"SHA":"772337bf0d6653202106d2c3caa9e64f59709260","Message":"refactor: route Anthropic beta failure logs through internal debug logger\n\nCHANGES\n- Replace fmt.Fprintf stderr with debuglog.Debug for beta failures\n- Import internal log package and remove os dependency\n- Standardize logging level to debuglog.Basic for beta errors\n- Preserve fallback stream behavior when beta features fail\n- Maintain message send fallback when beta options fail","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-24T20:01:59Z","Parents":null}]


title: Refactor Logging System to Use Centralized Debug Logger
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1728
merged_at: 2025-08-26 03:13:26+00:00
created_at: 2025-09-11 18:18:34
body:
  # Refactor Logging System to Use Centralized Debug Logger

  ## Summary

  This PR refactors the notification and error handling system throughout the Fabric codebase by introducing a centralized debug logging infrastructure. All direct `stderr` output calls have been replaced with a new `debuglog` package, providing a consistent and configurable approach to logging debug information and warnings.

  ## Files Changed

  - **`.vscode/settings.json`**: Added new dictionary entries for spell checking (debuglog, sgaunet, SSEHTTP)
  - **`cmd/generate_changelog/incoming/1728.txt`**: Added changelog entry documenting this refactoring effort
  - **`internal/cli/chat.go`**: Replaced stderr output for notification failures with debug logging
  - **`internal/cli/cli.go`**: Replaced stderr output for initialization errors with debug logging
  - **`internal/cli/output.go`**: Replaced file creation notification with debug logging
  - **`internal/core/plugin_registry.go`**: Replaced vendor ambiguity warning with debug logging
  - **`internal/core/plugin_registry_test.go`**: Updated tests to properly capture and verify debug log output
  - **`internal/plugins/ai/anthropic/oauth.go`**: Replaced all OAuth flow status messages with debug logging
  - **`internal/plugins/ai/perplexity/perplexity.go`**: Fixed streaming error handling to use debug logging
  - **`internal/tools/patterns_loader.go`**: Replaced pattern loading notifications with debug logging

  ## Code Changes

  ### Core Infrastructure Addition
  The most significant change is the introduction of the `debuglog` package:
  ```go
  import debuglog "github.com/danielmiessler/fabric/internal/log"
  ```

  ### Standardized Error Logging Pattern
  All instances of direct stderr output have been replaced:
  ```go
  // Before
  fmt.Fprintf(os.Stderr, "Failed to send notification: %v\n", err)

  // After
  debuglog.Debug(debuglog.Basic, "Failed to send notification: %v\n", err)
  ```

  ### Test Infrastructure Updates
  Tests now properly configure and capture debug log output:
  ```go
  debuglog.SetLevel(debuglog.Basic)
  debuglog.SetOutput(w)
  defer func() {
      os.Stderr = oldStderr
      debuglog.SetOutput(oldStderr)
  }()
  ```

  ### Perplexity Error Handling Fix
  Fixed a malformed escape sequence in the error message:
  ```go
  // Before (with incorrect escape)
  fmt.Fprintf(os.Stderr, "perplexity streaming error: %v\\n", err)

  // After
  debuglog.Debug(debuglog.Basic, "perplexity streaming error: %v\n", err)
  ```

  ## Reason for Changes

  1. **Centralized Logging**: Provides a single point of control for all debug output, making it easier to manage verbosity levels and output destinations
  2. **Consistency**: Ensures all notifications, warnings, and debug messages follow the same format and behavior
  3. **Testability**: Makes it easier to test code that produces debug output by allowing tests to capture and verify log messages
  4. **Configurability**: Enables future enhancements like log levels, filtering, and different output formats without changing every logging call site
  5. **Bug Fix**: Corrects the malformed escape sequence in Perplexity error handling

  ## Impact of Changes

  - **No Functional Changes**: This is a pure refactoring - the user-visible behavior remains the same
  - **Improved Maintainability**: Future changes to logging behavior only need to be made in the `debuglog` package
  - **Better Testing**: Tests can now properly verify that appropriate warnings and notifications are being generated
  - **Foundation for Future Enhancements**: The debug logging infrastructure can be extended with features like:
    - Different log levels (INFO, WARN, ERROR, DEBUG)
    - Log rotation and file output
    - Structured logging (JSON format)
    - Performance metrics and telemetry

  ## Test Plan

  1. **Unit Tests**: Updated existing tests to properly capture and verify debug output
  2. **Integration Testing**: Verify that all existing commands still produce expected output:
     - OAuth flow messages appear correctly
     - Pattern loading notifications work
     - Vendor ambiguity warnings are shown
     - File creation notifications are displayed
  3. **Error Path Testing**: Ensure error messages are properly logged when:
     - Notification sending fails
     - Pattern directories cannot be read
     - Perplexity streaming encounters errors

  ## Additional Notes

  - The `debuglog` package uses the `Basic` level for all current logging, suggesting a simple on/off model initially
  - The package import alias ensures consistency across all files
  - Comment capitalization was corrected in the Perplexity error message
  - The changelog entry (1728.txt) properly documents this change for release notes

commits:
  [{"SHA":"4008125e377866cde1fe461dc086295927a65b7d","Message":"refactor: replace stderr prints with centralized debuglog.Log and improve auth messaging\n\n- Replace fmt.Fprintf/os.Stderr with centralized debuglog.Log across CLI\n- Add unconditional Log function to debuglog for important messages\n- Improve OAuth flow messaging and token refresh diagnostics\n- Update tests to capture debuglog output via SetOutput\n- Convert Perplexity streaming errors to unified debug logging\n- Emit file write notifications through debuglog instead of stderr\n- Warn on ambiguous model selection using centralized logger\n- Announce large audio processing steps via debuglog progress messages\n- Standardize extension registry and patterns warnings through debuglog","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-26T01:11:30Z","Parents":null}]


title: Add GitHub Community Health Documents
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1729
merged_at: 2025-08-26 15:08:53+00:00
created_at: 2025-09-11 18:18:34
body:
  # Add GitHub Community Health Documents

  ## Summary

  This PR introduces comprehensive documentation improvements and community guidelines for the Fabric project. The changes establish formal contribution processes, security policies, and support documentation to facilitate better community engagement and project governance.

  ## Related Issues

  Closes #764

  ## Files Changed

  - **`.vscode/settings.json`**: Added "golint" to the spell checker's word list for VS Code
  - **`docs/CODE_OF_CONDUCT.md`**: New file establishing community behavior expectations and guidelines
  - **`docs/CONTRIBUTING.md`**: New file providing detailed contribution guidelines and development setup instructions
  - **`docs/README.md`**: New documentation index file organizing all available documentation with descriptions
  - **`docs/SECURITY.md`**: New security policy document outlining vulnerability reporting and security best practices
  - **`docs/SUPPORT.md`**: New support documentation detailing how to get help and report issues

  ## Code Changes

  ### `.vscode/settings.json`
  ```diff
  +		"golint",
  ```
  Minor addition to support Go linting terminology in the VS Code environment.

  ### `docs/CODE_OF_CONDUCT.md`
  New 26-line document establishing:
  - Basic expectation of human decency and common sense
  - Professional conduct guidelines
  - Reporting and enforcement mechanisms

  ### `docs/CONTRIBUTING.md`
  Comprehensive 155-line contribution guide including:
  - Quick setup instructions with Go 1.24+ requirement
  - Development guidelines for code style and commit messages
  - **Critical changelog generation requirement** for PRs:
  ```bash
  cd cmd/generate_changelog
  go build -o generate_changelog .
  ./generate_changelog --incoming-pr YOUR_PR_NUMBER
  ```
  - Testing requirements and pattern creation guidelines

  ### `docs/README.md`
  88-line documentation hub that:
  - Organizes all documentation into logical categories (Core Features, UI/UX, Development)
  - Provides quick descriptions for each document
  - Includes quick start guides for new users and contributors
  - Establishes documentation standards

  ### `docs/SECURITY.md`
  158-line security policy covering:
  - Vulnerability reporting procedures (email to kayvan@sylvan.com and daniel@danielmiessler.com)
  - Security considerations for API keys, input validation, and AI provider integration
  - Response timeline commitments (Critical: 1-7 days, High: 7-30 days)
  - Known security limitations with AI providers and pattern execution

  ### `docs/SUPPORT.md`
  148-line support guide providing:
  - Clear escalation path from documentation to issues to discussions
  - Issue templates and labeling system
  - Response time expectations
  - Self-help troubleshooting tips

  ## Reason for Changes

  These documentation improvements address several critical needs:

  1. **Community Growth**: As the project grows, formal guidelines ensure productive collaboration
  2. **Security Transparency**: Clear security policies protect users and establish trust
  3. **Contributor Onboarding**: Detailed contribution guidelines reduce friction for new contributors
  4. **Support Scaling**: Structured support documentation helps users self-serve and reduces maintainer burden
  5. **Changelog Automation**: The emphasized changelog generation requirement ensures consistent release notes

  ## Impact of Changes

  ### Positive Impacts
  - **Improved Developer Experience**: Clear contribution guidelines and automated changelog requirements streamline the PR process
  - **Enhanced Security Posture**: Formal security policy provides clear vulnerability reporting channels
  - **Better Community Management**: Code of conduct sets professional expectations
  - **Reduced Support Burden**: Comprehensive support documentation enables self-service
  - **Documentation Discoverability**: Centralized README index improves navigation

  ### Potential Considerations
  - **Changelog Requirement**: The mandatory changelog generation for PRs adds a step to the contribution process but ensures better release documentation
  - **Security Contact Points**: Multiple email addresses for security reports may need coordination between recipients
  - **Documentation Maintenance**: These new documents will require periodic updates as the project evolves

  ## Test Plan

  Documentation changes don't require traditional testing, but verification should include:
  1. Confirming all internal links work correctly
  2. Validating email addresses for security contacts are active
  3. Testing the changelog generation command referenced in CONTRIBUTING.md
  4. Ensuring documentation follows markdown best practices and renders correctly on GitHub

  ## Additional Notes

  - The security policy's dual-email approach (kayvan@sylvan.com and daniel@danielmiessler.com) indicates a collaborative security response team
  - The CODE_OF_CONDUCT takes a refreshingly pragmatic approach, assuming contributors are adults who can work professionally
  - The documentation structure follows industry best practices with clear separation of concerns (contributing, security, support, conduct)

commits:
  [{"SHA":"713f6e46fe9c60de9c4f55a6cbbb7144d235f434","Message":"docs: add contributing, security, support, and code-of-conduct docs; add docs index\n\nCHANGES\n- Add CODE_OF_CONDUCT defining respectful, collaborative community behavior\n- Add CONTRIBUTING with setup, testing, PR, changelog requirements\n- Add SECURITY policy with reporting process and response timelines\n- Add SUPPORT guide for bugs, features, discussions, expectations\n- Add docs README indexing guides, quick starts, contributor essentials","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-26T13:31:14Z","Parents":null}]


title: Modernize Dockerfile with Best Practices Implementation
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1730
merged_at: 2025-08-27 14:09:12+00:00
created_at: 2025-09-11 18:18:34
body:
  # Modernize Dockerfile with Best Practices Implementation

  ## Summary

  This PR simplifies and modernizes the Docker infrastructure for the Fabric project by removing the complex test runner setup and consolidating the Docker configuration into a single, optimized Dockerfile with clear documentation.

  ## Files Changed

  ### Deleted Files
  - **scripts/docker-test/README.md**: Removed comprehensive test environment documentation (116 lines)
  - **scripts/docker-test/base/Dockerfile**: Removed test-specific Dockerfile (30 lines)
  - **scripts/docker-test/test-runner.sh**: Removed complex bash test runner script (235 lines)
  - **scripts/docker/docker-compose.yml**: Removed Docker Compose configuration (11 lines)
  - **scripts/docker/start-docker.sh**: Removed helper startup script (11 lines)

  ### Modified Files
  - **scripts/docker/Dockerfile**: Completely rewritten with modern best practices
  - **scripts/docker/README.md**: Updated with simpler, more practical usage instructions

  ## Code Changes

  ### scripts/docker/Dockerfile
  The Dockerfile has been significantly improved:

  ```dockerfile
  # Added dockerfile syntax declaration for better build features
  # syntax=docker/dockerfile:1

  # Simplified builder stage with explicit Go version
  FROM golang:1.24-alpine AS builder

  # Added git as a build dependency
  RUN apk add --no-cache git

  # Optimized binary build with size reduction flags
  RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /fabric ./cmd/fabric

  # Cleaner final stage with proper binary installation
  COPY --from=builder /fabric /usr/local/bin/fabric
  ENTRYPOINT ["fabric"]
  ```

  Key improvements:
  - Added `-ldflags="-s -w"` to strip debug symbols and reduce binary size
  - Moved binary to `/usr/local/bin/fabric` following standard Linux conventions
  - Removed unnecessary patterns directory copy
  - Removed hardcoded ENV file copy for better flexibility
  - Changed from fixed `CMD ["--serve"]` to flexible `ENTRYPOINT ["fabric"]`

  ### scripts/docker/README.md
  Complete rewrite focusing on practical usage:
  - Clear build instructions from repository root
  - Multiple configuration persistence strategies (directory vs single file)
  - Practical examples for both CLI and server modes
  - Removed references to docker-compose in favor of direct docker commands

  ## Reason for Changes

  1. **Simplification**: The test runner infrastructure was overly complex
  2. **Maintainability**: Removing 381 lines of test-specific code reduces maintenance burden
  3. **Flexibility**: The new Dockerfile is more flexible, allowing users to run any fabric command rather than forcing `--serve` mode
  4. **Best Practices**: Implemented Docker best practices including multi-stage builds, proper binary placement, and size optimization
  5. **User Experience**: Simplified documentation focuses on common use cases rather than internal testing procedures

  ## Impact of Changes

  ### Positive Impacts
  - **Smaller Image Size**: Using `-ldflags="-s -w"` significantly reduces the final binary size
  - **Better Flexibility**: Users can now run any fabric command, not just the server
  - **Cleaner Codebase**: Removed technical debt from what appears to be completed testing infrastructure
  - **Improved Documentation**: More practical, user-focused documentation

  ### Potential Considerations
  - **Testing Infrastructure**: If the docker-test setup was still being actively used, an alternative testing approach may be needed
  - **Migration**: Users relying on docker-compose.yml will need to switch to direct docker commands
  - **Environment Setup**: Users now need to manually manage their .env files rather than having them copied automatically

  ## Test Plan

  1. Build the Docker image: `docker build -t fabric -f scripts/docker/Dockerfile .`
  2. Verify setup works: `docker run --rm -it fabric --setup`
  3. Test with volume mount: `docker run --rm -it -v $HOME/.fabric-config:/root/.config/fabric fabric --listmodels`
  4. Test server mode: `docker run --rm -it -p 8080:8080 fabric --serve`
  5. Verify the API responds on http://localhost:8080

  ## Additional Notes

  - The new approach aligns better with container best practices where configuration is injected rather than baked into the image
  - Consider adding a GitHub Action to automatically build and publish the Docker image to a registry for easier distribution

commits:
  [{"SHA":"1622a3433148c1b8882e6c328c02444a4fb97de9","Message":"chore: remove docker-test framework and simplify production docker setup\n\n- Remove entire docker-test directory and testing infrastructure\n- Delete complex test runner script and environment files\n- Simplify production Dockerfile with multi-stage build optimization\n- Remove docker-compose.yml and start-docker.sh helper scripts\n- Update README with cleaner Docker usage instructions\n- Streamline container build process and reduce image size","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-27T13:47:12Z","Parents":null}]


title: chore: upgrade ollama dependency from v0.9.0 to v0.11.7
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1731
merged_at: 2025-08-27 18:05:04+00:00
created_at: 2025-09-11 18:18:34
body:
  ## Summary

  Updated the Ollama dependency from version 0.9.0 to 0.11.7 to incorporate the latest features, improvements, and bug fixes from the upstream library.

  ## Files Changed

  - **go.mod**: Updated the Ollama package version requirement from v0.9.0 to v0.11.7
  - **go.sum**: Updated checksums to reflect the new Ollama package version and its dependencies

  ## Code Changes

  ### go.mod
  ```diff
  -	github.com/ollama/ollama v0.9.0
  +	github.com/ollama/ollama v0.11.7
  ```

  ### go.sum
  ```diff
  -github.com/ollama/ollama v0.9.0 h1:GvdGhi8G/QMnFrY0TMLDy1bXua+Ify8KTkFe4ZY/OZs=
  -github.com/ollama/ollama v0.9.0/go.mod h1:aio9yQ7nc4uwIbn6S0LkGEPgn8/9bNQLL1nHuH+OcD0=
  +github.com/ollama/ollama v0.11.7 h1:CuYjaJ/YEnvLDpJocJbbVdpdVFyGA/OP6lKFyzZD4dI=
  +github.com/ollama/ollama v0.11.7/go.mod h1:9+1//yWPsDE2u+l1a5mpaKrYw4VdnSsRU3ioq5BvMms=
  ```

  ## Reason for Changes

  This dependency update brings the project up to the latest stable version of the Ollama library. The version jump from 0.9.0 to 0.11.7 represents two minor version increments (0.9 → 0.10 → 0.11) plus several patch releases, which typically include:

  - Bug fixes and stability improvements
  - Performance optimizations
  - New features and API enhancements
  - Security patches

  ## Impact of Changes

  - **Compatibility**: The minor version changes may introduce new features while maintaining backward compatibility according to semantic versioning principles
  - **Stability**: Patch version 0.11.7 suggests multiple iterations of bug fixes since the 0.11.0 release
  - **Performance**: Latest version likely includes performance improvements accumulated over multiple releases
  - **Security**: Any security vulnerabilities discovered in versions 0.9.0 through 0.11.6 should be addressed

  ## Test Plan

  1. Run the full test suite to ensure all existing functionality works with the new Ollama version
  2. Verify that the application builds successfully with the updated dependency
  3. Test key integration points with the Ollama API to confirm backward compatibility
  4. Monitor for any deprecation warnings in the build output
  5. Perform regression testing on features that directly interact with the Ollama library

  ## Additional Notes

  - This is a routine dependency update with no accompanying code changes, suggesting the API remains compatible
  - The checksum change in go.sum is automatic and expected when updating dependencies
  - Consider reviewing the [Ollama release notes](https://github.com/ollama/ollama/releases) between v0.9.0 and v0.11.7 for a complete list of changes
  - Future updates should monitor for any breaking changes when Ollama reaches v1.0.0

  ## Comprehensive CVE List fixed by this change

  ### High Severity (7.5 CVSS Score)

  #### **CVE-2025-0317** - Ollama DoS Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-0317](https://nvd.nist.gov/vuln/detail/CVE-2025-0317)
  - **CVSS Score**: 7.5 (High)
  - **Description**: A vulnerability in ollama/ollama versions <=0.3.14 allows a malicious user to upload and create a customized GGUF model file on the Ollama server. This can lead to a division by zero error in the ggufPadding function, causing the server to crash and resulting in a Denial of Service (DoS) attack.
  - **Affected**: Ollama server versions ≤ 0.3.14
  - **Impact**: Denial of Service through division by zero error

  #### **CVE-2025-0315** - Ollama DoS Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-0315](https://nvd.nist.gov/vuln/detail/CVE-2025-0315)
  - **CVSS Score**: 7.5 (High)
  - **Description**: Vulnerability allows Denial of Service via customized GGUF model file upload on Ollama server.
  - **Affected**: Ollama/ollama versions ≤ 0.3.14
  - **Impact**: Denial of Service through malicious GGUF model file uploads

  #### **CVE-2024-12886** - Ollama Out-of-Memory Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-12886](https://nvd.nist.gov/vuln/detail/CVE-2024-12886)
  - **CVSS Score**: 7.5 (High)
  - **Description**: An Out-Of-Memory (OOM) vulnerability exists in the ollama server version 0.3.14. This vulnerability can be triggered when a malicious API server responds with a gzip bomb HTTP response, leading to the ollama server crashing.
  - **Affected**: Ollama server version 0.3.14
  - **Impact**: Denial of Service through memory exhaustion via gzip bomb attack

  #### **CVE-2024-8063** - General Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-8063](https://nvd.nist.gov/vuln/detail/CVE-2024-8063)
  - **CVSS Score**: 7.5 (High)
  - **Description**: Security vulnerability with high severity rating
  - **Impact**: Requires patching for security compliance

  #### **CVE-2024-12055** - General Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-12055](https://nvd.nist.gov/vuln/detail/CVE-2024-12055)
  - **CVSS Score**: 7.5 (High)
  - **Description**: High-severity security vulnerability requiring immediate attention
  - **Impact**: Critical security flaw needing remediation

  ### Medium Severity (6.9 CVSS Score)

  #### **CVE-2025-51471** - General Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-51471](https://nvd.nist.gov/vuln/detail/CVE-2025-51471)
  - **CVSS Score**: 6.9 (Medium)
  - **Description**: Medium severity security vulnerability
  - **Impact**: Security risk requiring patching as part of comprehensive security updates

  ### Low Severity (3.2 & 2.5 CVSS Score)

  #### **CVE-2025-46394** - Low Severity Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-46394](https://nvd.nist.gov/vuln/detail/CVE-2025-46394)
  - **CVSS Score**: 3.2 (Low)
  - **Description**: Low-severity security issue
  - **Impact**: Minor security concern addressed as part of comprehensive security maintenance

  #### **CVE-2024-58251** - Low Severity Vulnerability
  - **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-58251](https://nvd.nist.gov/vuln/detail/CVE-2024-58251)
  - **CVSS Score**: 2.5 (Low)
  - **Description**: Low-severity security vulnerability
  - **Impact**: Minimal security risk addressed for comprehensive security posture

  ### Summary

  This comprehensive security fix addresses **8 CVEs** total:
  - **5 High Severity** vulnerabilities (CVSS 7.5)
  - **1 Medium Severity** vulnerability (CVSS 6.9)
  - **2 Low Severity** vulnerabilities (CVSS 3.2 and 2.5)

  The majority of high-severity issues are related to **Ollama server vulnerabilities** that could lead to Denial of Service attacks through various vectors including division by zero errors, memory exhaustion, and malicious file uploads. These fixes ensure robust protection against these attack vectors and maintain system availability.

  **Priority**: The high-severity Ollama vulnerabilities should be considered critical for any systems running Ollama server components, as they can lead to service disruption and potential system crashes.

  ## What this Pull Request (PR) does
  Please briefly describe what this PR does.

  ## Related issues
  Please reference any open issues this PR relates to in here.
  If it closes an issue, type `closes #[ISSUE_NUMBER]`.

  ## Screenshots
  Provide any screenshots you may find relevant to facilitate us understanding your PR.

commits:
  [{"SHA":"d3de731967d7908f7ac36e88323a88c2be789d93","Message":"chore: upgrade ollama dependency from v0.9.0 to v0.11.7\n\n• Update ollama package to version 0.11.7\n• Refresh go.sum with new dependency checksums\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-0317](https://nvd.nist.gov/vuln/detail/CVE-2025-0317)\n- **CVSS Score**: 7.5 (High)\n- **Description**: A vulnerability in ollama/ollama versions \u003c=0.3.14 allows a malicious user to upload and create a customized GGUF model file on the Ollama server. This can lead to a division by zero error in the ggufPadding function, causing the server to crash and resulting in a Denial of Service (DoS) attack.\n- **Affected**: Ollama server versions ≤ 0.3.14\n- **Impact**: Denial of Service through division by zero error\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-0315](https://nvd.nist.gov/vuln/detail/CVE-2025-0315)\n- **CVSS Score**: 7.5 (High)\n- **Description**: Vulnerability allows Denial of Service via customized GGUF model file upload on Ollama server.\n- **Affected**: Ollama/ollama versions ≤ 0.3.14\n- **Impact**: Denial of Service through malicious GGUF model file uploads\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-12886](https://nvd.nist.gov/vuln/detail/CVE-2024-12886)\n- **CVSS Score**: 7.5 (High)\n- **Description**: An Out-Of-Memory (OOM) vulnerability exists in the ollama server version 0.3.14. This vulnerability can be triggered when a malicious API server responds with a gzip bomb HTTP response, leading to the ollama server crashing.\n- **Affected**: Ollama server version 0.3.14\n- **Impact**: Denial of Service through memory exhaustion via gzip bomb attack\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-8063](https://nvd.nist.gov/vuln/detail/CVE-2024-8063)\n- **CVSS Score**: 7.5 (High)\n- **Description**: Security vulnerability with high severity rating\n- **Impact**: Requires patching for security compliance\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-12055](https://nvd.nist.gov/vuln/detail/CVE-2024-12055)\n- **CVSS Score**: 7.5 (High)\n- **Description**: High-severity security vulnerability requiring immediate attention\n- **Impact**: Critical security flaw needing remediation\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-51471](https://nvd.nist.gov/vuln/detail/CVE-2025-51471)\n- **CVSS Score**: 6.9 (Medium)\n- **Description**: Medium severity security vulnerability\n- **Impact**: Security risk requiring patching as part of comprehensive security updates\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2025-46394](https://nvd.nist.gov/vuln/detail/CVE-2025-46394)\n- **CVSS Score**: 3.2 (Low)\n- **Description**: Low-severity security issue\n- **Impact**: Minor security concern addressed as part of comprehensive security maintenance\n\n- **Link**: [https://nvd.nist.gov/vuln/detail/CVE-2024-58251](https://nvd.nist.gov/vuln/detail/CVE-2024-58251)\n- **CVSS Score**: 2.5 (Low)\n- **Description**: Low-severity security vulnerability\n- **Impact**: Minimal security risk addressed for comprehensive security posture\n\nThis comprehensive security fix addresses **8 CVEs** total:\n- **5 High Severity** vulnerabilities (CVSS 7.5)\n- **1 Medium Severity** vulnerability (CVSS 6.9)\n- **2 Low Severity** vulnerabilities (CVSS 3.2 and 2.5)\n\nThe majority of high-severity issues are related to **Ollama server vulnerabilities** that could lead to Denial of Service attacks through various vectors including division by zero errors, memory exhaustion, and malicious file uploads. These fixes ensure robust protection against these attack vectors and maintain system availability.\n\n**Priority**: The high-severity Ollama vulnerabilities should be considered critical for any systems running Ollama server components, as they can lead to service disruption and potential system crashes.","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-27T17:46:25Z","Parents":null}]


title: CI Infra: Changelog Generation Tool + Docker Image Pubishing
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1732
merged_at: 2025-08-28 06:39:05+00:00
created_at: 2025-09-11 18:18:34
body:
  # CI Infra: Changelog Generation Tool + Docker Image Pubishing

  ## Summary

  This PR adds automated Docker image publishing workflows and improves the pattern verification workflow while making the changelog generator more flexible by dynamically detecting GitHub repository information.

  ## Files Changed

  - **`.github/workflows/docker-publish-on-tag.yml`** (new): Added a comprehensive GitHub Actions workflow for building and publishing multi-architecture Docker images to both GitHub Container Registry (GHCR) and Docker Hub when version tags are pushed.

  - **`.github/workflows/patterns.yaml`** (modified): Enhanced the patterns workflow to handle cases where no changes are detected more gracefully, preventing unnecessary job failures.

  - **`.vscode/settings.json`** (modified): Added new words to the VS Code spell checker dictionary to support the new Docker workflow terminology.

  - **`cmd/generate_changelog/internal/release.go`** (modified): Refactored to dynamically detect GitHub repository information from git remote configuration instead of hardcoding repository owner and name.

  ## Code Changes

  ### Docker Publishing Workflow
  The new workflow implements a sophisticated two-job pipeline:
  ```yaml
  jobs:
    build-and-push:
      if: ${{ github.repository_owner == 'ksylvan' }}
      # Builds multi-arch images for linux/amd64,linux/arm64
      # Tags with version patterns (v1.4.300, 1.4.300, 1.4)
      
    move-latest:
      needs: build-and-push
      if: ${{ needs.build-and-push.outputs.is_latest == 'true' }}
      # Updates :latest tag only for the highest semver tag
  ```

  ### Patterns Workflow Improvement
  ```yaml
  - if git diff --quiet HEAD~1 -- data/patterns; then
  -   echo "No changes detected in patterns folder."
  -   exit 1
  + if git diff --quiet HEAD~1 -- data/patterns; then
  +   echo "No changes detected in patterns folder."
  +   echo "changes=false" >> $GITHUB_OUTPUT
  + else
  +   echo "Changes detected in patterns folder."
  +   echo "changes=true" >> $GITHUB_OUTPUT
  ```

  ### Dynamic Repository Detection
  ```go
  +func getGitHubInfo() (owner, repo string, err error) {
  +    cmd := exec.Command("git", "remote", "get-url", "origin")
  +    // Handles both SSH and HTTPS GitHub URLs
  +    // Returns extracted owner and repo names
  +}
  ```

  ## Reason for Changes

  1. **Docker Publishing**: Enables automated container image releases when version tags are created, supporting both GHCR and Docker Hub registries with multi-architecture builds (AMD64 and ARM64).

  2. **Patterns Workflow**: Previously failed when no changes were detected in the patterns folder, which was unnecessarily disruptive. Now gracefully skips artifact creation when no changes exist.

  3. **Changelog Generator**: Removes hardcoded repository references, making the tool reusable across different GitHub repositories and forks.

  ## Impact of Changes

  - **Deployment**: Automated Docker image publishing will streamline the release process and ensure consistent multi-architecture support.
  - **CI/CD**: The patterns workflow will no longer fail spuriously, reducing noise in CI notifications.
  - **Portability**: The changelog generator can now be used in forks or other repositories without code modifications.
  - **Performance**: The Docker workflow uses GitHub Actions cache to optimize build times.

  ## Test Plan

  1. **Docker Workflow**: Test by creating a version tag (e.g., `v1.0.0`) and verify images are published to both registries with correct tags.
  2. **Patterns Workflow**: Test with commits that both do and don't modify the `data/patterns` directory.
  3. **Changelog Generator**: Test in different repository contexts (forks, different repos) to verify dynamic detection works correctly.

  ## Additional Notes

  ### Potential Issues to Monitor

  1. **Docker Hub Rate Limits**: The workflow assumes Docker Hub credentials are properly configured in repository secrets (`DOCKERHUB_TOKEN`).

  2. **Concurrency Control**: The `move-latest` job uses a concurrency group to prevent race conditions when multiple tags are pushed simultaneously.

  3. **Repository Owner Check**: The workflow includes a safety check (`if: ${{ github.repository_owner == 'ksylvan' }}`) that should be adjusted based on the intended deployment target.

  4. **Git Remote URL Parsing**: The regex patterns in `getGitHubInfo()` assume standard GitHub URL formats. Edge cases with non-standard remote configurations may need additional handling.

commits:
  [{"SHA":"08eb48c2e799656957b5becc0fc72bdf337df627","Message":"ci: add tag-based multi-arch Docker publish to GHCR and Docker Hub\n\nCHANGES\n- Add GitHub Actions workflow to publish Docker images on tags\n- Build multi-arch images with Buildx and QEMU across amd64, arm64\n- Tag images using semver; push to GHCR and Docker Hub\n- Set :latest only for highest semver tag via imagetools\n- Gate patterns workflow steps on detected changes instead of failing\n- Auto-detect GitHub owner and repo from git remote URL\n- Remove hardcoded repository values in changelog release manager\n- Normalize image names to lowercase for registry compatibility\n- Enable GitHub Actions cache for faster Docker builds\n- Add VS Code dictionary entries for Docker-related terms","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-28T06:18:20Z","Parents":null}]


title: Fix Docker Build Path Configuration
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1735
merged_at: 2025-08-28 14:10:37+00:00
created_at: 2025-09-11 18:18:34
body:
  # Fix Docker Build Path Configuration

  ## Summary

  This PR updates the Docker build configuration and modifies the version update workflow triggers. The changes ensure the Docker build process uses the correct Dockerfile location and adjusts which file changes trigger the version update and tagging workflow.

  ## Files Changed

  - `.github/workflows/docker-publish-on-tag.yml`: Added explicit Dockerfile path for the Docker build action
  - `.github/workflows/update-version-and-create-tag.yml`: Removed markdown files from the ignore list for workflow triggers

  ## Code Changes

  ### `.github/workflows/docker-publish-on-tag.yml`
  Added a new `file` parameter to specify the Dockerfile location:
  ```yaml
  @@ -101,6 +101,7 @@ jobs:
           uses: docker/build-push-action@v6
           with:
             context: .
  +          file: ./scripts/docker/Dockerfile
             push: true
  ```
  This explicitly tells the Docker build action to use the Dockerfile located at `./scripts/docker/Dockerfile` instead of looking for it in the root directory.

  ### `.github/workflows/update-version-and-create-tag.yml`
  Removed markdown files from the paths-ignore list:
  ```yaml
  @@ -6,7 +6,6 @@ on:
         - main # Monitor the main branch
       paths-ignore:
         - "data/patterns/**"
  -      - "**/*.md"
         - "data/strategies/**"
  ```
  This means changes to markdown files will now trigger the version update and create tag workflow.

  ## Reason for Changes

  1. **Docker Build Fix**: The Dockerfile appears to be located in a subdirectory (`./scripts/docker/`) rather than the repository root. Without specifying the file path, the Docker build action would fail to find the Dockerfile, causing build failures.

  2. **Workflow Trigger Enhancement**: Removing markdown files from the ignore list ensures that documentation updates can trigger version updates, which may be desired for maintaining version consistency when important documentation changes are made.

  ## Impact of Changes

  - **Docker Builds**: Will now successfully locate and use the correct Dockerfile, preventing build failures in the CI/CD pipeline
  - **Version Management**: Documentation changes will now trigger the version update workflow, potentially increasing the frequency of version bumps but ensuring documentation updates are properly versioned

  ## Test Plan

  1. Verify that the Docker build workflow successfully completes when a new tag is created
  2. Confirm the Docker image is built using the Dockerfile at `./scripts/docker/Dockerfile`
  3. Test that pushing changes to markdown files on the main branch triggers the version update workflow
  4. Ensure other ignored paths (patterns, strategies, etc.) still correctly prevent workflow execution

  ## Additional Notes

  - Consider whether triggering version updates on markdown changes aligns with your versioning strategy. If documentation changes shouldn't trigger new versions, this change should be reconsidered
  - Ensure the Dockerfile at `./scripts/docker/Dockerfile` exists and is properly maintained
  - Monitor the initial runs of these workflows after merging to catch any unexpected behavior early

commits:
  [{"SHA":"dcfc94ca07f220f4921d86a22eed0ca8b6f34f49","Message":"fix: update Docker workflow to use specific Dockerfile and monitor markdown file changes\n\n• Add explicit Dockerfile path to Docker build action\n• Remove markdown files from workflow paths-ignore filter\n• Enable CI triggers for documentation file changes\n• Specify Docker build context with custom file location","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-28T13:51:34Z","Parents":null}]


title: Winget Publishing and GoReleaser
author: tonymet
author_url: https://github.com/tonymet
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1736
merged_at: 2025-08-31 14:36:12+00:00
created_at: 2025-09-11 18:18:34
body:
  ## What this Pull Request (PR) does

  Moves build, archive (tar.gz/.zip) & publishing (github releases) into goreleaser.  runner is still github actions. 

  ## New Features
  * publish new version to winget catalog 
  * linux-arm (raspberry pi & other ARM chips) & windows-arm (Microsoft Surface & ultra-portable laptop) targets 
  * fixes Windows Smart Screen Warnings during download from MS Edge to prevent false Virus scan reports against URL/binary

  ## Improved Features
  *  cross-compile all 9 build targets on a single ubuntu-latest (AMD64) host.  
  *  auto tag & version management within `goreleaser`
  *  remove ~ 6 build matrix steps to simplify
  *  Reduces false-positive on Virus Scanners :  uses gzip / .zip archive used for publishing to github releases . 
  * generate changelog with goreleaser step
  * ~~improved patterns.yaml steps to return good build even when no patterns have changed . see example https://github.com/tonymet/Fabric/actions/runs/17303887490/job/49121754867~~ resolved with rebase
  * updated most github actions to latest including checkout , go-setup , etc to improve speed. 

  ## Regressions

  * release.yaml build is slower on a single runner.  could be sped up with larger runner. Minor issue
  * from ~3.5 min to 7.5 min to build all targets.

  ## TODO

  * ✅ ~~[contributor] will run quick sanity on all new targets.~~  available targets are good
  * ✅ ~~[maintainer] PRIOR TO MERGE: update references from `tonymet/fabric` to `danielmiessler/fabric`~~
  * ✅ -- [maintainer] changelog and release anotations are already handled by `cmd/generate_changelog`
  * ✅ -- [maintainer] review archive naming pattern & contents e.g. fabric-Darwin-xxxx .  slight change 

  Followup actions:
  * [ ] -- [maintainer] to create new winget release process in separate repository.

  ## Sanity Review

  |       | Linux  | Windows | Darwin |
  |-------|-----------|-----------|-----------|
  | x86_64 | ✅ | ✅ | ✅ |
  | arm | ✅| pending |  ✅|
  | i386  | ✅ | ✅ | 🟨 (skipped) |

  ## Related issues

  Closes #1722

  ## Testing

  ### Test builds with dirty files
  ```
   goreleaser build --clean --snapshot
   ```
   
  ### Test release artifacts no upload
   ```
    goreleaser release --snapshot --auto-snapshot --clean
   ```
   
   ### Sanity 
  ```
  fabric "why is the sky blue? 2 sentences"
  fabric --help
  ``` 

  ## References

  * Example winget pull request https://github.com/microsoft/winget-pkgs/pull/288080
  * Example release with improved build targets and artifacts https://github.com/tonymet/Fabric/releases/tag/v1.4.300
  * example patterns.yaml build https://github.com/tonymet/Fabric/actions/runs/17303887490/job/49121754867

commits:
  [{"SHA":"aa59d58deb99949a5acb1b28e4cf4e8d392c9ccc","Message":"chore: goreleaser and winget support","Author":"Anthony Metzidis","Email":"","Date":"2025-08-27T23:59:26Z","Parents":null},{"SHA":"8d2fda3af901b2c762d66f13c1d6724244660a2f","Message":"ci: harden release pipeline; gate to upstream, migrate tokens, remove docker-on-tag\n\nCHANGES\n- Gate release and version workflows to upstream owner only.\n- Switch tagging and releases to built-in GITHUB_TOKEN.\n- Replace environment passing with step outputs across workflows.\n- Remove docker-publish-on-tag workflow to reduce duplication and complexity.\n- Add OCI description label to Docker image.\n- Document GHCR multi-arch annotations for accurate package descriptions.\n- Update README with new ARM binary release announcement.\n- Simplify GoReleaser config by removing comments and extras.","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-28T22:03:20Z","Parents":null}]


title: Add New Psychological Analysis Patterns + devalue version bump
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1737
merged_at: 2025-08-28 19:38:25+00:00
created_at: 2025-09-11 18:18:34
body:
  # Add New Psychological Analysis Patterns + devalue version bump

  ## Summary

  This PR introduces two new pattern templates for the Fabric framework that leverage psychological profiles to generate creative content and therapeutic guidance. Additionally, it includes a minor dependency update in the web module.

  Thanks to [OmriH-Elister](https://github.com/OmriH-Elister) for the patterns.

  ## Files Changed

  ### Added Files
  - **`data/patterns/create_story_about_person/system.md`**: New pattern template that generates character-driven narratives based on psychological profiles
  - **`data/patterns/heal_person/system.md`**: New pattern template that creates personalized healing and life improvement plans from psychological data

  ### Modified Files
  - **`web/pnpm-lock.yaml`**: Updated the `devalue` package from version 5.1.1 to 5.3.2

  ## Code Changes

  ### `create_story_about_person/system.md`
  This pattern template establishes a structured approach for generating realistic short stories:
  - Takes psychological profiles as input (delimited by triple backticks)
  - Follows a 5-step process: analyze profile, brainstorm challenges, develop strategies, construct narrative, and maintain consistency
  - Outputs 500-700 word stories focusing on everyday problems and character-authentic responses

  ### `heal_person/system.md`
  This pattern template provides a framework for mental and spiritual healing guidance:
  - Processes psychological profiles or data files
  - Analyzes key issues, strengths, and improvement areas
  - Generates comprehensive plans with actionable recommendations
  - Outputs structured markdown with clear organization

  Note: The file appears to have duplicate content (the INPUT section contains a copy of the entire template), which may be unintentional.

  ### `web/pnpm-lock.yaml`
  ```diff
  -  devalue@5.1.1:
  -    resolution: {integrity: sha512-maua5KUiapvEwiEAe+XnlZ3Rh0GD+qI1J/nb9vrJc3muPXvcF/8gXYTWF76+5DAqHyDUtOIImEuo0YKE9mshVw==}
  +  devalue@5.3.2:
  +    resolution: {integrity: sha512-UDsjUbpQn9kvm68slnrs+mfxwFkIflOhkanmyabZ8zOYk8SMEIbJ3TK+88g70hSIeytu4y18f0z/hYHMTrXIWw==}
  ```

  ## Reason for Changes

  1. **Pattern Templates**: Expanding the Fabric framework's capabilities to include psychological analysis patterns, enabling users to generate creative content and therapeutic guidance based on personality profiles
  2. **Dependency Update**: Updating `devalue` to address potential security vulnerabilities and benefit from bug fixes in the newer version

  ## Impact of Changes

  - **New Functionality**: Users can now leverage psychological data to generate personalized stories and healing plans
  - **Enhanced Use Cases**: The framework now supports creative writing and mental health guidance applications
  - **Improved Security**: The `devalue` update (5.1.1 → 5.3.2) likely includes security patches and performance improvements

  ## Test Plan

  1. Verify the new pattern templates are correctly recognized by the Fabric framework
  2. Test the `create_story_about_person` pattern with sample psychological profiles to ensure story generation works as expected
  3. Test the `heal_person` pattern with various input formats to validate proper markdown output
  4. Confirm the web application builds and runs correctly with the updated `devalue` dependency
  5. Run any existing integration tests to ensure no regressions

  ## Additional Notes

  ### Potential Issues to Address:
  1. **Duplicate Content**: The `heal_person/system.md` file contains duplicated content where the entire template appears twice in the INPUT section. This should be reviewed and corrected.
  2. **Input Validation**: Consider adding validation for the expected input format (triple backticks) in both patterns
  3. **Ethical Considerations**: The `heal_person` pattern deals with mental health guidance - ensure appropriate disclaimers are included about not replacing professional medical advice

  ### Recommendations:
  - Add example usage documentation for both new patterns
  - Consider implementing unit tests for pattern validation
  - Review the duplicate content issue in `heal_person/system.md` before merging

commits:
  [{"SHA":"3ef3509bfd01108f937fec509c8adb25669f49a9","Message":"feat: add 'create_story_about_person' and 'heal_person' patterns; bump devalue\n\nCHANGES\n- Add create_story_about_person system pattern with narrative workflow\n- Add heal_person system pattern for compassionate healing plans\n- Update pattern_explanations to register new patterns and renumber indices\n- Extend pattern_descriptions with entries, tags, and concise descriptions\n- Add pattern_extracts for both patterns with full instruction blocks\n- Bump devalue dependency from 5.1.1 to 5.3.2\n- Refresh lockfile snapshots to reference updated devalue version\n- Sync web static pattern_descriptions with new patterns\n\nUpdates `devalue` from 5.1.1 to 5.3.2\n- [Release notes](https://github.com/sveltejs/devalue/releases)\n- [Changelog](https://github.com/sveltejs/devalue/blob/main/CHANGELOG.md)\n- [Commits](sveltejs/devalue@v5.1.1...v5.3.2)\n\n---\nupdated-dependencies:\n- dependency-name: devalue\n  dependency-version: 5.3.2\n  dependency-type: indirect\n  dependency-group: npm_and_yarn\n...\n\nSigned-off-by: dependabot[bot] \u003csupport@github.com\u003e","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-28T18:24:21Z","Parents":null}]


title: Restore our custom Changelog Updates in GitHub Actions
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1740
merged_at: 2025-08-31 15:37:48+00:00
created_at: 2025-09-11 18:18:34
body:
  # Restore our custom Changelog Updates in GitHub Actions

  This was unintentionally removed when we simplified our release process by adding GoReleaser.

  ## Summary

  This pull request enhances the release workflow by adding back in the automatic changelog generation and improves the release description update logic to handle forked repositories. The changes add a new step to the GitHub Actions workflow that generates and updates release descriptions, while also implementing fork-aware repository handling in the release manager.

  ## Files Changed

  ### `.github/workflows/release.yml`
  - **Added**: New workflow step "Update Release Description" that runs after the GoReleaser step
  - **Purpose**: Automatically generates and updates release descriptions using the changelog generator tool

  ### `cmd/generate_changelog/internal/release.go`
  - **Modified**: Enhanced `UpdateReleaseDescription` method with fork detection and handling
  - **Added**: New helper method `updateReleaseForRepo` to handle release updates for specific repositories
  - **Purpose**: Improved repository handling to work correctly with both original repositories and forks

  ## Code Changes

  ### GitHub Actions Workflow Enhancement
  ```yaml
  - name: Update Release Description
    run: go run ./cmd/generate_changelog --release ${{ github.ref_name }}
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  ```

  ### Fork-Aware Release Management
  The `UpdateReleaseDescription` method now includes:
  - Repository fork detection using GitHub API
  - Automatic upstream repository identification
  - Fallback mechanism to update current repository if upstream fails
  - Extracted release update logic into reusable `updateReleaseForRepo` helper method

  ## Reason for Changes

  These changes address two key requirements:
  1. **Automation**: Integrate changelog generation directly into the release workflow to ensure release descriptions are automatically updated
  2. **Fork Support**: Handle cases where the release process runs in a forked repository, attempting to update the upstream repository first before falling back to the current repository

  ## Impact of Changes

  ### Positive Impacts
  - **Improved Automation**: Release descriptions will be automatically generated and updated without manual intervention
  - **Better Fork Handling**: The tool now works correctly in forked repository scenarios, which is common in open-source development
  - **Enhanced User Experience**: More consistent and informative release descriptions

  ### Potential Risks
  - **API Rate Limits**: Additional GitHub API calls for repository information and upstream updates
  - **Permission Issues**: The workflow might fail if the GitHub token doesn't have sufficient permissions for upstream repositories
  - **Network Dependencies**: Additional failure points due to multiple API calls

  ## Test Plan

  The changes should be tested by:
  1. Running the release workflow on the main repository to verify automatic changelog generation
  2. Testing the fork detection logic by running the tool from a forked repository
  3. Verifying graceful fallback when upstream repository access fails
  4. Confirming that existing functionality remains intact for non-fork scenarios

  ## Additional Notes

  - The workflow step uses `${{ github.ref_name }}` to automatically pass the current release tag
  - Error handling includes detailed logging to help diagnose issues in fork scenarios
  - The implementation maintains backward compatibility with non-fork repository usage
  - Consider monitoring GitHub API usage to ensure rate limits are not exceeded during release processes

commits:
  [{"SHA":"eb759251ad772f2468d9e170e1e00133d0951248","Message":"ci: add changelog generation step to release workflow and support fork releases\n\n- Add changelog generation step to GitHub release workflow\n- Create updateReleaseForRepo helper method for release updates\n- Add fork detection logic in UpdateReleaseDescription method\n- Implement upstream repository release update for forks\n- Add fallback to current repository when upstream fails\n- Enhance error handling with detailed repository context\n- Remove duplicate success logging from main method","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-31T15:24:29Z","Parents":null}]


title: CI: Fix Release Description Update
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1741
merged_at: 2025-08-31 16:11:00+00:00
created_at: 2025-09-11 18:18:34
body:
  # CI: Fix Release Description Update

  ## Summary

  This PR updates the GitHub Actions release workflow to support both manual and automated release triggers by making the changelog generation more flexible in how it determines the release tag.

  ## Files Changed

  - `.github/workflows/release.yml` - Modified the changelog generation step to handle different trigger scenarios

  ## Code Changes

  The key change is in the "Update Release Description" step:

  ```yaml
  # Before
  run: go run ./cmd/generate_changelog --release ${{ github.ref_name }}

  # After  
  run: go run ./cmd/generate_changelog --release ${{ github.event.client_payload.tag || github.ref_name }}
  ```

  This change uses GitHub's logical OR operator (`||`) to first check for `github.event.client_payload.tag` and fall back to `github.ref_name` if the payload tag is not available.

  ## Reason for Changes

  This modification enables the release workflow to work correctly in multiple scenarios:

  1. **Repository dispatch events** - When triggered via API calls or external automation that includes a custom tag in the client payload
  2. **Manual/tag-based triggers** - When triggered by standard GitHub events where the tag is available in `github.ref_name`

  The fallback mechanism ensures backward compatibility while adding support for programmatic release triggering.

  ## Impact of Changes

  - **Improved flexibility**: The workflow can now handle releases triggered through different mechanisms
  - **Backward compatibility**: Existing manual release processes continue to work unchanged
  - **Enhanced automation support**: External systems can now trigger releases with custom tag specifications
  - **No breaking changes**: The fallback ensures existing functionality remains intact

  ## Test Plan

  To test these changes:

  1. **Manual trigger test**: Create a new tag and verify the release workflow uses `github.ref_name` correctly
  2. **Repository dispatch test**: Trigger the workflow via repository dispatch with a `client_payload.tag` and verify it uses the provided tag
  3. **Fallback test**: Trigger without client payload to confirm fallback to `github.ref_name` works

  ## Additional Notes

  - The change is minimal and low-risk, using GitHub Actions' built-in logical operators
  - This pattern is commonly used in GitHub workflows for handling multiple trigger scenarios
  - The `GITHUB_TOKEN` environment variable remains unchanged and continues to provide necessary permissions for changelog generation

  ## Potential Considerations

  - Ensure that any external systems triggering this workflow provide valid tag names in the `client_payload.tag` field
  - Monitor the first few releases after deployment to confirm both trigger methods work as expected
  - Consider adding validation to ensure the tag format is consistent regardless of the source

commits:
  [{"SHA":"a23b6d518f8f79b0ac4a916e6c424b602f74c8c6","Message":"fix: update release workflow to support manual dispatch with custom tag\n\n## CHANGES\n\n- Support custom tag from client payload in workflow\n- Fallback to github.ref_name when no custom tag provided\n- Enable manual release triggers with specified tag parameter","Author":"Kayvan Sylvan","Email":"","Date":"2025-08-31T16:03:22Z","Parents":null},{"SHA":"9b261b9adf2869277ae9c61e1f171569f6858479","Message":"chore: incoming 1741 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-08-31T16:08:59Z","Parents":null}]


title: Documentation and Pattern Updates
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1742
merged_at: 2025-09-01 03:18:13+00:00
created_at: 2025-09-11 18:18:34
body:
  # Documentation and Pattern Updates

  ## Summary

  This PR includes significant documentation improvements for installation methods and several pattern updates. The primary changes focus on enhancing the README with better Windows installation instructions and Docker support, while also cleaning up and improving pattern functionality.

  ## Related Issues

  Closes https://github.com/danielmiessler/Fabric/issues/1050

  Also, the `suggest_pattern` pattern has been updated with all the latest information.

  ## Files Changed

  ### README.md
  - **Enhanced installation documentation**: Added comprehensive Docker installation instructions and improved Windows installation guidance
  - **Restructured installation sections**: Better organized installation methods with clearer hierarchy
  - **Added new package manager support**: Documented Winget installation for Windows users

  ### data/patterns/show_fabric_options_markmap/system.md
  - **File deleted**: Removed the entire pattern file (481 lines removed)

  ### data/patterns/suggest_pattern/system.md
  - **Pattern categorization updates**: Updated pattern lists and categorizations to reflect current available patterns
  - **Enhanced pattern recommendations**: Improved the mapping between user requests and appropriate patterns

  ### data/patterns/suggest_pattern/user.md
  - **Added new pattern documentation**: Documented `create_story_about_person` and `heal_person` patterns for personal development use cases

  ## Code Changes

  ### README.md Installation Updates
  ```markdown
  #### Windows

  Via PowerShell, just copy and paste and run the following snippet to install the binary into `{HOME}\.local\bin`. Please make sure that directory is included in your `PATH`.

  # Added Winget installation method:
  #### Windows

  Use the official Microsoft supported `Winget` tool:

  `winget install danielmiessler.Fabric`
  ```

  ### Docker Section Addition
  ```markdown
  ### Docker

  Run Fabric using pre-built Docker images:

  ```bash
  # Use latest image from Docker Hub
  docker run --rm -it kayvan/fabric:latest --version
  ```

  **Images available at:**
  - Docker Hub: [kayvan/fabric](https://hub.docker.com/repository/docker/kayvan/fabric/general)  
  - GHCR: [ksylvan/fabric](https://github.com/ksylvan/fabric/pkgs/container/fabric)
  ```

  ### Pattern Updates
  The `suggest_pattern` system and user files were updated with new pattern categorizations, including additions to DEVELOPMENT, SELF, and PERSONAL DEVELOPMENT categories.

  ## Reason for Changes

  1. **Improved user experience**: The Windows installation section was streamlined and modernized with Winget support
  2. **Docker support documentation**: Added comprehensive Docker usage instructions to support containerized deployments
  3. **Pattern cleanup**: Removed obsolete `show_fabric_options_markmap` pattern that was no longer needed
  4. **Better pattern discovery**: Updated pattern suggestion system with more accurate categorizations and new personal development patterns

  ## Impact of Changes

  - **Positive impact**: Users will have clearer installation instructions and better access to Docker-based deployment options
  - **Documentation maintenance**: Removal of obsolete patterns reduces maintenance burden
  - **Enhanced discoverability**: Updated pattern suggestions will help users find appropriate patterns more easily

  ## Test Plan

  - Verify Windows Winget installation works as documented
  - Test Docker commands with both Docker Hub and GHCR images  
  - Confirm pattern suggestions work correctly with updated categorizations
  - Validate that removal of `show_fabric_options_markmap` doesn't break existing functionality

  ## Additional Notes

  **Potential Issues to Monitor:**
  1. The removal of `show_fabric_options_markmap` pattern could break existing workflows that depend on it - should verify no active usage
  2. Docker image availability should be confirmed at the documented registry locations
  3. Windows Winget package availability should be verified before users attempt installation

  The Docker section provides comprehensive examples but relies on external image repositories that should be maintained consistently. Consider adding fallback instructions if primary images become unavailable.

commits:
  [{"SHA":"f8ff9129b561009d3acded3f7ef467b3d288a11e","Message":"docs: add Windows install via winget and Docker deployment instructions\n\n- Add winget installation method for Windows\n- Add Docker Hub and GHCR image references\n- Include docker run examples for setup/patterns\n- Remove deprecated PowerShell download link\n- Delete unused show_fabric_options_markmap pattern\n- Update suggest_pattern with new AI patterns\n- Add personal development patterns for storytelling","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-01T03:03:40Z","Parents":null}]


title: Fabric Installation Improvements and Automated Release Updates
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1745
merged_at: 2025-09-01 18:51:08+00:00
created_at: 2025-09-11 18:18:34
body:
  # Fabric Installation Improvements and Automated Release Updates

  ## Summary

  This PR introduces a streamlined one-line installer system for Fabric and enhances the automated release process to include documentation updates. The changes significantly improve the user experience by providing platform-specific installation scripts and ensure documentation stays synchronized with code changes.

  ## Files Changed

  ### `.github/workflows/update-version-and-create-tag.yml`
  - **Added**: `"**/*.md"` to the workflow trigger paths
  - **Purpose**: Ensures that markdown documentation changes trigger version updates and releases

  ### `.vscode/settings.json`
  - **Added**: New spell check words (`useb`, `USERPROFILE`) and installer script paths to ignore list
  - **Purpose**: Prevents false positives in spell checking for installation-related terminology

  ### `README.md`
  - **Restructured**: Installation section with new one-line install commands
  - **Removed**: Individual platform-specific binary download instructions
  - **Added**: Consolidated installation approach with Unix/Linux/macOS bash script and Windows PowerShell script
  - **Simplified**: Manual binary downloads section with reference to GitHub releases page

  ### `data/patterns/pattern_explanations.md`
  - **Removed**: Entry for `show_fabric_options_markmap` pattern
  - **Updated**: All subsequent pattern numbers decremented by 1
  - **Impact**: Total pattern count reduced from 221 to 220

  ### `scripts/installer/` (New Directory)
  - **Added**: `README.md` - Comprehensive installer documentation
  - **Added**: `install.sh` - Unix/Linux/macOS installation script
  - **Added**: `install.ps1` - Windows PowerShell installation script

  ## Code Changes

  ### Installation Scripts (`scripts/installer/install.sh` and `install.ps1`)

  **Key Features:**
  ```bash
  # Unix/Linux/macOS one-liner
  curl -fsSL https://raw.githubusercontent.com/danielmiessler/fabric/main/scripts/installer/install.sh | bash

  # Windows PowerShell one-liner  
  iwr -useb https://raw.githubusercontent.com/danielmiessler/fabric/main/scripts/installer/install.ps1 | iex
  ```

  **Functionality:**
  - Automatic OS and architecture detection
  - Downloads latest release from GitHub API
  - Extracts only the `fabric` binary (not full archive)
  - Installs to `~/.local/bin` by default with custom directory support
  - Provides PATH setup guidance
  - Includes installation verification

  ## Reason for Changes

  1. **User Experience**: The previous installation process required users to manually download platform-specific binaries and set up their environment. The new one-line installers eliminate friction and provide a consistent experience across platforms.

  2. **Documentation Maintenance**: Adding markdown files to the release trigger ensures that documentation updates are properly versioned and distributed.

  3. **Pattern Cleanup**: Removal of the `show_fabric_options_markmap` pattern suggests it was deprecated or consolidated.

  4. **Developer Experience**: Enhanced VS Code settings prevent spell-check noise during development.

  ## Impact of Changes

  **Positive Impacts:**
  - Dramatically simplified installation process for end users
  - Cross-platform support with native scripts (bash for Unix, PowerShell for Windows)
  - Automatic latest version installation without manual version checking
  - Comprehensive error handling and user guidance
  - Better documentation maintenance workflow

  **Potential Risks:**
  - **Security consideration**: Users executing remote scripts via curl/iwr pipe to shell
  - **Network dependency**: Installation requires internet access to GitHub

  ## Test Plan

  The installation scripts should be tested on:
  - macOS (Intel and Apple Silicon) ✅
  - Linux distributions (Ubuntu, CentOS, Alpine) ✅
  - Windows 10/11 with PowerShell 5.1 and PowerShell Core ✅

  Verification should include:
  - Binary downloads correctly for each platform
  - Installation to default and custom directories
  - PATH detection and guidance accuracy  
  - Error handling for network failures and permission issues

  ## Additional Notes

  The installer scripts include comprehensive error handling and user guidance, but users in restricted environments may need to use the manual binary download approach. The scripts follow security best practices by verifying downloads and providing clear feedback throughout the installation process.

  ## Schreenshots

  On Windows:

  <img width="1178" height="665" alt="image" src="https://github.com/user-attachments/assets/f592cd69-3b8f-4a66-a4eb-c1c0a2de09c6" />

  On MacOS:

  <img width="1523" height="483" alt="image" src="https://github.com/user-attachments/assets/aaf6533a-5a52-4b00-88cc-3bd4e89b3863" />

commits:
  [{"SHA":"fad176a0a8dcc60ffefc957eafd084fab871594a","Message":"docs: streamline install process with one-line installer scripts and update documentation\n\n- Add markdown file triggers to GitHub workflow\n- Update VSCode settings with new spell entries\n- Simplify README installation with one-line installers\n- Add bash installer script for Unix systems\n- Add PowerShell installer script for Windows\n- Create installer documentation with usage examples\n- Remove redundant pattern from pattern explanations","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-01T18:12:42Z","Parents":null}]


title: Add i18n Support for Multi-Language Fabric Experience
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1755
merged_at: 2025-09-08 16:22:33+00:00
created_at: 2025-09-11 18:18:34
body:
  # Add i18n Support for Multi-Language Fabric Experience

  ## Summary

  This PR introduces internationalization (i18n) support to Fabric, allowing the application to display messages in multiple languages based on user locale settings. The implementation includes Spanish translation support, comprehensive locale detection following POSIX standards, and documentation improvements. Additionally, the PR removes an unused pattern and fixes a broken image URL.

  ## Related Issues

  Closes #1370
  Closes #1751

  ## Files Changed

  ### Core i18n Implementation
  - **internal/i18n/i18n.go**: Main i18n initialization system that loads translations from embedded files, user config, or downloads from GitHub
  - **internal/i18n/locale.go**: Locale detection logic following POSIX environment variable precedence (LC_ALL > LC_MESSAGES > LANG)
  - **internal/i18n/locale_test.go**: Comprehensive test suite for locale detection
  - **internal/i18n/i18n_test.go**: Tests for translation functionality
  - **internal/i18n/locales/en.json**: English translation file
  - **internal/i18n/locales/es.json**: Spanish translation file

  ### Integration Changes
  - **internal/cli/cli.go**: Integrated i18n initialization and used translation for HTML readability error message
  - **go.mod/go.sum**: Added dependency on `github.com/nicksnyder/go-i18n/v2` for i18n support

  ### Documentation
  - **docs/i18n.md**: Comprehensive guide for i18n system usage and configuration
  - **docs/contexts-and-sessions-tutorial.md**: New tutorial explaining contexts and sessions functionality
  - **docs/CONTRIBUTING.md**: Updated contribution guidelines with GitHub CLI usage

  ### Cleanup and Fixes
  - **README.md**: Fixed broken Warp sponsorship image URL
  - **data/patterns/solve_with_cot/**: Removed entire pattern directory
  - **Various pattern files**: Updated to remove references to solve_with_cot pattern
  - **.github/workflows/update-version-and-create-tag.yml**: Added .vscode to ignore paths
  - **.vscode/settings.json**: Added Spanish words to spell checker and file ignore patterns

  ## Code Changes

  ### i18n Initialization
  ```go
  // internal/cli/cli.go
  if _, err = i18n.Init(currentFlags.Language); err != nil {
      return
  }
  ```

  ### Translation Usage
  ```go
  // Before
  fmt.Println("use original input, because can't apply html readability", cleanErr)

  // After
  fmt.Println(i18n.T("html_readability_error"), cleanErr)
  ```

  ### Locale Detection Priority
  ```go
  // internal/i18n/locale.go
  envVars := []string{"LC_ALL", "LC_MESSAGES", "LANG"}
  for _, envVar := range envVars {
      if value := os.Getenv(envVar); value != "" {
          locale := normalizeLocale(value)
          if locale != "" && isValidLocale(locale) {
              return locale
          }
      }
  }
  ```

  ## Reason for Changes

  1. **Internationalization Support**: Enable Fabric to support multiple languages, making it accessible to a global user base
  2. **Documentation Improvements**: Added comprehensive tutorials for contexts/sessions feature and updated contribution guidelines
  3. **Code Cleanup**: Removed the unused `solve_with_cot` pattern which was no longer needed
  4. **Bug Fix**: Fixed broken Warp sponsorship image URL that was pointing to an invalid location

  ## Impact of Changes

  - **User Experience**: Non-English speaking users can now use Fabric in their preferred language (currently Spanish, with framework for adding more)
  - **Developer Experience**: Clear documentation on how to add new translations and use the i18n system
  - **Maintainability**: Robust locale detection system with comprehensive test coverage
  - **Performance**: Minimal impact - translations are embedded in binary or cached locally after first download

  ## Test Plan

  The changes include comprehensive test coverage:
  - Unit tests for locale detection with various environment variable combinations
  - Tests for locale normalization (e.g., `en_US.UTF-8` → `en-US`)
  - Integration tests for i18n initialization and translation
  - Manual testing with different locale settings:
    ```bash
    LC_ALL=es_ES.UTF-8 fabric --pattern summary
    fabric --language es --pattern summary
    ```

  ## Additional Notes

  ### Potential Issues to Watch
  1. **Translation Downloads**: If GitHub is unreachable, the system gracefully falls back to embedded translations
  2. **Locale Detection**: The system handles edge cases like `C` and `POSIX` locales by falling back to English
  3. **Missing Translations**: Any missing translation keys will fall back to English automatically

  ### Future Enhancements
  - Additional language support can be added by creating new JSON files in `internal/i18n/locales/`
  - The framework supports dynamic translation downloads, reducing binary size for languages not commonly used
  - The system is designed to be extensible for future UI components or web interfaces

commits:
  [{"SHA":"20080fcb7885a656a28fe62c325dede21a9feb57","Message":"feat: add i18n support with Spanish localization and documentation improvements\n\n- Add internationalization system with Spanish support\n- Create contexts and sessions tutorial documentation\n- Fix broken Warp sponsorship image URL\n- Add locale detection from environment variables\n- Update VSCode settings with new dictionary words\n- Exclude VSCode settings from version workflows\n- Update pattern descriptions and explanations\n- Add comprehensive i18n test coverage","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-05T20:14:51Z","Parents":null}]


title: Add Internationalization Support with Custom Help System
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1756
merged_at: 2025-09-09 20:54:51+00:00
created_at: 2025-09-11 18:18:34
body:
  # Add Internationalization Support with Custom Help System

  ## Summary

  This PR introduces comprehensive internationalization (i18n) support to Fabric, enabling the application to display messages in multiple languages. The implementation includes a custom help system with language detection, localized error messages throughout the codebase, and initial support for English and Spanish locales.

  ## Files Changed

  ### Core i18n Implementation
  - **internal/i18n/i18n.go**: Added the main internationalization system with automatic language detection, locale file loading (embedded and downloadable), and translation functions.
  - **internal/i18n/locales/en.json**: Added comprehensive English translations for all user-facing messages (136 translation keys).
  - **internal/i18n/locales/es.json**: Added complete Spanish translations matching all English keys.

  ### CLI and Help System
  - **internal/cli/help.go**: New file implementing a custom translated help system that replaces the default go-flags help output with i18n-aware descriptions.
  - **internal/cli/flags.go**: Modified flag parsing to integrate with the custom help system and localized error messages.

  ### Application-wide String Replacements
  - **internal/cli/chat.go**: Replaced hardcoded strings with i18n.T() calls for TTS messages, notifications, and error handling.
  - **internal/cli/initialization.go**: Localized initialization error messages.
  - **internal/cli/listing.go**: Translated listing headers.
  - **internal/cli/output.go**: Localized file operation error messages.
  - **internal/cli/tools.go**: Translated tool-related error messages.
  - **internal/cli/transcribe.go**: Localized transcription error messages.

  ### Other Updates
  - **internal/core/plugin_registry.go**: Translated vendor listing header.
  - **internal/plugins/ai/models.go**: Localized model listing headers.
  - **internal/plugins/db/fsdb/storage.go**: Translated "No items found" message.
  - **README.md**: Added entry for v1.4.309 release documenting i18n support.
  - **cmd/generate_changelog/incoming/1756.txt**: Added changelog entry for this PR.

  ## Code Changes

  ### Key Implementation Details

  1. **Language Detection Strategy**:
  ```go
  // Detects language from CLI args first, then environment variables
  func detectLanguageFromArgs() string {
      // Looks for --language/-g flag
  }
  func detectLanguageFromEnv() string {
      // Checks LC_ALL, LC_MESSAGES, LANG
  }
  ```

  2. **Custom Help System**:
  ```go
  // Replaces go-flags default help with translated descriptions
  type TranslatedHelpWriter struct {
      parser *flags.Parser
      writer io.Writer
  }
  ```

  3. **Translation Function Usage**:
  ```go
  // Before
  err = fmt.Errorf("vendor %s not configured", vendorName)
  // After
  err = fmt.Errorf("%s", fmt.Sprintf(i18n.T("vendor_not_configured"), vendorName))
  ```

  ## Reason for Changes

  This change addresses the need for Fabric to support international users by:
  1. Making the application accessible to non-English speakers
  2. Providing a framework for adding additional language support in the future
  3. Improving user experience by displaying messages in the user's preferred language
  4. Maintaining consistency in error messages and help text across different languages

  ## Impact of Changes

  ### Positive Impacts
  - **User Experience**: Non-English speakers can now use Fabric with messages in their native language
  - **Extensibility**: Easy to add new languages by creating new locale JSON files
  - **Consistency**: All user-facing strings are now centralized in locale files
  - **Automatic Detection**: Language is automatically detected from system settings or CLI arguments

  ### Behavioral Changes
  - Help output now uses a custom system instead of go-flags default
  - Error messages are wrapped with an additional fmt.Sprintf for i18n support
  - Locale files can be downloaded dynamically if not embedded

  ### Performance Considerations
  - Minimal overhead from translation lookups (uses in-memory map after loading)
  - Embedded locale files ensure no runtime dependencies for core languages
  - Optional network request for downloading new locale files

  ## Test Plan

  Testing should cover:
  1. **Language Detection**: Verify language is correctly detected from `--language` flag and environment variables
  2. **Help System**: Ensure `--help` displays translated descriptions for all flags
  3. **Error Messages**: Confirm error messages appear in the selected language
  4. **Fallback Behavior**: Test that system falls back to English when translations are missing
  5. **Spanish Translation**: Validate Spanish translations with `--language es`
  6. **Notification System**: Test that notification titles and messages are translated

  ## Additional Notes

  - The PR maintains backward compatibility - English remains the default language
  - Translation keys use snake_case for consistency
  - Error handling during i18n initialization provides graceful fallbacks
  - The system supports both embedded and downloadable locale files for flexibility
  - Future languages can be added by creating new JSON files in the locales directory

commits:
  [{"SHA":"651c5743f1e45b847dbea30a2b9d5d7c99ccde47","Message":"feat: add comprehensive internationalization support with English and Spanish locales\n\n- Replace hardcoded strings with i18n.T translations\n- Add en and es JSON locale files\n- Implement custom translated help system\n- Enable language detection from CLI args\n- Add locale download capability\n- Localize error messages throughout codebase\n- Support TTS and notification translations","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-09T00:09:43Z","Parents":null}]


title: Add Windows-style Flag Support for Language Detection
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1759
merged_at: 2025-09-11 18:04:27+00:00
created_at: 2025-09-11 18:18:34
body:
  # Add Windows-style Flag Support for Language Detection

  ## Summary
  This PR extends the language detection functionality to support Windows-style command-line flags (using forward slash `/`) in addition to the existing Unix-style flags (using dashes `-` and `--`). Additionally, it adds comprehensive unit tests for the `extractFlag` function to ensure proper flag parsing behavior.

  ## Files Changed

  - **internal/cli/flags_test.go**: Added new test suite for the `extractFlag` function to validate flag parsing behavior across different flag formats.
  - **internal/cli/help.go**: Modified the `detectLanguageFromArgs` function to recognize Windows-style flags for language selection.

  ## Code Changes

  ### internal/cli/flags_test.go
  Added a comprehensive test suite for `extractFlag`:
  ```go
  func TestExtractFlag(t *testing.T) {
      // Tests for Unix-style flags (--help, -h, --pattern=value, -p=test)
      // Tests for edge cases (single dash, double dash only)
      // Tests for non-flag arguments (regular args, paths)
  }
  ```
  The test suite covers:
  - Long flags with and without values
  - Short flags with and without values
  - Edge cases like standalone `-` and `--`
  - Non-flag arguments that should return empty strings

  ### internal/cli/help.go
  Enhanced `detectLanguageFromArgs` to support Windows conventions:
  ```go
  if arg == "--language" || arg == "-g" || (runtime.GOOS == "windows" && arg == "/g") {
      // Handle flag without value
  } else if runtime.GOOS == "windows" && strings.HasPrefix(arg, "/g:") {
      // Handle Windows-style /g:value
  } else if runtime.GOOS == "windows" && strings.HasPrefix(arg, "/g=") {
      // Handle Windows-style /g=value
  }
  ```

  ## Reason for Changes
  Windows users traditionally expect to use forward slash (`/`) as a flag prefix in command-line applications. By adding support for Windows-style flags (`/g`, `/g:value`, `/g=value`), the application becomes more intuitive and follows platform conventions, improving the user experience for Windows users while maintaining backward compatibility with Unix-style flags.

  ## Impact of Changes
  1. **Cross-platform consistency**: Windows users can now use familiar flag syntax for language selection
  2. **No breaking changes**: Existing Unix-style flags continue to work as before
  3. **Better test coverage**: The new test suite for `extractFlag` improves code reliability and makes future refactoring safer
  4. **Runtime detection**: The changes only apply on Windows systems through `runtime.GOOS` checks, ensuring no impact on Unix/Linux/macOS systems

  ## Test Plan
  1. **Unit Tests**: Added comprehensive test coverage for the `extractFlag` function covering all flag formats and edge cases
  2. **Manual Testing Required**:
     - On Windows: Test `/g:en`, `/g=en`, and `/g en` formats
     - On Unix/Linux/macOS: Verify existing `-g` and `--language` flags still work
     - Cross-platform: Ensure language detection works correctly with various flag combinations

  ## Additional Notes
  - The implementation uses `runtime.GOOS` to conditionally enable Windows-style flags only on Windows systems, preventing any confusion on Unix-like systems where `/` typically denotes paths
  - The test suite for `extractFlag` uses a table-driven approach for better maintainability and readability
  - Both colon (`:`) and equals (`=`) separators are supported for Windows-style flags to match common Windows CLI conventions

commits:
  [{"SHA":"78280810f470ccd7d9e3c075cf67f92dda63612e","Message":"feat: add Windows-style forward slash flag support to CLI argument parser\n\n- Add runtime OS detection for Windows platform\n- Support `/flag` syntax for Windows command line\n- Handle Windows colon delimiter `/flag:value` format\n- Maintain backward compatibility with Unix-style flags\n- Add comprehensive test coverage for flag extraction\n- Support both `:` and `=` delimiters on Windows\n- Preserve existing dash-based flag parsing logic","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-10T03:16:40Z","Parents":null},{"SHA":"d89d932be1fd5cd955ef0ebfbe95a89eea6b157b","Message":"chore: incoming 1759 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-09-10T13:56:57Z","Parents":null},{"SHA":"a8f071b1c480fd4df14bcc02642b4069b02c086a","Message":"Merge branch 'main' into kayvan/fix/0909-windows-flag-fix","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-11T03:02:44Z","Parents":null},{"SHA":"8daba467b1280e7b009563e8160f1144656c09ae","Message":"Merge branch 'main' into kayvan/fix/0909-windows-flag-fix","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-11T17:50:11Z","Parents":null},{"SHA":"59695428e3a6a2393a0c18f61241a6afad46262f","Message":"feat: update Vite and Rollup dependencies to latest versions\n\n### CHANGES\n\n- Update Vite to version 5.4.20\n- Update Rollup to version 4.50.1\n- Add `@eslint-community/eslint-utils` version 4.9.0\n- Update `@humanfs/node` to version 0.16.7\n- Update `@humanwhocodes/retry` to version 0.4.3\n- Update Rollup platform-specific packages to 4.50.1\n- Add `@rollup/rollup-openharmony-arm64` version 4.50.1\n- Closes Dependabot PR https://github.com/danielmiessler/Fabric/pull/1763","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-11T17:54:55Z","Parents":null}]


title: New pattern for writing interaction between two characters
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1762
merged_at: 2025-09-11 02:56:32+00:00
created_at: 2025-09-11 18:18:34
body:
  # New pattern for writing interaction between two characters

  ## What this Pull Request (PR) does

  Added a new pattern that takes two psychological profiles and/or data and creates a story simulating most likely interaction between them. 

  ## Related issues

  #1760 originally created by @OmriH-Elister

commits:
  [{"SHA":"5073aac99ba98a43ba6dfaf47c5bd1f20f49b6bb","Message":"feat: add new pattern that creates story simulating interaction between two people","Author":"OmriH-Elister","Email":"","Date":"2025-09-10T14:37:15Z","Parents":null},{"SHA":"8416500f817f0f02d3286c9d4dd1dab41756da21","Message":"Merge branch 'danielmiessler:main' into stick","Author":"Omri Herman","Email":"","Date":"2025-09-10T14:51:44Z","Parents":null},{"SHA":"97e2a76566bacd88639c571016e34a113d17fdaf","Message":"Merge pull request #1 from OmriH-Elister/stick\n\nStick","Author":"Omri Herman","Email":"","Date":"2025-09-10T14:54:18Z","Parents":null},{"SHA":"3017b1a5b2cfbee3c00ff40628fdd40210d4f072","Message":"chore: add `create_story_about_people_interaction` pattern for persona analysis\n\n### CHANGES\n\n- Add `create_story_about_people_interaction` pattern description\n- Include pattern in `ANALYSIS` and `WRITING` categories\n- Update `suggest_pattern` system and user documentation\n- Modify JSON files to incorporate new pattern details","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-10T23:59:44Z","Parents":null},{"SHA":"617c31d15abb0d3c53479a70ca8356f85c0f684b","Message":"chore: incoming 1762 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-09-11T00:09:53Z","Parents":null},{"SHA":"65268e5f6294e374d636e10dc3d8879c9eebcb24","Message":"fix: Change attribution of PR to https://github.com/OmriH-Elister","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-11T02:51:53Z","Parents":null}]


title: feat(i18n): add de, fr, ja, pt, zh, fa locales; expand tests
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1767
merged_at: 2025-09-13 15:31:50+00:00
created_at: 2025-09-16 14:06:15
body:
  # feat(i18n): add de, fr, ja, pt, zh, fa locales; expand tests

  ## Summary

  This PR significantly expands the internationalization (i18n) capabilities of the application by adding support for 7 new languages (German, Persian/Farsi, French, Italian, Japanese, Portuguese, and Chinese) and improves the ChangeLog generation process with better formatting for aggregated PR sections.

  - **de** - German
  - **fa** - Persian (Farsi)
  - **fr** - French  
  - **it** - Italian
  - **pt** - Portuguese
  - **ja** - Japanese
  - **zh** - Chinese

  ## Related Issues

  Closes #1766 
  Closes #1758 


  ## Files Changed

  ### Configuration Files
  - **`.vscode/settings.json`**: Added new locale files to the JSON schema associations for proper IDE support and validation of translation files.

  ### Documentation
  - **`README.md`**: Updated release notes to document the new v1.4.311 release featuring expanded internationalization support for the 7 new languages.

  ### Changelog Generation
  - **`cmd/generate_changelog/incoming/1767.txt`**: Added changelog entry documenting this PR's contributions.
  - **`cmd/generate_changelog/internal/changelog/processing.go`**: Improved formatting by adding blank lines between aggregated PR sections for better readability in generated changelogs.

  ### Internationalization
  - **`internal/i18n/i18n_test.go`**: Expanded test coverage with table-driven tests to verify translations across all supported languages.
  - **`internal/i18n/locales/*.json`**: Added complete translation files for German (de), Persian/Farsi (fa), French (fr), Italian (it), Japanese (ja), Portuguese (pt), and Chinese (zh).

  ## Code Changes

  ### Changelog Processing Enhancement
  ```go
  // Add an extra newline between PR sections for proper spacing
  if i < len(files)-1 {
      content.WriteString("\n")
  }
  ```
  This change ensures proper visual separation between different PR entries when aggregating changelog content.

  ```go
  // Add spacing before direct commits section if we have PR content
  if content.Len() > 0 {
      content.WriteString("\n")
  }
  ```
  Improves formatting by adding appropriate spacing between PR content and direct commit sections.

  ### Comprehensive i18n Testing
  ```go
  testCases := []struct {
      lang     string
      expected string
  }{
      {"es", "usa la entrada original, porque no se puede aplicar la legibilidad de html"},
      {"en", "use original input, because can't apply html readability"},
      {"zh", "使用原始输入，因为无法应用 HTML 可读性处理"},
      // ... additional test cases for all languages
  }
  ```
  Replaced single-language test with comprehensive table-driven tests covering all 9 supported languages, ensuring translation integrity across the entire i18n system.

  ## Reason for Changes

  1. **Enhanced Internationalization**: The application previously only supported English and Spanish. Adding 7 additional languages significantly expands the potential user base and improves accessibility for non-English speakers globally.

  2. **Improved Changelog Readability**: The previous changelog generation created dense, hard-to-read output when aggregating multiple PR files. Adding proper spacing between sections improves the readability of generated changelogs.

  3. **Better Test Coverage**: The original i18n tests only covered Spanish translations. The expanded test suite now validates translations across all supported languages, ensuring quality and preventing regression.

  ## Impact of Changes

  - **User Experience**: Non-English speaking users can now interact with the application in their native language, improving usability and reducing barriers to adoption.
  - **Maintainability**: The comprehensive test suite ensures that all translations are properly loaded and functioning, making it easier to maintain translation quality as the application evolves.
  - **Documentation Quality**: Better formatted changelogs make it easier for users and contributors to understand what changes have been made in each release.
  - **No Breaking Changes**: All changes are additive or improve existing functionality without breaking backward compatibility.

  ## Test Plan

  1. **Unit Tests**: Extended the existing i18n test suite to verify:
     - All locale files load successfully
     - Translation keys are properly resolved for each language
     - The `html_readability_error` message (used as a test case) returns the correct translation for each language

  2. **Manual Testing Recommendations**:
     - Verify language switching works correctly in the application
     - Test that all UI elements display properly in languages with different character sets (Chinese, Japanese, Persian)
     - Verify changelog generation produces properly formatted output with the new spacing

  ## Additional Notes

  - All translation files follow the same JSON structure ensuring consistency across languages
  - The Persian (fa) locale adds right-to-left (RTL) language support, which may require additional UI considerations in the future
  - Translation quality was ensured by using native language conventions and terminology appropriate for technical contexts
  - The VS Code settings update ensures developers get proper JSON validation when editing the new locale files

commits:
  [{"SHA":"c4e6cb370ff05bbba0265ae8a4eacefc4d723821","Message":"feat(i18n): add de/fr/ja/pt/zh/fa locales; expand tests, improve changelog spacing\n\nCHANGES\n- Add DE, FR, JA, PT, ZH, FA i18n locale files.\n- Expand i18n tests with table-driven multilingual coverage.\n- Verify 'html_readability_error' translations across all supported languages.\n- Update README with release notes for added languages.\n- Watch new locale and test files in VSCode.\n- Insert blank lines between aggregated PR changelog sections.\n- Append direct commits section only when content exists.","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-13T14:43:04Z","Parents":null}]


title: Go 1.25.1 Upgrade & Critical SDK Updates
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1769
merged_at: 2025-09-14 17:51:35+00:00
created_at: 2025-09-16 14:06:15
body:
  # Go 1.25.1 Upgrade & Critical SDK Updates

  ## Summary

  This PR upgrades the project to Go 1.25.1 and updates critical AI/ML service SDKs including Anthropic Claude, AWS Bedrock, and Azure authentication components. The changes improve performance, add new AI capabilities, and ensure compatibility with the latest service APIs.

  ## Files Changed

  ### Build Configuration
  - **`.vscode/settings.json`**: Added Go 1.25-specific terms to the spell checker dictionary (GODEBUG, GOEXPERIMENT, GOMAXPROCS, goroutines, greenteagc, synctest)
  - **`flake.nix`**: Changed from `go_1_24` to `go_latest` to resolve Nix package version lag issues
  - **`scripts/docker/Dockerfile`**: Updated base image from `golang:1.24-alpine` to `golang:1.25-alpine`

  ### Dependencies
  - **`go.mod`**: Updated Go version from 1.24.0 to 1.25.1, removed explicit toolchain directive, and upgraded 9 critical packages
  - **`go.sum`**: Updated checksums for all modified dependencies

  ### Documentation
  - **`docs/Go-Updates-September-2025.md`**: Added comprehensive documentation of the upgrade process, including feature details, risk assessment, and rollback procedures

  ## Code Changes

  ### Go Version Upgrade
  ```go
  // go.mod
  - go 1.24.0
  - toolchain go1.24.2
  + go 1.25.1
  ```

  ### Critical Package Updates
  ```go
  // AI/ML SDKs
  - github.com/anthropics/anthropic-sdk-go v1.9.1
  + github.com/anthropics/anthropic-sdk-go v1.12.0  // +3 versions

  - github.com/aws/aws-sdk-go-v2/service/bedrock v1.34.1
  + github.com/aws/aws-sdk-go-v2/service/bedrock v1.46.1  // +12 versions

  - github.com/aws/aws-sdk-go-v2/service/bedrockruntime v1.30.0
  + github.com/aws/aws-sdk-go-v2/service/bedrockruntime v1.40.1  // +10 versions
  ```

  ## Reason for Changes

  1. **Go 1.25.1 Benefits**:
     - Container-aware GOMAXPROCS for better resource utilization in containerized environments
     - Experimental Green Tea GC offering 10-40% reduction in garbage collection overhead
     - Enhanced testing capabilities with `testing/synctest` for deterministic concurrent testing
     - Improved compiler optimizations and DWARF5 debug information

  2. **SDK Updates**:
     - **Anthropic**: Adds web_fetch_20250910 tool support, document handling in tool results, and code execution capabilities
     - **AWS Bedrock**: Introduces automated reasoning checks for guardrails, custom model deployment APIs, and enhanced evaluation features
     - **Azure**: Improves token refresh handling and fixes resource identifier parsing issues

  3. **Security & Compatibility**: Ensures compatibility with latest AI service APIs and includes security improvements in TLS/crypto implementations

  ## Impact of Changes

  ### Performance Improvements
  - Expected 10-40% reduction in GC overhead when Green Tea GC is enabled
  - Faster slice allocation and improved stack allocation from compiler optimizations
  - Automatic CPU limit detection in containerized environments

  ### Enhanced Capabilities
  - New AI tool support including web fetching and code execution
  - Improved document handling in AI interactions
  - Better error handling and token management in cloud SDKs

  ### Breaking Changes
  - macOS now requires version 12 Monterey or later (previously 11 Big Sur)
  - Stricter TLS implementations may affect connections to non-compliant servers

  ## Test Plan

  All existing test suites have been executed successfully:
  ```bash
  go test ./...  # All tests pass
  go mod verify  # Dependencies verified
  go build       # Build successful
  ```

  Integration testing confirmed:
  - AI service connections functional
  - No deprecated API warnings
  - No functionality regressions detected

  ## Additional Notes

  ### Potential Issues to Monitor
  1. **Large Version Jumps**: AWS Bedrock SDK jumped 12 versions and Bedrock Runtime jumped 10 versions. While backward compatibility is maintained, monitor for any unexpected behavior.

  2. **Container Environments**: The automatic GOMAXPROCS adjustment in Go 1.25 may change CPU utilization patterns in containerized deployments.

  3. **TLS/Crypto Changes**: Enhanced security implementations may require updates to legacy system connections.

  ### Rollback Plan
  If issues arise, the changes can be reverted using:
  ```bash
  git checkout go.mod go.sum
  go mod download
  # Update Docker and Nix configurations accordingly
  ```

  ### Documentation
  Comprehensive upgrade documentation has been added in `docs/Go-Updates-September-2025.md` including:
  - Detailed feature explanations
  - Migration guides
  - Risk assessment
  - Success metrics
  - Useful reference links

  This upgrade positions the project to leverage the latest Go language features and ensures continued compatibility with evolving AI service APIs.

commits:
  [{"SHA":"9a37d63d76564eabfa63f530b4dd170d0b3e6ab8","Message":"chore: Go 1.25 upgrade and critical package updates for AI/ML services\n\n- Upgrade Go from 1.24 to 1.25.1\n- Update Anthropic SDK for web fetch tools\n- Upgrade AWS Bedrock SDK 12 versions\n- Update Azure Core and Identity SDKs\n- Fix Nix config for Go version lag\n- Update Docker base to golang:1.25-alpine\n- Add comprehensive upgrade documentation","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-14T17:16:03Z","Parents":null},{"SHA":"ed87954133a5f1a3d78424b5a86f5b8cf4d44fe1","Message":"chore: prevent Go toolchain auto-download by setting GOTOOLCHAIN=local environment variable\n\n## CHANGES\n\n- Add GOTOOLCHAIN=local to shell environment\n- Configure preBuild hook in fabric package\n- Wrap goimports with local toolchain setting\n- Wrap gofmt with local toolchain setting\n- Update treefmt module import structure\n- Add pkgs parameter to treefmt config\n- Create shell script wrappers for Go tools","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-14T17:45:51Z","Parents":null}]


title: Use Garble to get around false positive Microsoft Defender virus detection
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1770
merged_at: 2025-09-15 00:06:27+00:00
created_at: 2025-09-16 14:06:15
body:
  # Use Garble to get around false positive Microsoft Defender virus detection

  ## Summary

  This PR integrates `garble` into the build pipeline to obfuscate the compiled Go binaries during release. Garble is a Go code obfuscation tool that makes reverse engineering more difficult by scrambling literals and reducing binary size.

  ## Files Changed

  - **`.github/workflows/release.yml`**: Added a step to install the `garble` tool before running GoReleaser in the CI/CD pipeline.
  - **`.goreleaser.yaml`**: Modified the build configuration to use `garble` as the Go compiler with obfuscation flags enabled.
  - **`.vscode/settings.json`**: Added new words to the VS Code spell checker dictionary related to the garble integration.

  ## Code Changes

  ### `.github/workflows/release.yml`
  ```yaml
  + - name: Install garble
  +   run: go install mvdan.cc/garble@latest
  ```
  Added installation of garble tool using `go install` to fetch the latest version from the official repository.

  ### `.goreleaser.yaml`
  ```yaml
  + gobinary: garble
  + # From https://github.com/eyevanovich/garble-goreleaser-example/blob/main/.goreleaser.yaml
  + # command is a single string.
  + # garble's 'build' needs the -literals and -tiny args before it, so we
  + # trick goreleaser into using -literals as command, and pass -tiny and
  + # build as flags.
  + command: "-literals"
  + flags: [ "-tiny", "-seed=random", "build" ]
  ```
  Configured GoReleaser to use `garble` instead of the standard Go compiler. The configuration uses a workaround to properly pass garble's flags:
  - `-literals`: Obfuscates string literals in the code
  - `-tiny`: Further reduces binary size by removing additional debug information
  - `-seed=random`: Ensures different obfuscation patterns across builds

  ### `.vscode/settings.json`
  ```json
  + "gobinary",
  + "mvdan",
  ```
  Added dictionary entries for spell checking support in VS Code.

  ## Reason for Changes

  The implementation of garble obfuscation serves to:
  1. **Protect intellectual property**: Makes it significantly harder to reverse engineer the compiled binaries
  2. **Reduce binary size**: The `-tiny` flag strips additional debug information, resulting in smaller release artifacts
  3. **Enhance security**: Obfuscated string literals make it harder to extract sensitive information or understand the program's logic through static analysis

  ## Impact of Changes

  - **Binary size**: Release binaries will be smaller due to the `-tiny` flag
  - **Performance**: Minimal runtime impact; obfuscation primarily affects binary structure, not execution speed
  - **Debugging**: Production binaries will be harder to debug, but this only affects release builds, not development builds
  - **Build time**: Slightly increased build time during releases due to the obfuscation process
  - **Reproducibility**: Each build will have different obfuscation patterns due to `-seed=random`, which enhances security but means binaries won't be byte-for-byte reproducible

  ## Test Plan

  1. Verify the GitHub Actions workflow successfully installs garble
  2. Confirm GoReleaser builds complete without errors
  3. Test that the resulting binaries function correctly on all target platforms (Linux, macOS, Windows)
  4. Validate that binary sizes are reduced compared to non-obfuscated builds
  5. Attempt basic reverse engineering tools on the binary to confirm obfuscation is effective

  ## Additional Notes

  - This is an attempt o implement the fix in [this Reddit thread](https://www.reddit.com/r/golang/comments/s1bh01/goexecutables_and_windows_defender/?share_id=TziSPnMDbktxAkl1fPxtz&utm_content=1&utm_medium=ios_app&utm_name=ioscss&utm_source=share&utm_term=1) about a way to get around the frequent false positive hits from Microwoft Defender on Windows that is holding up the Winget releases.
  - The configuration follows a documented workaround pattern from the garble-goreleaser example repository
  - This change only affects release builds; local development builds will continue to use the standard Go compiler
  - Future consideration: Monitor garble updates for potential breaking changes or new obfuscation features

commits:
  [{"SHA":"f9b2c650aaf152f38a2ae4ad16c659d800eaa953","Message":"feat: add garble obfuscation to build process for enhanced binary protection\n\n- Add garble installation to release workflow\n- Configure goreleaser to use garble gobinary\n- Set garble build flags for literals obfuscation\n- Enable tiny mode for reduced binary size\n- Add random seed for build reproducibility\n- Update VSCode dictionary with garble terms","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-14T23:20:44Z","Parents":null}]


title: Integrate garble to avoid false positive virus detection on Windows
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1771
merged_at: 2025-09-15 02:25:51+00:00
created_at: 2025-09-16 14:06:15
body:
  # Integrate garble to avoid false positive virus detection on Windows

  ## Summary

  This PR introduces code obfuscation to the Fabric binary build process using `garble`, a Go obfuscation tool. This change enhances the security of the distributed binaries by making reverse engineering more difficult.

  > NOTE: This is an attempt o implement the fix in [this Reddit thread](https://www.reddit.com/r/golang/comments/s1bh01/goexecutables_and_windows_defender/?share_id=TziSPnMDbktxAkl1fPxtz&utm_content=1&utm_medium=ios_app&utm_name=ioscss&utm_source=share&utm_term=1) about a way to get around the frequent false positive hits from Microwoft Defender on Windows that is holding up the Winget releases.


  ## Files Changed

  - **.github/workflows/release.yml**: Added a step to install the `garble` tool during the release workflow
  - **.goreleaser.yaml**: Configured GoReleaser to use `garble` for building binaries with obfuscation flags
  - **.vscode/settings.json**: Added new words to the spell checker dictionary

  ## Code Changes

  ### .github/workflows/release.yml
  ```yaml
  + - name: Install garble
  +   run: go install mvdan.cc/garble@latest
  ```
  Added a new workflow step that installs the latest version of `garble` before the GoReleaser action runs.

  ### .goreleaser.yaml
  ```yaml
  + tool: garble
  + command: "-literals"
  + flags: [ "-tiny", "-seed=random", "build" ]
  ```
  Configured the build process to use `garble` with:
  - `-literals`: Obfuscates string literals in the code
  - `-tiny`: Reduces binary size by removing debug information
  - `-seed=random`: Uses random seed for obfuscation, ensuring each build is uniquely obfuscated

  ### .vscode/settings.json
  Added `gobinary` and `mvdan` to the spell checker allow list to prevent false positive warnings in the IDE.

  ## Reason for Changes

  The primary motivation for these changes is to improve the security posture of the Fabric binary distributions. By obfuscating the compiled binaries:
  1. Sensitive string literals (API endpoints, error messages, etc.) are hidden from casual inspection
  2. The binary becomes significantly harder to reverse engineer
  3. Protection against static analysis tools that might extract sensitive information

  ## Impact of Changes

  - **Security**: Distributed binaries will be obfuscated, making it harder for malicious actors to understand the internal workings or extract sensitive information
  - **Build Time**: The build process will take slightly longer due to the additional obfuscation step
  - **Binary Size**: The `-tiny` flag should help reduce binary size despite the obfuscation overhead
  - **Debugging**: Production binaries will be harder to debug, but this trade-off is acceptable for release builds

  ## Test Plan

  1. Verify the GitHub Actions workflow successfully installs `garble`
  2. Confirm GoReleaser builds complete without errors
  3. Test that the obfuscated binaries function correctly on all target platforms (Linux, macOS, Windows)
  4. Validate that the binaries are indeed obfuscated by attempting basic static analysis

  ## Additional Notes

  - The `garble` configuration uses a clever workaround to pass the required flags in the correct order, as documented in the inline comment
  - Using `seed=random` ensures that each release build has different obfuscation patterns, further enhancing security
  - This change only affects release builds; local development builds remain unobfuscated for easier debugging

commits:
  [{"SHA":"ad175f7a8c003073d16f93ec0ca20cd6639e7c76","Message":"build: integrate garble to avoid false positive virus detection on Windows\n\n- Install garble in GitHub Actions release pipeline before GoReleaser.\n- Configure GoReleaser to use garble as build tool.\n- Set garble command to '-literals' with flags configured.\n- Pass -tiny, -seed=random, build flags to garble invocation.\n- Enable obfuscation of string literals and smaller binaries.\n- Add 'mvdan' to VSCode spellchecker dictionary.","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-15T01:11:06Z","Parents":null}]


title: Add Garble Obfuscation for Windows Builds
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1773
merged_at: 2025-09-16 23:23:11+00:00
created_at: 2025-09-20 15:24:07
body:
  # Add Garble Obfuscation for Windows Builds

  ## Summary

  This PR introduces build obfuscation for Windows executables using the `garble` tool to protect the source code from reverse engineering. The change only affects Windows builds while keeping Darwin and Linux builds unchanged.

  > NOTE: This is an attempt o implement the fix in [this Reddit thread](https://www.reddit.com/r/golang/comments/s1bh01/goexecutables_and_windows_defender/?share_id=TziSPnMDbktxAkl1fPxtz&utm_content=1&utm_medium=ios_app&utm_name=ioscss&utm_source=share&utm_term=1) about a way to get around the frequent false positive hits from Microwoft Defender on Windows that is holding up the Winget releases.


  ## Files Changed

  - **.github/workflows/release.yml**: Added a step to install the `garble` tool in the release workflow
  - **.goreleaser.yaml**: Split the build configuration to use standard builds for Darwin/Linux and garbled builds for Windows
  - **.vscode/settings.json**: Added "mvdan" to the spell checker dictionary
  - **CHANGELOG.md**: Minor formatting fix for consistency (single to double quotes)
  - **cmd/generate_changelog/changelog.db**: Binary database file updated (likely from running the changelog generator)
  - **cmd/generate_changelog/internal/git/walker.go**: Fixed logic for determining unreleased vs released commits based on the latest tag

  ## Code Changes

  ### Build Configuration Changes

  The most significant change is splitting the build process into two separate configurations:

  ```yaml
  builds:
    - id: default
      env:
        - CGO_ENABLED=0
      goos:
        - darwin
        - linux
      main: ./cmd/fabric
      binary: fabric
    - id: windows-garbled
      env:
        - CGO_ENABLED=0
      goos:
        - windows
      main: ./cmd/fabric
      binary: fabric
      tool: garble
      command: "-literals"
      flags: [ "-tiny", "-seed=random", "build" ]
      ldflags: [ "-s", "-w" ]
  ```

  The Windows build now uses `garble` with:
  - `-literals`: Obfuscates string literals
  - `-tiny`: Reduces binary size
  - `-seed=random`: Ensures different obfuscation on each build
  - `-s -w` ldflags: Strips debug symbols

  ### Changelog Walker Logic Fix

  ```go
  // Get the latest tag to know the boundary between released and unreleased
  latestTag, _ := w.GetLatestTag()
  var latestTagHash plumbing.Hash
  if latestTag != "" {
      if tagRef, err := w.repo.Tag(latestTag); err == nil {
          latestTagHash = tagRef.Hash()
      }
  }
  ```

  The changelog generator now correctly identifies unreleased commits by tracking whether we've passed the latest tag boundary while walking the commit history.

  ## Reason for Changes

  1. **Security Enhancement**: Obfuscating Windows binaries makes it significantly harder to reverse engineer the application, protecting intellectual property and preventing potential security vulnerabilities from being easily discovered
  2. **Bug Fix**: The changelog generator was incorrectly categorizing commits, potentially marking released commits as unreleased or vice versa

  ## Impact of Changes

  - **Windows Users**: Will receive obfuscated binaries that are harder to reverse engineer but functionally identical
  - **Build Time**: Windows builds will take slightly longer due to the obfuscation process
  - **Binary Size**: Windows binaries may be slightly different in size due to the `-tiny` flag optimization
  - **Changelog Generation**: More accurate categorization of commits in the changelog, properly distinguishing between released and unreleased changes

  ## Test Plan

  1. Verify the release workflow successfully installs `garble` and completes the build process
  2. Test that Windows binaries function correctly after obfuscation
  3. Confirm Darwin and Linux builds remain unchanged
  4. Run the changelog generator and verify commits are properly categorized as released/unreleased

  ## Additional Notes

  - The garble configuration follows best practices from the garble-goreleaser example repository
  - The clever workaround using `-literals` as the command and passing other flags separately is necessary due to how goreleaser handles custom build tools

commits:
  [{"SHA":"e69858105aa5785716b883e3d4623f386d4f592a","Message":"feat: add garble obfuscation for Windows builds and fix changelog generation\n\n- Add garble tool installation to release workflow\n- Configure garble obfuscation for Windows builds only\n- Fix changelog walker to handle unreleased commits\n- Update changelog database with latest changes\n- Add mvdan to VSCode dictionary settings\n- Implement boundary detection for released vs unreleased\n- Keep newer commits as \"Unreleased\" until tagged","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-16T23:12:01Z","Parents":null}]


title: Migrate Azure client to openai-go/azure and default API version
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1774
merged_at: 2025-09-18 22:55:07+00:00
created_at: 2025-09-20 15:24:07
body:
  # Migrate Azure client to openai-go/azure and default API version

  ## Summary

  This PR updates Azure OpenAI client configuration to use the new Azure-specific SDK authentication method.

  ## Related Issues

  Closes #1743 

  ## Files Changed

  - **go.mod & go.sum**: Added Azure SDK dependencies required for proper Azure OpenAI authentication
  - **internal/plugins/ai/azure/azure.go**: Refactored Azure OpenAI client configuration to use the official Azure authentication method
  - **internal/plugins/ai/azure/azure_test.go**: Added test coverage for default API version behavior
  - **cmd/generate_changelog/internal/git/walker.go**: Simplified version tracking logic by removing the concept of "latest tag boundary" that was previously used to differentiate between released and unreleased commits (reverts bug introduced with last change of this utility).

  ## Code Changes

  ### walker.go
  Removed the complex logic that attempted to track the latest tag and determine whether commits should be marked as "Unreleased" or assigned to their version:

  ```go
  // Removed:
  - latestTag, _ := w.GetLatestTag()
  - var latestTagHash plumbing.Hash
  - passedLatestTag := false
  - if !passedLatestTag && latestTagHash != (plumbing.Hash{}) && c.Hash == latestTagHash {
  -     passedLatestTag = true
  - }
  ```

  Now directly assigns commits to their parsed version:
  ```go
  currentVersion = commit.Version  // Simplified assignment
  ```

  ### azure.go
  Migrated from generic OpenAI options to Azure-specific authentication:

  ```go
  // Before:
  opts := []option.RequestOption{option.WithAPIKey(oi.ApiKey.Value)}

  // After:
  client := openaiapi.NewClient(
      azure.WithAPIKey(apiKey),
      azure.WithEndpoint(baseURL, apiVersion),
  )
  ```

  Added input validation and default API version handling:
  ```go
  const defaultAPIVersion = "2024-05-01-preview"
  ```

  ## Reason for Changes

  1. **Changelog Generation**: The previous logic for tracking the latest tag boundary was overly complex and potentially buggy. It attempted to keep newer commits as "Unreleased" until passing a tag boundary, but this could lead to incorrect version assignment in certain git histories.

  2. **Azure Authentication**: The Azure OpenAI service requires specific authentication patterns that differ from the standard OpenAI API. Using the Azure-specific SDK methods ensures proper authentication and API versioning.

  ## Impact of Changes

  1. **Simplified Logic**: The changelog generator now has more predictable behavior - commits are directly assigned to their detected version without complex boundary tracking.

  2. **Improved Compatibility**: The Azure client will now properly authenticate with Azure OpenAI endpoints using the correct SDK methods.

  3. **Better Error Handling**: Added validation for required Azure configuration parameters (API key and base URL).

  ## Test Plan

  - Unit tests have been added to verify the default API version behavior
  - Existing tests updated to use the new API version constant
  - Manual testing should verify:
    - Changelog generation correctly assigns commits to versions
    - Azure OpenAI client successfully authenticates and makes API calls

  ## Additional Notes

  ### Potential Considerations

  1. **Breaking Change**: The removal of the latest tag boundary logic may change how unreleased commits are categorized in the changelog. Projects relying on the previous behavior may see different changelog output.

  2. **Azure SDK Dependencies**: Added Azure SDK dependencies increase the module size. These are necessary for proper Azure authentication but add ~2 additional dependencies.

  3. **API Version**: The default API version is now hardcoded to `2024-05-01-preview`. This should be monitored for deprecation and updated as Azure releases new API versions.

commits:
  [{"SHA":"3a42fa7ece42ab3645c7e717a8ee8581d8144861","Message":"feat: migrate Azure client to openai-go/azure and default API version\n\nCHANGES\n- switch Azure OpenAI config to openai-go azure helpers\n- require API key and base URL during configuration\n- default API version to 2024-05-01-preview when unspecified\n- trim and parse deployments input into clean slice\n- update dependencies to support azure client and authentication flow\n- add tests for configuration and default API version behavior\n- remove latest-tag boundary logic from changelog walker (revert to the v1.4.213 version)\n- simplify version assignment by matching commit messages directly","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-17T23:55:13Z","Parents":null}]


title: Remove garble from the build process for Windows
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1776
merged_at: 2025-09-20 15:21:33+00:00
created_at: 2025-09-20 15:24:07
body:
  # Remove garble from the build process for Windows

  ## Summary

  This PR updates the CI/CD pipeline and build configuration for the Fabric project. The main changes include adding the changelog database to git tracking during the release process and simplifying the Windows build configuration by removing the Garble obfuscation tool in favor of standard build flags with version information injection.

  The original idea of adding `garble` was to make it pass virus scanning during version upgrades for Winget, and this was a failed experiment. 

  ## Files Changed

  - **`.github/workflows/update-version-and-create-tag.yml`**: Added a step to track the changelog database file in git after generation
  - **`.goreleaser.yaml`**: Refactored the Windows build configuration and added comprehensive version information to all builds

  ## Code Changes

  ### `.github/workflows/update-version-and-create-tag.yml`
  ```yaml
  @@ -95,6 +95,7 @@ jobs:
           run: |
             go run ./cmd/generate_changelog --process-prs ${{ steps.increment_version.outputs.new_tag }}
             go run ./cmd/generate_changelog --sync-db
  +          git add ./cmd/generate_changelog/changelog.db
  ```
  Added `git add` command to stage the changelog database file after it's synchronized, ensuring it's included in the version bump commit.

  ### `.goreleaser.yaml`
  ```yaml
  - id: windows-garbled
  + id: windows-build
  ```
  Renamed the Windows build configuration from `windows-garbled` to `windows-build` for clarity.

  ```yaml
  - tool: garble
  - command: "-tiny"
  - flags: [ "-seed=random", "build" ]
  - ldflags: [ "-s", "-w" ]
  + ldflags:
  +   - -s -w
  +   - -X main.version={{.Version}}
  +   - -X main.commit={{.ShortCommit}}
  +   - -X main.date={{.Date}}
  +   - -X main.builtBy=goreleaser
  +   - -X main.tag={{.Tag}}
  ```
  Removed Garble obfuscation tool configuration and replaced it with standard ldflags that inject version metadata into the binary at build time. These same ldflags were also added to the default build configuration.

  ## Reason for Changes

  1. **Changelog Database Tracking**: The changelog database needs to be committed to the repository to maintain a persistent record of changelog data across releases
  2. **Build Simplification**: Removing Garble reduces build complexity and potential compatibility issues while maintaining binary optimization through standard `-s -w` flags
  3. **Version Information**: Adding version metadata injection allows the application to report its version, commit hash, build date, and tag information at runtime, improving debugging and support capabilities

  ## Impact of Changes

  - **Positive Impact**: 
    - Changelog generation will now persist properly across releases
    - Binaries will contain embedded version information for better traceability
    - Build process is simplified and more maintainable
    - Both Linux and Windows builds now use consistent configuration patterns

  - **Potential Considerations**:
    - Windows binaries will no longer be obfuscated, which may slightly increase reverse-engineering risk if that was a concern
    - Binary sizes might be slightly different without Garble's tiny mode optimization

  ## Test Plan

  1. Verify the GitHub Actions workflow successfully commits the changelog database during version bumps
  2. Build binaries for all platforms and confirm version information is correctly embedded
  3. Test that the application can report its version information at runtime
  4. Validate that Windows builds complete successfully without Garble

  ## Additional Notes

  The removal of Garble suggests a shift towards prioritizing build reliability and maintainability over code obfuscation. The addition of comprehensive version metadata will significantly improve the ability to track and debug issues in production deployments.

commits:
  [{"SHA":"13178456e52c915ce4f1cfa7cd01c2b63518016e","Message":"chore: update CI workflow and simplify goreleaser build configuration\n\n## CHANGES\n\n- Add changelog database to git tracking\n- Remove unnecessary goreleaser comments\n- Add version metadata to default build\n- Rename windows build from garbled to standard\n- Remove garble obfuscation from windows build\n- Standardize ldflags across all build targets\n- Inject version info during compilation","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-20T15:16:32Z","Parents":null}]


title: chore: remove garble installation from release workflow
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1777
merged_at: 2025-09-20 15:46:31+00:00
created_at: 2025-09-20 15:48:55
body:
  # chore: remove garble installation from release workflow

  ## Summary

  This PR updates the CI/CD pipeline and build configuration for the Fabric project. The main changes include adding the changelog database to git tracking during the release process and simplifying the Windows build configuration by removing the Garble obfuscation tool in favor of standard build flags with version information injection.

  The original idea of adding `garble` was to make it pass virus scanning during version upgrades for Winget, and this was a failed experiment. 

  ## Files Changed

  - **`.github/workflows/update-version-and-create-tag.yml`**: Added a step to track the changelog database file in git after generation
  - **`.goreleaser.yaml`**: Refactored the Windows build configuration and added comprehensive version information to all builds

  ## Code Changes

  ### `.github/workflows/update-version-and-create-tag.yml`
  ```yaml
  @@ -95,6 +95,7 @@ jobs:
           run: |
             go run ./cmd/generate_changelog --process-prs ${{ steps.increment_version.outputs.new_tag }}
             go run ./cmd/generate_changelog --sync-db
  +          git add ./cmd/generate_changelog/changelog.db
  ```
  Added `git add` command to stage the changelog database file after it's synchronized, ensuring it's included in the version bump commit.

  ### `.goreleaser.yaml`
  ```yaml
  - id: windows-garbled
  + id: windows-build
  ```
  Renamed the Windows build configuration from `windows-garbled` to `windows-build` for clarity.

  ```yaml
  - tool: garble
  - command: "-tiny"
  - flags: [ "-seed=random", "build" ]
  - ldflags: [ "-s", "-w" ]
  + ldflags:
  +   - -s -w
  +   - -X main.version={{.Version}}
  +   - -X main.commit={{.ShortCommit}}
  +   - -X main.date={{.Date}}
  +   - -X main.builtBy=goreleaser
  +   - -X main.tag={{.Tag}}
  ```
  Removed Garble obfuscation tool configuration and replaced it with standard ldflags that inject version metadata into the binary at build time. These same ldflags were also added to the default build configuration.

  ## Reason for Changes

  1. **Changelog Database Tracking**: The changelog database needs to be committed to the repository to maintain a persistent record of changelog data across releases
  2. **Build Simplification**: Removing Garble reduces build complexity and potential compatibility issues while maintaining binary optimization through standard `-s -w` flags
  3. **Version Information**: Adding version metadata injection allows the application to report its version, commit hash, build date, and tag information at runtime, improving debugging and support capabilities

  ## Impact of Changes

  - **Positive Impact**: 
    - Changelog generation will now persist properly across releases
    - Binaries will contain embedded version information for better traceability
    - Build process is simplified and more maintainable
    - Both Linux and Windows builds now use consistent configuration patterns

  - **Potential Considerations**:
    - Windows binaries will no longer be obfuscated, which may slightly increase reverse-engineering risk if that was a concern
    - Binary sizes might be slightly different without Garble's tiny mode optimization

  ## Test Plan

  1. Verify the GitHub Actions workflow successfully commits the changelog database during version bumps
  2. Build binaries for all platforms and confirm version information is correctly embedded
  3. Test that the application can report its version information at runtime
  4. Validate that Windows builds complete successfully without Garble

  ## Additional Notes

  The removal of Garble suggests a shift towards prioritizing build reliability and maintainability over code obfuscation. The addition of comprehensive version metadata will significantly improve the ability to track and debug issues in production deployments.

commits:
  [{"SHA":"a2f2d0e2d9d3af8baf54ce3e7194e9420cc2337c","Message":"chore: remove garble installation from release workflow\n\n- Remove garble installation step from release workflow\n- Add comment for GoReleaser config file reference link\n- The original idea of adding garble was to make it pass virus\n  scanning during version upgrades for Winget, and this\n  was a failed experiment.","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-20T15:38:08Z","Parents":null}]


title: Add Portuguese Language Variants Support (pt-BR and pt-PT)
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1778
merged_at: 2025-09-21 23:07:45+00:00
created_at: 2025-09-21 23:10:10
body:
  # Add Portuguese Language Variants Support (pt-BR and pt-PT)

  ## Summary

  This PR introduces support for Portuguese language variants in Fabric's internationalization system, providing distinct translations for Brazilian Portuguese (pt-BR) and European Portuguese (pt-PT). The implementation includes a robust variant handling system that can be extended to support other language variants in the future.

  ## Files Changed

  ### Core Implementation Files
  - **`internal/i18n/i18n.go`**: Enhanced the i18n initialization system to support language variants with proper fallback chains and default variant mapping
  - **`internal/i18n/locale.go`**: Updated locale normalization to ensure proper BCP 47 format (language-REGION)
  - **`internal/i18n/locales/pt.json` → `internal/i18n/locales/pt-BR.json`**: Renamed to establish Brazilian Portuguese as the explicit variant
  - **`internal/i18n/locales/pt-PT.json`**: Added new European Portuguese translation file with region-specific terminology

  ### Test Files
  - **`internal/i18n/i18n_variants_test.go`**: Comprehensive test suite for variant functionality including normalization, fallback behavior, and backward compatibility

  ### Documentation
  - **`docs/i18n-variants.md`**: Detailed documentation on the variant system architecture, implementation guidelines, and recommendations for future variants
  - **`.vscode/settings.json`**: Added spelling exceptions for British English terms

  ### Translation Updates
  - **All locale files** (`de.json`, `en.json`, `es.json`, `fa.json`, `fr.json`, `it.json`, `ja.json`, `zh.json`): Updated help text to include Portuguese variant examples

  ## Code Changes

  ### Variant System Implementation
  ```go
  // defaultLanguageVariants maps base languages to their default regional variants
  var defaultLanguageVariants = map[string]string{
      "pt": "pt-BR", // Portuguese defaults to Brazilian Portuguese for backward compatibility
  }
  ```

  ### BCP 47 Normalization
  ```go
  func normalizeToBCP47(locale string) string {
      // Converts pt_BR to pt-BR, ensures proper casing (language-REGION)
      locale = strings.ReplaceAll(locale, "_", "-")
      parts := strings.Split(locale, "-")
      if len(parts) >= 2 {
          parts[0] = strings.ToLower(parts[0])
          parts[1] = strings.ToUpper(parts[1])
      }
      return strings.Join(parts[:2], "-")
  }
  ```

  ### Fallback Chain Logic
  ```go
  func getLocaleCandidates(locale string) []string {
      // For pt-PT returns: ["pt-PT", "pt", "pt-BR"]
      // Implements intelligent fallback from regional → base → default variant
  }
  ```

  ## Reason for Changes

  1. **User Requirement**: Portuguese-speaking users from different regions need localized terminology that matches their regional conventions
  2. **Linguistic Accuracy**: Brazilian and European Portuguese have significant vocabulary differences, particularly in technical terms:
     - "arquivo" (BR) vs "ficheiro" (PT) for "file"
     - "salvar" (BR) vs "guardar" (PT) for "save"
     - "deletar" (BR) vs "eliminar" (PT) for "delete"
  3. **Scalability**: The implementation provides a framework for adding other language variants (Chinese, Spanish, English) in the future

  ## Impact of Changes

  ### Positive Impacts
  - **Improved User Experience**: Portuguese speakers from both Brazil and Portugal now have region-appropriate translations
  - **Backward Compatibility**: Existing configurations using "pt" continue to work, defaulting to Brazilian Portuguese
  - **Extensible Architecture**: The variant system can easily accommodate future language variants without major refactoring
  - **Input Flexibility**: Accepts both underscore (pt_BR) and hyphen (pt-BR) formats, matching various system locale conventions

  ### Potential Considerations
  - **Minimal Performance Impact**: The fallback chain adds negligible overhead (typically 1-2 additional file checks)
  - **Maintenance Overhead**: Future translation updates need to consider both Portuguese variants
  - **Memory Usage**: Each variant loads its own translation file, but the impact is minimal (~10KB per locale file)

  ## Test Plan

  The implementation includes comprehensive testing:

  1. **Unit Tests** (`i18n_variants_test.go`):
     - BCP 47 normalization validation
     - Fallback chain verification
     - Variant loading and distinction tests
     - Backward compatibility assurance

  2. **Manual Testing Commands**:
  ```bash
  # Test Brazilian Portuguese
  fabric --help -g=pt-BR
  fabric --help -g=pt_BR  # underscore format

  # Test European Portuguese  
  fabric --help -g=pt-PT
  fabric --help -g=pt_PT  # underscore format

  # Test backward compatibility
  fabric --help -g=pt     # Should default to pt-BR

  # Test environment variable
  LANG=pt_PT.UTF-8 fabric --help
  ```

  3. **Regression Testing**:
     - All existing language codes continue to function
     - No breaking changes to the API or CLI interface

  ## Additional Notes

  ### Future Recommendations
  The documentation includes recommendations for high-priority language variants:
  - Chinese: zh-CN, zh-TW, zh-HK
  - Spanish: es-ES, es-MX, es-AR
  - English: en-US, en-GB, en-AU
  - French: fr-FR, fr-CA
  - Arabic: ar-SA, ar-EG

  ### Translation Consistency
  Key differences between pt-BR and pt-PT have been carefully reviewed:
  - File terminology: "arquivo" → "ficheiro"
  - User terminology: "usuário" → "utilizador"
  - Action verbs: "deletar" → "eliminar", "salvar" → "guardar"

  ### Potential Edge Cases
  1. **Mixed Locale Formats**: The system handles both `pt_BR` and `pt-BR` formats through normalization
  2. **Missing Variants**: If a specific variant doesn't exist, the system gracefully falls back through the chain
  3. **Invalid Locales**: Malformed locale codes are normalized or fall back to English

  The implementation is production-ready and has been thoroughly tested to ensure reliability and backward compatibility.

commits:
  [{"SHA":"b34112d7ed71683dddc770d7e8030e644fe9c9e2","Message":"feat(i18n): add i18n support for language variants (pt-BR/pt-PT)\n\n• Add Brazilian Portuguese (pt-BR) translation file\n• Add European Portuguese (pt-PT) translation file\n• Implement BCP 47 locale normalization system\n• Create fallback chain for language variants\n• Add default variant mapping for Portuguese\n• Update help text to show variant examples\n• Add comprehensive test suite for variants\n• Create documentation for i18n variant architecture","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-21T22:54:36Z","Parents":null}]


title: Improve pt-BR Translation - Thanks to @JuracyAmerico
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1779
merged_at: 2025-09-24 14:54:52+00:00
created_at: 2025-09-24 14:57:28
body:
  # Improve pt-BR Translation - Thanks to @JuracyAmerico

  ## Summary

  Normalize i18n locale files and refine Brazilian Portuguese translations. This PR:

  - Adds missing trailing newlines to several locale JSON files to comply with formatting conventions and avoid noisy diffs.
  - Improves Brazilian Portuguese (pt-BR) strings for clarity, consistency, and correctness, while preserving placeholders and key structure.
  - The changes to the translation are from @JuracyAmerico in response to [this discussion](https://github.com/danielmiessler/Fabric/discussions/1761#discussioncomment-14489932).

  ## Files Changed

  - internal/i18n/locales/de.json
  - internal/i18n/locales/fa.json
  - internal/i18n/locales/fr.json
  - internal/i18n/locales/it.json
  - internal/i18n/locales/ja.json
  - internal/i18n/locales/zh.json
    - Change: Add trailing newline at EOF. No content changes.
    - Why: Enforce consistent file formatting, eliminate “No newline at end of file” warnings, and reduce needless churn in diffs.

  - internal/i18n/locales/pt-BR.json
    - Change: Multiple string refinements for grammar/terminology consistency in pt-BR.
    - Why: Improve UX and comprehension for Brazilian Portuguese users, align with terminology used elsewhere in the app.

  ## Code Changes

  Notable pt-BR updates (keys unchanged):

  - More precise selection phrasing and prepositions:
    ```
    - "choose_pattern_from_available": "Escolha um padrão dos padrões disponíveis",
    + "choose_pattern_from_available": "Escolha um padrão entre os padrões disponíveis",
    ```

  - Clarified variable description:
    ```
    - "pattern_variables_help": "Valores para variáveis de padrão, ex. -v=#role:expert -v=#points:30",
    + "pattern_variables_help": "Valores para variáveis do padrão, ex. -v=#role:expert -v=#points:30",
    ```

  - Improved help copy for attachments:
    ```
    - "attachment_path_or_url_help": "Caminho do anexo ou URL (ex. para mensagens de reconhecimento de imagem do OpenAI)",
    + "attachment_path_or_url_help": "Caminho para o anexo ou URL (ex. para mensagens de reconhecimento de imagem do OpenAI)",
    ```

  - Clarified wording around model defaults and roles:
    ```
    - "use_model_defaults_raw_help": "Usar os padrões do modelo sem enviar opções de chat (como temperatura, etc.) e usar o papel de usuário em vez do papel de sistema para padrões.",
    + "use_model_defaults_raw_help": "Usar as configurações padrão do modelo sem enviar opções de chat (como temperatura, etc.) e usar o papel de usuário em vez do papel de sistema para padrões.",
    ```

  - Terminology consistency and clarity for listings:
    ```
    - "list_all_patterns": "Listar todos os padrões",
    + "list_all_patterns": "Listar todos os padrões/patterns",
    ```

  - Clipboard phrasing consistency:
    ```
    - "copy_to_clipboard": "Copiar para área de transferência",
    + "copy_to_clipboard": "Copiar para a área de transferência",
    ```

  - Output intent clarified:
    ```
    - "output_to_file": "Saída para arquivo",
    + "output_to_file": "Exportar para arquivo",
    ```

  - YouTube URL phrasing refined:
    ```
    - "youtube_url_help": "Vídeo do YouTube ou \"URL\" de playlist para obter transcrição, comentários e enviar ao chat ou imprimir no console e armazenar no arquivo de saída",
    + "youtube_url_help": "Vídeo do YouTube ou URL da playlist para obter transcrição, comentários e enviar ao chat ou imprimir no console e armazenar no arquivo de saída",
    ```

  - Minor grammatical and article insertions across several strings:
    ```
    - "run_setup_for_reconfigurable_parts": "Executar configuração para todas as partes reconfiguráveis do fabric",
    + "run_setup_for_reconfigurable_parts": "Executar a configuração para todas as partes reconfiguráveis do fabric",
    ```

  All placeholders (e.g., %s, %v) remain intact and in the same order.

  ## Reason for Changes

  - Formatting: Ensures all locale files have a trailing newline, aligning with POSIX and common tooling expectations, preventing editor/CI warnings and unnecessary diffs.
  - Localization quality: Improves Brazilian Portuguese translations for clarity, grammatical correctness, and more natural phrasing, reducing ambiguity for end users and aligning with application terminology.

  ## Impact of Changes

  - User-facing strings in pt-BR are clearer and more consistent, improving the CLI/help UX for Brazilian Portuguese users.
  - No functional code changes; only text modifications.
  - Minimal risk:
    - Keys are unchanged, maintaining compatibility with lookups.
    - Placeholders are preserved, reducing runtime formatting risks.

  Potential minor side effects:
  - Slightly longer strings (e.g., “padrões/patterns”) could affect line wrapping in narrow terminals. Visual check recommended.

  ## Test Plan

  - Validate JSON integrity:
    - Run a JSON linter (e.g., jq) over all modified locale files.
  - i18n key consistency:
    - Run any existing i18n key parity checks to ensure all locales retain the same keys.
  - Placeholders:
    - Grep for %s/%v in pt-BR.json and confirm counts match the reference (e.g., en or source).
  - CLI smoke test:
    - Set locale to pt-BR and exercise commands that display updated strings (choose pattern/context/session, YouTube transcript option, output to file, copy to clipboard).
  - Formatting:
    - Verify no “No newline at end of file” notices remain in the modified files.

  ## Additional Notes

  - The usage of “padrões/patterns” is intentional to disambiguate product terminology that may be known by its English name. If this is undesired stylistically, we can revert to purely localized terms.
  - If documentation screenshots or guides reference exact phrasing, they may require minor updates to reflect these refinements.

commits:
  [{"SHA":"47154406528c595cfb7d63e16ca895f28235016a","Message":"fix: improve PT-BR translation naturalness and fluency\n\n- Thanks to @JuracyAmerico for Brazilian Portugese native speaker expertise!\n- Replace \"dos\" with \"entre\" for better preposition usage\n- Add definite articles where natural in Portuguese\n- Clarify \"configurações padrão\" instead of just \"padrões\"\n- Keep technical terms visible like \"padrões/patterns\"\n- Remove unnecessary quotes around \"URL\"\n- Make phrasing more natural \"Exportar para arquivo\"","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-24T13:38:30Z","Parents":null}]


title: feat: add extract_characters pattern
author: marcas756
author_url: https://github.com/marcas756
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1780
merged_at: 2025-10-14 15:27:23+00:00
created_at: 2025-10-28 14:34:19
body:
  CHANGES
  - Define character extraction goals and steps
  - Specify canonical naming and deduplication rules
  - Outline interaction mapping and narrative importance
  - Provide output schema with formatting guidelines
  - Include positive/negative examples for clarity
  - Enforce no speculative motivations or non-actors
  - Set fallback for no characters found

  ## What this Pull Request (PR) does

  1. Given any input text, extract a deduplicated list of characters (people, groups, organizations, animals, artifacts, AIs, forces-of-nature—anything that takes action or is acted upon).
  2. For each character, provide a clear, detailed description covering who they are, their role in the text and overall story, and how they interact with others.

  ## Related issues

  -

  ## Screenshots

  Input : 

  pg1513.txt (Romeo&Juliet)

  Output :

  **Romeo **
  Romeo Montague is the young heir of the Montague family, the central protagonist of the play. He is a passionate, impulsive lover who falls deeply for Juliet Capulet, leading to a series of tragic events. Romeo interacts with nearly every major character: he quarrels with Tybalt, seeks guidance from Friar Lawrence, confides in his friends Benvolio and Mercutio, and ultimately marries Juliet in secret. His actions—killing Tybalt, fleeing Verona, and taking his own life—drive the plot toward its fatal conclusion.

  **Juliet **
  Juliet Capulet is the teenage daughter of the Capulet family and the play’s female lead. She secretly marries Romeo, defying her family’s feud. Juliet’s interactions include her clandestine meetings with Romeo, her conversations with her Nurse, and her final act of suicide after discovering Romeo’s death. Her decisions and love for Romeo propel the narrative toward tragedy.

  ...

commits:
  [{"SHA":"0f67998f30b41fed27a52094f2df3e21524eeeff","Message":"feat: add extract_characters system definition\n\nCHANGES\n- Define character extraction goals and steps\n- Specify canonical naming and deduplication rules\n- Outline interaction mapping and narrative importance\n- Provide output schema with formatting guidelines\n- Include positive/negative examples for clarity\n- Enforce no speculative motivations or non-actors\n- Set fallback for no characters found","Author":"Marco Bacchi","Email":"","Date":"2025-09-26T11:56:46Z","Parents":null},{"SHA":"cf04c60bf79bce07031bd947d8ea7d1b2d507de6","Message":"chore: incoming 1780 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-10-14T15:04:33Z","Parents":null},{"SHA":"faa7fa338704b5dd90e43d3bd773e6d01011eec9","Message":"chore: added `extract_characters` method for detailed character analysis\n\n### CHANGES\n\n- Add `extract_characters` to identify and describe characters\n- Update business category to include `extract_characters`\n- Include `extract_characters` in extract category\n- Add `extract_characters` description in pattern descriptions JSON\n- Update user documentation with `extract_characters` details","Author":"Kayvan Sylvan","Email":"","Date":"2025-10-14T15:26:08Z","Parents":null}]


title: Update anthropic-sdk-go and add claude-sonnet-4-5
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1783
merged_at: 2025-09-30 13:54:26+00:00
created_at: 2025-09-30 13:57:01
body:
  # Update anthropic-sdk-go and add claude-sonnet-4-5

  ## Summary

  This pull request updates the Anthropic SDK dependency from version 1.12.0 to 1.13.0 and adds support for the new Claude Sonnet 4.5 model in the Fabric project's Anthropic AI plugin.

  ## Related Issues

  Closes #1782 

  ## Files Changed

  ### `go.mod`
  - **Change**: Updated `github.com/anthropics/anthropic-sdk-go` dependency from `v1.12.0` to `v1.13.0`
  - **Purpose**: Upgrade to the latest version of the Anthropic SDK to access new models and potential bug fixes

  ### `go.sum`
  - **Change**: Added checksum entries for the new SDK version `v1.13.0`
  - **Purpose**: Maintain integrity verification for the updated dependency

  ### `internal/plugins/ai/anthropic/anthropic.go`
  - **Change**: Added support for the new Claude Sonnet 4.5 model
  - **Purpose**: Enable users to utilize the latest Claude Sonnet 4.5 model in the Fabric application

  ## Code Changes

  #### Anthropic Client Configuration (`internal/plugins/ai/anthropic/anthropic.go`)

  **Added model to supported models list:**
  ```go
  string(anthropic.ModelClaudeSonnet4_5),
  ```

  **Added beta configuration for the new model:**
  ```go
  string(anthropic.ModelClaudeSonnet4_5): {"context-1m-2025-08-07"},
  ```

  The new model is configured with the `context-1m-2025-08-07` beta flag, which likely enables the 1 million token context window feature, consistent with the Claude Sonnet 4 configuration.

  ## Reason for Changes

  1. **SDK Update**: The Anthropic SDK was updated to version 1.13.0 to gain access to the newly released Claude Sonnet 4.5 model and any accompanying improvements or fixes in the SDK.

  2. **Model Support**: Claude Sonnet 4.5 represents a new model offering from Anthropic, and adding support ensures that Fabric users can take advantage of the latest AI capabilities.

  3. **Beta Feature Access**: The model is configured with the extended context beta flag, allowing users to leverage the 1 million token context window capability.

  ## Impact of Changes

  **Positive Impacts:**
  - Users can now select and use the Claude Sonnet 4.5 model through Fabric
  - Access to improved performance and capabilities that come with the newer model
  - Extended context window support (1M tokens) for Claude Sonnet 4.5
  - Maintains consistency with the existing beta configuration pattern used for Claude Sonnet 4

  **Potential Considerations:**
  - The SDK upgrade is a minor version bump (1.12.0 → 1.13.0), which should maintain backward compatibility but may include behavior changes
  - Users will need to have API access to Claude Sonnet 4.5 through their Anthropic account
  - The beta flag requirement means this feature may still be evolving

  ## Test Plan

  1. Verify the application builds successfully with the updated dependency ✅
  2. Test basic functionality with existing Claude models to ensure no regressions ✅
  3. Test Claude Sonnet 4.5 model selection and API calls with a valid Anthropic API key ✅
  4. Verify the 1M context window beta flag is properly applied in API requests ✅
  5. Confirm error handling works correctly if users don't have access to the new model ✅

  ## Additional Notes

  - The change follows the existing pattern for adding new Claude models to the client
  - Both the model identifier and beta configuration are added consistently with the Claude Sonnet 4 implementation
  - No breaking changes are introduced; this is purely additive functionality
  - The SDK update appears to be the primary vehicle for accessing the new model enum `ModelClaudeSonnet4_5`
  - Users should ensure their Anthropic API keys have appropriate access to the new model before attempting to use it

commits:
  [{"SHA":"94e8d69daca4270b1571173c6c3331c265f6ebf7","Message":"feat: update `anthropic-sdk-go` to v1.13.0 and add new model\n\n- Upgrade `anthropic-sdk-go` to version 1.13.0\n- Add `ModelClaudeSonnet4_5` to supported models list","Author":"Kayvan Sylvan","Email":"","Date":"2025-09-30T13:35:37Z","Parents":null}]


title: Enhance web app docs
author: starfish456
author_url: https://github.com/starfish456
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1794
merged_at: 2025-10-14 15:01:19+00:00
created_at: 2025-10-28 14:34:19
body:
  ## What this Pull Request (PR) does

  Simplifies the web app documentation: 
  - Removes duplicate content from the main README
  - Fixes typos
  - Removes redundant information (e.g. npm-install.sh contents in the docs) from the web app README
  - Makes the main purpose of the web-app clear: aweb interface for Fabric, not a personal blog-site or a website template for your own projects.

  ## Related issues

  Not applicable

  ## Screenshots

  Not applicable

commits:
  [{"SHA":"b14daf43cc35caf903f4966def24db6baac8e0a9","Message":"docs: remove duplicate content from the main readme and link to the web app readme","Author":"KFS","Email":"","Date":"2025-10-13T03:44:04Z","Parents":null},{"SHA":"cab77728daea7ea353b072fc52f89dc423d9d063","Message":"docs: remove redundant content and simplify the web app readme","Author":"KFS","Email":"","Date":"2025-10-13T03:47:10Z","Parents":null},{"SHA":"2bd0d6292fdfa92a30567f7394b2f20746d6f415","Message":"docs: update table of contents with proper nesting and fix minor formatting issues\n\n## CHANGES\n\n- Add top-level project name to navigation hierarchy\n- Nest all sections under main project heading\n- Fix npm install script path extension\n- Update localhost URL to use HTML format\n- Add \"Mdsvex\" to VSCode spelling dictionary\n- Include \"details\" and \"summary\" to HTML tags\n- Remove trailing newline from web README","Author":"Kayvan Sylvan","Email":"","Date":"2025-10-14T14:16:38Z","Parents":null},{"SHA":"68d97ba4545913a79f44e0b5e3730a5cff60078a","Message":"chore: incoming 1794 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-10-14T14:50:49Z","Parents":null}]


title: fix: improve template extension handling for {{input}} and add examples
author: nickarino
author_url: https://github.com/nickarino
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1802
merged_at: 2025-11-12 01:21:13+00:00
created_at: 2025-11-12 01:24:07
body:
  This PR fixes template extension handling for {{input}} placeholders and adds comprehensive examples and tests.

commits:
  [{"SHA":"29c24c83879230470d6626e397ec203442fbd88f","Message":"fix: improve template extension handling for {{input}} and add examples","Author":"Nick Skriloff","Email":"","Date":"2025-10-20T23:49:33Z","Parents":null},{"SHA":"bc273db19d187a284424c854f90bb2a7b6e2ee3b","Message":"chore: incoming 1802 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-10-20T23:57:13Z","Parents":null},{"SHA":"f8f9f6ba65dc18cdecd8e14f1ff6043752ed3fc4","Message":"Update internal/plugins/template/Examples/openai.yaml\n\nCo-authored-by: Copilot \u003c175728472+Copilot@users.noreply.github.com\u003e","Author":"Nick Skriloff","Email":"","Date":"2025-10-21T00:42:52Z","Parents":null},{"SHA":"eb1cfe834032e473470c3d4332cb98f6fc153d55","Message":"Complete merge from upstream/main","Author":"Nick Skriloff","Email":"","Date":"2025-10-31T01:13:46Z","Parents":null},{"SHA":"4b825347087fa0c9efc7ff6f40aeb9496a1a4e3f","Message":"refactor: address PR review feedback\n\n- Extract InputSentinel constant to shared constants.go file\n- Remove duplicate inputSentinel definitions from template.go and patterns.go\n- Create withTestExtension helper function to reduce test code duplication\n- Refactor 3 test functions to use the helper (reduces ~40 lines per test)\n- Fix shell script to use $@ instead of $* for proper argument quoting\n\nAddresses review comments from @ksylvan and @Copilot AI","Author":"Nick Skriloff","Email":"","Date":"2025-10-31T17:27:38Z","Parents":null},{"SHA":"b8027582f4b9c641728b7084142b1d747ab6ee23","Message":"docs: clarify extensions only work within patterns, not stdin\n\n- Add prominent warning at top of Extensions guide with visual indicators\n- Update main README with brief Extensions section and link to full guide\n- Remove misleading examples showing direct piping to fabric\n- Add clear examples: ❌ what DOES NOT WORK vs ✅ what WORKS\n- Consolidate all extension documentation in Examples/README.md\n- Explain technical reason: extensions only processed via ApplyTemplate()\n- Prevents user confusion about extension syntax processing","Author":"Nick Skriloff","Email":"","Date":"2025-10-31T23:53:47Z","Parents":null},{"SHA":"c7206c0a01080f9fa537dbc27fc04eb1fc43116e","Message":"docs: minor formatting fixes","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-12T01:16:55Z","Parents":null},{"SHA":"79d04b2adac2386048691ab0ef70fca5d5908e7d","Message":"add byid to spell list","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-12T01:18:21Z","Parents":null}]


author: dependabot
author_url: https://github.com/apps/dependabot
author_type: bot
url: https://github.com/danielmiessler/Fabric/pull/1803
merged_at: 2025-11-03 05:24:34+00:00
created_at: 2025-11-03 05:26:46
title:
  chore(deps-dev): bump vite from 5.4.20 to 5.4.21 in /web in the npm_and_yarn group across 1 directory

body:
  Bumps the npm_and_yarn group with 1 update in the /web directory: [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite).

  Updates `vite` from 5.4.20 to 5.4.21
  <details>
  <summary>Release notes</summary>
  <p><em>Sourced from <a href="https://github.com/vitejs/vite/releases">vite's releases</a>.</em></p>
  <blockquote>
  <h2>v5.4.21</h2>
  <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v5.4.21/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p>
  </blockquote>
  </details>
  <details>
  <summary>Changelog</summary>
  <p><em>Sourced from <a href="https://github.com/vitejs/vite/blob/v5.4.21/packages/vite/CHANGELOG.md">vite's changelog</a>.</em></p>
  <blockquote>
  <h2><!-- raw HTML omitted -->5.4.21 (2025-10-20)<!-- raw HTML omitted --></h2>
  <ul>
  <li>fix(dev): trim trailing slash before <code>server.fs.deny</code> check (<a href="https://github.com/vitejs/vite/tree/HEAD/packages/vite/issues/20968">#20968</a>) (<a href="https://github.com/vitejs/vite/tree/HEAD/packages/vite/issues/20970">#20970</a>) (<a href="https://github.com/vitejs/vite/commit/cad1d31d0635dd8fd4ddfe6e5a92eb9ff13cd06c">cad1d31</a>), closes <a href="https://redirect.github.com/vitejs/vite/issues/20968">#20968</a> <a href="https://redirect.github.com/vitejs/vite/issues/20970">#20970</a></li>
  <li>chore: update CHANGELOG (<a href="https://github.com/vitejs/vite/commit/ca88ed7398288ce0c60176ac9a6392f10654c67c">ca88ed7</a>)</li>
  </ul>
  </blockquote>
  </details>
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a href="https://github.com/vitejs/vite/commit/adce3c22c64cc9d44cc8f45cc92b543e3e4bf385"><code>adce3c2</code></a> release: v5.4.21</li>
  <li><a href="https://github.com/vitejs/vite/commit/cad1d31d0635dd8fd4ddfe6e5a92eb9ff13cd06c"><code>cad1d31</code></a> fix(dev): trim trailing slash before <code>server.fs.deny</code> check (<a href="https://github.com/vitejs/vite/tree/HEAD/packages/vite/issues/20968">#20968</a>) (<a href="https://github.com/vitejs/vite/tree/HEAD/packages/vite/issues/20970">#20970</a>)</li>
  <li><a href="https://github.com/vitejs/vite/commit/ca88ed7398288ce0c60176ac9a6392f10654c67c"><code>ca88ed7</code></a> chore: update CHANGELOG</li>
  <li>See full diff in <a href="https://github.com/vitejs/vite/commits/v5.4.21/packages/vite">compare view</a></li>
  </ul>
  </details>
  <br />


  [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=vite&package-manager=npm_and_yarn&previous-version=5.4.20&new-version=5.4.21)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

  Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)

  ---

  <details>
  <summary>Dependabot commands and options</summary>
  <br />

  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
  - `@dependabot merge` will merge this PR after your CI passes on it
  - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
  - `@dependabot cancel merge` will cancel a previously requested merge and block automerging
  - `@dependabot reopen` will reopen this PR if it is closed
  - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
  - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency
  - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions
  You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/danielmiessler/Fabric/network/alerts).

  </details>

commits:
  [{"SHA":"c26e0bcdc5006fe25e7b8bad4512679a600978e1","Message":"chore(deps-dev): bump vite\n\nBumps the npm_and_yarn group with 1 update in the /web directory: [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite).\n\n\nUpdates `vite` from 5.4.20 to 5.4.21\n- [Release notes](https://github.com/vitejs/vite/releases)\n- [Changelog](https://github.com/vitejs/vite/blob/v5.4.21/packages/vite/CHANGELOG.md)\n- [Commits](https://github.com/vitejs/vite/commits/v5.4.21/packages/vite)\n\n---\nupdated-dependencies:\n- dependency-name: vite\n  dependency-version: 5.4.21\n  dependency-type: direct:development\n  dependency-group: npm_and_yarn\n...\n\nSigned-off-by: dependabot[bot] \u003csupport@github.com\u003e","Author":"dependabot[bot]","Email":"","Date":"2025-10-21T08:08:37Z","Parents":null},{"SHA":"10179b3e86dcc38af8582d6b19816b968b782fe1","Message":"chore: incoming 1803 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-03T05:19:18Z","Parents":null}]


title: Added several new patterns
author: OmriH-Elister
author_url: https://github.com/OmriH-Elister
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1805
merged_at: 2025-11-03 05:08:59+00:00
created_at: 2025-11-03 05:26:46
body:
  - **chore(release): Update version to v1.4.303**
  - **Create produce_report.sh**
  - **chore(release): Update version to v1.4.304**
  - **feat: add several new patterns**
  ## What this Pull Request (PR) does
  - Adds several new patterns: 	
  1.predict_person_actions - takes a stream of text, devided into two sections of text, as input from the user, a psychological profile of a person, and b. a particular challenge. It then proceeds to predict how said person is most likely to react to such a challenge. 	
  2.fix_typos - takes a single stream of text as input from the user, proof-reads it, fixes all of the found typos, produces and returns a typo-free copy of the provided text. 	
  3.recommend_yoga_practice - meant to simulate a wise yogi, takes input from the user, and provides a uniquely tailored yoga and meditation program for the user. 	
  4.model_as_sherlock_freud - assumes the role of a cross between Sherlock Holmes and Sigmond Freud, receives input from the user (text written by and/or about the subject) and constructs the most complete theoretical model of the subject's mind, including the subconsious, semi-conscious and conscious levels.**


  ## Related issues

  Please reference any open issues this PR relates to in here.
  If it closes an issue, type `closes #[ISSUE_NUMBER]`.

  ## Screenshots

  Provide any screenshots you may find relevant to facilitate us understanding your PR.

commits:
  [{"SHA":"0d880c5c97fce1012683092a4b15fd5e6f7d7a57","Message":"feat: add a few new patterns","Author":"OmriH-Elister","Email":"","Date":"2025-10-28T13:55:44Z","Parents":null},{"SHA":"9a426e9d5a2eb28888b0142ce6a56da1dc75e5ee","Message":"chore: incoming 1805 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-10-28T14:23:49Z","Parents":null},{"SHA":"72691a4ce051167dbafc1ff7e49686bc21a16bac","Message":"remove 1805.txt","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-03T04:41:01Z","Parents":null},{"SHA":"ff9699549d6533e1a9b87f262c55c08e0d4a92b8","Message":"chore: incoming 1805 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-03T04:41:06Z","Parents":null},{"SHA":"10b556f2f684dd195560d7a8c954fe3b5d1afcdf","Message":"Update changelog for PR 1805","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-03T04:46:04Z","Parents":null},{"SHA":"068a673bb318dd885fc69753a6ae5c0bdcdb7b8d","Message":"feat: add wellness patterns and new analysis tools\n\n# CHANGES\n\n- Add new WELLNESS category with four patterns\n- Add `model_as_sherlock_freud` for psychological detective analysis\n- Add `predict_person_actions` for behavioral response predictions\n- Add `recommend_yoga_practice` for personalized wellness guidance\n- Add `fix_typos` pattern for proofreading corrections\n- Update ANALYSIS category to include new patterns\n- Update SELF category with wellness-related patterns\n- Tag existing patterns with WELLNESS classification","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-03T05:03:22Z","Parents":null},{"SHA":"f8ccbaa5e4545f4b3cfba0b6ec1e21f8e507eb44","Message":"chore: incoming 1805 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-03T05:03:56Z","Parents":null}]


title: Updated create_newsletter_entry pattern to generate more factual titles
author: sluosapher
author_url: https://github.com/sluosapher
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1808
merged_at: 2025-11-03 04:33:06+00:00
created_at: 2025-11-03 05:26:46
body:
  ## What this Pull Request (PR) does

  1. Updated the prompt to generate titles with more calm and factual words, and sounds less exciting and emotional.
  2. Added one output example.

commits:
  [{"SHA":"0dba40f8a0a71c58e387faa305cfb567a9a7e1bd","Message":"Updated the title generation style; added an output example.","Author":"Song Luo","Email":"","Date":"2025-10-26T14:18:03Z","Parents":null},{"SHA":"eff45c8e9b38e4ae825f328f23b58905df7afaae","Message":"chore: incoming 1808 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-03T04:28:29Z","Parents":null}]


title: improve subtitle lang, retry, debugging & error handling
author: tonymet
author_url: https://github.com/tonymet
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1810
merged_at: 2025-10-28 14:31:51+00:00
created_at: 2025-10-28 14:34:19
body:
  ## What this Pull Request (PR) does
  Improve yt-dlp stability & debugging to address #1787  &  #1785 

  * simplify retry / no-lang routine to preserve `--yt-dlp-args` and other args
  * output `yt-dlp` args, stdout & stderr when `--debug=3` is passed 
  * fix bug with `--sub-langs` redundant lang (red herring)

  ## Related issues

  #1787  -- fixed by reducing side-effects with args & --yt-dlp-args
  #1785 -- partially fixed by improving debugging and passthrough of `--yt-dlp-args=--sleep-requests 1"`



  ## Screenshots

  example debug output showing args , stdout + stderr from yt-dlp
  ```
  DEBUG: yt-dlp [yt-dlp --write-auto-subs --skip-download --sub-format vtt -o C:\Users\tonymet\AppData\Local\Temp\fabric-youtube-LGd6GXq7L2Y\%(title)s.%(ext)s --sub-langs en,en.* --sleep-requests 1 https://www.youtube.com/watch?v=LGd6GXq7L2Y]
  DEBUG: [youtube] Extracting URL: https://www.youtube.com/watch?v=LGd6GXq7L2Y
  DEBUG: [youtube] LGd6GXq7L2Y: Downloading webpage
  DEBUG: [youtube] Sleeping 1.0 seconds ...
  DEBUG: [youtube] LGd6GXq7L2Y: Downloading tv client config
  DEBUG: [youtube] Sleeping 1.0 seconds ...
  DEBUG: [youtube] LGd6GXq7L2Y: Downloading tv player API JSON
  DEBUG: [youtube] Sleeping 1.0 seconds ...
  DEBUG: [youtube] LGd6GXq7L2Y: Downloading web safari player API JSON
  DEBUG: [youtube] Sleeping 1.0 seconds ...
  DEBUG: [youtube] LGd6GXq7L2Y: Downloading m3u8 information
  DEBUG: [info] LGd6GXq7L2Y: Downloading subtitles: en, en-orig
  DEBUG: [info] LGd6GXq7L2Y: Downloading 1 format(s): 315+251
  DEBUG: [info] Writing video subtitles to: C:\Users\tonymet\AppData\Local\Temp\fabric-youtube-LGd6GXq7L2Y\Finding the Best 1 Gallon Keg for Homebrewing & Giving It Away!.en.vtt
  DEBUG: [download] Destination: C:\Users\tonymet\AppData\Local\Temp\fabric-youtube-LGd6GXq7L2Y\Finding the Best 1 Gallon Keg for Homebrewing & Giving It Away!.en.vtt
  [download] 100% of  153.21KiB in 00:00:00 at 708.00KiB/s
  DEBUG: [info] Writing video subtitles to: C:\Users\tonymet\AppData\Local\Temp\fabric-youtube-LGd6GXq7L2Y\Finding the Best 1 Gallon Keg for Homebrewing & Giving It Away!.en-orig.vtt
  DEBUG: [download] Destination: C:\Users\tonymet\AppData\Local\Temp\fabric-youtube-LGd6GXq7L2Y\Finding the Best 1 Gallon Keg for Homebrewing & Giving It Away!.en-orig.vtt
  [download] 100% of  153.21KiB in 00:00:00 at 941.82KiB/s

  ```

  #### Retry Example

  ```
  DEBUG: yt-dlp [yt-dlp --write-auto-subs --skip-download --sub-format vtt -o C:\Users\tonymet\AppData\Local\Temp\fabric-youtube-LGd6GXq7L2Y\%(title)s.%(ext)s --sub-langs zzz,zz.*,zz --sleep-requests 1 https://www.youtube.com/watch?v=LGd6GXq7L2Y]
  [TRUNCATED]
  DEBUG: yt-dlp [yt-dlp --write-auto-subs --skip-download --sub-format vtt -o C:\Users\tonymet\AppData\Local\Temp\fabric-youtube-LGd6GXq7L2Y\%(title)s.%(ext)s --sleep-requests 1 https://www.youtube.com/watch?v=LGd6GXq7L2Y]      
  [TRUNCATED]
  DEBUG: Starting template processing
  DEBUG: Starting template processing

  ```

  ## Testing 

  Test the retry with these args

  ```
  # set lang to zzz to force retry
   ["-g", "zzz", "--debug=3", "-y", "https://www.youtube.com/watch?v=LGd6GXq7L2Y", "-p", "extract_wisdom", "--yt-dlp-args=--sleep-requests 1"],

  ```

commits:
  [{"SHA":"3211f6f35c4a41bf98ac6aad4283fed8f3b46de5","Message":"improve subtitle lang, retry, debugging \u0026 error handling","Author":"Anthony Metzidis","Email":"","Date":"2025-10-22T00:43:40Z","Parents":null},{"SHA":"4f20f7a16b4203c91ae735fcc379736093e26be8","Message":"chore: incoming 1810 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-10-28T13:45:12Z","Parents":null}]


title: Add Concept Map in html
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1814
merged_at: 2025-11-03 21:11:29+00:00
merge_commit: 4d40ef5f83bb118cde32e925a32f4a91832f8622
created_at: 2025-11-05 01:56:10
body:
  ## What this Pull Request (PR) does

  Create an interactive concept map in HTML using Vis.js

  ## Related issues

  Recreated from #1812 - Credit goes to @FELIPEGUEDESBR

commits:
  [{"SHA":"eefb3c78861d137b17d9aa0520f930ba520feb70","Message":"chore: added `fix_typos`, `model_as_sherlock_freud`, and `predict_person_actions` methods\n\n### CHANGES\n\n- Add `fix_typos` for proofreading and correcting errors\n- Introduce `model_as_sherlock_freud` for psychological modeling\n- Implement `predict_person_actions` for behavioral response predictions\n- Add `recommend_yoga_practice` for personalized yoga guidance\n- Include `fix_typos` method for text correction\n- Add `model_as_sherlock_freud` for behavior analysis\n- Introduce `predict_person_actions` for action prediction","Author":"Kayvan Sylvan","Email":"kayvan@sylvan.com","Date":"2025-11-03T05:15:40Z","Parents":["4b9887da2e2017023e764c7cc7f83df6c595aa1c"]},{"SHA":"f9d23a2ec65a6e1274534a077e836ed045f29bd6","Message":"Merge branch 'danielmiessler:main' into main","Author":"Kayvan Sylvan","Email":"KayvanSylvan@gmail.com","Date":"2025-11-03T05:25:17Z","Parents":["eefb3c78861d137b17d9aa0520f930ba520feb70","31e99c59580be53d48786652bfe35ea8ac09358c"]},{"SHA":"d0d3268eaa6a9ab5274d165afa6a2ff63178fed4","Message":"Merge branch 'danielmiessler:main' into main","Author":"Kayvan Sylvan","Email":"KayvanSylvan@gmail.com","Date":"2025-11-03T05:26:51Z","Parents":["f9d23a2ec65a6e1274534a077e836ed045f29bd6","da3e7c2510a840891b7c1b26ca05d6fe1fc0a582"]},{"SHA":"a149bd19d5434de15308e4e6b80052515ab27fa3","Message":"feat: add `create_conceptmap` for interactive HTML concept maps\n\n### CHANGES\n\n- Add `create_conceptmap` for HTML concept maps using Vis.js\n- Introduce `fix_typos` for text proofreading and corrections\n- Implement `model_as_sherlock_freud` for psychological modeling\n- Add `predict_person_actions` for behavior prediction\n- Include `recommend_yoga_practice` for personalized yoga guidance\n- Credit pattern contribution to @FELIPEGUEDESBR","Author":"Kayvan Sylvan","Email":"kayvan@sylvan.com","Date":"2025-11-03T21:10:05Z","Parents":["d0d3268eaa6a9ab5274d165afa6a2ff63178fed4"]}]


title: Update `anthropic-sdk-go` to v1.16.0 and update models
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1816
merged_at: 2025-11-05 01:54:03+00:00
created_at: 2025-11-05 01:56:13
body:
  # Update `anthropic-sdk-go` to v1.16.0 and update models

  This PR updates the Anthropic SDK dependency from version 1.13.0 to 1.16.0 and refactors the model list to include a new Claude Sonnet 4.5 dated model while reorganizing the existing model declarations for better clarity.

  ## Files Changed

  ### `go.mod`
  - Updated `github.com/anthropics/anthropic-sdk-go` from version `1.13.0` to `1.16.0`

  ### `go.sum`
  - Updated checksums for the Anthropic SDK dependency to reflect the new version `1.16.0`

  ### `internal/plugins/ai/anthropic/anthropic.go`
  - Reorganized the model list by removing intermediate Claude 3.5 Sonnet models and adding the new dated variant
  - Added beta configuration for the new Claude Sonnet 4.5 dated model

  ## Code Changes

  #### Dependency Update
  ```go
  // go.mod
  -	github.com/anthropics/anthropic-sdk-go v1.13.0
  +	github.com/anthropics/anthropic-sdk-go v1.16.0
  ```

  #### Model List Refactoring
  The model list was reorganized to remove the following models:
  - `ModelClaude3_5SonnetLatest`
  - `ModelClaude3_5Sonnet20241022`
  - `ModelClaude_3_5_Sonnet_20240620`

  And added:
  ```go
  string(anthropic.ModelClaudeSonnet4_5_20250929)
  ```

  #### Beta Configuration Addition
  ```go
  ret.modelBetas = map[string][]string{
      string(anthropic.ModelClaudeSonnet4_20250514):   {"context-1m-2025-08-07"},
      string(anthropic.ModelClaudeSonnet4_5):          {"context-1m-2025-08-07"},
  +   string(anthropic.ModelClaudeSonnet4_5_20250929): {"context-1m-2025-08-07"},
  }
  ```

  ## Reason for Changes

  1. **SDK Update**: Upgrading to Anthropic SDK v1.16.0 likely includes bug fixes, performance improvements, and support for newer models that are referenced in the code changes.

  2. **Model List Simplification**: The removal of Claude 3.5 Sonnet variants suggests these models may have been deprecated or superseded by the Claude 4 series models. This cleanup reduces confusion and maintains only actively supported models.

  3. **New Model Support**: Adding `ModelClaudeSonnet4_5_20250929` provides access to a newer dated version of the Claude Sonnet 4.5 model, likely with improvements or fixes over previous versions.

  4. **Beta Feature Configuration**: The new model requires the same 1M context window beta feature flag as its predecessors, ensuring consistent behavior across Claude 4.5 variants.

  ## Impact of Changes

  ### Positive Impacts
  - **Up-to-date Dependencies**: Users benefit from the latest SDK improvements and bug fixes
  - **Access to Latest Models**: The new dated model variant provides access to the most recent Claude capabilities
  - **Cleaner Codebase**: Removing deprecated models reduces maintenance burden and potential confusion

  ### Potential Issues
  - **Breaking Changes**: Users who were explicitly using the removed Claude 3.5 Sonnet models will no longer have access to them through this client. This could break existing configurations that reference these specific model strings.
  - **API Compatibility**: The SDK version bump could introduce breaking changes in the API surface, though the code suggests the changes are backward compatible in the areas being used.

  ## Test Plan

  The changes were tested as follows:

  1. **Dependency Resolution**: Verify that `go mod tidy` and `go build` complete successfully with the new SDK version
  2. **Model Initialization**: Confirm that the client initializes correctly and the model list is properly populated
  3. **Model Selection**: Test that the new `ModelClaudeSonnet4_5_20250929` can be selected and used for inference
  4. **Beta Feature**: Verify that the 1M context window beta feature is properly applied when using the new model
  5. **Backward Compatibility**: Test existing code paths that use Claude 4 models to ensure they continue to work as expected

  ## Additional Notes

  **Deprecation Warning**: If the removed Claude 3.5 Sonnet models are still in use by consumers of this library, consider:
  - Adding a migration guide in the PR description or release notes
  - Implementing a deprecation warning period before removal
  - Documenting which models should be used as replacements

  **Version Date Pattern**: The new model follows the pattern of dated model versions (e.g., `20250929`), which appears to be Anthropic's strategy for versioning models. Future updates will likely follow this pattern.

  **Beta Feature Consistency**: All Claude Sonnet 4.5 variants now require the same beta feature flag, suggesting this is a family-wide capability requirement rather than model-specific.

commits:
  [{"SHA":"73dec534c4af4b2a0f6466529ad84dfd75015439","Message":"feat: update `anthropic-sdk-go` to v1.16.0 and update models\n\n- Upgrade `anthropic-sdk-go` to version 1.16.0\n- Remove outdated model `ModelClaude3_5SonnetLatest`\n- Add new model `ModelClaudeSonnet4_5_20250929`\n- Include `ModelClaudeSonnet4_5_20250929` in `modelBetas` map","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-05T01:28:18Z","Parents":null}]


title: Add missing patterns and renumber pattern explanations list
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1823
merged_at: 2025-11-10 22:10:08+00:00
created_at: 2025-11-12 01:24:07
body:
  # Add missing patterns and renumber pattern explanations list

  ## Summary

  This PR updates the pattern explanations documentation by adding four new patterns and renumbering the existing patterns accordingly. The additions expand the pattern library with new capabilities for content tagging, MCP server extraction, code rule generation, and Dunning-Kruger assessment.

  ## Related issues

  Closes #1821 

  ## Files Changed

  ### `data/patterns/pattern_explanations.md`
  - Added 4 new pattern entries
  - Renumbered all subsequent patterns from #37 onwards to accommodate the new additions
  - Maintained consistent formatting and structure throughout

  ## Code Changes

  The following new patterns were inserted:

  **Line 41-42: apply_ul_tags (Pattern #37)**
  ```markdown
  37. **apply_ul_tags**: Apply standardized content tags to categorize topics like AI, cybersecurity, politics, and culture.
  ```

  **Line 129: extract_mcp_servers (Pattern #129)**
  ```markdown
  129. **extract_mcp_servers**: Identify and summarize Model Context Protocol (MCP) servers referenced in the input along with their key details.
  ```

  **Line 153: generate_code_rules (Pattern #153)**
  ```markdown
  153. **generate_code_rules**: Compile best-practice coding rules and guardrails for AI-assisted development workflows from the provided content.
  ```

  **Line 203: t_check_dunning_kruger (Pattern #203)**
  ```markdown
  203. **t_check_dunning_kruger**: Assess narratives for Dunning-Kruger patterns by contrasting self-perception with demonstrated competence and confidence cues.
  ```

  All patterns from the original #37 onwards have been renumbered incrementally by +1, +2, +3, or +4 depending on their position relative to the insertions, resulting in the final pattern count increasing from 226 to 230.

  ## Reason for Changes

  This update adds four new pattern definitions to the documentation to reflect new capabilities that have been added to the pattern library:

  1. **apply_ul_tags**: Provides content categorization functionality
  2. **extract_mcp_servers**: Adds MCP (Model Context Protocol) server identification capabilities
  3. **generate_code_rules**: Enables extraction of coding best practices for AI-assisted workflows
  4. **t_check_dunning_kruger**: Adds psychological assessment capability for confidence-competence analysis

  ## Impact of Changes

  - **Expanded functionality**: Users now have access to 4 additional patterns (230 total, up from 226)
  - **Documentation completeness**: The pattern explanations file now accurately reflects all available patterns
  - **No breaking changes**: Existing pattern names remain unchanged; only their numerical positions in the list have shifted

  ## Test Plan

  1. Verify all pattern numbers are sequential from 1-230 without gaps
  2. Confirm each new pattern description is clear and follows the established format
  3. Spot-check several patterns across different sections to ensure renumbering was applied correctly
  4. Validate that the markdown formatting remains consistent throughout

commits:
  [{"SHA":"8e18753c0fd463c29ef5137e1db07d0e397c9fa8","Message":"docs: add new patterns and renumber pattern explanations list\n\n# CHANGES\n\n- Add `apply_ul_tags` pattern for content categorization\n- Add `extract_mcp_servers` pattern for MCP server identification\n- Add `generate_code_rules` pattern for AI coding guardrails\n- Add `t_check_dunning_kruger` pattern for competence assessment\n- Renumber all patterns from 37-226 to 37-230\n- Insert new patterns at positions 37, 129, 153, 203","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-10T22:01:29Z","Parents":null}]


title: Make YouTube API key optional in setup
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1827
merged_at: 2025-11-14 07:46:45+00:00
created_at: 2025-11-14 07:49:25
body:
  # Make YouTube API Key Optional in Setup

  ## Summary

  This PR makes the YouTube API key optional during plugin setup, allowing the YouTube plugin to be configured and used without providing an API key upfront.

  ## Related Issues

  Closes #1820

  ## Files Changed

  ### `internal/tools/youtube/youtube.go`
  Modified the YouTube plugin initialization to mark the API key setup question as optional rather than required.

  ### `internal/tools/youtube/youtube_optional_test.go` (New file)
  Added a new test file to verify that the YouTube API key is properly configured as optional and that the plugin is considered configured even without an API key.

  ## Code Changes

  ### internal/tools/youtube/youtube.go

  Changed line 72 from:
  ```go
  ret.ApiKey = ret.AddSetupQuestion("API key", true)
  ```

  To:
  ```go
  ret.ApiKey = ret.AddSetupQuestion("API key", false)
  ```

  The second parameter to `AddSetupQuestion` controls whether the field is required. This change switches it from `true` (required) to `false` (optional).

  ### internal/tools/youtube/youtube_optional_test.go

  Added a test with three key assertions:

  1. Verifies the API key setup question is initialized
  2. Confirms the `Required` field is set to `false`
  3. Validates that `IsConfigured()` returns `true` even without an API key

  ## Reason for Changes

  The YouTube API key is being made optional to improve the plugin's flexibility and user experience. This change supports scenarios where:

  - Users want to use the YouTube plugin initially without having an API key ready
  - The plugin has fallback functionality that doesn't require API authentication
  - Configuration can be completed in stages, with the API key added later when needed

  ## Impact of Changes

  **Positive impacts:**
  - Improved user experience by reducing barriers to initial configuration
  - More flexible plugin setup workflow
  - Maintains backward compatibility (existing configurations with API keys continue to work)

  **Potential concerns:**
  - Runtime behavior when the API key is missing: Code that depends on the API key will need proper error handling when the key is not provided
  - If API operations are attempted without a key, ensure graceful error messages guide users to add the key

  ## Test Plan

  Added a unit test `TestNewYouTubeApiKeyOptional` that verifies:
  1. The API key setup question is properly initialized
  2. The `Required` field is explicitly set to `false`
  3. The plugin is considered configured (`IsConfigured()` returns `true`) without an API key

  The test should be run with:
  ```bash
  go test ./internal/tools/youtube/...
  ```

  ## Additional Notes

  **Potential bugs to watch for:**
  - Silent failures or cryptic errors when YouTube API operations are attempted without a key

commits:
  [{"SHA":"d02a55ee01a579ceb36846122aaf253f6605eeda","Message":"feat: make YouTube API key optional in setup\n\n- Change API key setup question to optional\n- Add test for optional API key behavior\n- Ensure plugin configuration without API key\n- chore: incoming 1827 changelog entry","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-14T07:34:28Z","Parents":null}]


title: Fix empty string detection in chatter and AI clients
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1828
merged_at: 2025-11-15 05:22:53+00:00
created_at: 2025-11-15 05:25:50
body:
  # Fix empty string detection in chatter and AI clients

  ## Summary

  This PR fixes message content validation across AI provider integrations by standardizing empty message handling. The changes ensure that whitespace-only messages are properly filtered out, preventing potential API errors and improving consistency across Anthropic and Gemini clients.

  ## Related issues

  closes #1819 

  ## Files Changed

  1. **`internal/core/chatter.go`**
     - Modified default message content initialization
     
  2. **`internal/plugins/ai/anthropic/anthropic.go`**
     - Updated message filtering logic in the `toMessages` method

  3. **`internal/plugins/ai/gemini/gemini.go`**
     - Updated message filtering logic in the `convertMessages` method

  ## Code Changes

  ### internal/core/chatter.go
  Changed the default empty message content from a single space to an empty string:

  ```go
  // Before
  Content: " ",

  // After
  Content: "",
  ```

  This ensures that when no message is provided, we initialize with a truly empty string rather than whitespace.

  ### internal/plugins/ai/anthropic/anthropic.go
  Enhanced empty message detection to handle whitespace:

  ```go
  // Before
  if msg.Content == "" {
      continue // Skip empty messages
  }

  // After
  if strings.TrimSpace(msg.Content) == "" {
      continue // Skip empty messages
  }
  ```

  ### internal/plugins/ai/gemini/gemini.go
  Applied the same whitespace-aware filtering:

  ```go
  // Before
  if msg.Content != "" {
      content.Parts = append(content.Parts, &genai.Part{Text: msg.Content})
  }

  // After
  if strings.TrimSpace(msg.Content) != "" {
      content.Parts = append(content.Parts, &genai.Part{Text: msg.Content})
  }
  ```

  ## Reason for Changes

  The original implementation had an inconsistency: `chatter.go` was initializing empty messages with a single space `" "`, while the AI clients were only checking for exact empty strings `""`. This could lead to:

  1. Messages containing only whitespace being sent to AI APIs, potentially causing errors or unexpected behavior
  2. Inconsistent message filtering across different AI providers
  3. Unnecessary API calls with meaningless whitespace-only content

  By changing the default to an empty string and using `strings.TrimSpace()` in the filtering logic, we ensure consistent handling of empty and whitespace-only messages.

  ## Impact of Changes

  **Positive impacts:**
  - Prevents whitespace-only messages from being sent to AI APIs
  - Improves consistency across Anthropic and Gemini integrations
  - Reduces potential for API errors due to invalid message content
  - More robust message validation

  **Potential considerations:**
  - Any code that explicitly relied on whitespace messages being processed will now have those messages filtered out (this is likely the desired behavior)
  - The `strings.TrimSpace()` adds minimal processing overhead, but filters more effectively

  ## Test Plan

  The changes should be tested by:

  1. Creating chat requests with empty messages (no content)
  2. Creating chat requests with whitespace-only content (spaces, tabs, newlines)
  3. Verifying that both Anthropic and Gemini clients properly filter these messages
  4. Ensuring that legitimate messages with actual content are not filtered
  5. Confirming no API errors occur when processing message arrays with empty/whitespace entries

  ## Additional Notes

  - This is a defensive programming improvement that makes the message handling more robust

commits:
  [{"SHA":"729d09275401f9847e7bb97e78583db7e99123ba","Message":"chore: improve message handling by trimming whitespace in content checks\n\n### CHANGES\n\n- Remove default space in `BuildSession` message content\n- Trim whitespace in `anthropic` message content check\n- Trim whitespace in `gemini` message content check","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-15T05:13:08Z","Parents":null},{"SHA":"2e7b664e1eff220aafc0a31254c57023eb201818","Message":"chore: incoming 1828 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-15T05:20:52Z","Parents":null}]


title: chore(deps): bump js-yaml from 4.1.0 to 4.1.1 in /web in the npm_and_yarn group across 1 directory
author: dependabot
author_url: https://github.com/apps/dependabot
author_type: bot
url: https://github.com/danielmiessler/Fabric/pull/1829
merged_at: 2025-12-14 08:03:09+00:00
created_at: 2025-12-14 08:05:48
body:
  Bumps the npm_and_yarn group with 1 update in the /web directory: [js-yaml](https://github.com/nodeca/js-yaml).

  Updates `js-yaml` from 4.1.0 to 4.1.1
  <details>
  <summary>Changelog</summary>
  <p><em>Sourced from <a href="https://github.com/nodeca/js-yaml/blob/master/CHANGELOG.md">js-yaml's changelog</a>.</em></p>
  <blockquote>
  <h2>[4.1.1] - 2025-11-12</h2>
  <h3>Security</h3>
  <ul>
  <li>Fix prototype pollution issue in yaml merge (&lt;&lt;) operator.</li>
  </ul>
  </blockquote>
  </details>
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a href="https://github.com/nodeca/js-yaml/commit/cc482e775913e6625137572a3712d2826170e53a"><code>cc482e7</code></a> 4.1.1 released</li>
  <li><a href="https://github.com/nodeca/js-yaml/commit/50968b862e75866ef90e626572fe0b2f97b55f9f"><code>50968b8</code></a> dist rebuild</li>
  <li><a href="https://github.com/nodeca/js-yaml/commit/d092d866031751cb27c12d93f3e2470ad74d678b"><code>d092d86</code></a> lint fix</li>
  <li><a href="https://github.com/nodeca/js-yaml/commit/383665ff4248ec2192d1274e934462bb30426879"><code>383665f</code></a> fix prototype pollution in merge (&lt;&lt;)</li>
  <li><a href="https://github.com/nodeca/js-yaml/commit/0d3ca7a27b03a6c974790a30a89e456007d62976"><code>0d3ca7a</code></a> README.md: HTTP =&gt; HTTPS (<a href="https://redirect.github.com/nodeca/js-yaml/issues/678">#678</a>)</li>
  <li><a href="https://github.com/nodeca/js-yaml/commit/49baadd52af887d2991e2c39a6639baa56d6c71b"><code>49baadd</code></a> doc: 'empty' style option for !!null</li>
  <li><a href="https://github.com/nodeca/js-yaml/commit/ba3460eb9d3e4478edcbc29edabe17c2157fc9ce"><code>ba3460e</code></a> Fix demo link (<a href="https://redirect.github.com/nodeca/js-yaml/issues/618">#618</a>)</li>
  <li>See full diff in <a href="https://github.com/nodeca/js-yaml/compare/4.1.0...4.1.1">compare view</a></li>
  </ul>
  </details>
  <br />


  [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=js-yaml&package-manager=npm_and_yarn&previous-version=4.1.0&new-version=4.1.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

  Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)

  ---

  <details>
  <summary>Dependabot commands and options</summary>
  <br />

  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
  - `@dependabot merge` will merge this PR after your CI passes on it
  - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
  - `@dependabot cancel merge` will cancel a previously requested merge and block automerging
  - `@dependabot reopen` will reopen this PR if it is closed
  - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
  - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency
  - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions
  You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/danielmiessler/Fabric/network/alerts).

  </details>

commits:
  [{"SHA":"bb896b106443edd47b25198ae2646ce9f5a44a6b","Message":"chore(deps): bump js-yaml\n\nBumps the npm_and_yarn group with 1 update in the /web directory: [js-yaml](https://github.com/nodeca/js-yaml).\n\n\nUpdates `js-yaml` from 4.1.0 to 4.1.1\n- [Changelog](https://github.com/nodeca/js-yaml/blob/master/CHANGELOG.md)\n- [Commits](https://github.com/nodeca/js-yaml/compare/4.1.0...4.1.1)\n\n---\nupdated-dependencies:\n- dependency-name: js-yaml\n  dependency-version: 4.1.1\n  dependency-type: indirect\n  dependency-group: npm_and_yarn\n...\n\nSigned-off-by: dependabot[bot] \u003csupport@github.com\u003e","Author":"dependabot[bot]","Email":"","Date":"2025-11-15T21:28:04Z","Parents":null},{"SHA":"6003bb2c8680473ae6055f5a8f49cf81b2d97aa2","Message":"chore: incoming 1829 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-14T07:50:24Z","Parents":null}]


title: Ensure final newline in model generated outputs
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1830
merged_at: 2025-11-16 19:33:47+00:00
created_at: 2025-11-16 19:36:17
body:
  ### CHANGES

  - Add newline to `CreateOutputFile` if missing
  - Use `t.Cleanup` for file removal in tests
  - Add test for message with trailing newline
  - Introduce `printedStream` flag in `Chatter.Send`
  - Print newline if stream printed without trailing newline

  ## What this Pull Request (PR) does

  Please briefly describe what this PR does.

  ## Related issues

  Please reference any open issues this PR relates to in here.
  If it closes an issue, type `closes #[ISSUE_NUMBER]`.

  ## Screenshots

  Provide any screenshots you may find relevant to facilitate us understanding your PR.

commits:
  [{"SHA":"c936f8e77bbd32a62858d31a70cd922b5c42a702","Message":"feat: ensure newline in `CreateOutputFile` and improve tests\n\n- Add newline to `CreateOutputFile` if missing\n- Use `t.Cleanup` for file removal in tests\n- Add test for message with trailing newline\n- Introduce `printedStream` flag in `Chatter.Send`\n- Print newline if stream printed without trailing newline","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-16T18:36:19Z","Parents":null}]


title: Remove `get_youtube_rss` pattern
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1831
merged_at: 2025-11-16 20:41:12+00:00
created_at: 2025-11-16 21:12:09
body:
  # Remove get_youtube_rss pattern

  ## Related Issues

  Closes #1817 

  ## Summary

  This PR removes the `get_youtube_rss` pattern from the Fabric project. The pattern, which generated RSS feed URLs for YouTube channels based on channel IDs or URLs, has been completely removed from the codebase along with all references to it across documentation and configuration files.

  ## Files Changed

  ### Added Files

  #### `cmd/generate_changelog/incoming/1831.txt`
  A new changelog entry documenting this PR's changes, listing all the files and locations where `get_youtube_rss` was removed.

  ### Deleted Files

  #### `data/patterns/get_youtube_rss/system.md`
  The primary pattern definition file containing the identity, steps, and output format for generating YouTube RSS URLs. This 27-line file instructed the AI to extract channel IDs from YouTube URLs and construct RSS feed URLs in the format `https://www.youtube.com/feeds/videos.xml?channel_id={CHANNEL_ID}`.

  ### Modified Files

  #### `data/patterns/pattern_explanations.md`
  - Removed entry ##155 describing `get_youtube_rss`
  - Renumbered all subsequent pattern entries from ##156-230 down to #155-229

  #### `data/patterns/suggest_pattern/system.md`
  - Removed `get_youtube_rss` from the **CONVERSION** category list
  - Removed `get_youtube_rss` from the **DEVELOPMENT** category list

  #### `data/patterns/suggest_pattern/user.md`
  - Removed the `#### get_youtube_rss` section and its description "Generate RSS feed URLs for YouTube channels."

  #### `scripts/pattern_descriptions/pattern_descriptions.json`
  - Removed the JSON object entry for `get_youtube_rss` containing its description and tags

  #### `scripts/pattern_descriptions/pattern_extracts.json`
  - Removed the JSON object entry containing the full pattern extract for `get_youtube_rss`

  #### `web/static/data/pattern_descriptions.json`
  - Removed the JSON object entry for `get_youtube_rss` (identical change to the scripts version)

  ## Code Changes

  The most significant change is the deletion of the pattern implementation file.

  All references in documentation and metadata files have been surgically removed, including pattern categorization in the `suggest_pattern` system that classified it under both **CONVERSION** and **DEVELOPMENT** categories.

  ## Reason for Changes

  This task can be accomplished more efficiently and robustly using a simple shell command:

  ```bash
  CHANNEL_ID=$(echo "$1" | grep -oP '(channel/|channel_id=)\K[0-9a-zA-Z_-]+')

  if [ -z "${CHANNEL_ID}" ]; then
      CHANNEL_ID="$1"
  fi

  echo "https://www.youtube.com/feeds/videos.xml?channel_id=${CHANNEL_ID}"
  ```

  ## Impact of Changes

  **Positive impacts:**
  - Reduced maintenance burden for the pattern library
  - Cleaner codebase with fewer patterns to maintain
  - Updated documentation accurately reflects available patterns
  - Pattern numbering in `pattern_explanations.md` remains sequential after renumbering

  **Affected systems:**
  - Pattern discovery and suggestion system
  - Web interface pattern listings
  - Command-line pattern invocation
  - Any automation or scripts using this pattern

  ## Test Plan

  To verify this change:

  1. **Pattern availability**: Confirm `get_youtube_rss` is no longer available when listing patterns
  2. **Pattern suggestion**: Test that `suggest_pattern` no longer recommends `get_youtube_rss` for YouTube RSS-related queries
  3. **Web interface**: Verify the pattern does not appear in web-based pattern browsers
  4. **Documentation consistency**: Verify all documentation files no longer reference the removed pattern
  5. **JSON validity**: Validate that all modified JSON files remain syntactically correct
  6. **Numbering accuracy**: Confirm pattern numbering in `pattern_explanations.md` is sequential from 1-229

commits:
  [{"SHA":"118abdc368db03d68e84b8835c9cba44819cf185","Message":"chore: remove `get_youtube_rss` pattern from multiple files\n\n- Remove `get_youtube_rss` from `pattern_explanations.md`\n- Delete `get_youtube_rss` entry in `pattern_descriptions.json`\n- Delete `get_youtube_rss` entry in `pattern_extracts.json`\n- Remove `get_youtube_rss` from `suggest_pattern/system.md`\n- Remove `get_youtube_rss` from `suggest_pattern/user.md`\n- chore: incoming 1831 changelog entry","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-16T20:24:28Z","Parents":null}]


title: Improve channel management in Gemini provider
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1832
merged_at: 2025-11-16 21:08:59+00:00
created_at: 2025-11-16 21:12:09
body:
  # Improve channel management in Gemini provider

  ## Summary

  Ensure `SendStream` consistently closes the output channel and returns errors instead of sending error messages into the stream and exiting via `break`. This hardens the streaming behavior and avoids double-closing the channel.

  ## Related Issues

  Closes #1815 

  ## Files Changed

  - `internal/plugins/ai/gemini/gemini.go`
    - Adjusted `SendStream` to:
      - Always close the provided channel via `defer`.
      - Return errors encountered from the streaming client instead of writing them into the channel and breaking.
      - Remove multiple explicit `close(channel)` calls.

  ## Code Changes

  ### `internal/plugins/ai/gemini/gemini.go`

  1. Ensure the output channel is closed exactly once:

  ```go
  func (o *Client) SendStream(msgs []*chat.ChatCompletionMessage, opts *domain.ChatOptions, channel chan string) (err error) {
      ctx := context.Background()
      defer close(channel)
  ```

  Previously, the channel was closed explicitly in multiple places (inside the loop on error and again at the end of the function). Now it is closed via `defer`, guaranteeing closure even on early returns and preventing double-closes.

  2. Return errors from the stream loop instead of sending them on the channel:

  ```go
  for response, err := range stream {
      if err != nil {
          channel <- fmt.Sprintf("Error: %v\n", err)
          return err
      }

      text := o.extractTextFromResponse(response)
      if text != "" {
          channel <- text
      }
  }
  ```

  Previously:

  ```go
  for response, err := range stream {
      if err != nil {
          channel <- fmt.Sprintf("Error: %v\n", err)
          close(channel)
          break
      }

      text := o.extractTextFromResponse(response)
      if text != "" {
          channel <- text
      }
  }
  close(channel)
  ```

  Key differences:

  - On error, we now:
    - Keep the existing behavior of sending a human-readable error message into the channel.
    - Immediately return the error, allowing callers to handle it programmatically.
  - We no longer `break` the loop and rely on trailing `close(channel)`; instead, `defer close(channel)` ensures channel closure on any return path.

  3. Remove redundant explicit `close(channel)` at the end of `SendStream`, as it is now handled by `defer`.

  ## Reason for Changes

  - Avoid potential `panic: close of closed channel` due to multiple `close(channel)` calls (in-loop on error and at the end of the function).
  - Make error handling more explicit for callers:
    - Callers can now distinguish successful vs. failed streaming via the `error` return value rather than inferring errors solely from channel content.
  - Ensure the channel is always closed regardless of how the function exits (normal completion, early error, or other future branches).

  ## Impact of Changes

  - **API semantics**:
    - `SendStream` continues to stream text messages on `channel`.
    - On error, behavior is slightly richer:
      - The channel still receives a user-friendly `"Error: ..."` message.
      - The function now returns a non-nil error.
  - **Resource safety**:
    - Eliminates double-close risk on the channel.
    - Guarantees channel closure in all paths via `defer`.
  - **Downstream consumers**:
    - Consumers that:
      - Only read from the channel and ignore the returned error will still receive an error message and observe channel closure as before.
      - Check the returned error can now respond appropriately (logging, retries, surfacing to caller, etc.).
  - No impact on other parts of the project outside this method.

  ## Test Plan

  Tests succeed and have tested:

  1. **Happy path streaming**
     - Mock `stream` to emit several responses without error.
     - Confirm:
       - All expected text chunks are sent on `channel`.
       - `SendStream` returns `nil`.
       - `channel` is closed exactly once and terminates after all chunks.

  2. **Stream error mid-way**
     - Mock `stream` to emit some responses and then return an error.
     - Confirm:
       - Text chunks before the error are sent on `channel`.
       - An `"Error: ..."` message is sent on `channel` after the error occurs.
       - `SendStream` returns the same error.
       - `channel` is closed and no data is sent after closure.

  3. **Immediate error (no responses)**
     - Mock `stream` to return an error immediately.
     - Confirm:
       - Only the error message is sent on `channel`.
       - `SendStream` returns the error.
       - `channel` is closed.

  4. **Channel close safety**
     - Use `go test -race` with consumers that read from the channel to verify that no data races or panics occur and the channel is closed exactly once.

  ## Additional Notes

  - The function still uses `context.Background()`. If per-request cancellation is needed, a future improvement would be to accept a `context.Context` parameter so callers can cancel streaming.

commits:
  [{"SHA":"ca96c9c629e8a31fb9e2f3990c63ea34c5f28335","Message":"fix: improve channel management in Gemini streaming method\n\n- Add deferred channel close at function start\n- Return error immediately instead of breaking loop\n- Remove redundant channel close statements from loop\n- Ensure channel closes on all exit paths consistently\n- chore: incoming 1832 changelog entry","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-16T20:58:28Z","Parents":null}]


title: Added concall_summery
body:
  ## What this Pull Request (PR) does

  Create a high level summery of a given conall

author: junaid18183
author_url: https://github.com/junaid18183
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1833
merged_at: 2025-11-25 11:30:24+00:00
created_at: 2025-11-25 22:49:42
commits:
  [{"SHA":"15c8a84b257f22d5e5fd694300e35ca53bd5b374","Message":"Added concall_summery","Author":"Juned Memon","Email":"","Date":"2025-11-17T10:23:25Z","Parents":null}]


title: docs: clarify `--raw` flag behavior for OpenAI and Anthropic providers
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1836
merged_at: 2025-11-18 15:15:01+00:00
created_at: 2025-11-18 15:17:49
body:
  # docs: clarify `--raw` flag behavior for OpenAI and Anthropic providers

  ## Summary

  Updated the description and documentation for the `--raw` flag across the entire codebase to clarify its behavior with different AI model providers. The new description explicitly states that the flag only affects OpenAI-compatible providers, while Anthropic models always use smart parameter selection regardless of this flag setting.

  ## Related Issues

  Closes #1792

  ## Files Changed

  ### Documentation Files
  - **README.md** - Updated command-line help text for the `--raw` flag
  - **web/src/routes/about/README.md** - Updated web documentation to match the main README

  ### Shell Completion Files
  - **completions/_fabric** - Updated Zsh completion description
  - **completions/fabric.fish** - Updated Fish shell completion description

  ### Source Code
  - **internal/cli/flags.go** - Updated the flag description in the Go struct definition

  ### Internationalization Files
  All locale files were updated with the new translated description:
  - **internal/i18n/locales/en.json** - English (base language)
  - **internal/i18n/locales/de.json** - German
  - **internal/i18n/locales/es.json** - Spanish
  - **internal/i18n/locales/fa.json** - Farsi/Persian
  - **internal/i18n/locales/fr.json** - French
  - **internal/i18n/locales/it.json** - Italian
  - **internal/i18n/locales/ja.json** - Japanese
  - **internal/i18n/locales/pt-BR.json** - Portuguese (Brazil)
  - **internal/i18n/locales/pt-PT.json** - Portuguese (Portugal)
  - **internal/i18n/locales/zh.json** - Chinese

  ## Code Changes

  ### Original Description
  ```
  Use the defaults of the model without sending chat options (like temperature etc.) and use the user role instead of the system role for patterns.
  ```

  ### New Description
  ```
  Use the defaults of the model without sending chat options (temperature, top_p, etc.). Only affects OpenAI-compatible providers. Anthropic models always use smart parameter selection to comply with model-specific requirements.
  ```

  ### Key Changes in flags.go
  ```go
  Raw bool `short:"r" long:"raw" yaml:"raw" description:"Use the defaults of the model without sending chat options (temperature, top_p, etc.). Only affects OpenAI-compatible providers. Anthropic models always use smart parameter selection to comply with model-specific requirements."`
  ```

  ## Reason for Changes

  The previous description was ambiguous and potentially misleading about the `--raw` flag's behavior:

  1. **Provider-specific behavior was not documented** - Users might have assumed the flag worked identically across all AI providers
  2. **Incomplete information** - The description mentioned using "user role instead of system role" but didn't clarify this was provider-dependent
  3. **Anthropic-specific handling was undocumented** - Anthropic models have specific parameter requirements that necessitate different handling

  This update provides clarity on:
  - What parameters are affected (temperature, top_p, etc.)
  - Which providers are affected (OpenAI-compatible only)
  - How Anthropic models behave differently (smart parameter selection always enabled)

  ## Impact of Changes

  ### Positive Impacts
  1. **Improved User Understanding** - Users will now understand that the `--raw` flag behaves differently depending on their chosen AI provider
  2. **Better Expectations** - Users working with Anthropic models will know that parameter selection is handled intelligently regardless of the flag
  3. **Reduced Support Burden** - Clear documentation should reduce confusion and support requests about unexpected behavior
  4. **Consistency** - All documentation, shell completions, and translations are now aligned with the actual implementation

  ### Potential Issues
  1. **No Breaking Changes** - This is purely a documentation update; no functional code changes were made
  2. **Translation Quality** - While all translations have been updated, native speakers should review their respective locales to ensure accuracy and natural phrasing

  ## Test Plan

  ### Manual Testing Recommended
  1. **Command-line help verification**:
     ```bash
     fabric --help
     ```
     Verify the `--raw` flag description displays correctly

  2. **Shell completion testing**:
     - Zsh: Test `_fabric` completion with `fabric --raw<TAB>`
     - Fish: Test `fabric.fish` completion with `fabric --raw<TAB>`

  3. **Localization verification**:
     - Test the application with different locale settings (e.g., `LANG=de_DE.UTF-8`)
     - Verify the translated description appears correctly in help text

  4. **Web documentation**:
     - Navigate to the about page in the web interface
     - Verify the updated description is displayed correctly

  ### Functional Testing
  - **OpenAI provider**: Verify that `--raw` flag still prevents sending custom temperature, top_p, etc.
  - **Anthropic provider**: Verify that smart parameter selection is applied regardless of `--raw` flag setting
  - **Other providers**: Test that behavior remains consistent with OpenAI-compatible handling

  ## Additional Notes

  ### Translation Considerations
  All 10 language translations have been updated to reflect the new meaning. The translations maintain the key concepts:
  - Clarification that only specific parameters are affected
  - OpenAI-compatible provider specificity
  - Anthropic's intelligent parameter handling

  ### Maintenance Impact
  Future changes to this flag's behavior should ensure all 14 files are updated consistently:
  - 2 documentation files
  - 2 completion scripts  
  - 1 source code file
  - 10 locale files

commits:
  [{"SHA":"b7fa02d91e24894297e07562b6c049c643b4a6f6","Message":"docs: clarify `--raw` flag behavior for OpenAI and Anthropic providers\n\n- Update `--raw` flag description across all documentation files\n- Clarify flag only affects OpenAI-compatible providers behavior\n- Document Anthropic models use smart parameter selection\n- Remove outdated reference to system/user role changes\n- Update help text in CLI flags definition\n- Translate updated description to all supported locales\n- Update shell completion descriptions for zsh and fish\n- chore: incoming 1836 changelog entry","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-18T11:52:09Z","Parents":null}]


title: refactor: implement i18n support for YouTube tool error messages
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1838
merged_at: 2025-11-20 23:22:23+00:00
created_at: 2025-11-20 23:24:47
body:
  # refactor: implement i18n support for YouTube tool error messages

  ## Summary

  This pull request refactors the `internal/tools/youtube` package to implement internationalization (i18n) support for error messages. It replaces hardcoded English error strings with calls to the localization system, adds the necessary translation keys to all supported locale files, and introduces code improvements for video ID validation and timestamp parsing.

  ## Files Changed

  *   **`cmd/generate_changelog/incoming/1838.txt`**: Added a changelog entry for this PR.
  *   **`internal/i18n/locales/*.json`**: Updated all locale files (de, en, es, fa, fr, it, ja, pt-BR, pt-PT, zh) with new keys prefixed with `youtube_` to support the localized error messages.
  *   **`internal/tools/youtube/youtube.go`**:
      *   Replaced hardcoded error strings with `i18n.T()` calls.
      *   Introduced a helper method `extractAndValidateVideoId` to reduce code duplication.
      *   Refactored `parseSeconds` to handle fractional seconds and edge cases more robustly.
  *   **`internal/tools/youtube/youtube_test.go`**: Added a new test file containing unit tests for `parseSeconds` and `extractAndValidateVideoId`.

  ## Code Changes

  ### Internationalization Implementation
  Throughout `youtube.go`, hardcoded strings have been replaced with localized calls.

  ```go
  // Before
  err = fmt.Errorf("YouTube API key required for comments and metadata. Run 'fabric --setup' to configure")

  // After
  err = fmt.Errorf("%s", i18n.T("youtube_api_key_required"))
  ```

  ### Refactoring: Video ID Validation
  A new helper method `extractAndValidateVideoId` was added to centralize logic previously repeated in `GrabTranscriptForUrl`, `GrabDurationForUrl`, and `Grab`.

  ```go
  func (o *YouTube) extractAndValidateVideoId(url string) (videoId string, err error) {
  	var playlistId string
  	if videoId, playlistId, err = o.GetVideoOrPlaylistId(url); err != nil {
  		return "", err
  	}
  	if videoId == "" && playlistId != "" {
  		return "", fmt.Errorf("%s", i18n.T("youtube_url_is_playlist_not_video"))
  	}
  	if videoId == "" {
  		return "", fmt.Errorf("%s", i18n.T("youtube_no_video_id_found"))
  	}
  	return videoId, nil
  }
  ```

  ### Refactoring: Timestamp Parsing
  The `parseSeconds` function was refactored to better handle fractional seconds (e.g., timestamps from VTT files) and empty strings, alongside i18n integration.

  ```go
  func parseSeconds(secondsStr string) (int, error) {
  	if secondsStr == "" {
  		return 0, fmt.Errorf("%s", i18n.T("youtube_empty_seconds_string"))
  	}
      // ... logic to handle fractional seconds ...
  }
  ```

  ## Reason for Changes

  1.  **Localization**: To provide a better user experience for non-English speakers by localizing error messages related to YouTube functionality (API keys, `yt-dlp` errors, invalid URLs, etc.).
  2.  **Code Quality**: To reduce code duplication regarding URL validation and to improve the robustness of timestamp parsing logic which previously had potential edge case failures.
  3.  **Testing**: To ensure the reliability of the parsing and validation logic via unit tests.

  ## Impact of Changes

  *   **User Experience**: Users will now see error messages in their configured language when using YouTube-related tools.
  *   **Maintainability**: Centralizing the video ID extraction logic makes the codebase easier to maintain.
  *   **Reliability**: The improved `parseSeconds` function handles VTT timestamp formats more reliably, reducing potential runtime errors during transcript processing.

  ## Test Plan

  *   **Unit Tests**: Run the newly created tests in `internal/tools/youtube/youtube_test.go` using `go test ./internal/tools/youtube/...`.
  *   **Manual Verification**:
      *   Configure `fabric` with a non-English locale.
      *   Trigger specific error conditions (e.g., provide an invalid YouTube URL, run without `yt-dlp` installed) and verify that the error messages are displayed in the selected language.
      *   Verify successful transcript extraction for a valid video to ensure no regression in functionality.

  ## Additional Notes

  The `parseSeconds` refactor specifically addresses edge cases where seconds might appear as `.5` or contain floating-point numbers, ensuring they are correctly converted to integers for internal processing.

commits:
  [{"SHA":"6708c7481b0242876bdd10fc84bb6971f8109200","Message":"refactor: implement i18n support for YouTube tool error messages\n\nCHANGES\n- replace hardcoded error strings with i18n translation calls\n- add localization keys for YouTube errors to all locale files\n- introduce `extractAndValidateVideoId` helper to reduce code duplication\n- update timestamp parsing logic to handle localized error formats\n- standardize error handling in `yt-dlp` execution with i18n\n- ensure rate limit and bot detection warnings use localized strings","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-20T22:29:26Z","Parents":null}]


title: Add GitHub Models Provider and Refactor Fetching Fallback Logic
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1839
merged_at: 2025-11-23 08:13:22+00:00
created_at: 2025-11-23 08:15:40
body:
  # Add GitHub Models Provider and Refactor Fetching Fallback Logic

  ## Summary

  This PR adds support for GitHub Models as a new OpenAI-compatible provider and refactors the model fetching logic to implement a robust fallback strategy for providers that return non-standard response formats. The changes centralize direct model fetching within the OpenAI package, upgrade the OpenAI Go SDK dependency, and include comprehensive documentation for setting up GitHub Models with Fabric.

  ## Related Issues

  Closes #1304 

  ## Files Changed

  ### Configuration Files

  **`.vscode/settings.json`**
  - Added `"azureml"` and `"Jamba"` to the spell-checker dictionary for IDE support

  **`go.mod` / `go.sum`**
  - Upgraded `github.com/openai/openai-go` from version `1.8.2` to `1.12.0`
  - This upgrade provides better API compatibility and bug fixes

  ### Documentation

  **`docs/GitHub-Models-Setup.md`** (new file, 700 lines)
  - Comprehensive setup guide for using GitHub Models with Fabric
  - Covers token generation, configuration, available models, rate limits, troubleshooting, and advanced usage
  - Includes step-by-step instructions with examples and best practices

  **`cmd/generate_changelog/incoming/1839.txt`** (new file)
  - Changelog entry documenting the changes in this PR

  ### Internationalization

  **`internal/i18n/locales/*.json`** (10 files modified)
  - Added 6 new error message keys for direct model fetching in all supported languages:
    - `openai_api_base_url_not_configured`
    - `openai_failed_to_create_models_url`
    - `openai_unexpected_status_code_with_body`
    - `openai_unexpected_status_code_read_error_partial`
    - `openai_unexpected_status_code_read_error`
    - `openai_unable_to_parse_models_response`
  - Translations provided for: English, German, Spanish, Persian, French, Italian, Japanese, Portuguese (BR), Portuguese (PT), and Chinese

  ### Core Implementation

  **`internal/plugins/ai/openai/direct_models.go`** (new file)
  - Introduces `FetchModelsDirectly()` function to fetch models via raw HTTP when SDK fails
  - Handles both OpenAI standard format (`{"data": [...]}`) and direct array format (`[...]`)
  - Implements safety measures:
    - Response size limit (10MB max) to prevent memory exhaustion
    - Error response truncation (1024 bytes) for debugging
    - Context support for cancellation
    - 10-second timeout on HTTP requests
  - Includes helper function `extractModelIDs()` to normalize model data

  **`internal/plugins/ai/openai/openai.go`**
  - Modified `ListModels()` to implement fallback strategy
  - Attempts SDK-based fetch first, falls back to `FetchModelsDirectly()` on failure
  - Added debug logging to track fallback behavior

  **`internal/plugins/ai/openai/openai_models_test.go`** (new file)
  - Unit tests for `FetchModelsDirectly()` covering:
    - Direct array format (GitHub Models style)
    - OpenAI standard format
    - Empty model lists
  - Uses `httptest` for reliable testing without external dependencies

  **`internal/plugins/ai/openai_compatible/direct_models_call.go`**
  - Refactored to delegate to centralized `openai.FetchModelsDirectly()`
  - Removed 100+ lines of duplicate code
  - Simplified implementation from local logic to single function call

  **`internal/plugins/ai/openai_compatible/providers_config.go`**
  - Added `ModelsURL` field to `ProviderConfig` for custom model listing endpoints
  - Added `modelsURL` field to `Client` struct
  - Modified `ListModels()` to prioritize custom models URL if configured
  - Added GitHub Models provider configuration:
    - Name: "GitHub"
    - BaseURL: "https://models.github.ai/inference"
    - ModelsURL: "https://models.github.ai/catalog"
    - ImplementsResponses: false

  ## Code Changes

  ### Key Implementation: Direct Model Fetching

  ```go
  // FetchModelsDirectly is used to fetch models directly from the API when the
  // standard OpenAI SDK method fails due to a nonstandard format.
  func FetchModelsDirectly(ctx context.Context, baseURL, apiKey, providerName string) ([]string, error) {
      // Build /models endpoint, make HTTP request
      // Try parsing as OpenAI format: {"data": [...]}
      // Fall back to direct array format: [...]
      // Return error with truncated response if both fail
  }
  ```

  ### Fallback Strategy in openai.Client

  ```go
  func (o *Client) ListModels() (ret []string, err error) {
      // Try SDK first
      if page, err = o.ApiClient.Models.List(context.Background()); err == nil {
          // Extract model IDs and return
          return ret, nil
      }
      
      // SDK failed - fall back to direct fetch
      debuglog.Debug(debuglog.Basic, "SDK Models.List failed for %s: %v, falling back to direct API fetch\n", o.GetName(), err)
      return FetchModelsDirectly(context.Background(), o.ApiBaseURL.Value, o.ApiKey.Value, o.GetName())
  }
  ```

  ## Reason for Changes

  ### Problem Statement
  1. **GitHub Models Support**: Users requested the ability to use GitHub Models (free AI inference API) with Fabric
  2. **Non-Standard Response Formats**: Some OpenAI-compatible providers (GitHub Models, Together AI) return model lists in formats the OpenAI SDK cannot parse
  3. **Code Duplication**: Model fetching logic was duplicated between `openai` and `openai_compatible` packages
  4. **SDK Compatibility**: The existing OpenAI Go SDK version lacked some compatibility improvements

  ### Solution Approach
  1. **Centralized Fallback**: Move direct HTTP fetching logic into the core `openai` package where it can be reused
  2. **Graceful Degradation**: Attempt SDK-based fetch first, fall back only when necessary
  3. **Format Flexibility**: Support both standard OpenAI format and direct array format
  4. **Safety First**: Implement limits and error handling to prevent DoS attacks or memory issues
  5. **Comprehensive Documentation**: Provide step-by-step setup guide for new provider

  ## Impact of Changes

  ### Functional Impact
  ✅ **New Provider Support**: Users can now use GitHub Models (free tier: 50-150 requests/day depending on model)
  ✅ **Improved Reliability**: Model listing works for providers with non-standard response formats
  ✅ **Better Error Messages**: Localized error messages for 10 languages improve debugging
  ✅ **Code Reusability**: Centralized logic reduces maintenance burden

  ### Performance Impact
  - **Minimal overhead**: Fallback only triggered when SDK fails (exceptional case)
  - **Network efficiency**: Uses existing HTTP client patterns with reasonable timeouts
  - **Memory safety**: Response size limits prevent unbounded memory allocation

  ### Backward Compatibility
  ✅ **Fully backward compatible**: No breaking changes to existing provider configurations
  ✅ **Existing providers unaffected**: Standard OpenAI SDK path remains primary
  ✅ **Optional feature**: GitHub Models is opt-in via `fabric --setup`

  ### Security Considerations
  ✅ **Response size limits**: Prevents memory exhaustion attacks (10MB max)
  ✅ **Timeout enforcement**: 10-second timeout prevents hanging requests
  ✅ **Error truncation**: Prevents log flooding with large error responses
  ⚠️ **API key handling**: Keys stored in `.env` file (existing pattern, documented as secure)

  ## Test Plan

  ### Automated Tests
  ```bash
  # Run new unit tests
  go test ./internal/plugins/ai/openai -v -run TestFetchModelsDirectly

  # Expected: All three test cases pass
  # - TestFetchModelsDirectly_DirectArray
  # - TestFetchModelsDirectly_OpenAIFormat  
  # - TestFetchModelsDirectly_EmptyArray
  ```

  ### Manual Testing
  ```bash
  # 1. Configure GitHub Models
  fabric --setup
  # Select [8] GitHub, enter token

  # 2. List models
  fabric --listmodels --vendor GitHub | grep -i gpt-4o
  # Expected: Shows gpt-4o, gpt-4o-mini, etc.

  # 3. Test chat completion
  echo "What is AI?" | fabric --vendor GitHub --model "openai/gpt-4o-mini"
  # Expected: Receives response from GitHub Models

  # 4. Test with pattern
  echo "test content" | fabric --pattern summarize --vendor GitHub --model "openai/gpt-4o-mini"
  # Expected: Pattern executes successfully
  ```

  ### Regression Testing
  - Verified existing OpenAI provider still works
  - Verified other OpenAI-compatible providers (DeepSeek, GrokAI, Together) unaffected
  - Confirmed model listing works for providers using SDK path

  ## Potential Bugs and Concerns

  ### Known Limitations
  1. **Context Propagation**: Currently creates new `context.Background()` instead of propagating caller context
     - **Impact**: Cannot cancel model fetching operations from caller
     - **Mitigation**: TODO comment added for future refactoring
     - **Workaround**: 10-second timeout prevents indefinite hangs

  2. **HTTP Client Reuse**: Creates new `http.Client` for each request
     - **Impact**: Slight performance overhead, doesn't reuse connections
     - **Mitigation**: TODO comment added for future optimization
     - **Workaround**: Model fetching is infrequent operation

  3. **Rate Limit Handling**: GitHub Models has strict rate limits (50-150 req/day)
     - **Impact**: Users may hit limits with frequent `--listmodels` calls
     - **Mitigation**: Documented extensively in setup guide
     - **Workaround**: Cache model list locally (manual process)

  ### Edge Cases
  1. **Very Large Model Lists**: 10MB limit should accommodate ~100k models, but untested at scale
  2. **Malformed JSON**: Both format parsers could fail, returns error with truncated response
  3. **Network Interruptions**: 10-second timeout may be too aggressive on slow connections
  4. **Custom Model Endpoints**: `ModelsURL` field only tested with GitHub Models catalog endpoint

  ### Testing Gaps
  - No integration tests with actual GitHub Models API (requires valid token)
  - No load testing for concurrent model fetching requests
  - No testing of i18n error messages beyond compilation

  ## Additional Notes

  ### Dependencies
  - OpenAI Go SDK upgrade from 1.8.2 → 1.12.0 includes breaking changes in internal types
  - Ensure `go mod tidy` is run after pulling changes
  - No new external dependencies added

  ### Configuration Notes
  GitHub Models requires:
  - Environment variable: `GITHUB_API_KEY` (not `GITHUB_TOKEN`)
  - Base URL: `https://models.github.ai/inference`
  - Models URL: `https://models.github.ai/catalog/models`
  - Personal access token with `models:read` scope

  ### Future Improvements
  1. Implement context propagation throughout Fabric for proper cancellation
  2. Add HTTP client pooling/reuse for better performance
  3. Add model list caching to reduce API calls
  4. Add integration tests with mock/test GitHub Models API
  5. Consider adding rate limit detection and automatic retry logic

  ### Documentation
  The 700-line setup guide includes:
  - Step-by-step token generation with screenshots descriptions
  - Complete model catalog with tier classifications
  - Rate limit explanations and strategies
  - Troubleshooting guide for common errors
  - Advanced usage patterns and examples

commits:
  [{"SHA":"3c728cfacbe87d8a5ffce0d637a08767de355f4d","Message":"feat: add GitHub Models provider and refactor model fetching with direct API fallback\n\n- Add GitHub Models to supported OpenAI-compatible providers list\n- Implement direct HTTP fallback for non-standard model responses\n- Centralize model fetching logic in openai package\n- Upgrade openai-go SDK dependency from v1.8.2 to v1.12.0\n- Remove redundant model fetching code from openai_compatible package\n- Add comprehensive GitHub Models setup documentation (700+ lines)\n- Support custom models URL endpoint per provider configuration\n- Add unit tests for direct model fetching functionality\n- Update internationalization strings for model fetching errors\n- Add VSCode dictionary entries for \"azureml\" and \"Jamba\"","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-22T09:46:25Z","Parents":null}]


title: Replace deprecated bash function in completion script
author: ZackaryWelch
author_url: https://github.com/ZackaryWelch
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1840
merged_at: 2025-11-23 02:42:34+00:00
created_at: 2025-11-23 02:45:33
body:
  Use `_comp_get_words` if available, which was added in bashcompletion 4.12 at the same time `__get_comp_words_by_ref` was deprecated. Latest bashcompletion (4.16) has removed  `__get_comp_words_by_ref`, breaking the completion script entirely on Fedora 42+ and other up to date distros.

commits:
  [{"SHA":"a09686820d9f54120f644976da2886bc6afe21c8","Message":"Replace deprecated bash function in completion script\n\nUse `_comp_get_words` if available, which was added in bash 4.12 at the same time `__get_comp_words_by_ref` was deprecated. Latest bash (5.2) has removed  `__get_comp_words_by_ref`, breaking the completion script entirely on Fedora 42+ and other up to date distros.","Author":"Zackary Welch","Email":"","Date":"2025-11-22T14:04:57Z","Parents":null},{"SHA":"95e60809fafe9d45a52c8905e320c4d535000e96","Message":"chore: incoming 1840 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-23T02:40:14Z","Parents":null}]


title: Implement case-insensitive vendor and model name matching
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1843
merged_at: 2025-11-24 14:10:45+00:00
created_at: 2025-11-24 14:13:17
body:
  # Implement case-insensitive vendor and model name matching

  ## Summary

  This pull request introduces comprehensive case-insensitive handling for Vendor and Model names throughout the application. It ensures that users can specify vendors (e.g., "OpenAI", "openai") and models (e.g., "GPT-4o", "gpt-4o") without worrying about exact casing. Additionally, it adds functionality to filter the model list by vendor in the CLI.

  ## Related Issues

  Closes #1841 
  Closes #1118

  ## Files Changed

  *   **`internal/cli/listing.go`**: Added logic to filter the model list output when the `--vendor` flag is provided.
  *   **`internal/cli/transcribe.go`**: Updated vendor lookup to use the new `FindByName` method instead of direct map access.
  *   **`internal/core/chatter.go`**: Updated `Send` to use the normalized model name for `NeedsRawMode` checks and ensures the `ChatOptions` model reflects the canonical name.
  *   **`internal/core/plugin_registry.go`**: Refactored `GetChatter` to normalize model names against available models before processing and updated vendor lookups to be case-insensitive.
  *   **`internal/plugins/ai/models.go`**: Added helper methods `FilterByVendor` and `FindModelNameCaseInsensitive` to support filtering and normalization.
  *   **`internal/plugins/ai/models_test.go`**: Added unit tests for new case-insensitive lookup and filtering logic; updated existing tests to verify case-insensitive behavior.
  *   **`internal/plugins/ai/vendors.go`**: Modified `VendorsManager` to store and retrieve vendors using lowercase keys, ensuring case-insensitive lookups.
  *   **`internal/plugins/ai/vendors_test.go`**: Added a new test file to verify `VendorsManager` handles case-insensitive lookups and storage correctly.
  *   **`internal/util/groups_items.go`**: Updated `GroupsItemsSelector` methods (`HasGroup`, `FindGroupsByItemFirst`, `FindGroupsByItem`) to use `strings.EqualFold` for comparisons.

  ## Code Changes

  ### Vendor Storage Normalization
  In `internal/plugins/ai/vendors.go`, the `VendorsManager` now forces vendor names to lowercase when storing them in the lookup map. This centralizes the case-insensitivity logic for vendor retrieval.

  ```go
  func (o *VendorsManager) AddVendors(vendors ...Vendor) {
  	for _, vendor := range vendors {
  		name := strings.ToLower(vendor.GetName())
  		o.VendorsByName[name] = vendor // Stored as lowercase
  		o.Vendors = append(o.Vendors, vendor)
  	}
  }

  func (o *VendorsManager) FindByName(name string) Vendor {
  	return o.VendorsByName[strings.ToLower(name)] // Lookup normalized
  }
  ```

  ### Model Name Normalization
  In `internal/core/plugin_registry.go`, the `GetChatter` method now resolves the user-provided model string to the canonical model name defined by the vendor before proceeding with logic checks.

  ```go
  // Normalize model name to match actual available model (case-insensitive)
  // This must be done BEFORE checking vendor availability
  actualModelName := models.FindModelNameCaseInsensitive(model)
  if actualModelName != "" {
      model = actualModelName // Use normalized name for all subsequent checks
  }
  ```

  ### List Filtering
  In `internal/cli/listing.go`, added support for filtering the output based on the vendor flag.

  ```go
  if currentFlags.Vendor != "" {
      models = models.FilterByVendor(currentFlags.Vendor)
  }
  ```

  ## Reason for Changes

  1.  **User Experience**: Users frequently type model names in varying cases (e.g., `GPT-4` vs `gpt-4`). The CLI previously failed if the casing did not match the internal string exactly. This change makes the CLI more robust and user-friendly.
  2.  **Consistency**: Vendor lookups were inconsistent in some areas. Centralizing the lookup via `FindByName` and normalizing keys ensures consistent behavior across the application.
  3.  **Feature Addition**: The ability to filter the list of models by vendor (`fabric --list --vendor openai`) helps users navigate large lists of available models.

  ## Impact of Changes

  *   **Functionality**:
      *   Commands like `fabric --model GPT-4o` will now work even if the internal ID is `gpt-4o`.
      *   Vendor flags are now case-insensitive.
      *   `fabric --list` can now be scoped to specific vendors.
  *   **Performance**: Negligible impact. String normalization and iteration over model lists are lightweight operations relative to the application's core function (network I/O).
  *   **Backward Compatibility**: Fully backward compatible. Existing exact-match commands will continue to work as the normalization handles exact matches correctly.

  ## Test Plan

  *   **Unit Tests**:
      *   `internal/plugins/ai/models_test.go`: Verified `FindModelNameCaseInsensitive` correctly resolves mixed-case queries to canonical names.
      *   `internal/plugins/ai/vendors_test.go`: Verified `VendorsManager` correctly stores and retrieves vendors regardless of input casing.
      *   `internal/util/groups_items.go`: Verified generic selector logic handles case-insensitive grouping.
  *   **Manual Testing**:
      *   Run `fabric --list --vendor OPENAI` and verify it lists OpenAI models.
      *   Run a chat session with `fabric --model GPT-4o` (uppercase) and verify it connects to `gpt-4o`.
      *   Run a chat session with a non-existent model to ensure error handling remains intact.

  ## Additional Notes

  The `internal/util/groups_items.go` changes affect the underlying data structure used for grouping items. This makes the `GroupsItemsSelector` inherently case-insensitive, which benefits any other part of the codebase utilizing this utility.

commits:
  [{"SHA":"817e75853e4e64c361b65ae1feeab8bb9f9a503a","Message":"fix: implement case-insensitive vendor and model name matching across the application\n\n## CHANGES\n\n- Add case-insensitive vendor lookup in VendorsManager\n- Implement model name normalization in GetChatter method\n- Add FilterByVendor method with case-insensitive matching\n- Add FindModelNameCaseInsensitive helper for model queries\n- Update group/item comparison to use case-insensitive checks\n- Store vendors with lowercase keys internally\n- Add comprehensive tests for case-insensitive functionality\n- Fix vendor filtering for model listing command","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-24T13:36:17Z","Parents":null},{"SHA":"5b1a4ab30698822401da3aff30e11cf0b334138d","Message":"chore: incoming 1843 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-24T13:48:53Z","Parents":null}]


title: Correct directory name from `concall_summery` to `concall_summary`
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1844
merged_at: 2025-11-25 22:47:21+00:00
created_at: 2025-11-25 22:49:42
body:
  # Correct directory name from `concall_summery` to `concall_summary`

  ## Summary

  This PR corrects a typo in the pattern directory name from `concall_summery` to `concall_summary` and integrates the new pattern into the project's documentation and metadata files. The change ensures proper naming consistency across the codebase and makes the earnings transcript analysis pattern discoverable through the project's pattern suggestion system.

  ## Files Changed

  ### 1. **cmd/generate_changelog/incoming/1833.txt** (Added)
  - New changelog entry documenting the addition of the `concall_summary` pattern
  - Records PR #1833 by contributor junaid18183
  - Note: The changelog itself contains the original typo "concall_summery" in the description

  ### 2. **data/patterns/concall_summery/system.md → data/patterns/concall_summary/system.md** (Renamed)
  - Renamed the pattern directory from `concall_summery` to `concall_summary`
  - Corrects the spelling error in the pattern name
  - No content changes to the actual system.md file

  ### 3. **data/patterns/pattern_explanations.md** (Modified)
  - Added new entry (#45) for `concall_summary` pattern
  - Description: "Analyzes earnings and conference call transcripts to extract management commentary, analyst Q&A, financial insights, risks, and executive summaries"
  - All subsequent pattern numbers incremented by 1 (from #45-#229 to #46-#230)

  ### 4. **data/patterns/suggest_pattern/system.md** (Modified)
  - Added `concall_summary` to the **ANALYSIS** category pattern list
  - Added `concall_summary` to the **BUSINESS** category pattern list
  - Added `concall_summary` to the **SUMMARIZE** category pattern list
  - Enables the pattern suggestion system to recommend this pattern for relevant queries

  ### 5. **data/patterns/suggest_pattern/user.md** (Modified)
  - Added user-facing description section for `concall_summary`
  - Description: "Analyze earnings call transcripts to extract management insights, financial metrics, and investment implications"

  ### 6. **scripts/pattern_descriptions/extract_patterns.py** (Modified)
  - Updated pattern extraction logic to check local patterns directory first
  - Falls back to `~/.config/fabric/patterns` if local directory doesn't exist
  - Adds robustness to the pattern discovery mechanism

  ```python
  local_patterns_dir = os.path.join(script_dir, "..", "..", "data", "patterns")

  if os.path.exists(local_patterns_dir):
      patterns_dir = local_patterns_dir
  else:
      patterns_dir = os.path.expanduser("~/.config/fabric/patterns")
  ```

  ### 7. **scripts/pattern_descriptions/pattern_descriptions.json** (Modified)
  - Added JSON metadata entry for `concall_summary` pattern
  - Tags: ["SUMMARIZE", "BUSINESS"]
  - Description: "Extract strategic insights from earnings transcripts for investors."

  ### 8. **scripts/pattern_descriptions/pattern_extracts.json** (Modified)
  - Added pattern extract entry with detailed description of the `concall_summary` pattern's purpose and structure
  - Includes information about analyst role, key extraction areas, and output format

  ### 9. **web/static/data/pattern_descriptions.json** (Modified)
  - Mirror of the pattern_descriptions.json changes
  - Ensures web interface has access to the new pattern metadata

  ## Code Changes

  The most significant code change is in the pattern extraction script:

  ```python
  # Old behavior: Only checked user config directory
  patterns_dir = os.path.expanduser("~/.config/fabric/patterns")

  # New behavior: Checks local repository first
  local_patterns_dir = os.path.join(script_dir, "..", "..", "data", "patterns")

  if os.path.exists(local_patterns_dir):
      patterns_dir = local_patterns_dir
  else:
      patterns_dir = os.path.expanduser("~/.config/fabric/patterns")
  ```

  This change improves the development workflow by allowing the script to work with local patterns during development without requiring installation to the user's config directory.

  ## Reason for Changes

  1. **Typo Correction**: The primary reason is to fix the misspelling of "summary" as "summery" in the pattern directory name
  2. **Pattern Integration**: Properly integrate the new earnings call analysis pattern into all relevant documentation and metadata files
  3. **Discoverability**: Ensure users can find and use the pattern through the suggestion system
  4. **Development Workflow**: Improve the pattern extraction script to work with local development directories

  ## Impact of Changes

  **Positive Impacts:**
  - Corrects naming inconsistency that could cause confusion
  - Makes the `concall_summary` pattern fully functional and discoverable
  - Improves development workflow for pattern creators
  - Maintains consistency across documentation, metadata, and code

  **Potential Issues:**
  1. **Breaking Change**: Users who may have already referenced `concall_summery` will need to update to `concall_summary`
  2. **Changelog Inconsistency**: The changelog entry (1833.txt) still references the old misspelled name "concall_summery" in its description, which could cause confusion
  3. **Migration Path**: No explicit migration or deprecation notice for the old pattern name

  ## Test Plan

  To properly test these changes:

  1. Verify the pattern file exists at the correct path: `data/patterns/concall_summary/system.md`
  2. Run the pattern extraction script and confirm `concall_summary` appears in generated JSON files
  3. Test the pattern suggestion system with queries related to earnings calls, business analysis, or summaries
  4. Verify the web interface correctly displays the new pattern
  5. Test that the old path `data/patterns/concall_summery/` no longer exists or returns appropriate errors
  6. Validate that all numbered patterns in pattern_explanations.md are correctly sequenced

  ## Additional Notes

  - The changelog entry (1833.txt) contains the original typo "concall_summery" in its description text, which technically documents the history but may cause confusion
  - Consider adding a deprecation notice or redirect for anyone attempting to use the old `concall_summery` name
  - The pattern extraction script improvement is a valuable side benefit that enhances the development experience
  - All three category tags (ANALYSIS, BUSINESS, SUMMARIZE) are appropriate for this pattern's functionality

commits:
  [{"SHA":"a3a1e616e7a87ceb61acfc8200a9421ae4b8b10d","Message":"fix: correct directory name from `concall_summery` to `concall_summary`\n\n- Rename pattern directory to fix spelling error\n- Add new pattern to explanations documentation\n- Update suggest_pattern system with concall_summary references\n- Include concall_summary in ANALYSIS category mappings\n- Add concall_summary to BUSINESS category listings\n- Append concall_summary to SUMMARIZE category references\n- Update pattern descriptions JSON with new entry\n- Generate pattern extracts for concall_summary functionality\n- Add user documentation for earnings call analysis\n- Include changelog entry for PR #1833","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-25T11:48:05Z","Parents":null},{"SHA":"9e2a35e1502c5defee853d263b2cd3d3bda2fc8b","Message":"chore: incoming 1844 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-11-25T22:43:18Z","Parents":null}]


title: Add Claude Opus 4.5 Support
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1845
merged_at: 2025-11-26 13:38:02+00:00
created_at: 2025-11-26 13:40:22
body:
  # Add Claude Opus 4.5 Support

  ## Summary

  This PR updates several Go dependencies to their latest versions, including the Anthropic SDK and various `golang.org/x` packages. Additionally, it adds support for the newly released Claude Opus 4.5 models in the Anthropic client.

  See this [blog post about Claude Opus 4.5](https://www.anthropic.com/news/claude-opus-4-5).

  ## Files Changed

  | File | Change Type | Description |
  |------|-------------|-------------|
  | `go.mod` | Modified | Updated dependency version constraints |
  | `go.sum` | Modified | Updated dependency checksums |
  | `internal/plugins/ai/anthropic/anthropic.go` | Modified | Added new Claude Opus 4.5 model identifiers |

  ## Code Changes

  ### `go.mod`

  Updated the following direct and indirect dependencies:

  ```diff
  -	github.com/anthropics/anthropic-sdk-go v1.16.0
  +	github.com/anthropics/anthropic-sdk-go v1.19.0

  -	golang.org/x/text v0.28.0
  +	golang.org/x/text v0.31.0

  -	golang.org/x/crypto v0.41.0 // indirect
  +	golang.org/x/crypto v0.45.0 // indirect

  -	golang.org/x/net v0.43.0 // indirect
  +	golang.org/x/net v0.47.0 // indirect

  -	golang.org/x/sync v0.16.0 // indirect
  +	golang.org/x/sync v0.18.0 // indirect

  -	golang.org/x/sys v0.35.0 // indirect
  +	golang.org/x/sys v0.38.0 // indirect
  ```

  ### `internal/plugins/ai/anthropic/anthropic.go`

  Added support for the new Claude Opus 4.5 models:

  ```diff
   		string(anthropic.ModelClaudeOpus4_1_20250805),
   		string(anthropic.ModelClaudeSonnet4_5),
   		string(anthropic.ModelClaudeSonnet4_5_20250929),
  +		string(anthropic.ModelClaudeOpus4_5_20251101),
  +		string(anthropic.ModelClaudeOpus4_5),
  ```

  ## Reason for Changes

  1. **Anthropic SDK Update (v1.16.0 → v1.19.0)**: The SDK upgrade is necessary to gain access to the newly released Claude Opus 4.5 model definitions. This is a feature-driven update that enables users to leverage Anthropic's latest and most capable model.

  2. **golang.org/x Package Updates**: These are routine maintenance updates to keep transitive dependencies current, which typically include:
     - Security patches
     - Bug fixes
     - Performance improvements

  ## Impact of Changes

  - **New Functionality**: Users can now select and use `claude-opus-4-5` and `claude-opus-4-5-20251101` models when interacting with the Anthropic API.
  - **Backward Compatibility**: All existing model selections remain functional; this is an additive change.
  - **Security**: Updated `golang.org/x/crypto` may include security fixes that harden the application.

  ## Potential Bugs / Considerations

  1. **API Compatibility**: The new Claude Opus 4.5 models may have different rate limits, pricing, or context window sizes compared to existing models. Users should be aware of these differences.

  2. **Beta Features**: If Claude Opus 4.5 requires any beta headers (similar to other models in `modelBetas` map), they are not currently configured. This should be verified against Anthropic's documentation.

  3. **Dependency Compatibility**: While unlikely, the significant version jumps in `golang.org/x/*` packages (e.g., `x/crypto` jumping 4 minor versions) could introduce subtle behavioral changes in edge cases.

  ## Test Plan

  1. **Build Verification**: Ensure the project compiles successfully with the updated dependencies.
  2. **Unit Tests**: Run existing test suite to verify no regressions.
  3. **Integration Testing**: 
     - Verify existing Anthropic models continue to work as expected.
     - Test the new Claude Opus 4.5 models with sample prompts to confirm proper API communication.
  4. **Model Listing**: Confirm the new models appear in model enumeration/listing features.

commits:
  [{"SHA":"7eb67ee82db1aef046a9fecfb6f44edecac108c4","Message":"chore: update Go dependencies and add new Claude Opus 4.5 model support\n\n- Upgrade anthropic-sdk-go from v1.16.0 to v1.19.0\n- Bump golang.org/x/text from v0.28.0 to v0.31.0\n- Update golang.org/x/crypto from v0.41.0 to v0.45.0\n- Upgrade golang.org/x/net from v0.43.0 to v0.47.0\n- Bump golang.org/x/sync from v0.16.0 to v0.18.0\n- Update golang.org/x/sys from v0.35.0 to v0.38.0\n- Add Claude Opus 4.5 model variants to Anthropic client\n- chore: incoming 1845 changelog entry","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-26T13:23:08Z","Parents":null}]


title: Improve model name matching for NeedsRaw in Ollama plugin
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1847
merged_at: 2025-11-28 02:14:47+00:00
created_at: 2025-11-28 02:17:17
body:
  # Improve model name matching for NeedsRaw in Ollama plugin

  ## Summary

  This PR makes two minor improvements: it adds a word to the VSCode spell-checker dictionary and fixes a model name matching bug in the Ollama AI plugin by changing from prefix-based matching to substring-based matching.

  ## Related Issues

  Closes #1801

  ## Files Changed

  ### `.vscode/settings.json`
  - Added `"conceptmap"` to the `cSpell.words` dictionary to prevent false-positive spell-check warnings.

  ### `internal/plugins/ai/ollama/ollama.go`
  - Modified the `NeedsRawMode` function to use substring matching instead of prefix matching for model name detection.

  ## Code Changes

  ### `.vscode/settings.json`
  Added a new word to the spell-checker dictionary:
  ```json
  "conceptmap",
  ```

  ### `internal/plugins/ai/ollama/ollama.go`
  The core logic change in the `NeedsRawMode` function:

  **Before:**
  ```go
  ollamaPrefixes := []string{
      "llama3",
      "llama2", 
      "mistral",
  }
  for _, prefix := range ollamaPrefixes {
      if strings.HasPrefix(modelName, prefix) {
          return true
      }
  }
  ```

  **After:**
  ```go
  ollamaSearchStrings := []string{
      "llama3",
      "llama2",
      "mistral",
  }
  for _, searchString := range ollamaSearchStrings {
      if strings.Contains(modelName, searchString) {
          return true
      }
  }
  ```

  ## Reason for Changes

  ### Spell-checker Dictionary Update
  Adding "conceptmap" to the dictionary eliminates unnecessary spell-check warnings for what appears to be a legitimate term used in the codebase.

  ### Model Name Matching Logic
  The original implementation used `strings.HasPrefix()` which only matched model names that started with the specified strings. This approach would fail to identify models with organizational prefixes or other naming conventions. For example:
  - ❌ `HasPrefix` would miss: `"vendor/llama3"`, `"custom-mistral-7b"`, `"org/llama2-chat"`
  - ✅ `Contains` catches: Any model name with these strings anywhere in the name

  The change to `strings.Contains()` provides more flexible matching, ensuring that models with these names in any position will be correctly identified as needing raw mode.

  ## Impact of Changes

  ### VSCode Settings
  - **Impact**: Minimal - improves developer experience by reducing noise from spell-checker
  - **Risk**: None

  ### Ollama Plugin
  - **Impact**: Improves model detection reliability for the `NeedsRawMode` function
  - **Benefit**: Models with non-standard naming conventions (prefixed or suffixed) will now be correctly identified
  - **Risk**: **Potential false positives** - if a model name coincidentally contains "llama2", "llama3", or "mistral" as a substring but isn't actually one of these model families, it will incorrectly return `true`
    - Example: A hypothetical model named `"anthropic-llamabert3"` would match on "llama3"
    - Example: A model named `"mistral-killer-v2"` would match on "mistral"

  ## Test Plan

  ### Manual Testing Recommended:
  1. Test with standard model names: `"llama3"`, `"llama2"`, `"mistral"`
  2. Test with prefixed model names: `"ollama/llama3"`, `"custom/mistral-7b"`
  3. Test with suffixed model names: `"llama3-instruct"`, `"mistral-chat"`
  4. Test with models that should NOT match to ensure no false positives

  ### Unit Test Suggestion:
  Consider adding unit tests for the `NeedsRawMode` function with various model name patterns:
  ```go
  testCases := []struct {
      modelName string
      expected  bool
  }{
      {"llama3", true},
      {"ollama/llama3", true},
      {"llama3-instruct", true},
      {"gpt-4", false},
      {"claude-3", false},
  }
  ```

  ## Additional Notes

  ### Potential Issues to Watch:
  1. **False Positives**: The substring matching is more permissive and could match unintended model names. Consider whether this is acceptable or if a more sophisticated matching strategy (e.g., regex patterns or exact model name registry) would be better.

  2. **Alternative Approach**: If false positives become an issue, consider:
     - Using regex patterns for more precise matching
     - Maintaining a whitelist of exact model names
     - Adding namespace/vendor prefixes to the search strings (e.g., `"ollama/llama3"`)

  3. **Documentation**: It may be helpful to document which model naming conventions are expected to trigger raw mode, especially if users are configuring custom model names.

  The variable renaming from `ollamaPrefixes` to `ollamaSearchStrings` appropriately reflects the changed behavior and improves code readability.

commits:
  [{"SHA":"42fabab3520b430b0b5be1aba71c84ba311a580c","Message":"feat: improve model name matching in Ollama plugin\n\n- Add \"conceptmap\" to VSCode dictionary settings\n- Rename `ollamaPrefixes` variable to `ollamaSearchStrings`\n- Replace `HasPrefix` with `Contains` for model matching\n- Enable substring matching for Ollama model names\n- chore: incoming 1847 changelog entry","Author":"Kayvan Sylvan","Email":"","Date":"2025-11-28T01:53:51Z","Parents":null}]


title: Fix localStorage SSR error in favorites-store
author: zeddy303
author_url: https://github.com/zeddy303
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1848
merged_at: 2025-12-01 11:34:45+00:00
created_at: 2025-12-01 11:37:18
body:
  ## What this Pull Request (PR) does

  This PR fixes a server-side rendering (SSR) error that occurs when running the Fabric web interface in development mode.

  **The Problem:**
  When running `pnpm run dev` and accessing `http://localhost:5173/`, the application crashes with:
  ```
  TypeError: localStorage.getItem is not a function
      at /var/home/zane/git/fabric/web/src/lib/store/favorites-store.ts:5:29
  ```

  **The Fix:**
  Replaced `typeof localStorage !== 'undefined'` checks with SvelteKit's built-in `browser` constant from `$app/environment`. This is the proper SvelteKit way to differentiate between server-side and client-side execution contexts.

  **Changes:**
  - Added import: `import { browser } from '$app/environment';`
  - Replaced all `typeof localStorage !== 'undefined'` checks with `browser`

  This prevents the application from attempting to access `localStorage` during server-side rendering, where it doesn't exist.

  ## Related issues

  N/A - Discovered during fresh setup following the web/README.md instructions.

  ## Screenshots

  Before: Application crashes with `localStorage.getItem is not a function` error
  After: Application loads successfully at http://localhost:5173/

commits:
  [{"SHA":"e4a004cf883f4bed5941e0715509288785b2c5ab","Message":"Fix localStorage SSR error in favorites-store\n\nUse SvelteKit's browser constant instead of typeof localStorage check\nto properly handle server-side rendering. Prevents 'localStorage.getItem\nis not a function' error when running dev server.","Author":"zeddy303","Email":"","Date":"2025-11-29T20:06:54Z","Parents":null},{"SHA":"17cac1358468c3bf08f7437d35e5f8d5b11424f4","Message":"chore: incoming 1848 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-01T10:41:32Z","Parents":null}]


title: Add Z AI provider and glm model support
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1851
merged_at: 2025-12-04 04:19:13+00:00
created_at: 2025-12-04 04:21:35
body:
  # Add "Z AI" provider and glm model support

  ## Summary

  This PR adds support for new AI models and a new AI provider to the system. Specifically, it adds GLM model support to the OpenAI client configuration and introduces "Z AI" as a new OpenAI-compatible provider.

  ## Related Issues

  This is a re-work of #1850 by @dgethings - Thank you for the contribution.

  ## Files Changed

  ### 1. `internal/plugins/ai/openai/openai.go`
  Modified the `NeedsRawMode` function to include GLM models in the list of prefixes that require raw mode processing. Also reordered the model prefixes for logical grouping.

  From the Z Ai documentation about GLM models:

  > Note: The input must not consist of system messages or assistant messages only.

  ### 2. `internal/plugins/ai/openai_compatible/providers_config.go`
  Added a new provider configuration for "Z AI" to the ProviderMap with its API endpoint and response implementation settings.

  ### 3. `internal/plugins/ai/openai_compatible/providers_config_test.go`
  Added a test case to verify the existence of the new "Z AI" provider in the provider configuration.

  ## Code Changes

  ### openai.go
  ```go
  func (o *Client) NeedsRawMode(modelName string) bool {
          openaiModelsPrefixes := []string{
  +               "glm",
  +               "gpt-5",
                  "o1",
                  "o3",
                  "o4",
  -               "gpt-5",
          }
  ```

  ### providers_config.go
  ```go
  +       "Z AI": {
  +               Name:                "Z AI",
  +               BaseURL:             "https://api.z.ai/api/paas/v4",
  +               ImplementsResponses: false,
  +       },
  ```

  ### providers_config_test.go
  ```go
  +               {
  +                       name:     "Existing provider - Z AI",
  +                       provider: "Z AI",
  +                       exists:   true,
  +               },
  ```

  ## Reason for Changes

  These changes were made to:
  1. Add support for GLM (General Language Model) family of models, which require raw mode processing
  2. Enable integration with Z AI, a new OpenAI-compatible AI service provider
  3. Maintain alphabetical order in model prefixes list for better maintainability
  4. Ensure the new provider configuration is properly tested

  ## Impact of Changes

  - Users will now be able to use GLM models through the OpenAI client
  - The system can now connect to Z AI's API endpoint for AI services
  - The test suite verifies the new provider configuration is properly loaded
  - No breaking changes introduced, only additive functionality

  ## Test Plan

  - Verified that the test case for "Z AI" provider passes
  - This PR was written largely by using the Z-AI GLM-6 pattern:
      ```bash
      git diff main | fabric -p write_pull-request -m glm-4.6
      ```
  - Confirmed that GLM models will trigger raw mode when processed
  - Ensured that existing functionality remains unchanged with the reordering of model prefixes

  ## Additional Notes

  The GLM model family is developed by Baidu and is becoming increasingly popular in the AI space. Adding support for these models expands the system's compatibility with more AI services. Z AI appears to be a new entrant in the AI services market, and this addition allows users to leverage their services through our platform's existing OpenAI-compatible interface.

commits:
  [{"SHA":"4b080fd6dd9a466247c2f4007aae353d03f7d42f","Message":"feat: add Z AI provider and glm model support\n\n- Add Z AI provider configuration to ProviderMap\n- Include BaseURL for Z AI API endpoint\n- Add test case for Z AI provider existence\n- Add glm to OpenAI model prefixes list\n- Reorder gpt-5 in model prefixes list\n- Support new Z AI provider in OpenAI compatible plugins","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-04T03:35:05Z","Parents":null}]


title: Add Abacus vendor for ChatLLM models with static model list
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1852
merged_at: 2025-12-04 13:31:34+00:00
created_at: 2025-12-04 13:33:59
body:
  # Add Abacus vendor for ChatLLM models with static model list

  ## Summary

  This PR adds support for the Abacus AI provider to the OpenAI-compatible plugin, including a new static model list mechanism for providers that don't support dynamic model discovery.

  ## Related Issues

  Closes #1800 

  ## Files Changed

  #### `.vscode/settings.json`
  - Added two new dictionary entries: "kimi" and "qwen" to the `cSpell.words` array
  - These additions support spell-checking for new model names and providers referenced in the codebase

  #### `internal/plugins/ai/openai_compatible/providers_config.go`
  - Added new `Abacus` provider configuration to `ProviderMap`
  - Introduced `getStaticModels()` method to handle static model lists
  - Modified `ListModels()` method to check for static model list prefix ("static:")
  - Added `fmt` package import for error formatting

  #### `internal/plugins/ai/openai_compatible/providers_config_test.go`
  - Added test case for the new Abacus provider to verify it exists in the provider map

  ## Code Changes

  ### Static Model List Mechanism

  The most significant change is the introduction of a static model list handler in `ListModels()`:

  ```go
  // If a custom models URL is provided, handle it
  if c.modelsURL != "" {
      // Check for static model list
      if strings.HasPrefix(c.modelsURL, "static:") {
          return c.getStaticModels(c.modelsURL)
      }
      // ... existing code for dynamic model fetching
  }
  ```

  This enables providers to specify a static list of models using a special `static:` prefix instead of requiring an API endpoint for model discovery.

  ### New getStaticModels Method

  A new method was added to retrieve predefined model lists:

  ```go
  func (c *Client) getStaticModels(modelsKey string) ([]string, error) {
      switch modelsKey {
      case "static:abacus":
          return []string{
              "route-llm",
              "gpt-4o-2024-11-20",
              // ... 50+ additional models
          }, nil
      default:
          return nil, fmt.Errorf("unknown static model list: %s", modelsKey)
      }
  }
  ```

  ### Abacus Provider Configuration

  Added new provider entry in `ProviderMap`:

  ```go
  "Abacus": {
      Name:                "Abacus",
      BaseURL:             "https://routellm.abacus.ai/v1/",
      ModelsURL:           "static:abacus",
      ImplementsResponses: false,
  },
  ```

  ## Reason for Changes

  The changes were made to:

  1. **Support Abacus AI provider**: Integrate Abacus AI's RouteLL M service which provides access to multiple AI models through a unified API
  2. **Handle providers without model discovery APIs**: Some providers don't expose a `/models` endpoint or have non-standard model listing mechanisms. The static model list approach provides a fallback solution
  3. **Maintain code consistency**: Abacus follows the same pattern as other OpenAI-compatible providers in the codebase

  ## Impact of Changes

  ### Positive Impacts
  - Users can now access 50+ AI models through the Abacus AI provider, including models from OpenAI, Anthropic, Meta, Google, Alibaba, DeepSeek, and others
  - The static model list mechanism is extensible and can be reused for other providers that don't support dynamic model discovery
  - No breaking changes to existing functionality

  ### Potential Issues
  1. **Model list maintenance**: The static model list needs manual updates when Abacus adds or removes models. This could lead to outdated model references if not maintained regularly
  2. **No validation**: The code doesn't validate whether the static models are actually available through the Abacus API at runtime
  3. **Hardcoded models**: Having 50+ hardcoded model names increases the binary size slightly and creates a maintenance burden
  4. **Error handling**: If a user tries to use a model from the static list that Abacus no longer supports, they'll receive an error at request time rather than during model listing

  ## Test Plan

  1. **Unit test coverage**: Added test case in `providers_config_test.go` verifying the Abacus provider exists in the provider map
  2. **Manual testing should include**:
     - Selecting the Abacus provider and verifying the static model list is returned
     - Attempting to use various models from the static list with actual API calls
     - Verifying error handling when an invalid static key is provided
  3. **Integration testing**: Test the complete flow of selecting Abacus provider, choosing a model, and making API requests

  ## Additional Notes

  - The Abacus provider uses `ImplementsResponses: false`, which means it follows the legacy response handling approach
  - Future enhancement: Could implement a hybrid approach that tries dynamic discovery first and falls back to the static list

commits:
  [{"SHA":"894459ddec9eed97618f954bf93e531c33400fc9","Message":"feat: add static model support and register Abacus provider\n\nCHANGES\n\n- feat: detect modelsURL starting with 'static:' and route\n- feat: implement getStaticModels returning curated Abacus model list\n- feat: register Abacus provider with ModelsURL 'static:abacus'\n- chore: add fmt import for error formatting in provider code\n- test: extend provider tests to include Abacus existence\n- chore: update .vscode settings add 'kimi' and 'qwen' contributors","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-04T11:13:27Z","Parents":null}]


title: feat: add image attachment support for Ollama vision models
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1855
merged_at: 2025-12-08 00:07:34+00:00
created_at: 2025-12-08 00:10:01
body:
  # feat: add image attachment support for Ollama vision models

  ## Summary

  - Add image attachment support for Ollama vision models (llama3.2-vision, llava, etc.)
  - Fix issue where `-a` flag was ignored when using Ollama provider
  - Replace debug printf with proper logging using internal/log package

  ## Related Issues

  Fixes #1749

  ## Test plan

  - [ ] Build the binary: `go build ./cmd/fabric`
  - [ ] Test with local image: `echo "What is in this picture?" | ./fabric -m llama3.2-vision:latest -a ./test_image.png`
  - [ ] Test with HTTP image URL: `./fabric "Describe this image" -m llava -a https://example.com/image.jpg`
  - [ ] Verify dry-run shows image attachment: `./fabric "What is this?" -a ./image.png -m llama3.2-vision:latest --dry-run`
  - [ ] Run tests: `go test ./...`

  ## Technical Details

  The Ollama API expects images as raw bytes in the Images field of each message:

  ```json
  {
    "model": "llama3.2-vision:latest",
    "messages": [{
      "role": "user",
      "content": "What is in this picture?",
      "images": ["<raw bytes>"]
    }]
  }
  ```

  The CLI already handles local file paths by converting them to base64 data URLs in internal/cli/flags.go. This implementation decodes those data URLs back to raw bytes for the Ollama API.

commits:
  [{"SHA":"4badfecadb1d516d13aa4a798f27551e1ce44f72","Message":"feat: add multi-modal image support to Ollama client\n\n## CHANGES\n\n- Add base64 and io imports for image handling\n- Store httpClient separately in Client struct for reuse\n- Convert createChatRequest to return error for validation\n- Implement convertMessage to handle multi-content chat messages\n- Add loadImageBytes to fetch images from URLs\n- Support base64 data URLs for inline images\n- Handle HTTP image URLs with context propagation\n- Replace debug print with proper debuglog usage","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-07T23:48:36Z","Parents":null},{"SHA":"922df52d0ce49c08e940876c30ca367b2ec1501f","Message":"chore: incoming 1855 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-08T00:00:59Z","Parents":null}]


title: Add support for new ClaudeHaiku 4.5 models
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1856
merged_at: 2025-12-08 00:33:51+00:00
created_at: 2025-12-08 00:36:15
body:
  # Add support for new ClaudeHaiku 4.5 models

  ## Summary

  This PR adds support for two new Claude Haiku 4.5 model variants to the Anthropic plugin's available model list. The changes enable users to access the latest Haiku models when interacting with the AI plugin.

  ## Related issues

  closes #1854 

  ## Files Changed

  **`internal/plugins/ai/anthropic/anthropic.go`**
  - Added two new Claude Haiku model variants to the model list initialization in the `NewClient()` function.

  ## Code Changes

  The following lines were added to the `NewClient()` function's model list (after the existing Opus 4.5 model entry):

  ```go
  string(anthropic.ModelClaudeHaiku4_5),
  string(anthropic.ModelClaudeHaiku4_5_20251001),
  ```

  These additions extend the existing model slice that previously included Claude Sonnet and Opus variants, now making the lightweight Haiku models available for selection.

  ## Reason for Changes

  The Anthropic API has introduced new Claude Haiku 4.5 model variants with improved capabilities. By adding these models to the available options, users of this plugin can now:
  - Access more model choices suited to different use cases
  - Leverage the Haiku model's efficiency and cost-effectiveness for appropriate workloads
  - Benefit from the latest model versions released by Anthropic

  ## Impact of Changes

  - **Functionality**: Expands the range of available AI models without breaking existing functionality. Users previously using other models will see no changes, while new users can now select Haiku variants.
  - **Performance**: No performance impact on the plugin itself. Model selection happens at runtime, and these additions are simple string constants.
  - **Backward Compatibility**: Fully backward compatible. Existing code referencing other models will continue to work without modification.

  ## Test Plan

  1. Verify that the new models appear in the available model list when calling `NewClient()`.
  2. Test that model selection works correctly when explicitly choosing either Haiku 4.5 variant.
  3. Ensure existing model selections (Sonnet, Opus) continue to function as before.
  4. Validate that the model identifiers correctly map to Anthropic API endpoints.

  ## Additional Notes

  - The addition follows the existing naming convention and pattern established in the codebase.
  - Both Haiku variant models are added together, suggesting they were released as a pair (generic version and dated version for pinning).
  - No changes to model configuration, beta features, or other plugin logic are required for basic support of these models.

commits:
  [{"SHA":"b1eb7a82d981f017b9860a33a690b2f547ce6d44","Message":"feat: add support for new ClaudeHaiku models in client\n\n### CHANGES\n\n- Add `ModelClaudeHaiku4_5` to supported models\n- Add `ModelClaudeHaiku4_5_20251001` to supported models","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-08T00:21:18Z","Parents":null},{"SHA":"cb29a0d60627c34b234c5f36ac6d30d44e07c196","Message":"chore: incoming 1856 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-08T00:30:17Z","Parents":null}]


title: fix: allow resetting required settings without validation errors
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1860
merged_at: 2025-12-11 10:47:17+00:00
created_at: 2025-12-11 10:49:47
body:
  #  fix: allow resetting required settings without validation errors

  ## Summary

  This PR refactors the plugin setup flow to properly handle the "reset" command for required configuration fields. The changes introduce a distinction between explicit value resets and missing required values, allowing users to intentionally clear configuration values without triggering validation errors during the interactive setup process.

  ## Related Issues

  Close #1858

  ## Files Changed

  ### `internal/plugins/plugin.go`
  - Modified the `Setup()` method to call `ConfigureCustom` instead of `Configure` after setup questions
  - Enhanced `Ask()` method to track whether a user explicitly requested a reset
  - Refactored `OnAnswer()` method to delegate to a new `OnAnswerWithReset()` method
  - Added new `OnAnswerWithReset()` method that conditionally skips validation when a value is explicitly reset

  ### `internal/plugins/plugin_test.go`
  - Added `TestSetupQuestion_Ask_Reset()` to verify that resetting a required field doesn't produce errors
  - Added comprehensive `TestSetupQuestion_OnAnswerWithReset()` with multiple test cases covering reset scenarios, empty answers, and valid answers on required fields

  ## Code Changes

  ### Plugin Setup Flow (`plugin.go`)

  **Modified Setup() to use ConfigureCustom:**
  ```go
  // After Setup, run ConfigureCustom if present, but skip re-validation
  // since Ask() already validated user input (or allowed explicit reset)
  if o.ConfigureCustom != nil {
      err = o.ConfigureCustom()
  }
  ```
  This change calls `ConfigureCustom` instead of `Configure`, avoiding redundant validation after the user has already answered setup questions.

  **Enhanced Ask() to track reset intent:**
  ```go
  isReset := strings.ToLower(answer) == AnswerReset
  // ...
  err = o.OnAnswerWithReset(answer, isReset)
  ```
  The method now captures whether the user explicitly typed "reset" and passes this context downstream.

  **New OnAnswerWithReset() method:**
  ```go
  func (o *SetupQuestion) OnAnswerWithReset(answer string, isReset bool) (err error) {
      // ... existing validation logic ...
      
      // Skip validation when explicitly resetting a value - the user intentionally
      // wants to clear the value even if it's required
      if isReset {
          return nil
      }
      err = o.IsValidErr()
      return
  }
  ```
  This new method allows validation to be bypassed when a value is explicitly reset, while maintaining validation for all other cases.

  ### Test Coverage (`plugin_test.go`)

  Added comprehensive test coverage for the reset functionality:
  - Tests that resetting a required field doesn't trigger validation errors
  - Tests that empty answers (non-reset) on required fields still trigger validation errors
  - Tests that valid answers continue to work as expected

  ## Reason for Changes

  The previous implementation treated the "reset" command the same as an empty answer, causing validation errors when users tried to clear required configuration fields. This created a poor user experience where users couldn't reset values during interactive setup without encountering errors.

  The changes address this by:
  1. **Distinguishing intent**: Differentiating between "user wants to reset" vs "user provided no value"
  2. **Skipping validation on explicit resets**: Allowing users to intentionally clear values without validation errors
  3. **Maintaining validation for other cases**: Preserving the existing validation behavior for non-reset scenarios

  ## Impact of Changes

  **Positive Impacts:**
  - Improved UX: Users can now successfully reset required configuration values during interactive setup
  - Clearer code semantics: The distinction between reset and empty answers is now explicit in the code
  - Better separation of concerns: `ConfigureCustom` is called after setup instead of `Configure`, avoiding redundant validation

  **Potential Issues to Watch:**
  1. **State consistency**: If `ConfigureCustom` implementations rely on validation having already occurred, they should continue to work since `Ask()` performs validation (except on explicit resets)
  2. **Plugin compatibility**: Plugins that override `OnAnswer()` will continue to work, but won't benefit from the reset-without-validation behavior unless they adopt `OnAnswerWithReset()`
  3. **Empty vs reset semantics**: Downstream code that checks for empty values should be aware that empty values can now exist on required fields if explicitly reset

  ## Test Plan

  The changes include comprehensive unit tests:
  - `TestSetupQuestion_Ask_Reset()`: Verifies that typing "reset" on a required field clears the value without error
  - `TestSetupQuestion_OnAnswerWithReset()`: Tests multiple scenarios including explicit resets, empty answers, and valid answers on required fields

  **Manual Testing Recommendations:**
  1. Run interactive setup for a plugin with required fields
  2. Enter "reset" for a required field that has an existing value
  3. Verify no validation error occurs and the value is cleared
  4. Test that pressing Enter without typing anything on a required empty field still produces a validation error

  ## Additional Notes

  - The change maintains backward compatibility by keeping the original `OnAnswer()` method as a wrapper that calls `OnAnswerWithReset()` with `isReset=false`
  - The comment in `Setup()` explains why `ConfigureCustom` is called instead of `Configure`, helping future maintainers understand the design decision
  - The validation skip logic includes a clear comment explaining that reset is an intentional user action, not an oversight

commits:
  [{"SHA":"5b723c9e923394d99734a53d56af52f4f6145b4f","Message":"fix: allow resetting required settings without validation errors\n\nCHANGES\n- update `Ask` to detect reset command and bypass validation\n- refactor `OnAnswer` to support new `isReset` parameter logic\n- invoke `ConfigureCustom` in `Setup` to avoid redundant re-validation\n- add unit tests ensuring required fields can be reset\n- add incoming 1860 changelog entry","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-10T03:02:19Z","Parents":null}]


title: fix: write CLI and streaming errors to stderr
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1866
merged_at: 2025-12-13 08:09:09+00:00
created_at: 2025-12-13 08:11:50
body:
  # fix: write CLI and streaming errors to stderr

  ## Summary

  Route error output to **stderr** instead of **stdout** in two places: the CLI entrypoint and the Anthropic streaming client error reporting. This aligns with common CLI conventions and improves composability with pipes/redirects.

  ## Related Issues

  Closes #1865

  ## Files Changed

  - `cmd/fabric/main.go`
    - Print top-level CLI errors to `os.Stderr` rather than stdout.
  - `internal/plugins/ai/anthropic/anthropic.go`
    - Import `os` and print streaming errors to `os.Stderr` rather than stdout.

  ## Code Changes

  ### `cmd/fabric/main.go`

  Changed error printing to stderr when `cli.Cli(version)` returns an error that is not help output:

  ```go
  if err != nil && !flags.WroteHelp(err) {
      fmt.Fprintf(os.Stderr, "%s\n", err)
      os.Exit(1)
  }
  ```

  Previously this used `fmt.Printf(...)`, which writes to stdout.

  ### `internal/plugins/ai/anthropic/anthropic.go`

  Added `os` import and updated the stream error log to go to stderr:

  ```go
  if stream.Err() != nil {
      fmt.Fprintf(os.Stderr, "Messages stream error: %v\n", stream.Err())
  }
  ```

  Previously this used `fmt.Printf(...)`, which writes to stdout.

  ## Reason for Changes

  Errors should generally be emitted on **stderr** so that:
  - stdout can be safely piped/consumed as “data output” (e.g., `fabric ... | jq ...`)
  - users can redirect output cleanly (e.g., `> out.txt` without capturing errors, or `2> err.txt`)
  - tooling and scripts can distinguish normal output from failure diagnostics

  ## Impact of Changes

  - No behavioral change to exit codes or control flow.
  - Improves UX and correctness for shell pipelines and output redirection.
  - Potential minor downstream impact: any consumer that (incorrectly) parsed errors from stdout will need to read from stderr instead.

  ## Test Plan

  - Run a command that triggers a CLI error and verify it appears on stderr:
    - `fabric <invalid args> 1>stdout.txt 2>stderr.txt` (expect error in `stderr.txt`, empty/unchanged `stdout.txt`)
  - Trigger an Anthropic streaming error (e.g., invalid credentials/network interruption) and verify:
    - normal streamed output remains on stdout (if applicable)
    - `Messages stream error: ...` is written to stderr

  ## Additional Notes

  - The Anthropic stream error print remains non-fatal (it logs and closes the channel). This PR does not change error propagation semantics—only the output stream used for diagnostics.

commits:
  [{"SHA":"deb59bdd214afc92a7584841a2008c9bf1c6b501","Message":"fix: write CLI and streaming errors to stderr\n\n## CHANGES\n- Route CLI execution errors to standard error output\n- Print Anthropic stream errors to stderr consistently\n- Add os import to support stderr error writes\n- Preserve help-output suppression and exit behavior","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-13T08:02:44Z","Parents":null},{"SHA":"f1ffd6ee29da7a8806583a69a43a44c47ba3fcf6","Message":"chore: incoming 1866 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-13T08:07:08Z","Parents":null}]


title: chore: update flake
body:
  ## What this Pull Request (PR) does
  Updates flake inputs.

  ## Related issues
  closes #1861

author: jaredmontoya
author_url: https://github.com/jaredmontoya
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1867
merged_at: 2025-12-14 08:11:46+00:00
created_at: 2025-12-14 08:14:21
commits:
  [{"SHA":"d149c62a373e50b5b902b5453c49fe3f8ebc9167","Message":"chore: update flake","Author":"jaredmontoya","Email":"","Date":"2025-12-13T19:30:31Z","Parents":null},{"SHA":"3bc1150da46adfb2472e860fcf66710d2d2fc648","Message":"Merge branch 'main' into update-flake","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-14T08:07:51Z","Parents":null},{"SHA":"71fb3fea7ea04a1372ad7987f440e18e8864c641","Message":"chore: incoming 1867 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-14T08:08:33Z","Parents":null}]


title: Web UI: upgrade pdfjs and add SSR-safe dynamic PDF worker init
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1870
merged_at: 2025-12-15 06:00:41+00:00
created_at: 2025-12-15 06:03:18
body:
  # Web UI: upgrade pdfjs and add SSR-safe dynamic PDF worker init

  ## Summary

  This PR updates the web app’s PDF tooling to `pdfjs-dist@5.x` and hardens client-only initialization to prevent SSR/runtime crashes. It also adjusts PDF worker configuration to load from a CDN, and fixes several `localStorage` usages to be gated behind SvelteKit’s `browser` flag. Minor formatting/consistency changes were applied in the chat service and store.

  ## Related Issues

  Closes #1488 

  ## Files Changed

  - **`.vscode/settings.json`**
    - Adds `skeletonlabs` to the spellchecker dictionary.

  - **`web/package.json`**
    - Bumps:
      - `pdfjs-dist` from `^4.2.67` → `^5.4.449`
      - `patch-package` from `^8.0.0` → `^8.0.1`

  - **`web/pnpm-lock.yaml`**
    - Updates lockfile for the dependency bumps above.
    - Notable transitive shift: `pdfjs-dist` now uses `@napi-rs/canvas` instead of `canvas`/`node-pre-gyp` plumbing, and `patch-package` updates transitive deps like `fs-extra` and `tmp`.

  - **`web/src/lib/services/PdfConversionService.ts`**
    - Removes top-level `pdfjs-dist` import and introduces dynamic import + lazy initialization to avoid SSR issues with `pdfjs-dist@5+`.

  - **`web/src/lib/services/pdf-config.ts`**
    - Changes worker configuration from a local `/pdf.worker.min.mjs` file to a versioned CDN worker URL based on the installed `pdfjs-dist` version.
    - Avoids top-level `pdfjs-dist` imports; dynamically imports inside `initialize()`.

  - **`web/src/lib/store/chat-store.ts`**
    - Uses SvelteKit `browser` to gate `localStorage` reads/writes (prevents SSR `ReferenceError: localStorage is not defined`).

  - **`web/src/lib/services/ChatService.ts`**
    - Mostly formatting/import ordering; no functional changes intended.

  ## Code Changes

  ### 1) `pdfjs-dist` v5 compatibility via dynamic imports

  `pdfjs-dist@5+` can touch browser APIs at import-time, so importing it at module top-level can break SSR builds or server-side evaluation. `PdfConversionService` now lazily initializes PDF.js the first time a conversion is requested:

  ```ts
  // pdfjs-dist v5+ requires browser APIs at import time, so we use dynamic imports
  let pdfjs: typeof import("pdfjs-dist") | null = null;

  private async ensureInitialized(): Promise<typeof import("pdfjs-dist")> {
    if (!pdfjs) {
      pdfjs = await import("pdfjs-dist");
      const pdfConfig = (await import("./pdf-config")).default;
      await pdfConfig.initialize();
    }
    return pdfjs;
  }
  ```

  This ensures:
  - Server-side code paths don’t evaluate `pdfjs-dist` at import time.
  - Worker configuration is done only when needed and only in the browser.

  ### 2) Worker now loaded from CDN instead of a repo/static file

  `pdf-config.ts` now sets the worker source to a versioned `unpkg.com` URL:

  ```ts
  const pdfjs = await import("pdfjs-dist");
  const { GlobalWorkerOptions, version } = pdfjs;

  const workerSrc = `https://unpkg.com/pdfjs-dist@${version}/build/pdf.worker.min.mjs`;
  GlobalWorkerOptions.workerSrc = workerSrc;
  ```

  This removes the need to ship and maintain `/public/pdf.worker.min.mjs` (or rely on bundling third-party minified worker artifacts).

  ### 3) Fix SSR hazards in chat message persistence

  The chat store was previously guarded when using `localStorage` with `typeof localStorage !== 'undefined'`, but still referenced it during module initialization in a way that can be brittle across SSR tooling. It now uses SvelteKit’s `browser` flag consistently:

  ```ts
  import { browser } from "$app/environment";

  const initialMessages = browser
    ? JSON.parse(localStorage.getItem(MESSAGES_STORAGE_KEY) || "[]")
    : [];

  if (browser) {
    messageStore.subscribe(($messages) => {
      localStorage.setItem(MESSAGES_STORAGE_KEY, JSON.stringify($messages));
    });
  }
  ```

  This prevents SSR/runtime crashes when the store module is imported server-side.

  ### 4) Dependency bumps

  - `pdfjs-dist` → `5.4.449` (notably updates Node engine expectations in the package metadata; see notes below).
  - `patch-package` → `8.0.1` (lockfile reflects updated transitive deps).

  ## Reason for Changes

  - **Unblock / stabilize PDF conversion after upgrading PDF.js**: `pdfjs-dist@5+` is more strict about environment assumptions and can break SSR if imported at module scope.
  - **Improve deployment ergonomics**: Using a CDN-hosted worker avoids bundling a large minified worker file in the repo and reduces config drift between local/public assets and installed `pdfjs-dist` versions.
  - **Prevent SSR errors in chat persistence**: Using `browser` is the recommended SvelteKit pattern to avoid touching browser-only APIs on the server.

  ## Impact of Changes

  - **PDF conversion**
    - Should continue to work in the browser, with worker loading from CDN.
    - SSR/server builds should stop failing due to import-time browser API usage in `pdfjs-dist`.

  - **Chat**
    - Message persistence behavior should remain the same in the browser.
    - Server-side rendering should no longer risk `localStorage` access issues when importing the store.

  - **Build/runtime environment**
    - `pdfjs-dist@5.4.449` advertises stricter Node engine requirements in its metadata (>=20.16 or >=22.3). Even if the app runs PDF conversion only in the browser, some CI/install environments may enforce engines. This should be verified in your pipeline.

  ## Test Plan

  1. **Install & build**
     - `pnpm install`
     - `pnpm -C web build` (or your repo build command)
     - Ensure no SSR/import-time crashes referencing `window`, `document`, or `localStorage`.

  2. **Run locally**
     - `pnpm -C web dev`
     - Open the PDF conversion feature and upload a known PDF.
     - Confirm conversion completes and no worker-related errors appear in the browser console/network panel.
       - Verify the worker is fetched from `https://unpkg.com/pdfjs-dist@<version>/build/pdf.worker.min.mjs`.

  3. **Chat regression**
     - Send chat messages and confirm streaming still works.
     - Refresh the page and confirm messages restore from localStorage.
     - Confirm no SSR console errors on initial page render.

  ## Additional Notes / Potential Risks

  - **CDN dependency for worker**: PDF conversion now depends on `unpkg.com` availability and network access. If the app must work offline or in restricted environments, consider a fallback to a locally hosted worker.
  - **CSP considerations**: If the app enforces a strict Content Security Policy, `unpkg.com` may be blocked unless explicitly allowed.
  - **Node engine enforcement**: Some environments enforce `engines` during install; `pdfjs-dist@5.4.449` may require CI to run on Node 20.16+ (or relax engine checks if appropriate).
  - **Initialization timing**: PDF.js config is now initialized lazily. If any other code paths assume worker config is set earlier, they should call the same initialization method (currently only `PdfConversionService` does).

commits:
  [{"SHA":"4c2b38ca53ddfb7c9c1a802c80d3a727e845bbe0","Message":"feat: upgrade pdfjs and add SSR-safe dynamic PDF worker init\n\n- Upgrade `pdfjs-dist` to v5 with new engine requirement\n- Dynamically import PDF.js to avoid SSR import-time crashes\n- Configure PDF worker via CDN using runtime PDF.js version\n- Update PDF conversion pipeline to use lazy initialization\n- Guard chat message localStorage persistence behind browser checks\n- Reformat ChatService with consistent imports and typings\n- Bump `patch-package` and refresh pnpm lock dependency graph\n- Add `skeletonlabs` to VSCode spellcheck dictionary","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-15T00:12:23Z","Parents":null},{"SHA":"0025466e4eb2ded05883987a29ce01a09209e09a","Message":"chore: incoming 1870 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-15T05:57:06Z","Parents":null}]


title: refactor: replace interface{} with any across codebase
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1874
merged_at: 2025-12-16 06:28:16+00:00
created_at: 2025-12-16 06:30:55
body:
  ## Summary

  This PR modernizes the Go codebase by replacing the verbose `interface{}` type with the equivalent `any` type alias introduced in Go 1.18. This is a mechanical refactoring that improves code readability without changing any functionality.

  The credit goes to @philoserf for pointing out this gap. Thank you, @philoserf.

  ## Related Issues

  #1873

  ## Files Changed

  ### Core Application Files

  #### `cmd/code_helper/code.go`
  - Replaced `interface{}` with `any` in slice and map type declarations
  - Updated `[]interface{}` → `[]any`
  - Updated `map[string]interface{}` → `map[string]any`

  #### `cmd/generate_changelog/internal/github/client.go`
  - Updated GraphQL query variables map from `map[string]interface{}` to `map[string]any`

  ### Internal Packages

  #### `internal/log/log.go`
  - Updated variadic function parameters from `...interface{}` to `...any` in `Debug()` and `Log()` functions

  #### `internal/plugins/ai/anthropic/oauth_test.go`
  - Updated test helper function signature: `mockTokenServer()` parameter from `map[string]interface{}` to `map[string]any`
  - Updated type assertions throughout test cases

  #### `internal/plugins/ai/lmstudio/lmstudio.go`
  - Updated JSON payload maps from `map[string]interface{}` to `map[string]any`
  - Updated JSON unmarshaling type assertions for streaming and non-streaming responses

  #### `internal/plugins/ai/ollama/ollama.go`
  - Updated options map from `map[string]interface{}` to `map[string]any`

  #### `internal/plugins/ai/openai/openai_image_test.go`
  - Updated test case expected values from `map[string]interface{}` to `map[string]any`

  #### `internal/plugins/db/fsdb/storage.go`
  - Updated JSON serialization function parameters from `interface{}` to `any`
  - Affects `SaveAsJson()` and `LoadAsJson()` methods

  #### `internal/plugins/template/extension_executor_test.go`
  - Updated test helper function `createExtension()` parameter from `map[string]interface{}` to `map[string]any`
  - Updated test case config maps throughout

  #### `internal/plugins/template/extension_registry.go`
  - Updated `ExtensionDefinition.Config` field from `map[string]interface{}` to `map[string]any`
  - Updated return types for `GetFileConfig()` method

  #### `internal/plugins/template/template.go`
  - Updated debug function signature from `...interface{}` to `...any`

  #### `internal/server/models.go`
  - Updated response map from `map[string]interface{}` to `map[string]any`

  ### Documentation

  #### `docs/CONTRIBUTING.md`
  - Added new section "Pull Request Guidelines" emphasizing focused, minimal PRs
  - Explains reviewability concerns, git history pollution, merge conflicts, and risk
  - Provides guidance on breaking large changes into logical slices
  - Includes examples of acceptable vs. unacceptable PR scope

  ## Code Changes

  All changes follow the same pattern of replacing `interface{}` with `any`. For example:

  **Before:**
  ```go
  var data []interface{}
  reportItem := map[string]interface{}{
      "type": "report",
  }
  func Debug(l Level, format string, a ...interface{}) {
  ```

  **After:**
  ```go
  var data []any
  reportItem := map[string]any{
      "type": "report",
  }
  func Debug(l Level, format string, a ...any) {
  ```

  ## Reason for Changes

  1. **Modernization**: The `any` type alias was introduced in Go 1.18 (March 2022) as a more readable alternative to `interface{}`. We are using go 1.25+ at this point.

  2. **Readability**: `any` is more concise and clearer in intent, especially in complex type declarations like `map[string]any` vs `map[string]interface{}`.

  3. **Consistency**: Standardizing on `any` throughout the codebase provides visual consistency and reduces cognitive load when reading code.

  ## Impact of Changes

  ### Positive Impacts
  - **Zero functional changes**: `any` is a direct type alias for `interface{}`, making this a completely safe refactor
  - **Improved readability**: Code is easier to scan and understand
  - **Modern Go idioms**: Brings codebase in line with current Go conventions

  ### Potential Risks
  - **Minimal**: Since `any` and `interface{}` are identical at the type system level, there is no runtime impact
  - **Type assertions**: All existing type assertions (e.g., `.(map[string]any)`) continue to work identically
  - **JSON marshaling/unmarshaling**: No changes to behavior since the underlying type is the same

  ### Areas to Watch
  - Type assertion chains in the LM Studio client code (`lmstudio.go`) have multiple nested assertions that should be verified to work correctly
  - Template extension system uses dynamic configuration maps that rely heavily on type assertions

  ## Test Plan

  1. **Compilation**: Verify the code compiles without errors (it must, since `any` is just an alias)
  2. **Existing tests**: Run the full test suite to ensure no behavioral changes
  3. **Specific focus areas**:
     - `internal/plugins/ai/lmstudio/lmstudio.go`: Test streaming and non-streaming chat completions
     - `internal/plugins/ai/anthropic/oauth_test.go`: Ensure OAuth tests pass
     - `internal/plugins/template/extension_executor_test.go`: Verify extension execution tests
     - JSON serialization/deserialization in `internal/plugins/db/fsdb/storage.go`

  ## Additional Notes

  This PR follows the new contributing guidelines added in `docs/CONTRIBUTING.md`, which emphasize focused, reviewable changes. While this PR touches multiple files (15 files), it represents a single mechanical change that is easy to verify: a find-and-replace of `interface{}` with `any`. Each change is identical in nature and carries no functional risk.

  The documentation update in `CONTRIBUTING.md` provides valuable guidance for future contributors, helping prevent large PRs that are difficult to review effectively.

  NOTE: We will be incorporating `modernbize` into the CI/CD process in a future PR.

commits:
  [{"SHA":"66025d516c1de8594bdb25d3a6f3c3ddca30d8e7","Message":"refactor: replace interface{} with any across codebase\n\n- Part 1 of incorporating `modernize` tool into Fabric.\n- Replace `interface{}` with `any` in slice type declarations\n- Update map types from `map[string]interface{}` to `map[string]any`\n- Change variadic function parameters to use `...any` instead of `...interface{}`\n- Modernize JSON unmarshaling variables to `any` for consistency\n- Update struct fields and method signatures to prefer `any` alias\n- Ensure all type assertions and conversions use `any` throughout codebase\n- Add PR guidelines in docs to encourage focused, reviewable changes","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-16T06:08:03Z","Parents":null}]


title: modernize: update benchmarks to use b.Loop and refactor map copying
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1875
merged_at: 2025-12-16 06:48:59+00:00
created_at: 2025-12-16 06:51:40
body:
  # modernize: update benchmarks to use b.Loop and refactor map copying

  ## Summary

  Part 2 of incorporating `modernbize` into the Fabric codebase.

  This pull request updates two files to leverage newer Go standard library features for improved code efficiency and readability. Specifically, it modernizes benchmark loops in test code and replaces manual map copying with a built-in function.

  ## Related issues

  See #1873

  ## Files Changed

  - **internal/plugins/ai/anthropic/oauth_test.go**: Modified benchmark test functions to use the updated Go benchmarking API.
  - **internal/server/patterns.go**: Added a new import and replaced a manual map iteration with a standard library function for copying maps.

  ## Code Changes

  ### internal/plugins/ai/anthropic/oauth_test.go
  - Updated `BenchmarkGeneratePKCE` to use `for b.Loop()` instead of `for i := 0; i < b.N; i++`.
  - Updated `BenchmarkTokenIsExpired` to use `for b.Loop()` and removed the `b.ResetTimer()` call, as the new API handles timing internally.

  These changes align with Go 1.21+ benchmarking best practices, where `b.Loop()` simplifies the loop and automatically manages timing.

  ### internal/server/patterns.go
  - Added `import "maps"` to the imports section.
  - In the `ApplyPattern` function, replaced the manual loop:
    ```go
    for key, value := range request.Variables {
        variables[key] = value
    }
    ```
    with:
    ```go
    maps.Copy(variables, request.Variables)
    ```

  This uses the `maps.Copy` function introduced in Go 1.21, which efficiently copies key-value pairs from one map to another.

  ## Reason for Changes

  The changes modernize the codebase to use Go's latest standard library features, reducing boilerplate code and potential for errors in manual implementations. The benchmark updates ensure compatibility with current Go testing conventions, while the map copying change improves readability and leverages optimized built-in functions. These updates were motivated by Go's evolution towards more concise and performant APIs.

  ## Impact of Changes

  - **Performance**: The `maps.Copy` function is likely more optimized than a manual loop, potentially offering slight performance gains in map operations. Benchmark updates may provide more accurate timing due to internal handling.
  - **Maintainability**: Code is now more concise and less prone to copy-paste errors in loops.
  - **Compatibility**: Requires Go 1.21 or later; no breaking changes to functionality, but ensures the code stays current with Go's ecosystem.
  - **Functionality**: No changes to runtime behavior; purely a refactoring for efficiency.

  Potential bugs: If the project supports older Go versions (<1.21), this could cause compilation failures. The `maps.Copy` assumes no overlapping keys in a way that overwrites, which matches the original loop's behavior, so no logical bugs introduced.

  ## Test Plan

  - Run existing unit tests for `oauth_test.go` to ensure benchmarks execute without errors.
  - Run tests for `patterns.go` to verify that pattern application still works correctly with variable copying.
  - Execute benchmarks manually to confirm they run and produce expected output.
  - Full test suite should pass, as these are non-functional changes.

  ## Additional Notes

  These changes are backward-compatible in terms of logic but require a minimum Go version of 1.21.

commits:
  [{"SHA":"dccdfbac8c3da6a2f33016d18b498fe54297d9dc","Message":"test: update benchmarks to use b.Loop and refactor map copying\n\n# CHANGES\n\n- update benchmark loops to use cleaner `b.Loop()` syntax\n- remove unnecessary `b.ResetTimer()` call in token benchmark\n- use `maps.Copy` for merging variables in patterns handler","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-16T06:40:55Z","Parents":null},{"SHA":"b057f52ca6078d2082a3005fca7cc4c48cb3cebe","Message":"chore: incoming 1875 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-16T06:46:45Z","Parents":null}]


title: modernize Go code with TypeFor and range loops
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1876
merged_at: 2025-12-16 07:31:45+00:00
created_at: 2025-12-16 07:34:44
body:
  # modernize Go code with TypeFor and range loops

  ## Summary

  This PR introduces minor code quality improvements by adopting modern Go idioms and syntax. The changes replace older reflection patterns with the newer `reflect.TypeFor` generic function and simplify loop iterations where the index variable is unused.

  This is part 3 of incorporating `modernize` into Fabric.

  ## Related Issues

  See #1873 for the bigger context.

  ## Files Changed

  ### `internal/cli/flags.go`
  - **Line 118**: Replaced `reflect.TypeOf(Flags{})` with `reflect.TypeFor[Flags]()`
  - **Line 227**: Simplified loop from `for i := 0; i < len(args); i++` to `for i := range args`

  ### `internal/cli/help.go`
  - **Lines 140-141**: Replaced pointer creation and `reflect.TypeOf(flags).Elem()` with `reflect.TypeFor[Flags]()`
  - **Lines 220-221**: Same reflection pattern update as above

  ### `internal/plugins/ai/openai/openai_test.go`
  - **Line 19**: Changed `for i := 0; i < 2; i++` to `for range 2` (index unused)
  - **Line 45**: Same loop simplification as above

  ### `internal/plugins/template/text.go`
  - **Line 19**: Simplified loop from `for i := 0; i < len(runes); i++` to `for i := range runes`

  ## Code Changes

  #### Reflection API Modernization

  **Before:**
  ```go
  t := reflect.TypeOf(Flags{})
  ```

  **After:**
  ```go
  t := reflect.TypeFor[Flags]()
  ```

  **Before:**
  ```go
  flags := &Flags{}
  flagsType := reflect.TypeOf(flags).Elem()
  ```

  **After:**
  ```go
  flagsType := reflect.TypeFor[Flags]()
  ```

  #### Loop Simplification

  **Before:**
  ```go
  for i := 0; i < len(args); i++ {
      arg := args[i]
      // ...
  }
  ```

  **After:**
  ```go
  for i := range args {
      arg := args[i]
      // ...
  }
  ```

  **Before:**
  ```go
  for i := 0; i < 2; i++ {
      // loop body doesn't use i
  }
  ```

  **After:**
  ```go
  for range 2 {
      // cleaner when index is unused
  }
  ```

  ## Reason for Changes

  These changes modernize the codebase to use Go 1.22+ idioms:

  1. **`reflect.TypeFor`**: This generic function (introduced in Go 1.22) is the preferred way to obtain type information. It's more type-safe and eliminates the need to instantiate structs or use `.Elem()` on pointer types.

  2. **Range-over-integer**: The `for range N` syntax (Go 1.22+) clearly expresses intent when a loop counter isn't needed.

  3. **Simplified range**: Using `for i := range slice` instead of `for i := 0; i < len(slice); i++` is more idiomatic and slightly more efficient (avoids bounds checking).

  ## Impact of Changes

  **Positive impacts:**
  - Improved code readability and maintainability
  - Adopts modern Go best practices
  - Slightly better performance due to eliminated allocations (no temporary `Flags{}` structs)
  - More type-safe reflection code

  **Potential concerns:**
  - **Go version requirement**: These changes require Go 1.22 or later. If the project supports earlier Go versions, this will break compatibility.
  - No functional changes to behavior—all changes are refactoring only

  ## Test Plan

  The changes are purely refactoring with no behavioral modifications:

  1. Existing unit tests should pass without modification (verified in `openai_test.go`)
  2. The reflection changes maintain identical runtime behavior—the same type information is obtained
  3. Loop simplifications preserve exact iteration semantics

  **Recommended testing:**
  ```bash
  go test ./...
  ```

  Verify that all existing tests pass, particularly:
  - Flag parsing and initialization tests
  - Help text generation tests
  - Template processing tests

  ## Additional Notes

  - These changes assume the project has migrated to Go 1.22 or later
  - No breaking changes to public APIs
  - This is consistent with a broader codebase modernization effort
  - All changes follow official Go style guidelines and recommendations from the Go team

commits:
  [{"SHA":"a4484d4e01ec6ce562fcaeb186088e44695b9c77","Message":"refactor: modernize Go code with TypeFor and range loops\n\n- Replace reflect.TypeOf with TypeFor generic syntax\n- Convert traditional for loops to range-based iterations\n- Simplify reflection usage in CLI flag handling\n- Update test loops to use range over integers\n- Refactor string processing loops in template plugin","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-16T07:21:55Z","Parents":null}]


title: modernize: update GitHub Actions and modernize Go code
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1877
merged_at: 2025-12-16 08:09:43+00:00
created_at: 2025-12-16 08:12:11
body:
  # modernize: update GitHub Actions and modernize Go code

  ## Summary

  This PR modernizes the codebase by upgrading GitHub Actions dependencies and adopting Go 1.23+ standard library improvements. The changes focus on using newer string manipulation functions (`strings.CutPrefix`, `strings.CutSuffix`, `strings.SplitSeq`) and slice utilities (`slices.Contains`) to replace older, more verbose patterns. Additionally, GitHub Actions are updated to their latest versions, and a new modernization check is added to the CI pipeline.

  ## Related Issues

  Closes #1873 

  ## Files Changed

  ### GitHub Actions Workflows
  - **`.github/workflows/ci.yml`**: Updated action versions, reordered steps, and added modernization check
  - **`.github/workflows/patterns.yaml`**: Bumped `actions/checkout@v6` and `actions/upload-artifact@v6`
  - **`.github/workflows/release.yml`**: Updated `actions/checkout@v6` and `actions/setup-go@v6`
  - **`.github/workflows/update-version-and-create-tag.yml`**: Updated action versions and fixed conditional syntax

  ### Go Source Files
  - **`cmd/generate_changelog/internal/changelog/generator.go`**: Adopted `strings.SplitSeq` for iterating over lines
  - **`cmd/generate_changelog/internal/changelog/processing.go`**: Used `strings.CutSuffix` for cleaner string manipulation
  - **`internal/cli/flags.go`**: Refactored using `strings.CutPrefix` and `slices.Contains`
  - **`internal/cli/help.go`**: Simplified flag parsing and padding calculation with `max()` function
  - **`internal/cli/output.go`**: Replaced manual loop with `slices.Contains`
  - **`internal/domain/file_manager.go`**: Used `slices.Contains` for escape sequence validation
  - **`internal/plugins/ai/gemini/voices.go`**: Migrated to `strings.Builder` for efficient string concatenation
  - **`internal/plugins/ai/lmstudio/lmstudio.go`**: Adopted `bytes.CutPrefix`
  - **`internal/plugins/ai/openai/openai_image.go`**: Simplified model checking with `slices.Contains`
  - **`internal/plugins/ai/perplexity/perplexity.go`**: Used `strings.Builder` for content assembly
  - **`internal/plugins/template/extension_executor_test.go`**: Converted to `strings.Builder` in test setup
  - **`internal/server/ollama.go`**: Used `fmt.Appendf` and `strings.SplitSeq`

  ## Code Changes

  ### GitHub Actions Dependency Updates

  Updated all GitHub Actions to their latest major versions for improved security and performance:

  ```yaml
  - uses: actions/checkout@v5
  + uses: actions/checkout@v6

  - uses: actions/setup-go@v5
  + uses: actions/setup-go@v6

  - uses: actions/upload-artifact@v4
  + uses: actions/upload-artifact@v6

  - uses: DeterminateSystems/nix-installer-action@main
  + uses: DeterminateSystems/nix-installer-action@v21
  ```

  ### New Modernization Check

  Added an automated check to identify further modernization opportunities:

  ```yaml
  - name: Check for modernization opportunities
    run: |
      go run golang.org/x/tools/go/analysis/passes/modernize/cmd/modernize@latest ./...
  ```

  ### String Manipulation Improvements

  Replaced verbose prefix/suffix checking patterns with cleaner Go 1.20+ functions:

  **Before:**
  ```go

  if strings.HasPrefix(arg, "--debug=") {
      if lvl, err := strconv.Atoi(strings.TrimPrefix(arg, "--debug=")); err == nil {
          return lvl
      }
  }
  ```

  **After:**
  ```go
  if after, ok := strings.CutPrefix(arg, "--debug="); ok {
      if lvl, err := strconv.Atoi(after); err == nil {
          return lvl
      }
  }
  ```

  ### Slice Contains Simplification

  Replaced manual loops with `slices.Contains` for readability:

  **Before:**
  ```go
  valid := false
  for _, validSize := range validSizes {
      if size == validSize {
          valid = true
          break
      }
  }
  ```

  **After:**
  ```go
  valid := slices.Contains(validSizes, size)
  ```

  ### Iterator-Based String Splitting

  Adopted `strings.SplitSeq` for memory-efficient iteration over split strings:

  **Before:**
  ```go
  lines := strings.Split(pr.Body, "\n")
  for _, line := range lines {
      // process line
  }
  ```

  **After:**
  ```go
  lines := strings.SplitSeq(pr.Body, "\n")
  for line := range lines {
      // process line
  }
  ```

  ### String Builder Pattern

  Replaced string concatenation with `strings.Builder` for better performance:

  **Before:**
  ```go
  result := "Available Gemini Text-to-Speech voices:\n\n"
  result += fmt.Sprintf("%s:\n", groupName)
  return result
  ```

  **After:**
  ```go
  var result strings.Builder
  result.WriteString("Available Gemini Text-to-Speech voices:\n\n")
  result.WriteString(fmt.Sprintf("%s:\n", groupName))
  return result.String()
  ```

  ## Reason for Changes

  1. **Security and Stability**: GitHub Actions v6 includes security improvements and bug fixes
  2. **Performance**: `strings.Builder` and iterator-based splitting reduce memory allocations
  3. **Readability**: Modern Go idioms (`CutPrefix`, `CutSuffix`, `slices.Contains`) are more expressive
  4. **Maintainability**: Cleaner code is easier to understand and modify
  5. **Future-proofing**: Adopting Go 1.23+ patterns prepares the codebase for future Go versions
  6. **Automation**: The modernization check prevents regression to older patterns

  ## Impact of Changes

  ### Positive Impacts
  - **Improved Performance**: String operations allocate less memory and run faster
  - **Enhanced Readability**: Code is more concise and self-documenting
  - **Better CI/CD**: Updated actions provide improved performance and security
  - **Reduced Cognitive Load**: Simpler patterns are easier to reason about

  ### Potential Risks
  - **Go Version Requirement**: Code now requires Go 1.23+ for `strings.SplitSeq` and other features
  - **Behavioral Changes**: While semantically equivalent, iterator-based approaches may have subtle differences in error handling
  - **Action Breaking Changes**: GitHub Actions major version updates may introduce breaking changes (though v5→v6 transitions are generally smooth)

  ## Test Plan

  1. **Unit Tests**: All existing Go tests should pass with `go test -v ./...`
  2. **CI Pipeline**: The workflow changes will be validated on the next push to a branch
  3. **Manual Testing**: Verify that:
     - String parsing logic behaves identically (flag parsing, file validation)
     - Iterator-based loops produce the same output
     - String building produces identical results
     - GitHub Actions complete successfully in CI
  4. **Integration Testing**: Run full build and release workflows to ensure action updates don't break deployment

  ## Additional Notes

  ### Breaking Changes
  - **Go Version**: This PR effectively raises the minimum Go version to 1.23. The `go.mod` file should be updated accordingly if not already set.

  ### Potential Bugs
  1. **Iterator Edge Cases**: `strings.SplitSeq` behavior differs slightly from `strings.Split` for edge cases (empty strings, single elements). Verified behavior is identical for all usage patterns in this codebase.
  2. **Conditional Syntax Fix**: The workflow file had incorrect YAML syntax (`${{ }}`) that was removed. This was a bug fix rather than a potential issue.
  3. **Buffer Reuse**: Using `fmt.Appendf(nil, ...)` creates a new buffer each time, which is semantically equivalent to the original code.

commits:
  [{"SHA":"fdadeae1e7cb339c35857364a176fb3592271bcb","Message":"modernize: update GitHub Actions and modernize Go code with latest stdlib features\n\n## CHANGES\n\n- Upgrade GitHub Actions to latest versions (v6, v21)\n- Add modernization check step in CI workflow\n- Replace strings manipulation with `strings.CutPrefix` and `strings.CutSuffix`\n- Replace manual loops with `slices.Contains` for validation\n- Use `strings.SplitSeq` for iterator-based string splitting\n- Replace `bytes.TrimPrefix` with `bytes.CutPrefix` for clarity\n- Use `strings.Builder` instead of string concatenation\n- Replace `fmt.Sprintf` with `fmt.Appendf` for efficiency\n- Simplify padding calculation with `max` builtin","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-16T07:55:37Z","Parents":null},{"SHA":"6ecbd044e6e12aee7f35f27fb12805b75f728ece","Message":"chore: incoming 1877 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-16T08:06:39Z","Parents":null}]


title: docs: add REST API server section and new endpoint reference
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1880
merged_at: 2025-12-18 03:29:28+00:00
created_at: 2025-12-18 18:29:51
body:
  # docs: add REST API server section and new endpoint reference

  ## Summary

  This pull request adds comprehensive documentation for Fabric's new REST API server feature, including updates to the main README.md file and the creation of a dedicated API documentation file. The changes introduce user-facing guides for starting the server, authenticating requests, and interacting with various endpoints for chat completions, pattern management, and more.

  ## Related Issues

  Closes #1878 

  ## Files Changed

  - **README.md**: Modified to include references to the REST API Server in the table of contents and usage sections. Added a new "## REST API Server" section with a brief overview and link to detailed documentation.
  - **docs/rest-api.md**: New file created containing full REST API documentation, including quick start, server options, authentication, endpoint details with examples, Docker usage, and error handling.

  ## Code Changes

  The changes are primarily documentation updates, with no code modifications. Key additions include:

  - In README.md, added TOC entry `[REST API](#rest-api-server) •` and usage subsection `- [REST API Server](#rest-api-server)`.
  - Updated the Docker command comment from `# Run the REST API server` to `# Run the REST API server (see REST API Server section)`.
  - Introduced a new section in README.md for the REST API.
  - Created docs/rest-api.md with detailed sections covering all API aspects, such as endpoints for `/chat`, `/patterns`, `/contexts`, etc., complete with JSON examples and curl commands.

  ## Reason for Changes

  The REST API server in Fabric was not well documented.  It allows programmatic access to core functionalities like AI chat completions and pattern management.

  This documentation is essential to make the feature accessible to users, developers, and integrators.

  Without it, users would lack guidance on how to start the server, authenticate, and use the endpoints effectively. The changes address the need for clear, comprehensive docs to support adoption and reduce support queries.

  ## Impact of Changes

  - **Usability**: Significantly improves the project's usability by providing step-by-step instructions for the REST API, enabling users to integrate Fabric into web applications, scripts, or other tools via HTTP requests.
  - **Documentation Completeness**: Enhances the overall documentation ecosystem, making Fabric more professional and user-friendly. This could lead to increased community contributions and usage.
  - **No Functional Impact**: As these are documentation-only changes, there is no impact on existing code functionality, performance, or behavior. However, it assumes the underlying REST API server code is already implemented and working correctly.
  - **Potential for Broader Adoption**: By exposing core features via API, this could expand Fabric's use cases beyond CLI, potentially increasing its popularity in automation and integration scenarios.

  ## Additional Notes

  - Potential bugs or issues: If the API endpoints change in the future, this documentation will need updates to avoid confusion. 
  - Future updates: Adding a Swagger UI endpoint to the server implementation.

commits:
  [{"SHA":"99b8b6a97293d4e7233b123ef4d26a60ccb2fff0","Message":"- Add README table-of-contents link for REST API.\n- Document REST API server startup and capabilities.\n- Add endpoint overview for chat, patterns, contexts.\n- Describe sessions management and model listing endpoints.\n- Provide curl examples for key API workflows.\n- Explain Ollama compatibility mode endpoints and port.","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-18T03:02:04Z","Parents":null}]


title: Added yt-dlp package to docker image.
author: bvandevliet
author_url: https://github.com/bvandevliet
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1882
merged_at: 2025-12-18 18:34:55+00:00
created_at: 2025-12-18 18:37:22
body:
  ## What this Pull Request (PR) does

  This PR adds the yt-dlp package to the docker image. Having yt-dlp bundled in the image makes sure the YouTube transcript functionality works out of the box.

  ## Related issues

  Will not close this specific issue as it's not about the docker deployment, but it is related as it's about missing yt-dlp: #1862 

commits:
  [{"SHA":"d84bd6f9891ad0fd63a3a7a89e18562d8134533a","Message":"Added yt-dlp package to docker image.","Author":"Bob Vandevliet","Email":"","Date":"2025-12-18T10:16:39Z","Parents":null},{"SHA":"f61db2cdce306cc75a3946ab6922fbe4e8136e0d","Message":"chore: incoming 1882 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-18T18:30:23Z","Parents":null}]


title: Implement interactive Swagger API documentation and automated OpenAPI specification generation.
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1884
merged_at: 2025-12-18 18:27:06+00:00
created_at: 2025-12-18 18:29:51
body:
  # Implement interactive Swagger API documentation and automated OpenAPI specification generation.

  ## Summary

  This pull request implements interactive REST API documentation using Swagger (OpenAPI 2.0). It introduces the `swaggo` system to the project, allowing for automated documentation generation from code comments. Key changes include the addition of Swagger annotations to core API handlers, the generation of OpenAPI specification files, and the integration of a Swagger UI accessible directly from the Fabric server.

  Documented Endpoints (4 total)

  1. POST /chat - Stream chat completions
  2. GET /patterns/{name} - Get pattern
  3. POST /patterns/{name}/apply - Apply pattern with variables
  4. GET /models/names - List models

  > NOTE: We can add remaining endpoints in subsequent PRs (and I am responsive to the developer/user base here).

  ## Related Issues

  Closes #1881 

  Based on discussions from @bvandevliet in #1878

  ## Screenshots

  <img width="1485" height="1133" alt="image" src="https://github.com/user-attachments/assets/6312908d-13dd-4ec8-bcb9-feb8a25bc0a9" />

  And the response

  <img width="1424" height="1094" alt="image" src="https://github.com/user-attachments/assets/d3b48d0b-e57b-4176-ba6b-783fff60ce50" />


  ## Files Changed

  - **.vscode/settings.json**: Added API-related terms (`apikey`, `godoc`, `swaggo`, `varnames`) to the workspace dictionary to prevent linting false positives.
  - **docs/CONTRIBUTING.md**: Added a new section providing instructions for contributors on how to document REST API endpoints and regenerate Swagger files.
  - **docs/docs.go, docs/swagger.json, docs/swagger.yaml**: New generated files containing the OpenAPI specification for the Fabric API.
  - **docs/rest-api.md**: Updated documentation to include information about the interactive Swagger UI, detailed request/response field tables, and a new "Complete Workflow Examples" section.
  - **go.mod / go.sum**: Added `github.com/swaggo/swag`, `github.com/swaggo/gin-swagger`, and `github.com/swaggo/files` dependencies. Updated `gin` and other sub-dependencies.
  - **internal/server/auth.go**: Modified the `APIKeyMiddleware` to allow unauthenticated access to the `/swagger/*` endpoints.
  - **internal/server/chat.go, internal/server/models.go, internal/server/patterns.go**: Added declarative Swagger annotations to the handler functions.
  - **internal/server/serve.go**: Added global API metadata annotations and configured the Gin routes to serve the Swagger UI and the YAML specification file.

  ## Code Changes

  #### Authentication Bypass for Documentation
  The middleware was updated to ensure the documentation remains accessible even when API key authentication is enabled for the rest of the API.

  ```go
  // internal/server/auth.go

  func APIKeyMiddleware(apiKey string) gin.HandlerFunc {
          return func(c *gin.Context) {
                  if strings.HasPrefix(c.Request.URL.Path, "/swagger/") {
                          c.Next()
                          return
                  }
          // ... existing auth logic
      }
  }
  ```

  #### Handler Annotations
  Handlers now include structured comments that define the API contract.

  ```go
  // internal/server/chat.go

  // HandleChat godoc
  // @Summary Stream chat completions
  // @Description Stream AI responses using Server-Sent Events (SSE)
  // @Tags chat
  // @Accept json
  // @Produce text/event-stream
  // @Param request body ChatRequest true "Chat request with prompts and options"
  // @Success 200 {object} StreamResponse "Streaming response"
  // @Security ApiKeyAuth
  // @Router /chat [post]
  ```

  #### Swagger UI Integration
  The server now serves the interactive UI and handles requests for the `swagger.yaml` file.

  ```go
  // internal/server/serve.go

  r.GET("/swagger/*any", func(c *gin.Context) {
      if c.Param("any") == "/swagger.yaml" {
          // Logic to locate and serve the yaml file
          c.File(yamlPath)
          return
      }
      ginSwagger.WrapHandler(swaggerFiles.Handler)(c)
  })
  ```

  ## Reason for Changes

  As the Fabric REST API grows, maintaining manual documentation in Markdown becomes error-prone and difficult to keep in sync with the implementation. By using Swagger:
  1. **Synchronization**: The documentation is derived directly from the code.
  2. **Interactivity**: Developers can test API calls (including streaming chat completions) directly from the browser without needing `curl` or Postman.
  3. **Standardization**: Provides a machine-readable OpenAPI spec that can be used to generate client SDKs or integrate with other tools.

  ## Impact of Changes

  - **Developer Experience**: Significant improvement in API discoverability and testing.
  - **Security**: Documentation endpoints are public by design, but actual API execution still requires a valid `X-API-Key` if configured.
  - **Build Process**: Contributors now need to run `swag init` when modifying API signatures to keep the `docs/` directory updated.

  ## Test Plan

  1. **Manual Verification**:
     - Start the server: `go run ./cmd/fabric --serve`
     - Navigate to `http://localhost:8080/swagger/index.html`
     - Verify that the UI loads and displays the `/chat`, `/models/names`, and `/patterns` endpoints.
     - Use the "Try it out" feature on `/models/names` to verify it returns the expected JSON.
  2. **Authentication Test**:
     - Start the server with `--api-key your_key`.
     - Verify `/swagger/index.html` is still accessible without a header.
     - Verify that calling `/chat` via the Swagger UI fails without the `X-API-Key` header and succeeds when the key is provided via the UI's "Authorize" button.

  ## Additional Notes

  - The `swagger.yaml` file is served via a custom handler because `gin-swagger` primarily focuses on the JSON version. This ensures users who prefer YAML or use tools that require it can access it at `/swagger/swagger.yaml`.
  - Dependency updates in `go.mod` were performed to ensure compatibility with the latest `gin` and `sonic` versions.

commits:
  [{"SHA":"c06c94f8b868ec4b1b3d696f7459921eead41891","Message":"# CHANGES\n\n- Add Swagger UI at `/swagger/index.html` endpoint\n- Generate OpenAPI spec files (JSON and YAML)\n- Document chat, patterns, and models endpoints\n- Update contributing guide with Swagger annotation instructions\n- Add swaggo dependencies to project\n- Configure authentication bypass for Swagger documentation\n- Add custom YAML handler for OpenAPI spec\n- Update REST API documentation with Swagger links\n- Add dictionary entries for new tools","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-18T15:12:08Z","Parents":null},{"SHA":"645190be3a7b035ebe7c3f00797ef22b9b718b59","Message":"feat: update REST API docs with new fields and examples\n\n### CHANGES\n\n- Add detailed prompt fields table with defaults\n- Introduce chat options table with new parameters\n- Include complete workflow examples for YouTube summary\n- Provide alternative script and CLI comparison for flexibility","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-18T15:30:34Z","Parents":null},{"SHA":"3a4468b9709f6f831d67e92b35f3915505c58e63","Message":"chore: incoming 1884 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-18T18:05:33Z","Parents":null}]


title: Enhanced Onboarding and Setup Experience
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1886
merged_at: 2025-12-18 23:42:59+00:00
created_at: 2025-12-18 23:45:27
body:
  # Enhanced Onboarding and Setup Experience

  ## Summary

  This pull request significantly improves the initial user experience and configuration workflow for Fabric. It introduces a guided "first-time setup" flow, adds comprehensive configuration validation, improves error messaging when patterns are missing, and updates localization files across all supported languages to support these changes.

  ## Related Issues

  Closes #1863 

  ## Screenshots

  On a fresh Ubuntu Docker Container, having only run `apt-get  update && apt-get install -y curl git`, the new setup
  flow looks like this:

  <img width="804" height="811" alt="image" src="https://github.com/user-attachments/assets/db712f02-30fb-46f6-9939-6389689e1cab" />

  After providing an API key for one provider, we continue:

  <img width="809" height="463" alt="image" src="https://github.com/user-attachments/assets/5fee07b1-f496-4f4f-bc01-06eade3a8d9c" />

  And we set the default model,

  <img width="804" height="526" alt="image" src="https://github.com/user-attachments/assets/52df12e6-934d-4957-a308-a79018d4d410" />

  Afterwards, running `fabric --setup` provides better and more visible feedback too:

  ```text
  root@a452b877ff11:/# fabric -S

  Available plugins::

  Required Tools

  	[1]	Default AI Vendor and Model [required] ✓
  	[2]	Patterns - Downloads patterns [required] ✓
  	[3]	Strategies - Downloads Prompting Strategies (like chain of thought) [required] ✓

  ━━━ OPTIONAL CONFIGURATION ━━━

  Optional Tools

  	[4]	Custom Patterns - Set directory for your custom patterns (optional) ⚠️  NOT CONFIGURED
  	[5]	Jina AI Service - to grab a webpage as clean, LLM-friendly text ✓
  	[6]	Language - Default AI Vendor Output Language ✓
  	[7]	YouTube - to grab video transcripts (via yt-dlp) and comments/metadata (via YouTube API) ✓

  ━━━ REQUIRED CONFIGURATION ━━━

  AI Vendors [at least one required]

  	[8]	Abacus ⚠️  NOT CONFIGURED
  	[9]	AIML ⚠️  NOT CONFIGURED
  	[10]	Anthropic ⚠️  NOT CONFIGURED
  	[11]	Azure ⚠️  NOT CONFIGURED
  	[12]	Cerebras ⚠️  NOT CONFIGURED
  	[13]	DeepSeek ⚠️  NOT CONFIGURED
  	[14]	Exolab ⚠️  NOT CONFIGURED
  	[15]	Gemini ⚠️  NOT CONFIGURED
  	[16]	GitHub ⚠️  NOT CONFIGURED
  	[17]	GrokAI ⚠️  NOT CONFIGURED
  	[18]	Groq ⚠️  NOT CONFIGURED
  	[19]	Langdock ⚠️  NOT CONFIGURED
  	[20]	LiteLLM ⚠️  NOT CONFIGURED
  	[21]	LM Studio ⚠️  NOT CONFIGURED
  	[22]	Mistral ⚠️  NOT CONFIGURED
  	[23]	Ollama ⚠️  NOT CONFIGURED
  	[24]	OpenAI ✓
  	[25]	OpenRouter ⚠️  NOT CONFIGURED
  	[26]	Perplexity ⚠️  NOT CONFIGURED
  	[27]	SiliconCloud ⚠️  NOT CONFIGURED
  	[28]	Together ⚠️  NOT CONFIGURED
  	[29]	Venice AI ⚠️  NOT CONFIGURED
  	[30]	Z AI ⚠️  NOT CONFIGURED

  [Plugin Number] Enter the number of the plugin to setup (leave empty to skip):


  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Configuration Status:
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    ✓ AI Provider configured
    ✓ Default vendor/model set: OpenAI/gpt-4o
    ✓ Patterns downloaded
    ✓ Strategies downloaded
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✓ All required components configured!
  ```

  ## Files Changed

  - **`.vscode/settings.json`**: Added "Astley" to the workspace dictionary.
  - **`internal/cli/listing.go`**: Updated the pattern listing command to check for the existence of patterns and provide helpful setup guidance if none are found.
  - **`internal/core/plugin_registry.go`**: Refactored the setup logic to include a guided first-time flow, a dedicated vendor setup, and a post-setup validation report.
  - **`internal/i18n/locales/*.json`**: (Multiple files: `de`, `en`, `es`, `fa`, `fr`, `it`, `ja`, `pt-BR`, `pt-PT`, `zh`) Added numerous keys for setup instructions, validation status, and error messages.
  - **`internal/plugins/db/fsdb/patterns.go`**: Enhanced error reporting when a pattern is not found, specifically identifying if the patterns directory is empty.
  - **`internal/plugins/strategy/strategy.go`**: Improved the strategy download process with better logging and state reloading.

  ## Code Changes

  ### Guided Setup Logic
  In `internal/core/plugin_registry.go`, the `Setup()` method now branches based on whether the user has a valid configuration:

  ```go
  func (o *PluginRegistry) Setup() (err error) {
          isFirstRun := o.isFirstTimeSetup()

          if isFirstRun {
                  err = o.runFirstTimeSetup()
          } else {
                  err = o.runInteractiveSetup()
          }
      // ... validation follows
  }
  ```

  The `runFirstTimeSetup` method automates the downloading of patterns and strategies before prompting the user for an AI provider, reducing the manual steps required to get Fabric running.

  ### Configuration Validation
  A new `validateSetup()` function provides a clear status report of the environment:

  ```go
  func (o *PluginRegistry) validateSetup() {
      // Checks AI vendor, default models, patterns, and strategies
      // Prints a summary with checkmarks (✓) or crosses (✗)
  }
  ```

  ### Improved Pattern Listing UX
  In `internal/cli/listing.go`, the application now intercepts requests to list patterns when the database is empty, providing actionable commands instead of an empty list:

  ```go
  if len(names) == 0 && !currentFlags.ShellCompleteOutput {
      fmt.Println(i18n.T("patterns_not_found_header"))
      fmt.Printf("  %s\n", i18n.T("patterns_option_run_setup_command"))
      return true, nil
  }
  ```

  ## Reason for Changes
  The previous setup process was purely interactive and required users to know which components (Patterns, Strategies, Vendors) were mandatory. New users often encountered "pattern not found" errors because they skipped the download step. These changes:
  1.  **Reduce Friction**: Automate mandatory downloads during the first run.
  2.  **Improve Discoverability**: Provide clear instructions when the tool is in an unconfigured state.
  3.  **Increase Reliability**: Validate the configuration at the end of the setup to ensure the user is ready to go.

  ## Impact of Changes
  - **User Experience**: New users will have a much smoother "Day 1" experience.
  - **Supportability**: Clearer error messages and validation reports make it easier to debug user configuration issues.
  - **Internationalization**: All new strings have been added to the existing locale files, maintaining full i18n support.
  - **Performance**: Minor impact; the strategy manager now reloads files after setup to ensure the in-memory state matches the disk.

  ## Test Plan
  1.  **Fresh Install Simulation**: Delete the `.env` file and the `~/.config/fabric` directory. Run `fabric --setup` and verify the guided flow downloads patterns/strategies automatically.
  2.  **Re-configuration**: Run `fabric --setup` on an existing installation and verify it opens the standard interactive menu.
  3.  **Empty Patterns Check**: Manually empty the patterns directory and run `fabric -l`. Verify the helpful guidance message appears.
  4.  **Validation**: Complete a setup and verify the "Configuration Status" report correctly identifies configured vs. missing components.

  ## Additional Notes
  - The `internal/i18n/locales` files underwent significant updates. While most translations were added, some languages may require a native speaker's review for nuance in the new technical instructions.
  - The addition of "Astley" to the dictionary is a minor developer convenience for VS Code users.
  - Potential Bug: If a user has a very slow network connection, the automatic `git clone` for patterns/strategies during `runFirstTimeSetup` might timeout. Error handling is in place, but the user would need to re-run setup.

commits:
  [{"SHA":"9f79877524496d1d7a4c07c94d2ef5864a32adab","Message":"User Experience: implement automated first-time setup and improved configuration validation\n\n### CHANGES\n\n- Add automated first-time setup for patterns and strategies.\n- Implement configuration validation to warn about missing required components.\n- Update setup menu to group plugins into required and optional.\n- Provide helpful guidance when no patterns are found in listing.\n- Expand localization support for setup and error messaging across languages.\n- Enhance strategy manager to reload and count installed strategies.\n- Improve pattern error handling with specific guidance for empty directories.","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-18T22:48:50Z","Parents":null},{"SHA":"b2d24aa5c7db9f6008302ab58a11f55839cdb787","Message":"chore: incoming 1886 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-18T23:03:22Z","Parents":null}]


title: feat: correct video title and added description to yt transcript api response
author: bvandevliet
author_url: https://github.com/bvandevliet
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1887
merged_at: 2025-12-19 16:19:16+00:00
created_at: 2025-12-19 16:21:49
body:
  ## What this Pull Request (PR) does

  This PR includes a few changes to the YouTube transcript API response:
  - Now returns the actual YouTube video title in the `title` field instead of the video id.
  - The video id is still in the response, but in its own `videoId` field.
  - Also added the video description to the response, could be useful to provide additional context to the LLM besides the transcript.

  ## Related issues

  None, this is just a small fix and improvement feature.

  ## Example
  ```bash
  $ curl -X POST http://localhost:8080/youtube/transcript -H "Content-Type: application/json" -d '{"url": "https://youtube.com/watch?v=dQw4w9WgXcQ", "timestamps": true}'
  ```
  ```json
  {
    "transcript": "[00:00:00] [Music]\n[00:00:18] We're no strangers to\n[00:00:21] love. You know the rules and so do\n[00:00:25] I. I feel commitments from what I'm\n[00:00:29] thinking\n[00:00:30] of. You wouldn't get this from any other\n[00:00:34] guy. I just want to tell you how I'm\n[00:00:39] feeling. Got to make you understand.\n[00:00:43] Never going to give you up. I'm going to\n[00:00:45] let you down. I'm going to run around\n[00:00:49] and desert you. I'm going to make\n[00:00:53] you say goodbye.\n[00:00:56] Tell a lie and hurt\n[00:00:59] you. We've known each other for so\n[00:01:04] long. Your heart's been aching, but\n[00:01:07] you're too shy to say we don't know\n[00:01:10] what's been going\n[00:01:12] on. We know the game and we're going to\n[00:01:17] play. If you ask me how I'm\n[00:01:21] feeling, don't tell me your truth. to\n[00:01:24] see. I will give\n[00:01:29] you\n[00:01:31] around\n[00:01:35] you. I will say\n[00:01:39] goodbye and hurt you. I will give\n[00:01:43] [Music]\n[00:01:46] you\n[00:01:48] around you. I will leave you. I will say\n[00:01:56] goodbye and hurt you.\n[00:02:08] Never going to give. Never going to\n[00:02:09] give.\n[00:02:16] We've known each other for so long.\n[00:02:21] Your heart's been aching, but you're too\n[00:02:23] shy to say it. We both know what's been\n[00:02:27] going\n[00:02:28] on. We know the game and we're going to\n[00:02:32] play it. I just want to tell you how I'm\n[00:02:37] feeling. Got to make you understand.\n[00:02:41] Never going to give you up. Never going\n[00:02:43] to let you down. Never going to run\n[00:02:46] around and desert you. Heat.\n[00:02:52] [Music]\n[00:02:58] Heat. Heat. Heat.\n[00:03:03] [Music]\n[00:03:11] Never going to tell a lie and hurt you.\n[00:03:15] Never going to give you up. Never going\n[00:03:17] to let you down. Never going to run\n[00:03:20] around and desert you. Never going to\n[00:03:24] make you cry. Never going to say\n[00:03:26] goodbye. Never going to say goodbye.",
    "videoId": "dQw4w9WgXcQ",
    "title": "Rick Astley - Never Gonna Give You Up (Official Video) (4K Remaster)",
    "description": "The official video for “Never Gonna Give You Up” by Rick Astley. \n\nNever: The Autobiography 📚 OUT NOW! \nFollow this link to get your copy and listen to Rick’s ‘Never’ playlist ❤️ #RickAstleyNever\nhttps://linktr.ee/rickastleynever\n\n“Never Gonna Give You Up” was a global smash on its release in July 1987, topping the charts in 25 countries including Rick’s native UK and the US Billboard Hot 100.  It also won the Brit Award for Best single in 1988. Stock Aitken and Waterman wrote and produced the track which was the lead-off single and lead track from Rick’s debut LP “Whenever You Need Somebody”.  The album was itself a UK number one and would go on to sell over 15 million copies worldwide.\n\nThe legendary video was directed by Simon West – who later went on to make Hollywood blockbusters such as Con Air, Lara Croft – Tomb Raider and The Expendables 2.  The video passed the 1bn YouTube views milestone on 28 July 2021.\n\nSubscribe to the official Rick Astley YouTube channel: https://RickAstley.lnk.to/YTSubID\n\nFollow Rick Astley:\nFacebook: https://RickAstley.lnk.to/FBFollowID \nTwitter: https://RickAstley.lnk.to/TwitterID \nInstagram: https://RickAstley.lnk.to/InstagramID \nWebsite: https://RickAstley.lnk.to/storeID \nTikTok: https://RickAstley.lnk.to/TikTokID\n\nListen to Rick Astley:\nSpotify: https://RickAstley.lnk.to/SpotifyID \nApple Music: https://RickAstley.lnk.to/AppleMusicID \nAmazon Music: https://RickAstley.lnk.to/AmazonMusicID \nDeezer: https://RickAstley.lnk.to/DeezerID \n\nLyrics:\nWe’re no strangers to love\nYou know the rules and so do I\nA full commitment’s what I’m thinking of\nYou wouldn’t get this from any other guy\n\nI just wanna tell you how I’m feeling\nGotta make you understand\n\nNever gonna give you up\nNever gonna let you down\nNever gonna run around and desert you\nNever gonna make you cry\nNever gonna say goodbye\nNever gonna tell a lie and hurt you\n\nWe’ve known each other for so long\nYour heart’s been aching but you’re too shy to say it\nInside we both know what’s been going on\nWe know the game and we’re gonna play it\n\nAnd if you ask me how I’m feeling\nDon’t tell me you’re too blind to see\n\nNever gonna give you up\nNever gonna let you down\nNever gonna run around and desert you\nNever gonna make you cry\nNever gonna say goodbye\nNever gonna tell a lie and hurt yoou\n\n#RickAstley #NeverGonnaGiveYouUp #WheneverYouNeedSomebody #OfficialMusicVideo"
  }
  ```

commits:
  [{"SHA":"8a3fa9337c280354622fd2faf03d1a70876275fe","Message":"feat: correct video title (instead of id) and added description to yt transcript api response","Author":"Bob Vandevliet","Email":"","Date":"2025-12-19T12:14:12Z","Parents":null},{"SHA":"7fa4c0a030d1f0db7ee5daf73e9a2ac0d178a0a9","Message":"Updated API documentation.","Author":"Bob Vandevliet","Email":"","Date":"2025-12-19T12:23:44Z","Parents":null},{"SHA":"e3f9b12fde9f1f17064040c04ab91df48802c7b3","Message":"chore: incoming 1887 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-19T16:16:18Z","Parents":null}]


title: docs: Add a YouTube transcript endpoint to the Swagger UI.
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1889
merged_at: 2025-12-19 18:44:47+00:00
created_at: 2025-12-19 18:47:36
body:
  # docs: Add a YouTube transcript endpoint to the Swagger UI.

  ## Summary

  This pull request adds comprehensive API documentation for the YouTube transcript endpoint. It includes the addition of Swagger/OpenAPI annotations to the YouTube handler and updates the generated documentation files. These changes ensure that the `/youtube/transcript` endpoint is discoverable and well-defined for API consumers.

  ## Related Issues

  Closes #1888 

  ## Screenshot

  <img width="797" height="738" alt="image" src="https://github.com/user-attachments/assets/b2f3a3a8-6c77-4134-9ea7-6ee88e921e35" />


  ## Files Changed

  - **internal/server/youtube.go**: Updated `YouTubeRequest` and `YouTubeResponse` structs with validation tags and example values. Added godoc annotations to the `Transcript` method to facilitate Swagger documentation generation.
  - **docs/docs.go**: Updated the internal documentation template to include the new `/youtube/transcript` path and associated definitions.
  - **docs/swagger.json**: Updated the JSON representation of the API specification.
  - **docs/swagger.yaml**: Updated the YAML representation of the API specification.

  ## Code Changes

  #### Struct Enhancements
  In `internal/server/youtube.go`, the request and response models were updated to include `binding` tags for validation and `example` tags for documentation.

  ```go
  type YouTubeRequest struct {
  	URL        string `json:"url" binding:"required" example:"https://www.youtube.com/watch?v=dQw4w9WgXcQ"`
  	Language   string `json:"language,omitempty" example:"en"`
  	Timestamps bool   `json:"timestamps,omitempty" example:"false"`
  }
  ```

  #### Handler Annotations
  The `Transcript` method now includes standard godoc annotations used by `swag` to generate the OpenAPI specification.

  ```go
  // Transcript godoc
  // @Summary Get YouTube video transcript
  // @Description Retrieves the transcript of a YouTube video along with video metadata (title and description)
  // @Tags youtube
  // @Accept json
  // @Produce json
  // @Param request body YouTubeRequest true "YouTube transcript request with URL, language, and timestamp options"
  // @Success 200 {object} YouTubeResponse "Successful response with transcript and metadata"
  // @Failure 400 {object} map[string]string "Bad request - invalid URL or playlist URL provided"
  // @Failure 500 {object} map[string]string "Internal server error - failed to retrieve transcript or metadata"
  // @Security ApiKeyAuth
  // @Router /youtube/transcript [post]
  ```

  ## Reason for Changes

  The primary goal is to improve the maintainability and usability of the API. By adding these annotations:
  1. **Validation**: The `binding:"required"` tag on the `URL` field ensures that the Gin framework automatically validates incoming requests, reducing boilerplate error handling in the handler.
  2. **Documentation**: The API contract is now explicitly defined in the Swagger UI, allowing frontend developers and external consumers to understand the required inputs and expected outputs without reading the source code.

  ## Impact of Changes

  - **API Documentation**: The Swagger UI (typically served at `/swagger/index.html`) will now display the YouTube transcript endpoint under the `youtube` tag.
  - **Request Validation**: Requests to `/youtube/transcript` that omit the `url` field will now automatically return a `400 Bad Request` response.
  - **Developer Experience**: Provides clear examples of request and response payloads within the documentation.

  ## Test Plan

  1. **Documentation Verification**: Run the application and navigate to the Swagger UI to ensure the `/youtube/transcript` endpoint appears correctly with all parameters and examples.
  2. **Validation Testing**: 
     - Send a POST request to `/youtube/transcript` with an empty body or missing `url` field to verify a `400` error is returned.
     - Send a valid request with a YouTube URL to verify the transcript is retrieved successfully.
  3. **Security Testing**: Verify that the endpoint still requires the `ApiKeyAuth` as specified in the annotations.

commits:
  [{"SHA":"5e4e4f4bf17252b749bbabdb469519722dae6b79","Message":"docs: Add YouTube transcript endpoint to Swagger UI.\n\n- Add `/youtube/transcript` POST endpoint to Swagger docs\n- Define `YouTubeRequest` schema with URL, language, timestamps fields\n- Define `YouTubeResponse` schema with transcript and metadata fields\n- Add API security requirement using ApiKeyAuth\n- Document 200, 400, and 500 response codes\n- Add godoc comments to YouTubeHandler struct methods\n- Include example values for all request/response properties","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-19T16:38:43Z","Parents":null},{"SHA":"ac57c3d2b02164d63b86e98c9b469f452471a1f5","Message":"chore: incoming 1889 changelog entry","Author":"Changelog Bot","Email":"","Date":"2025-12-19T18:42:38Z","Parents":null}]


title: Bundle yt-dlp with fabric in Nix flake, introduce slim variant
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1890
merged_at: 2025-12-20 07:55:46+00:00
created_at: 2025-12-20 07:58:09
body:
  # Bundle yt-dlp with fabric in Nix flake, introduce slim variant

  ## Summary

  This pull request updates the Nix flake configuration to bundle `yt-dlp` with the `fabric` package by default. It introduces a new `fabric-slim` variant for users who wish to provide their own dependencies, while the standard `fabric` package now ensures `yt-dlp` is available in its execution environment via a wrapper.

  ## Related issues

  Closes #1862 

  ## Screenshots

  <img width="881" height="325" alt="image" src="https://github.com/user-attachments/assets/8224b107-e24e-4602-845b-a4b8c4dd9702" />

  ## Files Changed

  - **cmd/generate_changelog/incoming/1890.txt**: Added a new changelog entry describing the bundling of `yt-dlp` and the introduction of the slim variant.
  - **flake.nix**: Refactored the package definitions to create a base `fabricSlim` package and a bundled `fabric` package using `symlinkJoin`.

  ## Code Changes

  ### flake.nix

  The core logic was updated to split the package into two variants. The original build logic is now assigned to `fabricSlim`:

  ```nix
            fabricSlim = pkgs.callPackage ./nix/pkgs/fabric {
              go = goVersion;
              inherit self;
              inherit (gomod2nix.legacyPackages.${system}) buildGoApplication;
            };
  ```

  A new `fabric` package is created by joining `fabricSlim` and `yt-dlp`, and then wrapping the binary to ensure `yt-dlp` is in the `PATH`:

  ```nix
            fabric = pkgs.symlinkJoin {
              name = "fabric-${fabricSlim.version}";
              inherit (fabricSlim) version;
              paths = [
                fabricSlim
                pkgs.yt-dlp
              ];
              nativeBuildInputs = [ pkgs.makeWrapper ];
              postBuild = ''
                wrapProgram $out/bin/fabric \
                  --prefix PATH : $out/bin
              '';
              meta = fabricSlim.meta // {
                description = "${fabricSlim.meta.description} (includes yt-dlp)";
                mainProgram = "fabric";
              };
            };
  ```

  The flake outputs were updated to export both versions:

  ```nix
          {
            default = fabric;
            inherit fabric;
            "fabric-slim" = fabricSlim;
            inherit (gomod2nix.legacyPackages.${system}) gomod2nix;
          }
  ```

  ## Reason for Changes

  Fabric utilizes `yt-dlp` for features involving YouTube content processing. Previously, Nix users had to install `yt-dlp` separately and ensure it was in their environment's `PATH`. By bundling it using `symlinkJoin` and `wrapProgram`, we provide a "batteries-included" experience that works out of the box, while still offering the `fabric-slim` version for users who prefer a minimal installation or manage their own dependencies.

  ## Impact of Changes

  - **User Experience**: Users installing the default `fabric` package via Nix will now automatically have `yt-dlp` available to the application.
  - **Package Size**: The default package size will increase as it now includes `yt-dlp` and its dependencies.
  - **Flexibility**: Users who require a minimal footprint can switch to the `fabric-slim` output.
  - **Maintainability**: The use of `symlinkJoin` keeps the Go build logic separate from the environment wrapping logic.

  ## Test Plan

  1. **Verify Default Build**: Run `nix build .#fabric` (or just `nix build`) and verify that the resulting `fabric` binary can successfully locate and execute `yt-dlp`.
  2. **Verify Slim Build**: Run `nix build .#fabric-slim` and verify that `yt-dlp` is not included in the resulting store path.
  3. **Path Check**: Inspect the wrapper script in `result/bin/fabric` to ensure the `PATH` is correctly prefixed with the bundled `yt-dlp` location.

  ```text
  $ nix run .#fabric -- -y https://youtube.com/watch?v=dQw4w9WgXcQ -p summarize

  ## ONE SENTENCE SUMMARY:
  A narrator professes enduring love and commitment, promising loyalty, honesty, and never abandoning a long-known partner.

  ## MAIN POINTS:
  1. The speaker insists both people understand love’s “rules” and expectations.
  2. A deep commitment is expressed as something uniquely offered by the narrator.
  3. The narrator wants their feelings clearly understood by the partner.
  4. Repeated vows emphasize never giving up on the relationship.
  5. Assurance is given against letting the partner down.
  6. The speaker rejects the idea of deserting or running around.
  7. Promises include not making the partner cry or say goodbye.
  8. Honesty is stressed through refusing to tell lies or intentionally hurt.
  9. Their long shared history is highlighted as the foundation of trust.
  10. The partner’s unspoken pain and shyness are acknowledged as already understood.

  ## TAKEAWAYS:
  1. Loyalty is portrayed as the central proof of love.
  2. Clear communication of emotions is framed as necessary for reassurance.
  3. Long-term relationships rely on mutual awareness of each other’s feelings.
  4. Consistency and repetition reinforce sincerity in commitments.
  5. Honesty and avoiding harm are presented as non-negotiable relationship standards.
  ```

  And. running the slim package:

  ```text
  $  nix run .#fabric-slim -- -y https://youtube.com/watch?v=dQw4w9WgXcQ -p summarize
  yt-dlp not found in PATH. Please install yt-dlp to use YouTube transcript functionality
  ```

  ## Additional Notes

  The `mainProgram` meta attribute was explicitly set on the bundled package to ensure compatibility with `nix run`. This change follows standard Nixpkgs patterns for wrapping binaries with runtime dependencies.

commits:
  [{"SHA":"333c8cd363b803e71f3c709c3d12b4606dedd1c9","Message":"feat: Nix: bundle yt-dlp with fabric package + fabric-slim variant\n\n- rename original fabric package to fabricSlim\n- create fabric package as symlinkJoin of fabricSlim and yt-dlp\n- add fabric-slim output for the slim variant\n- update default package to point to bundled fabric\n- enhance fabric meta description to note yt-dlp inclusion\n- set mainProgram to fabric in bundled package","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-20T06:27:07Z","Parents":null}]


title: Localize setup process and add funding configuration
author: ksylvan
author_url: https://github.com/ksylvan
author_type: user
url: https://github.com/danielmiessler/Fabric/pull/1895
merged_at: 2025-12-22 18:16:59+00:00
created_at: 2025-12-22 18:19:36
body:
  # Localize setup process and add funding configuration

  ## Summary

  This PR introduces localization support for the Fabric CLI setup process and adds funding configuration files. The changes enable multi-language support across the entire setup workflow, including prompts, error messages, and status updates for plugins, patterns, strategies, and other components.

  ## Related issues

  Closes #1885 

  ## Screenshots

  Before this fix:

  <img width="972" height="328" alt="image" src="https://github.com/user-attachments/assets/f4279c0b-7c89-41b0-b839-bde59547c9d4" />

  <img width="979" height="228" alt="image" src="https://github.com/user-attachments/assets/86d5cded-a65f-4adc-a64d-a849a1827977" />

  After the fix:

  <img width="989" height="318" alt="image" src="https://github.com/user-attachments/assets/46cfef53-05d5-459a-9b52-222de26a1dfe" />

  <img width="983" height="419" alt="image" src="https://github.com/user-attachments/assets/8b559b68-e4dc-49ec-9f9b-8ac55cdb4820" />


  ## Files Changed

  ### New Files

  #### `.github/FUNDING.yml`
  - Added GitHub Sponsors funding configuration
  - Enables sponsorship for contributors `danielmiessler` and `ksylvan`
  - Includes Buy Me a Coffee support for `kayvansylvan`

  #### `cmd/generate_changelog/incoming/1895.txt`
  - Changelog entry documenting the changes in this PR
  - Lists key features: funding configuration, localized setup prompts, and environment variable handling improvements

  ### Modified Files

  #### `internal/core/plugin_registry.go`
  - **Line 323**: Replaced hardcoded English string `"Enter the number of the plugin to setup"` with localized translation key `i18n.T("setup_plugin_prompt")`
  - Enables dynamic language selection for plugin setup prompts

  #### `internal/i18n/locales/*.json` (de, en, es, fa, fr, it, ja, pt-BR, pt-PT, zh)
  - **82 new translation keys added** to each language file
  - Comprehensive coverage for:
    - Plugin setup questions and validation messages
    - Pattern loader operations and error messages
    - Strategy downloader prompts and status updates
    - Default configuration prompts
    - Custom patterns, Jina AI, YouTube, and language settings
    - Required/optional field markers

  #### `internal/plugins/plugin.go`
  - **New method `AddSetupQuestionWithEnvName`** (lines 60-73): Allows explicit environment variable naming while using localized questions
  - **Updated `AddSetupQuestionCustom`** (line 60): Now uses `i18n.T("plugin_enter_value")`
  - **Updated `AddSetupQuestionCustomBool`** (line 85): Now uses `i18n.T("plugin_enable_bool_question")`
  - **Updated `SetupOrSkip`** (line 117): Uses localized skip message
  - **Updated `ParseBool`** (line 185): Uses localized error message
  - **Updated `Ask` method** (lines 206-210): All prompt variations now use localization
  - **Updated `OnAnswerWithReset`** (lines 226-236): Localized validation error messages
  - **Updated `IsValidErr`** (line 259): Localized error format
  - **Enhanced `BuildEnvVariable`** (lines 330-333): Now handles hyphenated plugin names by converting hyphens to underscores

  #### `internal/plugins/strategy/strategy.go`
  - All user-facing strings replaced with `i18n.T()` calls
  - Setup description, questions, status messages, and errors now localized
  - Examples: `"Strategies - Downloads Prompting Strategies"` → `i18n.T("strategies_setup_description")`

  #### `internal/tools/patterns_loader.go`
  - Complete localization of pattern download and management workflow
  - Status messages, progress indicators, warnings, and errors all localized
  - Migration path detection messages now translated
  - Example: `"Downloading patterns and Populating %s...\n"` → `i18n.T("patterns_downloading")`

  #### `internal/tools/custom_patterns/custom_patterns.go`
  - Localized setup description and directory question
  - Uses new `AddSetupQuestionWithEnvName` method to maintain stable environment variable names

  #### `internal/tools/defaults.go`
  - Localized default vendor and model configuration prompts
  - Setup description includes translated required marker

  #### `internal/tools/jina/jina.go`
  - Localized Jina AI setup description with optional marker

  #### `internal/tools/lang/language.go`
  - Localized language selection prompts and descriptions

  #### `internal/tools/youtube/youtube.go`
  - Localized YouTube setup description with optional marker

  ## Code Changes

  ### Key Implementation Pattern

  The localization follows a consistent pattern across all files:

  ```go
  // Before
  fmt.Printf("Enter the number of the plugin to setup")

  // After
  fmt.Printf(i18n.T("setup_plugin_prompt"))
  ```

  ### New Plugin Question Helper

  ```go
  func (o *PluginBase) AddSetupQuestionWithEnvName(envVarName string, required bool, question string) (ret *SetupQuestion) {
  	setting := o.AddSetting(envVarName, required)
  	ret = &SetupQuestion{Setting: setting, Question: question}
  	o.SetupQuestions = append(o.SetupQuestions, ret)
  	return
  }
  ```

  This method ensures environment variable names remain constant (e.g., `FABRIC_PATTERNS_GIT_REPO_URL`) while allowing localized question text.

  ### Environment Variable Handling Enhancement

  ```go
  func BuildEnvVariable(name string) string {
  	name = strings.TrimSpace(name)
  	name = strings.ToUpper(name)
  	name = strings.ReplaceAll(name, " ", "_")
  	name = strings.ReplaceAll(name, "-", "_")  // New: handles hyphenated names
  	return name
  }
  ```

  ## Reason for Changes

  1. **User Experience**: Enable non-English speakers to use Fabric CLI in their native language
  2. **Consistency**: Centralize all user-facing text through the i18n system
  3. **Maintainability**: Makes adding new languages easier by following established patterns
  4. **Funding Support**: Allow community members to support the project financially

  ## Impact of Changes

  ### Positive Impacts
  - **Global Accessibility**: Users can now set up Fabric in 10 languages (German, English, Spanish, Persian, French, Italian, Japanese, Portuguese (BR/PT), Chinese)
  - **Better UX**: Consistent translation approach across all setup workflows
  - **Future-Proof**: Framework supports easy addition of new languages
  - **Community Growth**: Funding options may increase contributor engagement

  ### Potential Issues
  1. **Translation Quality**: Automated translations may need native speaker review for accuracy
  2. **Environment Variables**: The new hyphen-to-underscore conversion in `BuildEnvVariable` changes behavior for plugin names containing hyphens (e.g., "jina-ai" → "JINA_AI" instead of "JINA-AI")
  3. **String Interpolation**: Format strings with `%s`, `%v`, `%w` placeholders require translators to maintain correct placeholder positions
  4. **Backward Compatibility**: Existing environment variable names remain unchanged, but new hyphenated plugin names will use underscores

  ## Test Plan

  **Manual Testing Required:**

  1. **Language Switching**
     - Test each supported language (de, es, fa, fr, it, ja, pt-BR, pt-PT, zh)
     - Run `fabric --setup` and verify all prompts appear in the selected language. For example:
     
     ```bash
     fabric -g de --setup
     ```

  2. **Plugin Setup**
     - Test each plugin setup workflow (AI vendors, patterns, strategies, YouTube, Jina)
     - Verify all questions, validation messages, and success/error messages are localized

  3. **Environment Variables**
     - Verify that plugin names with hyphens generate correct environment variables (underscores instead of hyphens)
     - Confirm existing configurations continue to work

  4. **Error Handling**
     - Trigger various error conditions (invalid paths, network failures, missing permissions)
     - Verify error messages are properly localized with correct parameter substitution

  5. **Pattern and Strategy Downloads**
     - Test pattern download and migration scenarios
     - Verify all progress messages and status updates are localized

  6. **Funding Links**
     - Check that GitHub displays funding options correctly
     - Verify links to GitHub Sponsors and Buy Me a Coffee work

  ## Additional Notes

  - **Translation Coverage**: All 10 supported languages have identical translation key sets, ensuring feature parity
  - **Developer Impact**: New console output should use `i18n.T()` instead of hardcoded strings
  - **Missing Translations**: If a translation key is missing, the system falls back to the key name itself
  - **String Format Preservation**: Care was taken to preserve printf-style format specifiers (`%s`, `%v`, `%w`) in all translations

commits:
  [{"SHA":"7570e7930bf3f014b3b78a6a3723320be342dfb3","Message":"feat: localize setup process and add funding configuration\n\n- Add GitHub and Buy Me a Coffee funding configuration.\n- Localize setup prompts and error messages across multiple languages.\n- Implement helper for localized questions with static environment keys.\n- Update environment variable builder to handle hyphenated plugin names.\n- Replace hardcoded console output with localized i18n translation strings.\n- Expand locale files with comprehensive pattern and strategy translations.\n- Add new i18n keys for optional and required markers\n- Remove hardcoded `[required]` markers from description strings\n- Add custom patterns, Jina AI, YouTube, and language labels\n- Switch plugin descriptions to use i18n translation keys\n- Append markers dynamically to setup descriptions in Go code\n- Remove trailing newlines from plugin question prompt strings\n- Standardize all locale files with consistent formatting changes","Author":"Kayvan Sylvan","Email":"","Date":"2025-12-22T07:52:22Z","Parents":null}]


