sloptic 1.1.0__tar.gz

sloptic-1.1.0/.gitignore

@@ -0,0 +1,36 @@
+.venv/
+__pycache__/
+*.pyc
+.pytest_cache/
+
+# Hidden-pool probes must NEVER be committed to this PUBLIC repo. The real boundary is a
+# separate PRIVATE hidden-probe catalog repo; this is only a backstop.
+**/hidden/
+catalog-hidden/
+
+# GRADING OUTPUT MUST NOT BE PUBLISHED. A results file names real third-party apps and carries, per finding, a
+# paste-to-reproduce request against a live deployment — the v9/v10 corpus runs alone held 1,709 named Devpost
+# projects and 8,825 repro blocks. Black-box scanning of a public URL is one thing; publishing per-app
+# reproduction steps against someone else's submission is a different act, and it contradicts the product's own
+# guardrail (hand the builder back a private report, upside-only).
+#
+# THIS FILE IS THE SOURCE OF TRUTH FOR BOTH REPOS, and that is the whole point. The league -> mirror sync is
+# `rsync --delete` followed by `git add -A`, so rsync OVERWRITES the mirror's .gitignore with this one on every
+# sync — a fix applied only on the mirror side survives until the next sync and then silently un-ignores
+# everything (observed, not hypothesised). The sync command also carries matching --exclude flags; this is the
+# backstop for when one is forgotten.
+#
+# *.jsonl and NOT *.json: validation/benchmark-curve.json is the frozen scoring curve and must stay tracked.
+*.jsonl
+*.log
+*.tsv
+v9-baseline-stats.json
+nextjs-trace-sample.txt
+sprint-sample.txt
+terminal output of test.md
+
+# Diagnostic URL worklists carry hundreds of named third-party apps (the v11 session-gap list is 311). Same
+# reasoning as the grading output above: black-box scanning a public URL is one thing, publishing the list of
+# who we scanned is another. Keep the *pattern* here so a regenerated list is covered without anyone rememb-
+# ering to add it.
+*.urls.txt

sloptic-1.1.0/CONTRIBUTING.md

