@appsforgood/next-supabase-kit 0.3.0 → 0.4.0

package/research/summaries/design-critique-patterns.md

@@ -1,34 +0,0 @@
-# Reference-Led Design Critique Patterns
-
-Generated from a follow-up design-quality review after the kit already had content-first design, design adapters, and visual QA.
-
-## Why This Pass Was Needed
-
-The existing frontend guidance required brand/content intake, creative-direction options, design tokens, component states, screenshot review, and visual QA. That reduced generic AI-site defaults, but it still allowed a weak design to pass if it had enough checklist artifacts. A best-practice frontend setup also needs a critique loop that compares the work to relevant references, names anti-references, and records why the result is distinct for the product.
-
-## Focused Sources Reviewed
-
-- `shadcn-ui/ui`: registry-oriented component distribution and reusable UI skill guidance.
-- `primer/design` and Primer accessibility guidance: design-system guidelines, inclusive design, product-context review, and reusable pattern discipline.
-- `radix-ui/primitives`: accessible low-level primitives that separate behavior foundations from project-specific styling.
-- Carbon Design System guidance: accessibility status, component guidance, and standards-backed review expectations.
-- Storybook documentation: component state, interaction, accessibility, and visual testing workflows.
-
-## Repeated Patterns To Adopt
-
-- Separate reusable primitives from product-specific visual direction.
-- Use references to learn hierarchy, density, state treatment, and interaction patterns without copying source designs.
-- Record anti-references so agents know which category tropes and AI-generated defaults to avoid.
-- Treat accessibility and component-state behavior as foundations, not as visual differentiation by themselves.
-- Use screenshots, stories, or visual tests to make critique evidence reviewable after implementation.
-- Require a written verdict before accepting significant UI work.
-
-## Promoted Updates
-
-- Add Reference-Led Design Critique skill.
-- Add design-critique gate prompt and checklist.
-- Add reference set, anti-reference, source-safety, distinctiveness, and critique verdict fields to `DESIGN.md`.
-- Wire the Frontend Design Lead and frontend-change workflow to require reference-set evidence and a design critique verdict.
-- Add audit warnings when `DESIGN.md` lacks the critique gate.
-
-Do not copy third-party source code, design files, protected visual identity, brand marks, or proprietary copy from reviewed repositories. Adopt generalized practices only.

package/research/summaries/docs-and-agent-patterns.md

@@ -1,64 +0,0 @@
-# Docs And Agent Patterns
-
-Generated from 31 relevant repository findings.
-
-## Focus Areas
-- documentation
-- agentReadiness
-
-## Aggregate Evidence
-- Average normalized focus score: 0.42
-- Repositories considered: 31
-
-## Strongest Repositories For This Topic
-- sno-ai/mda (testing-docs-agents) - focus score 9, total 19/45
-- thedaviddias/souls-directory (testing-docs-agents) - focus score 8, total 29/45
-- vercel/next.js (official-nextjs) - focus score 7, total 30/45
-- vercel/ai (official-nextjs) - focus score 7, total 29/45
-- microsoft/skills (testing-docs-agents) - focus score 7, total 26/45
-- Piebald-AI/tweakcc (testing-docs-agents) - focus score 7, total 20/45
-- vercel/next-forge (official-nextjs) - focus score 6, total 23/45
-- wasp-lang/open-saas (testing-docs-agents) - focus score 6, total 21/45
-- AndreaPontrandolfo/sheriff (testing-docs-agents) - focus score 6, total 21/45
-- MrLesk/Backlog.md (testing-docs-agents) - focus score 6, total 20/45
-- brocoders/extensive-react-boilerplate (testing-docs-agents) - focus score 6, total 19/45
-- vercel/examples (official-nextjs) - focus score 5, total 26/45
-
-## Repeated Strengths
-- Test setup includes meaningful automated and browser-level coverage. (12)
-- Documentation is strong enough for external contributors or agents to onboard. (9)
-- Frontend implementation shows reusable components, states, and design-system signals. (9)
-- Security posture is explicit through docs, validation, CI, or review tooling. (6)
-
-## Repeated Gaps
-- Supabase RLS/Auth practices are not clearly discoverable. (31)
-- Accessibility signals are weak or absent. (23)
-- Agent handoff and AI-workflow instructions are not mature. (20)
-- Security expectations are implicit or incomplete. (19)
-
-## Source Findings
-- research/findings/sno-ai__mda.md
-- research/findings/thedaviddias__souls-directory.md
-- research/findings/Piebald-AI__tweakcc.md
-- research/findings/microsoft__skills.md
-- research/findings/vercel__ai.md
-- research/findings/vercel__next.js.md
-- research/findings/AndreaPontrandolfo__sheriff.md
-- research/findings/MrLesk__Backlog.md.md
-- research/findings/brocoders__extensive-react-boilerplate.md
-- research/findings/vercel__next-forge.md
-- research/findings/wasp-lang__open-saas.md
-- research/findings/google-labs-code__design.md.md
-- research/findings/ixartz__Next-js-Boilerplate.md
-- research/findings/vercel__examples.md
-- research/findings/vercel__next-devtools-mcp.md
-- research/findings/agentsmd__agents.md.md
-- research/findings/antiwork__shortest.md
-- research/findings/zero-one-group__monorepo.md
-- research/findings/RichardHruby__login-machine.md
-- research/findings/kaje94__menufic.md
-- research/findings/vercel__chatbot.md
-- research/findings/vercel__nextjs-postgres-nextauth-tailwindcss-template.md
-- research/findings/vercel__swr.md
-- research/findings/connectrpc__examples-es.md
-- research/findings/vercel__kirimase.md

