Skip to content

Repository Handbook

This handbook explains the logic of one bounded proteomics product. It exists for the questions that no single package can answer honestly on its own:

  • how benchmark assets become execution, review, recommendation, and lab consequence
  • which package owns each handoff in that chain
  • where the repository can defend strong wording today and where it still must narrow

The root discipline is restraint. This handbook should make the full product legible, then hand the reader to the true owner before repository prose starts pretending it owns package-local behavior.

flowchart TB
    root["repository handbook<br/>system split and cross-package logic"]
    foundation["foundation<br/>shared meaning"]
    core["core<br/>scientific contracts and benchmark law"]
    knowledge["knowledge<br/>evidence state"]
    intelligence["intelligence<br/>judgment pressure"]
    lab["lab<br/>assay burden and refusal"]
    runtime["runtime<br/>execution proof"]
    maintain["maintainer handbook<br/>repository health"]

    root --> foundation
    root --> core
    root --> knowledge
    root --> intelligence
    root --> lab
    root --> runtime
    root --> maintain

Why This Handbook Matters More Now

Older repository docs could make bijux-proteomics look like package governance plus utilities. That is no longer honest. The repository now has a real scientific and operational chain to explain: public benchmark packets, runtime rerun proof, explicit grounding pressure, measurable recommendation challenge, and downstream assay consequence.

Strongest Repository Proof Surfaces

  • Open Flagship Release Candidate when the question is which workflow-family sentences currently survive public scrutiny.
  • Open Public Artifact Index when the question is which outsider-facing artifacts should be opened and why they coexist.
  • Open Release Readiness Matrix when the question is whether the current repository language outruns checked evidence.
  • Open Hostile Review Kit when the question is how to challenge the strongest current repository claim without maintainer narration.

Shared Reader Routes

  • Open Product Overview when the question is still product-wide rather than repository-handbook specific.
  • Open Workflow Families when the reader already knows the question is family credibility rather than repository topology.
  • Open Maintenance when the question is already about safe change, release validation, or repository honesty.

Start Inside This Handbook

  • Open Product Architecture when the question is how benchmark, runtime, knowledge, intelligence, and lab consequence are meant to compose.
  • Open Cross-Package Ownership when the question is which package or handoff owns disputed behavior.
  • Open Decision Support when the question is which owner currently controls the strongest honest public sentence.
  • Open Repository Shape Rationale when the question is why the package split still exists and which part is compatibility versus product substance.
  • Open Operations when the question is how the repository validates, releases, and reviews work across package boundaries.

Questions This Handbook Should Settle

  • Why is one concern a package boundary while another is only a module?
  • Which package should own a disputed behavior or public claim?
  • Which repository proof surfaces are truly shared and which are only adjacent?
  • Which strong-sounding sentence should narrow because another owner surface still refuses it?

Reader Routes

Canonical Package Handbooks

Compatibility Handbook

Boundary Test

If the best proof lives mostly in one package source tree, one package test suite, or one package API contract, this handbook should hand the reader off instead of pretending repository prose owns that behavior.