@@ -0,0 +1,162 @@
+# Authoring probes
+
+How to add, change, and remove probes. The engine is **fixed**; **probes are data**
+(`catalog/**/*.yaml`, loaded by `load_catalog()` at run time). Reusing existing detection needs no
+code change, only a *new* detection primitive touches Python. This is the practical recipe.
+
+The live lists of detection primitives are **`MATCHERS` and `PREDICATES` in `sloptic/probes.py`**,
+the source of truth (this doc deliberately does not enumerate them, so it cannot drift). Skim those
+dicts to see everything that exists today.
+
+## The probe schema
+
+```yaml
+id: sec-sqli-001            # unique: the LOADER KEYS ON THIS, NOT THE FILENAME (a dup id collides even
+                            #          across files with different names)
+bundle: security            # security | qa | performance
+category: sql-injection     # diminishing-returns damper applies WITHIN a category (sorted descending decay)
+variant_group_id: <id>      # optional; probes sharing one fire ONCE at the max penalty (same logical flaw)
+pool: public                # public | hidden
+evidence_model: provable    # provable (slop visible in a response) | oracle (differential / self-as-oracle)
+penalty: 40                 # slop added when it fires (deduction-only; always positive)
+applicability:
+  requires: [any_endpoint_accepts_text_input]   # capabilities from discovery; empty = always applicable
+probe:
+  # EITHER declarative (fetch a target, apply matchers):
+  method: POST
+  target: /search           # a literal path, or the selector "routes"/"forms" to fan across the surface
+  query: { q: "<payload>" }  #   optional query params
+  data:  { age: abc }        #   optional form body
+  # OR a predicate (multi-step oracle):
+  predicate: sqli_auth_bypass
+  payload: "' OR '1'='1' -- "   # arbitrary keys under probe: are read by the predicate via probe.probe
+slop_if:                      # declarative ONLY; ALL must match -> slop. Omit for predicate probes.
+  - response_contains: "<payload>"
+```
+
+## The two detection primitives (contracts)
+
+**Matcher**: `MATCHERS[name](resp, arg=None) -> bool`. A pure function over ONE response, `True` when
+slop is present. For declarative probes.
+
+**Predicate**: `PREDICATES[name](ctx, probe) -> bool | None`. A multi-step oracle. **Three-state, and
+the third state is load-bearing:**
+
+| return | meaning |
+| --- | --- |
+| `True`  | slop detected → the probe's `penalty` applies |
+| `False` | clean → tested and the flaw is absent |
+| `None`  | **not applicable**: could not establish the conditions to test (no such surface, self-registration failed, and so on). This is NOT a clean pass. A `False` when you could not actually test is a **false clean, a missed finding.** When in doubt between `False` and `None`, return `None`. |
+
+The `ctx` object gives a predicate: `ctx.base_url`, `ctx.headers` (auth), `ctx.profile` (the discovered
+surface: `.routes`, `.forms`, `.endpoints`, `.capabilities`), `ctx.client` (a shared httpx client), and
+`ctx.evidence` (see below). For a fresh, correctly authenticated client use
+`make_client(ctx.base_url, ctx.headers)` (seeds the cookie into the jar so a rotating session is
+followed; defaults `verify=False` so an https target with a self-signed cert is reachable).
+
+### Evidence (required for a new predicate)
+
+Every predicate should record what it measured or attempted via `ctx.evidence.update(key=value, ...)`,
+for **all** outcomes, clean and n/a too, not just slop. It rides in `--json` and the `-v` view, and is
+the product's transparency ("load_time_s=0.4 ✓", "tried error+boolean+union+time, none hit"). Keep it
+small and typed (numbers, short strings, small lists). Example:
+
+```python
+def perf_ttfb(ctx, probe) -> bool:
+    thresh = perf.TTFB_PROFILE
+    with make_client(ctx.base_url, ctx.headers) as c:
+        sample = perf.sample_ttfb(c, "/")
+    ctx.evidence.update(ttfb_s=round(sample, 3), threshold_s=thresh)   # <- what it measured
+    return sample >= thresh
+```
+
+### Safety (a probe fetches an UNTRUSTED, possibly authenticated target)
+
+- **Never GET a discovered `<a href>` navigation or a state-changing endpoint with the auth cookie.**
+  A blind fetch of `<a href="logout.php">` logs the grader's own session out mid-run and blinds every
+  later probe (this actually happened, `fix 8071b67`). Fetch only true subresources
+  (`<img/script/media src>`, `<link href>`), and skip logout/delete-looking links (see `broken_links`).
+- Never send `PUT`/`PATCH`/`DELETE` payloads that mutate the target's state; grading must be safe to
+  re-run. Read-only injection (`GET`/benign `POST`) only.
+- A predicate that raises is caught and degraded to N/A for that one probe (the run never DNFs), but
+  do not rely on it; handle `httpx.HTTPError`/`InvalidURL` yourself.
+
+## Add a probe
+
+### 1. Declarative, reusing a matcher: one file, no code
+Drop a YAML in `catalog/<bundle>/` with a `target` + `slop_if` using an existing matcher.
+
+### 2. A variant of an existing class: one file, same `variant_group_id`
+A new SQLi syntax or XSS payload: copy a sibling YAML, change the `payload`, keep the
+`variant_group_id`. It reuses the oracle and folds into the fire-once group (the group counts one
+penalty no matter how many syntaxes fire). **Give it a unique `id`.**
+
+### 3. A new detection primitive: +1 function, then the YAML
+Add a `MATCHERS` or `PREDICATES` entry (and a matching `_MATCHER_REASONS`/`_PREDICATE_REASONS` line for
+the human "why it fired"). Predicates emit `ctx.evidence`. **One finding per class, all its techniques:**
+cover the class's techniques (SQLi = error/boolean/UNION/time; XSS = script/img/svg/attr/…) but collapse
+them to ONE finding, a single predicate that returns once, or siblings sharing a `variant_group_id`.
+Breadth is recall, not score inflation; keep each technique precise (marker, differential, confirmation
+guards) so breadth does not cost false positives.
+
+### CI-lock it (per-technique reference servers)
+Add `tests/test_<name>.py` that stands up a throwaway `http.server` exhibiting exactly the flaw (one
+per technique) and asserts the predicate fires, plus a clean server it must not fire on, plus the N/A
+case. A fake `ctx` is `type("C", (), {"base_url": url, "headers": None, "client": None, "evidence": {}})()`.
+Note the **`evidence: {}`** (a predicate writes to it; the full suite catches a missing one via
+`AttributeError`).
+
+## Change a probe
+- **Tuning** (penalty, payload, threshold, applicability, pool) → edit the YAML field, re-run the suite.
+- **Detection logic** → edit the matcher/predicate (affects every probe that uses it, so review
+  accordingly).
+- **Pool flip** (public ↔ hidden) → change `pool:` and move the file between this public catalog and
+  the private hidden-probe catalog repo.
+
+## Remove a probe
+Delete the YAML and the runner stops loading it. Remove its assertion in `tests/`. For an event-grade
+catalog, *deprecate in the changelog* rather than silently delete, so past results stay interpretable.
+
+## Pricing a penalty (risk = frequency × severity)
+A penalty is **expected harm**, not raw severity. Price it by how often a real user is hurt × how badly:
+
+- **Security = low-frequency × terminal-severity.** A DB-dumping SQLi, auth bypass, or RCE is rare per
+  app (injection incidence ~3% of endpoints, Verizon DBIR / OWASP) but a single one is company-ending
+  (avg breach $4.4M, IBM 2025). These sit at the **per-instance ceiling (≈40)** and no other class
+  outranks a single one. Defense in depth (missing headers) is low × low, so it stays small.
+- **QA / performance = high-frequency × moderate-severity.** Every visitor on slow 4G hits the slow
+  page (~53% bounce past 3s, Google 2016; ~79% never return); every wrong-order user hits the crash
+  (~32% churn after one bad experience, PwC 2018); ~16% of people are barred by a11y failures (WHO
+  2023). Priced **up toward the deadly range but strictly below the catastrophic-security ceiling**, so
+  no single qa/perf penalty is ≥ the worst single security penalty.
+- **Net effect (deliberate):** the aggregate leans qa/perf (high-frequency harm stacks across many
+  probes and instances), while the per-incident ceiling stays with catastrophic security.
+
+Do not multiply ordinal severities (Cox 2008, *What's Wrong with Risk Matrices?*, ordinal labels are
+not cardinal). These magnitudes are a **designed table** with a consequence-triggered override band
+(terminal severity keeps the ceiling regardless of low frequency), the practice NIST 800-30 /
+MIL-STD-882E use.
+
+## The calibration gate (non-negotiable)
+Every add or change must keep `uv run pytest` green. A probe must read **slop on `references/vulnerable`,
+clean on `references/hardened`, and N/A or clean on `references/minimal`**: the same surface, three
+verdicts. If your probe needs a surface the references lack, add it (broken in `vulnerable`, defended
+in `hardened`). So "add a probe" is usually three coupled edits:
+
+1. the probe YAML,
+2. the reference surface (if new),
+3. the test assertion.
+
+That coupling is the point: a probe that cannot separate defended from broken from absent does not
+merge.
+
+**The score:** `tests/test_pipeline.py` holds the **single authoritative** vulnerable-app score
+(`assert report.slop_score == N`, plus an `axis_slop` decomposition assertion that must sum to it). A
+probe that fires on `vulnerable` changes `N` by its (damped) penalty, so update it there, in **one**
+place. `test_remote.py` and the docker tests assert *deployer-equivalence* (they equal the
+SubprocessDeployer baseline), so they self-track and never need editing for a scoring change.
+
+## Over time
+Versioning follows semver on a quarterly cadence, with PR review and public-vs-hidden pool governance.
+Hidden probes are authored the same way but live in the private hidden-probe catalog repo, never this
+public one.

