n2b 0.5.0 → 0.5.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: d512a4b43acc8a3adac6fe3fd60d05605abef697b36e0beb2e896371c6ae94c0
-  data.tar.gz: 140274359582046b03b89521d143e7efc498c07ee85c6cd200de821191b0b0db
+  metadata.gz: 58ed8c5277d383ecd58f83b79a90e2328161c1cb45dfa70551facef28641d3f1
+  data.tar.gz: 109d222d1867e76458a6b720c2afe3196c37fcab0648773d0311157c04c63086
 SHA512:
-  metadata.gz: '0184eb2ae93e21a1a389f7445c5e1d3532f645f5164df29ba7acc77ce67e163b8a273767aadc7a3b1ccab8483ae62d7e75b691331cb9145f4075a5a3aa3777ae'
-  data.tar.gz: d12e12c75dc2e6b161fb9f169de0a2dd7a8760bdcdf49b915c217407937516cffca31fb5649c5b65e33b81f7c02d688c7695c9c7cf4f5c638d837756c3ce97e5
+  metadata.gz: c623f7a497b81bec3edf136d18d4ef2f64578bf347334e91dec4feaf01a43dc0deb374d5da74aa0e513b669f55315a835b7c36588e82221dde8d62c8a7728746
+  data.tar.gz: d4687399cf5e2e9d62fca484616bbd48d9c74b03f6c5266e31362978efb44ea4c13fa44708c5097704c9ca63e0616693b016eb79aa97da2bf664f6e18ff7d431

data/lib/n2b/jira_client.rb

@@ -111,6 +111,75 @@ module N2B
       end
     end
 
+    def extract_requirements_from_description(description_string)
+      extracted_lines = []
+      in_requirements_section = false
+
+      # Headers that trigger requirement extraction. Case-insensitive.
+      # Jira often uses h1, h2, etc. for headers, or bold text.
+      # We'll look for lines that *start* with these, possibly after Jira's header markup like "hN. "
+      # Or common text like "Acceptance Criteria:", "Requirements:"
+      # Also include comment-specific implementation keywords
+      requirement_headers_regex = /^(h[1-6]\.\s*)?(Requirements|Acceptance Criteria|Tasks|Key Deliverables|Scope|User Stories|Implementation|Testing|Technical|Additional|Clarification|Comment \d+)/i
+
+      # Regex to identify common list item markers
+      _list_item_regex = /^\s*[\*\-\+]\s+/ # Unused but kept for potential future use
+      # Regex for lines that look like section headers (to stop capturing)
+      # This is a simple heuristic: a line with a few words, ending with a colon, or Jira hN. style
+      section_break_regex = /^(h[1-6]\.\s*)?\w+(\s+\w+){0,3}:?\s*$/i
+
+
+      description_string.to_s.each_line do |line| # Handle nil description_string
+        stripped_line = line.strip
+
+        if stripped_line.match?(requirement_headers_regex)
+          in_requirements_section = true
+          # Add the header itself to the extracted content if desired, or just use it as a trigger
+          # For now, let's add the line to give context.
+          extracted_lines << stripped_line
+          next # Move to the next line
+        end
+
+        if in_requirements_section
+          # If we encounter another significant header, stop capturing this section
+          # (unless it's another requirements header, which is fine)
+          if stripped_line.match?(section_break_regex) && !stripped_line.match?(requirement_headers_regex)
+            # Check if this new header is one of the requirement types. If so, continue.
+            # Otherwise, break. This logic is simplified: if it's any other header, stop.
+            is_another_req_header = false # Placeholder for more complex logic if needed
+            requirement_headers_regex.match(stripped_line) { is_another_req_header = true }
+
+            unless is_another_req_header
+              in_requirements_section = false # Stop capturing
+              # Potentially add a separator if concatenating multiple distinct sections later
+              # extracted_lines << "---"
+              next # Don't include this new non-req header in current section
+            else
+              # It's another requirement-related header, so add it and continue
+              extracted_lines << stripped_line
+              next
+            end
+          end
+
+          # Capture list items or general text within the section
+          # For now, we are quite inclusive of lines within a detected section.
+          # We could be more strict and only take list_item_regex lines,
+          # but often text paragraphs under a heading are relevant too.
+          extracted_lines << stripped_line unless stripped_line.empty?
+        end
+      end
+
+      if extracted_lines.empty?
+        # Fallback: return the entire description if no specific sections found
+        return description_string.to_s.strip # Handle nil and strip
+      else
+        # Join extracted lines and clean up excessive newlines
+        # Replace 3+ newlines with 2, and 2+ newlines with 2 (effectively max 2 newlines)
+        # Also, strip leading/trailing whitespace from the final result.
+        return extracted_lines.join("\n").gsub(/\n{3,}/, "\n\n").gsub(/\n{2,}/, "\n\n").strip
+      end
+    end
+
     private
 
     def process_ticket_data(ticket_data, comments_data)
