Hold .soldeerignore against the repo root, and stop shipping .audit/

[thedavidmeister]

Closes #91

No test guards this change, and it can regress silently

This PR ships no forge test. The check it used to carry —
test/package/SoldeerIgnore.t.sol, which listed the repo root and held
.soldeerignore against it in both directions — has been deleted, and the
repo-root { access = "read", path = "./" } fs_permissions grant it needed has
been reverted, so fs_permissions is back to its base three entries.

That means: nothing in this repo will notice if this regresses. A new
top-level path can start shipping in the soldeer package because nobody added it
to .soldeerignore, and a .soldeerignore entry can go dead — matching nothing,
exactly the .vscode and /docs defect this PR fixes — and the suite will stay
green through either. There is no test to strengthen and no assertion to read;
the only thing standing between the package and the next leak is someone editing
.soldeerignore by hand, correctly, at the same time they add a root path.

The check is being rehomed to rainlanguage/rainix#317 — "Six repos' worth of
static analysis is being hand-rolled in Solidity because rainix-static has no
home for repo-wide lint checks". It is a repo-root packaging rule, not a
statement about any Solidity in src/, and it belongs in shared static analysis
that every rain repo gets, not in one repo's forge test reading its own
directory listing through a cheatcode. Until that lands, this is unguarded.

Why the test was here at all

The fixer brief that produced this PR said every fix ships a test and
verify-by-hand is never acceptable, with no exemption for changes that have no
behaviour. That was wrong and has been corrected. .soldeerignore and
.gitignore are configuration files with no Solidity behaviour, and the test
written to satisfy that brief was hand-rolled static analysis in Solidity: 174
lines whose subject was a directory listing and two text files, with two of its
four tests asserting only against its own hardcoded shipped() set — itself a
hand-maintained second definition of the package, which is the same class of
defect as the .soldeerignore drift it was written to catch.

What ships here

.soldeerignore and .gitignore. This is the change with the real consequence:
.audit/ stops shipping, and meta/ can no longer leak.

Dead entries, the finding as filed. .vscode and /docs matched nothing and
never have — git log --all -- .vscode and git log --all -- docs are both
empty. Removed.

.audit/ was shipping. The audit stamp commit added .audit/runs.jsonl and
.audit/scope.json at the root. .soldeerignore excluded /audit but not
.audit, so both files are inside the published package. Confirmed against the
registry rather than inferred — unzip -Z1 on the 0.1.12 and 0.1.16 zips
pulled from api.soldeer.xyz lists:

.audit/
.audit/runs.jsonl
.audit/scope.json

Now excluded via /.audit.

meta/ was one test run away from shipping.
LibCodeGenDescribedByMetaHashConstantStringTest.setUp does vm.createDir("meta"),
and the directory is left behind at the repo root. It was in neither .gitignore
nor .soldeerignore, so any package built from a tree that has run the suite
carries it. It is absent from 0.1.12 and 0.1.16 because the publish job does
not run the suite, so this is latent rather than already leaked — but it is
latent by luck, not by design. Now excluded, and gitignored alongside cache,
dependencies and out, which is what the rest of the suite's output already
gets.

The issue's note about keeping .DS_Store is right and the entry is untouched:
nothing here produces it and git is not told about it, but macOS writes it into
any directory it browses.

Where the issue's proposed fix was incomplete

The issue said "delete lines 8 and 12" and it was right about those two lines. It
did not name .audit or meta, and neither would have been found by reading the
list — .audit needed the published zip and meta needed the suite to run. Both
are the same defect the issue describes, so both are fixed here.

Interaction with #121

#121 (issue #84) removes .gas-snapshot and its .soldeerignore entry. The two
changes do not conflict textually. With no test in this repo holding the list
against the root, nothing forces whichever lands second to do both halves —
dropping the file without the entry, or the entry without the file, is now silent
in both directions. That is a concrete instance of the regression this PR is
unguarded against.

QA

• Full suite: nix develop -c forge test — Ran 18 test suites: 142 tests passed, 0 failed, 0 skipped (142 total tests). Before the strip, on the same
  merge commit, Ran 19 test suites: 146 tests passed, 0 failed, 0 skipped (146 total tests) — the count drops by exactly the four
  test/package/SoldeerIgnore.t.sol tests removed, and nothing else changes.
• nix develop -c forge fmt --check — clean, no diff.
• origin/main is merged in (merge, not rebase), which brings Declare every tooling builder view so an implementation can read state #124.
• foundry.toml is now byte-identical to origin/main — git diff origin/main -- foundry.toml is empty.
• Oracle for what ships is the published package itself, not the source:
  unzip -Z1 over the 0.1.12 and 0.1.16 zips fetched from api.soldeer.xyz
  gives the actual shipped file list, and .audit/runs.jsonl and
  .audit/scope.json are in it, which is the leak. For the dead entries the
  oracle is git log --all -- .vscode and git log --all -- docs, both empty,
  so neither path has ever existed here. For meta the oracle is the suite's own
  vm.createDir("meta") plus the directory left at the root after a run.

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 1 minute

Limit details: You’ve used all 1 included review currently available under your plan.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 6c20aad3-50f6-41f2-8e10-61191f2fc933

📥 Commits

Reviewing files that changed from the base of the PR and between b422d97 and a3f90fe.

📒 Files selected for processing (2)

• .gitignore
• .soldeerignore

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}