package/research/summaries/dogfood-adoption-patterns.md

@@ -1,33 +0,0 @@
-# Dogfood And Adoption Evidence Patterns
-
-Generated from a focused follow-up review after current read-only dogfood audits showed that older installs fail the hardened setup standard.
-
-## Why This Pass Was Needed
-
-The kit already had broad 100-repo research, public release gates, and two earlier dogfood installs. Those dogfood notes were stale after later hardening added schema-backed council routing, assistant adapters, upgrade lifecycle, maturity gates, visual QA, and reference-led design critique.
-
-A public best-practice repo needs adoption evidence that stays current as standards change. Dogfood should not only prove that an install once worked; it should also prove that the audit catches drift when the kit improves.
-
-## Focused Sources Reviewed
-
-- GitHub community profile guidance for public repositories: community health files such as README, license, conduct, and contributing files are treated as visible project-health signals.
-- npm Trusted Publishing guidance: publish identity should avoid long-lived tokens, use workflow-bound OIDC, and produce provenance for public packages when conditions are met.
-- npm provenance guidance: publish workflows should support provenance and public access, and consumers can verify registry signatures and attestations.
-- Storybook testing guidance: stories can become reusable accessibility, interaction, visual, and end-to-end testing inputs.
-
-## Repeated Patterns To Adopt
-
-- Keep a public-safe dogfood summary separate from detailed local-path evidence.
-- Treat stale dogfood as a signal, not a failure to hide.
-- Record whether audits were read-only or changed downstream files.
-- Capture pass/warn/fail counts and readiness level for each adoption pass.
-- Promote repeated downstream gaps into installed assets, audit checks, tests, release gates, or decisions.
-- Keep post-publish `npx` verification separate from local package smoke.
-
-## Promoted Updates
-
-- Add `DOGFOOD.md` as a public-safe package asset.
-- Update detailed `dogfood/*` notes with current read-only audit results.
-- Add public-readiness tests that require dogfood evidence while preventing local project paths from leaking into the package.
-
-Do not publish local project paths, private project details, or screenshots without review. Public dogfood summaries should use project archetypes and generalized findings.

package/research/summaries/frontend-design-patterns.md

