{"results":{"result":{"added-files":{"code-health":8.267299710538001,"old-code-health":0.0,"files":[{"file":"crates/harnx-mcp-plans-core/src/conformance.rs","loc":895,"code-health":7.169471385350732},{"file":"crates/harnx-mcp-plans-core/src/server/handler.rs","loc":149,"code-health":9.598006916836821},{"file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","loc":901,"code-health":5.660402510836792},{"file":"crates/harnx-mcp-plans-core/src/server/mod.rs","loc":224,"code-health":8.816158827775617},{"file":"crates/harnx-mcp-plans-github/src/auth.rs","loc":575,"code-health":10.0},{"file":"crates/harnx-mcp-plans-github/src/client.rs","loc":684,"code-health":8.679575849015766},{"file":"crates/harnx-mcp-plans-github/src/codec.rs","loc":805,"code-health":9.6882083290695},{"file":"crates/harnx-mcp-plans-github/src/config.rs","loc":571,"code-health":8.125477026960358},{"file":"crates/harnx-mcp-plans-github/src/main.rs","loc":7,"code-health":10.0},{"file":"crates/harnx-mcp-plans-github/src/ratelimit.rs","loc":451,"code-health":9.387218218812514},{"file":"crates/harnx-mcp-plans-github/src/runtime.rs","loc":266,"code-health":9.592551999935852},{"file":"crates/harnx-mcp-plans-github/src/store_github.rs","loc":757,"code-health":7.106711345609554},{"file":"crates/harnx-mcp-plans-github/src/store_github/tests.rs","loc":945,"code-health":8.283981080161325},{"file":"crates/harnx-mcp-plans-github/tests/conformance_github.rs","loc":473,"code-health":8.339665408214998},{"file":"crates/harnx-mcp-plans-github/tests/github_specific.rs","loc":382,"code-health":9.387218218812514},{"file":"crates/harnx-mcp-plans-github/tests/live_e2e.rs","loc":274,"code-health":8.997354731618337}]},"external-review-url":"https://github.com/dobesv/harnx/pull/1023","old-code-health":0.0,"modified-files":{"code-health":0.0,"old-code-health":0.0,"files":[]},"removed-files":{"code-health":0.0,"old-code-health":0.0,"files":[]},"external-review-id":"1023","analysis-time":"2026-07-10T17:25:10Z","negative-impact-count":41,"suppressions":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"affected-hotspots":0,"commits":["247cdb1bd3ba136471f2c3253d1e88daa4ccdc29"],"is-negative-review":true,"negative-findings":{"number-of-types":9,"number-of-files-touched":14,"findings":[{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-core/src/conformance.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":118,"what-changed":"The module contains 8 functions with similar structure: assert_deleted_plan_contract,assert_deleted_task_contract,collect_all_plans,collect_all_tasks and 4 more functions","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"method":"test_task_crud","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-core/src/conformance.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":367,"what-changed":"test_task_crud has 101 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"method":"test_note_crud","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-core/src/conformance.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":691,"what-changed":"test_note_crud has 84 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"method":"test_plan_crud","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-core/src/conformance.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":199,"what-changed":"test_plan_crud has 82 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"method":"test_body_edits","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-core/src/conformance.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":830,"what-changed":"test_body_edits has 78 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"method":"test_plan_list_pagination","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"crates/harnx-mcp-plans-core/src/conformance.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":288,"what-changed":"test_plan_list_pagination has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"PlansServer.call_tool","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-core/src/server/handler.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":82,"what-changed":"PlansServer.call_tool has 72 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"why-it-occurs":"Cohesion is a measure of how well the elements in a file belong together. CodeScene measures cohesion using the LCOM4 metric (Lack of Cohesion Measure). With LCOM4, the functions inside a module are related if a) they access the same data members, or b) they call each other. High Cohesion is desirable as it means that all functions are related and likely to represent the same responsibility. Low Cohesion is problematic since it means that the module contains multiple behaviors. Low Cohesion leads to code that's harder to understand, requires more tests, and very often become a coordination magnet for developers.","name":"Low Cohesion","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":[{"diff":"diff --git a/low_cohesion_example.js b/low_cohesion_example.js\nindex 1ae56cf85b..209fc02c73 100644\n--- a/low_cohesion_example.js\n+++ b/low_cohesion_example.js\n@@ -2,8 +2,10 @@\n \n var userLayer = connectUsers(myConnectionProperties);\n \n-var chessEngine = startEngine(gameProperties);\n+// [Refactoring: moved the data related to chess to a new chessGame.js module]\n \n+// The module contains login related functionality that forms one behaviour: all\n+// code is related since it either a) uses the same data, or b) calls the same functions.\n export function login(newUser) {\n   val authenticated = userLayer.authenticate(newUser);\n   traceLoginFor(authenticated);\n@@ -19,11 +21,6 @@ function traceLogin(user) {\n    // ...some code...\n }\n \n-// playChess seems like a very unrelated responsibility.\n-// Should it really be within the same module?\n-\n-export function playChess(loggedInUser) {\n-   var board = chessEngine.newBoard();\n-\n-   return newGameOn(board, loggedInUser);\n-}\n+// [Refactoring: moved playChess to a new chessGame.js module\n+// As a result of this refactoring, the module maintains a\n+// single behavior where all code and data is related: high cohesion.]\n","language":"rust","improvement-type":"Low Cohesion"}],"change-level":"warning","is-hotspot?":false,"what-changed":"This module has at least 4 different responsibilities amongst its 26 functions, threshold = 3","how-to-fix":"Look to modularize the code by splitting the file into more cohesive units; functions that belong together should still be located together. A common refactoring is [EXTRACT CLASS](https://refactoring.com/catalog/extractClass.html).","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":69,"what-changed":"The module contains 12 functions with similar structure: PlansServer.handle_delete_note,PlansServer.handle_delete_task,PlansServer.handle_get_note,PlansServer.handle_get_task and 8 more functions","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"method":"PlansServer.handle_delete_plan","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the Rust language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"rust","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":672,"what-changed":"PlansServer.handle_delete_plan has a cyclomatic complexity of 9, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"PlansServer.handle_update_plan","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the Rust language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"rust","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":544,"what-changed":"PlansServer.handle_update_plan has a cyclomatic complexity of 9, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"PlansServer.handle_add_plan","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":424,"what-changed":"PlansServer.handle_add_plan has 74 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"method":"PlansServer.handle_delete_plan","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":672,"what-changed":"PlansServer.handle_delete_plan has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"PlansServer.handle_add_plan","why-it-occurs":"Deep nested logic means that you have control structures like if-statements or loops inside other control structures. Deep nested logic increases the cognitive load on the programmer reading the code. The human working memory has a maximum capacity of 3-4 items; beyond that threshold, we struggle with keeping things in our head. Consequently, deep nested logic has a strong correlation to defects and accounts for roughly 20% of all programming mistakes.\n\nCodeScene measures the maximum nesting depth inside each function. The deeper the nesting, the lower the code health. The threshold for the Rust language is 4 levels of nesting.","name":"Deep, Nested Complexity","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":424,"what-changed":"PlansServer.handle_add_plan has a nested complexity depth of 4, threshold = 4","how-to-fix":"Occassionally, it's possible to get rid of the nested logic by [Replacing Conditionals with Guard Clauses](https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html).\n\nAnother viable strategy is to identify smaller building blocks inside the nested chunks of logic and extract those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring explains the steps.","change-type":"introduced"},{"method":"PlansServer.handle_update_plan","why-it-occurs":"Deep nested logic means that you have control structures like if-statements or loops inside other control structures. Deep nested logic increases the cognitive load on the programmer reading the code. The human working memory has a maximum capacity of 3-4 items; beyond that threshold, we struggle with keeping things in our head. Consequently, deep nested logic has a strong correlation to defects and accounts for roughly 20% of all programming mistakes.\n\nCodeScene measures the maximum nesting depth inside each function. The deeper the nesting, the lower the code health. The threshold for the Rust language is 4 levels of nesting.","name":"Deep, Nested Complexity","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":544,"what-changed":"PlansServer.handle_update_plan has a nested complexity depth of 4, threshold = 4","how-to-fix":"Occassionally, it's possible to get rid of the nested logic by [Replacing Conditionals with Guard Clauses](https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html).\n\nAnother viable strategy is to identify smaller building blocks inside the nested chunks of logic and extract those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring explains the steps.","change-type":"introduced"},{"method":"apply_body_edit","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the Rust language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"crates/harnx-mcp-plans-core/src/server/handlers.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":3,"what-changed":"apply_body_edit has 5 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"validate_plan_name","why-it-occurs":"A complex conditional is an expression inside a branch such as an <code>if</code>-statmeent which consists of multiple, logical operations. Example: <code>if (x.started() && y.running())</code>.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"crates/harnx-mcp-plans-core/src/server/mod.rs","refactoring-examples":[{"diff":"diff --git a/complex_conditional.js b/complex_conditional.js\nindex c43da09584..94259ce874 100644\n--- a/complex_conditional.js\n+++ b/complex_conditional.js\n@@ -1,16 +1,34 @@\n function messageReceived(message, timeReceived) {\n-   // Ignore all messages which aren't from known customers:\n-   if (!message.sender &&\n-       customers.getId(message.name) == null) {\n+   // Refactoring #1: encapsulate the business rule in a\n+   // function. A clear name replaces the need for the comment:\n+   if (!knownCustomer(message)) {\n      log('spam received -- ignoring');\n      return;\n    }\n \n-  // Provide an auto-reply when outside business hours:\n-  if ((timeReceived.getHours() > 17) ||\n-      (timeReceived.getHours() < 8)) {\n+  // Refactoring #2: encapsulate the business rule.\n+  // Again, note how a clear function name replaces the\n+  // need for a code comment:\n+  if (outsideBusinessHours(timeReceived)) {\n     return autoReplyTo(message);\n   }\n \n   pingAgentFor(message);\n+}\n+\n+function outsideBusinessHours(timeReceived) {\n+  // Refactoring #3: replace magic numbers with\n+  // symbols that communicate with the code reader:\n+  const closingHour = 17;\n+  const openingHour = 8;\n+\n+  const hours = timeReceived.getHours();\n+\n+  // Refactoring #4: simple conditional rules can\n+  // be further clarified by introducing a variable:\n+  const afterClosing = hours > closingHour;\n+  const beforeOpening = hours < openingHour;\n+\n+  // Yeah -- look how clear the business rule is now!\n+  return afterClosing || beforeOpening;\n }\n\\ No newline at end of file\n","language":"rust","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":85,"what-changed":"validate_plan_name has 1 complex conditionals with 2 branches, threshold = 2","how-to-fix":"Apply the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.","change-type":"introduced"},{"method":"validate_id","why-it-occurs":"A complex conditional is an expression inside a branch such as an <code>if</code>-statmeent which consists of multiple, logical operations. Example: <code>if (x.started() && y.running())</code>.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"crates/harnx-mcp-plans-core/src/server/mod.rs","refactoring-examples":[{"diff":"diff --git a/complex_conditional.js b/complex_conditional.js\nindex c43da09584..94259ce874 100644\n--- a/complex_conditional.js\n+++ b/complex_conditional.js\n@@ -1,16 +1,34 @@\n function messageReceived(message, timeReceived) {\n-   // Ignore all messages which aren't from known customers:\n-   if (!message.sender &&\n-       customers.getId(message.name) == null) {\n+   // Refactoring #1: encapsulate the business rule in a\n+   // function. A clear name replaces the need for the comment:\n+   if (!knownCustomer(message)) {\n      log('spam received -- ignoring');\n      return;\n    }\n \n-  // Provide an auto-reply when outside business hours:\n-  if ((timeReceived.getHours() > 17) ||\n-      (timeReceived.getHours() < 8)) {\n+  // Refactoring #2: encapsulate the business rule.\n+  // Again, note how a clear function name replaces the\n+  // need for a code comment:\n+  if (outsideBusinessHours(timeReceived)) {\n     return autoReplyTo(message);\n   }\n \n   pingAgentFor(message);\n+}\n+\n+function outsideBusinessHours(timeReceived) {\n+  // Refactoring #3: replace magic numbers with\n+  // symbols that communicate with the code reader:\n+  const closingHour = 17;\n+  const openingHour = 8;\n+\n+  const hours = timeReceived.getHours();\n+\n+  // Refactoring #4: simple conditional rules can\n+  // be further clarified by introducing a variable:\n+  const afterClosing = hours > closingHour;\n+  const beforeOpening = hours < openingHour;\n+\n+  // Yeah -- look how clear the business rule is now!\n+  return afterClosing || beforeOpening;\n }\n\\ No newline at end of file\n","language":"rust","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":96,"what-changed":"validate_id has 1 complex conditionals with 4 branches, threshold = 2","how-to-fix":"Apply the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.","change-type":"introduced"},{"why-it-occurs":"String is a generic type that fail to capture the constraints of the domain object it represents. In this module, 57 % of all function arguments are string types.","name":"String Heavy Function Arguments","file":"crates/harnx-mcp-plans-core/src/server/mod.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"In this module, 56.5% of all arguments to its 18 functions are strings. The threshold for string arguments is 39.0%","how-to-fix":"Heavy string usage indicates a missing domain language. Introduce data types that encapsulate the semantics. For example, a user_name is better represented as a constrained User type rather than a pure string, which could be anything.","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-github/src/client.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":294,"what-changed":"The module contains 7 functions with similar structure: GitHubClient.add_sub_issue,GitHubClient.create_comment,GitHubClient.get_json,GitHubClient.patch_json and 3 more functions","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"method":"GitHubClient.ensure_label","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"crates/harnx-mcp-plans-github/src/client.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":459,"what-changed":"GitHubClient.ensure_label has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"issue_to_plan","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the Rust language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"crates/harnx-mcp-plans-github/src/codec.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":245,"what-changed":"issue_to_plan has 5 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"issue_to_task","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the Rust language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"crates/harnx-mcp-plans-github/src/codec.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":355,"what-changed":"issue_to_task has 6 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"method":"AppConfig.parse_from_with","why-it-occurs":"A Complex Method has a high cyclomatic complexity. The recommended threshold for the Rust language is a cyclomatic complexity lower than 9.","name":"Complex Method","file":"crates/harnx-mcp-plans-github/src/config.rs","refactoring-examples":[{"diff":"diff --git a/complex_method.js b/complex_method.js\nindex 10cce78e6d..0c1a8cabaf 100644\n--- a/complex_method.js\n+++ b/complex_method.js\n@@ -1,15 +1,20 @@\n function postItem(item) {\n   if (!item.id) {\n-    if (item.x != null && item.y != null) {\n-      post(item);\n-    } else {\n-      throw Error(\"Item must have x and y\");\n-    }\n+    // extract a separate function for creating new item\n+    postNew(item);\n   } else {\n-    if (item.x < 10 && item.y > 25) {\n-      put(item);\n-    } else {\n-      throw Error(\"Item must have an x and y value between 10 and 25\");\n-    }\n+    // and one for updating existing items\n+    updateItem(item);\n   }\n }\n+\n+function postNew(item) {\n+  validateNew(item);\n+  post(item);\n+}\n+\n+function updateItem(item) {\n+  validateUpdate(item);\n+  put(item);\n+}\n+\n","language":"rust","improvement-type":"Complex Method"}],"change-level":"warning","is-hotspot?":false,"line":48,"what-changed":"AppConfig.parse_from_with has a cyclomatic complexity of 18, threshold = 9","how-to-fix":"There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html). Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring.","change-type":"introduced"},{"method":"parse_owner_repo_path","why-it-occurs":"A complex conditional is an expression inside a branch such as an <code>if</code>-statmeent which consists of multiple, logical operations. Example: <code>if (x.started() && y.running())</code>.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.","name":"Complex Conditional","file":"crates/harnx-mcp-plans-github/src/config.rs","refactoring-examples":[{"diff":"diff --git a/complex_conditional.js b/complex_conditional.js\nindex c43da09584..94259ce874 100644\n--- a/complex_conditional.js\n+++ b/complex_conditional.js\n@@ -1,16 +1,34 @@\n function messageReceived(message, timeReceived) {\n-   // Ignore all messages which aren't from known customers:\n-   if (!message.sender &&\n-       customers.getId(message.name) == null) {\n+   // Refactoring #1: encapsulate the business rule in a\n+   // function. A clear name replaces the need for the comment:\n+   if (!knownCustomer(message)) {\n      log('spam received -- ignoring');\n      return;\n    }\n \n-  // Provide an auto-reply when outside business hours:\n-  if ((timeReceived.getHours() > 17) ||\n-      (timeReceived.getHours() < 8)) {\n+  // Refactoring #2: encapsulate the business rule.\n+  // Again, note how a clear function name replaces the\n+  // need for a code comment:\n+  if (outsideBusinessHours(timeReceived)) {\n     return autoReplyTo(message);\n   }\n \n   pingAgentFor(message);\n+}\n+\n+function outsideBusinessHours(timeReceived) {\n+  // Refactoring #3: replace magic numbers with\n+  // symbols that communicate with the code reader:\n+  const closingHour = 17;\n+  const openingHour = 8;\n+\n+  const hours = timeReceived.getHours();\n+\n+  // Refactoring #4: simple conditional rules can\n+  // be further clarified by introducing a variable:\n+  const afterClosing = hours > closingHour;\n+  const beforeOpening = hours < openingHour;\n+\n+  // Yeah -- look how clear the business rule is now!\n+  return afterClosing || beforeOpening;\n }\n\\ No newline at end of file\n","language":"rust","improvement-type":"Complex Conditional"}],"change-level":"warning","is-hotspot?":false,"line":218,"what-changed":"parse_owner_repo_path has 1 complex conditionals with 2 branches, threshold = 2","how-to-fix":"Apply the [DECOMPOSE CONDITIONAL](https://refactoring.com/catalog/decomposeConditional.html) refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.","change-type":"introduced"},{"method":"AppConfig.parse_from_with","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"crates/harnx-mcp-plans-github/src/config.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":48,"what-changed":"AppConfig.parse_from_with has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"why-it-occurs":"String is a generic type that fail to capture the constraints of the domain object it represents. In this module, 52 % of all function arguments are string types.","name":"String Heavy Function Arguments","file":"crates/harnx-mcp-plans-github/src/config.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"In this module, 51.7% of all arguments to its 18 functions are strings. The threshold for string arguments is 39.0%","how-to-fix":"Heavy string usage indicates a missing domain language. Introduce data types that encapsulate the semantics. For example, a user_name is better represented as a constrained User type rather than a pure string, which could be anything.","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-github/src/config.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":411,"what-changed":"The module contains 3 functions with similar structure: tests.parse_base_url_trims_trailing_slash,tests.parse_delete_behavior_leave,tests.parse_http_defaults_to_loopback_host","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-github/src/ratelimit.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":287,"what-changed":"The module contains 2 functions with similar structure: tests.retries_on_reset_header_then_succeeds,tests.retries_on_retry_after_then_succeeds","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"method":"run_http","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-github/src/runtime.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":163,"what-changed":"run_http has 73 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"why-it-occurs":"Cohesion is a measure of how well the elements in a file belong together. CodeScene measures cohesion using the LCOM4 metric (Lack of Cohesion Measure). With LCOM4, the functions inside a module are related if a) they access the same data members, or b) they call each other. High Cohesion is desirable as it means that all functions are related and likely to represent the same responsibility. Low Cohesion is problematic since it means that the module contains multiple behaviors. Low Cohesion leads to code that's harder to understand, requires more tests, and very often become a coordination magnet for developers.","name":"Low Cohesion","file":"crates/harnx-mcp-plans-github/src/store_github.rs","refactoring-examples":[{"diff":"diff --git a/low_cohesion_example.js b/low_cohesion_example.js\nindex 1ae56cf85b..209fc02c73 100644\n--- a/low_cohesion_example.js\n+++ b/low_cohesion_example.js\n@@ -2,8 +2,10 @@\n \n var userLayer = connectUsers(myConnectionProperties);\n \n-var chessEngine = startEngine(gameProperties);\n+// [Refactoring: moved the data related to chess to a new chessGame.js module]\n \n+// The module contains login related functionality that forms one behaviour: all\n+// code is related since it either a) uses the same data, or b) calls the same functions.\n export function login(newUser) {\n   val authenticated = userLayer.authenticate(newUser);\n   traceLoginFor(authenticated);\n@@ -19,11 +21,6 @@ function traceLogin(user) {\n    // ...some code...\n }\n \n-// playChess seems like a very unrelated responsibility.\n-// Should it really be within the same module?\n-\n-export function playChess(loggedInUser) {\n-   var board = chessEngine.newBoard();\n-\n-   return newGameOn(board, loggedInUser);\n-}\n+// [Refactoring: moved playChess to a new chessGame.js module\n+// As a result of this refactoring, the module maintains a\n+// single behavior where all code and data is related: high cohesion.]\n","language":"rust","improvement-type":"Low Cohesion"}],"change-level":"warning","is-hotspot?":false,"what-changed":"This module has at least 9 different responsibilities amongst its 48 functions, threshold = 3","how-to-fix":"Look to modularize the code by splitting the file into more cohesive units; functions that belong together should still be located together. A common refactoring is [EXTRACT CLASS](https://refactoring.com/catalog/extractClass.html).","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-github/src/store_github.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":122,"what-changed":"The module contains 17 functions with similar structure: GitHubPlanStore.decode_issue_to_plan,GitHubPlanStore.decode_issue_to_task,GitHubPlanStore.dedupe_notes,GitHubPlanStore.dedupe_tasks and 13 more functions","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-github/src/store_github/tests.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":19,"what-changed":"The module contains 13 functions with similar structure: create_test_store,create_test_store_with_config,dedupe_tie_break_prefers_higher_issue_number,delete_note_deletes_comment and 9 more functions","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"method":"mock_issue_with_labels_json","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the Rust language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"crates/harnx-mcp-plans-github/src/store_github/tests.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":74,"what-changed":"mock_issue_with_labels_json has 5 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"why-it-occurs":"String is a generic type that fail to capture the constraints of the domain object it represents. In this module, 43 % of all function arguments are string types.","name":"String Heavy Function Arguments","file":"crates/harnx-mcp-plans-github/src/store_github/tests.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"what-changed":"In this module, 42.9% of all arguments to its 29 functions are strings. The threshold for string arguments is 39.0%","how-to-fix":"Heavy string usage indicates a missing domain language. Introduce data types that encapsulate the semantics. For example, a user_name is better represented as a constrained User type rather than a pure string, which could be anything.","change-type":"introduced"},{"method":"mount_mock_handlers","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-github/tests/conformance_github.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":257,"what-changed":"mount_mock_handlers has 238 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"},{"method":"issue_body_from_request","why-it-occurs":"A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.\n\nA bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is  levels of conditionals.","name":"Bumpy Road Ahead","file":"crates/harnx-mcp-plans-github/tests/conformance_github.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":203,"what-changed":"issue_body_from_request has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function","how-to-fix":"Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the [Bumpy Road code health issue](https://codescene.com/blog/bumpy-road-code-complexity-in-context/).\n\nA Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring is the primary response.","change-type":"introduced"},{"method":"MockGitHubState.update_issue","why-it-occurs":"Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.\n\nThe threshold for the Rust language is 4 function arguments.","name":"Excess Number of Function Arguments","file":"crates/harnx-mcp-plans-github/tests/conformance_github.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":90,"what-changed":"MockGitHubState.update_issue has 5 arguments, max arguments = 4","how-to-fix":"Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring [INTRODUCE PARAMETER OBJECT](https://refactoring.com/catalog/introduceParameterObject.html) to encapsulate arguments that refer to the same logical concept.","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-github/tests/github_specific.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":45,"what-changed":"The module contains 2 functions with similar structure: mock_issue_response,mock_plan_issue_response","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"why-it-occurs":"Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.","name":"Code Duplication","file":"crates/harnx-mcp-plans-github/tests/live_e2e.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":144,"what-changed":"The module contains 2 functions with similar structure: live_e2e_create_note,live_e2e_create_task","how-to-fix":"A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. [Read More](https://codescene.com/blog/software-revolution-part3/)\n\nOnce you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.","change-type":"introduced"},{"method":"live_e2e_full_crud_cycle","why-it-occurs":"Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.","name":"Large Method","file":"crates/harnx-mcp-plans-github/tests/live_e2e.rs","refactoring-examples":null,"change-level":"warning","is-hotspot?":false,"line":281,"what-changed":"live_e2e_full_crud_cycle has 75 lines, threshold = 70","how-to-fix":"We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the [EXTRACT FUNCTION](https://refactoring.com/catalog/extractFunction.html) refactoring to encapsulate that concern.","change-type":"introduced"}]},"positive-impact-count":0,"repo":"harnx","code-health":8.267299710538001,"version":"3.0","authors":["Dobes Vandermeer"],"directives":{"added":[],"removed":[]},"positive-findings":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"notices":{"number-of-types":0,"number-of-files-touched":0,"findings":[]},"external-review-provider":"GitHub"},"analysistime":"2026-07-10T17:25:09.000Z","project-name":"harnx","repository":"https://github.com/dobesv/harnx.git"}}