0.3.8

agentic-proteins

agentic-proteins is a legacy compatibility bridge for runtime entrypoints and imports.

Canonical runtime ownership is bijux-proteomics-runtime.

This package owns one thing: legacy compatibility routing for historical CLI, HTTP, agent, execution, provider, state, and tool entrypoints while all real behavior stays in canonical packages.

At a glance

• Use agentic-proteins only when an existing integration still depends on the legacy command, import root, or bridge submodule tree.
• Start new execution work from the canonical runtime package docs and treat this package as a migration bridge, not as a second runtime owner.
• Route runtime behavior to bijux-proteomics-runtime, lower scientific behavior to the canonical bijux-proteomics-* packages, and keep this layer forwarding-only.

Compatibility contract

• mirrors the canonical runtime root exports at agentic_proteins
• forwards surviving bridge families to bijux-proteomics-runtime
• forwards structure-report and lower scientific surfaces to canonical packages
• keeps the historical submodule tree explicit so legacy imports stay inspectable
• exists to preserve migration safety for existing integrations

0.3.8 Release Highlights

• The package now states its forwarding-only contract directly instead of sounding like a second runtime owner.
• Direct dependencies and optional extras are narrowed to the canonical bijux-proteomics-core and bijux-proteomics-runtime packages.
• Legacy CLI and import continuity remain documented, but new integrations are pointed at the canonical runtime package first.

Installation

pip install agentic-proteins

Quick start

For new workflow execution, start from the canonical runtime CLI:

bijux-proteomics-runtime --help

Use the compatibility CLI only when an existing integration still depends on the legacy command:

agentic-proteins --help

Prefer canonical imports for new integrations:

from bijux_proteomics_runtime.api.cli import cli

Legacy imports continue to work via forwarding:

from agentic_proteins import cli
from agentic_proteins.interfaces.cli import cli

Public APIs

New integrations should prefer canonical runtime imports, but the compatibility surface remains executable:

from agentic_proteins import cli as legacy_cli
from bijux_proteomics_runtime import cli as canonical_cli

assert legacy_cli is canonical_cli

Package identity

• Distribution name: agentic-proteins
• Import root: agentic_proteins
• Legacy compatibility CLI command: agentic-proteins
• Canonical replacement package: bijux-proteomics-runtime

Package boundaries

• this package owns compatibility routing only
• the root import agentic_proteins mirrors canonical runtime root exports
• this package keeps the durable bridge tree under interfaces/, agents/, orchestration/, providers/, state/, and tools/
• historical execution/, agents/execution/, and providers/experimental/ paths remain only as legacy aliases
• canonical runtime behavior belongs in bijux-proteomics-runtime
• canonical domain behavior belongs in the lower bijux-proteomics-* packages
• new features should land in canonical packages before compat forwarding expands

What this package must not do

• introduce package-local runtime semantics
• fork canonical provider or workflow behavior
• become a second owner for scientific or execution logic

Contract checkpoints

• legacy imports must forward without redefining canonical behavior
• compat docs must name the canonical owner for the surface they describe
• compat modules must stay forwarding-only unless migration policy explicitly says otherwise
• new integrations should start from canonical packages even while compat remains available

Choose this package when

• you must preserve legacy imports or CLI entrypoints during migration
• the change is forwarding-only and names a canonical owner clearly
• integration continuity matters more than adding fresh behavior

Route elsewhere when

• the change defines runtime orchestration, provider behavior, or domain semantics
• the helper mainly serves new integrations rather than compatibility
• the module would stop being forwarding-only

Verification route