@@ -1,64 +0,0 @@
-# Frontend Design Patterns
-
-Generated from 41 relevant repository findings.
-
-## Focus Areas
-- frontendDesign
-- accessibility
-
-## Aggregate Evidence
-- Average normalized focus score: 0.57
-- Repositories considered: 41
-
-## Strongest Repositories For This Topic
-- triggerdotdev/trigger.dev (production-saas) - focus score 7, total 32/45
-- formbricks/formbricks (production-saas) - focus score 7, total 29/45
-- shadcn-ui/ui (design-systems) - focus score 7, total 27/45
-- dubinc/dub (production-saas) - focus score 7, total 27/45
-- documenso/documenso (production-saas) - focus score 7, total 27/45
-- boxyhq/saas-starter-kit (production-saas) - focus score 7, total 25/45
-- nextify-limited/saasfly (production-saas) - focus score 7, total 20/45
-- Blazity/next-saas-starter (production-saas) - focus score 7, total 16/45
-- michaelshimeles/nextjs-starter-kit (production-saas) - focus score 7, total 15/45
-- mui/base-ui (design-systems) - focus score 6, total 28/45
-- carbon-design-system/carbon (design-systems) - focus score 6, total 27/45
-- chakra-ui/zag (design-systems) - focus score 6, total 26/45
-
-## Repeated Strengths
-- Documentation is strong enough for external contributors or agents to onboard. (15)
-- Frontend implementation shows reusable components, states, and design-system signals. (14)
-- Security posture is explicit through docs, validation, CI, or review tooling. (11)
-- Test setup includes meaningful automated and browser-level coverage. (9)
-
-## Repeated Gaps
-- Supabase RLS/Auth practices are not clearly discoverable. (41)
-- Agent handoff and AI-workflow instructions are not mature. (26)
-- Security expectations are implicit or incomplete. (22)
-- Accessibility signals are weak or absent. (17)
-
-## Source Findings
-- research/findings/Blazity__next-saas-starter.md
-- research/findings/boxyhq__saas-starter-kit.md
-- research/findings/documenso__documenso.md
-- research/findings/dubinc__dub.md
-- research/findings/formbricks__formbricks.md
-- research/findings/michaelshimeles__nextjs-starter-kit.md
-- research/findings/nextify-limited__saasfly.md
-- research/findings/shadcn-ui__ui.md
-- research/findings/triggerdotdev__trigger.dev.md
-- research/findings/Davronov-Alimardon__canva-clone.md
-- research/findings/DouyinFE__semi-design.md
-- research/findings/LubomirGeorgiev__cloudflare-workers-nextjs-saas-template.md
-- research/findings/async-labs__saas.md
-- research/findings/carbon-design-system__carbon.md
-- research/findings/chakra-ui__ark.md
-- research/findings/chakra-ui__zag.md
-- research/findings/cloudscape-design__components.md
-- research/findings/cosscom__coss.md
-- research/findings/cossistantcom__cossistant.md
-- research/findings/dodopayments__billingsdk.md
-- research/findings/keyshade-xyz__keyshade.md
-- research/findings/mui__base-ui.md
-- research/findings/nextacular__nextacular.md
-- research/findings/palantir__blueprint.md
-- research/findings/primer__react.md

package/research/summaries/frontend-distinctiveness-benchmark-patterns.md

@@ -1,38 +0,0 @@
-# Frontend Distinctiveness Benchmark Patterns
-
-Generated after reviewing the frontend gap raised during public-readiness hardening: a broad repo scan can identify strong component and documentation patterns, but frontend quality still needs a product-specific acceptance benchmark.
-
-## Why This Pass Was Needed
-
-The 100-repo scan and focused follow-up reviews already promoted design tokens, component states, accessibility, visual QA, content-first design, reference-led critique, and a product-quality scorecard. That is better than a normal prompt bundle, but it still left one practical failure mode: a design could satisfy many checklist items while still feeling interchangeable with other AI-generated sites in the same category.
-
-The fix is to require proof that the first screen, content, references, assets, states, and screenshots are specific to the product before accepting significant frontend work.
-
-## Focused Sources Reviewed
-
-- Primer React and Primer design guidance: product-context components, accessibility foundations, and reviewable pattern discipline.
-- Shopify Polaris: product-specific admin patterns, content guidance, tokens, and stateful component guidance.
-- GOV.UK Design System and service/content guidance: user-need-first design, task language, accessibility, and trust.
-- Storybook documentation: component state review, interaction tests, accessibility checks, and visual testing evidence.
-- Radix UI Primitives: accessible behavior foundations separated from product-specific styling.
-- Carbon Design System and USWDS: standards-backed accessibility, state, and service-design expectations.
-
-## Repeated Patterns To Adopt
-
-- Components and tokens are foundations, not proof of product fit.
-- The first viewport should expose the real product object, task, workflow, content, or decision.
-- Product nouns, data shapes, actions, and edge cases should drive layout before styling.
-- References should become named lessons and anti-references, not copied layouts or visual signatures.
-- Asset provenance should be explicit so generated, licensed, placeholder, and real media are not blurred together.
-- State evidence and visual QA should be tied to the product workflow, not only to isolated component polish.
-
-## Promoted Updates
-
-- Add Frontend Distinctiveness Benchmark skill.
-- Add frontend-distinctiveness checklist and benchmark prompt.
-- Update `DESIGN.md` with first-screen proof, content fingerprint, reference benchmark, asset provenance, state proof, and visual QA proof fields.
-- Wire Frontend Design Lead and frontend-change workflow to require distinctiveness benchmark evidence.
-- Add audit warnings when `DESIGN.md` lacks the distinctiveness benchmark.
-- Add public-readiness tests for distinctiveness assets and routing.
-
-Do not copy third-party source code, design files, protected visual identity, brand marks, proprietary layouts, exact copy, or visual signatures from reviewed repositories. Adopt generalized practices only.

