Skip to content

Installation and Setup

Installation for bijux-canon-runtime should start from the package metadata and the specific optional dependencies that matter for the work being done.

This page exists to keep setup honest. A maintainer should be able to tell which files actually define installation truth and which dependencies are merely present in the environment for unrelated reasons.

Treat the operations pages for bijux-canon-runtime as the package's explicit operating memory. They should make common tasks repeatable without relearning the workflow from logs or oral history.

Visual Summary

flowchart TB
    page["Installation and Setup<br/>clarifies: repeat workflows | find diagnostics | release safely"]
    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;
    step1["packages/bijux-canon-runtime/pyproject.toml"]
    step1 --> page
    step2["CLI entrypoint in src/bijux_canon_runtime/interfaces/cli/entrypoint.py"]
    step2 --> page
    step3["HTTP app in src/bijux_canon_runtime/api/v1"]
    step3 --> page
    run1["tests/e2e for governed flow behavior"]
    page --> run1
    run2["tests/regression and tests/smoke for replay and storage protection"]
    page --> run2
    run3["tests/unit for api, contracts, core, interfaces, model, and runtime"]
    page --> run3
    release1["README.md"]
    run1 --> release1
    release2["CHANGELOG.md"]
    run2 --> release2
    release3["pyproject.toml"]
    run3 --> release3
    class page page;
    class step1,step2,step3 positive;
    class run1,run2,run3 anchor;
    class release1,release2,release3 action;

Package Metadata Anchors

  • package root: packages/bijux-canon-runtime
  • metadata file: packages/bijux-canon-runtime/pyproject.toml
  • readme: packages/bijux-canon-runtime/README.md

Dependency Themes

  • bijux-canon-agent
  • bijux-canon-ingest
  • bijux-canon-reason
  • bijux-canon-index
  • duckdb
  • pydantic

Concrete Anchors

  • packages/bijux-canon-runtime/pyproject.toml for package metadata
  • packages/bijux-canon-runtime/README.md for local package framing
  • packages/bijux-canon-runtime/tests for executable operational backstops

Use This Page When

  • you are installing, running, diagnosing, or releasing the package
  • you need repeatable operational anchors rather than architectural framing
  • you are responding to package behavior in local work, CI, or incident pressure

Decision Rule

Use Installation and Setup to decide whether a maintainer can repeat the package workflow from checked-in assets instead of memory. If a step works only because someone already knows the trick, the workflow is not documented clearly enough yet.

What This Page Answers

  • how bijux-canon-runtime is installed, run, diagnosed, and released in practice
  • which checked-in files and tests anchor the operational story
  • where a maintainer should look first when the package behaves differently

Reviewer Lens

  • verify that setup, workflow, and release statements still match package metadata and current commands
  • check that operational guidance still points at real diagnostics and validation paths
  • confirm that maintainer advice still works under current local and CI expectations

Honesty Boundary

This page explains how bijux-canon-runtime is expected to be operated, but it does not replace package metadata, actual runtime behavior, or validation in a real environment. A workflow is only trustworthy if a maintainer can still repeat it from the checked-in assets named here.

Next Checks

  • move to interfaces when the operational path depends on a specific surface contract
  • move to quality when the question becomes whether the workflow is sufficiently proven
  • move back to architecture when operational complexity suggests a structural problem

Purpose

This page tells maintainers where setup truth actually lives for the package.

Stability

Keep it aligned with pyproject.toml and the checked-in package metadata.