Skip to content

Common Workflows

Most work on bijux-canon-ingest follows one of a few recurring paths.

This page should make those paths feel familiar and repeatable. Readers should not have to rediscover the same workflow from scratch every time they debug, extend, or review the package.

Treat the operations pages for bijux-canon-ingest 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["Common Workflows<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-ingest/pyproject.toml"]
    step1 --> page
    step2["CLI entrypoint in src/bijux_canon_ingest/interfaces/cli/entrypoint.py"]
    step2 --> page
    step3["HTTP boundaries under src/bijux_canon_ingest/interfaces"]
    step3 --> page
    run1["tests/e2e for package boundary coverage"]
    page --> run1
    run2["tests/invariants for long-lived repository promises"]
    page --> run2
    run3["tests/unit for module-level behavior across processing, retrieval, and interfaces"]
    page --> run3
    release1["CHANGELOG.md"]
    run1 --> release1
    release2["pyproject.toml"]
    run2 --> release2
    release3["README.md"]
    run3 --> release3
    class page page;
    class step1,step2,step3 positive;
    class run1,run2,run3 anchor;
    class release1,release2,release3 action;

Recurring Paths

  • inspect the package README and section indexes first
  • follow an interface into the owning module group
  • run the owning tests before declaring the change complete

Code Areas

  • src/bijux_canon_ingest/processing for deterministic document transforms
  • src/bijux_canon_ingest/retrieval for retrieval-oriented models and assembly
  • src/bijux_canon_ingest/application for package workflows
  • src/bijux_canon_ingest/infra for local adapters and infrastructure helpers
  • src/bijux_canon_ingest/interfaces for CLI and HTTP boundaries
  • src/bijux_canon_ingest/safeguards for protective rules for ingest behavior

Concrete Anchors

  • packages/bijux-canon-ingest/pyproject.toml for package metadata
  • packages/bijux-canon-ingest/README.md for local package framing
  • packages/bijux-canon-ingest/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 Common Workflows 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-ingest 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-ingest 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 makes common package workflows easier to repeat consistently.

Stability

Keep it aligned with the actual package structure and tests.