CONTRIBUTING step 4 reads as a hard precondition, and it has cost us two contributors' correct work

[cevheri]

CONTRIBUTING.md step 4 says "Run the local gate before pushing" and then prints a nine-command chain. Read as written, that is a precondition for opening a PR. It is not: the required CI checks are the authority, and a fork PR's checks run once a maintainer approves the workflow. Contributors whose environment cannot install bun (or helm, which the chart tests need - see #570) have no way to satisfy the sentence, and two of them have now withdrawn rather than submit work they could not verify.

Measured, twice.

• 2026-09-05, CONTRIBUTING prerequisites omit Helm, which 166 tests in bun run test need #570: the claimant released the claim with "the required Bun-based test gate is unavailable in my current environment, so I cannot verify the change to the repository standard." No PR was ever opened.
• 2026-09-07, test(env): resolve static process.env bracket reads in the docs guard #612 and docs(sqlite): replace 7 stale line-number citations with named citations #613: both PRs were opened against curated issues (The env-documentation guard sees 40 of 62 variables, and 16 of the missing 22 are statically resolvable #609, docs/providers/sqlite.md: replace 7 stale line-number citations with named citations #587), then withdrawn 80 minutes later with "withdrawing the contribution, sorry for the noise." Both were measured after the fact and both were correct and complete: test(env): resolve static process.env bracket reads in the docs guard #612 takes the env extractor from 40 names to 57, docs(sqlite): replace 7 stale line-number citations with named citations #613 leaves no .ts:<line> citation in either doc, and each PR's own test file is green. Our required checks had never run on either, because nobody had approved the fork workflow.

So the wording is losing correct work, and the fork-approval step makes the only remaining verification path invisible to the contributor.

Fix, two parts.

1. CONTRIBUTING.md, step 4: keep the command chain, and add that CI is the gate - a contributor who cannot run a step may say so in the PR body under a Testing heading, naming the commands they could not run, and a maintainer approves the workflow run. Mention npm install -g bun for sandboxes with npm registry access, and that helm is only needed for the unrelated chart tests. The same sentence belongs in the footer we paste onto curated Hacktoberfest issues (that footer is not stored in the repo today - putting it in a file under .github/ so it stops being retyped is welcome in the same PR).
2. Add a .devcontainer/ with Bun and helm on PATH, so Codespaces and any devcontainer-aware editor give a contributor an environment where the chain in step 4 actually runs. bun install and helm dependency build charts/libredb-studio are the two setup steps worth wiring into postCreateCommand.

Done when step 4 no longer reads as a hard precondition, the CI-is-the-gate sentence exists in both places, .devcontainer/devcontainer.json opens a container where bun run typecheck and helm lint charts/libredb-studio --strict both succeed, and the container config is verified by an actual container start rather than by inspection. Docs plus config; no product code, and nothing here needs a new test beyond what the repo already guards.

Part 1 alone is a useful PR if part 2 is more than you want to take on - say so when you claim it and take just the docs half.

[j-gynn]

Hello! I just wanted to let you know that your second point's author haas26p-ctrl is/was a headless AI agent spamming repos. After the project I am involved in banned them (as we explicitly do not want AI submissions), they went through all their PRs and closed them with the same message apologising for the noise. Just so you don't feel guilty about that.

[cevheri]

Hello! I just wanted to let you know that your second point's author haas26p-ctrl is/was a headless AI agent spamming repos. After the project I am involved in banned them (as we explicitly do not want AI submissions), they went through all their PRs and closed them with the same message apologising for the noise. Just so you don't feel guilty about that.

Thanks for the feedback👍; they withdrew all their PRs on the same day. I check every contributor's profile, and I saw that too; however, hoping there was a real person on the other end, and seeing that the development work was solid, I said that: dont give up.
If they don't reply, I'll unassign these issues

[SyedMuhamadYasir]

I would like to take both parts of this issue: clarify the contribution gate and add the reusable issue footer, then add a Bun/Helm devcontainer and validate it with an actual container start. I will submit a PR referencing #618 with the validation results.