package/research/summaries/frontend-product-quality-rubric-patterns.md

@@ -1,37 +0,0 @@
-# Frontend Product Quality Rubric Patterns
-
-Generated from a focused follow-up review after the kit already had content-first design, reference-led critique, visual QA, and anti-generic UI guidance.
-
-## Why This Pass Was Needed
-
-The previous frontend hardening made generic AI-site output harder, but it still relied on qualitative review language. A best-practice setup needs a repeatable product-quality rubric so design agents, coding agents, and human reviewers can reject weak UI for the same reasons.
-
-## Focused Sources Reviewed
-
-- `primer/react` and Primer design guidance: accessible component foundations, product-context patterns, and reviewable design-system decisions.
-- GOV.UK Design System and service/content guidance: user-need-first service design, accessibility, and task-oriented content.
-- Storybook documentation: stateful component review, interaction tests, accessibility checks, and visual testing as review evidence.
-- Shopify Polaris: product-specific admin interface foundations, content guidance, tokens, and component guidance.
-- Radix UI Primitives: accessible, unstyled primitives that separate behavior foundations from product-specific visual direction.
-- Carbon Design System: accessibility status, component guidance, and design-system quality expectations.
-- USWDS: design principles that prioritize real user needs, accessibility, trust, and consistent interaction patterns.
-
-## Repeated Patterns To Adopt
-
-- Treat accessible primitives and components as the foundation, not the product's visual identity.
-- Score UI against real user task, content specificity, information architecture, visual identity, states, accessibility, and safe reference use.
-- Make first-screen specificity a hard gate: users should see the real product object, task, workflow, or content immediately.
-- Require source-safety review whenever references influence layout, imagery, copy, or visual style.
-- Keep desktop/mobile screenshots, state evidence, and visual QA tied to the scorecard verdict.
-- Reject work when polished styling hides missing content, fake data, or generic category tropes.
-
-## Promoted Updates
-
-- Add Frontend Product Quality Rubric skill.
-- Add frontend product-quality checklist and scorecard prompt.
-- Update `DESIGN.md` with a product-quality scorecard and acceptance thresholds.
-- Wire Frontend Design Lead and frontend-change workflow to require the scorecard.
-- Add audit warnings when the scorecard is missing from `DESIGN.md`.
-- Add public-readiness tests for rubric assets and routing.
-
-Do not copy third-party source code, design files, protected visual identity, brand marks, proprietary layouts, or exact copy from reviewed repositories. Adopt generalized practices only.

package/research/summaries/maturity-model-patterns.md

@@ -1,29 +0,0 @@
-# Maturity Model Patterns
-
-Generated from a focused follow-up pass after the 100-repo scan showed that popularity and broad research volume do not prove best-practice readiness.
-
-## Why This Pass Was Needed
-
-The initial scan identified repeated gaps in Supabase/Auth/RLS discoverability, AI-agent handoff maturity, accessibility evidence, and explicit security expectations. Follow-up review of public production, repository-health, supply-chain, and visual-testing guidance showed that mature projects make quality evidence durable across docs, automation, release, and review settings.
-
-## Generalized Practices
-
-- Use an explicit maturity model instead of treating any green build as best-practice readiness.
-- Separate baseline setup, strong team/agent delivery, and best-practice release evidence.
-- Require evidence for council routing, architecture decisions, security boundaries, Supabase/RLS, frontend quality, accessibility, testing, deployment, and repository health.
-- Treat research findings as inputs only; promote them into installed assets, audit checks, tests, release gates, or documented decisions before counting them as kit behavior.
-- Keep production-readiness expectations broad enough to cover framework behavior, data access, user experience, security, observability, and release integrity.
-- Keep repository operations visible through issue/PR templates, CODEOWNERS, dependency update automation, code scanning, dependency review, provenance expectations, support, conduct, and governance.
-
-## Promoted Updates
-
-- Added `templates/next-supabase/QUALITY_GATES.md`.
-- Added `QUALITY_GATES.md` to installed root docs and manifest hashing.
-- Added audit coverage for baseline, strong, best-practice, evidence, and multi-area maturity expectations.
-- Added tests that warn when the maturity model is hollowed out.
-- Added audit warnings when starter placeholders remain in evidence docs, so clean installation is not confused with completed project evidence.
-- Added a minimum-readiness CLI gate so downstream projects can enforce baseline or best-practice thresholds in CI.
-- Added an audit-report JSON Schema so downstream CI, dashboards, and repo-health tools can validate audit output shape.
-- Updated public docs and roadmap to make best-practice readiness evidence-based rather than research-volume-based.
-
-Do not copy source, policy wording, or brand systems from reviewed repositories or documentation. Adopt only generalized practices with clear rationale.

