freeharness 0.4.1

package/node_modules/@freeharness/sdd/dist/vendor/openspec/validation/task-lines.js

@@ -0,0 +1,105 @@
+// Reconstructed minimal slice of upstream @fission-ai/openspec@1.8.0
+//   src/utils/task-progress.ts
+// Only `parseTaskLines` (and its `ParsedTask` shape) is reproduced here: it is
+// the single dependency `task-numbering.ts` has on task-progress. The rest of
+// task-progress (schema/artifact-graph-driven task-file resolution, progress
+// counting, unreadable-file tracking) is out of the change-validation slice and
+// is deliberately NOT vendored. The regex and semantics below are faithful to
+// upstream so task-numbering behaves identically.
+/**
+ * A Markdown task line: a `-`/`*` bullet carrying a `[ ]` or `[x]` checkbox.
+ *
+ * Leading whitespace is allowed so nested sub-tasks count like their parents.
+ * Deliberately unanchored at the end: `.` does not match `\r`, so writing the
+ * description group as `(.*)$` would reject every line of a CRLF tasks.md.
+ */
+const TASK_LINE_PATTERN = /^\s*[-*]\s*\[([\sxX])\]\s*(.*)/;
+/**
+ * Parses every task line in a tasks file, in document order. Every line matching
+ * the pattern counts, wherever it sits (inside a code fence, HTML comment, or an
+ * indented block), matching upstream.
+ */
+export function parseTaskLines(content) {
+    const tasks = [];
+    for (const line of content.split('\n')) {
+        const match = line.match(TASK_LINE_PATTERN);
+        if (match) {
+            tasks.push({ done: match[1].toLowerCase() === 'x', description: match[2].trim() });
+        }
+    }
+    return tasks;
+}
+// ---------------------------------------------------------------------------
+// FreeHarness V4-P4 (4.5): per-task annotation lines. Not in upstream.
+//
+// The FreeHarness tasks template allows optional lines under a task that name
+// how to verify it, which interfaces it touches, its write boundary, its
+// dependencies and, when the task is resolved outside this change, its
+// disposition:
+//
+//   - [ ] 2.1 Implement the parser
+//     Verify: node --test test/parser.test.ts
+//     Interfaces: parseTaskLines(content)
+//     Boundary: packages/sdd/vendor/openspec/validation/
+//     Depends: 1.2
+//     Disposition: moved other-change
+//
+// They carry no checkbox, so `parseTaskLines` above never counts them; this
+// section only makes the convention explicit (one place defines the keys) and
+// attaches the annotations to the task they follow for readers such as the
+// converge hook and the subagent-driven-development briefs.
+// ---------------------------------------------------------------------------
+/** The annotation keys the tasks template documents. */
+export const TASK_ANNOTATION_KEYS = ['Verify', 'Interfaces', 'Boundary', 'Depends', 'Disposition'];
+// The trailing `\s*` absorbs the `\r` of a CRLF file, which `.` never matches, the same way
+// TASK_LINE_PATTERN above drops its end anchor; without it no annotation of such a file parses.
+const TASK_ANNOTATION_PATTERN = /^\s*(Verify|Interfaces|Boundary|Depends|Disposition):\s*(.*)\s*$/;
+/**
+ * True when the line is one of the documented annotation lines. Such a line is
+ * never a task, whatever precedes it.
+ */
+export function isTaskAnnotationLine(line) {
+    return TASK_ANNOTATION_PATTERN.test(line);
+}
+/** Splits a `Disposition:` value into its leading kind token and the rest. */
+function parseDisposition(value) {
+    const match = value.match(/^(\S+)\s*(.*)$/);
+    return match ? { kind: match[1], target: match[2].trim() } : { kind: '', target: '' };
+}
+/**
+ * Parses task lines and attaches the annotation lines that directly follow each
+ * task (blank lines and non-annotation prose end the run). The task count is
+ * exactly `parseTaskLines(content).length`.
+ */
+export function parseAnnotatedTaskLines(content) {
+    const tasks = [];
+    const lines = content.split('\n');
+    let current;
+    for (let i = 0; i < lines.length; i++) {
+        const line = lines[i];
+        const task = line.match(TASK_LINE_PATTERN);
+        if (task) {
+            current = {
+                done: task[1].toLowerCase() === 'x',
+                description: task[2].trim(),
+                line: i + 1,
+                annotations: {},
+                disposition: null,
+            };
+            tasks.push(current);
+            continue;
+        }
+        const annotation = line.match(TASK_ANNOTATION_PATTERN);
+        if (annotation && current) {
+            const key = annotation[1];
+            const value = annotation[2].trim();
+            current.annotations[key] = value;
+            if (key === 'Disposition')
+                current.disposition = parseDisposition(value);
+            continue;
+        }
+        // A blank line or any other prose ends the annotation run.
+        current = undefined;
+    }
+    return tasks;
+}

