Foundation

The foundation section explains why bijux-proteomics is split the way it is. It is the place to resolve boundary questions before they become code drift, docs drift, or review confusion.

The central question here is simple: why should this repository stay a package family instead of collapsing into a blur of shared code and mixed ownership. If that question is unresolved, the rest of the handbook will only restate the same confusion in smaller pieces.

flowchart TB
    question["cross-package question"]
    platform["platform overview"]
    package["package map"]
    ownership["ownership model"]
    rules["decision rules"]
    handoff["handoff to the true owner"]

    question --> platform
    platform --> package
    package --> ownership
    ownership --> rules
    rules --> handoff

This section should move a reader from system-level confusion to a package-level owner without making them guess which page settles what. If the foundation pages cannot do that, the rest of the handbook only spreads the confusion into smaller fragments.

Why This Section Matters

• it explains why the split is a quality decision, not only a packaging choice
• it gives reviewers a language for stopping ownership drift early
• it helps the reader see the family as a designed system instead of a pile of sibling packages

Start With

• Open Platform Overview for the shortest explanation of the full package chain.
• Open Package Map when the question is which package should own the work.
• Open Ownership Model when a change crosses root and package boundaries.
• Open Decision Rules when a reviewer needs a hard yes-or-no gate.

Section Pages

• Platform Overview
• Repository Scope
• Workspace Layout
• Package Map
• Ownership Model
• Domain Language
• Documentation System
• Change Principles
• Decision Rules

What This Section Settles

• why one concern becomes a package boundary while another stays local
• how package seams protect meaning, reviewability, and change control
• when a reader should stop using repository-level theory and move to a package handbook

First Proof Check

• packages/ for the actual ownership seams
• docs/ for the handbook split mirroring those seams
• root process surfaces such as Makefile, makes/, and apis/ when a claim truly sits above one package

Design Pressure

The easy failure is to keep the root foundation section descriptive but not decisive, which leaves readers with theory and no reliable route to the real owner.

Boundary

If the answer depends mostly on one package's source tree, tests, or public contracts, the root foundation section should hand the reader off instead of stretching repository prose to cover package-local behavior.