package/research/summaries/nextjs-patterns.md

@@ -1,65 +0,0 @@
-# Next.js Patterns
-
-Generated from 39 relevant repository findings.
-
-## Focus Areas
-- architecture
-- ciDeployment
-- documentation
-
-## Aggregate Evidence
-- Average normalized focus score: 0.39
-- Repositories considered: 39
-
-## Strongest Repositories For This Topic
-- vercel/next-forge (official-nextjs) - focus score 10, total 23/45
-- triggerdotdev/trigger.dev (production-saas) - focus score 9, total 32/45
-- keyshade-xyz/keyshade (production-saas) - focus score 9, total 25/45
-- cossistantcom/cossistant (production-saas) - focus score 9, total 24/45
-- vercel/chatbot (official-nextjs) - focus score 9, total 23/45
-- vercel/next.js (official-nextjs) - focus score 8, total 30/45
-- vercel/ai (official-nextjs) - focus score 8, total 29/45
-- formbricks/formbricks (production-saas) - focus score 8, total 29/45
-- boxyhq/saas-starter-kit (production-saas) - focus score 8, total 25/45
-- nextacular/nextacular (production-saas) - focus score 8, total 23/45
-- nextify-limited/saasfly (production-saas) - focus score 8, total 20/45
-- dubinc/dub (production-saas) - focus score 7, total 27/45
-
-## Repeated Strengths
-- Frontend implementation shows reusable components, states, and design-system signals. (20)
-- Security posture is explicit through docs, validation, CI, or review tooling. (12)
-- Test setup includes meaningful automated and browser-level coverage. (11)
-- Documentation is strong enough for external contributors or agents to onboard. (8)
-
-## Repeated Gaps
-- Supabase RLS/Auth practices are not clearly discoverable. (39)
-- Agent handoff and AI-workflow instructions are not mature. (30)
-- Accessibility signals are weak or absent. (26)
-- Security expectations are implicit or incomplete. (23)
-
-## Source Findings
-- research/findings/vercel__next-forge.md
-- research/findings/cossistantcom__cossistant.md
-- research/findings/keyshade-xyz__keyshade.md
-- research/findings/triggerdotdev__trigger.dev.md
-- research/findings/vercel__chatbot.md
-- research/findings/boxyhq__saas-starter-kit.md
-- research/findings/formbricks__formbricks.md
-- research/findings/nextacular__nextacular.md
-- research/findings/nextify-limited__saasfly.md
-- research/findings/vercel__ai.md
-- research/findings/vercel__next.js.md
-- research/findings/documenso__documenso.md
-- research/findings/dodopayments__billingsdk.md
-- research/findings/dubinc__dub.md
-- research/findings/vercel__examples.md
-- research/findings/zenstackhq__zenstack.md
-- research/findings/Blazity__next-saas-starter.md
-- research/findings/cruip__open-react-template.md
-- research/findings/ixartz__SaaS-Boilerplate.md
-- research/findings/michaelshimeles__nextjs-starter-kit.md
-- research/findings/nextjs__saas-starter.md
-- research/findings/revokslab__ShipFree.md
-- research/findings/vercel__nextjs-postgres-nextauth-tailwindcss-template.md
-- research/findings/vercel__platforms.md
-- research/findings/vercel__swr.md

package/research/summaries/repo-health-patterns.md

