docs: update adrs

Author: Rel1cx

.adrs/0000-choice-between-useless-and-unnecessary-in-rule-naming.md

@@ -6,11 +6,12 @@ Accepted
 
 ## Context
 
-When naming rules related to identifying redundant or non-functional code (e.g., in linting or static analysis), the terms "useless" and "unnecessary" both convey a sense of superfluity. However, their nuanced semantic differences could lead to ambiguity if misapplied. For example, a `forwardRef`-wrapped component that is never passed a `ref` is entirely without purpose, but other scenarios might involve optional code that is only redundant in specific contexts. A consistent naming convention is needed to ensure clarity and accuracy in rule documentation and error messaging.
+When naming rules related to identifying redundant or non-functional code (e.g., in linting or static analysis), the terms "useless" and "unnecessary" both convey a sense of superfluity. However, their nuanced semantic differences could lead to ambiguity if misapplied. For example, a `forwardRef` call with no `ref` usage is entirely without purpose, but other scenarios might involve optional code that is only redundant in specific contexts. A consistent naming convention is needed to ensure clarity and accuracy in rule documentation and error messaging.
 
 ## Decision
 
-Use "useless" to describe code that has no functional purpose under any circumstances (e.g., a `forwardRef` with no `ref` usage).
+Use "useless" to describe code that has no functional purpose under any circumstances (e.g., a `forwardRef` call with no `ref` usage).
+
 Use "unnecessary" to describe code that is contextually redundant but not strictly non-functional (e.g., an `useEffect` that runs event-specific logic).
 
 ## Consequences

.adrs/0001-rename-ensure-forward-ref-using-ref-to-no-useless-forward-ref.md

@@ -6,26 +6,22 @@ Accepted
 
 ## Context
 
-The rule `ensure-forward-ref-using-ref` detects React `forwardRef`-wrapped components that never receive a `ref` prop. This matches the "useless" criteria defined in ADR 0000, as such components serve no functional purpose. The current name lacks alignment with our established `no-<category>-<term>` naming convention and semantic categorization.
+Renaming the `ensure-forward-ref-using-ref` rule to align with the existing rule naming conventions and accurately reflect the rule's focus on non-functional code.
 
 ## Decision
 
-Rename the rule to **`no-useless-forward-ref`** to:
-
-1. Adhere to the `no-<category>-<term>` pattern used in similar rules (e.g., `no-useless-state`).
-2. Reflect the strict "useless" classification per ADR 0000, since unreferenced `forwardRef` components are functionally inert.
+Rename the rule to **`no-useless-forward-ref`** to the `no-<category>-<term>` pattern used in similar rules (e.g., `no-useless-fragment`).
 
 ## Consequences
 
-- **Consistency**: Aligns with existing rule taxonomy and terminology.
-- **Clarity**: Clearly signals the rule's focus on non-functional code.
-- **Documentation updates**: Requires migration guides and rule metadata changes.
+- The rule name will be more consistent with other rules in the project.
+- The rule name will more accurately reflect the rule's focus on non-functional code.
 
 ## Alternatives Considered
 
 Using `no-unnecessary-forward-ref`:
 
-- Rejected because "unnecessary" implies optional redundancy, whereas unreferenced `forwardRef` has zero runtime utility.
+- Rejected because "unnecessary" implies optional redundancy, in this case, the `forwardRef` call is always redundant.
 
 ## Related ADRs
 

.github/workflows/publish.yml

@@ -7,12 +7,10 @@ on:
       - "**"
     paths-ignore:
       - "**/*.gitignore"
+      - .adrs/**
       - .editorconfig
-      - adrs/**
-      - docs/**
+      - apps/**
       - examples/**
-      - website/**
-      - scripts/**
   pull_request: null
 jobs:
   publish: