paperlint 4.2.0 → 6.0.0

package/fixtures/paper-research-question/comment-only/PIPELINE-STATUS.md

@@ -1,9 +0,0 @@
----
-stages:
-  - stage: submitted
-    date: 2026-07-22
-    venue: A Venue 2026
-    pdf: versions/2026-07-22-submitted.pdf
-    bytes: 100
----
-# PIPELINE-STATUS

package/fixtures/paper-research-question/comment-only/paper.tex

@@ -1,7 +0,0 @@
-\section{Introduction}
-% TODO: state the research question — this is a LaTeX COMMENT.
-% The rule reads RAW text and today does not tell it apart from the paper, so here it STAYS
-% SILENT. The hole is named in the rule's header and measured: on the live corpus there are
-% zero such cases, so it is latent. The fixture keeps it visible — the first real case turns
-% up and the assertion below has to be rewritten deliberately, not discovered after the fact.
-Body text of the paper, in which no question is stated.

package/fixtures/paper-research-question/declared-not-in-paper/PIPELINE-STATUS.md

@@ -1,10 +0,0 @@
----
-stages:
-  - stage: submitted
-    date: 2026-07-22
-    venue: A Venue 2026
-    pdf: versions/2026-07-22-submitted.pdf
-    bytes: 100
-researchQuestion: "Does pruning reduce review cost?"
----
-# PIPELINE-STATUS

package/fixtures/paper-research-question/declared-not-in-paper/paper.tex

@@ -1,6 +0,0 @@
-\section{Introduction}
-% This fixture is the one the predecessor could not express. The scorecard declares a question;
-% the paper does not carry it. And the words "research question" DO appear below — so the old
-% pattern `/\textbf{RQ|\bRQ[0-9]?\b|research question/i` matched and went silent on a paper that
-% states no question at all. Matching a phrase ABOUT the thing is not finding the thing.
-We leave the research question to future work.

package/fixtures/paper-research-question/draft/PIPELINE-STATUS.md

@@ -1,6 +0,0 @@
----
-stages: []
----
-# PIPELINE-STATUS
-
-A draft, never submitted anywhere.

package/fixtures/paper-research-question/draft/paper.tex

@@ -1,2 +0,0 @@
-\section{Introduction}
-A draft with no question. Nobody was asked to read it.

package/fixtures/paper-research-question/markdown-no-rq/PIPELINE-STATUS.md

@@ -1,9 +0,0 @@
----
-stages:
-  - stage: submitted
-    date: 2026-07-22
-    venue: A Venue 2026
-    pdf: versions/2026-07-22-submitted.pdf
-    bytes: 100
----
-# PIPELINE-STATUS

package/fixtures/paper-research-question/markdown-no-rq/paper.md

@@ -1,4 +0,0 @@
-# Introduction
-
-The paper is written in markdown, not LaTeX — that happens in this corpus, and the rule must
-see it the same way. No question is stated here.

package/fixtures/paper-research-question/shipped-no-rq/PIPELINE-STATUS.md

@@ -1,12 +0,0 @@
----
-stages:
-  - stage: submitted
-    date: 2026-07-22
-    pdf: versions/a.pdf
-    bytes: 1
-  - stage: camera-ready
-    date: 2026-08-29
-    pdf: versions/b.pdf
-    bytes: 2
----
-# PIPELINE-STATUS

package/fixtures/paper-research-question/shipped-no-rq/paper.tex

@@ -1,3 +0,0 @@
-\section{Introduction}
-We study how agents behave and measure how many rules survive to the run.
-The question is named nowhere — neither by a macro nor in words.

package/fixtures/paper-research-question/shipped-with-rq/PIPELINE-STATUS.md

@@ -1,10 +0,0 @@
----
-stages:
-  - stage: submitted
-    date: 2026-07-22
-    venue: A Venue 2026
-    pdf: versions/2026-07-22-submitted.pdf
-    bytes: 100
-researchQuestion: "does a rule written in prose survive to the run?"
----
-# PIPELINE-STATUS

package/fixtures/paper-research-question/shipped-with-rq/paper.tex

@@ -1,2 +0,0 @@
-\section{Introduction}
-\textbf{RQ1:} does a rule written in prose survive to the run?

package/src/action-ref.test.ts

@@ -1,26 +0,0 @@
-import assert from "node:assert/strict";
-import { test } from "vitest";
-import { actionRef } from "./action-ref.ts";
-
-/** [the running package's version, the ref `paperlint init` may pin the action to]. */
-const TABLE: readonly (readonly [string | undefined, string | null])[] = [
-  ["1.2.3", "v1.2.3"],
-  ["1.0.0", "v1.0.0"],
-  ["10.20.30", "v10.20.30"],
-  // Guards: a git checkout / `npm link` carries the unreleased placeholder — there is no tag for it.
-  ["0.0.0-semantically-released", null],
-  // Guards: only a plain release is known to have a tag; anything else stays the placeholder.
-  ["1.2.3-beta.1", null],
-  ["v1.2.3", null],
-  ["1.2", null],
-  ["", null],
-  ["latest", null],
-  [" 1.2.3", null],
-  // Guards: the CLI could not read its own manifest — no version, no pin.
-  [undefined, null],
-];
-
-for (const [version, ref] of TABLE)
-  test(`actionRef(${JSON.stringify(version)})`, () => {
-    assert.equal(actionRef(version), ref);
-  });

package/src/action-ref.ts

@@ -1,15 +0,0 @@
-/**
- * The ref `paperlint init` pins the GitHub Action to, decided from the version of the package that is
- * running. semantic-release tags every release `v<version>` on the commit it publishes, so the
- * action at that tag is the same code as the installed package.
- *
- * Only a plain `X.Y.Z` has such a tag. A git checkout or `npm link` carries the unreleased
- * placeholder `0.0.0-semantically-released`, a version that could not be read is `undefined`, and
- * anything else is not known to be tagged: those return `null` ("no pin known"), and the caller
- * keeps the placeholder. A wrong tag written confidently is worse than an obvious placeholder.
- */
-export function actionRef(version: string | undefined): string | null {
-  return version !== undefined && /^\d+\.\d+\.\d+$/.test(version)
-    ? `v${version}`
-    : null;
-}