@@ -1,41 +0,0 @@
-# Repo Health Patterns
-
-Generated from a focused public OSS repository-health pass.
-
-## Focused Sources Reviewed
-
-- GitHub issue and pull request template documentation: issue forms belong in `.github/ISSUE_TEMPLATE`, and PR templates can live in `.github/pull_request_template.md`.
-- GitHub CODEOWNERS documentation: `.github/CODEOWNERS` is the first location GitHub checks and supports automatic owner review requests.
-- GitHub Dependabot documentation: `.github/dependabot.yml` configures npm and GitHub Actions update PRs.
-- GitHub CodeQL documentation: JavaScript and TypeScript projects can run CodeQL through GitHub Actions.
-- GitHub branch protection and environment documentation: required status checks, required reviews, environment reviewers, and deployment branch restrictions are repository settings that must be reviewed outside git.
-- GitHub private vulnerability reporting documentation: public repositories can expose private vulnerability reporting through Security Advisories.
-- High-signal OSS repos commonly expose structured contribution, security, release, and review workflows rather than relying on maintainer memory.
-
-## Repeated Patterns To Adopt
-
-- Use issue forms to collect enough evidence for maintainers to reproduce bugs and evaluate reusable feature proposals.
-- Use a PR template that ties changes to scope, tests, docs, security, and release impact.
-- Use CODEOWNERS for review ownership of source, templates, schemas, and workflows.
-- Use Dependabot for npm and GitHub Actions updates.
-- Use CodeQL or equivalent code scanning for JavaScript/TypeScript repositories.
-- Publish support, conduct, and governance docs so contributor expectations are explicit.
-- Keep required labels and PR labeler rules in the repo.
-- Document branch protection, environment protection, security advisory, private vulnerability reporting, and label setup because those settings are not fully represented by package files.
-
-## Promoted Updates
-
-- Added `.github/ISSUE_TEMPLATE/config.yml`.
-- Added bug, feature-request, and research-promotion issue forms.
-- Added `.github/pull_request_template.md`.
-- Added `.github/CODEOWNERS`.
-- Added `.github/dependabot.yml`.
-- Added `.github/labels.yml`.
-- Added `.github/labeler.yml` and PR labeler workflow.
-- Added `.github/workflows/codeql.yml`.
-- Added `CODE_OF_CONDUCT.md`, `SUPPORT.md`, and `GOVERNANCE.md`.
-- Added `REPOSITORY_SETTINGS.md`.
-- Added repo-health public-readiness tests.
-- Added repo-health scoring and discovery signals to the research scanner.
-
-Research and repo examples are used only for generalized practices. Do not copy third-party source or project-specific policy wording.

package/research/summaries/scan-overview.md

@@ -1,46 +0,0 @@
-# Research Scan Overview
-
-Generated from 100 parsed repository findings.
-
-## Category Coverage
-- production-saas: 24
-- design-systems: 17
-- testing-docs-agents: 16
-- official-nextjs: 15
-- supabase-nextjs: 15
-- security-quality: 13
-
-## Highest Total Scores
-- supabase/supabase (supabase-nextjs) - 35/45
-- trycompai/comp (security-quality) - 33/45
-- triggerdotdev/trigger.dev (production-saas) - 32/45
-- onlook-dev/onlook (supabase-nextjs) - 31/45
-- thedaviddias/llms-txt-hub (supabase-nextjs) - 31/45
-- vercel/next.js (official-nextjs) - 30/45
-- better-auth/better-auth (security-quality) - 30/45
-- vercel/ai (official-nextjs) - 29/45
-- formbricks/formbricks (production-saas) - 29/45
-- thedaviddias/souls-directory (testing-docs-agents) - 29/45
-- mui/base-ui (design-systems) - 28/45
-- shadcn-ui/ui (design-systems) - 27/45
-- dubinc/dub (production-saas) - 27/45
-- documenso/documenso (production-saas) - 27/45
-- carbon-design-system/carbon (design-systems) - 27/45
-- unkeyed/unkey (security-quality) - 27/45
-- nextauthjs/next-auth (security-quality) - 26/45
-- midday-ai/midday (supabase-nextjs) - 26/45
-- chakra-ui/zag (design-systems) - 26/45
-- vercel/examples (official-nextjs) - 26/45
-
-## Most Repeated Strengths
-- Frontend implementation shows reusable components, states, and design-system signals. (42)
-- Documentation is strong enough for external contributors or agents to onboard. (36)
-- Security posture is explicit through docs, validation, CI, or review tooling. (29)
-- Test setup includes meaningful automated and browser-level coverage. (27)
-- Supabase authorization appears to be handled close to the data boundary. (6)
-
-## Most Repeated Gaps
-- Supabase RLS/Auth practices are not clearly discoverable. (88)
-- Agent handoff and AI-workflow instructions are not mature. (66)
-- Accessibility signals are weak or absent. (57)
-- Security expectations are implicit or incomplete. (54)

