patchground 0.1.0__py3-none-any.whl

patchground/catalog/order-notifications-boundary/workspace/src/orders/sqlite_store.py

@@ -0,0 +1,44 @@
+"""SQLite persistence for confirmed orders."""
+
+from __future__ import annotations
+
+import json
+import sqlite3
+from pathlib import Path
+
+from orders.models import Order, OrderLine
+
+_SCHEMA = """
+CREATE TABLE IF NOT EXISTS orders (
+    order_id TEXT PRIMARY KEY,
+    customer_email TEXT NOT NULL,
+    lines TEXT NOT NULL,
+    status TEXT NOT NULL
+)
+"""
+
+
+class SqliteOrderRepository:
+    def __init__(self, path: str | Path) -> None:
+        self._path = str(path)
+        with sqlite3.connect(self._path) as connection:
+            connection.execute(_SCHEMA)
+
+    def save_confirmed(self, order: Order) -> None:
+        lines = json.dumps([line.__dict__ for line in order.lines])
+        with sqlite3.connect(self._path) as connection:
+            connection.execute(
+                "INSERT OR REPLACE INTO orders VALUES (?, ?, ?, ?)",
+                (order.order_id, order.customer_email, lines, "confirmed"),
+            )
+
+    def get(self, order_id: str) -> Order | None:
+        with sqlite3.connect(self._path) as connection:
+            row = connection.execute(
+                "SELECT order_id, customer_email, lines FROM orders WHERE order_id = ?",
+                (order_id,),
+            ).fetchone()
+        if row is None:
+            return None
+        lines = tuple(OrderLine(**item) for item in json.loads(row[2]))
+        return Order(order_id=row[0], customer_email=row[1], lines=lines)

patchground/catalog/pagination-last-page/TICKET.md

@@ -0,0 +1,44 @@
+# Last page of search results returns "page out of range"
+
+**Reported by:** support (via customer ticket)
+**Component:** `catalog.pagination`
+
+## Symptom
+
+Customers browsing search results can't reach the last few products. Clicking the final page
+link shows an error instead of the remaining items. The pager also hides the "Next" button one
+page too early.
+
+It does not happen for every search: a search for "lamp" (40 results) pages fine, a search for
+"chair" (25 results) does not.
+
+## Reproduction
+
+```python
+from catalog.pagination import paginate
+
+results = [f"chair-{i}" for i in range(25)]
+
+paginate(results, page=1, per_page=10)   # works, 10 items
+paginate(results, page=2, per_page=10)   # works, 10 items
+paginate(results, page=3, per_page=10)   # raises PageOutOfRange
+```
+
+## Expected
+
+25 results at 10 per page are 3 pages: 10, 10 and 5 items. Page 3 returns the last 5 items,
+`total_pages` is 3, and page 2 reports `has_next=True`.
+
+## Actual
+
+`total_pages` is 2, page 2 reports `has_next=False`, and page 3 raises `PageOutOfRange`.
+
+## Notes
+
+- Requesting a page past the real end (e.g. page 4 above) must keep raising `PageOutOfRange`;
+  the web layer turns it into a 404.
+- An empty result set is still a single, empty page 1.
+- Run `pgnd check` from the session workspace to check your changes in Docker.
+- Add a regression test covering the reported case, and keep existing behavior intact.
+- You may use your own editor and AI tools. The goal is to explain the cause and verify your fix,
+  not merely make the reported error disappear.

patchground/catalog/pagination-last-page/challenge.yaml

@@ -0,0 +1,31 @@
+spec_version: "0.1"
+id: pagination-last-page
+version: 1.0.1
+title: Last page of search results returns "page out of range"
+type: debug
+summary: >-
+  The catalog API rejects the last page of results whenever the result count is not
+  a multiple of the page size. Find the root cause and fix it.
+languages: [python]
+tags: [pagination, off-by-one]
+difficulty: beginner
+timebox_minutes: 20
+ai_policy: allowed
+environment:
+  dockerfile: environment/Dockerfile
+  services: []
+  test_command: pytest -q -p no:cacheprovider --junitxml=$PG_RESULTS/junit.xml
+checks:
+  visible: checks/visible
+  hidden: checks/hidden
+solution: solution/reference.patch
+expected_paths: [src/catalog/, tests/]
+hints:
+  - Compare the number of pages the paginator computes with the number you would count by hand for 25 items, 10 per page.
+  - Integer division rounds down. What happens to the items that don't fill a whole page?
+debrief:
+  questions: debrief/questions.md
+  focus: [debugging_method, test_quality, scope_judgment]
+author: {name: Fran Delicado, github: franndeli}
+content_license: CC-BY-4.0
+provenance: handmade

