Submission Gates

The design rule everything here follows

A failure to look must never be indistinguishable from having looked and found nothing.

That single sentence is what the gates are for. Every one of them has a state where the check could not run — a shallow clone, a failed history walk, an unresolvable dependency, an unreachable repo — and in every case the naive implementation records the same thing it would record for a clean result: no findings.

That is worse than not scanning at all, because it produces a scan row that says the submission was reviewed.

The five gates

### 1. A shallow clone is not history

CI checkouts default to depth 1. Scan a shallow clone for leaked secrets and you have scanned one commit while reporting that you scanned the repository. This **refuses to claim history was scanned** on a truncated checkout, and a failed history walk is recorded as a failure rather than as a clean history.

### 2. Count what you actually walked

The real commit count is recorded, and zero when history was not scanned — which fails closed downstream instead of reading as a tiny, clean repo. A secret that is gone from the working tree but still in the log is marked history-only, because it is still extractable and still needs rotating.

### 3. Declared is not detected

The licence a submitter claims and the licence actually found in the repo are reported separately, so a disagreement between them is catchable rather than silently resolved. An unrecognised licence body is undefined — never guessed permissive. No LICENSE file and no declared licence blocks the submission.

### 4. Unresolved is not permissive

Dependencies that cannot be resolved stay in the list without a licence, rather than being dropped. A resolution failure yields all-unknown rather than an empty list — the difference between "this has no copyleft dependencies" and "we could not tell," which look identical once the unresolved entries are silently discarded.

One copyleft dependency under a permissive top-level licence is caught, which is the common real case: the repo says MIT and something three levels down does not.

### 5. Every IO failure degrades to null

When the repo cannot be fetched, the scanner returns null and **no scan row is written at all** — rather than an empty result that reads as a pass.

Two more layers: consent, and the pipeline

consent — an agent prepares a submission, a human publishes it. Approval binds to a content hash, so a draft that changes between the moment a human read it and the moment they clicked is no longer approved. A price change after approval voids the approval, because the number was the thing they were agreeing to.

pipeline — three doors (web form, editor tool, phone link), one gate. The reasoning is worth stating: hosts disagree about approval, and several editors let a user auto-approve every tool call, so a local "allow" is evidence that a tool ran, not that a human read a price. The binding check therefore sits on the server, where no client setting can turn it off. A door may narrow what the pipeline offers; it can never widen it.

These two are namespaced, and that is a finding

consent and pipeline both export approve, reject and publish — the same verbs at different levels. Flattening them into one barrel silently shadows one with the other, and the caller gets whichever resolved last: a bug with no error message.

That was discovered during packaging, by a test that expected an approval and got a pending review. They are exported as namespaces:

  import { consent, pipeline } from "@amos-products/submission-gates";

The primitives (gates, scanner, dependency licences) stay flat.

Why the scanner is separate from the gates

The gates consume evidence; the scanner is the only thing permitted to produce it. That boundary exists because an adversarial review of an earlier version found two ways to publish on assertions rather than findings. Evidence is server-produced and commit-bound; a submitter cannot hand you a verdict.

What this does NOT do

No malware or vulnerability detection — run your existing security scan alongside; these are the questions it does not ask.

No git, network or filesystem access of its own: you supply the calls. No payout, identity verification or KYC. No licence compatibility analysis — it tells you what is present, not whether the combination is lawful for your use.

Verified

133 tests across the gates, scanner, dependency licences, consent and pipeline: shallow-clone refusal, failed history walks, commit counting, history-only secret hits, declared-versus-detected licence disagreement, unrecognised licence bodies, missing LICENSE, unresolvable dependencies, transitive copyleft under a permissive root, IO failure returning null, approval bound to a content hash, a price change voiding approval, and no path that auto-publishes.

Not covered: no test runs against a real git remote or a real registry. The ownership check verifies a token you place; it cannot prove authorship, and nothing here detects code copied from elsewhere.