package/node_modules/@freeharness/sdd/dist/vendor/openspec/validation/task-numbering.d.ts

@@ -0,0 +1,15 @@
+export interface TaskNumberingDocument {
+    path: string;
+    content: string;
+}
+export interface TaskNumberingIssue {
+    path: string;
+    line: number;
+    message: string;
+}
+/**
+ * Finds ambiguous task references across the task files tracked by a change.
+ * Numbering is interpreted only inside `## N.` groups. Unnumbered sections,
+ * unnumbered tasks, and files without numbered groups are intentionally ignored.
+ */
+export declare function findTaskNumberingIssues(documents: readonly TaskNumberingDocument[]): TaskNumberingIssue[];

package/node_modules/@freeharness/sdd/dist/vendor/openspec/validation/task-numbering.js

@@ -0,0 +1,56 @@
+import { parseTaskLines } from './task-lines.js';
+const LEVEL_TWO_HEADING = /^ {0,3}##(?!#)(?:[ \t]+|[ \t]*\r?$)/;
+const NUMBERED_GROUP_HEADING = /^ {0,3}##[ \t]+(\d+)\.(?:[ \t]|\r?$)/;
+const TASK_ID = /^(\d+(?:\.\d+)+(?:[A-Za-z]+)?)(?=\s|$)/;
+/**
+ * Finds ambiguous task references across the task files tracked by a change.
+ * Numbering is interpreted only inside `## N.` groups. Unnumbered sections,
+ * unnumbered tasks, and files without numbered groups are intentionally ignored.
+ */
+export function findTaskNumberingIssues(documents) {
+    const issues = [];
+    const firstLocationById = new Map();
+    for (const document of documents) {
+        const lines = document.content.split('\n');
+        if (!lines.some((line) => NUMBERED_GROUP_HEADING.test(line)))
+            continue;
+        let currentGroup;
+        lines.forEach((line, index) => {
+            if (LEVEL_TWO_HEADING.test(line)) {
+                currentGroup = line.match(NUMBERED_GROUP_HEADING)?.[1];
+            }
+            if (currentGroup === undefined)
+                return;
+            const task = parseTaskLines(line)[0];
+            const id = task?.description.match(TASK_ID)?.[1];
+            if (!id)
+                return;
+            const lineNumber = index + 1;
+            const taskGroup = id.split('.')[0];
+            const normalizedTaskGroup = taskGroup.replace(/^0+(?=\d)/, '');
+            const normalizedCurrentGroup = currentGroup.replace(/^0+(?=\d)/, '');
+            if (normalizedTaskGroup !== normalizedCurrentGroup) {
+                issues.push({
+                    path: document.path,
+                    line: lineNumber,
+                    message: `Task "${id}" is under group ${currentGroup}, but its leading number points to group ${taskGroup}. Move it to group ${taskGroup} or renumber it.`,
+                });
+            }
+            const firstLocation = firstLocationById.get(id);
+            if (firstLocation !== undefined) {
+                const firstDeclaration = firstLocation.path === document.path
+                    ? `on line ${firstLocation.line}`
+                    : `in ${firstLocation.path} on line ${firstLocation.line}`;
+                issues.push({
+                    path: document.path,
+                    line: lineNumber,
+                    message: `Task ID "${id}" is duplicated; it was first declared ${firstDeclaration}.`,
+                });
+            }
+            else {
+                firstLocationById.set(id, { path: document.path, line: lineNumber });
+            }
+        });
+    }
+    return issues;
+}

package/node_modules/@freeharness/sdd/dist/vendor/openspec/validation/types.d.ts

@@ -0,0 +1,17 @@
+export type ValidationLevel = 'ERROR' | 'WARNING' | 'INFO';
+export interface ValidationIssue {
+    level: ValidationLevel;
+    path: string;
+    message: string;
+    line?: number;
+    column?: number;
+}
+export interface ValidationReport {
+    valid: boolean;
+    issues: ValidationIssue[];
+    summary: {
+        errors: number;
+        warnings: number;
+        info: number;
+    };
+}

package/node_modules/@freeharness/sdd/dist/vendor/openspec/validation/types.js

@@ -0,0 +1 @@
+export {};

package/node_modules/@freeharness/sdd/dist/vendor/openspec/validation/validator.d.ts