sloptic-1.1.0/CORPUS_REPORT.md

@@ -0,0 +1,220 @@
+# The Shape of AI Era Web App Slop
+
+### A black-box quality audit of 1,528 live hackathon web apps
+
+**Reference release:** `2026.1` · **Instrument:** Sloptic (deduction-only black-box grader) · **Population:** live hackathon submissions
+
+---
+
+## TL;DR
+
+- On a corpus of **1,528** live web apps graded black-box, AI era "slop" is overwhelmingly **chronic**, not **acute**. Pervasive missing hygiene, not exploitable holes.
+- **98%** ship no Content-Security-Policy, **42%** never rate limit a login, **70%** have a critical accessibility violation. But only **3.8%** expose any exploitable vulnerability, and **zero** of the 1,528 a remote code execution class.
+- The acute danger has not disappeared. It **relocated behind authentication and vendor boundaries**: only **16.6%** of the apps with observed runtime traffic (176 of 1,063) even have an own injectable backend, so a black-box grader mostly cannot reach the dangerous surface.
+- **AI-builder apps are measurably sloppier, and it is a performance tax.** Apps generated by Lovable carry a statistically significant slop premium (median **72 vs 49** hand-built, p = 1.1e-5) that is **entirely performance**, heavy, slow bundles, not weaker security.
+- The overall score is smooth and unimodal (good for ranking), but the security axis is **bimodal**, two "header flat tax" values account for **70%** of it.
+- The median app defends **~94%** of its worst case failure surface. Slop is the rare exception, not the rule, per app.
+
+---
+
+## 1. The question
+
+AI assisted building makes shipping a web app nearly free, and the volume of "looks done" submissions has exploded. The security research is blunt about the tradeoff. Veracode's 2025 report, testing over 100 models on 80 tasks, found that **45%** of AI generated code introduces an OWASP Top 10 vulnerability and that AI written code carries **2.74 times** more flaws than human written code, a pass rate that had not budged by early 2026. The Cloud Security Alliance put the share of AI generated solutions carrying a design flaw or known vulnerability at **62%**. Hackathons feel this directly: when any team can generate a polished UI in minutes, judges report the bar for "impressive" moving from "does it look done" to "does it hold up." So a natural question for anyone grading these apps at scale:
+
+> When you look at a large population of real, deployed, AI era web apps from the outside, **what does the failure actually look like?** A field of exploitable vulnerabilities, or something else?
+
+This report answers that from one instrument's black-box view of 1,528 apps.
+
+## 2. The dataset
+
+| property | value |
+|---|---|
+| Apps ingested | 2,250 |
+| Apps successfully graded | **1,528** |
+| Attrition | dead URLs, pages that are not web apps, and submissions that never deployed |
+| Each row | one deployed app, graded over HTTP with no source and no spec |
+| Grader version | frozen catalog of 91 probes across 3 axes |
+
+Rows that could not be graded (a URL that never answered, a repo that never deployed) are excluded rather than scored, so the population is "apps that actually presented a working surface."
+
+### 2.1 Where the apps came from
+
+The corpus is drawn from **60 hackathons** on Devpost, whose public project galleries were scraped for submissions that shipped a live URL. The events span North America (the majority, largely US and Canadian university hackathons), Europe (London, Barcelona, Ireland), Latin America (Monterrey), and Asia Pacific (Singapore and Australia), with editions concentrated in 2025 and 2026. From these galleries, **2,250** submissions carried a gradeable URL and **1,528** graded successfully. The full list of 60 events is in Appendix A.
+
+This provenance matters for reading the results. The population is young, collegiate, time boxed (a hackathon is a day or a weekend), and built in the AI era, so it is a clean look at what teams ship when speed is everything and the tooling writes much of the code. It is deliberately **not** a sample of production software.
+
+Every figure in this report is computed on one grading run (n = 1,528). The frozen percentile curve used to rank a new app against this population remains **2026.1**, built from the prior run; it stays valid because the two runs rank correlate at **0.967** with an unchanged median, so the scored numbers here and the ranking curve describe the same population.
+
+## 3. Method
+
+Sloptic is a **black-box** grader. It reads no source, needs no spec, and emits one **slop score**: deduction-only, unbounded, lower is better, `0` means nothing was found. The score decomposes into three axes (security, quality, performance) whose subtotals sum exactly to the total. Penalties are risk priced (frequency times severity) and damped, so one root cause counts once.
+
+Because it ignores the stack, the same 91 probes run identically against every app, which is what makes 1,528 unrelated apps **comparable on one axis**. Every grade also ships a coverage report, so a `0` that means "clean" is distinguishable from a `0` that means "we could not reach the surface."
+
+Two things this method is honest about up front: it grades the **unauthenticated, observable** surface, and it measures **intent-independent** failures only (defects no matter what the app is for).
+
+## 4. Results
+
+### 4.1 The score distribution
+
+| statistic | value |
+|---|---|
+| mean | 55.1 |
+| median | 49 |
+| max | 168 |
+| distinct values | 132 |
+| landmarks (p10 / p25 / p50 / p75 / p90 / p99) | 26 / 35 / 49 / 70 / 89 / 142 |
+
+The overall score is **smooth and nearly unimodal**, the largest single spike holds under 5% of the population. This is exactly the property a ranking needs: the convolution of three axes and many probes spreads apps out, so a percentile is meaningful.
+
+### 4.2 What drives the score
+
+Penalty mass splits across the three axes like this:
+
+| axis | share of total slop | median | shape |
+|---|---:|---:|---|
+| security | **41.9%** | 14 | bimodal (two values = 70%) |
+| quality | 36.4% | 20 | spike at 0 (15%), then spread |
+| performance | 21.7% | 0 | **62% score zero** |
+
+The probes that fire most often are not exotic. They are missing HTTP headers:
+
+| prevalence | probe |
+|---:|---|
+| 98% | missing Content-Security-Policy |
+| 97% | no clickjacking defense |
+| 91% | missing `X-Content-Type-Options` |
+| 90% | missing `Referrer-Policy` |
+| 70% | critical accessibility violation |
+| 42% | login with no rate limiting |
+
+A finding at 98% prevalence is nearly a constant, it taxes everyone and separates no one. The **discriminating** signal lives in the middle band (rate limiting at 42%, source map disclosure at ~10%, accessibility tiers, Core Web Vitals), which is where apps actually pull apart.
+
+### 4.3 Severity composition: chronic, not acute
+
+This is the headline. Split every security finding into **acute** (exploitable now) versus **chronic** (missing mitigation), and the population is lopsided:
+
+| tier | rate | examples |
+|---|---:|---|
+| any acute finding | **3.8%** | |
+| remote code execution / injection | **0%** | zero of 1,528 apps (SQLi / command / template injection) |
+| data exposure | 2.68% | world readable managed backend, bulk PII |
+| secret or source file leak | 0.85% | served `.env`, `.git`, backups, keys |
+| source map disclosure (moderate) | ~10% | production `.map` leaks original source |
+| chronic hygiene (representative) | 41 to 98% | headers, rate limiting, accessibility |
+
+Read the two ends together: **~4% of apps are exploitable, not one has a remote code execution hole, while 40 to 98% are missing basic hygiene.** The functionality is mostly there; the nonfunctional floor is pervasively absent. That is the empirical signature of AI era slop from the outside, chronic rot, not a field of smoking guns.
+
+### 4.4 Why the acute surface is so thin
+
+The low acute rate is not "these apps are safe." It is an artifact of **where the modern stack puts the danger.** Of the graded apps, **1,063 exposed observed runtime traffic** we could classify by host tier. An app's traffic routinely spans several tiers at once (a same-origin API *and* a managed BaaS *and* a consumed vendor), so **the tiers OVERLAP: each row counts how many of the 1,063 have *any* host of that tier, not a slice of a pie. They sum to 1,487 tier-memberships across 1,063 apps (≈140%), not to 100%, and must not be read as shares of a whole.**
+
+| host tier | apps with this tier (of 1,063 classified; overlapping) | injectable black-box? |
+|---|---:|---|
+| same-origin (static frontend) | 682 (64%) | no backend to inject |
+| third-party vendor (consumed) | 272 (26%) | not the app's surface |
+| opaque (unattributable off-origin) | 203 (19%) | not probed (flagged, no clean-bill credit) |
+| **own backend (attributed)** | **176 (16.6%)** | **yes** |
+| managed backend (Supabase / Firebase) | 154 (14%) | only via row-level security config |
+
+**Only 16.6% of the classified apps (176 of 1,063 with observed runtime traffic) have an own injectable backend**, and that is already a share of the traffic-bearing subset, not of the full corpus. You cannot inject SQL into a static site, and a managed backend app's only misconfiguration knob is row-level security. So the classic acute classes (SQLi, RCE) have almost no surface to land on, and the genuine acute risk that remains is disproportionately **backend misconfiguration** (the data-exposure tier), which is exactly where a black-box probe can still reach it. (Tier counts are off-score diagnostics from `scripts/stats.py`; they are the overlapping tiers over the 1,063 classified population.)
+
+By hosting platform, identified from response headers and origin suffix (`platform_id`, off-score), the population is dominated by Vercel:
+
+| platform | apps (of 1,528) |
+|---|---:|
+| Vercel | 988 (65%) |
+| unknown / custom (unattributable) | 136 (9%) |
+| Netlify | 99 (6%) |
+| GitHub Pages | 71 (5%) |
+| Streamlit | 66 (4%) |
+| Lovable | 56 (4%) |
+| other (Render, Firebase, Cloud Run, Cloudflare, Railway, ...) | 112 (7%) |
+
+A further 200 apps sit behind a Cloudflare edge and 70 behind Fastly; a fronting CDN can mask the origin platform, which is why 9% stay unattributable rather than guessed. Reading response headers as well as the domain suffix cuts that unattributable share to 9% (a suffix-only pass leaves ~32% "custom/other"). A population this heavy on Vercel also explains why bot challenges rarely interfered: Vercel's bot protection is opt-in, and hackathon teams almost never configure it.
+
+### 4.5 The AI-builder slop premium
+
+Because `platform_id` also fingerprints the *builder* from served markup (Lovable ships `cdn.gpteng.co`, Bolt its own signature), we can test the question the AI-slop thesis rests on: do AI-built apps carry more slop than hand-deployed ones? For Lovable the answer is yes, and it is specific.
+
+| group | n | median slop | mean slop |
+|---|---:|---:|---:|
+| hand-built (no builder signature) | 1,459 | 49 | 54 |
+| **Lovable** | **58** | **72** | **73** |
+| Bolt | 11 | 44 | (n too small to read) |
+
+The Lovable gap is statistically significant (Mann-Whitney U, one-sided, **p = 1.1e-5**) and it is **entirely performance**. Decomposed by axis (mean penalty per app), Lovable's performance slop is **30.0 versus 11.1** for hand-built (a +18.9 gap), while its security is marginally *lower* (−2.8) and its QA marginally higher (+2.6). Lovable apps are not less secure; they ship **heavy and slow**: large unsplit bundles, uncompressed responses, weak Core Web Vitals, the diffuse performance floor an AI builder trades away for generation speed.
+
+Three bounds on the claim, stated. It is a correlation, not a controlled experiment, though the all-performance decomposition makes the mechanism concrete. Bolt's n = 11 is too small to read (its median is *lower*, but on eleven apps that is noise). And detection is a floor: a Lovable app on a custom domain with its signature stripped falls into the hand-built bucket, which can only *understate* the gap. The same pattern shows up by host: Streamlit is the sloppiest platform (median 88, another auto-generation stack), GitHub Pages the cleanest (34, static sites have little floor to miss).
+
+### 4.6 Measurement validity
+
+A ranking is only trustworthy if the ruler is stable. Two independent runs over the full corpus agree closely:
+
+| metric | value |
+|---|---:|
+| Spearman rank correlation | **0.974** |
+| deciles identical | 92.6% (96% within one) |
+| apps scoring exactly the same | 92% |
+| systematic drift | none (mean delta +0.15) |
+
+The residual movement is confined to the probes where black-box nondeterminism is unavoidable (stateful browser behavior, Core Web Vitals timing, and the security tail behind authentication); the deterministic surface holds.
+
+Coverage is reported per grade: the median app had **62%** of the battery apply to it, so the scores are legible as "clean," not "untested."
+
+## 5. Interpretation
+
+One number captures the thesis. The median app's **worst case slop** (the score it would carry if every applicable probe fired) is **866**, while its actual median score is **49**. The median app therefore realizes only about **6%** of its potential failure surface: it defends nearly everything it exposes, and fails on the diffuse hygiene it never thought about.
+
+So the story of this corpus is not "AI writes insecure code that gets exploited." From the black-box, it is "AI writes **functional** code that ships without the boring, universal, nonfunctional floor," no headers, no rate limiting, no accessibility, sometimes a leaked source map. The acute danger is real but rare and increasingly hidden behind authentication and vendor APIs, which is a finding about the modern stack as much as about the apps.
+
+## 6. Limitations (stated, not hidden)
+
+- **Unauthenticated surface only.** Defects behind a login the grader cannot establish are undercounted. The true acute rate is a floor.
+- **Recall is not audited, and precision is vouched, not blanket.** This release guarantees **stability** (the ruler repeats) and **precision on the classes that carry explicit precision rules**; findings elsewhere are **unaudited, not endorsed**. That unaudited mass (most of the in-score penalty by count) is dominated by **deterministic presence checks** (a security header is absent, a `.map` resolves, a control is dead) where false-positive risk is structurally low. But the audit cannot distinguish "no rule needed" from "no rule written," and we can, so we report it as unaudited rather than claim a precision we have not checked. The false-negative rate against ground truth is measured separately and is ongoing: a low finding rate for a class could mean "rare" or "our detector missed it," and only a recall benchmark distinguishes them.
+- **Intent-independent scope.** Sloptic grades the universal floor, not whether a feature is good. Originality, product quality, and creativity are out of scope by design.
+- **Population, not universe.** Hackathon submissions skew toward young, small apps that are heavy on the frontend. The distribution should not be read as representative of production software at large.
+
+## 7. Reproduce
+
+```sh
+# freeze the reference distribution from a corpus run
+uv run python scripts/benchmark.py build <run>.jsonl --version 2026.1 --status final
+
+# place any single app on that curve
+uv run python -m sloptic.cli --target https://your-app.example.com --out app.jsonl
+uv run python scripts/benchmark.py rank --results app.jsonl
+```
+
+## Sources
+
+Background figures on AI generated code are external; the corpus figures are this instrument's own measurements over the 2026.1 population.
+
+- [Veracode 2025 GenAI Code Security Report](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/) (45% of AI generated code introduces an OWASP Top 10 flaw; 2.74x more vulnerabilities than human written code)
+- [Veracode, Spring 2026 GenAI Code Security update](https://www.veracode.com/blog/spring-2026-genai-code-security/) (the 45% pass rate had not improved through early 2026)
+- [Cloud Security Alliance, AI generated code vulnerability research](https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-codegen-vulnerability-debt-20260406-csa/) (62% carry a design flaw or known vulnerability)
+- [Vercel Bot Management docs](https://vercel.com/docs/bot-management) (bot protection is opt-in, which is why it rarely interfered)
+
+## Appendix A: the 60 hackathons
+
+Devpost event slugs, as ingested:
+
+```
+hack-brown-2026        ds-x                   bigred-hacks-2025      luddyhacks
+innovation-hacks-2     hackgt-12              hacktech-by-caltech-2026  mhacks-2025
+hacknyu-2025           vthacks-13             jumbohack-2025         devfest-2026
+hack-mit-2023          ai-hackathon-2026      hacktx2025             jumbohack-2026
+hackrice-15            hackprinceton-fall-2025  hackdartmouth-xi     hackbeanpot2025
+la-hacks-2026          la-hacks-2025          treehacks-2026         bostonhacks-2025
+hackharvard-2025       hackduke-code-for-good-2026  hackillinois-2026  hackcwru-012025
+beaverhacks            boilermake-xii         terrahacks-2025        hackpsu-spring-2026
+uwb-hacks-the-future   civic-hacks-2026       hackumass-xiii         uofthacks-13
+deltahacks-12          hack-western-12        nwhacks-2026           hackku26
+newhacks-2025          hacknc-2025            hacklondon-2026        hackupc-2026
+kenthackit             emory-hacks-2025-fall  interhackbcn           steminate-hacks-2026
+hackeurope             hack4her-mty           hackmty2025            hacknroll2026
+uncommon-hacks-2026    swamphacks-xi          hack-arizona-2026      wildhacks-2026
+nus-fintech-summit-2026  unihack2026          usaii-global-ai-hackathon-2026  hack-ireland-2025
+```
+
+*All figures are aggregate over the 2026.1 population. No per app identities are stored or reported.*

sloptic-1.1.0/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 Ian Sun
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.