• check compat tests for forwarding and migration proof before treating a new legacy surface as safe
• review docs/BOUNDARIES.md, docs/CONTRACTS.md, and docs/ARCHITECTURE.md when a change claims to remain forwarding-only
• use README.md, CHANGELOG.md, and package docs/*.md when the change affects package publication, metadata, or release-readiness expectations

Review questions

• does the change preserve legacy continuity for a surface that already has a clear canonical owner
• would the implementation still live entirely in canonical packages if the compat layer disappeared
• can the change be justified as forwarding-only without adding fresh runtime or domain behavior

Escalation route

• route the change to the canonical owner when the proposal introduces any new runtime orchestration or domain semantics
• stop and review docs/BOUNDARIES.md and docs/ARCHITECTURE.md when the compat layer would need behavior beyond import forwarding or stable aliases
• escalate before release when adopting the change would require documenting compat-only exceptions instead of the canonical package surface

Consumer impact signals

• expect review against the canonical owner when compat exports or forwarding targets change because consumers rely on stable migration continuity
• treat changes that alter forwarding behavior or canonical mapping as high-impact even when public import names stay stable
• expect a lower release burden when the change only tightens documentation or internal compat wiring without changing forwarding behavior

Explicit non-goals

• this package does not own canonical runtime orchestration or lower-package domain semantics
• this package does not add fresh product behavior for new integrations
• this package does not replace repository governance or release policy owned by the maintainer package

Documentation

• Product overview
• Product architecture
• Cross-package ownership
• Execution overview
• Canonical runtime package docs
• Compatibility package docs
• Changelog

Changelog

All notable changes for agentic-proteins are recorded here.

Unreleased

0.3.8 - 2026-07-01

Changed

• Reframed the package around the real compatibility-bridge contract instead of the retired full-runtime description, with docs and metadata that point readers back to canonical runtime ownership.
• Narrowed direct dependencies to the only owners the bridge should forward into: bijux-proteomics-runtime and bijux-proteomics-core.
• Kept legacy CLI and import continuity explicit while preserving forwarding-only package ownership and migration-ledger visibility.
• Aligned fallback version and optional dependency floors with the 0.3.8 release line.

Fixed

• Restored clean-checkout compatibility imports, lazy forwarding behavior, package contract checks, and isolated local-model test surfaces so the bridge behaves like a compatibility shim instead of a second runtime owner.

0.3.7 - 2026-04-21

Changed

• Updated package README links to readable markdown hyperlink text and aligned handbook navigation references with canonical proteomics docs routes.

0.3.6 - 2026-04-20

Changed

• Prepared the v0.3.6 release line by aligning fallback versions and inter-package dependency floors across the repository.
• Synchronized release automation and governance with the bijux-std v0.1.3 shared standards baseline.

Fixed

• release-pypi.yml now uses parse-safe publication gating for token/bootstrap checks.
• Protected workflow policy checks now accept shared-manifest-driven standards updates through approved control paths.

0.3.5 - 2026-04-19

Changed

• Maintainer release documentation now references the split repository release workflows (release-artifacts.yml, release-pypi.yml, release-ghcr.yml, release-github.yml) instead of legacy publish workflow names.
• README docs badges and package metadata documentation links now point to the numbered handbook route 02-agentic-proteins for stable docs navigation.

0.3.4 - 2026-04-11

Changed

• Release history now records the synchronized v0.3.4 proteomics publication line used by the shared tag-driven release workflow.

0.3.3 - 2026-04-10

Changed

• Release history now records the synchronized v0.3.3 proteomics publication line used by the shared tag-driven release workflow.

0.3.2 - 2026-04-10

Changed

• Release history now records the synchronized v0.3.2 proteomics publication line used by the shared tag-driven release workflow.

0.3.1 - 2026-04-06

Added

• Package family PyPI and docs badges were added to README and maintainer package notes for cross-package discoverability.

Changed

• README content was rewritten with clearer package value proposition, usage scenarios, installation, quick-start guidance, and boundary definitions.
• Package description text was enhanced for stronger PyPI search relevance and package discovery.

0.3.0 - 2026-04-06

Added

• Package-local release manifest and maintainer-facing package docs: README.md, docs/ARCHITECTURE.md, docs/BOUNDARIES.md, docs/CONTRACTS.md, and docs/maintainer/pypi.md.
• Package-local changelog publishing path wired in package and root metadata.

Changed

• Package URLs now consistently reference bijux.io/bijux-proteomics and github.com/bijux/bijux-proteomics.

Fixed

• Test path resolution now uses explicit monorepo-root detection so e2e, regression, and governance tests stay stable with nested package manifests.

0.2.3 - 2026-01-16

Added

• Expanded provider test coverage for ColabFold, OpenProtein, and local ESMFold utilities.
• Runtime capability validation tests and candidate filter unit coverage.
• Stability marking test for module annotations.

Changed

• Hardened local ESMFold utility tests to exercise error and success branches.

Fixed

• Reliability checks and helper tests to keep coverage and gating stable.

0.2.2 - 2026-01-16

Added

• Release alignment for docs, gates, and CI structure.

Changed

• Consistent documentation build and validation wiring.

Fixed

• Minor release hygiene issues discovered in CI.

0.2.1 - 2026-01-16

Added

• Expanded unit and integration coverage with new invariants, API, and docs gates.
• Additional tests for provider isolation, reproducibility, and abuse-case blocking.
• Fancy PyPI readme fragments for README + changelog publishing.

Changed

• Refactored tests/unit into a structured layout for clearer ownership.

Fixed

• Coverage floors and CI gates stabilized around new test layout.

0.2.0 - 2026-01-16

Added

• Architecture invariants, threat model skeleton, and design debt ledger.
• Reproducible runs via agentic-proteins reproduce <run_id> with hash checks.
• Determinism tests, artifact immutability tests, and invariant regression coverage.
• Provider isolation checks and chaos failure test for mid-run provider loss.
• Benchmark regression gate and per-module coverage floors in CI.
• Documentation system contracts, lint gates, and CLI surface audit coverage.
• API error taxonomy enforcement, correlation ID logging test, and OpenAPI drift guard.
• Dependency allowlist enforcement for SBOM changes.

0.1.0 - 2026-01-14

Added

• Deterministic, artifact-first execution engine with explicit run directories and state snapshots.
• Agent-based architecture covering planning, analysis, execution, verification, and reporting.
• End-to-end design loop with failure handling, stagnation detection, and human-in-the-loop gating.
• CLI for running, resuming, inspecting, comparing, and exporting protein design runs.
• Local and remote provider abstractions with explicit capability and requirement checks.
• Structured reporting system with machine-readable artifacts and human-readable summaries.
• Integrated evaluation pipeline supporting structure-based metrics and ground-truth comparison.
• Reproducibility controls, observability hooks, and execution telemetry.
• Example datasets and reference runs for local experimentation and validation.
• Comprehensive test suite covering unit, integration, regression, and execution boundaries.