eslint-plugin-traceability 1.8.1 → 1.8.2

package/lib/tests/utils/ioTestHelpers.js

@@ -0,0 +1,24 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.runFallbackTextBeforeHasStoryDetectsStoryTest = runFallbackTextBeforeHasStoryDetectsStoryTest;
+/**
+ * Shared IO helper tests for require-story-io behavior.
+ *
+ * @story docs/stories/003.0-DEV-FUNCTION-ANNOTATIONS.story.md
+ * @req REQ-TEST-UTILS-IO - Provide reusable helpers for IO-related edge case tests
+ */
+function runFallbackTextBeforeHasStoryDetectsStoryTest(storyAnnotationOrFallbackFn = "@story docs/stories/003.0-DEV-FUNCTION-ANNOTATIONS.story.md", maybeFallbackFn) {
+    const isFirstArgFn = typeof storyAnnotationOrFallbackFn === "function";
+    const storyAnnotation = isFirstArgFn
+        ? "@story docs/stories/003.0-DEV-FUNCTION-ANNOTATIONS.story.md"
+        : storyAnnotationOrFallbackFn;
+    const fallbackFn = isFirstArgFn
+        ? storyAnnotationOrFallbackFn
+        : maybeFallbackFn;
+    const pre = `/* ${storyAnnotation} */\n`;
+    const rest = "function y() {}";
+    const full = pre + rest;
+    const fakeSource = { getText: () => full };
+    const node = { range: [full.indexOf("function"), full.length] };
+    expect(fallbackFn(fakeSource, node)).toBe(true);
+}

package/lib/tests/utils/temp-dir-helpers.d.ts

@@ -0,0 +1,14 @@
+export interface TempDirHandle {
+    /** The absolute path to the created temporary directory. */
+    readonly dir: string;
+    /** Remove the directory recursively; safe to call multiple times. */
+    cleanup(): void;
+}
+/**
+ * Create a temporary directory under the OS temp root with a common prefix.
+ *
+ * This helper centralizes the mkdtemp + rmSync pattern that appears in
+ * multiple maintenance tests so those tests can focus on behavior instead
+ * of filesystem plumbing.
+ */
+export declare function createTempDir(prefix: string): TempDirHandle;

package/lib/tests/utils/temp-dir-helpers.js

