Briefing

Use this page as the reading contract for the portal. It defines what fq-compressor is trying to prove in public, how the site is organized, and which route is fastest for different readers.

Portal contract

• The site argues for fq-compressor as a systems design, not a standalone benchmark headline.
• Every durable public claim should resolve to architecture, methodology, or tracked repository artifacts.
• The reading order is shaped for advanced GitHub readers who want auditability first.

What this portal is not

• Not a README mirror
• Not a feature checklist detached from evidence
• Not a frontend-heavy showcase that hides the engineering substance

Default reading order

1. Read Algorithms to understand the compression thesis.
2. Read System Design to see where those ideas live in the codebase and archive format.
3. Read Performance to understand what the repository currently proves, and where the proof surface stops.
4. Read Operations if your question is practical: install, run, verify, contribute.
5. Read References if your question is bibliographic, comparative, or historical.

Reader intents

Reader	Start here	Then read	Main outcome
Staff-level reviewer	Algorithms	Performance	Judge whether the public story is technically credible
Contributor	System Design	Operations	Understand boundaries before editing
Operator	Operations	System Design	Run and verify archives without guessing format rules
Research reader	References	Algorithms	Place fq-compressor in the wider FASTQ compression landscape

Why this structure exists

fq-compressor is easier to trust when the documentation behaves like a technical dossier. The portal therefore keeps the top-level route shallow, the evidence claims explicit, and the supporting bibliography visible instead of burying it in a side note.

Reading tracks

Choose a route that matches your question, then stay in that lane.

1. 01

   Staff-level reviewer

   Evaluate the project thesis in one sitting

   Start with algorithms, then verify every public claim against the evidence contract.

   Entry

   Whitepaper -> Performance

   Outcome

   You can judge whether the public story outruns the repository.

   Open this track
2. 02

   Operators

   Move from install to verified archive handling

   Stay in operations when the immediate goal is to install, run, verify, or spot-check real outputs.

   Entry

   Operations -> System Design

   Outcome

   You can execute the tool without guessing hidden format rules.

   Open this track
3. 03

   Contributors

   Map the code before changing anything

   Read the system blueprint with contribution guidance open beside it so architectural boundaries stay visible during edits.

   Entry

   System Design -> Operations

   Outcome

   You know which modules own parsing, compression, format, and command glue.

   Open this track
4. 04

   Research readers

   Put the design choices back into external context

   Use the reference shelf for papers, comparator repositories, and closeout-mode evolution notes.

   Entry

   References -> Algorithms

   Outcome

   You can explain which upstream ideas fq-compressor keeps, adapts, or rejects.

   Open this track