CrossCheck · implementation

Your repository tells coding agents what to do. We make sure it only tells them one thing.

People and AI coding agents both change repositories without seeing the whole picture. A repository can end up declaring pnpm while an agent quietly adds a package-lock.json, and every build still passes. CrossCheck reads the configuration evidence, tells you where a repository contradicts itself, and lets you enforce the decision you actually made.

This page is the one-off implementation package: we do that work across your repositories rather than handing you a tool and wishing you luck.

US$499 one-off. Not a subscription, and no recurring charge is started by this purchase.

What you get for US$499

• CrossCheck implemented on up to 10 GitHub repositories
• A baseline of package-manager configuration findings and declared repository decisions
• Warn-only or blocking enforcement configured for each repository
• False-positive and edge-case review during rollout
• Up to 2 organisation-specific checks
• A baseline report for every repository plus a prioritised rollout summary
• 30 days of rollout support and a final re-scan

Ongoing monitoring after the rollout is a separate recurring plan. You are not required to take it, and the implementation stands on its own — the configuration lives in your repositories.

What actually happens

1. 01Purchase. You buy the implementation package through Stripe. No GitHub connection is required to pay.
2. 02Scoping. We confirm which repositories to cover, which coding agents your team uses, and whether you want warn-only or blocking enforcement.
3. 03Baseline. We run CrossCheck across those repositories and record what each one currently declares, what its lockfiles and CI actually do, and where those disagree.
4. 04Implementation. We configure CrossCheck in your GitHub environment and set enforcement per repository.
5. 05Edge-case review. We go through the findings with you and suppress or adjust anything that is deliberate rather than a defect. This is the part that takes judgement.
6. 06Reports. A baseline report for each repository, plus one prioritised summary of what is worth fixing first.
7. 0730 days of rollout support. We stay available while it settles into your pull-request workflow.
8. 08Final re-scan. We re-run the baseline at the end so you can see what changed.

What access we need

You do not upload source code to zFinia. CrossCheck runs inside your GitHub environment. You choose whether to grant temporary setup access or have us provide the exact files and pull requests for your team to apply.

CrossCheck itself reads configuration files only. It does not install dependencies, execute your code, or make network calls while scanning. It is MIT-licensed and you can read every rule it applies: github.com/zFinia/crosscheck.

Why you should believe any of this

We have used CrossCheck on public repositories and reported what it found. In these cases the maintainers independently confirmed the problem and fixed it themselves. These are public records you can open and check. None of these maintainers are customers — they are evidence that the tool finds real things, not evidence that anyone has paid us.

The method is published in full, including what it cannot do: METHODOLOGY.md. Static repository state does not always establish intent — two lockfiles updated deliberately in the same commits look identical to one abandoned manager. We say so rather than guessing, and the edge-case review in this package exists precisely because that judgement cannot be automated away.

First, the free thing you should do instead

If your repository declares "packageManager" in package.json, Corepack (once enabled) stops someone running the wrong one of pnpm or Yarn, and CI setup actions and coding agents can read the same declaration. It does not, by default, stop a bare npm install: npm is not managed by Corepack unless you opt in. It is still one line, it costs nothing, and it is the right first step. Do that first. We would rather tell you than sell around it.

We scanned 82 organisations that run coding agents in CI. About 13% had any contradictory lockfile state at all, and once throwaway repositories and deliberate test fixtures are excluded, roughly 7% had something worth raising. The rest were clean — and clean because they already declare the field. So the honest question is not “do you have this problem” — most teams do not — it is whether the part Corepack cannot do is worth paying for:

• Corepack is per repository. It enforces the field where the field exists. It cannot tell you which of your repositories are missing it, which drifted before it was added, or where CI installs with something the manifest never declared.
• Corepack has no opinion about intent. A second lockfile is sometimes deliberate — dual publishing, a compatibility matrix, a migration in flight. A naive checker flags those identically to real mistakes, which is how teams end up muting the check. Separating the two is judgement, and it is most of what this engagement is.

If you have one repository and you have added the field, you do not need us. That is a real answer, not false modesty.

Who this is for

Teams where more than one person or coding agent changes the same repositories — Claude Code, Codex, Cursor, Copilot, or a mix — and where a repository carrying contradictory configuration costs real time. It is most useful across several active repositories rather than one.

It is probably not worth US$499 to you if you have one repository, one developer, and no AI coding agents. We would rather say that than sell it to you.