@@ -0,0 +1,61 @@
+"use strict";
+var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    var desc = Object.getOwnPropertyDescriptor(m, k);
+    if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
+      desc = { enumerable: true, get: function() { return m[k]; } };
+    }
+    Object.defineProperty(o, k2, desc);
+}) : (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    o[k2] = m[k];
+}));
+var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {
+    Object.defineProperty(o, "default", { enumerable: true, value: v });
+}) : function(o, v) {
+    o["default"] = v;
+});
+var __importStar = (this && this.__importStar) || (function () {
+    var ownKeys = function(o) {
+        ownKeys = Object.getOwnPropertyNames || function (o) {
+            var ar = [];
+            for (var k in o) if (Object.prototype.hasOwnProperty.call(o, k)) ar[ar.length] = k;
+            return ar;
+        };
+        return ownKeys(o);
+    };
+    return function (mod) {
+        if (mod && mod.__esModule) return mod;
+        var result = {};
+        if (mod != null) for (var k = ownKeys(mod), i = 0; i < k.length; i++) if (k[i] !== "default") __createBinding(result, mod, k[i]);
+        __setModuleDefault(result, mod);
+        return result;
+    };
+})();
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.createTempDir = createTempDir;
+/**
+ * Shared temp directory helpers for maintenance tests.
+ * @story docs/stories/009.0-DEV-MAINTENANCE-TOOLS.story.md
+ * @req REQ-MAINT-TEMP-HELPERS - Provide reusable OS tempdir setup/cleanup utilities for tests
+ */
+const fs = __importStar(require("fs"));
+const os = __importStar(require("os"));
+const path = __importStar(require("path"));
+/**
+ * Create a temporary directory under the OS temp root with a common prefix.
+ *
+ * This helper centralizes the mkdtemp + rmSync pattern that appears in
+ * multiple maintenance tests so those tests can focus on behavior instead
+ * of filesystem plumbing.
+ */
+function createTempDir(prefix) {
+    const dir = fs.mkdtempSync(path.join(os.tmpdir(), prefix));
+    return {
+        dir,
+        cleanup() {
+            // @implements docs/stories/009.0-DEV-MAINTENANCE-TOOLS.story.md REQ-MAINT-SAFE
+            fs.rmSync(dir, { recursive: true, force: true });
+        },
+    };
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eslint-plugin-traceability",
-  "version": "1.8.1",
+  "version": "1.8.2",
   "description": "A customizable ESLint plugin that enforces traceability annotations in your code, ensuring each implementation is linked to its requirement or test case.",
   "main": "lib/src/index.js",
   "types": "lib/src/index.d.ts",
@@ -20,7 +20,8 @@
   },
   "scripts": {
     "build": "tsc -p tsconfig.json",
-    "prepare": "husky install",
+    "prepare": "",
+    "postinstall": "husky",
     "type-check": "tsc --noEmit -p tsconfig.json",
     "check:traceability": "node scripts/traceability-check.js",
     "lint-plugin-check": "node scripts/lint-plugin-check.js",

package/user-docs/api-reference.md

@@ -11,15 +11,15 @@ Security and dependency hygiene for the published package are enforced by the sa
 
 Each rule enforces traceability conventions in your code. Below is a summary of each rule exposed by this plugin.
 
-In addition to the core `@story` and `@req` annotations, the plugin also understands `@implements` for code that fulfills requirements from multiple stories—for example:
-`@implements docs/stories/010.0-PAYMENTS.story.md#REQ-PAYMENTS-REFUND`.
-For a detailed explanation of `@implements` behavior and validation, see [Migration Guide](migration-guide.md) (section **3.1 Multi-story @implements annotations**) and the corresponding `valid-annotation-format` and `valid-req-reference` rule documentation in the plugin's internal docs.
+In addition to the core `@story` and `@req` annotations, the plugin also understands `@supports` for code that fulfills requirements from multiple stories—for example, a consuming project might use a path like
+`@supports docs/stories/010.0-PAYMENTS.story.md#REQ-PAYMENTS-REFUND`
+to indicate that a given function supports a particular requirement from a payments story document within that project’s own `docs/stories` tree. For a detailed explanation of `@supports` behavior and validation, see [Migration Guide](migration-guide.md) (section **3.1 Multi-story @supports annotations**). Additional background on multi-story semantics is available in the project’s internal rule documentation, which is intended for maintainers rather than end users.
 
-The `prefer-implements-annotation` rule is an **opt-in migration helper** that is disabled by default and **not** part of any built-in preset. It can be enabled and given a severity like `"warn"` or `"error"` using normal ESLint rule configuration when you want to gradually encourage multi-story `@implements` usage. For rule details and migration guidance, see `docs/rules/prefer-implements-annotation.md`.
+The `prefer-implements-annotation` rule is an **opt-in migration helper** that is disabled by default and **not** part of any built-in preset. It can be enabled and given a severity like `"warn"` or `"error"` using normal ESLint rule configuration when you want to gradually encourage multi-story `@supports` usage. Detailed behavior and migration guidance are documented in the project’s internal rule documentation, which is targeted at maintainers; typical end users can rely on the high-level guidance in this API reference and the [Migration Guide](migration-guide.md).
 
 ### traceability/require-story-annotation
 
-Description: Ensures every function declaration has a JSDoc comment with an `@story` annotation referencing the related user story. When you adopt multi-story `@implements` annotations as described in `docs/stories/010.2-DEV-MULTI-STORY-SUPPORT.story.md` and `REQ-REQUIRE-ACCEPTS-IMPLEMENTS`, this rule also accepts `@implements` as an alternative way to prove story coverage, so either `@story` or at least one `@implements` tag will satisfy the presence check. When run with `--fix`, the rule inserts a single-line placeholder JSDoc `@story` annotation above missing functions, methods, TypeScript declare functions, and interface method signatures using a built-in template aligned with Story 008.0. This template is currently fixed but structured for future configurability, and fixes are strictly limited to adding this placeholder annotation without altering the function body or changing any runtime behavior. Selective enabling of different auto-fix behaviors (such as applying fixes only to certain scopes or node types) is planned for a future version.
+Description: Ensures every function declaration has a JSDoc comment with an `@story` annotation referencing the related user story. When you adopt multi-story `@supports` annotations, this rule also accepts `@supports` as an alternative way to prove story coverage, so either `@story` or at least one `@supports` tag will satisfy the presence check. When run with `--fix`, the rule inserts a single-line placeholder JSDoc `@story` annotation above missing functions, methods, TypeScript declare functions, and interface method signatures using a built-in template aligned with Story 008.0. This template is currently fixed but structured for future configurability, and fixes are strictly limited to adding this placeholder annotation without altering the function body or changing any runtime behavior. Selective enabling of different auto-fix behaviors (such as applying fixes only to certain scopes or node types) is planned for a future version.
 
 Options:
 
@@ -41,7 +41,7 @@ function initAuth() {
 
 ### traceability/require-req-annotation
 
-Description: Ensures that function-like constructs consistently declare their linked requirement using an `@req` annotation in JSDoc. The rule targets the same function-like node types as `traceability/require-story-annotation` (standard function declarations, non-arrow function expressions used as callbacks or assignments, class/object methods, TypeScript declare functions, and interface method signatures), and enforces that each of them has at least one `@req` tag in the nearest associated JSDoc comment. When you adopt multi-story `@implements` annotations as described in `docs/stories/010.2-DEV-MULTI-STORY-SUPPORT.story.md` and `REQ-REQUIRE-ACCEPTS-IMPLEMENTS`, this rule also treats `@implements story-path REQ-ID...` tags as satisfying the requirement coverage check, although deep verification of requirement IDs continues to be handled by `traceability/valid-req-reference`. Arrow functions (`ArrowFunctionExpression`) are not currently checked by this rule.
+Description: Ensures that function-like constructs consistently declare their linked requirement using an `@req` annotation in JSDoc. The rule targets the same function-like node types as `traceability/require-story-annotation` (standard function declarations, non-arrow function expressions used as callbacks or assignments, class/object methods, TypeScript declare functions, and interface method signatures), and enforces that each of them has at least one `@req` tag in the nearest associated JSDoc comment. When you adopt multi-story `@supports` annotations, this rule also treats `@supports story-path REQ-ID...` tags as satisfying the requirement coverage check, although deep verification of requirement IDs continues to be handled by `traceability/valid-req-reference`. Arrow functions (`ArrowFunctionExpression`) are not currently checked by this rule.
 
 This rule is typically used alongside `traceability/require-story-annotation` so that each function-level traceability block includes both an `@story` and an `@req` annotation, but it can also be enabled independently if you only want to enforce requirement linkage. Unlike `traceability/require-story-annotation`, this rule does not currently provide an auto-fix mode for inserting placeholder `@req` annotations; it only reports missing or malformed requirement annotations on the configured scopes.
 
@@ -90,11 +90,11 @@ Options:
 This rule accepts an optional configuration object. The primary configuration shape is **nested**:
 
 - `story` (object, optional) – Configuration for `@story` values.
-  - `pattern` (string, optional) – A JavaScript regular expression **source** (without leading and trailing `/`) that all `@story` values must match. If provided, the rule validates each `@story` against this pattern in addition to its built‑in structural checks. Defaults to the value returned by `getDefaultStoryPattern()`, which is equivalent to `^docs/stories/.*\.story\.md$`, aligning with the standard `docs/stories/<name>.story.md` convention.
-  - `example` (string, optional) – A short example `@story` path shown in error messages when `story.pattern` is configured. Defaults to the value returned by `getDefaultStoryExample()`, `"docs/stories/001.0-EXAMPLE.story.md"`. This value is used **only** for guidance and does not affect validation.
+  - `pattern` (string, optional) – A JavaScript regular expression **source** (without leading and trailing `/`) that all `@story` values must match. If provided, the rule validates each `@story` against this pattern in addition to its built‑in structural checks. By default, the plugin uses a pattern equivalent to `^docs/stories/.*\.story\.md$`, which matches a typical project convention such as `docs/stories/<name>.story.md`; you can override this to match however your own project organizes story files.
+  - `example` (string, optional) – A short example `@story` path shown in error messages when `story.pattern` is configured. The built-in default example is `"docs/stories/001.0-EXAMPLE.story.md"`, intended as a generic illustration of a project story file, and does not refer to this plugin’s internal documentation.
 - `req` (object, optional) – Configuration for `@req` values.
   - `pattern` (string, optional) – A JavaScript regular expression **source** (without leading and trailing `/`) that all `@req` values must match. If provided, the rule validates each `@req` identifier against this pattern. Defaults to the value returned by `getDefaultReqPattern()`, which is equivalent to `^REQ-[A-Z0-9_-]+$`, matching IDs such as `REQ-USER-AUTH` or `REQ-1234`.
-  - `example` (string, optional) – A short example requirement ID shown in error messages when `req.pattern` is configured. Defaults to the value returned by `getDefaultReqExample()`, `"REQ-USER-AUTH"`. This is purely informational and does not participate in matching.
+  - `example` (string, optional) – A short example requirement ID shown in error messages when `req.pattern` is configured. Defaults to the value returned by `getDefaultReqExample()`, `"REQ-USER-AUTH"`. This value is used **only** for guidance and does not affect validation.
 
 For backward compatibility, the rule also supports **flat shorthand** fields that map directly to the nested properties:
 
@@ -114,13 +114,10 @@ Behavior notes:
 The `valid-annotation-format` rule is intentionally **backward compatible** with existing code that only uses `@story` and `@req`. You can:
 
 - Continue using `@story` + `@req` for single-story functions and modules.
-- Introduce `@implements` incrementally for integration code that implements requirements from multiple stories.
+- Introduce `@supports` incrementally for integration code that implements requirements from multiple stories.
 - Mix both styles in the same comment block when needed; the rule validates the format of each annotation independently.
 
-Deep requirement checking for both `@req` and `@implements` is handled by the `valid-req-reference` rule in the plugin's internal docs. For step-by-step guidance on when and how to migrate, see:
-
-- **Migration guide:** [Migration Guide](migration-guide.md) (section **3.1 Multi-story `@implements` annotations**)
-- **Rule docs:** The `valid-annotation-format` and `valid-req-reference` rule documentation in the plugin's internal docs.
+Deep requirement checking for both `@req` and `@supports` is handled by the `valid-req-reference` rule in the plugin's internal docs. Advanced edge cases and internal semantics are mainly of interest to maintainers; typical end users can rely on the options and examples in this API reference when configuring the rule for their projects.
 
 Default Severity: `error`
 Example:
@@ -201,7 +198,7 @@ The plugin provides two built-in presets for easy configuration:
 Enables the **six core traceability rules** with severities tuned for common usage (most at `error`, with
 `traceability/valid-annotation-format` at `warn` to reduce noise). This `warn` level for `traceability/valid-annotation-format` is intentional to keep early adoption noise low, but you can safely raise it to `error` in projects that want strict enforcement of annotation formatting.
 
-The `prefer-implements-annotation` migration rule is **not included** in this (or any) preset and remains disabled by default. If you want to encourage or enforce multi-story `@implements` annotations, you must enable `traceability/prefer-implements-annotation` explicitly in your ESLint configuration and choose an appropriate severity (for example, `"warn"` during migration or `"error"` once fully adopted).
+The `prefer-implements-annotation` migration rule is **not included** in this (or any) preset and remains disabled by default. If you want to encourage or enforce multi-story `@supports` annotations, you must enable `traceability/prefer-implements-annotation` explicitly in your ESLint configuration and choose an appropriate severity (for example, `"warn"` during migration or `"error"` once fully adopted).
 
 Core rules enabled by the `recommended` preset:
 

package/user-docs/migration-guide.md

@@ -37,29 +37,29 @@ export default [traceability.configs.recommended];
 - `valid-req-reference` rejects path traversal (`../`) and absolute paths (`/etc/passwd`).
 - `valid-annotation-format` enforces correct JSDoc traceability annotation syntax (`@story` and `@req` tags).
 
-Review and update your existing annotations accordingly:
+The following diff shows a typical migration in **your own project**, where `docs/stories/001.0-DEV-PLUGIN-SETUP.story.md` is an example of a story file path from your documentation tree:
 
 ```diff
 - /** @story docs/stories/001.0-DEV-PLUGIN-SETUP.md */
 + /** @story docs/stories/001.0-DEV-PLUGIN-SETUP.story.md */
 ```
 
-### 3.1 Multi-story `@implements` annotations
+### 3.1 Multi-story `@supports` annotations
 
-Starting in v1.x, `eslint-plugin-traceability` supports an additional annotation form for integration code that implements requirements from multiple stories:
+Starting in v1.x, `eslint-plugin-traceability` supports an additional annotation form for integration code that implements requirements from multiple stories in a consuming project. The following snippet shows one example of how you might structure such an annotation in **your** codebase:
 
 ```js
 /**
- * @implements docs/stories/010.2-DEV-MULTI-STORY-SUPPORT.story.md REQ-IMPLEMENTS-PARSE REQ-IMPLEMENTS-VALIDATE
+ * @supports docs/stories/010.2-DEV-MULTI-STORY-SUPPORT.story.md REQ-IMPLEMENTS-PARSE REQ-IMPLEMENTS-VALIDATE
  */
 function integrate() {}
 ```
 
-You **do not** need to change existing, single-story annotations that already use `@story` and `@req`. Migration to `@implements` is only recommended when a function or module genuinely implements requirements from more than one story file.
+You **do not** need to change existing, single-story annotations that already use `@story` and `@req`. Migration to `@supports` is only recommended when a function or module genuinely implements requirements from more than one story file.
 
 #### Optional `prefer-implements-annotation` migration rule
 
-For teams that want to gradually migrate from `@story` + `@req` to `@implements`, the plugin provides an optional rule: `traceability/prefer-implements-annotation`.
+For teams that want to gradually migrate from `@story` + `@req` to `@supports`, the plugin provides an optional rule: `traceability/prefer-implements-annotation`.
 
 - This rule is **disabled by default** and is **not** included in any built-in presets.
 - You can enable it with any standard ESLint severity (`"off"`, `"warn"`, or `"error"`) in your config, for example:
@@ -73,8 +73,8 @@ For teams that want to gradually migrate from `@story` + `@req` to `@implements`
   }
   ```
 
-- When enabled, it offers **conservative auto-fixes** that rewrite eligible `@story` + `@req` combinations into equivalent `@implements` lines, without attempting risky or ambiguous transformations.
-- Detailed behavior, limitations, and examples are documented in `docs/rules/prefer-implements-annotation.md`.
+- When enabled, it offers **conservative auto-fixes** that rewrite eligible `@story` + `@req` combinations into equivalent `@supports` lines, without attempting risky or ambiguous transformations.
+- Detailed behavior, limitations, and examples are documented in the project’s internal rule documentation, which is primarily intended for maintainers; most users can rely on this guide and the API reference for day-to-day usage.
 
 #### When to keep `@story` + `@req`
 
@@ -84,7 +84,7 @@ Keep your current annotations if:
 - All relevant requirements live in that story file.
 - You do not need to distinguish which story a particular requirement ID comes from.
 
-Example (no migration required):
+Example (no migration required). Here, `docs/stories/003.0-DEV-FUNCTION-ANNOTATIONS.story.md` is an illustrative path representing a typical story file location in **your** documentation structure:
 
 ```js
 /**
@@ -96,15 +96,15 @@ export function initAuth() {
 }
 ```
 
-#### When to introduce `@implements`
+#### When to introduce `@supports`
 
-Adopt `@implements` for **multi-story integration** code, especially when:
+Adopt `@supports` for **multi-story integration** code, especially when:
 
 - The function combines behavior governed by **multiple** stories.
 - Requirement IDs are reused across stories (for example, `REQ-SHARED-ID` appears in more than one story file).
 - You want deep validation (via `valid-req-reference`) to know **which story file** each requirement came from.
 
-Before (single-story annotations trying to describe multi-story behavior):
+Before (single-story annotations trying to describe multi-story behavior). The story path shown here is an example of how you might name and organize a story file in your own project:
 
 ```js
 /**
@@ -118,7 +118,7 @@ export async function applyFilters(rows, options) {
 }
 ```
 
-After (multi-story `@implements`), aligned with Story 010.2:
+After (multi-story `@supports`), using illustrative story paths that represent typical files in your project’s documentation tree (they are examples, not files provided by this plugin):
 
 ```js
 /**
@@ -127,8 +127,8 @@ After (multi-story `@implements`), aligned with Story 010.2:
  * @req REQ-AGE-THRESHOLD
  * @req REQ-OUTPUT
  *
- * @implements docs/stories/003.0-DEV-IDENTIFY-OUTDATED.story.md REQ-AGE-THRESHOLD REQ-OUTPUT
- * @implements docs/stories/004.0-DEV-FILTER-VULNERABLE-VERSIONS.story.md REQ-AUDIT-CHECK REQ-SAFE-ONLY
+ * @supports docs/stories/003.0-DEV-IDENTIFY-OUTDATED.story.md REQ-AGE-THRESHOLD REQ-OUTPUT
+ * @supports docs/stories/004.0-DEV-FILTER-VULNERABLE-VERSIONS.story.md REQ-AUDIT-CHECK REQ-SAFE-ONLY
  */
 export async function applyFilters(rows, options) {
   // combined behavior
@@ -137,19 +137,19 @@ export async function applyFilters(rows, options) {
 
 In the "after" example:
 
-- `valid-annotation-format` ensures the `@implements` lines use a valid story path and requirement ID format.
-- `valid-req-reference` validates that each requirement listed after `@implements` exists in the corresponding story file.
+- `valid-annotation-format` ensures the `@supports` lines use a valid story path and requirement ID format.
+- `valid-req-reference` validates that each requirement listed after `@supports` exists in the corresponding story file.
 
 #### Mixed usage during migration
 
-You can introduce `@implements` gradually without breaking existing code:
+You can introduce `@supports` gradually without breaking existing code:
 
 1. Leave existing `@story` and `@req` annotations in place.
-2. Add `@implements` lines that group requirements by story file.
+2. Add `@supports` lines that group requirements by story file.
 3. Run ESLint with `traceability/valid-annotation-format` and `traceability/valid-req-reference` enabled to confirm everything passes.
-4. Optionally, once you are comfortable, standardize on using `@implements` for multi-story integration functions while keeping `@story` + `@req` for simple, single-story code.
+4. Optionally, once you are comfortable, standardize on using `@supports` for multi-story integration functions while keeping `@story` + `@req` for simple, single-story code.
 
-For detailed semantics and edge cases (path validation, scoped requirement IDs, and multi-story fixtures), see the valid-annotation-format and valid-req-reference rule documentation and the multi-story support story in the project documentation.
+Detailed semantics and edge cases (path validation, scoped requirement IDs, and multi-story fixtures) are ultimately governed by your own stories and requirements. For typical migrations, this guide together with the plugin’s API reference is sufficient.
 
 ## 4. Test and Validate