Skip to content

Capability Map

The fastest way to understand bijux-proteomics-lab is to map capabilities to the code that carries them. This page should help a reader move from a package claim to a likely code area without pretending that module names alone are enough.

When this page is healthy, the package feels like a set of deliberate abilities, not a pile of implementation details.

Treat the foundation pages for bijux-proteomics-lab as the package's durable self-description. If the package still feels blurry after this section, the boundary story is not clear enough yet.

Visual Summary

flowchart LR
    page["Capability Map<br/>clarifies: own the right work | name the boundary | compare neighbors"]
    classDef page fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a,stroke-width:2px;
    classDef positive fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef caution fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    classDef anchor fill:#ede9fe,stroke:#7c3aed,color:#4c1d95;
    classDef action fill:#fef3c7,stroke:#d97706,color:#7c2d12;
    own1["replay and acceptability semantics"]
    own1 --> page
    own2["trace capture, runtime persistence, and execution-store behavior"]
    own2 --> page
    own3["flow execution authority"]
    own3 --> page
    limit1["repository tooling and release support"]
    page -.keeps outside.-> limit1
    limit2["agent composition policy"]
    page -.keeps outside.-> limit2
    limit3["ingest and index domain ownership"]
    page -.keeps outside.-> limit3
    anchor1["packages/bijux-proteomics-lab/tests"]
    page --> anchor1
    anchor2["packages/bijux-proteomics-lab"]
    page --> anchor2
    anchor3["packages/bijux-proteomics-lab/src/bijux_proteomics_lab"]
    page --> anchor3
    class page page;
    class own1,own2,own3 positive;
    class limit1,limit2,limit3 caution;
    class anchor1,anchor2,anchor3 anchor;

Capability Map

  • src/bijux_proteomics_lab/model for durable runtime models
  • src/bijux_proteomics_lab/runtime for execution engines and lifecycle logic
  • src/bijux_proteomics_lab/application for orchestration and replay coordination
  • src/bijux_proteomics_lab/verification for runtime-level validation support
  • src/bijux_proteomics_lab/interfaces for CLI surfaces and manifest loading
  • src/bijux_proteomics_lab/api for HTTP application surfaces

Produced Artifacts

  • execution store records
  • replay decision artifacts
  • non-determinism policy evaluations

Concrete Anchors

  • packages/bijux-proteomics-lab as the package root
  • packages/bijux-proteomics-lab/src/bijux_proteomics_lab as the import boundary
  • packages/bijux-proteomics-lab/tests as the package proof surface

Use This Page When

  • you need the package idea before the implementation detail
  • you are deciding whether work belongs here or in a neighboring package
  • you want the shortest honest explanation of what this package is for

Decision Rule

Use Capability Map to decide whether a change makes bijux-proteomics-lab easier or harder to defend as one distinct role in the overall system. If the work makes the package broader without making its role clearer, stop and re-check the boundary before treating the change as a local improvement.

What This Page Answers

  • what problem bijux-proteomics-lab is supposed to own on purpose
  • where the package boundary stops, even when nearby code looks tempting
  • which neighboring package seams deserve comparison before the boundary is changed

Reviewer Lens

  • compare the stated boundary with the modules, artifacts, and tests that are supposed to uphold it
  • check that out-of-scope behavior is not quietly re-entering through convenience paths
  • confirm that the package story still matches the real repository layout and neighboring package docs

Honesty Boundary

This page can explain the intended boundary of bijux-proteomics-lab, but it cannot prove that boundary by itself. The real proof still lives in the code, tests, and neighboring package seams that either support or contradict the story told here.

Next Checks

  • move to architecture when the question becomes structural rather than boundary-oriented
  • move to interfaces when the question becomes contract-facing
  • move to quality when the question becomes proof or review sufficiency

Purpose

This page helps a reader quickly map package claims to code areas.

Stability

Keep it aligned with the real package modules and generated outputs.