docs: Explain one boundary test fixture - first-time contributors welcome, no assignment needed

[aoto-tech]

Your first contribution can be one useful README improvement

Help someone understand what a CellFence test fixture checks and how to reproduce its result.

You do not need to change the engine, discover a bug, or understand the entire codebase. A focused improvement to one fixture README is enough.

This is a rolling call for contributions. Multiple contributors are welcome, with no deadline or contributor limit.

Pick one fixture

Browse fixtures/invalid/ and choose a README that is missing a clear explanation or reproducible instructions.

These fixtures illustrate useful topics:

Fixture	Topic
private-cross-cell-import	An import that reaches another cell's private implementation
path-alias-private-import	A path alias that resolves to a private import target
computed-dynamic-fail-closed	A computed import that cannot be resolved statically

These are starting points, not a list of guaranteed unfinished tasks. Check the current files and open PRs before choosing. If an explanation is already complete, choose another fixture or identify a specific remaining gap.

What to contribute

Read the fixture's source files, cellfence.manifest.json, and expected-result.json. Improve its README so a new reader can understand:

• Which files and cells are involved.
• Which manifest contract is being tested.
• Why the source triggers the expected finding.
• How to reproduce the result, including the actual rule IDs observed.

Link to the relevant files using relative paths. Keep the explanation focused on the fixture.

Run the reproduction

From the repository root:

npm ci
npm run build

# Replace the fixture path when working on another example.
node packages/cli/dist/index.js check \
  --root fixtures/invalid/private-cross-cell-import \
  --format markdown

node --test tests/fixtures.test.mjs
git diff --check

The example above is intentionally invalid: its check should fail and report CELLFENCE_PRIVATE_IMPORT. The fixture test suite should still pass because it checks the expected failure.

Do not change the source, manifest, expected results, or checker just to make an invalid fixture pass.

Follow the applicable validation requirements in CONTRIBUTING.md and AGENTS.md. Report commands actually executed and any checks you could not run.

Submit a PR

Fork CellFence, make one focused improvement, and open a PR.

For this rolling issue, no assignment, reservation, or advance comment is required. This is an explicit exception to the general "comment before starting" workflow. Check open PRs to avoid duplicating work.

Use Refs #45, not Closes #45. This issue stays open after individual contributions merge.

AI-assisted contributions and coding agents are welcome. Submit only work whose explanation, changes, and reported validation have been checked.

Acceptance criteria

• The README adds a useful explanation or fixes a concrete documentation gap.
• File references and explanations match the current fixture.
• Reproduction commands and observed results are documented accurately.
• The PR reports actual validation and does not duplicate existing work.

No engine changes or unrelated refactoring are needed for this task.

[kingdt1991-netizen]

You explicitly welcome first-time and AI-assisted contributors, so this may be relevant to people here who also want a path into verified paid work. Knight Exchange has opened a Founding Builder cohort for humans and AI agents, with explicit assignment, evidence-backed completion, and settlement verification. It is an additional work market, not a replacement for CellFence's contribution rules: kingdt1991-netizen/Knight-Exchange#5