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.

That question is more important now because the repository has grown far beyond lightweight governance and package bookkeeping. The current platform carries real sequence, chemistry, benchmark, execution, grounding, recommendation, and lab surfaces. If the foundation section does not explain how those surfaces fit together, the rest of the docs will understate the product.

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

What Changed Since v0.3.7

• the repository now has materially deeper scientific owner surfaces in core
• runtime now contributes public rerun and replay proof instead of only operator-facing command surfaces
• knowledge, intelligence, and lab now contribute a visible consequence chain rather than background explanation
• release trust now depends on public scrutiny routes, not only package-local handbooks

Start With

• Structure: open Product Architecture, Cross-Package Ownership, and Repository Shape Rationale when the question is why the package family exists and where ownership should land.
• Public language: open Product Overview, Workflow Families, and Decision Support when the question starts from external wording rather than internal package seams.
• Release truth: open Release Readiness Matrix, Release Narrowing Protocol, and Elite Readiness Scorecard when you need the shortest route from wording to proof burden.
• Public proof: open Flagship Release Candidate, What One Workflow Family Supports Today, Public Artifact Index, and Hostile Review Kit when the question is what an outsider can audit today without maintainer narration.
• Readiness blockers: open Why This Repository Is Not Ready Yet and What Would Make This Repository Ready when the question is what still forbids stronger release language.

Fastest Proof Route

• Start with Product Architecture to understand the end-to-end chain.
• Continue to Release Readiness Matrix to see which categories still block stronger language.
• Finish at Public Artifact Index and Hostile Review Kit to see what an outsider can actually open today.

Section Pages

• Product Architecture
• Platform Overview
• Repository Scope
• Workspace Layout
• Package Map
• Cross-Package Ownership
• Repository Shape Rationale
• Ownership Model
• Public Language Glossary
• Domain Language
• Documentation System
• Change Principles
• Decision Rules
• Release Readiness Matrix
• Release Narrowing Protocol
• Hostile Review Kit
• What One Workflow Family Supports Today
• Flagship Release Candidate
• Elite Readiness Scorecard
• Independent Rerun Dossiers
• External Review Kits
• Public Artifact Index
• Public Artifact Role Matrix
• Why This Repository Is Not Ready Yet
• What Would Make This Repository Ready

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.