package/research/summaries/security-patterns.md

@@ -1,64 +0,0 @@
-# Security Patterns
-
-Generated from 52 relevant repository findings.
-
-## Focus Areas
-- security
-
-## Aggregate Evidence
-- Average normalized focus score: 0.53
-- Repositories considered: 52
-
-## Strongest Repositories For This Topic
-- trycompai/comp (security-quality) - focus score 5, total 33/45
-- onlook-dev/onlook (supabase-nextjs) - focus score 5, total 31/45
-- thedaviddias/llms-txt-hub (supabase-nextjs) - focus score 5, total 31/45
-- better-auth/better-auth (security-quality) - focus score 5, total 30/45
-- formbricks/formbricks (production-saas) - focus score 5, total 29/45
-- dubinc/dub (production-saas) - focus score 5, total 27/45
-- midday-ai/midday (supabase-nextjs) - focus score 5, total 26/45
-- keyshade-xyz/keyshade (production-saas) - focus score 5, total 25/45
-- cossistantcom/cossistant (production-saas) - focus score 5, total 24/45
-- supabase/supabase (supabase-nextjs) - focus score 4, total 35/45
-- triggerdotdev/trigger.dev (production-saas) - focus score 4, total 32/45
-- documenso/documenso (production-saas) - focus score 4, total 27/45
-
-## Repeated Strengths
-- Frontend implementation shows reusable components, states, and design-system signals. (32)
-- Security posture is explicit through docs, validation, CI, or review tooling. (20)
-- Documentation is strong enough for external contributors or agents to onboard. (18)
-- Test setup includes meaningful automated and browser-level coverage. (12)
-- Supabase authorization appears to be handled close to the data boundary. (6)
-
-## Repeated Gaps
-- Supabase RLS/Auth practices are not clearly discoverable. (40)
-- Agent handoff and AI-workflow instructions are not mature. (38)
-- Accessibility signals are weak or absent. (31)
-- Security expectations are implicit or incomplete. (25)
-
-## Source Findings
-- research/findings/better-auth__better-auth.md
-- research/findings/cossistantcom__cossistant.md
-- research/findings/dubinc__dub.md
-- research/findings/formbricks__formbricks.md
-- research/findings/keyshade-xyz__keyshade.md
-- research/findings/midday-ai__midday.md
-- research/findings/onlook-dev__onlook.md
-- research/findings/thedaviddias__llms-txt-hub.md
-- research/findings/trycompai__comp.md
-- research/findings/403errors__repomind.md
-- research/findings/arcjet__arcjet-js.md
-- research/findings/aspen-cloud__triplit.md
-- research/findings/documenso__documenso.md
-- research/findings/jakejarvis__domainstack.io.md
-- research/findings/nextacular__nextacular.md
-- research/findings/nextauthjs__next-auth.md
-- research/findings/supabase__supabase.md
-- research/findings/triggerdotdev__trigger.dev.md
-- research/findings/unkeyed__unkey.md
-- research/findings/zenstackhq__zenstack.md
-- research/findings/LubomirGeorgiev__cloudflare-workers-nextjs-saas-template.md
-- research/findings/boxyhq__saas-starter-kit.md
-- research/findings/dodopayments__billingsdk.md
-- research/findings/ibelick__zola.md
-- research/findings/nextify-limited__saasfly.md

package/research/summaries/supabase-rls-patterns.md

