You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Priority (absolute — consult this whenever a design decision is unclear; there should be no ambiguity once you check this)
Viewer compatibility — never break the existing viewer application (frontend UI in packages/@nitpicker/viewer/web/ and its API contract). Before shipping any endpoint/response-shape change, verify actual frontend consumers exist (check web/api/ and web/routes/, not just the backend src/) and update them in the same change.
Read performance — reads must always be fast, with no exceptions. All read-model construction happens at crawl completion or via the explicit nitpicker viewer-build command — never inline during a read-only open. Any on-open/opportunistic building that can block or slow down a read is a violation of this priority and must be removed wherever it exists (see Remove on-open opportunistic read model build (corrects #112) #177).
Archive DB storage — minimize the additional storage the read model adds to an archive.
These three are ranked in this order and are non-negotiable. No half-measures: pursue maximum read performance without compromise. Research prior art and existing techniques before implementing. Benchmark with real measurements (including real large archives, not just synthetic data) rather than assumptions. Implementation effort or time is never an acceptable reason to settle for a suboptimal design.
AS IS
The viewer can be slow on large archives because several endpoints still depend on request-time aggregation, broad scans, wide joins, redirect resolution, graph work, or JSON parsing. Existing archive data must not be treated as disposable, and customer/site/local archive details must not be recorded in public issues, comments, commits, benchmark logs, or test fixtures.
TO BE
Build a viewer read model strategy for large archives with hundreds of thousands of content records. Start with cache/sidecar read models for PDCA and benchmarking, then promote stable read models to persistent tables built after crawl completion.
The implementation must follow these design documents:
docs/viewer-db-redesign-plan.md
docs/viewer-sql-query-plan.md
docs/viewer-implementation-plan.md
Branch Policy
Integration branch: feature/impl-new-db.
Sub-issue implementation branches should branch from feature/impl-new-db, not from dev.
Sub-issue PRs should target feature/impl-new-db unless the maintainer explicitly decides otherwise.
Do not open endpoint migration PRs directly against dev while this project is still in PDCA.
Must
Keep source archive data recoverable and do not discard observed facts for size reduction.
Prefer SQL/read-model solutions before Node.js, Hono, React, JSON-file, or process-cache optimizations.
Keep viewer GET paths away from huge source-table scans.
Use limit-before-join patterns for URL/text/header joins.
Use keyset cursor pagination for virtual scrolling.
Use page anchors only for explicit page-number jumps.
Precompute totals, counts, graph facts, duplicate groups, summaries, and diagnostics during read model build.
Record benchmark methodology without customer/site names, real local file paths, or concrete archive identifiers.
Keep stub-mode safety: viewer must not mutate a live or interrupted crawl tmpDir.
Verify frontend (packages/@nitpicker/viewer/web/) consumers before assuming an endpoint is backend-only.
Don't
Do not write customer names, site names, real archive file names, or local filesystem paths.
Do not introduce large OFFSET based pagination for virtual scrolling.
Do not add request-time GROUP BY, connected-component computation, duplicate detection, redirect-chain resolution, or broad JSON parsing to viewer GET paths.
Do not make frontend or Hono caching the primary solution.
Do not make persistent schema decisions before cache/sidecar read model benchmarks validate them.
Priority (absolute — consult this whenever a design decision is unclear; there should be no ambiguity once you check this)
packages/@nitpicker/viewer/web/and its API contract). Before shipping any endpoint/response-shape change, verify actual frontend consumers exist (checkweb/api/andweb/routes/, not just the backendsrc/) and update them in the same change.nitpicker viewer-buildcommand — never inline during a read-only open. Any on-open/opportunistic building that can block or slow down a read is a violation of this priority and must be removed wherever it exists (see Remove on-open opportunistic read model build (corrects #112) #177).These three are ranked in this order and are non-negotiable. No half-measures: pursue maximum read performance without compromise. Research prior art and existing techniques before implementing. Benchmark with real measurements (including real large archives, not just synthetic data) rather than assumptions. Implementation effort or time is never an acceptable reason to settle for a suboptimal design.
AS IS
The viewer can be slow on large archives because several endpoints still depend on request-time aggregation, broad scans, wide joins, redirect resolution, graph work, or JSON parsing. Existing archive data must not be treated as disposable, and customer/site/local archive details must not be recorded in public issues, comments, commits, benchmark logs, or test fixtures.
TO BE
Build a viewer read model strategy for large archives with hundreds of thousands of content records. Start with cache/sidecar read models for PDCA and benchmarking, then promote stable read models to persistent tables built after crawl completion.
The implementation must follow these design documents:
docs/viewer-db-redesign-plan.mddocs/viewer-sql-query-plan.mddocs/viewer-implementation-plan.mdBranch Policy
feature/impl-new-db.feature/impl-new-db, not fromdev.feature/impl-new-dbunless the maintainer explicitly decides otherwise.feature/impl-new-dbis the staging branch for the Viewer DB read model redesign for large archives #103 project and will be merged todevonly after the read model plan is coherent and validated.devwhile this project is still in PDCA.Must
packages/@nitpicker/viewer/web/) consumers before assuming an endpoint is backend-only.Don't
OFFSETbased pagination for virtual scrolling.GROUP BY, connected-component computation, duplicate detection, redirect-chain resolution, or broad JSON parsing to viewer GET paths.Recommended Execution Order
/api/pagestoviewer_pageswith cursor pagination/api/pageson large archives/api/summarytoviewer_summary/api/error-kindsto viewer error-kind tablesviewer_anchor_factsviewer_page_statsviewer_imagesviewer_header_checksanalysis_violationsDependency Rules
Sub-issues
/api/pagestoviewer_pageswith cursor pagination/api/pageson large archives/api/summarytoviewer_summary/api/error-kindsto viewer error-kind tablesviewer_page_statsviewer_imagesviewer_anchor_factsviewer_header_checksanalysis_violationsAcceptance