@@ -327,75 +396,6 @@ module N2B
       end
     end
 
-    def extract_requirements_from_description(description_string)
-      extracted_lines = []
-      in_requirements_section = false
-
-      # Headers that trigger requirement extraction. Case-insensitive.
-      # Jira often uses h1, h2, etc. for headers, or bold text.
-      # We'll look for lines that *start* with these, possibly after Jira's header markup like "hN. "
-      # Or common text like "Acceptance Criteria:", "Requirements:"
-      # Also include comment-specific implementation keywords
-      requirement_headers_regex = /^(h[1-6]\.\s*)?(Requirements|Acceptance Criteria|Tasks|Key Deliverables|Scope|User Stories|Implementation|Testing|Technical|Additional|Clarification|Comment \d+)/i
-
-      # Regex to identify common list item markers
-      _list_item_regex = /^\s*[\*\-\+]\s+/ # Unused but kept for potential future use
-      # Regex for lines that look like section headers (to stop capturing)
-      # This is a simple heuristic: a line with a few words, ending with a colon, or Jira hN. style
-      section_break_regex = /^(h[1-6]\.\s*)?\w+(\s+\w+){0,3}:?\s*$/i
-
-
-      description_string.to_s.each_line do |line| # Handle nil description_string
-        stripped_line = line.strip
-
-        if stripped_line.match?(requirement_headers_regex)
-          in_requirements_section = true
-          # Add the header itself to the extracted content if desired, or just use it as a trigger
-          # For now, let's add the line to give context.
-          extracted_lines << stripped_line
-          next # Move to the next line
-        end
-
-        if in_requirements_section
-          # If we encounter another significant header, stop capturing this section
-          # (unless it's another requirements header, which is fine)
-          if stripped_line.match?(section_break_regex) && !stripped_line.match?(requirement_headers_regex)
-            # Check if this new header is one of the requirement types. If so, continue.
-            # Otherwise, break. This logic is simplified: if it's any other header, stop.
-            is_another_req_header = false # Placeholder for more complex logic if needed
-            requirement_headers_regex.match(stripped_line) { is_another_req_header = true }
-
-            unless is_another_req_header
-              in_requirements_section = false # Stop capturing
-              # Potentially add a separator if concatenating multiple distinct sections later
-              # extracted_lines << "---"
-              next # Don't include this new non-req header in current section
-            else
-              # It's another requirement-related header, so add it and continue
-              extracted_lines << stripped_line
-              next
-            end
-          end
-
-          # Capture list items or general text within the section
-          # For now, we are quite inclusive of lines within a detected section.
-          # We could be more strict and only take list_item_regex lines,
-          # but often text paragraphs under a heading are relevant too.
-          extracted_lines << stripped_line unless stripped_line.empty?
-        end
-      end
-
-      if extracted_lines.empty?
-        # Fallback: return the entire description if no specific sections found
-        return description_string.to_s.strip # Handle nil and strip
-      else
-        # Join extracted lines and clean up excessive newlines
-        # Replace 3+ newlines with 2, and 2+ newlines with 2 (effectively max 2 newlines)
-        # Also, strip leading/trailing whitespace from the final result.
-        return extracted_lines.join("\n").gsub(/\n{3,}/, "\n\n").gsub(/\n{2,}/, "\n\n").strip
-      end
-    end
-
     private
 
     def format_comment_as_adf(comment_data)

data/lib/n2b/llm/ollama.rb

@@ -88,7 +88,7 @@ module N2M
         # The prompt_content for diff analysis should instruct the LLM to return JSON.
         # For Ollama, you can also try adding "format": "json" to the request if the model supports it.
         request_body = {
-          "model" => @config['model'] || MODELS.keys.first,
+          "model" => get_model_name,
           "messages" => [
             {
               "role" => "user",

data/lib/n2b/version.rb

@@ -1,4 +1,4 @@
 # lib/n2b/version.rb
 module N2B
-  VERSION = "0.5.0"
+  VERSION = "0.5.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: n2b
 version: !ruby/object:Gem::Version
-  version: 0.5.0
+  version: 0.5.1
 platform: ruby
 authors:
 - Stefan Nothegger
@@ -53,7 +53,7 @@ dependencies:
       - !ruby/object:Gem::Version
         version: '13.0'
 description: A tool to convert natural language instructions to bash commands using
-  Claude API or OpenAI's GPT. also is q quick helper in the console to provide ruby
+  Claude API or OpenAI's GPT. also is a quick helper in the console to provide ruby
   code snippets and explanations or debug exceptions.
 email:
 - stefan@kaproblem.com