@@ -1,54 +0,0 @@
-# Supabase RLS Patterns
-
-Generated from 15 relevant repository findings.
-
-## Focus Areas
-- supabaseAuthRls
-
-## Aggregate Evidence
-- Average normalized focus score: 0.65
-- Repositories considered: 15
-
-## Strongest Repositories For This Topic
-- supabase/supabase (supabase-nextjs) - focus score 5, total 35/45
-- srizzon/git-city (supabase-nextjs) - focus score 5, total 23/45
-- firecrawl/open-scouts (supabase-nextjs) - focus score 5, total 23/45
-- devtodollars/mvp-boilerplate (supabase-nextjs) - focus score 5, total 20/45
-- supabase-community/nextjs-openai-doc-search (supabase-nextjs) - focus score 5, total 18/45
-- onlook-dev/onlook (supabase-nextjs) - focus score 3, total 31/45
-- ibelick/zola (supabase-nextjs) - focus score 3, total 21/45
-- gokulkrishh/expense.fyi (supabase-nextjs) - focus score 3, total 19/45
-- ShenSeanChen/launch-mvp-stripe-nextjs-supabase (supabase-nextjs) - focus score 3, total 18/45
-- braydoncoyer/braydoncoyer.dev (supabase-nextjs) - focus score 3, total 16/45
-- midday-ai/midday (supabase-nextjs) - focus score 2, total 26/45
-- aspen-cloud/triplit (supabase-nextjs) - focus score 2, total 25/45
-
-## Repeated Strengths
-- Frontend implementation shows reusable components, states, and design-system signals. (10)
-- Documentation is strong enough for external contributors or agents to onboard. (7)
-- Security posture is explicit through docs, validation, CI, or review tooling. (5)
-- Supabase authorization appears to be handled close to the data boundary. (5)
-- Test setup includes meaningful automated and browser-level coverage. (3)
-
-## Repeated Gaps
-- Agent handoff and AI-workflow instructions are not mature. (11)
-- Accessibility signals are weak or absent. (8)
-- Security expectations are implicit or incomplete. (8)
-- Supabase RLS/Auth practices are not clearly discoverable. (5)
-
-## Source Findings
-- research/findings/devtodollars__mvp-boilerplate.md
-- research/findings/firecrawl__open-scouts.md
-- research/findings/srizzon__git-city.md
-- research/findings/supabase-community__nextjs-openai-doc-search.md
-- research/findings/supabase__supabase.md
-- research/findings/ShenSeanChen__launch-mvp-stripe-nextjs-supabase.md
-- research/findings/braydoncoyer__braydoncoyer.dev.md
-- research/findings/gokulkrishh__expense.fyi.md
-- research/findings/ibelick__zola.md
-- research/findings/onlook-dev__onlook.md
-- research/findings/aspen-cloud__triplit.md
-- research/findings/imbhargav5__nextbase-nextjs-supabase-starter.md
-- research/findings/midday-ai__midday.md
-- research/findings/supabase__auth-helpers.md
-- research/findings/thedaviddias__llms-txt-hub.md

package/research/summaries/supply-chain-patterns.md

@@ -1,38 +0,0 @@
-# Supply Chain Patterns
-
-Generated from a focused public package supply-chain pass.
-
-## Focused Sources Reviewed
-
-- npm Trusted Publishing documentation: GitHub Actions OIDC can publish without long-lived automation tokens, and public trusted publishes generate provenance attestations automatically.
-- npm provenance documentation: provenance links package artifacts to source and build instructions so consumers can verify origin.
-- GitHub Dependency Review action documentation: pull requests that change dependencies can be checked for vulnerabilities and policy issues.
-- OpenSSF Scorecard action documentation: repository security posture can be measured and published as code-scanning evidence.
-- GitHub artifact attestation documentation: release evidence can bind an SBOM to a specific package artifact.
-- GitHub workflow security patterns: least-privilege permissions, explicit concurrency, and non-persistent checkout credentials reduce accidental workflow risk.
-
-## Repeated Patterns To Adopt
-
-- Prefer OIDC Trusted Publishing over long-lived npm publish tokens.
-- Document provenance expectations in package release docs.
-- Add dependency review for pull requests that change dependency graphs.
-- Add Scorecard or equivalent repository security posture checks.
-- Keep CodeQL and dependency update automation active.
-- Generate an SBOM for release artifacts and attest it against the exact artifact being published.
-- Treat workflow edits as release-risk changes.
-- Validate manual publish paths so accidental non-main publishes are not accepted.
-
-## Promoted Updates
-
-- Added `SUPPLY_CHAIN.md`.
-- Added `.github/workflows/dependency-review.yml`.
-- Added `.github/workflows/scorecard.yml`.
-- Hardened workflow checkout with `persist-credentials: false`.
-- Added workflow concurrency.
-- Added manual publish ref validation for release workflow dispatches.
-- Added lockfile-derived CycloneDX SBOM validation.
-- Added release-workflow SBOM attestation for the exact npm tarball being published.
-- Added supply-chain scanner score and research category.
-- Added public-readiness tests for supply-chain files and release controls.
-
-Do not treat provenance as a complete guarantee of safety. Provenance proves origin and workflow context; maintainers still need dependency review, workflow review, branch/environment controls, and post-publish verification.