bijux-proteomics-dev

bijux-proteomics-dev implements repository policy as versioned, tested Python instead of embedding it in shell fragments or CI-only behavior. It owns validators for documentation, APIs and schemas, architecture, security, quality, governance, compatibility, and release evidence.

flowchart LR
    M["Make target"] --> E["stable Python entry point"]
    E --> P["policy owner"]
    P --> V["validator"]
    V --> A["evidence in artifacts/"]
    V --> X["actionable failure"]
    P --> T["contract tests"]

Make targets provide stable operator commands; this package carries the policy and implementation behind them. The split keeps orchestration readable while allowing validators to have typed inputs, unit tests, and reusable failure reports.

Route by responsibility

Concern	Guide	Expected owner
find a validator or helper family	Module map	one durable Python module family
choose checks for a change	Quality gates	explicit gate and evidence contract
protect API and schema evolution	Schema governance	lock, compatibility, and generated evidence owners
validate public documentation	Documentation integrity	links, structure, claims, badges, and build checks
evaluate dependency or code risk	Security gates	static, vulnerability, policy, and allowlist checks
prepare publication	Release support	build, identity, version, artifact, and preflight checks
make a repository-safe change	Maintainer safe change	scoped edit, affected gates, coherent commit
decide whether code belongs here	Scope and non-goals	repository policy rather than product behavior

The package overview and package substance describe the implemented surface. Operating guidelines govern extensions and failure behavior.

Validator contract

Every repository validator needs:

1. a stable command entry point;
2. a clearly owned policy input;
3. deterministic repository discovery and output location;
4. success and failure tests, including malformed and missing inputs;
5. actionable diagnostics identifying the violated contract and evidence;
6. a nonzero exit status on failure;
7. documented scope and known limits.

flowchart TD
    I["repository inputs"] --> N["normalize and validate"]
    N --> C["evaluate named contract"]
    C --> R{"result"}
    R -->|pass| E["write bounded evidence"]
    R -->|fail| D["diagnostic and nonzero exit"]
    D --> O["owner corrects cause"]
    O --> I

A validator must not rewrite the input to make it conform, catch and discard a failure, or report success when a required tool is missing. Remediation belongs to an explicit owner command and remains separate from verification whenever the two actions can be reviewed independently.

Policy ownership

Product packages own scientific and runtime behavior. bijux-proteomics-dev may inspect those packages against repository contracts, but it does not become the source of truth for their domain models. Conversely, CI workflows call maintainer commands; they do not carry independent copies of validation policy.

This creates a traceable chain:

• the Make target names the operator contract;
• the package module owns policy evaluation;
• package tests exercise positive and negative behavior;
• CI repeats the command in a clean environment;
• evidence and failures remain available for review.

Failure discipline

Failures identify the exact contract, subject, expected condition, observed condition, and remediation owner whenever possible. Existing blockers remain visible and distinguishable from regressions introduced by a change. A missing dependency, stale generated artifact, empty test collection, or skipped required surface is not a passing result.

Generated logs and reports belong under artifacts/ unless the command explicitly governs a tracked repository output. Handwritten policy and generated evidence are reviewed and committed separately when they are not inseparable for correctness.