@@ -0,0 +1,94 @@
+import { ValidationReport, ValidationIssue } from './types.js';
+export declare class Validator {
+    private strictMode;
+    constructor(strictMode?: boolean);
+    validateSpec(filePath: string): Promise<ValidationReport>;
+    /**
+     * Validate spec content from a string (used for pre-write validation of rebuilt specs)
+     */
+    validateSpecContent(specName: string, content: string): Promise<ValidationReport>;
+    /**
+     * Validate the change proposal document (Why / What Changes prose + the
+     * top-level ChangeSchema). Delta-level checks live in
+     * `validateChangeDeltaSpecs`. This is the non-blocking proposal-level pass
+     * archive uses; TRIMMED here to drop the skip_specs marker awareness.
+     */
+    validateChange(filePath: string): Promise<ValidationReport>;
+    /**
+     * Validate delta-formatted spec files under a change directory.
+     * Enforces:
+     * - At least one delta across all files
+     * - ADDED/MODIFIED: each requirement has at least one scenario; missing
+     *   English SHALL/MUST keywords are guidance unless strict mode is enabled
+     * - REMOVED: names only; no scenario/description required
+     * - RENAMED: pairs well-formed
+     * - No duplicates within sections; no cross-section conflicts per spec
+     *
+     * When `options.mainSpecsDir` is given, MODIFIED blocks are also checked
+     * against the current main specs for the scenario loss archive refuses to
+     * apply (#1477). When `options.projectRoot` is given, the change's tasks.md is
+     * checked for ambiguous task numbering (#1520).
+     */
+    validateChangeDeltaSpecs(changeDir: string, options?: {
+        mainSpecsDir?: string;
+        projectRoot?: string;
+    }): Promise<ValidationReport>;
+    /**
+     * Task-numbering check, reconstructed minimally for this slice. Upstream
+     * resolves the schema's tracked task files (artifact graph) and gates the
+     * check to the built-in spec-driven schema; here we read the change's
+     * top-level tasks.md — the spec-driven schema's `apply.tracks` target — and
+     * run the identical `findTaskNumberingIssues` analysis.
+     */
+    private collectTaskNumberingIssues;
+    /**
+     * Report MODIFIED requirements whose block omits a scenario the main spec
+     * still carries. Uses the same comparison archive applies, so validate can
+     * only report what archive would refuse.
+     *
+     * Silent when the main spec or the requirement header is absent: applying a
+     * MODIFIED against a base that is not there yet is a different failure (a
+     * sister change still in flight is the legitimate case), and archive is the
+     * gate for it. A spec that exists but cannot be read is not absent, though —
+     * archive aborts on it, so reporting it beats calling the change valid.
+     */
+    private findScenarioLossIssues;
+    private convertZodErrors;
+    private applySpecRules;
+    private applyChangeRules;
+    private enrichTopLevelError;
+    private extractNameFromPath;
+    /**
+     * Dry-run archive's merge builder without writing its result. Reusing the
+     * builder preserves its already-synced delta rules instead of duplicating them.
+     * INFO leaves the verdict unchanged: a missing target can be a typo or a
+     * requirement introduced by a sibling change that has not archived yet.
+     * This does not run archive's later merged-spec validation or retirement checks.
+     */
+    findArchiveBlockers(changeDir: string, mainSpecsDir: string, alreadyReportedPaths: string[]): Promise<ValidationIssue[]>;
+    /**
+     * FreeHarness addition: MODIFIED / REMOVED / RENAMED headers absent from the
+     * current main spec (delta-resolution.ts). ERROR in strict mode, WARNING
+     * otherwise: the default verdict tolerates a sister change still in flight,
+     * strict does not. The change's parent directory is the changes root, which
+     * is where the ADDED-elsewhere attribution looks.
+     */
+    private findUnresolvedHeaderIssues;
+    private createReport;
+    isValid(report: ValidationReport): boolean;
+    private extractRequirementText;
+    private containsShallOrMust;
+    /**
+     * Build a message for a requirement block whose body lacks SHALL/MUST.
+     *
+     * When the SHALL/MUST keyword already appears in the requirement header (e.g.
+     * `### Requirement: The system SHALL ...`) the original generic error
+     * ("must contain SHALL or MUST") is confusing because the keyword is visibly
+     * present in the spec. Per the OpenSpec conventions the keyword has to live
+     * on the requirement body line (the line right after the header), so we point
+     * the author at that exact fix when the keyword is found in the header only.
+     */
+    private buildMissingShallOrMustMessage;
+    private countScenarios;
+    private formatSectionList;
+}