patchground/catalog/pagination-last-page/checks/hidden/tests/test_pagination_hidden.py

@@ -0,0 +1,32 @@
+import pytest
+
+from catalog.pagination import PageOutOfRange, paginate
+
+CHAIRS = [f"chair-{i}" for i in range(25)]
+
+
+def test_partial_last_page_is_reachable():
+    page = paginate(CHAIRS, page=3, per_page=10)
+    assert page.items == CHAIRS[20:]
+    assert page.has_next is False
+
+
+def test_total_pages_rounds_up():
+    assert paginate(CHAIRS, page=1, per_page=10).total_pages == 3
+    assert paginate(CHAIRS[:1], page=1, per_page=10).total_pages == 1
+    assert paginate(CHAIRS[:11], page=1, per_page=10).total_pages == 2
+
+
+def test_second_to_last_page_has_next():
+    assert paginate(CHAIRS, page=2, per_page=10).has_next is True
+
+
+def test_page_past_the_end_is_out_of_range():
+    with pytest.raises(PageOutOfRange):
+        paginate(CHAIRS, page=4, per_page=10)
+
+
+def test_fewer_items_than_one_page():
+    page = paginate(CHAIRS[:3], page=1, per_page=10)
+    assert page.items == CHAIRS[:3]
+    assert page.total_pages == 1

patchground/catalog/pagination-last-page/checks/visible/tests/test_pagination.py

@@ -0,0 +1,37 @@
+import pytest
+
+from catalog.pagination import PageOutOfRange, paginate
+
+LAMPS = [f"lamp-{i}" for i in range(40)]
+
+
+def test_first_page_has_per_page_items():
+    page = paginate(LAMPS, page=1, per_page=10)
+    assert page.items == LAMPS[:10]
+    assert page.number == 1
+    assert page.has_previous is False
+    assert page.has_next is True
+
+
+def test_exact_multiple_has_expected_page_count():
+    page = paginate(LAMPS, page=4, per_page=10)
+    assert page.items == LAMPS[30:]
+    assert page.total_pages == 4
+    assert page.has_next is False
+
+
+def test_empty_results_are_one_empty_page():
+    page = paginate([], page=1, per_page=10)
+    assert page.items == []
+    assert page.total_pages == 1
+    assert page.has_next is False
+
+
+def test_page_zero_is_out_of_range():
+    with pytest.raises(PageOutOfRange):
+        paginate(LAMPS, page=0, per_page=10)
+
+
+def test_per_page_must_be_positive():
+    with pytest.raises(ValueError):
+        paginate(LAMPS, page=1, per_page=0)

patchground/catalog/pagination-last-page/debrief/questions.md

@@ -0,0 +1,9 @@
+# Debrief questions
+
+1. The visible tests were green before you changed anything. What made you trust (or distrust)
+   that baseline, and how did you confirm the bug before touching the code?
+2. Walk me through the boundary cases you considered for the page count: empty results, fewer
+   items than one page, exact multiples, one item over a multiple. Which one would you add as a
+   regression test first, and why?
+3. The web layer turns `PageOutOfRange` into a 404. If your fix had made every page number valid,
+   how would that have shown up in production, and how would you have noticed?

patchground/catalog/pagination-last-page/environment/Dockerfile

@@ -0,0 +1,3 @@
+FROM python:3.12-slim
+ENV PYTHONDONTWRITEBYTECODE=1
+RUN pip install --no-cache-dir pytest==8.3.5

patchground/catalog/pagination-last-page/solution/reference.patch

