Add pre-publication similarity screening and creator protection

[jal-co]

Problem

Creator feedback identified a launch-critical trust concern: component marketplaces commonly accumulate unattributed copies, impersonation, and low-effort derivatives. Even a free listing can imply that a creator or brand endorses the surrounding catalog.

Modulora already collects provenance and performs human listing review, but it needs an enforceable pre-publication similarity filter and an accountable dispute path. This must reduce plagiarism risk without claiming that automation can prove originality or plagiarism.

Product principles

• Similarity is a review signal, never an automated accusation or a generic trust badge.
• A human listing review is not proof of ownership, originality, security, or freedom from plagiarism.
• Never create a creator account, profile, listing, copied preview, or apparent brand association without affirmative authorization.
• Creators must be able to report attribution or association problems without opening a Modulora account.
• Promotion, marketplace status, Plus, or revenue potential must never affect thresholds, review priority, or outcomes.

Scope

Submission filter

Run similarity screening before a draft can enter the review queue:

1. Detect exact file/content-digest matches across the Modulora corpus.
2. Detect renamed or reformatted near-duplicates using normalized source fingerprints.
3. Produce file-level similarity candidates with explainable matched regions; do not return only an opaque score.
4. Exclude expected shared scaffolding, generated files, vendored dependencies, and common shadcn primitives from decisive scoring.
5. Ask the submitter to classify material matches as original work, authorized republication, fork/derivative, or false positive and provide the original URL plus authorization/attribution where applicable.
6. Block automatic submission for exact or high-confidence cross-owner matches until a curator resolves them.
7. Fail safely: scanner errors must not silently pass a submission into review.

Initial screening may compare only against Modulora's own immutable release corpus. External-source discovery can be a later phase, but the UI and evidence model must state the corpus limitation exactly.

Curator review

• Show side-by-side source comparison, matched files/regions, normalized versus raw similarity, provenance records, original URLs, ownership claims, and prior decisions.
• Support outcomes: clear, request evidence, require attribution/license correction, reject, escalate dispute, or link as an authorized derivative.
• Require reviewer rationale and preserve an immutable audit record.
• Detect repeat submissions and previously resolved matches without treating precedent as an automatic verdict.
• Keep similarity evidence neutral in color and language; it must not borrow success/approval styling.

Creator protection and remediation

• Extend the existing account-optional webhook report intake into a durable moderation-case flow for plagiarism, impersonation, copied previews, incorrect attribution, and unauthorized brand association.
• Accept reports without requiring a Modulora account; verify contact privately.
• Preserve the challenged release, evidence, notices, responses, decisions, and appeal history.
• Support temporary listing restriction, takedown, attribution correction, release revocation, and appeal.
• Do not expose private reporter contact information or unpublished evidence publicly.

Public representation

• Component details show original source, creator authorization/relationship, derivative attribution, review scope, and active dispute/takedown state where appropriate.
• Never display “originality verified,” “plagiarism free,” or an equivalent universal claim.
• Describe similarity screening as scoped to the corpus and methods actually used.

Acceptance criteria

• New submissions receive exact-digest and normalized-source similarity screening before review submission.
• Exact/high-confidence cross-owner matches cannot bypass curator resolution through direct API calls.
• Common scaffolding and generated/vendor files are excluded or down-weighted with test coverage.
• Submitters can disclose original, authorized, derivative, and false-positive relationships with supporting URLs/evidence.
• Curators receive explainable file/region comparisons and must record a scoped decision rationale.
• Decisions and later disputes have an immutable audit trail.
• A creator can submit a plagiarism/impersonation/association report without an account to the configured report webhook.
• Reports are persisted, reporter contact is privately verified, and restriction, takedown, correction, revocation, notice, and appeal states are recorded.
• Listing restrictions, takedowns, corrections, revocations, notices, and appeals are represented explicitly.
• Public copy states corpus/method limitations and makes no originality guarantee.
• Paid status and promotion do not alter screening or review behavior.
• Unit tests cover exact copies, renamed copies, formatting-only changes, shared scaffolding, authorized forks, false positives, scanner failure, and direct API bypass.
• Storybook covers clear, potential match, blocked, authorized derivative, under dispute, and takedown states without server imports.
• E2E covers submit → match → curator comparison → decision and public report → remediation.

