From 5a97c34ed1e1bf698d06032d3d42a889871ab15f Mon Sep 17 00:00:00 2001 From: Machumerre <136588962+Machumerre@users.noreply.github.com> Date: Sun, 6 Sep 2026 16:13:39 +0200 Subject: [PATCH 1/3] =?UTF-8?q?Add=20lightweight=20contributor=20workflow?= =?UTF-8?q?=20for=20=E2=80=9Cgood=20first=20issue=E2=80=9D=20/=20=E2=80=9C?= =?UTF-8?q?help=20wanted=E2=80=9D=20issues?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds a concise “Contributor Workflow” section to `CONTRIBUTING.md` that guides new contributors through the process of picking a small issue, commenting before work, keeping the PR focused, running the minimal relevant validation, and reporting skipped slow checks. No code or CI changes are made. --- CONTRIBUTING.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f5ff55e5..6a5e86fa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -16,3 +16,16 @@ npm run cellfence:self-check Do not relax fixture expectations to hide implementation defects. If a fixture reveals an ambiguity, record the ambiguity in the change description and update the protocol only when the intended rule is clear. Publishing is intentionally not automated in v0.x. Future npm publishing should use GitHub OIDC trusted publishing rather than long-lived package tokens. + +## Lightweight contributor workflow + +If you’re new to the project or just want to tackle a small issue, follow this short path: + +1. **Pick an issue** – look for issues labeled `good first issue` or `help wanted`. +2. **Comment before you start** – add a comment on the issue stating you’re working on it. This keeps the maintainer aware and prevents duplicate work. +3. **Keep the PR focused** – the pull request should address only the acceptance criteria of the issue. Avoid adding unrelated changes or generated output. +4. **Run the minimal validation** – execute the smallest relevant CI checks (e.g., `make test` or `pytest -q`). +5. **Report skipped slow checks** – if you skip a longer check (e.g., mutation testing, full linting), mention it explicitly in the PR body and explain why. +6. **Include validation results** – paste the output or a link to the CI run in the PR description so reviewers can verify the changes. + +This workflow keeps the review cycle short and encourages quick, high‑quality contributions. From afa83ed46b67ed637ffbeb312607d961662a82e0 Mon Sep 17 00:00:00 2001 From: PushNaNaShi <84632330+pushnanashi2@users.noreply.github.com> Date: Mon, 7 Sep 2026 12:54:41 +0000 Subject: [PATCH 2/3] docs: align contributor workflow validation --- CONTRIBUTING.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6a5e86fa..75a2417e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -19,13 +19,15 @@ Publishing is intentionally not automated in v0.x. Future npm publishing should ## Lightweight contributor workflow -If you’re new to the project or just want to tackle a small issue, follow this short path: - -1. **Pick an issue** – look for issues labeled `good first issue` or `help wanted`. -2. **Comment before you start** – add a comment on the issue stating you’re working on it. This keeps the maintainer aware and prevents duplicate work. -3. **Keep the PR focused** – the pull request should address only the acceptance criteria of the issue. Avoid adding unrelated changes or generated output. -4. **Run the minimal validation** – execute the smallest relevant CI checks (e.g., `make test` or `pytest -q`). -5. **Report skipped slow checks** – if you skip a longer check (e.g., mutation testing, full linting), mention it explicitly in the PR body and explain why. -6. **Include validation results** – paste the output or a link to the CI run in the PR description so reviewers can verify the changes. - -This workflow keeps the review cycle short and encourages quick, high‑quality contributions. +If you're new to the project or just want to tackle a small issue, follow this +short path: + +1. **Pick an issue** - look for issues labeled `good first issue` or `help wanted`. +2. **Comment before you start** - add a comment on the issue stating you're working on it. +3. **Keep the PR focused** - address only the issue acceptance criteria, without unrelated refactors or generated output. +4. **Run targeted validation first** - use the smallest relevant npm check, such as `node --test tests/.mjs`, `npm run build`, or `npm test`. +5. **Report skipped slow checks** - if a full suite or mutation run is not practical, say exactly what you skipped and why. +6. **Include validation results** - add the commands you ran and a short result summary to the PR description. + +Documentation-only changes can use focused validation when the PR explains why +broader checks were not needed. From 5ccb8a23358a98d70c2de226aae5cf12e66136fe Mon Sep 17 00:00:00 2001 From: PushNaNaShi <84632330+pushnanashi2@users.noreply.github.com> Date: Mon, 7 Sep 2026 15:17:00 +0000 Subject: [PATCH 3/3] test: stabilize plugin cache identity check --- tests/engine-api-coverage.test.mjs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/engine-api-coverage.test.mjs b/tests/engine-api-coverage.test.mjs index e28f5294..bbab0673 100644 --- a/tests/engine-api-coverage.test.mjs +++ b/tests/engine-api-coverage.test.mjs @@ -1363,20 +1363,20 @@ test("engine changed checks require an explicit plugin cache identity", () => { plugins: [plugin], }); assert.equal(uncached.baseCacheHit, false); - const seeded = checkChangedRepository({ + const seeded = withFrozenDate("2026-01-01T00:00:00.000Z", () => checkChangedRepository({ rootDir, manifestPath: "cellfence.manifest.json", baseRef: "HEAD", plugins: [plugin], pluginCacheKey: "cache-test@1", - }); - const cached = checkChangedRepository({ + })); + const cached = withFrozenDate("2026-01-01T00:00:00.000Z", () => checkChangedRepository({ rootDir, manifestPath: "cellfence.manifest.json", baseRef: "HEAD", plugins: [plugin], pluginCacheKey: "cache-test@1", - }); + })); assert.equal(seeded.baseCacheHit, false); assert.equal(cached.baseCacheHit, true); } finally {