@@ -0,0 +1,22 @@
+diff --git a/src/catalog/pagination.py b/src/catalog/pagination.py
+index 8c0a96e..f09b864 100644
+--- a/src/catalog/pagination.py
++++ b/src/catalog/pagination.py
+@@ -2,6 +2,7 @@
+ 
+ from __future__ import annotations
+ 
++import math
+ from collections.abc import Sequence
+ from dataclasses import dataclass
+ from typing import Generic, TypeVar
+@@ -39,7 +40,8 @@ def paginate(items: Sequence[T], page: int, per_page: int = 20) -> Page[T]:
+     if page < 1:
+         raise PageOutOfRange(f"page {page} is before the first page")
+ 
+-    total_pages = max(1, len(items) // per_page)
++    # Round up: a partial last page is still a page.
++    total_pages = max(1, math.ceil(len(items) / per_page))
+     if page > total_pages:
+         raise PageOutOfRange(f"page {page} is past the last page ({total_pages})")
+ 

patchground/catalog/pagination-last-page/workspace/pyproject.toml

@@ -0,0 +1,8 @@
+[project]
+name = "catalog"
+version = "0.3.1"
+requires-python = ">=3.12"
+
+[tool.pytest.ini_options]
+pythonpath = ["src"]
+testpaths = ["tests"]

patchground/catalog/pagination-last-page/workspace/src/catalog/__init__.py

@@ -0,0 +1 @@
+"""Product catalog helpers."""

patchground/catalog/pagination-last-page/workspace/src/catalog/pagination.py

@@ -0,0 +1,52 @@
+"""Split result lists into fixed-size pages for the catalog API."""
+
+from __future__ import annotations
+
+from collections.abc import Sequence
+from dataclasses import dataclass
+from typing import Generic, TypeVar
+
+T = TypeVar("T")
+
+
+class PageOutOfRange(LookupError):
+    """The requested page does not exist. The web layer maps this to a 404."""
+
+
+@dataclass(frozen=True)
+class Page(Generic[T]):
+    items: list[T]
+    number: int
+    total_pages: int
+    total_items: int
+
+    @property
+    def has_next(self) -> bool:
+        return self.number < self.total_pages
+
+    @property
+    def has_previous(self) -> bool:
+        return self.number > 1
+
+
+def paginate(items: Sequence[T], page: int, per_page: int = 20) -> Page[T]:
+    """Return page ``page`` (1-based) of ``items``, ``per_page`` items per page.
+
+    An empty sequence still has one (empty) page, so page 1 is always valid.
+    """
+    if per_page < 1:
+        raise ValueError("per_page must be at least 1")
+    if page < 1:
+        raise PageOutOfRange(f"page {page} is before the first page")
+
+    total_pages = max(1, len(items) // per_page)
+    if page > total_pages:
+        raise PageOutOfRange(f"page {page} is past the last page ({total_pages})")
+
+    start = (page - 1) * per_page
+    return Page(
+        items=list(items[start : start + per_page]),
+        number=page,
+        total_pages=total_pages,
+        total_items=len(items),
+    )

patchground/catalog/release-version-ordering/TICKET.md

@@ -0,0 +1,72 @@
+# The release picker chooses the wrong version
+
+Our changelog tool uses the small `releasekit` library in `src/releasekit/` to show release labels
+in ascending order and select the latest release. Support reports that
+`latest(["1.9.0", "1.10.0", "1.2.0"])` chooses `"1.9.0"`, and release candidates appear in surprising
+positions. Fix the ordering behavior and add a regression check. Keep the public API below.
+
+## Public API
+
+Import from `src/releasekit/index.ts`:
+
+- `compare(a: string, b: string): -1 | 0 | 1` returns the sign of the SemVer precedence comparison.
+- `sortVersions(versions: readonly string[]): string[]` returns a **fresh**, ascending, stable array.
+  The input is never mutated, including on error. Equal-precedence strings retain their input order.
+- `latest(versions: readonly string[], options?: {includePrerelease?: boolean}): string | undefined`
+  returns the original string with greatest precedence. By default prereleases are excluded;
+  `{includePrerelease: true}` includes them. Return `undefined` for an empty input or when no eligible
+  versions remain. Equal-precedence candidates keep the **first** eligible input string. Never mutate
+  the input.
+- `InvalidVersionError` is an exported `Error` subclass. Every API validates every supplied version,
+  including a singleton array and prereleases that `latest` would filter out. Any invalid version
+  throws `InvalidVersionError`; message text is unspecified. An empty array is valid.
+
+Inputs to this API are strings and arrays of strings; handling other JavaScript types is outside
+this ticket. Runtime checks exercise TypeScript code; they do not establish compiler type correctness.
+
+## Accepted version strings
+
+Use strict **SemVer 2.0.0**, with no trimming, normalization, range syntax or optional prefixes:
+
+`MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]`
+
+- MAJOR, MINOR and PATCH are nonempty ASCII decimal digit strings. Each is either `0` or begins with
+  `1`–`9`; leading zeroes are invalid. Exactly three components are required.
+- PRERELEASE and BUILD are nonempty lists of nonempty identifiers separated by `.`. Each identifier
+  contains only ASCII letters `A`–`Z`/`a`–`z`, decimal digits `0`–`9`, or `-`.
+- A prerelease identifier containing only decimal digits must be `0` or start with `1`–`9`. Build
+  identifiers may have leading zeroes. A nonnumeric prerelease identifier such as `01a` is valid.
+- No whitespace, Unicode letters/digits, leading `v`, signs, wildcards, operators (`^`, `~`, `>=`),
+  missing components, empty identifiers or trailing characters are accepted. Hyphens within an
+  identifier are allowed, including an identifier consisting only of a hyphen.
+- Numeric components and numeric prerelease identifiers have **arbitrary precision**: their magnitude
+  must be compared exactly regardless of length, without floating-point rounding or safe-integer
+  rejection. Decimal-string comparison or BigInt is suitable. The ticket imposes no numeric length cap.
+
+Parsing already works; keep its validation policy intact.
+
+## Precedence
+
+Compare core components MAJOR, then MINOR, then PATCH by numeric magnitude. For equal cores:
+
+1. A version without a prerelease has higher precedence than one with a prerelease.
+2. Compare prerelease identifiers from left to right. Two numeric identifiers compare by exact numeric
+   magnitude. A numeric identifier has lower precedence than a nonnumeric identifier. Two nonnumeric
+   identifiers compare by case-sensitive ASCII lexical order, including ordinary prefix ordering.
+3. If all compared identifiers are equal, the shorter prerelease identifier list has lower precedence.
+
+BUILD metadata has **no effect** on precedence, eligibility or tie breaking. Preserve original input
+strings in returned arrays and in `latest` rather than reconstructing or dropping build metadata.
+For example, this is an ascending precedence chain:
+
+`1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0`
+
+`1.0.0+build.09` and `1.0.0+build.10` compare equal. `latest(["2.0.0-rc.1", "1.0.0"])`
+returns `"1.0.0"` by default, and `"2.0.0-rc.1"` when prereleases are included.
+
+## Scope
+
+Fix application code and add focused editable checks. Do not add a semver dependency or change the
+runner, dependency recipe, or hidden checks. No range resolution, filesystem access, clocks, network,
+CLI, or compatibility with a third-party semver package is required. The 45-minute timebox and
+intermediate difficulty are author estimates, pending independent human usability testing.

patchground/catalog/release-version-ordering/challenge.yaml

@@ -0,0 +1,31 @@
+spec_version: "0.1"
+id: release-version-ordering
+version: 1.0.1
+title: Release picker orders version labels incorrectly
+type: debug
+summary: A release-tool library chooses the wrong latest version and misorders prereleases.
+languages: [typescript]
+tags: [semver, ordering, releases]
+difficulty: intermediate
+timebox_minutes: 45
+ai_policy: allowed
+environment:
+  dockerfile: environment/Dockerfile
+  services: []
+  test_command: node /opt/patchground/vitest-runner.mjs
+checks:
+  visible: checks/visible
+  hidden: checks/hidden
+solution: solution/reference.patch
+expected_paths: [src/releasekit/, tests/]
+hints:
+  - Start with two version labels whose numeric components have different digit counts.
+  - Compare prerelease identifiers one position at a time, distinguishing numeric and nonnumeric identifiers.
+  - A release and its prereleases share the same core version; build metadata never decides precedence.
+debrief:
+  questions: debrief/questions.md
+  focus: [debugging_method, test_quality, scope_judgment]
+author: {name: Patchground contributors}
+content_license: CC-BY-4.0
+provenance: generated
+generated_by: {model: "Codex configured default (model unverified)", prompt_version: launch-release-order-v1}

patchground/catalog/release-version-ordering/checks/hidden/tests/releasekit_contract.test.ts

@@ -0,0 +1,92 @@
+import {test, expect} from "vitest";
+import {compare, sortVersions, latest, InvalidVersionError} from "../src/releasekit/index";
+
+test("core components compare by exact numeric magnitude", () => {
+  const pairs = [
+    ["9.0.0", "10.0.0"], ["1.9.0", "1.10.0"], ["1.0.9", "1.0.10"],
+    ["9007199254740992.0.0", "9007199254740993.0.0"],
+    ["1.999999999999999999999999999999.0", "1.1000000000000000000000000000000.0"],
+    ["1.0.9007199254740992", "1.0.9007199254740993"],
+  ];
+  for (const [lower, higher] of pairs) {
+    expect(compare(lower, higher)).toBe(-1);
+    expect(compare(higher, lower)).toBe(1);
+  }
+  expect(compare("10.0.0", "9.999.999")).toBe(1);
+});
+
+test("release has higher precedence than its prereleases", () => {
+  expect(compare("1.0.0", "1.0.0-rc.1")).toBe(1);
+  expect(compare("1.0.0-rc.1", "1.0.0")).toBe(-1);
+  expect(latest(["1.0.0-rc.1", "1.0.0"], {includePrerelease: true})).toBe("1.0.0");
+});
+
+test("prerelease identifiers follow numeric and ASCII rules", () => {
+  const pairs = [
+    ["1.0.0-beta.2", "1.0.0-beta.11"],
+    ["1.0.0-1", "1.0.0--"],
+    ["1.0.0-0", "1.0.0-01a"],
+    ["1.0.0-A", "1.0.0-a"],
+    ["1.0.0-alpha", "1.0.0-alphabet"],
+    ["1.0.0-alpha", "1.0.0-alpha.0"],
+    ["1.0.0-beta.9007199254740992", "1.0.0-beta.9007199254740993"],
+    ["1.0.0-99999999999999999999999999999", "1.0.0-100000000000000000000000000000"],
+  ];
+  for (const [lower, higher] of pairs) {
+    expect(compare(lower, higher)).toBe(-1);
+    expect(compare(higher, lower)).toBe(1);
+  }
+});
+
+test("full SemVer precedence chain sorts independently of input order", () => {
+  const chain = ["1.0.0-alpha", "1.0.0-alpha.1", "1.0.0-alpha.beta", "1.0.0-beta",
+    "1.0.0-beta.2", "1.0.0-beta.11", "1.0.0-rc.1", "1.0.0"];
+  expect(sortVersions([...chain].reverse())).toEqual(chain);
+});
+
+test("build metadata is ignored and ties preserve original labels", () => {
+  const labels = ["1.0.0+build.09", "1.0.0+build.10", "1.0.0", "1.0.0+build.00"];
+  for (const value of labels) expect(compare(value, "1.0.0")).toBe(0);
+  expect(sortVersions(labels)).toEqual(labels);
+  expect(latest(labels)).toBe(labels[0]);
+  expect(compare("1.0.0-alpha+Z", "1.0.0-alpha+A")).toBe(0);
+  expect(latest(["1.0.0-alpha+first", "1.0.0-alpha+second"],
+    {includePrerelease: true})).toBe("1.0.0-alpha+first");
+});
+
+test("all entry points reject strict grammar violations including filtered labels", () => {
+  const invalid = ["", "1", "1.0", "v1.0.0", "01.0.0", "1.01.0", "1.0.01", "1.0.0-01",
+    "1.0.0-alpha.01", "1.0.0-", "1.0.0+", "1.0.0-a..b", "1.0.0+a..b", "1.0.0_a",
+    " 1.0.0", "1.0.0 ", "1.0.0\n", "1.0.0+\n", "1.0.0-é", "１.0.0",
+    "^1.0.0", "~1.0.0", ">=1.0.0", "1.0.*", "+1.0.0", "1.0.0+a+b"];
+  for (const value of invalid) {
+    expect(() => compare(value, "1.0.0")).toThrowError(InvalidVersionError);
+    expect(() => compare("1.0.0", value)).toThrowError(InvalidVersionError);
+    expect(() => sortVersions([value])).toThrowError(InvalidVersionError);
+    expect(() => latest(["2.0.0", value])).toThrowError(InvalidVersionError);
+    expect(() => latest([value], {includePrerelease: true})).toThrowError(InvalidVersionError);
+  }
+});
+
+test("valid identifier edges and arbitrary length components remain accepted", () => {
+  const labels = ["0.0.0", "1.0.0--", "1.0.0-01a", "1.0.0-a-b.0", "1.0.0+00.-.A",
+    "999999999999999999999999999999999999999999999999999999999999.0.0"];
+  for (const value of labels) expect(compare(value, value)).toBe(0);
+});
+
+test("empty fresh sort and latest never mutate even after invalid input", () => {
+  const empty: string[] = [];
+  const fresh = sortVersions(empty);
+  expect(fresh).toEqual([]);
+  expect(fresh).not.toBe(empty);
+  expect(latest(empty, {includePrerelease: true})).toBeUndefined();
+  const labels = ["1.0.0", "2.0.0-rc.1", "0.1.0"];
+  const saved = [...labels];
+  expect(latest(labels)).toBe("1.0.0");
+  expect(latest(labels, {includePrerelease: true})).toBe("2.0.0-rc.1");
+  expect(labels).toEqual(saved);
+  const invalid = ["2.0.0", "invalid", "1.0.0"];
+  expect(() => sortVersions(invalid)).toThrowError(InvalidVersionError);
+  expect(() => latest(invalid)).toThrowError(InvalidVersionError);
+  expect(invalid).toEqual(["2.0.0", "invalid", "1.0.0"]);
+});

patchground/catalog/release-version-ordering/checks/visible/tests/releasekit.test.ts

@@ -0,0 +1,31 @@
+import {test, expect} from "vitest";
+import {compare, sortVersions, latest, InvalidVersionError} from "../src/releasekit/index";
+
+test("ordinary labels compare with normalized signs", () => {
+  expect(compare("1.2.3", "1.2.3")).toBe(0);
+  expect(compare("1.2.3", "2.0.0")).toBe(-1);
+  expect(compare("2.0.0", "1.2.3")).toBe(1);
+});
+
+test("release picker handles double digit minor versions", () => {
+  expect(latest(["1.9.0", "1.10.0", "1.2.0"])).toBe("1.10.0");
+});
+
+test("sort returns fresh material and ignores build labels", () => {
+  const labels = ["1.0.0+z", "1.0.0+a", "0.9.0"];
+  const ordered = sortVersions(labels);
+  expect(ordered).toEqual(["0.9.0", "1.0.0+z", "1.0.0+a"]);
+  expect(labels).toEqual(["1.0.0+z", "1.0.0+a", "0.9.0"]);
+  expect(ordered).not.toBe(labels);
+});
+
+test("prerelease opt in and empty selection are explicit", () => {
+  expect(latest([])).toBeUndefined();
+  expect(latest(["2.0.0-rc.1"])).toBeUndefined();
+  expect(latest(["2.0.0-rc.1", "1.0.0"])).toBe("1.0.0");
+  expect(latest(["2.0.0-rc.1", "1.0.0"], {includePrerelease: true})).toBe("2.0.0-rc.1");
+});
+
+test("strict parsing rejects a leading zero", () => {
+  expect(() => compare("01.0.0", "1.0.0")).toThrowError(InvalidVersionError);
+});

patchground/catalog/release-version-ordering/debrief/questions.md

@@ -0,0 +1,9 @@
+# Debrief
+
+- Which smallest pair of labels reproduced the reported problem? How did you separate parsing from ordering?
+- Which check would catch an implementation that passes ordinary numeric cases but rounds very long numbers?
+- How did you test the prerelease rules independently rather than relying only on one long ordering chain?
+- What did equal-precedence build labels tell you about stable sorting and latest tie behavior?
+- Which parts of the starting library did you leave intact, and what evidence supported that scope?
+
+The timebox and difficulty are estimates. No independent human usability trial has been recorded.

patchground/catalog/release-version-ordering/environment/Dockerfile

@@ -0,0 +1,7 @@
+FROM node:24.15.0-bookworm-slim@sha256:4e6b70dd6cbfc88c8157ba19aa3d9f9cce6ba4703576d55459e45efcbc9c5f5d
+WORKDIR /opt/patchground
+COPY package.json package-lock.json ./
+RUN npm ci --ignore-scripts --no-audit --no-fund && npm cache clean --force
+COPY vitest-runner.mjs ./
+RUN chmod 644 package.json package-lock.json vitest-runner.mjs
+WORKDIR /workspace