Follow-ups

• Evaluate privacy-preserving external-source discovery and opt-in creator source registration.
• Publish the moderation, notice, appeal, and repeat-infringer policy after counsel review.
• Measure false-positive/false-negative rates before changing thresholds; never tune for catalog growth.

Area: Trust & Safety

[jal-co]

Audit update: keep high priority after #69. Existing account-optional webhook reporting is now reflected in the body; remaining scope is similarity screening, explainable evidence, durable/private moderation cases, contact verification, notices, decisions, and appeals.

[jal-co]

Similarity screening and creator protection landed in #79 and are deployed (Worker 0772c473).

Shipped:

• Pure screening engine (sim-alpha-1): exact digests + normalized token fingerprints with explainable matched line regions; scaffolding never scores decisively
• Draft-first publish: promotion to the review queue happens only after a durably persisted clean/potential screen \u2014 scanner and persistence failures fail closed
• Corpus is approved + public + unmoderated + non-revoked releases only, deterministic under the cap; unpublished work can never leak to other submitters
• Blocked submissions hold for curator resolution (clear / authorized derivative / attribution required / reject / escalate), rationale required, version-matched and atomic against draft-swap races
• Submitters classify matches (claim, never verdict) with supporting URLs; classification locks at resolution
• Per-check evidence signals prefill the alpha-1 checklist; the two judgment checks never get signals
• Account-optional reports persist as durable moderation cases with append-only events; owner actions apply restriction/takedown/correction/revocation with scoped public banners; browse, featured, profiles, and /r/ exclude moderated listings
• 38 tests including a real-corpus integration test blocking a renamed cross-owner copy; two independent review passes (initial findings B1/B2/H1/M1 all fixed and re-verified)

Still open on this issue:

• Private reporter contact verification (double-opt-in email) \u2014 cases persist contact but do not yet verify it
• Full E2E of submit \u2192 match \u2192 curator comparison \u2192 decision and report \u2192 remediation through the UI
• Unit tests for direct-API bypass of holds specifically (auth guards reviewed and verified manually)
• Side-by-side source diff view for curators (current UI shows matched files, regions, and scores)
• Rate limiting on the account-optional report endpoint

[jal-co]

Reporter-contact verification, report throttling, and curator diff clarity shipped in #84 and are deployed as Worker 08525446-d21a-4c8e-bb6c-b0d724a0ab6a.

Evidence:

• Case-specific 24-hour contact token; only SHA-256 hash stored
• GET is scanner-safe and non-mutating; intentional form POST is required
• One PostgreSQL CTE atomically confirms, clears token fields, and appends reporter_contact_verified
• Existing reports remain valid/unconfirmed through nullable migration columns
• External webhook contains no reporter email or free-form evidence; email logs contain no dynamic subjects, recipients, provider bodies, or bearer URLs
• Cloudflare native limiter is bound at 5 reports / 60 seconds per signed-in user or client IP and fails closed if missing in production
• Real production server-function probe: initial valid quota responses, then 20/20 follow-up requests rejected as rate-limited; the nonexistent probe ref created no cases
• Real HTTPS confirmation probe: GET 200 + form + no mutation; POST 200 + confirmed state + token cleared + exactly one audit event; temporary case deleted
• PostgreSQL integration tests passed non-skipped for success, replay, expiry, clearing, and event insertion
• Curator UI now labels percentages as normalized token similarity and the expandable view as a raw local source diff, with a historical-source-unavailable Storybook state
• CI and DCO green; final security review found no blocker/high issues

The broader submit → match → decision → remediation browser E2E and direct-server authorization contracts remain tracked by the existing unchecked acceptance items; they are not being represented as complete here.